システム開発を進める上で、やはりベンダーとの関係性は重要です。全てお任せではこちらの要望通りの物が出てくることはほぼないです。この本は、2008年とかなり古い本ですが、ベンダとの付き合い方の原則は変わらないと思うので改めて読んで勉強してみました。
進捗管理について特に印象深かったので、そこをピックアップして記しておきたいと思います。
進捗管理の前提
進捗計画を作成する必要があり、発注側として考えるべきは大きく２つ。
①いつシステムを使用したいのか。
②契約上の検収時期（どの年度の予算かもあるので）
この２つを必ずベンダに伝えて、各工程のレビュー実施について合意形成を図る事。
発注側がシステム計画を立てる必要がある工程
こちらも多く２つの領域がある。
①ベンダーに委託できない工程（受け入れテスト、ユーザ教育など）
受け入れテストは自社でやらないとテストの意味がないですし、ユーザ教育も社員にいつ習熟させるかスケジュール調整等が必要になり、発注側がリードする必要がある。
②レビュー（ベンダの提出物を確認する工程）
客観的に問題ないか判断するためにも、発注側で該当システムや業務に詳しい有識者のスケジュールを押さえて、十分に確かめるようにする必要がある。
進捗報告（実績もそうだが、予定より遅れているかどうかわかるようにすべき）
実際にシステム開発が進む際に進捗報告会があると思います。その際に、数値を使って報告してもらう事が大事だが、下記のような物では意味が薄い。
悪い一例）
●20XX年XX月XX日時点の進捗報告
ー機能仕様書作成：80%
ー画面定義書作成：65%
→これだと、個々のタスクがどれくらい進んでいるかは確かに報告されている。
しかし、知りたい事は【遅れているか、そうでないのか】なので、この報告では意味がない。
良い一例）
●20XX年XX月XX日時点の進捗報告
予定
ー機能仕様書作成：4機能
ー画面定義書作成：10画面
実績
ー機能仕様書作成：2機能(-2)
ー画面定義書作成：10画面(0)
→これなら、予定より遅れているかどうかがわかる。
なので、リカバリ策が必要なのか具体的な検討も可能となる。
詳細に進捗報告が必要な場合（粒度を細かくすればいい）
もしも、システムに直結する機能や特に重要な成果物なので細かく管理したい時があるかもしれない。そういう時は、報告するステータス粒度を細かくする。
例として、完成と仕掛かりと未着手の3段階から、間にレビュー中、設計中など5段階にすることでどのタスクがどのような進捗かがわかる。
※ただし、細かく把握して管理して何があるかは考える必要がある。信頼できるベンダだからこそ契約しているはずなので、無意味に管理稼働を増やしても意味はない事は注意する。
総数との比較（全体進捗の把握）
一つ一つのタスク進捗を管理する事に越したことはないが、発注側として真に見るべきはシステム開発の【全体】に遅れがないかである。
ベンダとしてみるなら、開発すべき機能の総数は常に念頭にあった上で、今どのくらいの数できるか、全体進捗把握も必要。
まとめ
全てお任せにする訳にもいかず、とか一つ一つに細かい粒度の報告を出してもらって指摘していくのもプロの邪魔をするだけになるため、バランスが難しいですね。
予定より遅れているかどうかを知るために、予定と実績のセットと開発総数と今の実績数で全体把握、この２つがまずまず重要ととらえて報告してもらうように依頼するのが無難ですかね。
勿論、それだけで十分なんですかと判断されて出し惜しみをくらうのもいやな所ですが・・・話し合いができないベンダと長期的に付き合うのも難しいので、そこは見極めのために、正直ベースで話を進めていきたいと思います。出し惜しみでもしっかりしたクオリティで納期通り納品いただけるベンダなら、それが一番ですしね。
