はじめに
事業部MVPを取った優秀な後輩から「まだまだ書けるよな?」的な圧を感じたので記事を書いたのですが、
今度は「もしかして、たった2つの記事でギブアップですか?」という新しい圧を感じたので、プレッシャーに負けずもう一記事書くことにしました。
"最短で作る" と "最速で届ける" の違いを考える
「なるはやでお願い!」って、どっちの意味なんでしょう?
「なるはやでお願い!」
この言葉、割と聞きますよね。
でも、その"早さ"がどこを指しているかって、人によって結構バラバラじゃないですか?
- 最短で 作る ことを求めているのか?
- 最速で ユーザーに届ける ことを求めているのか?
似ているようで、実はまったく違う話なんですよね。
このあたりがあやふやなまま進んじゃうと、"最速で、誰にも届かないもの" ができあがってしまうかもしれません。
だからこそ、どこに向かってるか、できるだけ早めに認識を揃えておきたいなって思うんです。
1. "最短で作る"ってどういうこと?
"最短で作る"っていうのは、要するに開発の工数を最小限にして素早く形にすることですよね。
- 複雑な仕様をちょっと後回しにして、まずは最低限で動く形にする
- 既存のパーツを流用して、それっぽい動きを実現する
- UIやエラー対応は仮置きでも、とにかく動くものを出す
こういうアプローチ、効くときは効きますよね。
特に開発工数がネックになってる場合は、最短で作るのが正解な場面もあったりします。
でも、開発以外の部分に課題があるときは、このアプローチだけでは足りないこともありますよね。
2. "最速で届ける"ってハードル高くないですか?
"最速で届ける"ってなると、開発以外のプロセスも全部含めた話 になってきますよね。
たとえば
- 社内のステークホルダーにお披露目したら全然違う意見が出てきちゃう
- 営業体制が整っていなくて、リリース周知などのお客様のフォローができない
- サイレントリリースができなくて、サイト閉塞の調整が難航する
こういうの、よくあるんじゃないでしょうか。
つまり、 「最短で作る」だけじゃ"早く届けられない" ことも多いんですよね。
むしろ、作ったはいいけど止まってる...みたいな状態、経験したことある人も多いんじゃないかなと思います。
3. 「言われたとおり最短で作ったのに...」の裏にあるズレ
だれか:「なるはやでお願い!」
開発チーム:「OK、最低限だけど一旦最短で作ったぜ!」
──はい、すれ違い発生です。
- 「触ってみたけど、これ思ってたレベルじゃないんだよね・・・」
- 「お客様に案内するから、とりあえずリリースは待ってて!」
こういうすれ違い、わりとありがちですよね。
でもこれって、
"どっちの早さを求めているのか"をちゃんとすり合わせられていなかっただけ
だったりします。
なんだったら、
出来上がる前にスケジュール感の共有すらできていない 感じになっちゃってます。
同じ「早く」の中にも、「作る早さ」と「届ける早さ」があるんですよね。
「今回の大切にしたい早さって、どっちを指してるんだっけ?」
っていう認識を事前に共有できていたら、こういうすれ違いって防げると思うんですよね。
4. "早さ"の認識を揃えるためにできることって?
じゃあ、どうすればいいのかって話なんですが、対話による認識共有に尽きると思うんですよね。
1. 最初に「今回の早さ」は何の早さかを確認する
「とりあえずPoCなので最小の開発工数で動くものを作る」
「今月中にリリースしたいので、各チームそれぞれ逆算して進める」
みたいに、どっちの"早さ"が求められてるのか、言葉にしてみるだけでも全然違います。
2. 作る(Build)と 届ける(Delivery)をちゃんと分けて話す
作る(Build)と 届ける(Delivery)を整理してみましょう。
| 観点 | 作る(Build) | 届ける(Delivery) |
|---|---|---|
| フェーズ | 実装・開発 | リリース・顧客告知・運用整備 |
| 主要な課題 | 工数・技術的制約 | 承認・顧客調整・サポート体制の確保 |
| 優先される視点 | 開発チーム内部の効率・速度 | リリースから活用・定着までの速度 |
チーム内で「今どこに時間がかかってるのか?」「どの部分を短縮したいのか?」って会話をするだけでも、だいぶ見え方が変わると思うんですよね。
- 開発工数を最小限に抑えたいから、最速で作ることを優先するのか
- 開発工数には余裕があるけど、ユーザーが喫緊の課題を抱えているから、
それを早く正確に解決するために届けることを優先するのか
もし、こんな認識合わせが着手前に行われていたら、動き方も変わると思うんですよ。
作る(Build)という内部のスピードを上げたいのか
届ける(Delivery)という外部のスピードを上げたいのか
認識を合わせたい部分ですよね。
3. 「これはどっちの話?」って一言添える文化を作る
「いま話してるポイントって、作る(Build)スピードのこと?それとも届ける(Delivery)スピードのこと?」みたいな、
ちょっとした一言がズレを防いでくれるんですよね。
スピードの話に限ったことではないですが、
会話の前提を揃えてから議論するって
結構忘れちゃう人多いですよね。(私も気をつけたい・・・)
おわりに:「"なるはやで!"の裏側にある想い」
「なるはやで!」って、ちょっと焦った声に聞こえるかもしれません。
でも、その裏には
「なるべく開発工数を少なくしていこう!」
とか
「ユーザーの課題を早く解決したいよね!」っていう、
誰かの、優しさとか、熱量とか、想い があるんじゃないかなって思うんです。
だからこそ、単に"早く作る"だけじゃなくて、
"早く届ける"ことも含めて、
同じ目標を目指しながら一緒に歩んで行きたい ですよね。
そのためにできるのが、
「今回はどっちの"早さ"を目指してるんだっけ?」って、早めに声をかけあうことじゃないかな〜って思っています。