ITを統べるためのヒント

　CIO諸氏にとり悩ましい問題の筆頭は社命を賭すような開発プロジェクトであろう。特に、今後予想される社会に開かれたユビキタス対応の基幹系システムの再構築プロジェクトなどでは、従来のリスクに加えてインターネット時代特有のレピュテーション（評判）リスクを考慮する必要がある。もし、テスト不十分なシステムをカットオーバーし不具合が露見すれば、ブログやツィッターなどで悪評を散々に呟かれる恐れが強い。その結果、自社の評判が簡単に地に落ちることになる。これまでのシステム開発のトラブル以上に、企業に重大なダメージを与えかねない。そこで、本稿では、システム開発を客観的に見つめて、成功に導く方法があるのかどうか、そして、特にこれまでのキャリアで情報システム部門に縁のなかったCIO諸氏の取るべき選択肢などについて考えてみたい。

プロジェクトのマクロモデル
　まず、客観的に見てシステム開発とは、どのようなプロセスなのであろうか。図5-１に示すのは、プロジェクトの外側から見たマクロモデルである。開発というプロセスの入力はシステム機能要件であり、その具体的な量を示すものとしてはプログラムの開発規模である。そして、開発プロセスの中で時間と開発要員をかけて出力するものが情報システムである。この出力物については、信頼性や性能、実現機能などに関する品質基準をクリア―することが求められる。この品質基準合格の諾否は、入念なテストによってしか確認できないことはご存じの通りである。そして、これらの変数の間で以下のような式が結果的に成立する。
 

　W=M×T＝V÷P 　W:総工数（人月）、 Ｍ：平均月間投入工数（人）　T：開発期間（月）　V：開発規模（fpまたはkloc）、P：1人月当りの生産性（fpまたはkloc／人月) 　但しfp=function point  kloc=1000 lines of code
 

　さて、「この式は結果的に成立する」と述べたのには理由がある。例えば、開発期間1年で毎月50人の技術者を動員したプロジェクトの総工数W=12（月）×50（人）＝600人月ということになる。であるならば、投入する人員を月平均4倍の200人に増員すれば、開発期間は四分の一のT=600÷200＝３か月ということに計算上はなる。しかし、実際には、そうならない。それは、システム開発は、複数の工程を踏み、それぞれの工程に一定程度以上の時間がどうしてかかるからである。従って、単純に人数を増やしたから、その分期間短縮ができる訳ではないのである。そこにシステム開発の難しさがある。

プロジェクトの変数と因果関係
　次に、このモデルに出てくる変数がどのような性質のものか見てみたい。
 

＜プロジェクトのマクロモデルの変数＞
（1）V（開発規模）：主にシステムの機能要件を元に見積られる量で、開発が進むごとに予測値から実績値に変化する。計画段階では見積りの精度が問題で、もし、誤差が大きいとすると、計画の信憑性に大きな影響が出る。

（2）P（生産性）：1人月当たり、どの程度の規模のプログラムを作成できるかという人月当たりの生産性の数字であり、これも計画段階では予測値である。そして、開発の進行とともに実績値に置き換わっていく。一般に、開発の規模が大きくなると、生産性は低下する傾向にある。

（3）W（総工数）：V（開発規模）をP（生産性）で割ることで求められる開発で必要となる人月数である。この数字をもとに、開発コストが概算される。つまり、投入される開発要員の平均月額単価を掛けることで、総人件費を見積ることができる。

（4）T（開発期間）：開発期間は、事業運営上要求される稼働時期と、開発工程の積み上げの双方から妥当な開発期間を決めるのが普通である。しかし、今日では一度決めた稼働開始時期を延ばしたりするのは、レピュテーション・リスクなどの観点から好ましくない。つまり、開発期間はもはや変数ではなく、絶対に実現すべき目標となっているのが現実である。

（5）M（月間平均投入工数）：W（総工数）をT（開発期間）で割ることで求められる数値であり、開発要員の動員の目安になる。
 

　このような諸変数の相互関係の中で、プロジェクト管理は行われるのである。そして、一般的に情報システム部門に精通するマネジャーは、P（生産性）の数字を上げて、開発の納期を守ろうとする。しかし、プロジェクトをコントロールするための変数は、生産性だけではない。
  
マイクロソフト流の制御法
　そのような中で、マイクロソフト（MS）社が自社内の開発で採用していると言われる「同期化安定プロセス」と呼ばれる手法に注目すべき点があると筆者は考える。この手法に関しては、米国MITのマイケル.A.クスマノ教授の著書『ソフトウェア企業の競争戦略』（ダイヤモンド社、2004）で紹介されたもので、MS社が苦労の末にシステム開発を安定的に着地させ、アナウンスした納期を遵守する手法である。図5-２に示すのは、その基本的な概念図である。この手法は、開発とテストの二つのチームに分けたりする同社の開発組織の作り方なども参考になるが、筆者が着目するのは、実現する機能仕様の扱い方である。まず、開発中のバージョンで装備する予定の機能を三つほどのサブプロジェクトに分ける。そして、第一グループには、絶対に必要な機能を分類する。第二グループには、その次に必要と思われる機能群を収容する。そして、第三グループには、その機能があれば良いが、今回分としては必ずしも必要ないかもしれない機能を入れる。そして、第一グループをまず完成させ、次に第二グループに着手する。そして、納期が近付いた段階で、最低第二グループは完成させておくことにし、第三グループは日程に余裕があれば挑戦するという分類にしておく。そして、腹七、八分目の仕様である第二グループまで反映したものを確実に納期までに作るという考え方で運用する。この結果、一時は納期遅延を繰り返したMS社は、この手法の採用で以後、安定的に製品の出荷を行えているのだという。

主体的なプロジェクト制御の基本
　この事例の示唆するところは、非常に重大である。システム開発のプロであるMS社ですら、納期を守るために制御可能な変数が、生産性（P）ではなく開発規模（V）であると考えていることだ。筆者の経験でも、プロジェクトが遅延してくると、生産性を向上させる一発逆転の策が練られるが、成功した事例を見たことがない。逆に現場を混乱の淵に追いやり、余計に遅延の幅を拡げたりするのである。よく見かける“うまくいかない遅延解消法”を上げてみよう。まずよく出てくるのが「生産性を上げるツールの採用」である。しかし、一般的に生産性が上昇するのは、そのツールに熟練してからであり、短期的には逆に生産性が落ちることが普通である。このようなツールは、開発着手前に開発部隊に十分に使用させ、熟練させておくという準備が不可欠なのだ。それ以外のよくある遅延救済策としては「人員の追加投入」という策がある。つまり、生産性が上昇しないのであれば、投入人員数を増やすということだ。しかし、これも十分に考えて行わないと現場に混乱を生じさせる。それは、新規の要員に仕様を教えるなどの余分な作業が加わり、従来からの要員の生産性が落ち込むからである。この混乱は、最低一カ月以上は続くので、人員の追加投入の決断は、残りの期間がまだかなり残っている時に行えば、効果が見込めるのだが、納期間際の追加投入では効果は期待できない。
 

　このようにシステム開発プロジェクトの生産性を向上させるなどで、納期に間に合わせるという試みは、現場に精通したプロマネが行っても容易に成果につながるとは言い難いのである。そこで、MS社の方法は、経営者層が自らの判断で変動させることができる唯一の変数である開発規模（V）に直結する機能要件を変動（主に減らすという方向）させることで、納期を守ろうとするものである。つまり、システムに詰め込む機能量と納期をトレードオフするのである。これならば、経営者層が自分の判断で決断でき、自分で調整可能な変数となるのである。

制御の鍵は「自分の扱える変数の発見」
　情報システム部門出身のCIO氏でも難しいプロジェクトの制御に、システム経験のないCIO氏が立ち向かうにはどうしたら良いだろうか。その一つの答えがMS社の手法で、機能仕様に実現の優先度を最初から設けておき、開発の実情に合わせて、腹八分目の仕様で我慢することで、開発期間をコントロールするやり方である。この方法は、システム開発の実務には精通していないCIOでも、自分のこれまでの経験をシステム仕様の優先度を評価する場面で発揮できるということだ。その点に関しては、情報システム部門出身者よりも、ユーザーとの交渉力が高いかもしれない。つまり、情報システムに精通していないCIO氏の場合、自分が主体的に動かすことができる変数は何かを見極めることが重要である。例えば、マネジメント一般の制御手段として人事というプロセスの制御手段がある。プロマネを誰にするのか、主要なSEの誰を投入するのかなど、他の案件との関係を睨みながら、十分に検討することである。このように、自分が主体的に操作できる変数がどれなのかを見極めることで、他力本願的状況から脱し、プロジェクトを制御可能にする道を発見できる可能性があると筆者は考えている。そのためには、細部に拘らずマクロ的にシステム開発をモデル化し、その中の変数のうち、制御できるもの、制御不能のものをまず把握するだけで、有効な手段の発見につながる可能性が高い。また、情報システム経験者のCIO氏の場合でも、納期を守ることがいくつかの機能の先送りで可能になるという選択肢を忘れるべきではない。このようにCIOという立場は、現場で技術的な問題に対応するSEとは異なる立ち位置にあり、まったく異なる視点からのプロジェクト成功への制御法が求められるのだ。そこで、次回は、経営のミッションとSEのミッションとの違いを考えてみたい。