今回は本連載のまとめとして、筆者が考えるプロジェクトマネジメント（PM）の勘所を提示したい。常に基本を大事にし、冷徹に考え、情熱を持ってプロジェクトに向き合うことが肝心である。そして、プロジェクトの成功は何よりも顧客との運命共同体の形成にあることを強調したい。1年間365句に込めた筆者の経験則が、読者が関与されるプロジェクトの好展開に少しでも役立つことができれば幸いである。
情報システムは他に比べ、契約仕様があいまいなだけに、あいまい性への対応が、プロジェクト成否の鍵を握る。SEは、契約仕様のあいまい性を前提に、見積もり方法や契約条件の定め方、仕様の確定プロセスについて、しっかりとした戦略を立てる必要がある。
しかし、要求があいまいということは、要求の実現方法もいろいろあってよいということだ。要は顧客の要求を何とか実現でき、顧客が満足できることが、解になる。決して、だれもが同じ解を出さなければならないというものではない。要求のあいまい性と共存し、ベンダーとしても何とか赤字を出さない解を見つけ出せるSEこそが、ス ーパーSEだといえよう。
逆に言えば、あいまい性の波を上手に乗り切ることがSEという仕事のやりがいであり、醍醐味でもある。
見積もりを事務作業の一つとみなす傾向があるのは問題だ。見積もりの重要性を徹底するためにも、見積もり業務と言わず、むしろ「見積もり設計」と呼んで真剣に取り組むべきであろう。
工程表についても、単なる管理ドキュメントとみなすのが問題だ。工程表はシステムの展開戦略、実現手順を表現する重要なドキュメントなのだから、「工程表の作成」という言葉ではなく、「工程設計」と名付け、「工程という設計図を書く」という気持ちで臨むことが重要である。
テストにおいても、テスト実施のはるか前に、本体設計と並行してしっかりとした「テスト設計」が展開される必要がある。まして、中核となるプログラムを、設計抜きで試行錯誤的に作ることはとんでもないことだ。
何事も極力「設計」と呼び、真剣に取り組みたいものである。
見積もりとは、「必ずしも見通しが立っていない未来を予測し、あたかも確定しているがごとく未来を表現しなければならない」という極めて創造的で、かつリスクの高い仕事である。それだけに、一流の設計者でなければできない仕事なのだ。まさに「見積もり能力こそ最高の設計能力である」といえる。
見積もりは注文を取るために行うものだが、注文が取れたときには、その注文の運命の大半を決めてしまう。見積もりは大事な基本中の基本設計と考え、見積もりと同時に基本設計をやっているという覚悟が必要だ。
プロジェクト管理においても、管理対象を数量化し客観的・定量的評価を基本にすべきである。ソフト開発のデバッグやテストの進捗については、チェック項目の消化やバグ検出の推移など、定量的評価が定着しているものの、設計の定量的進捗評価は難しい。しかし設計者の感覚的報告に頼らず、例えば設計仕様書の予定仕上がりページ数に対して、何ページまで記述できたかを評価するなど、クールに定量的進捗把握に努めるべきだ。
ただし、定量的評価だけに頼るのも問題だ。設計文書の中身をレビューし、質的評価も地道に実施しないと魂の入らない管理になってしまう。管理の要は、無理にでも数値化をする一方で、質的評価によって定量的評価の限界を補うことである。
また、数値を安易に個人評価に使うと、いつの間にか虚偽の報告が出る心配があることにも、注意が必要だ。
