プロジェクト計画書はモノと情報の流れを書こう

「プロジェクトを成功させるために何をすればいいですか」

と聞かれるたびに「プロジェクト計画書を書き続ければいいのに」と思うのだけれど、そう答えると釈然としないお顔になるエンジニアが多いから言わないのだけれど。

でもですね、なぜプロジェクト計画書を書き続ける必要があるかがわかってるエンジニアなら、黙ってプロジェクト計画書に必要なアイテムは用意しているものなんですよ。

一つ足らないもの

Q　プロジェクト計画書は何が書かれているかを述べなさい。

さて、どう答えるかしら。パッと出てきた答えがそのエンジニアにとって日頃から考えている大事な価値の一つでだと思うのですけど。

エンジニアがプロジェクトマネージャにアサインされて、幸いにもプロジェクト計画書のテンプレートがあって、あったらあったで書かされて作ったプロジェクト計画書に足らないものが一つ生まれてしまうのです。

プロジェクト計画書に書くコンテンツとは

幸いにもテンプレートがあって書かなければならないプロジェクト計画書のコンテンツには何があるでしょうか。

チャーター？進捗管理？品質管理？WBS…えーっとそれからそれからたくさん。

そうなんですよね、下手にテンプレートがあると書かなければならない（と思ってしまう）フォーマットが用意されているのでうんざりするんですよね。

これだけ書かないといけないのか。

ここに存在するのはプロジェクト計画書ウゼーだし、プロジェクトマネージャやってられない、です。じゃあいいやいちエンジニアで、と。

どうして何種類ものフォーマットがあるのでしょうね。とそうした書かなければならないという視線、観点でプロジェクト計画書のフォーマットをみてしまうこと自体が実は間違っていることに気づかなければなりません。

プロジェクト計画書はあることを表現する手段としてあるのであって、プロジェクト計画書のフォーマットを埋めることがお仕事ではありません。

プロジェクト計画書に書くのは、プロジェクトを完了させるための価値を書くのです。

モノと情報の流れ

プロジェクト計画を完了させるための価値とはなんでしょうか。

プロジェクトとは顧客が実現したい業務課題をシステムで実現する業務活動です。業務課題に価値を添加して顧客が手に入れたい解決手段を提供するのです。

インプットが課題、アウトプットは業務課題の解決手段。間のプロセスに必要なものは、インプットの課題にまつわるモノと情報を価値により変換する手続きです。

プロジェクト計画書に書かれるのは、プロジェクトのモノと情報の流れを書くのです。

[resources]　　→　　[procedure]　　→　　[deliverables]
各種資源　　　　　モノと情報の流れ　　　アウトプット

書かされ感の根源

 プロジェクト計画書を書く際に書かされ感を１ミリでも感じているなら、それに足らないものはプロジェクトをどうしたいのか、それも具体的に運営するためのイメージ像を持っていないからです。

プロジェクトマネージャとして実現したいことが

「プロジェクトの成功」

 では絶対に実現することはできません。

必要なことは、どのようにして理想のプロジェクトを実現するかというプロジェクト運営の考え方、念持のようなものです。

将来を実現するための構想

残業をしないくらいスマートに、効率的に、かもしれませんし、致命的なバグを出さないための活動を伴った運営かもしれません。

いづれにしても、必要なのはプロジェクトマネージャを担うエンジニア自身がプロジェクトをどうしたいか、というプロジェクトの将来の構想です。

それがプロジェクト計画書のフォーマットを使って表現するのだと認識した時点が、プロジェクト計画書はやっと一つの道具として扱うアイテムになるので書かされ感から解放される瞬間となるのです。