●連載・プロジェクト管理のつぼ●

第一回　キモに銘じておくこと

プロジェクト管理委員会
（promgt@bolero.plala.or.jp）


第二条：人は言葉でごまかせるがシステムは嘘をつかない

　システムの仕様定義や設計に曖昧な部分を残したまま開発を進めると大きな手戻りを発生させたり、最悪の場合は機能の矛盾や処理方式の欠陥が原因でシステムがまともに動かない事態を招く。このような問題を防止するためウォーターフォール型システム開発では作業の手順を「工程」に分割し、工程毎の達成確認をしながら、次の工程へ進むという方法をとる。

　工程終了判断のために、開発プロジェクトで定めた手順の中に（例：各種手順書や開発実施要領）チェックリストや判断指標が用意されていると思うので、発注側と委託先のメンバーで構成される開発管理チームは、それらを利用して客観性の高い材料を揃えた上で判断を行なうことが基本となる。

　また、開発作業では、不測の事態が発生することは多々あり、標準的な指標が使えないこともある。その場合の判断は決して単独では行なわず、信頼できる複数の経験者の意見を求めて判断する。

　好ましいことではないが、現実には当該工程で達成すべき目標に到達できていない（部分的な遅れを内在している）が、全体の作業を進めるために工程終了の判断をしなければならないことが起こる。常に起こるといったほうが正しいかもしれない。この場合、未達成事項を実施担当者との間で明らかにした上で、その対策を検討する。一例として、遅れを次工程で回復させることを条件に当該工程の終了判断をする場合、新たな作業スケジュール/達成条件の設定/追加リソース投入の有無などをチェックし、課題管理の対象とする。

　工程終了判断時の委託先の報告において、よく見かける傾向として下記がある。

�@委託先の開発会社は立場上、達成度が高いという判断に偏りがちである。
�A未達成事項の先送りを主張する場合、その問題自身が矮小化されて扱われている場合がある。

　未達成事項を単に先送りするだけは事態を悪化させるのみというのは、読者の皆様にも直感的にご理解頂けると思う。しかし、ここで申し上げたいのは、先送り自身が悪いというのでなく、未達成事項や先送り事項に付帯する問題の有無も確認し、全体計画への影響の程度をその都度必ず判断しなければならないということである。当事者にとってみれば次工程の作業が苦しくなるのが判っているので時として実態を直視せずに問題を矮小化したり、さらなる先送りを主張することがあるからだ。実際には委託先の事情を聞くともっともなこともあるので状況を考慮しながら対処するが、このようなことを安直に受け入れ始めるといろいろな矛盾が拡大され、あとでツケが廻ってくる。人は言葉でごまかせるがシステムは嘘をつかない。再発するリスクを大きくしないため、発注側の開発責任者は委託先とよく話し合って計画的な回復の方策を見つけることが大切である。

第三条：実態把握の遅れはマネージャーの責任

　第二条では、開発の各工程終了時の達成確認や委託先からの報告について注意しなければならないことを書いたが、第三条もこれに関連した事項である。

　開発責任者や各マネージャーは、進捗などの状況を確認するために定期報告を求め、それをチェックする。また、上記に延べたように、各工程の終了判断をするために工程の後半で、開発状態や完了見込みに関する報告を求める。さらに、様式を定めた報告以外に適宜メンバーや委託先からの意見も聞き、プロジェクト運営に反映してゆく。

　委託先の開発会社は立場上、達成度が高いという判断に偏りがちであると書いたが、発注者側の開発責任者は委託先からの聞き心地の良い報告を鵜呑みにしたり、楽観的な判断を積み重ねて問題発見の機会を逸してしまうことがある。実際の開発作業では、本来発注者自身が行なわなければならない業務を委託先に代行してもらう場合もある。そうすることで開発管理作業を効率的に実施できる場合もあるからだ。そのような時、委託先からの聞き心地の良い報告のみを信じ、その報告の裏付けデータに目を通すのを怠ると、後で重大な問題を招くことになる。本来早期に発見できる問題が発見されないで、システムの内部に矛盾を抱えたまま作業が進行し、発見が遅れ、サービス開始時期を変更せざるを得ない等の事態に発展してしまう場合もある。

　楽観的なことも大切なことであるので一概に否定できないが、ことと次第によるということをわきまえなければならない。「良い報告には裏があると思え」というと言い過ぎかも知れないが、委託先に楽観的判断の傾向が認められる場合は、発注側の責任者はあえて慎重に解釈してみるなどバランスを保った現状認識が必要かと思う。

　さらに、各工程終了時の達成確認や報告チェックに関連して重要な事項として、「ファクトを見る」がある。開発状態に関する報告に関しては、報告内容がファクト（事実）であるかどうかをマネージャー自らが確認する義務がある。一般的には、ファクトでないもの（意見など）をファクト（対象の状態）と分離して報告してもらえば判別できるので、定期報告の様式や工程別の成果報告様式に反映させておく。

　しかしファクトと規定した報告に関しても、人間の目を通して認識・報告されたものであるため、ファクトと期待（願望や予想）が混在している、作業状況説明の方が精緻で製品の状態や成果の説明がアバウトである、再委託先の報告を十分吟味せず寄せ集めたため内容がチグハグである、「〜の筈である」という報告になっている等、いろいろなノイズが含まれていると心得た上で報告を聞く/読むことが大切である。

　このようなノイズは大抵委託先の個性に依存した一定の傾向（くせ）が出る。ノイズが一定で小さいうちは受け流せばよいのだが、問題の芽を抱えている場合もあるので、ノイズが多かったり質的に変化したと感じたら注意深く報告を吟味する。後述するis/is not（イズ/イズノット）の質問を行い、報告内容を揺すってみるのも有効である。

　以上述べたように、実態把握の遅れはマネージャーの責任であり、実態把握にはファクトを確認することが重要であると心得た上で、各種報告を聞く/読み、さらに場合によっては自分から情報収集に努めるという姿勢が大事である。

第四条：確認はis/is not（イズ/イズノット）で行なう

　仕事の進み具合や状態を確認する場合、期待していることに関して現状はどうか、というチェック形式を一般的にとる。ルーチン的な業務ではこれでだいたい事足りるが、システム開発のマネジメントでは確認がこれでは十分とはいえない。

　開発状態をバランスよく見極めておく必要がある。問題を早く発見したり、それ以上大きくしないためには

・期待したくないこと（付随する問題）の状態はどうか
・問題（目標と現状とのギャップ）に対して取り組むべき課題は何か

という観点でも継続的に状態を把握することが必要である。継続的にモニターしていると「変化」に気付くので、問題が小さいうちに発見できるという大きな効用がある。

　is/is notとは、「そうであること：is」を確認するとともに、対極にある「そうでないこと：is not 」のほうも一緒に押さえておくということである。対象物の認識方法にis notの観点を加えることによってisを再認識させる効果もあるので、曖昧性や漏れを低減するのに有効である。is/is notはいろいろな局面で活用できる。

　is notの内容を発見する（隠れていることに光を当てる）こと及びその事象への対応は、開発責任者、マネージャーの重要な仕事である。発見したら課題を確認するとともに、作業計画の修正やリソースの調整が必要かどうか必ず点検する。放置するとシステムは矛盾を正直に抱えたまま作り上げられるという事実を常に念頭におかねばならない。

第五条：当たり前のことを（A）、バカにせず（B）、ちゃんとやる（C）

　第一条から第四条で述べたことは、一度はプロジェクト管理業務の経験がある方ならば、「なんだ当たり前のことだ」と思われるのではないだろうか。そのとおりである。しかし、実際の開発現場では、なかなかその当たり前のことが実践できていないのも事実である。そこで、第五条は、ABC（当たり前のことを（A）、バカにせず（B）、ちゃんとやる（C））である。これは、筆者の一人が、約20年ほど前、ソフトウェア工学の研究が盛んであった頃に、大先輩から教わったことである。

　人間、誰しも楽をしたいと思うのだが、開発責任者や各マネージャーは、進捗報告、各工程終了時の達成確認や各種報告を、毎回、注意深く確認するとともに、各開発現場で規定されている開発作業標準の徹底を粘り強く推進していかねばならない。

■おわりに

　今回は発注者側としてシステム開発やソフトウェア開発に携る責任者やマネージャーをターゲットにプロジェクト管理の心得について紹介させて頂いた。次回は、「開発作業計画の作り方」と「進捗管理」についてご紹介する予定である。

　なお、プロジェクト管理作業において注意しなければならない事については他にも多くの事があるのも事実であり、また他の優れたアイディアや本稿へのご意見・コメント等をお持ちの方もいらっしゃると思う。冒頭のアドレスまでメールを頂戴できると幸いである。

参考文献
[１]F.P.Brooks,Jr.The Mythical Man-Month:essays on software engineering （Anniversary
edition）, Addison-Wesley （1995）（人月の神話,ピアソン・エデュケーション（1996））
[２]M. Cantor, Software Leadership, Addison-Wesley（2002）（ソフトウェア開発管理の要, ピアソン・エデュケーション（2002））
[３]竹野内勝次他, SE のためのプロジェクト管理心得ノート,日刊工業新聞社（2002）
[４]佐藤義男,PMBOK によるIT プロジェクトマネジメント実践法, SRC（2002）
[５]P.Jalote,ソフトウェア開発のためのプロジェクトマネジメント入門, SOFT BANK Publishing（2003）
[６]竹山寛, ソフトウェア開発工程管理,技術評論社（2000）
[７]P. McBreen, Software Craftsmanship,Addison-Wesley,（ソフトウェア職人気質, ピアソン・エデュケーション（2002））
[８]秋月明彦他, SEの持つべき「思想」,すばる舎（2003）