“最短で作る” と “最速で届ける” の違いを考える

# はじめに
事業部MVPを取った優秀な後輩から「まだまだ書けるよな？」的な圧を感じたので[記事を書いた](https://qiita.com/pilot_fish/items/a624cde0a401e8f6d83c)のですが、
今度は「もしかして、たった２つの記事でギブアップですか？」という新しい圧を感じたので、プレッシャーに負けずもう一記事書くことにしました。

# “最短で作る” と “最速で届ける” の違いを考える

## 「なるはやでお願い！」って、どっちの意味なんでしょう？

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/394384/8e9d00a3-9fe9-4cc3-9da3-635a7c0345c5.png" width=50%>


**「なるはやでお願い！」**

この言葉、割と聞きますよね。  
でも、その“早さ”がどこを指しているかって、人によって結構バラバラじゃないですか？

- 最短で **作る** ことを求めているのか？  
- 最速で **ユーザーに届ける** ことを求めているのか？

似ているようで、実はまったく違う話なんですよね。

このあたりがあやふやなまま進んじゃうと、**"最速で、誰にも届かないもの"** ができあがってしまうかもしれません。

だからこそ、**どこに向かってるか、できるだけ早めに認識を揃えておきたいな**って思うんです。

---

## 1. “最短で作る”ってどういうこと？

“最短で作る”っていうのは、要するに**開発の工数を最小限にして素早く形にすること**ですよね。

- 複雑な仕様をちょっと後回しにして、まずは最低限で動く形にする  
- 既存のパーツを流用して、それっぽい動きを実現する  
- UIやエラー対応は仮置きでも、とにかく動くものを出す

こういうアプローチ、効くときは効きますよね。
特に開発工数がネックになってる場合は、最短で作るのが正解な場面もあったりします。

でも、開発以外の部分に課題があるときは、このアプローチだけでは足りないこともありますよね。

---

## 2. “最速で届ける”ってハードル高くないですか？

“最速で届ける”ってなると、**開発以外のプロセスも全部含めた話** になってきますよね。

たとえば

- 社内のステークホルダーにお披露目したら全然違う意見が出てきちゃう
- 営業体制が整っていなくて、リリース周知などのお客様のフォローができない
- サイレントリリースができなくて、サイト閉塞の調整が難航する

こういうの、よくあるんじゃないでしょうか。

つまり、 **「最短で作る」だけじゃ“早く届けられない”** ことも多いんですよね。  
むしろ、作ったはいいけど止まってる…みたいな状態、経験したことある人も多いんじゃないかなと思います。

---

## 3. 「言われたとおり最短で作ったのに…」の裏にあるズレ

**だれか：「なるはやでお願い！」**
**開発チーム：「OK、最低限だけど一旦最短で作ったぜ！」**

──はい、すれ違い発生です。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/394384/aabc2687-f7bf-4f23-90d4-31e7a9d59b6e.png" width=50%>


- 「触ってみたけど、これ思ってたレベルじゃないんだよね・・・」
- 「お客様に案内するから、とりあえずリリースは待ってて！」

こういうすれ違い、わりとありがちですよね。

でもこれって、
**“どっちの早さを求めているのか”をちゃんとすり合わせられていなかっただけ** 
だったりします。

なんだったら、
**出来上がる前にスケジュール感の共有すらできていない** 感じになっちゃってます。

同じ「早く」の中にも、「作る早さ」と「届ける早さ」があるんですよね。
**「今回の大切にしたい早さって、どっちを指してるんだっけ？」**
っていう認識を事前に共有できていたら、こういうすれ違いって防げると思うんですよね。

---

## 4. “早さ”の認識を揃えるためにできることって？

じゃあ、どうすればいいのかって話なんですが、対話による認識共有に尽きると思うんですよね。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/394384/487150da-199f-40bd-a9e2-1ee799c25861.png" width=50%>


### 1. 最初に「今回の早さ」は何の早さかを確認する

「とりあえずPoCなので最小の開発工数で動くものを作る」  
「今月中にリリースしたいので、各チームそれぞれ逆算して進める」  
みたいに、**どっちの“早さ”が求められてるのか、言葉にしてみる**だけでも全然違います。

### 2. 作る（Build）と 届ける（Delivery）をちゃんと分けて話す

作る（Build）と 届ける（Delivery）を整理してみましょう。

| 観点             | 作る（Build）                          | 届ける（Delivery）                     |
|------------------|----------------------------------------|----------------------------------------|
| フェーズ         | 実装・開発                            | リリース・顧客告知・運用整備               |
| 主要な課題       | 工数・技術的制約                      | 承認・顧客調整・サポート体制の確保   |
| 優先される視点 | 開発チーム内部の効率・速度                           | リリースから活用・定着までの速度                             |

チーム内で「今どこに時間がかかってるのか？」「どの部分を短縮したいのか？」って会話をするだけでも、だいぶ見え方が変わると思うんですよね。

- 開発工数を最小限に抑えたいから、最速で作ることを優先するのか
- 開発工数には余裕があるけど、ユーザーが喫緊の課題を抱えているから、
それを早く正確に解決するために届けることを優先するのか

もし、こんな認識合わせが着手前に行われていたら、動き方も変わると思うんですよ。

作る（Build）という内部のスピードを上げたいのか
届ける（Delivery）という外部のスピードを上げたいのか

認識を合わせたい部分ですよね。

### 3. 「これはどっちの話？」って一言添える文化を作る

「いま話してるポイントって、作る（Build）スピードのこと？それとも届ける（Delivery）スピードのこと？」みたいな、  
ちょっとした一言がズレを防いでくれるんですよね。

スピードの話に限ったことではないですが、
**会話の前提を揃えてから議論する**って
結構忘れちゃう人多いですよね。（私も気をつけたい・・・）


# おわりに：「“なるはやで！”の裏側にある想い」

「なるはやで！」って、ちょっと焦った声に聞こえるかもしれません。 

でも、その裏には
「なるべく開発工数を少なくしていこう！」
とか
「ユーザーの課題を早く解決したいよね！」っていう、
**誰かの、優しさとか、熱量とか、想い** があるんじゃないかなって思うんです。

だからこそ、単に“早く作る”だけじゃなくて、  
“早く届ける”ことも含めて、
**同じ目標を目指しながら一緒に歩んで行きたい** ですよね。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/394384/79245382-bedf-4178-be33-47d66b1b1a47.png" width=50%>


そのためにできるのが、  
**「今回はどっちの“早さ”を目指してるんだっけ？」って、早めに声をかけあうこと**じゃないかな〜って思っています。