効率よりも正しくあるべき
理想、「効率よりも正しくあるべき」は理想である。
最速の開発、最高のコスパは 理想と真逆。
営業やマーケサイドから XX をやってほしいと言われ
その場で仕様を考え、ざっとインパクトを出した上で開発着手
おそらくこれは最速で、最もコスパの良い開発方法だろう。
小さな開発チームにおいて、このように開発が進むことが多くある
コスパのために犠牲にしていること
上記の開発手法はコスパが非常に高い。
無駄が一切なく、必要最低限の工数で理想的なプロダクトを最短で作れる。
コスパとのトレードオフは必ず存在する
何もかもが必要最低限なので考慮出来て居ない事は当然ある。
- 意思決定者の不在（営業と実装担当者2名で決めるので事業としての判断ではない）
- リスク、ハレーション、社内連携ミス
- インパクト考慮、KPI未策定、蓋然性検討
- 計測方法、撤退基準、改善プラン、今後の展望
正しさをどこまで求めるのか
チームとしてどこまで正しくあるべきなのかは明確に定義しなければならない。
【定義すべきもの】
- 用件定義をどこまで詰めるのか
- 用件定義の不足情報や詰め、リスク考慮をチームとして行う状態を作るか
- 施策の「やる、やらない」を誰が何時、どのように決めるのか
私のチームで一旦やってみようと思う流れ
- 用件定義は背景、作りたいもの、デザイン、計測方法、KPIをセットで。
- チーム全体で定義した要件を検討し、問題がないことを確認
- 施策の実施可否は開発、マーケ、営業のリーダー3人の合意で決定とする
エンジニアの怠慢では？
もちろん初めはセールスサイド、マーケサイドからなぜここまで細かく用件定義してあげないといけないんだ。
エンジニアの怠慢だと言われるかも知れない。
エンジニアが決めすぎ問題
今までエンジニアがよしなに全てを考えて確認して、開発をしすぎていたのだ。
エンジニアが営業、マーケ、カスタマーサポートの面で問題ないか一人一人に確認しに奔走し
エンジニアがやるやらないの判断をする
あまりにもリスクが高い、それは避けよう。