「うちのシステムの方向性、そろそろ考えてよ」
ある日、会議でそう頼まれる。IT部門は資料を開き、現場の担当者は少しだけ遠い目をする。会社として何を伸ばすのか、どの業務を変えたいのか、何を優先するのか。その話はまだ聞いていない。
会社の行き先が分からないまま、システムの行き先だけを決める。これは「目的地は秘密だけれど、乗り物は選んでおいて」と言われるようなものです。
現場が欲しいのは、完璧な未来予測ではありません。少なくとも、経営が何を実現したいのか、どんな選択を優先するのかという、判断のよりどころです。
WHERE ARE WE GOING?
行き先なしで、乗り物だけ選べるだろうか
システムをつくることは、旅の目的に合う乗り物を選ぶことに少し似ています。
| 目指すこと | 考えられる手段 | 先に知りたいこと |
|---|---|---|
| 身近な業務の手間を減らす | 既存サービスの活用、小さなWebアプリ、業務手順の見直し | どの作業を、誰のために、どれだけ改善したいか |
| 新しい市場や地域へ広げる | 拡張可能なサービス基盤、データ連携、複数地域での運用 | 対象顧客、開始時期、必要な規模や展開順序 |
| 高い統制や特殊な要件を満たす | 強化したアクセス制御、監査、専用環境など | 守るべき情報、規制、許容できるリスクと運用負担 |
近所へ行くのか、海を渡るのか、極地を目指すのかが違えば、適した乗り物も変わります。ところが目的地が決まらないまま「最新で、何にでも使えて、将来も困らないものを」と頼まれると、選びやすいのは、たいてい高価で大きくて、誰も全容を説明できない乗り物です。
WHEN THE PREMISE CHANGES
完成間際に行き先が変わると、現場で何が起きるか
前提の変更そのものが悪いわけではありません。変化を共有せず、以前の判断がそのまま有効であるかのように進めることが、手戻りを大きくします。
01 / ASSUMPTION
前提を、現場が想像で埋める
情報がないまま、エンジニアは「おそらくこうだろう」と仮定して設計します。その仮定は、資料に書かれていないほど後から事実として扱われがちです。
02 / CHANGE
作ったものが、新方針に合わない
新事業や優先順位の変更が共有されると、既存の設計では足りないことが分かります。追加開発、作り直し、移行で、時間と予算が必要になります。
03 / PATCHWORK
「翼を付けよう」が始まる
完成した四輪車に、急いで翼を取り付ける。たとえ話なら笑えますが、現実には例外処理や暫定対応が増え、保守しづらさとして残ります。
もちろん、変更を一切なくすことはできません。大切なのは、どの前提で決めたのか、前提が変わったら何を見直すのかを記録し、変更の影響を早めに話せる状態にしておくことです。
IT IS A MEANS, NOT MAGIC
システムは、経営の代わりに目的を決めない
ITは戦略を実行しやすくする手段であり、経営上の選択そのものを肩代わりするものではありません。
業務をそのままシステムにすると
整理されていない手順や重複した承認を変えずに自動化すると、不要な工程まで速く、正確に繰り返す仕組みになることがあります。まず業務の目的と、変えてよい範囲を確かめます。
目的が共有されないまま作ると
機能の希望は集まっても、何を優先すべきか判断できません。要望を積み上げた結果、誰のどんな課題を解くのかが見えにくいシステムになることがあります。
一方で、IT側が経営の検討に何も貢献できないという意味ではありません。小さな試作やデータの分析から、実現可能性、費用、リスクを示し、経営が選択する材料をつくることもできます。目的を決める責任と、実現方法を検討する専門性を、対話でつなぐことが必要です。
A BETTER CONVERSATION
「できません」ではなく、決めるための材料を返す
方向性が曖昧なときは、技術だけで結論を出そうとせず、選択肢とそれぞれの影響を見える形にします。
01 / OPTIONS
複数のシナリオを示す
「既存事業の効率化を優先する場合」と「新規事業への展開を優先する場合」など、前提ごとに構成、費用、期間、制約を並べます。
「どれが正解ですか」ではなく、「どの結果を優先しますか」と尋ねると、経営判断につながります。
02 / TRADE-OFFS
決めない場合の影響も示す
判断が遅れたときに増える手戻り、暫定運用、契約更新、機会損失の可能性を整理します。
根拠のない大きな金額で不安をあおるのではなく、分かっている事実、仮定、影響の幅を分けて説明します。
03 / SMALL STEPS
戻せる範囲で小さく試す
不確実な部分は、短い検証や最小限の試作で確かめます。大きな契約や一括構築の前に、利用者の反応や技術上の制約を確認します。
試行の目的、期間、成功条件、中止条件を決めておけば、「小さく始める」が終わりのない実験になるのを防げます。
WHO DECIDES WHAT?
経営とIT、それぞれが決めること
責任を押し付け合うのではなく、判断する人と専門知識を持ち寄る人を明確にします。
| 経営が決めること | ITが整理・提案すること | 一緒に決めること |
|---|---|---|
| 顧客や事業の目標、優先順位 | 実現方式、選択肢、制約、技術的なリスク | 段階計画、予算、期限、期待する効果 |
| どの業務を変えるか、何を後回しにするか | 移行方法、運用体制、必要な人員やスキル | 業務変更の範囲、利用者への支援、定着の測定 |
| 許容する事業リスクと投資判断 | セキュリティ対策、障害時の選択肢、費用の幅 | 継続・見直し・中止の判断基準 |
IT側は経営判断に必要な問いを出し、選べる材料を整える。経営側は目的と優先順位を示し、決定する。これが揃えば、IT戦略は単なる技術選定ではなく、事業の方向に沿った実行計画になります。
SUMMARY
エンジニアは予言者ではない
会社の未来をすべて言い当てられる人はいません。だからこそ、経営の方向が変わる可能性を認め、前提を共有し、変更の影響を確かめながら進む必要があります。
「システムの方向性を考えて」と頼まれたら、こう問い返してみてください。
「このシステムで、会社のどんな状態を実現したいですか。今、何を優先し、何を後回しにしますか。」
その答えがまだ決まっていないなら、答えを選ぶためのシナリオを一緒に作るところから始められます。地図のない航海で必要なのは、万能のエンジンではありません。行き先を話し合い、進路を確かめ、必要なら引き返せる航海の仕組みです。