こんにちは、poipoiです。

「テクニカルディレクター目線のプロジェクトマネージメント手法」
を考えてみる記事。

今回は、すべてのドキュメントはコミュニケーションのために書くんだよね。というお話。

プロジェクト進行とドキュメント

プロジェクトを進行していくと色々なドキュメントを作らなければなりません。

見積書、システム構成、機材構成、部材リスト、画面遷移図、通信仕様、納品書、請求書・・・etc.

これらをただの「提出しなければいけない書類」と考えて、漠然と書いてしまうのはもったいないなと思っています。

私は一応テクニカルディレクターという「テクノロジーを軸に企画を実現する」という仕事をやっているので、ドキュメントひとつとっても「企画を実現する」ために利用しています。

そもそも、なぜこういったドキュメントってわざわざ書かなければいけないんでしょう。
それは、発注側と受注側の双方で、内容を揉んだり、「これで決定ね」っていう決め事にするために書くわけです。

つまりそれって、コミュニケーションをするための媒介（ツール）としてドキュメントを書いているということなんです。

なので、コミュニケーションツールとしてドキュメントを使うという意識をするとプロジェクトの進行にとても便利に活用することができます。

見積もりを依頼する理由

例えば、見積もりをすることを例にとって考えてみます。
通常、見積もりを提出するタイミングは

・まず引き合いをいただく。
・ざっくりとした内容のヒアリングをする。
・ざっくりとした項目分けをする。必要に応じてクライアントに詳細を確認する。
・詳細を詰めて完成。提出する。←ココ

という事が多いかと思いますが、個人的にはこれだとタイミングが遅いと思っています。

順を追って説明していきましょう。
まず前提として、発注側が最終的に知りたいことは何かというと、結局のところ「費用対効果」なわけです。

この企画に〇〇円を使うと、結果として〇〇円の効果が出るだろう。

という算段をつけたいわけです。

仮に発注サイドがある程度企画の方向性を自社で定めているとします。
この場合施策のイメージはあるため、効果の部分はある程度自社内で予測できます。しかし、そこにかかる費用に関しては制作側（受注側）でしか勘案できません。
こういう状態だから、見積もりを依頼するわけです。

そしてさらに、その見積もりが予想していた額を上回る場合、企画を別案に変更したり、内容を調整して実現可能な範囲におさめたりしなければならないわけです。

そう考えると見積もりにも段階的なニーズがあるはずで、例えば

相談初期：
予算にハマらない場合企画内容を大幅に変更する必要があるため、ものすごくざっくりでいいから早く費用感を知りたい。

相談中期：
企画の方向性は固まったがもう少し詳細をブレイクダウンしていき、個別に費用がかさみそうな箇所を別アイディアで補えないか検討したりしたい。

相談後期：
詳細まで内容を詰めて実際に支払いが必要な金額を握りたい。

というような段階分けになるわけです。
そして、各段階のニーズに合わせて見積もりを出す必要があるわけです。

見積もりでのコミュニケーション実例

ひとくちに見積もりといっても、軽い共有からしっかりと書面で作成するものまで多岐にわたります。
したがって前述した各フェーズでそれらを使い分けることによって、コミュニケーションをとりプロジェクトを進行していきます。

下記に私が普段の仕事で行っている方法を実例として紹介します。

相談初期：口頭で伝える
まず初回打ち合わせで内容をヒアリングした際にその場で
「雑感ですが多分〇〇円くらいかかるんじゃないかと思います。」
と口頭で伝えてしまう事がほとんどです。
（もちろん、あくまで雑感で実際の費用感は詳細詰めていくと変動しますよ、という念押しはします。）

初期のタイミングでざっくりとした費用感が判明するので、発注側は自分たちが想定している費用対効果を出せそうかすぐに判断できます。

そこでそもそも費用対効果的に企画が成立しないとなれば、発注側で企画を再検討することになりますし、もしある程度金額がハマりそうであれば話が次の段階にすぐ進みます。
つまりどちらにせよ進退がすぐにはっきるするので、発注側にとってもこちら側にとってもスムーズで無駄がありません。

もちろん、先方の予算以上に費用がかかりそうな場合でも、費用を抑える、もしくは同様の費用で効果があがる代案があればその場でお伝えします。

相談中期：箇条書き程度の見積もりを出す（複数回）
初回打ち合わせから数日以内に、もう少し詳細に項目を分けた費用感を箇条書き程度でお送りします。
（もちろんこちらも正式見積もりではないので費用感は変動はします、という念押しは添えます。）

これはどんな開発作業やどんな機材が必要で、それぞれにどのくらい費用がかかりそうかというイメージを掴んでもらうためのものです。

また各項目に対して、技術的な実現可能性もコメントとして加えておきます。
（この項目は実現可能。こちらは要検証。など。）

これを元に次の打ち合わせをセッティングし、内容のすり合わせや各項目についてピポッドの可能性などを探ったりします。

これを何度か繰り返しながら、並行してシステム構成や機材構成なども起こしていき企画詳細を詰めていきます。

相談後期：決定版の見積書を書面で提出
相談中期の詳細詰めを繰り返し、ある程度内容が詰まった段階で正式に見積書をつくり提出します。

この段階までくると、ほぼ開発するモノや必要な機材が洗い出せているはずなのでそれを元に詳細な金額を割り出します。

ここでの目的は最終的な金額の握りをするためのものなので、これ以降は金額の変更が難しいと考えてしっかり算出します。

ドキュメントでコミュニケーションすることで効率をあげる

こんな形で１回こっきりで見積書を書くのではなく、何度もコミュニケーションを重ねていくことによって、見積書というドキュメントを通じて企画自体の骨子を固めていきます。
見積もりが必要だから書く、ではなく見積もりを使って企画を詳細化していくというイメージです。

こうすることにより

発注側：
だいぶ時間がかかって返ってきた詳細見積もりが全然予算にはまらない、でももうだいぶ時間をつかってしまったので別案に変更する余裕もない。のような最悪の事態を回避することができる。

受注側：
工数をかけて見積もりをしたのに受注に至らない。結局労働力をロスしてしまった。というような事態を回避することができる。

というように、ミスコミュニケーションを避けどちらにとっても効率よくプロジェクトを進行することができるようになります。

今回は見積書だけにフォーカスして実例を挙げましたが、プロジェクトに関わるあらゆるドキュメントについても同様です。
すべてのドキュメントは企画を実施に向けて推し進めるためのコミュニケーションツールとして捉え、バンバンリライトしながらコミュニケーションしていくことをお勧めします。

そして、それだけバンバンとリライトするには、使い勝手の良い、使っていてストレスにならないツールを用いるのも重要です。
（以前にも、ツールは軽快さで選ぶべき、という記事を書きました）

例えばシステム構成図や機器構成図などを作る際、私は Whimsical というツールをつかっています。
シンプルで過不足ない機能ながら使い勝手がよく、簡単にそれなりの図が書け、また共同編集もできるため非常に重宝しています。

という事で、ドキュメントはコミュニケーションツールである、という話でした。
今回はこのへんで。