■プロジェクトをアセスメントする （No.143）
プロジェクトを計画した段階で，そのプロジェクトが成功裡に終えることができるかどうか，アセスメントする機会があり，今回はこのことを話題に取り上げる。
通常一般に，プロジェクトのスタートは，プロジェクトリーダが企画した内容を，決裁権を持った幹部（或いは社長）を交えて，企画会議とか開発会議とか，呼び名は会社によって違うがプロジェクトをスタートして良いかどうかの決裁を得ることによって始まる。
この会議では，プロジェクトリーダが企画内容を説明する。プロジェクトなので，ＱＣＤはもちろん，製品開発であれば，投資内容，製造工程，商品の目標価格，原材料費，利益などの見積もり内容を発表し，審議される。それらの内容に関して，職場を代表する経験者がいろいろな角度から質問を投げかけ，プロジェクトリーダが見逃している重要なポイントなどがあらわにされ，プロジェクトの概要が明確になり，最後に決裁者がプロジェクトのスタートを承認，否認，場合によっては条件付きで承認されることもある。
ここでは，こうした通常一般の承認の前段階，場合によっては，承認後の詰めと云うような形で，プロジェクトが上手く行くかどうかを開発の当事者ではない第三者としてアセスメントすることについて取り上げる。
このアセスメントの目的は，プロジェクトの企画や計画段階で，その計画が妥当なものかどうか，やってみなければ判らない，と云うのでは困る。もちろん，プロジェクトなので進める過程でいろいろなことが起こる可能性があるが，それらを上手く乗り越えて計画した通りのことが首尾よくできることが最大の栄冠である。この最大の栄冠を無事勝ち得ることができるかどうかを，計画段階でアセスメントしようとするものである。アセスメント者は，プロジェクトの内容をある程度把握した者がその任に当たる。アセスメントする内容は，プロジェクトなので，スコープ，ＱＣＤが基本になる。
スコープ
当該プロジェクトが計画している範囲，内容（製品であれば，搭載機能，目指す性能など）を明確になっているかを確認する。プロジェクトなので，状況の変化により，スコープが追加になったり，削除されたりすることが起こる。これによって，後述のＱＣＤが影響されることになる。したがって，計画段階でのスコープをきっちりさせておくことが大切である。プロジェクトによっては，スコープでも不確定要素を含んでいることもある。これについても，計画段階で明確にし，いつまでに確定させる予定かも決めておくと良い。そうしないと，この不確定要素が残ると，ズルズル引っぱられるリスクが高いことになる。
品質（Ｑ）
これは目指す性能の品質としてどのようなものが求められているかを明確にしていることが前提となる。この目標品質を確保するために，開発の各工程においてどのような品質確保を目指しているかを評価する。即ち，最後になってからしか品質が判らない，と云うのではなく，各工程でどのような品質の作り込みがなされるのか，しかも，それらが定量値化されたものであると，予測値と実績値が比較できて品質目標レベルの確認ができる。しかも，その予測値はエイヤーで決めたものではなく，ある論理性を持ったものでなければならない。もちろん，前のプロジェクトからの実績値から推測するのもよい。この目標値の妥当性をアセスメントする。
また，品質確保のためには，各工程の評価内容が十分かどうか，評価に当たる工数確保，評価環境が十分かどうか，など品質評価が確実にできるか否かについてもアセスメントする。
コスト（Ｃ）
掛かる費用についてのアセスメントで，先ず，一番大きいのはリソースであり，何人月のプロジェクトに相当するかの見積もりである。この場合，全く初めてのタスクはなかなか予測が難しいが，大抵のタスクはこれまでの経験値からはじき出すことができる。一般的にはＷＢＳ（Work Breakdown Structure）によって，タスクに詳細が決まり，それにどれだけのリソースが必要かを割り出して導き出される。しかし，詳細なＷＢＳを出すまでに，プロジェクトのスタートの決裁を仰ぐことも多く，詳細なＷＢＳの前の，各工程の仕事量を想定した概算見積もりでＧＯが掛かるケースも良くあることである。つまり，この段階でリソース確保が決定されるので，概算見積もりといえども，精度を要求されることがある。
詳細な見積もりはＷＢＳ化されたタスクからリソース計算がなされるので，ＷＢＳが大きく変わらない限りコストが変動することはない。変動する一番の要素は，不確定要素がどのくらいあるかである。この不確定要素に対するリソースは明確にして，随時明確になった時点で見直しするのがよい。また，プロジェクトリーダや見積もりするメンバーの経験の違いで，ＷＢＳが漏れていたり，ＷＢＳの個別の見積もりが狂っていた場合は，コストに大きな影響を与えることもあるので，第三者がその箇所を見つけることは難しいことであるが，ヒヤリングなどで自信の度合いを聞き出すなど方法はいろいろある。もちろん，見積もりした工数分のリソース確保がされているか，バッファーとしてどれほど見ているかもアセスメント対象である。
また，プロジェクトは通常同じことを繰り返すようではプロジェクトとは言えないこともあって，経験値があってもそれにどれだけ改善を加えて見積もっているか，またその部分を計画内にどれだけコミットメントしようとしているかなども考慮しないと，開発側の挑戦度合いがあまり大きくて実現性が困難でないかどうかも見極めが必要である。これらの挑戦度合いはリーダの資質などにも大きく左右される。
納期（Ｄ）
プロジェクトは一過性のものであるから，必ず完了があり，この目標完了日までに確実にプロジェクトを終えることが可能かどうかをアセスメントする。このためには，いきなり最終完了日がどうか，を見るのではなく，各プロジェクトには必ず，重要なマイルストーンが設定される。そのマイルストーン（中間目標値）に対する各工程に必要な工数と確保リソースが十分かどうかを先ず確認する。
もちろん，ＷＢＳがきっちりできているかどうかもアセスメント対象である。ＷＢＳが不十分である場合は，不確定要素が残っているか，或いはリソース不足でＷＢＳとして計画に落とし込めないなど，納期に不安を与える要素が含まれている可能性が高い。
製品開発などで，一番難しいのは，量の部分ではなく質の部分の見極めである。つまり，設計量では大きな狂いは生じないが，技術難易度が高い場合，質的な問題でスキル不足で計画通りの進捗ができないケースがある。不確定要素の大きな開発案件では特に，この見極めが難しい。こうした場合には，必ずマイルストーンの中に，チェックポイントを設け，不確定要素の高い技術内容の進展を確認するポイントを設けることが必要で，これを怠ると，この部分がクリティカル・パスとなり，プロジェクト全体のスケジュールを大きく狂わせる結果となる場合が起こる。
以上の項目についてのアセスメントは通常一般には，会社によってマニュアルのようなものが出来上がっていて，各々の項目に関して判定基準の目安も決まっている。従って，必要なデータが正確に把握さえできれば，大きな間違いを犯すような判定間違いは起こらない。しかし，一番重要なプロジェクトが計画通り成功裡に終えることができるかどうかは，実際のプロジェクトに関わる人の要素もあり，或いは環境変化の読みをどのように見るか，或いはリスクの予測とその対応能力をどのように見るかによっても違ってくるので，そうした点はある程度経験を積んだ者でないと，判定は難しい。
こうした判定も事例の積み重ねと，データの蓄積が重要で，これらを繰り返し，繰り返し行うことで，アセスメントの精度が向上し，判定の狂いが少なくなることは間違いない。単なる経験と勘だけで判断しているケースと比較すれば，確実に経営的な成果でみても違ってくると思われる。これは，プロジェクトを実際行う開発者にとっても，こうした第三者のアセスメントが早い，企画段階で受けられることは，プロジェクトを進める上での重要ポイントを押さえることが可能となり，プロジェクトを進める自信にもつながる。
プロジェクトのアセスメント評価を導入しよう
企画段階で正確なアセスメントができることは，プロジェクト推進の大きな力となる
[Reported by H.Nishimura 2009.11.09]
Copyright (C)2009 Hitoshi Nishimura
