プロジェクトのアウトプットの品質を確保するには

on


ITのプジェクトで顧客が求めるdeliverableを届けるとしたら、大雑把に言えば、ドキュメントとプログラムに分けられるだろう。大雑把にね。で、準委任契約でも請負契約でも問題になるのがdeliverableの品質が悪いというクレーム。顧客と直接契約しているときより、サブコン(二次請け)のときの方がクレームが多いような気がするんだけれどどうだろう。


プロジェクトだからこそ、限られた時間の枠の中でdeliverableを拵えないといけないわけだけれど、プロジェクトに手を付けること自体がいろいろな制約の中ではじめることだと知ってはじめないといけないのに知ろうとせずに始めてしまう人もいる。
＃とっても不思議だ。


もっと○○があれば
プロジェクトのdeliverableは名前だけ決められていることが多いらしいけれど、−実際、自分達がそのdeliverableを作るのにその中身を決めもせず、知らずに見積もり仕様書を書いてレビューに臨む人が多いのは事実だ−、それで一体どうやって見積もったのかを教えて欲しいものだ。


確かに見積もり仕様書を書く時点で最終形のdeliverableの姿を予言することができないこともあるだろう。ならば、見積もり時点ではわからないからこうしましょう、とその見積もり仕様書を作ったときの前提を顧客と摺合せ、見積もり仕様書か契約書に織り込んでおくものだ。それがなければ、準委任だろうが、請負契約だろが終えようがないではないか。
＃厳密に言えば準委任契約は終了条件が書かれてれば契約を終えることはできるけれど。


見積もり時の前提、若しくは、プロジェクト計画時の前提を踏まえ、そして、顧客とのプロジェクトのキックオフでプロジェクトをどう運営するかを合意してこそ、顧客と同じテーブルに着いてプロジェクトをはじめて進められる。プロジェクトをボタンのかけ違いをしないようにはじめるために必要なことだ。


それら、プロジェクトをはじめる前の前提を整理するという準備という行為、こうやりますよという過ごし方を整えるという行為があってこそ、そのプロジェクトで顧客に届けるdeliverableもプロジェクトチームと顧客の間で明確になるものだ。


それをはじめにせず、プロジェクトの局面ごとのexitが差し迫ってからはじめても遅いのである。もうやってしまったことが顧客の想いと一致しているなんてことはないのだ。顧客自身がdeliverableの具体的なイメージ像なんてプロジェクトをはじめる前に持ち合わせているわけがない。もし、顧客が実現して欲しいdeliverableをイメージできるなら、それが仕様書であり、それを作ることを基本として契約すればいいのだ。しかし、それができないから、ぼんやりとした仕様とも呼べないレベルのものをもとに“前提を置いて”想像するのだ。


前提を置かず、局面のexit間近になってから調整を始めるから、もっと期限が先ならとか、もっと人的リソースがあればとか、予算が潤沢にあればとか言い始めるのだ。それでは遅すぎる。


手の内に何を持っているか
見積もりをするという行為は、プロジェクトをはじめるときのプロジェクトマネージャやチームメンバに武器を与えるということである。別に顧客と戦うわけではないし、どちらかと言うと顧客もユニゾンしてプロジェクトのdeliverableを作り上げるためのパーティを組むの方が良い方としては正しい。その見積もりに関わった人たちがそのままプロジェクトをキャリーすることは稀だろし、そうなら一層プロジェクトをキャリーするチームに武器を置いておきたいと思うものだが、これを読むあなたが見積もりをする側の人だとしたら、どうするのだろうか。もし、武器を出来る限り与えてあげようと思わなければ、あなたはとても優秀なのか、人が苦労することに何の躊躇いもしない人のどちらかだ。


見積もりとプロジェクトをキャリーする人が違うとき、見積もり仕様と前提は武器であり、それが顧客とプロジェクトをユニゾンするときの手の内の駒なのである。それがハッキリとしたもので、顧客とそれをもってユニゾンすることを話せる環境を作れるからこそ、ユニゾンが成立するのだ。


プロジェクトをキャリーする側は、その他に持ち合わせるのはエンジニアというリソースだけしかない。見積もり仕様や前提がなければ、プロジェクトをキャリーするチームにあるのは“人的リソース”だけでしかなく、何を作るかも何ら情報もなく、顧客と開始時に擦り合わなければ何を作るかわからないというダンジョンに投げ込まれた上に、スキルセットもわからないままパーティをはじめなければならないのだ。


はたしてそれでゴールにたどり着けると思いか。


何をどれだけ投入するかで結果が変わる
プロジェクトのdeliverableが何であるか、その仕様や前提には何を置いて顧客にdeliverableを届けるシナリオを練ったのか、そしてどうやって届けるか顧客とユニゾンの役割分担を明確にするからこそ、持ち合わせる手駒を最大限に使う準備ができるのである。


顧客のdeliverableのイメージが前提であっても把握しているなら、それほど顧客と揉めもせずにゴールにたどり着くことが出来るだろう。ゴールにたどり着くためには、常に顧客と今どこにいて、ゴールに仮置きしたdeliverableを局面ごとに少しずつはっきりさせていく経過の中で、手持ちの駒であるリソースをどう使えば最大限の効果を得られるか計るのだ。


リソースを最大限に活用し効果を得るということは、何かを取り、何かを捨てるという行為と言い換えることもできる。そういった行為をするときにdeliverableが何で、それを実現するために何を最優先とする評価の順位付けが必要だ。それも合わさってdeliverableが作られていくのである。


それを出来る環境を整えるからこそ、プロジェクトのアウトプットの品質を確保できるのである。