システム開発プロジェクトでは規模を表す単位として「人月」という単位がよく用いられる。これは技術者一人が1カ月労働することを意味し，人を数え る助数詞「人」と，時間を数える単位「月」を掛け合わせたものである。数学的な見地から見ると「人」は分離量であり「月」は連続量である。この分離量と連 続量の違いとは，例えば計算機について考えれば，分離量はデジタル計算機であり，連続量は計算尺である。つまり，「人月」とは分離量と連続量を掛け合わせ た特殊な単位であり，どちらかというと「概念」に近い。
この「人月」という概念を「人」×「月」という単純な数式で考えると大きな失敗を犯す。例えば，プロジェクトの後半で問題が発覚し納期遅延が発生しそうな場合，あとどのくらいの工数が必要かを算定し，追加要員を投入して遅延を挽回しようとすることがある。
これは，遅延挽回対策として非常に危険な方法である。遅延を挽回できるどころか，当初想定した追加工数以上に工数がかかってしまうことも少なくない。
Eさんの失敗
Eさんは入社12年目。これまで大きな失敗もなく順調に経験を積んできている中堅SEである。彼は1年目こそプログラミングを行ったが，2年目以 降は常にプロジェクト・サブリーダーを任され，昨年からはプロジェクト・マネージャ（PM）として働いている。これは一刻も早くPMの頭数をそろえたいと いう会社側の強い意向によるものである。
今回，Eさんは，得意先であるX社の備品在庫管理システムについて担当することとなった。要求仕様書はコンサルタントを使って既に作成 されており，内容としては十分なものであった。その仕様書を基に試算した結果，開発の規模は約400人月だった。ただし，現行システムのハードウエア・ リース期間が1年後に終了することが分かっていた。
そこで，X社としては1年以内に新システムを稼働させたいと考えており，納期の絶対順守を第一条件としてきた。プロジェクトの開始に当たり，Eさんは「12カ月で400人月だから1カ月平均約33人月。大したことはない」と考え，簡単にこの仕事を引き受けることにした。
なぜならば，Eさんは過去に1000人月規模のプロジェクトを2回経験したことがあった。Eさんとしては，サブリーダーではあったもののピーク時に40人の技術者を使って開発を成功させたという自負があったのだ。
実際，開発開始から8カ月が経過し単体テストまでは大きな問題もなく順調に完了した。しかし，結合テストに入ってから問題が発覚した。Eさんの後輩であるFさんがサブリーダーを務める伝票処理サブシステムの品質が悪く，システム間結合テストでバグが続出したのである。
さっそくEさんは，主要なメンバーを集めて対策会議を行った。その結果，伝票処理サブシステムの内部設計からやり直しを行う必要があるこ とが分かった。伝票処理サブシステムの規模は，全体規模の約1/5であった。そこでEさんは技術者を増員することでこの危機を乗り越えようと考えた。
Eさんは会社の上層部に対して「利益率こそ下がるものの，残り3カ月で20人のプログラマを増員すれば納期を順守でき，当社の信頼を保つことができる」と力説したのだ。上層部はEさんの熱意と彼の実績を考慮し，Eさんの対策案を許可した。
Eさんの考えは簡単だった。問題となっている部分の内部設計～プログラミング～単体テストに必要な工数が約60人月である。そこに結合テ ストと総合テストで必要な工数を合わせると約80人月になる。そこで既存メンバー10人に追加メンバー20人を合わせた30人で3カ月間実施すれば，追加 メンバーの立ち上がりを考えても間に合うはずである。
しかし，実際はそうは行かなかった。既存メンバーは追加メンバーへの指導に掛かり切りとなった。また追加メンバーのモチベーションは上がらず，全体としての生産性は要員を追加する前よりも明らかに低下してしまった。
結局，納期は守れず3カ月遅延での納品となった。当然リース期間延長に伴う諸費用についてもEさんの会社が負担することとなり，プロジェクトとしては完全に失敗に終わったのだ。
Eさんが失敗した原因はいくつかある。
一つは，プロジェクト開始当初にシステム規模と開発期間が分かっていながら，プロジェクトを楽観視したことにある。PMは，システム規模と開発期間が分かった段階で，そのプロジェクトの難易度を想定しておく必要がある。
難易度が高いと分かっていれば，要員計画を行う際に多少コストはかかったとしても専門のアーキテクトやDBA（データベース管理者）を配 置したり，ベテランのSEを確保したりと事前にリスクを回避する手立てが打てる。新米SEの5人月とベテランSEの5人月とでは，たとえ「工数」が同じで あったとしても，その内容が全く異なることは言うまでもない。
なお，このシステム規模と開発規模の関係については，IBMが発表しているWalston ＆ Felix統計値（WF統計値）が有名だ。このWF統計値は，開発期間がそのシステム規模に妥当かどうかを判断する目安となる。日本情報システム・ユー ザー協会（JUAS）でも国内の開発事例を基に同様の統計値を作成している（図）。JUAS統計値のほうがIBMの統計値よりも生産性が高くなっている。筆者は，JUASの方がより実態に近いと感じている。
 |
| 図●Walston & Felix統計値 |
二つ目の失敗の原因は，開発の終盤に大量にメンバーを増員したことである。Eさんが単純に必要な工数と残りの月数から増員数を算出しているが，そもそも これが間違いである。理由は先に述べたとおりで，「人月」という概念を，「月」を定数としたために，帳尻あわせの「人」を算出していることにある。つまり Eさんは「人」の持つ様々な属性を考慮していなかったとも言える。例えば，コミュニケーション能力やモチベーション，能力が発揮されるまでの助走期間など である。
どうすれば良かったのか？
一つ目の失敗の原因を潰すには，プロジェクトの開始に当たってそのプロジェクトの難易度を計測しておくべきであった。このケースの場合，JUAS統計値を用いると期間Mは約18カ月である。
仮に，上記期間の±20％を妥当な開発期間だとすると，最低でも14.5カ月必要である。つまり，Eさんは今回の12カ月という開発期間 が非常に厳しい期間であることを認識する必要があった。その上でこれを考慮した要員手配を行ったり，契約前に開発期間について再リースを含めた交渉を行っ たりする必要があったのだ。
二つ目の失敗の原因を潰すには，プロジェクトの後半で大量に増員するのではなく，現在いるメンバーを活用すべきであった。または，優秀な人材（一般に火消し役と呼ばれるような技術者）を小数投入する必要があった。
今回のケースの場合には，内部設計からやり直す必要があるということが分かっていた。そうであれば，プロジェクト内の別のチームから厳選 した要員を増員するという方法があった。この方法であればコミュニケーションに関する問題は発生しない。プロジェクト開始から半年以上一緒に仕事をしてい る仲間である。どの技術者が優秀であるかは見当が付くはずだ。そういう技術者を集めた特別チームを編成して，対策を行わせるという方法があったはずであ る。
一方，プロジェクト外から増員するのであれば，他のプロジェクトで火消し役の経験のある技術者を少数投入し，その技術者に強い指揮権を 与えるといった方法が有効である。いずれにしても，今回のケースの場合，Eさんが過去に大きな失敗プロジェクトを経験していなかったことがこれらの原因に 結びついた。
「人月」という概念は，それを導出するときには「人」と「月」を掛け合わせて算出する。しかし，ひとたび計算されて「人月」になると，これを分解することは非常に難しい。なぜならば，「月」という連続量が含まれているため，無限に分解することができるからだ。
このことを理解しておかないと，Eさんのように帳尻あわせの計算をして大失敗をしてしまう。「3人×6カ月＝18人月」と計算したつもりでも，18人月という数値だけを受け取った相手が「6人×3カ月」と人月を入れ替えてしまうこともあり得る。
PMは，工数の報告を受けた時に，単純に上記のような計算してはならない。人月を入れ替えることが無いように，その工数の内容について充分精査する必要がある。具体的には「人月」を構成する「人」と「月」について，あらゆる角度から分析・精査を行うべきなのだ。
プロジェクトを構成する「人」は生き物であり，それ以上分解することはできない。PMたるもの，このような「人」を，工数計算においても数式だけで単純に扱わないということを常に心がけるべきである。
●●コメント●●
0 件のコメント:
コメントを投稿