日本のIT業界に巣くう大問題
人月での見積もりがエンジニアをダメにする（前編）
馬場史郎（グローバル ナレッジ ネットワーク）
2002/8/2
| 何げなく聞く“マンパワー”という言葉の裏に、ITベンダをむしばむ“人月問題”が横たわる。日本のIT業界に深く根を張ったこの問題が、エンジニアをダメにすると筆者はいう。人月問題とは何か、そしてそれを改善する方法とは？ |
| マンパワーという言葉 |
前編 マンパワーという言葉人月問題の意味とは現在のシステム提案の方法人月はSEのモラルを低くするそれでもユーザーに人月提示を行う理由後編 コンサルタント会社には人月提示がない横並び単価ではSEのスキルは上がらない職位は同じでも、スキルは同じではない1つの解決策は社内資格制度人月ベースではない方法の考察人月問題の思い出 |
筆者が現役のSEだったころ、“マンパワー”という言葉に抵抗があった。現在でもこの言葉に抵抗がある。IT業界では、プロジェクトを手掛けるときなどに「マンパワーが足りない」とか、「マンパワーは十分だ」という場合がある。その“マンパワー”という言葉だ。そうした言葉を聞くと、往々に「SEはスキルではなく頭数だけが問題とされている」ような気分となる。
さらに、プロジェクトでは「このプロジェクトは30人月掛かります。従って3000万円となります」などということがある。こうした表現にも筆者は抵抗を感じる。その言葉を聞くと、人間そのものが1人当たりいくらかで売られ、まるでモノ扱いされているように感じるからだ。
SEの仕事とは、システムを作り上げる仕事だ。その仕事には、新システムの企画や要件定義、設計などの上流工程の作業、プロジェクト全体を管理するプロジェクト管理など、付加価値のある仕事が多い。これらの仕事にマンパワーは関係がなく、SEの持つスキルこそが重要なのである。例えば、できるSEが設計したシステムとそうでないSEが設計したシステムとでは、時間だけでなく品質にも比較にならないほど差があるはずだ。このことは、ITにかかわっている人ならばだれもが知っている。
しかし、現実はできるSEもそうでないSEも1人当たり月いくら、いわゆる“人月”という単位で十把ひとからげで取引される。これで本当によいのだろうか？
この問題は、筆者のみならず多くのIT関係者が疑問を抱いていることだと思う。だが、日本のIT業界に深く根を張ってしまっているこの問題は、残念ながらいまだに解決していない。それによって、さまざまな弊害を生んできた。
この問題について今回、これまでの経験をベースに、問題提起の意味も含めて筆者の考えを述べたい。読者にとって何らかの参考になればと思うと同時に、遠慮のない意見もお待ちしている。
| 人月問題の意味とは |
いわゆる“人月問題”とは、「ユーザー（顧客）に何人で月いくらという仕事の提案方法に関連する問題」をいう。
ITベンダとユーザーとの契約には、一般的に請負型と委任型とがある。請負型とは、ベンダが仕事の完成を約束し、仕事が完了した後になって初めて、ユーザーから契約金額が支払われる契約形態である。それに対して委任型とは、委任された作業を行い、その作業量に応じてユーザーから契約金額が支払われる契約形態である。両者はこうした明確な区別がある。
このうち、後者の契約は作業量に応じた契約のため、必然的に人月契約や時間契約になりやすい。それに対して前者は、SEが数人だろうが数十人だろうが関係なく、仕事の完成を約束すればよい。そのため本来は何人月という提案をユーザーに行う必要はない。しかし、日本のベンダは前者の場合でも商習慣上、「このシステム開発は何人月となるので、この金額でやります」という提案を行うことが多い。もちろん、請負型の契約では、提示した人月に法律上の義務はない、完成すればよいのだ。
しかし、どちらの契約にしても人月をユーザーに提案することで、さまざまな問題が生じている。以下、IT業界で一般的な請負型における人月問題を中心に述べるが、委任型でも共通する部分があると思うので、ぜひ参考にしてもらいたい。
| 現在のシステム提案の方法 |
多くのベンダは、ユーザーにシステムなどの提案を行う場合、SEやプログラマなどの開発費を、「設計工程では何人月△△円、製造工程では何人月××円、テスト工程は何人月□□円。従って、合計何人月で○○円」という形で提示することが多く、このやり方が日本の標準的な見積もり提示方法となっている。
各工程の人月や総人月は、ファンクションポイント法で見積もったり、画面や帳票などの入出力数から見積もったり、経験値から見積もったりなど、各社はさまざまな見積もり方法で計算する。しかし、いずれの方法であっても、最終的には「人月」としてまとめられる。その人月に、SEやプログラマの月当り社内単価を乗じて見積もり金額を計算する。そこで使われる社内単価は、SEの職位やレベルで異なる企業もあれば、そうではない企業もある。また、人件費や管理費、そのほかの経費なども企業ごとに異なる。また、二次請けのSE、プログラマを必要とするような場合は、二次請けとの契約金額に何％かを乗じて合計金額を計算する。さらにリスクの度合いをも判断して、ユーザーへ提示する「開発費」を決め、そしてユーザーに提案する。
もちろん、提案した金額には何％かの利益も入っている。簡単にまとめれば、こうした人月ベースの見積もり方法で「人月」と「開発費」をユーザーへ提示する。提案を受けたユーザーは、開発費が高いとぼやいてみたり、人月単価を値切ったりする。
こうした見積もり方法は、建築物や橋などの物理的な“モノ作りプロジェクト”の方法を、コンピュータのシステム作りに応用したものだと思う。
この人月以外に良い方法があればいいのだが、現実として提案するシステム開発費は、人月以外の何をベースとして金額に換算し、それをユーザーに提示すればよいのかが分からない。なぜなら、根拠がハッキリしない金額を提示しても、ユーザーがそれを受け入れることはできないからだ。
ところで、人月にはどのような問題があるのだろうか。さらに、解決・改善するためのアプローチはあるのだろうか？ その点について私なりの意見を述べたい。
| 人月はSEのモラルを低くする |
多くのSEは、「われわれは自分のIT力を発揮してモノを作るのが仕事だ。ワークロードや時間を売っているのではない」と考えているはずだ。これは技術屋のプライドでもある。自分が“モノ扱い”され、1人当たり月いくら、という形で売られてしまえばモラルだけでなく、やる気も低下する。
従って、このシステム開発案件はこの金額だと、それだけをユーザーに提示すべきである。私は、工程別の人月とか、総人月を出してほしくないし、出さないでほしいと思っている。プロジェクトメンバーのSEならだれしも、工程別の人月や総人月を提示されると、ユーザーのところに自分が売られたような気分になるだろうし、ユーザーに提示した工数を意識して、行動が束縛されるように感じるものだ。
中には「自分はどうせマンパワーの1人。だったら時間どおり働けばよいのだ」と、成果よりも労働時間だと考えるSEも現れるだろう。そうしたことがSEを消極的にさせ、次第に受け身のSE、指示待ちSE、技術偏重SEなどに変身させてしまうのである。つまり、そうしたSEづくりを、人月提示は助長しているともいえる。
企業の経営者層の中には、「そんなばかな。SEがそう考えるのはおかしい。仕事ではないか」と考えたり、「SEは仕事をやればよいのだ。彼らのモラルの低下や彼らが技術偏重になろうが、受け身になろうが関係ない」と、考える人がいるかもしれない。とはいえ、SEが生き生きと働き、SEの能力が上がり、それが企業の生産性を上げるのだと考えれば、企業や企業の経営者層は、こうした点をいま一度再考してもよいはずだ。仮に、どうしても開発人月を提出する必要がある場合でも、SEの心理を考え、「人月はこれこれこういう事情でユーザーに提示したが、君たちは第一線のSEらしくやってくれればよい。それでもめたら俺が責任を持つ。ただし、しっかりとQCD（品質、原価、量・納期）は守れよ」というなど、SEを勇気付ける心配りが欲しいものだ。
| それでもユーザーに人月提示を行う理由 |
しかし、現実は多くのベンダが工程別に人月を明記した見積書をユーザーに恒常的に提出している。そこで彼らに、「なぜ、工程別人月や総人月をユーザーに提示するのか？」と質問すると、たいていは「ユーザーが要求するので提出せざるを得ない」という。その結果、要件定義工程では3人月でいくら、設計工程は10人月でいくら、製造工程では30人月いくら、よって合計50人月で5000万円といったような工程別人月や総人月をユーザーに提示する。
ユーザーはこのような見積もりを複数のベンダから受け取って、比較検討する。しかも、当然妥当な価格で契約したいと考えている。安かろう悪かろうでは意味がないし、といって高ければ良いというモノでもないからだ。最も重要なのは、自分たちが目的とするシステムは、どこのベンダであれば任せられるかにある。この観点で企業力や技術論なども含めた価格を比較するわけだ。
この観点ではユーザーにとって必要なのはトータル金額であり、工程単位の人月や金額は必要としないはずだ。それではなぜ、ユーザーは工程別の人月などを要求するのか？ それは、提案されたシステムの開発可能性を判断するための目安となるからだ。例えば、工程ごとの人月を見ながら、「この程度しか考えてないのか？これで大丈夫なのか？」とか、「これはかなり人が多いが、何か理由があるのか？ 聞いてみるか」というような判断材料となるからだ。
ユーザーは、システムさえ開発できればベンダが何人月掛けようとも関係ないのであって、人月そのものに興味があるわけではない。裏を返せば、ユーザーが信用するだけの提案ができれば、人月については「設計では約何人月考えています。その理由は……」などと口頭で説明すれば十分なのだ。これは売り込み時に競合があろうがなかろうが関係はない。各ITベンダは、このことを再確認した方がよい。もちろん、営業もSEも腕を磨いてそれだけの提案力を持てるようになることが重要だ。
| 筆者プロフィール |
| 馬場 史郎（ばば しろう） ●日本アイ・ビー・エムでSE、SEマネージャとして活躍。その後、金融機関営業統括本部などで統括SE部長などを歴任。1993年に萬有製薬へ入社して情報システム部で活躍後、1999年に大手IT教育ベンダのグローバル ナレッジ ネットワークへ入社した。現在は同社副社長。著書に『SEを極める50の鉄則』（日経BP社）などがある。 |
|
1/2
|
後編 |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
