提案書を読んで鍛えるプロマネスキル

つくづく提案資料を作る作業に関わったりレビューをしたりしていると、あたかも自分がその提案しているプロジェクトマネジメントをしているような気分でドキュメントを扱っていることに気付くんですよ。

提案ごとに顧客も実現するシステムも違いますね。提案書ですから顧客が実現したい要件、それを実現するシステム仕様、アウトプット、工程定義、SOW、コミュニケーション計画、スケジュール、マイルストーン、前提条件、制約条件、費用が整然と並べられているわけです。

提案書ですからね、具体的なツールやテクニック何かは書きませんし、書いてしまうとプロジェクト計画書になってしまいますからね。提案書ですから顧客の課題を解決することがわかることを書かなければなりませんから。プロジェクト計画書はもっとさきですよね。

でも、提案書を作ったり、レビューアとして読む提案書からプロジェクトは始まっている、と思うんです。もちろん、提案が採用されて、注文書を受け取ってはじめてプロジェクトになるんですけどね。

だって、提案書に書かれていることが後々の足枷にも、プロジェクトチームを助けることにもなるんですから。だから、提案書を手を抜いて書いてあったり、ろくすっぽ考えもせずに書かれていると腹が立つどころか呆れてしまうんですよ。その提案書は誰のために書いているのか、って。

もちろん、プロジェクトチームのためでもあるけれど、顧客の課題解決のため、ですよ。当たり前のことをだと思うでしょ？当たり前のことをなんで書くんでしょうかね。そりゃ、中途半端にしか考えていなくて書いている人が少なからずいるからです。

もうちょっと考えて提案書を書いて欲しいです、書く人は。

提案書を書くエンジニアはよくよく考えて欲しいです。提案だけする役割の人もいるでしょうけど、自分がプロジェクトをキャリーするつもり、いや、腹を決めて書いて欲しい。あとは、アサインされたチームがやるんだから、とそうした他人任せで書いてある提案書を見ると速攻でリジェクトしたくなる。なんともせつない。

あー、そうじゃなくて、提案書を書くことがどれだけプロジェクトマネジメントについて考えることが出来るか、っていう話でした。

でも、提案書を書く機会ってそうそうないものですか世間ではどうなんでしょう。一番いいのは提案書を書く、という行為そのものなんですが全く書く機会がないと諦める必要もないです。

もし、提案書を閲覧できるなら、書くほどではないけれど書かれた提案書を読んで何を解決しようとしてどんなシステムを提案しているか、そのシステムはどのようにして現実のものとして作り上げようとしているか、そうしたことを考えながら読むだけでも学べることをは多いです。

そして、提案書は大体において、プロジェクトマネジメントの観点で読むとこれどうするの？、っていうトラップが仕込まれていることに気付くようになります。期間的なものであったり、余りにも曖昧な仕様であったり。

提案書を読んでプロジェクトマネジメントを考えることは、現実的なプロジェクトマネジメントについて語っていない分だけ自分ならどうしようかと考える裁量の余地があるのでその余地の分だけ発想が読み手の経験に基づきつつも自由度を持っていることに気付くかもしれません。いや、逆に自分の経験の範囲でしかどのようにプロジェクトをキャリーするかを考えられないから却って躓くかもしれれないですね。

その躓きのなぜを自分でもっと考えてみたり、周りに訊いてみたりして、知らなかったことの考え方を教えてもらったり、そうしたことこそが提案書を後から読んで学べることもある、と一度騙されて試してほしいです。で、一度騙されたんですがら、あと2回でも3回でも騙されてください。そのうち、いいことありますから。