まとめ:なぜ人月見積がダメか

| コメント(0) | トラックバック(0)

社団法人日本情報システム・ユーザー協会(JUAS)発行の『ソフトウェアメトリックス調査2007』を取り寄せて読んでみましたよ。SI関係の人は必読ですよね。私はいままで知らずに損していました。

そんなこともあり、年の瀬でもあり、今回の記事では表題の件「なぜ人月見積がダメか」について、現時点での総括をします。

人月見積方式の弊害に対する言論

「ユーザー企業は出席をとるな」,日本IBMの大歳社長が提言:ITpro (2001/08/31)

 「日本の商慣習でぜひとも変えて欲しいのは,ユーザー企業が我々の技術者の出席をとることだ。出席をとられると我々は開発の生産性を挙げようとする努力をしなくなる。1000人でできる仕事を500人でやってのけると,売り上げが半分になってしまうからだ。技術者の頭数ではなく,成果物について対価を払っていただける商慣習に変えていくよう,広く呼びかけたい」。日本IBMの大歳卓麻社長は8月30日の記者会見でこう提言した

よいSEにはよい報酬を,“人月いくら”はもうやめよう:ITpro (2001/11/19)

「ユーザーとベンダーでコミュニケーションする“言葉”が違うと不幸な結果になる」(リクルート 次世代事業開発グループ メディアデザインセンターシステムアーキテクト熊澤公平氏)。この課題を解決するために,リクルートでは今後は,かかったコストをアクセス数や会員数など売り上げに比例する数字で割った値を,SIベンダーとの間で共通の指標とする計画をたてている。システムの価格を評価する指標に,システムの価値やユーザー側の目標を表す要素を含め,両者が納得できる共通の“言葉”を見出そう,というわけだ。

(略)

東建コーポレーションのマルチメディア開発部次長の小山伸治氏は,「(できるSEとできないSEでは)6倍くらいの差がある」と見ている。「優秀なSEは簡単な要件のプログラムに対して3日でプロトタイプを作成し,1週間で完成させたが,だめなSEは1カ月でも仕様すらきっちりしなかった」

もっと大きな個人差を示すデータもある。米IBMのサンノゼ研究所の実験調査では,数百ファンクション・ポイント以下といった小規模なシステム開発で,開発者によって最大25倍の生産性の開きがあったという

まだまだ続く“人月課金”:ITpro (2002/10/17)

 請負契約にもかかわらず、開発の進み具合を、実際に投入した人月で計ることが多いのも問題と言える。本来なら成果物の出来具合、あるいは米国で普及している出来高(アーンド・バリュー)と呼ばれる数値で計ることが望ましい。

 ここにきて、官公庁のシステム調達改革の一環として、アーンド・バリューを使うプロジェクトマネジメント手法が日本で導入される兆候がみえてきた。その一方で、「アーンド・バリューは事務作業が増えるばかりで面倒」ともらすインテグレータもある。

 米国で導入が進んだ理由は、プロジェクトマネジメント学会の是澤(これさわ)輝昭理事によると、「アーンド・バリュー方式と報奨付きの契約がいわばセットになっていたから」である。

 報奨付きの契約とは、あらかじめ決めた開発コストの範囲で開発を終えた場合、顧客がインテグレータに報奨金を支払うもの。報奨金とは、日本の金一封などではない。決め方や契約方式はいくつかあるが、総開発コストの何%という相当な額である。

人月見積もりでは生産性は上がらない、IPAが警告 − @IT (2006/11/29)

 情報処理推進機構(IPA)は11月29日、2006年度「情報処理産業経営実態調査」の結果を発表した。この調査は「情報処理産業界の財務、経営状況の現状を把握し、今後の経営の参考に供する」(IPA)ことが目的で、1978年以降毎年実施されている。28回目となる今年は従来のアンケート調査に加えてヒアリングも実施し、労働生産性の分析などを行った点が特徴だという。アンケートでは861社から有効な回答が得られた。ヒアリングは25社に対して行った。

Twitter / From dusk till dawn (2007/12/02)

豊かさは、年収じゃなくって、時給で勝負しようぜ。一日3時間しかはたらかなければ、年収 200 万円でもリッチな人でしょ。

誰も知らないWeb業界「広告系」と「IT系」の違い @ ZEROBASE BLOG (2007/12/18)

工数見積・人月単価といった予算管理によって、企画(アイデア)やクリエイティブに対する投資性向は低い。


「レベル低い」「エセ独立系」「自己矛盾」――ジャステック神山社長にITベンダーの現状を聞く ビジネス-最新ニュース:IT-PLUS (2007/12/20)


人を出して、いくらというのでは技術者の努力を阻害する。人を出す数で決めたら、少しでも開発を前倒しするという努力がなくなるからだ。一括請負なら10カ月で見積もった仕事を9カ月でやれば我々の利益になるからがんばれる。

まとめ:なぜ人月見積がダメか

人月見積方式の問題点、それは、開発者の能力、付加価値を無視すること。

人月見積は「顧客価値」ではなく「製造コスト」にのみ焦点を当てた方法であることが問題なのです。全否定するつもりはないが、問題が大きすぎる。

ITの「価値」は「コスト」とは関係ない。

1ヶ月あたりの生産性(人月)、1時間あたりの生産性(人時)って人によって何倍も違うでしょう。弊社は「1人月100万円」といった、どこを切っても同じ金太郎飴のようにタレントを見るクライアントとは、仕事をしたくない。付加価値を認めてもらって正当な対価を頂戴したい。

FPとその問題点

Function Point法(FP法)というソフトウェア定量化の方法があります。ソフトウェアの「大きさ」を機能の数で表すものです。

少なくとも「人月」よりは妥当な指標になりうると思います。なぜなら、必要なFP数を実現すれば、「いくらのコストでそのFP数を実現したか」は関係ないともいえるので人月方式よりは良いと思います。

PM定量化の実践技術(2), リスクマネジメント(18)|プロジェクトマネジメント・ユニバーシティ (2005/02/09)

  • 工学的に開発するためにはさまざまな量を測る必要がありますが、その中でも最も基本的な「量」は「ソフトウェアの規模」です。
  • 見積り、開発計画、生産性、品質などすべてが開発対象のソフトウェアがどれほどの「大きさ」なのか、の上に成立っています。
  • 規模を計測する尺度には、ステップとFPがありますが、今後、ユーザにとっての機能価値を計測する手段として、FPがますます重要となっています。

しかし、そんなFPが普及すればするほど、新たな問題が認識されてくるでしょう。

ITの「価値」は「機能の数」とは関係ない。

人月見積という「コストの大きさでITの価値を計る価値観」を脱したとしたら、次にぶち当たる壁が「機能の数でITの価値を計る価値観」ですよ。

機能の数が価値だというのは意味不明すぎる。機能の数が価値ならば、冷蔵庫にはテレビがついているほうが売れるだろうし、ストップウォッチのついていない時計は売れないでしょう。

たとえば37signalsのBasecampには200万アカウントのユーザ登録がある事実は「機能の数が価値だ」という説の逆をいってます。37signalsは"Simplicity"を掲げ、「"Less is more"は"less"に失礼だ!"less"は"less"だ」といった訳の分からない主張をするほどイッちゃってる「少機能主義(ミニマリストというべきか)」の集団なのです。

あなたにも「このソフト、シンプルで使いやすい」という経験、ありますよね?

使い方、あるいは「使わせ方」のデザイン。ユーザビリティの観点でユーザ・インタフェイスをきちんとデザインすれば、必要な機能が減ることがある。そういった「価値」がFP法には反映されない。UIデザインで機能を減らすとFP値が減って価格が下がる。努力するほど損をする。

FP法はデザインの価値を認めないという点で、まだ不完全なのです。

結局はクライアント(発注元)の意識が変わってくれるしかないのですよ。先進的で意識の高いクライアントの登場を待ち望んでいます。

実際、弊社では、そういう先進的な考え方の企業とのおつきあいが多いです。ありがたいことです。今後はクライアントの啓蒙にも力を入れていきたいと思います。

トラックバック(0)

トラックバックURL: http://zerobase.jp/mt/mt-tb.cgi/209

コメントする

このブログ記事について

このページは、ishibashiが2007年12月22日 23:01に書いたブログ記事です。

ひとつ前のブログ記事は「Webサービスへの予算配分は、既存ユーザを大事に、新機能追加よりも既存部分の改善を」です。

次のブログ記事は「「デザイン」がソフトウェア開発を変革する」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。