引っ越しのとき、夜10時に段ボールを組み始めて、勢いに乗って明け方には食器も本も服も全部詰め終わっていました。自分の段取りの良さに、少し感心したのを覚えています。
そこから、段ボールの壁の中で11日暮らしました。
歯ブラシがどの箱に入っているか分からないので、コンビニで買い直しました。早く終わらせたのは事実です。ただ、早く終わらせて手に入ったものは、11日間の待ち時間と、2本目の歯ブラシだけでした。
退去日は、動かなかったからです。
先に一行だけ置きます。内製化とは、外部に発注していた開発を自社の側に取り戻すことです。エンジニアを採用して自社で作る形もあれば、少人数の共創チームで作る形もあります。
題材は、大企業との共創プロジェクトです。現場にアプリを入れて、滞在客が自分の端末から手続きできるようにする。少人数で、内製に近い形で作りました。
前置きはさておき、本題に入ります。
今日は、この内製化で実装が3日になったのに、プロジェクトが動かなかった話をしていこうと思います。
① 教科書どおりに、内製化して速くする
内製化の教科書には、こう書いてあります。外部への発注をやめれば、伝言が減り、意思決定から実装までの距離が縮む。
そのとおりでした。
ある3日間の実装量について、こういう報告が出ています。
「この3日間で実装した分（チャット機能・多言語対応・レビュー修正一式）だけでも、SI見積もりなら15〜25人月に相当します」
3日です。
チャット機能、多言語対応、レビューで挙がった指摘の修正一式。従来の目盛りに当てると15〜25人月。数千万円規模の実装量です。
作り方も変わりました。デザインの工程について、こういうやりとりがあります。
「Figma、一切使っていないんです。時間がなかったので、全部直接AIでデザインしました…。」
「Figma使ってない！？ 一体、、」
中間成果物が消えています。 設計書もモックも作らず、動くものが直接出てくる。内製化とAIが重なると、こういう速度になります。
ここまでは、教科書どおりです。
② そのとおりに進めて、0件に詰まる
ところが、同じ日にこういうやりとりがありました。
「はい、0件ですね…。」
トランザクション、0件です。
念のため書いておきますが、これは別の月の話ではありません。数千万円規模を3日で積んだと報告した、その同じ日の実績です。
片方には数千万円相当の実装量があり、もう片方には0がある。
この2つが同じ日に並んでいる状態を、私はきれいな言葉で説明できません。
引っ越しと同じでした。荷造りを一晩で終わらせても、退去日は動きません。動かないどころか、一晩で終わらせたおかげで、退去日までの11日間がまるごと待ち時間として見えるようになっただけです。
「速くなった」の最初の成果物は、成果ではなく、待ち行列の可視化でした。
③ そして、原因が紙だと分かる
0件の原因を追いました。
技術的な不具合ではありませんでした。アプリは動いています。決済も通ります。利用が始まらないのは、QRコードを刷った印刷物が現場に置かれていないからでした。
置かれていないだけではありません。置くべき場所が空かない。 部屋の中の限られた面積に、何を置くかという話は、こちらの権限では決まりません。
ここで多くのチームは、こう考えます。
「印刷物の展開は現場のタスクだから、こちらは仕様を整えて待つ」
これは正しい判断です。役割の線引きとして、間違っていません。
ただ、この正しさを守った場合、プロダクトは正しいまま0件のままになります。
④ 原因は「制約を解除したら、制約が移動していた」こと
原因を一つに絞ると、これでした。
私たちは、実装という制約を外すことに成功しました。そして外した瞬間に、制約は別の場所へ移動しました。
移動先は、プロダクトの中ではありません。
→ 印刷物が現場に届いていない
→ 置く場所が空かない
→ 決裁の予定表が空かない
どれも、コードでは解けません。そしてどれも、私たちの担当範囲の外にあります。
速くなる前は、この3つは見えませんでした。実装が最も遅かったので、外側は「まだ待てる」状態だったからです。実装が3日になった瞬間に、残っていた遅さが全部むき出しになりました。
⑤ 直してみる — 速い側が「作る以外の仕事」を取りにいく
律速が自分の外に出たとき、選択肢は3つしかありません。
→ (a) 待つ
→ (b) 相手に依頼して待つ
→ (c) 自分で取りにいく
(a) は、荷造りを終えて段ボールの壁の中で11日過ごす選択です。(b) は、相手の予定表を動かせない限り (a) と同じ結果になります。
(c) を選びました。
現場に必要なのは印刷物でした。誰も作れる状態になかった。そこで、依頼されていないA4のチラシと、A3のプラカード3種類を作って、現場に投げ込みました。
もう一つ。チラシを部屋のドアノブに掛けるための袋が、どこにも売っていません。100円ショップを巡っても見つからない。そこで、こうなりました。
「ドアノブ用の袋は、ハンドルバッグタイプがないなら透明のOPP袋にパンチで穴開けて、紐通して作るとかでいいと思います」
開発会社が、袋に穴を開ける話をしています。
引き受けたくて引き受けたわけではありません。0件のままだと、3日間の実装がまるごと存在しなかったことになるからです。
⑥ あとで知った — 制約が移動することには、名前がついていた
素朴な対処のつもりでしたが、調べると同じものを指す理屈は、すでにありました。
物理学者のエリヤフ・ゴールドラットが1984年の著書『ザ・ゴール』で提示した制約理論（Theory of Constraints）です。組織の目標達成を妨げている、ただ一つの最大の制約を特定して、そこに集中する、という考え方です。
手順は5つに整理されています。制約を見つける／制約を活用しきる／他を制約に合わせる／制約を引き上げる／繰り返す。
要点は5つ目です。
制約を引き上げて解消したら、手順1に戻れと書かれています。そして、そこにこう付いています。「惰性によって、それがシステムの制約であり続けることを許すな」。
制約は、解消すると消えるのではありません。次の場所へ移動します。
私たちがやったのは、実装という制約を引き上げたことでした。引き上げた瞬間に、制約は印刷物と決裁へ移った。 それだけの話です。
そして、もう一つ。制約を引き上げる前に活用しきれ、という順序も書かれています。設備投資が要るからです。内製化は「引き上げ」にあたります。 だから費用がかかる。にもかかわらず、引き上げた先に別の制約が待っていることは、40年前から知られていました。
新しい理屈は、ひとつも要りませんでした。
⑦ 何が変わったか — 速さの証拠は、タイムスタンプにしか残らない
「作る以外の仕事」を取りにいくようになって、変わったことがあります。速さの示し方です。
提案書に「アジャイル」「高速リリース」「並走型開発」と書くのは誰でもできます。書いた文字と実力に相関はありません。
証明になったのは、時刻の記録だけでした。
→ 31分。現場から「アプリから配送が押せません」の報告。原因を切り分けて、復旧の報告まで31分
→ 12分。現場から「規約でこの機能が使えないことが分かりました」の報告。外部の規約で機能が丸ごと死んだ状態から、代替設計に差し替えるまで12分
→ 8時間。決済の3Dセキュアが、お客さんの目の前で止まった。同じ日のうちに恒久対応まで完了
障害の報告時刻と復旧の報告時刻の差は、後から書き足せません。 12分で代替設計に差し替えた記録は、偽造できない。
内製化の効果を説明するとき、人月削減額を並べても伝わりませんでした。タイムスタンプの密度を見せると、一度で伝わります。
⑧ 現場で使うなら、この2枚
表1：制約の移動先を、先に書き出す
| 工程 | 速くなるか | 誰が持つか | 空かないと何が起きるか |
|---|---|---|---|
| 実装 | なる | 内製チーム | — |
| 印刷物の作成・配布 | ならない | 不明になりがち | 利用が0件で始まらない |
| 設置場所の確保 | ならない | 現場 | 同上 |
| 決裁 | ならない | 決裁者の予定表 | 公開日が動く |
| オペレーション変更 | ならない | 現場 | 使われない |
「誰が持つか」が空欄の行が、次の制約です。 内製化を始める前にこの表を書くと、投資対効果の議論が変わります。
表2：速さを証明する記録の取り方
| 記録するもの | 粒度 | なぜ効くか |
|---|---|---|
| 障害報告の時刻 | 分 | 後から書き足せない |
| 復旧報告の時刻 | 分 | 同上 |
| 仕様変更の依頼〜反映 | 分 | 伝言が減った証拠になる |
| 上申日の変更履歴 | 日 | 決裁の待ち行列が可視化される |
⑨ この考え方が効き続ける理由
実装は、これからも速くなります。そして、速くなるほど外側の遅さがむき出しになります。 これは技術の進歩で解決しません。制約が移動するという構造だからです。
このプロジェクトについて、こういう言葉が残っています。
「情熱と制度（投資承認）は時間軸が異なる」
半年動かして、起案の枠は20分でした。決裁の四者会議は30分で、しかもそれは、すでに他に6つ予定が入っている時間への割り込みとして設定されたものでした。
そして、18か月のあいだに上申日が4回動いています。
4回動いた理由に、技術やプロダクトが挙がったことは一度もありません。
片方は31分で動き、片方は18か月で4回滑る。この2つが、同じプロジェクトの中に同居しています。
つまり、内製化とAIが生産性に与えた本当の帰結は、「開発が速くなった」ではないと思います。速い側が、もう「言われたものを作る人」の位置に立てなくなった、ということです。
外側の律速を自分で外しにいかない限り、3日間の実装は、存在しなかったことになります。
ただし、正直に書いておきます。速く作れるということは、速く事故を起こせるということでもあります。 そして、この「範囲の外まで取りにいく」動きは、人数を増やすと途端に成立しなくなります。範囲の外側の仕事は、担当が決まっていないから外側にあるのであって、人を増やすと「それは誰の仕事か」の議論が先に立つからです。
関連して、アジャイル開発をAIで並行させたときの衝突話と、AI駆動開発で自作基盤とネイティブ機能を分ける話を別に書いています。AI時代の要件定義話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。
この判断を実際の案件で使う場面については、AIプロダクト開発のページに整理しています。
3日でできる、といえば、年賀状はいつも3日で書き終わります。
出すかどうかを、11月から悩んでいるだけです。手が遅いわけではありませんでした。
以上です。
Yuki Susai
