見えている未来を、手元に並べる

1. よくある破綻

要件定義や開発計画の説明を聞いているとき。
あるいは設計をしているとき。
その場では特に問題は起きていない。

議論は成立しているし、計画も一応、筋が通っている。

ところが、実装がある程度進むと詰む。

• 運用が回らない
• 承認が下りない
• 調整コストが爆発する
• スケジュールが崩壊する

はたから見ていると、
ああ、やっぱりそこで詰んだか。
と言いたくなるようなポイントで止まる。

2. その場で何が起きているか

この手の破綻は、その場で何かが「足りていなかった」わけではない。

説明は通っている。
質疑も成立している。
合意も取れた、という空気がある。

それでも、後から詰む。

このとき、その場では「あとで必要になる判断」が混ざったまま進行している。

たとえば、

• この工程、誰の判断が必要になるのか
• いつまでなら延期が認められるのか
• 実装途中で止まる要因はあるのか

こうした点が、未確定のまま先送りされる。

重要なのは、それが見えていなかったのではなく、見えていたが扱われなかったという点だ。

今は決めなくていい、そのとき考えよう、まずは進もう。

そうやって、未来で必ず立ち止まる判断が、場の外に置かれる。

---

「じゃあ別案でいこう」
その決定が下されたのはまさに今だった。
だがその別案を実装できるエンジニアは、既にプロジェクトを外れている。

---

「外部システムのデータ連携有無はまだ決まってないし、今は単体で動けばいいよね。」
しかし、後日連携案件が決まってしまう。
連携するには、基盤の再設計が必要になる。

---

それは、分岐点に立った瞬間に噴き出す。

3. 先行して未来を巡らせる

こうした状態に対して、自分がやっていることは単純だ。

説明を聞きながら、あるいは設計を書きながら、その前提を未来に向かって一度、最後まで進めてみる。

いま決めたことが、実装段階でどう扱われるか。
運用に渡ったとき、誰がどのタイミングで判断を下すことになるか。
合意が必要になる瞬間はどこか。
止まるとすれば、どの条件で止まるか。

順番に先へ送り進める。

これは予言ではない。
計画と呼ぶのも少し違う。
単に、いまの前提を時間軸に沿って展開しているだけだ。

そうすると、必ずどこかで

• 判断が必要になる地点
• 誰かの意思決定に依存する地点
• 未確認の前提が露出する地点

が現れる。

そこが「未来で止まる場所」だ。

筆者は、この一連の処理を
非同期シミュレーションと呼んでいる。

やることは一つ。

その地点を、いまの会話に戻す。

4. 未来を「判断材料」に落とす

未来を先に走らせて、止まる地点が見えたとしても、それをそのまま口に出しても意味はない。

「ここで詰みます」
「たぶん無理です」

と言っても、それは根拠のない予言か感想にしか聞こえない。

やるべきなのは、未来で必要になる判断を、いま扱える材料に変換することだ。

たとえば、こう返す。

---

「この前提で進むと、いずれ必ず〇〇さんの判断が必要になる。
そのタイミングで止まっても問題ないか？」

---

「この計画だと、その後の案件のためにリリース延期は不可能になる。
それを考慮しているか？」

---

「外注ならすぐに取り掛かれるが、実装中の判断待ちは増える。
どちらの未来を選ぶ想定か？」

---

今決めろとは言わない。
正解も提示しない。

起こりうる未来と帰結だけを並べて置く。

そうすると、本来は未来で行われるはずだった判断が、自然といまの場に戻ってくる。

決めさせることが目的ではない。
少なくとも、"必要な判断が存在すること"だけは、その場で共有される。
それだけで、「進んでいたはずなのに止まる」という破綻は減る。

5. いつ使うべきスキルなのか

会議の場でも、手を動かしているときも、設計を書いているときも、並行して思考を未来に走らせる。

いま進んでいるこの道は、どこで詰まるか。
この実装は、あとで判断待ちにならないか。
この構造は、運用で破綻しないか。

無心で前進するのではない。
常に軽くブレーキを踏みながら進む。

この先で止まる未来はないか？
と問い続ける。

この処理が常時走っているからこそ、破綻の兆候を早い段階で拾える。

6. 症例1：運用統合で詰む

システム統合の案件を外から見ていたことがある。

技術的な統合自体は進んでいたが、運用フローや責任分界の話がほとんど出てこなかった。

未来に向けて考えられる道を辿っていくと、どこで止まるかは明確だった。

実際に運用の適用につまづき、困り果てた段階でヘルプが飛んできた。

技術の問題ではない。
未来の運用が、その段階になるまで選ばれていなかった。

7. 症例2：外注か内製か

外注か内製かを検討している場にいたことがある。

自分の見立ては明確だった。

内製でなければ成立しない。
ドメイン理解者がいない状態で外注しても、判断待ちと仕様迷走が連鎖する。

進言したものの、判断は覆された。
結果は、典型的なデスマーチだった。

このときも、未来は見えていた。

だが、

• 楽観
• 目の前の都合

が優先され、
未来の選択は先送りされた。

8. なぜ通らないことがあるか

このやり方は、正しくても通らないことがある。

理由は単純だ。
未来より、今が優先されるからだ。

まだ起きていない事故は軽く見られる。
これは技術の問題ではない。
時間軸の優先順位の問題だ。

このスキルは、破綻や選択の誤りをゼロにするものではない。

それでも、判断できたはずの分岐を、判断可能なタイミングに戻す。

それだけで、現場の安定感は確実に上がる。

9. このスキルが生む摩擦

このやり方には、コストがある。

• 議論のテンポを壊すことがある
• 「先回りしすぎ」「話を止める人」に見える
• 立場によっては、権限を越えた介入に映る

思考のプロセスが見えにくいぶん、周囲からの反感が生まれることもある。
それでもこの処理を走らせるかどうかは、常にトレードオフになる。

10. スピードが出る副作用

この処理の副作用として、進行のスピードが上がる。
不要な選択肢を早期に潰せるからだ。

詰む未来が見えているにもかかわらず、
そこに向かって思考を積み上げるのは、あとで捨てる前提の議論を量産する行為になる。

• 詰むと分かっている案を深掘りしない
• 確定できない分岐は「確認必須」として止める
• 生き残る枝だけに思考を集中する

速く考えているのではない。
考えなくていいことを、先に減らしている。

その結果として、意思決定も実装も自然と速くなる。

まとめ

これは、未来を当てるスキルではない。
観測して満足するためのものでもない。

見えている未来を、無心で先送りしないための処理だ。

今すぐ決めなくていい。
その未来を選ぶ準備・覚悟があるか
という問いを手元に置いておく。

それだけで、防げる手戻りは少なくない。