まずはたたきを作って目線合わせをしよう

よく、たたきを作るのが大事などと言いますが、なんで大事なんだっけ、ということを考えました。

たたきとは

たとえば、新しい施策のために機能開発するとき、企画者はこのような機能が欲しいといったイメージが頭にある（orない）場合、それをメンバーに共有してもらう必要があります。
そこで必要になるのが、「たたき」です。

たたきのアウトプットイメージはケースバイケースで、テキスト箇条書きのページ1枚のときもあれば、ラフイメージを起こす場合もあります。たたきがあるだけで、イメージをチーム内で共有できるだけでなく、フィードバックをもらいよりブラッシュアップさせていくことができます。

逆にたたきがないと、どんなイメージを持っているのが伝わりにくく、的外れなフィードバックや議論が発散してしまったり、方向性が定まらなくなります。

おすすめのたたきの作り方

私がたたきを作るときは、議論に参加するメンバーのスキルセットや、時間、イメージの解像度によって変えています。ケース別でおすすめのたたきの作り方を紹介します。

企画が初出しの場合

企画自体がまだ誰の目にも触れられていない場合、まだまだ解像度が低くその企画自体の練度が低いため実行やるやら判断段階のことも多々あります。
この場合、たたきを作る時間をかけても捨てる可能性も大いにあるので、できるだけ簡素にします。例えば、1枚箇条書きでドキュメントを書く程度でも十分でしょう。またこの場合は、はじめから多くの人に見せても良いですが、上司や頼れるメンバー1~2人にみてもらいざっくばらんに話して方向性を確認しておく方が、メンバー拘束時間も少なく済むことが多いです。

企画実施決定・要件定義に入る段階

企画の実施自体は決定、具体どのような機能開発をするのか、要件定義に入っていくフェーズでは、図を書いたほうが目線合わせしやすくなります。詳細なシステムアーキテクチャはSWEに任せるとしても、その機能がどのようにユーザーに使われ、どのようにデータが動くのかのフローを整理できると良いでしょう。この場合私は、ユースケース図やシーケンス図を書いてます。もし時間がなかったり、まだ初期であれば、図の作成ツールを使って簡単なデータモデリングをする場合もあります。

さいごに

たたきを作ることは非常に重要です。一方、たたきには厳しいフィードバック・指摘が送られることも多々あります。たたきを作るレビュイーはその前提で、自分自身の攻撃ではないマインドをちゃんと持っておいた方が良いです。一方レビュワーも、たたきを作って提示してくれたこと自体が良いムーブなので指摘はする一方、対峙するのではなく一緒にものづくりをしているというマインドでコミュニケーションをとるほうが円滑なプロダクト開発につながると思います。