開発者との対話が頻繁に詰まって悩んであれば、本人の企画方法を点検してみるのがいい。
開発を学ぶのも良い方法ですが、開発を習うことによって、この問題がすぐに解決されない。開発者との会話の中で最も重要なのは論理的思考！企画書を作成するときはこの機能がなぜ必要であり、どのようなプロセスで動作して予想される問題点は何であり、どのように解決するかについて習慣的に考えなければならない。
企画者本人も理解していない企画書を渡してはならない。
下の6つのコースを習慣化すると、あえて開発を学ばなくてもより効果的なコミュニケーションができると考えている。
1.機能を追加しても明確な理由がなければならない。
始めたばかりの企画者や時間に追われて企画をしていると、他社サービスをむやみにコピーする場合がある。一見同じ機能であっても、現在開発中のサービスには、導入が不可能な場合が多い。
バックエンドのロジックが異なるからである。したがって、企画者は他のサービスをむやみにコピーしてはならない。ボタンを追加しても、このボタンがあってこその理由を提示しなければならない。そうしてこそ、自分の企画に自信が生じ質問を受けた際に明確な答えができる。本人の考えが不足したままむやみにコピーするプランナーは資格未達である。
2.複雑な企画であるほど、フローチャートを作成してみる。
フローチャート作成を難しく感じる企画が多い。
しかし、プロセスが複雑にすればするほど、必ずしもフローチャートを作成する必要がある。そうしてこそサービスの論理的な流れも整理できて、途中に発生する例外ケースをもれなく見つけられる。
フローチャートを作成する際に、あえて形式に縛られる必要はない。プランナーの考えを開発者がよく理解できるようにまとめれば良い。
3.予想される問題点と対応方針を作成する。
フローチャートを作成すると、通常のプロセスから抜け出した例外ケースが発見される。
既存のプロセスを少し変更して対応可能な場合もあるが、不可能な場合もある。その場合は別の政策で制約しなければならない。
たとえ、ファイル1つを登録する際には問題ないが、複数を登録する時にシステムロジックに問題が生じたとすると、政策的にファイルのアップロードは1つだけにするなどのルールを用意しなければならない。
4.プロトタイプを作ってみる。（推奨）
ほとんどの現場では、パワーポイントやエクセルで画面を設計するが、機会があれば、プロトタイプツールの利用をお勧めする。
プロトタイプは画面設計をすぐに駆動みることができるので、不足している要素をリアルタイムで検出でき、よりしっかりとした企画を作られる。また、開発者を含む業務関係者と話をするときも、企画意図を簡単に伝えられる。
個人的に、プロトタイプツールは Axureをおすすめする。
5.企画書を渡すときは、必ず口頭で説明する。
企画書を電子メール、メッセンジャー、業務システムなどに渡す場合には、いくら文書をよく作り、コメントを入念に記載しても企画意図を100％正確に伝達することは難しい。
したがって、企画書を伝達した後には必ず口頭で説明するのが良い。ベストは正式にレビューをすること、次にはプログラマを訪ねて直接説明すること、これも難しい場合は電話連絡を通っても説明すること。
レビューをする過程で、企画する際に考慮していなかった問題が発見でき、開発者との対話を通じて効果的な代替を見つけられる。
6. 開発者の意見に耳を傾けて聞く。
私が企画した通りに作り出せという一匹狼スタイルの企画者がいる。
しかし、これまでの経験を照らしてみると企画には正解がない。様々な分野の人々と考えや意見を共有して、その中で最も優れた選択肢を見つけることが企画者が持つべき基本的な素養である。企画は企画者の専有物ではない。
まとめると、
開発者と効果的に通信するために企画は、より論理的に企画して、開発者の批判的な意見も積極的に受け入れて、より良い企画案を作成するには姿勢が重要である。
最も効果的な方法は、開発者と懇意の間になるだろう。IT職群は、人と人との間にすることなので、お互いが信頼して友好関係を結んで後の業務処理がはるかに容易になる。
