http://www.martinfowler.com/bliki/CannotMeasureProductivity.html

設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。

生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。

これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし、コード書式も違うんですよ。仮に、同じ言語で、数え方を同じにして、同じコード書式にしたとしても、コード行なんかじゃアウトプットを正確に測れるわけがありません。

賢明な開発者だったら、同じことをやるのにいくつものやり方があり、それによってコード行が変わってくることくらいご存知ですよね。しっかり設計され、きちんとリファクタリングされたコードほど、コード行は短くなるものです。だって重複が無いんだもの。コピペぷろぐらみんぐだったらコード行は稼げるでしょうけど、重複重複重複重複で、設計は見てられないものになります。 メソッドのインライン化をサポートしているリファクタリングツールを使って、自分でやってみると分かると思いますよ。共通したルーチンをインライン展開してあるだけで、コード行は簡単に倍になるんです。

コード行なんてダメだなあって思ったでしょう。でも、コード行で生産性を測定しようと研究してる人たちは多いんですよ。 定評のある『IEEEソフトウェア』誌でさえそうなんですから。

さて。こんなコード行による計測ですが、まったくダメってわけでもありません。システムの規模を測るのにはちょうどよいのです。 100k行のシステムは、10k行のシステムよりも規模が大きいですよね。 だけど、私が一年かけて100k行のシステムを構築したのに、Joeが10k行で同じシステムを同じく一年で開発したら……どうでしょう。 私のほうが生産性が高いとは言えませんよね。成果物は同じだから生産性は同じなのかもしれませんが、私の設計がいいものだとは言えません。

もうひとつよく言われるのが、ファンクションポイント法による計測方法です。 こっちは、まあ、ね、分からないでもないですよね。でも完全には納得しているわけじゃありません。こんな話を聞いたことがあります。 ファンクションポイント法を使って同じシステムを計測したところ、結果がバラバラ（3倍！）になったんだって。

ファンクションポイント法が正確に機能を測定できるものだったとしても、まだ生産性のポイントを捕らえきれていないように思います。 機能性を計測して分かるのはソフトウェア開発自体のアウトプットでしかなく、本当のアウトプットはまだ他にあるのです。 ファンクションポイント法でシステムを計測してみましょう。私が100FPシステムを１年かけて納品したとします。Joeは同じ期間かけて、50FPのシステムを納品するとします。さて、私の方が生産性が高いと言えるでしょうか？……言えませんよね。私の100FP分の機能のうち、30FP分の機能しか実際にお客様に使ってもらえず、Joeの50FP分の機能はすべて使ってもらえるなんてこともあるのです。つまり、こういうことです。生産性数値自体は私のほうが高いですが、実際の生産性はJoeのほうが高いのです。

でも、使われる機能がどっちが多いかなんて、実際は関係ないのです。 私のシステムの30FP分の機能が使われ、Joeのは15FPしか使われないとしましょう。 でも誰かが気付きました。Joeの15FP分の機能は10ドルの余剰利益を上げて、私の30FP分の機能は5ドルしか利益を上げられなかったと。 （はあ何度目だよ）Joeのほうが本当の生産性は高いのです。彼のシステムのほうがビジネス価値を生んだからです。ソフトウェア開発の生産性を測る手段は、それによってもたらされるビジネス価値に基づいていなければなりません。

この考え方はプロジェクトの成功率にも関係してきます。 「ソフトウェアの成功」とよく言われるものは、だいたいウソです。 みんな失敗とは何のことだか、分かっていないからです。 成功プロジェクトというのは、プロジェクトにかかったコストよりも多くのビジネス価値をもたらすもののことです。Joeと私がそれぞれ５つのプロジェクトを受け持ち、私は４つ、Joeは１つプロジェクトを成功させたとします。さて、結局、私の方がJoeよりも良いんでしょうか？ いえいえ、必ずしもそうではありません。私の４つのプロジェクトがそれぞれ100万ドルの収入をもたらし、Joeのプロジェクトが（失敗したプロジェクト分のコストを合わせて）1000万ドルの収入をもたらしたとしたら……きっと昇進するのはJoeでしょう。

「計測できなければ、マネジメントなんかできないよ」と言う人もいます。そんなのは単なる責任逃れです。ビジネスはいつだって計測できないものを扱っているのです。企業弁護士の生産性をどうやって計測しますか？ マーケティング部門の生産性は？ 教育機関の生産性は？ そんなの計測できっこないのです。だけど、計測できないものをマネジメントしていかなければならないのです（詳しくはRobert Austinの書籍を参照のこと）。

チームの生産性が分かりづらいのであれば、個人のチームへの貢献度はさらに分かりづらいものでしょう。イテレーションにつきどれだけの機能を実装したかで、チームの成果をざっと把握することもできます。ざっくりとしすぎてはいますが、チームのスピードが上がったかどうか、もしくは、あるチームの生産性が他のチームよりも高いかどうかといったことは分かります。一方、個人の貢献はなかなか把握しづらいものです。機能を実装する役割のひとがいる一方、サポートの役割を担うひともいます（他のひとの実装を手伝う人）。彼らの貢献はチーム全体の生産性を上げています。しかしながら、チーム内にいないと、なかなか彼らの成果は分かりづらいものです。

以上でまだ物足りないのなら、『エコノミスト』誌（2003年9月13-19日号）に生産性の動向に関する記事が載っていました。 この記事によると、90年代におけるIT投資によりビジネスの生産性は高まっていると専門家は考えているのだそうです。 重要なのは、投資に対する効果のタイムラグです。つまり、IT投資をすれば自動的に生産性が高まるわけではないのです。企業はビジネスのやり方もしっかり把握する必要があります。このタイムラグは、電気の発明の際にも起こりました。

つまり、ビジネスの価値を計測するのが困難というだけでなく、 そこにはタイムラグの問題もあるのです。 チームの生産性というのは、構築したソフトウェアをリリースしてから 数年後に初めて分かるようなものかもしれないのです。

「生産性の計測」に魔性の力があるのは分かります。 生産性を測ることができれば、ソフトウェアを今よりも簡単に、 より客観的に評価することができるからです。 しかし、偽りの計測方法では事態は悪いほうにしか進まないでしょう。 この点について我々は、自分たちの無知を認めねばならないように思います。

コメント

2003/12/12 Fowlerさんは、ＦＰを誤解しているようですね。 要件が固まっているものを測れば、誰がやっても＋−5％の値になる（といわれる）のがＦＰです。 上の例は、要件が固まっていない時に、成果物規模をＦＰ単位で表示しただけにしかみえません。（上手裕）

  • 2003-12-12 (金) 11:23:07 ‘’[[kdmsnr]]’’ : “a factor of three from different function point counters”あたりの日本語訳には自信がありません。間違っていましたらすいません。
  • 2003-12-21 (日) 02:01:19 ‘’[[WR]]’’ : お客様に価値をもたらさない余計な要件をいっぱい作っても無駄じゃん？といいたいのでは？
  • 2004-02-12 (木) 13:03:48 ‘’[[HOGE]]’’ : でも、「お客様に価値をもたらさない余計な要件」って作ってみないとわからないですよねえ？
  • 2004-02-12 (木) 13:11:59 ‘’[[Wata]]’’ : 作ってみないと（もしくは、みても）わからないから、「生産性は計測不能だ」というお話では？
  • 2004-02-12 (木) 13:37:41 ‘’[[kdmsnr]]’’ : 条件次第でどうにでもなるという意味でしょう。
  • 2004-02-13 (金) 01:43:21 ‘’[[i]]’’ : 要求仕様が固まってから計測をスタートしますか？それとも社会との関わりの中で誰も想像したこともない価値の創造を指していますか？
  • 2004-10-28 (木) 22:03:04 ‘’[[村山]]’’ : 「要件が固まっているもの」ってのが，そもそも現実離れした仮定ですよね．理想論もいいところ．それに加えてこれで計れるのは「かかるコスト」であって「生み出される価値」じゃありません．
  • 2004-11-09 (火) 17:44:43 ‘’[[タイの像]]’’ : 例えると、ＦＰは東京−大阪間の距離（５５０ｋｍ）。生産性は時速。要件が確定しない段階で出すＦＰは、名古屋までか大阪までかが決まらないうちに、東京からの距離を出そうとするようなもの。で、途中割愛して結論は、生産性は測れる。少なくとも事後の。サービスエリアでの休憩時間が分からなければ正確ではないが、だからと言って測れないとは言えない。
  • 2004-11-09 (火) 17:56:14 ‘’[[kdmsnr]]’’ : 本文中にもありますが、視点を決めさえすれば相対的には測れるでしょうね。
  • 2004-11-10 (水) 09:28:34 ‘’[[sapp]]’’ : 生産性ってソースコードの生産性（LOC）なのか、機能の生産性（FP）なのか、ソフトウエアが生み出す価値（売価）の生産性なのかはっきりすれば測れるんでしょうけどね。その議論なしに生産性うんぬんというのは．．．
  • 2004-11-14 (日) 22:01:08 ‘’[[酔狂人]]’’ : ソースコードや機能の量って、むしろコストと考えるべきでは……。
  • 2005-03-01 (火) 10:37:10 ‘’[[名無しさん]]’’ : コスト、つまり例えば「納期遅れを防ぐ」という後ろ向きの生産性評価形態ってことでしょうかね。
  • 2005-03-01 (火) 10:37:32 ‘’[[名無しさん]]’’ : で、XPみたいに元々「コード(や関数やクラス)を書くこと自体は苦にならない」＆「それらを短く記述する術も充分知っている」というスタンスだと、プログラムを後ろ向きに計量されても馬鹿馬鹿しく感じるだけかも。
  • 2005-03-02 (水) 20:44:54 ‘’[[村山]]’’ : 「生産性は時速。」あまり適切なたとえではないと思う．シャーロックホームズじゃないけれど「全速力で2時間進んで，その後2時間戻る」とすると，これが「4時間分の生産性がある」と言えるだろうか？実際にもこういう手戻りが極めて多いのがソフトウエア開発の特徴で，酷い場合には「2時間進んで．１０時間道に迷って，12時間かけてスタート地点まで戻ってきて1時間仮眠．その後に1時間かけて目的地に着く」ということもある．この場合には「最後の１時間の生産性は，残りの24時間の生産性に比べて24倍の差がある」というだろうか．むしろ残り24時間の生産性はマイナスだったと考えた方がいいくらいでは．
  • 2005-08-30 (火) 14:36:35 通りすがり : 著者は何が言いたいのか・・・&br;いろいろと難癖をつけて生産性は計測できないから生産性でオレの成果物を語るなと言いたいのか。では著者はどのように作業を見積もるのだろう？コード行はあくまでも単なる目安に過ぎないし条件次第でいくらでも変動するものであることはわかっているはず。しかも結果の振り返り（分析とフィードバック）を行うこともせず・・・&br;何かよっぽど頭にくることでもあったのだろうか。。。
  • 2005-08-30 (火) 14:56:11 札幌 : だから、コード行数とかＦＰとかでソフトウエアの価値は測れないといっているわけで、見積もりとは関係ないです。また、エンジニアとしては、ソフトウエアの価値と関係が無い”生産性”でもって見積もりされ、結果としてエンジニア能力を評価されるのは面白くないので、自分としてはこの文面に共感を覚えます。
  • 2006-06-22 (木) 20:07:13 あぼーん : ビジネス的価値（プロジェクトの利益）とコーディングの生産性って別物で、そもそも比較するものではないと思うんだが・・・。プロジェクトマネジャの生産性か、コーダーの生産性か、ビジネスマンの生産性かという具合に、誰が対象かで、生産性の図り方を変えるのが適切なのではと、読んでから思った
  • 2006-06-28 (水) 20:00:15 m : 「(労働)生産性」というのは（少なくとも経済学では）「労働者1人が単位時間当たりに産み出す付加価値」のこと(単位はドル/人・時とか円/人・年とか)ですから、「開発に結局どのくらいの人月がかかったか」「最終的にソフトウェアがもたらしたビジネス価値はどれだけか」が分からないと計算できないものでしょう。「付加価値」を「受託会社の、そのプロジェクトにおける粗利」のようにごく狭く捉えれば、これは計測可能だと思いますが、それを用いるユーザの得る価値まで含めたり、パッケージソフトや社内で用いるソフトwo場合には計測が困難なのは間違いないと思います。ＦＰなどのメトリクスで事前に見積もれるのはあくまで開発コストであって付加価値ではありませんから、生産性と関係付けるのはおかしいですね。たとえばＦＰで見積もった100ポイントの機能のうちコストの関係で50しかリリースに入れられないと事前に分かったとして「ＦＰを使った生産性の計測」だと、どの50を選んでも生産性は同じということになりますよね。しかし、実際のビジネス価値がどれも同じなんてありえないでしょう。
  • 2006-06-30 (金) 19:37:36 ども : ソフト会社から見るとお客様が使ったかどうかや、それを使った収益は生産性と関係ないと思う。同じ50FP作ったら、使おう使うまいが同じ金額がソフト会社に入ってくる。同じ期間に売れる車10台作れるA工場と売れない車100台作れるB工場ならB工場の方が生産性は高い。だからB工場で売れる車を作るように振るのが経営者の仕事ではないかと。
  • 2006-07-13 (木) 20:46:28 m : お客様にすれば、同じ値段で同じＦＰのソフトを得てもそこから得られる付加価値が全く違ってくるわけで、つまりお客様から見たソフトの生産性は相変わらず計測不能ということになりますね。『アジャイル宣言』を読めば、「お客が何を得るかなんて関係ない。作る立場から見れば生産性は計測できる」なんていう考え方はＦｏｗｌｅｒにとって明らかにペケなものに見えるでしょう。
  • 2006-08-22 (火) 00:23:03 名無しさん : ＞設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。
  • 2006-09-20 (水) 17:05:36 あぽーん : 久しぶりに思いっきり幼稚な意見を目にしました。まだ、こんな人がいるんですねえ。
  • 2006-09-22 (金) 12:46:19 名無しさん : どの意見について？>あぽーんさん
  • 2006-10-15 (日) 14:15:42 なかじまゆうじ : 「っていうか、（ここで言う）生産性って何？」という意味ではあぼーんさんに同意。Fowlerさんも（意図は違うが）同じようなことをいっている気がする。でも、「わかんないものは、わかんない」と言ってしまっては「人類に進歩は無い」とも思う。
  • 2006-11-06 (月) 00:41:03 きしだ : 「測れる」と考えて計っているものが、ファウラー氏にとって本当に意味のある数値なのかが問題だろうと思います。リファクタリングによるシンプル化、コードジェネレーション、自動化、Railsのような優れたフレームワークの創出や利用などのように、達人な作業を行なっている人たちにとっては、「測れる」単純な何かを弾き出しても、それが意味のある数値にならないということの実感を説明している考えています。逆に言えば、「測れる」方々の現場では、測れるような取り組みのみ実践しているということになると思います。そしてそれは、ファウラー氏が価値ある取り組みと考えるところとは異なるということだと思います。
  • 2007-09-27 (木) 07:44:02 松本 安雄 : 生産性が計れないのは　計らないからです。経営成果に無関係な　労働生産性への偏向を捨てて、「基本投入費原理」に基づく　経営資本利益率に高度に相関する　「総合生産性指標」で計れば、ソフトウェアプロセスであろうとも　立派に測定が可能です。「基本投入費原理」を　ご研究下さい。◇
  • 2008-06-23 (月) 17:56:32 名無しさん : プログラマの開発効率
  • 2008-11-27 (木) 14:02:46 zjkpvcwd : muVBkdgwRmR