プロジェクトあるある（１１０）

本日のプロジェクトあるある：

お客様との打ち合わせ頻度を間違えるとプロジェクトがまわらなくなる

お客様とのミーティングを行う目的はいくつかあります。

①意思決定を行う（決める）
②様々な議論を行う。ブレーンストーミング（広げる、深める）
③定期的に報告・周知する（伝える）

お客様からヒアリングするなど「確認する」という目的も考えられますが、これは上記すべてに要素として包含していると考えられます。

プロジェクトでは、①から③のどのタイプのミーティングも必要になってきます。

そんな中、①と②については結構重要で、要件定義や設計のフェーズでお客様と活発に行うことになります。

例えば要件定義や設計検討。

プロジェクト期間があまりないとき、とにかく決めなきゃいけないことがたくさんあるので、ミーティングを無理やり詰め込んで消化しておこうとするような場合があります。

ただ、あまりにも詰め込み過ぎると自分達が泣きをみることがあります。

ある金関系の会社の新電話システムの基本設計プロジェクトにエンジニアとして参加したときの経験です。

このプロジェクトでのスコープは、お客様の要件定義書を作成し、それを元に基本設計書を作成するというものです。

この基本設計書が、、、なんと500ページを超えるという大作でした。そのうちたぶん400ページ以上は私が書いたんじゃないかな。

内容もすごく細かくて、もはや基本設計というか詳細設計じゃね？と思えるような内容でした。

ただ、設計書そのものにそれなりのお金をいただいていたので、あまりペラペラなものを出すわけにはいかないという事情もありました。

要件定義はそれなりに進み、一応予定どおり完成しました。

問題は基本設計書のほうでした。

設計検討を全部で10回（だったかな？）実施しますが、プロジェクト期間が短いので毎週火曜と木曜にお客様とのミーティングがセットされました。

これがなかなかの地獄の始まりでした。

火曜日のミーティングで設計検討を行い、そこで重い宿題が出ました。すると、次の木曜にはその回答の準備と、本来木曜に行う予定の検討資料の両方を作成する必要がでてしまいました。

結構毎回思い宿題がでてきたため、早い段階でオーバーフロー状態となってしまったのです。

そして、設計書もワードできっちりとした書き物として作成していきますが、これがまたたいへんでした。

雑音なく集中して物を書けるのは土日しかありませんでした。なので、毎週土日にドキュメントを執筆するという感じでした。

ドキュメントレビューも引き続き週2で行われていきました。これも短期間で行われたので、本当にしんどかったなぁ。。

この時のプロジェクトマネージャさんは、今でも私にとっての戦友です。（少なくとも私はそう思ってます。）

そして自分がプロジェクトマネージャーをやることになってから、あのころいっぱいわがまま言って申し訳なかったなぁ、と思います。

あの限られた期間でやるしかなかったので本当に大変だったと思います。

その経験をふまえて。

短期間で消化するためにお客様とのミーティングをつめこんでも、結局自分の首がしまってしまうことがあります。

そこはよくよく考えてやらないといけない、と思った次第です。

それではまた！

日々感謝 m(_ _)m