これをやると必ず失敗する！？ プロダクト開発時に避けたい地雷まとめ

いくつかの開発現場を経験してきて、見えたきたことがある。
それは、どうやら失敗には共通する地雷があるということだ。
成功要因を踏まえても必ずしも、次回成功が再現できるとは限らない。
もちろん、確度は上がるだろう。
ただ、状況も変われば、その成功要因が次も効いてくるわけではない。

プロダクト開発は地雷原を走り抜けるようなものだ。
そこかしこに埋まっている地雷を避けながらゴールに向かって進んでいく。

そして、時折踏んだ地雷が大きな痛手を残すこともある。
これは、生き延びるためのサバイバルマニュアルのようなものと思ってもらえるとありがたい。

なお、失敗の区分としては、ヒト・モノ・カネの三つにわけることとした。
無論、これがすべてではないし、他にもあるけれど、何かしらの役に立つと嬉しい。

モノにまつわるコト

■ターゲットのニーズの理解をしていない

自分たちのお客さんは誰で、何を欲しているのか？の解像度が低い場合、大抵失敗する。
というのも、必要以上な機能をつくってしまったり、欲している体験を提供できなかったりするからだ。
実際のお客さんをイメージでき、その人が欲するニーズを把握できているか？
すべてはここから始まる。

■優先度を理解していない

ターゲットのニーズ把握不足から、派生して発生するもの。
ニーズを理解しており、言語化できていれば、何に力を注ぎ、何を捨てるかが見えてくる。
ニーズを満たすものを優先、そうでないものは優先度を落とし、削る。
また、必要以上に開発のサイズを大きくしない、というのもポイントになってくる。

■商材を理解・分析していない

自分たちが作ろうとしているものの、類似商品を理解・分析していないパターン。
わからないものを、わかるように作れるはずがない。
サービスに触れるほど、解像度は上がる。
そして、それをチーム全体でやっていると、だんだんと共通言語ができてくる。
共通言語が少ないほど、コミュニケーションの難度が上がる。
共通言語があると、自分の考えていることを、他者の頭の中で再構築しやすくなる。

■開発プロセスの原理原則から外れる

一般的な開発プロセスは、時間の洗礼を受けていまのかたちとなっている。
一般的には、企画→設計→プロトタイプ→α→β→テスト→リリース。
そのプロセスを無視して開発を進めようとしても、やはりどこかしらで歪みが出てくる。
多くのプロジェクトが失敗した結果、このようなフェーズに区切る開発プロセスがあるのだから。

■QCDの優先度が途中で変わる

QCDとは、品質・コスト・スケジュールのそれぞれの頭文字をとったもの。
Quality、Cost、Deliveryを指す。
スケジュールが優先だったのに気がついたら品質を最優先する話にすり替わってしまっているケース。
ただ、よく考えればわかることではあるけれど、品質（=Quality）を落とすのは悪手になりがち。

たとえば、D(= delivery = スケジュール）を優先するのであれば、
・Q クオリティ（というよりは、つくるスコープ）をミニマムにする
・C コストを積んで早くつくる
などがある。ヒトもおカネも使えない場合、アプローチが限られるので、不味いことになる。

ヒトにまつわるコト

■本来、チームに必要な役割が不足している

本来あるべきチーム機能が不在・不全となっているパターン。
たとえば、プロデュースをしなくてはいけないのに、それをする人が不在であったり、
マーケティングを加味してプロダクト開発しないといけないのに、それが不在だったり、
特定の人に業務が集中しすぎて、その人が機能不全になってしまっていること。
もちろん、理想と現実は異なるのが世の常ではあるが、どこが不足しているか？を共通認識として持っておくことはとても重要。

■得意なスキルを発揮できない

上記と関連して、特にチームビルドができていない状態や、コンパクトなチームで起きやすい。
前者は、誰が何が得意なのかが形式化されておらず、
後者は、得意もそうだけれども、それよりも捌かなけれいけない業務が多く、領域を規定しているどころではない。
前者は特にチームメンバー・上長に対して、自分は何が得意で・何は不得意だからフォローアップ/他の人をつけることが必要か？を周知していくしかない。

■コミュニケーションの質と量が足りていない

コミュニケーションで発生する関係値は大きくは三つ。
上司、同僚、部下の三者。

特に上司との目線合わせができていないと、梯子が外され孤立することもある。
上司とあなたは、見えている景色が違う。
それは追っている責任の大きさも、持っている情報も、である。
まず、ここを理解しておく必要がある。
なので、細かく情報連携をして、脳内をつまびらかにするしかない。

同僚とも目線合わせをしていく必要がある。
特に、職種によって大事にすることが変わってくるので、ここをハンドリングする必要がある。

・プロジェクト責任者なら、それがなぜビジネス的にいいのかを知りたい
・デザイナーなら、画面仕様が欲しい
・エンジニアなら、機能仕様が欲しい

各職種からのオーダーに、応えることが必ずしも正ではない。
あくまで、プロジェクトを成功させるために、何が優先して取り組むべき問題なのか？を見極めるのが重要になる。

部下には、報告/連絡/相談を自分からさせる必要がある。
こちらから聞いていくと、甘え、一向に報告しなくなるからだ。
特に期日になってもアウトプットがでてこない場合に、こちらからいうのではなく、この仕組みを作ることがポイントになってくる。
・期日を設定する
・期日を守らせる
・自分から報告させる

おカネにまつわること

■バッファがない・途中で見直しがされない

一発でうまくいくことはほとんどない。
作っていく中で、作り直しは発生するし、作り始めてから初めて解像度は上がるし、こうした方がよりよくなる、というのも見えてくる。理想としては、25~30%くらいは持っておきたい（切実）

と、いくつかまとめてみた。
開発は、本当に難しい。
これらの失敗への嗅覚があるかどうか、というのが成功するための確度にもなっていくのだろう。