仏像を彫るようなわけにはいかない ─ ソフトウェア開発の複雑性
導入：世界線1 を振り返る
Day9 の続きです。
昨日は Geminiが作成してくれた「二つの世界線」の例え話を紹介しました。
経営者の指示：
「すべてのECサイトの売上とPOSの売上を統合して分析したい。どのチャネルが売れているか知りたい」
世界線1（戦略実行設計者がいない場合） では、こうなりました：
IT部門に丸投げ → Excel が落ちる → 手作業で3日
外部コンサルに依頼 → Tableau + Snowflake で 500万円
実装フェーズで問題噴出 → 「楽天は仕様が特殊」「ZOZOはAPI制限」
追加費用 200万円、納期延長 3ヶ月
結果: 初期費用 700万円、年間ランニング 270万円、期間 6-12ヶ月
今週は、Gemini の例え話を深掘りします。
今日のテーマ: なぜ世界線1 は失敗したのか？
多くの経営者が経験する「世界線1」について
世界線1 のような失敗は、多くの会社で起きています：
「作ってもらったけど、これじゃない...」
「なんでこんなに時間がかかるの？」
「追加費用がこんなに？最初に言ってよ...」
なぜこうなるのでしょうか？
多くの人は作業者やソフトウェアに理由を求めます。「ちゃんとしないから」「技術が足りない」「バグ製品じゃないのか」などなど。
でも、本当の原因は違います。
根本原因：業務・人間が複雑
問題は、作業者やソフトウェアだけではありません。
業務や人間が複雑だ、ということです。
それを"銀の弾丸"思想で IT 化しようとすると、失敗します。
❌ よくある誤解
「作業者がちゃんとヒアリングしないから失敗する」
「技術が足りないから失敗する」
「バグのあるソフトウェアだから失敗する」
⭕ 本質
「経営者の暗黙知を、一緒に言語化する必要がある」
「業務が複雑だから、一緒に整理しながら作る必要がある」
「ソフトウェアにバグはつきものだから検証しながら進める必要がある」
4つの複雑性
世界線1 の失敗を振り返ると、4つの複雑性が見えてきます。
1. 経営者の頭の中が複雑
経営者：「在庫配分を最適化したい」
一見シンプルですが...
どのチャネルに、どの商品を、どれだけ配分するのか？
売上予測はどう計算するのか？
在庫回転率の目標値は？
欠品リスクと過剰在庫のバランスは？
季節性は考慮する？
誰が意思決定するのか？
そもそも、経営者自身も全てを言語化できていません。
世界線1 では：
経営者：「売上のデータを見たいんだよ」
IT部門：「全部ですか？」
経営者：「とりあえず全部。詳しいことは君たちに任せる」
→ 2ヶ月後: 「これじゃない...在庫との比較が見たかったんだよ」
触ってみて初めて、「あ、こういうのが欲しかった」と分かるのです。
2. 業務が複雑
「ECサイトとPOSの売上を統合」と言っても：
楽天: RMS API がある、でも仕様が特殊
Amazon: MWS API がある、でも認証が面倒
ZOZOTOWN: API がない、CSV 手動ダウンロード
POS: スマレジ？何を使ってる？確認必要
それぞれシステムが違い、仕様が違います。
さらに：
商品マスタの統合（同じ商品でもシステムごとにコードが違う）
倉庫管理（どの倉庫にどの商品があるか？）
在庫回転率の計算式（会社ごとに違う）
例外処理（返品、キャンセル、セール品）
世界線1 では：
開発会社：「楽天は仕様が特殊です」
開発会社：「ZOZOはAPI制限があります」
開発会社：「POSシステムは何ですか？」
→ 実装フェーズで判明: 追加費用 200万円、納期延長 3ヶ月
作り始めてから気づくことは多いのです。
3. 組織が複雑
世界線1 では、こんなやり取りがありました：
IT部門：「ECサイトって何がありますか？」
経営者：「えーと、楽天と、Amazonと...他にもあったはず。営業に聞いてくれ」
経営者も全てを把握していません。
現場には、こんな複雑性があります：
経営者、営業部、IT部門、開発会社... それぞれ理解度が違う
使う言葉が違う（「チャネル」「API」「ダッシュボード」）
部門間の調整コスト（誰に聞けばいいのか？）
意思決定プロセス（誰が承認するのか？）
組織が複雑だから、情報が断片化します。
4. 人間の感覚が複雑
世界線1 では：
IT部門：「ダッシュボードができました」
経営者：「うーん...なんか違う気がする...」
開発会社：「何が違いますか？」
経営者：「...よく分からないけど、使いにくい」
画面を触ってみないと、「使いにくい」が分かりません。
ボタンの配置
画面遷移の流れ
データの見せ方
色の使い方
これらは、実物を見て初めて「あ、こうじゃない」と気づくのです。
仏像を彫るようなわけにはいかない
唐突ですが、優れた仏師は「木の中に仏が見える」と言います。
最初から完成形が分かっているということでしょう。
でも、当然ながらソフトウェア開発は違います。
"仏" が見えてはいますが、役職や役割が違うそれぞれの "曖昧" な仏の姿 しか見えてません。
従来のウォーターフォールと呼ばれる開発プロセスでは、こう考えます：
要件定義: 全ての要件を文書化する
設計: 要件定義に基づいて設計する
実装: 設計に基づいて実装する
テスト: 仕様通りか確認する
納品: 完成
前提: 要件は最初に全て決まる（彫る前に仏が見えるはず）
でも、この前提だとシステム開発や DX の成功は難しくなります。
私たちは木の中に仏は見えません。
作りながら、見せながら、確認しながら、形を見つけていく必要があるのです。
重要なのは創りたい仏像を一致させること
ソフトウェア開発で難しいのは、プログラムを書くことではありません。
難しいのは、「何を作るか」を皆が理解することです。
経営者の暗黙知を言語化すること
業務の例外処理を洗い出すこと
組織の情報を集約すること
他人の理解状況を想像すること
など、非常に多くのことを考えながら、共通理解を進めていく必要があるのです。フィードバック、コミュニケーションのループが肝要だと思います。
まとめ
世界線1 の失敗は 「複雑性」と向き合わなかった結果 といえるのではないでしょうか。
4つの複雑性
経営者の頭の中が複雑（言語化できない）
業務が複雑（例外処理、暗黙知、システム間の違い）
組織が複雑（部門間の調整、情報の断片化）
人間の感覚が複雑（触ってみないと分からない）
これらの複雑性に対処するために
一度に作ろうとしない
作りながら、見せながら、お互いに確認しながら進める（フィードバック、コミュニケーション）
IT 現場の複雑性やコミュニケーションの重要性について、少しでもご理解頂ければ幸いです。
明日（Day10）は、「小さく作って、見せて、確認する」という考え方 「MVP（Minimum Viable Product）」 を紹介します。
