上流の会議にシステムの席はあるか——事業判断とIT参画の順番を問う

「決まってから呼ぶ」という構造

ある開発担当者の言葉が、問題の本質を正確に言い当てていた。

「海外に出店すると決まったタイミングで連絡してほしい。出店の3か月前に『なんとかしてください』と言われても、もう間に合わない」

間に合わないのは、能力の問題ではない。呼ばれる順番の問題だ。

多くの組織で、ITシステムは「事業の判断を実装する部門」として位置づけられている。新しい拠点を開く、新しいサービスを始める、業務フローを変える——こうした判断は、経営層や事業部門の会議の中で進む。システム担当者が呼ばれるのは、その後だ。決まった要件を、決まった期日までに形にすることを求められる。

開発側はこの構造に、何年も前から気づいている。それでも変わらないのは、「システムは実装する部門」という役割認識が、組織の慣習として固まっているからだ。

システムが「下流」に置かれているとき

意思決定の後に呼ばれる部門は、必然的に制約の多い状況で仕事をすることになる。

• スケジュールはすでに決まっている
• 予算はすでに組まれている
• 業務フローはすでに合意されている
• システム側の制約を、誰も確認していない

この状態で「あとはシステムをお願いします」と言われると、開発担当者にできることは限られる。既存の仕組みに合わせるか、短期間で動くものを無理やり作るか。どちらも、後工程でのコストと問題を先送りにするだけだ。

「仕様書があるから大丈夫」という感覚は、このときも働く。しかし仕様書は、ある時点の事業判断を文書化したものにすぎない。その判断の過程で、システムが何を受け入れられるかは誰にも問われていない。「仕様書がある」は安心の根拠にならないで整理したように、ドキュメントの存在は実行可能性を保証しない。

同じ構造は、AI活用の場面でも起きる。業務の要件が言語化されていない段階で「AIで何かやってほしい」と依頼しても、実装の入り口に立てない。AIへの指示が書けないときで整理した問いは、ここにも重なってくる。要件を言語化できないまま実装を依頼することと、判断が終わってからシステムを呼ぶことは、同じ構造の別の顔だ。

上流の席をどうつくるか

解決策はシンプルだ。事業の判断をする場に、システム担当の席をつくる。

これはITが意思決定を主導するという話ではない。検討の早い段階で「システム側の制約を確認する人」として同席することだ。事業側が決断を下す前に、技術的な実現可能性とおおよその期間感を共有しておく。それだけで、後工程の「間に合わない」は大きく減る。

具体的には、三つの変化が起点になる。

1. 「決まったら連絡」から「検討中に相談」へ。 新しい事業や拠点を検討し始めた段階で、IT担当者に情報を共有する。「こういうことを考えているが、システム上の制約はあるか」と問うだけでいい。
2. 会議体の参加者を見直す。 事業計画会議や経営会議の参加者リストに、IT担当を加える。「声をかける・かけない」の属人的な文化から、構造的な参加の仕組みへ変える。
3. 「実装の依頼」と「制約の確認」を分ける。 IT担当への連絡をすべて実装依頼として扱わない。制約を確認する相談を、実装依頼の前段に置く。

外部のパートナーとして事業のデジタル伴走を担うしぼるのような関わり方が機能するのも、計画の初期段階から同席できるからだ。「決まってから呼ばれる」関係では、できることに構造的な限界がある。

呼ぶ順番を変えることが、間に合う仕事をつくる。それが、システムに上流の席をつくるという意味だ。