全体最適の罠を避けるには　情シスが小さく進める設計と実行

どうも おかしん です。

情シスやIT企画の仕事では、全体最適を考えることがとても大事です。

部門ごとに個別最適された仕組みをバラバラに作ると、同じようなマスタが複数できたり、似たような機能が別々のSaaSやシステムに作られたりします。最初は小さな便利さに見えても、組織が大きくなるほど、どれが正本なのか、誰が直すのか、どこへ連携するのかが分からなくなります。

一方で、全体最適にこだわりすぎると、今度は何も前に進まなくなります。

「全社の完成形を設計してからでないと始められない」「全体アーキテクチャが決まっていないから現場改善は待つべきだ」という状態が続くと、現場の困りごとは放置され、情シスは意思決定と実行に接続されない調整や分析を繰り返すことになります。

この記事で言いたいことはシンプルです。全体最適は、全部を先に決めることではありません。後で組織を壊さないための要所を押さえながら、実行を前に進めることです。

全体最適は、全部を先に決めることではない

まず、この記事でいう全体最適を定義します。

ここでいう全体最適とは、全社で使うシステム、SaaS、データ、権限、運用責任が、組織として説明できる状態に近づいていることです。すべての業務を一つの巨大な仕組みに統合することではありません。

たとえば、従業員情報を扱うなら、どのシステムを正本にするのか。部門情報は誰が直すのか。退職者の権限はどこから止まるのか。顧客情報を扱うなら、営業、請求、サポート、マーケティングのどこで同じ情報を参照するのか。

こうした問いに答えられないまま個別対応を重ねると、あとで必ず苦しくなります。

ただし、全体最適を「全体の完成図を最初から完璧に決めること」と捉えると、それもまた危険です。事業も組織も業務も変わります。最初に描いた完成図が、半年後の現場に合っているとは限りません。

ISO/IEC 38500:2024 は、組織における現在および将来のIT利用をガバナンスの対象として扱っています。ここから読み取れる大事な点は、ITの全体最適は「今ある構成」だけではなく、「これからどう使われるか」も含めて考える必要があるということです。

つまり、全体最適は静的な完成図ではありません。現在地を押さえ、将来の変化に耐えられるように、意思決定の土台を作ることです。

個別最適を放置すると何が起きるのか

個別最適そのものが悪いわけではありません。小さく始めること、現場の困りごとに早く対応することは大切です。

問題は、個別最適されたものが、そのまま組織の標準になってしまうことです。

架空の例で考えてみます。

営業部門が商談管理のためにSaaSを導入します。人事部門は入退社管理のために別のSaaSを導入します。経理部門は請求先管理のためにまた別のシステムを使います。それぞれの導入理由は正しい。各部門の業務効率は上がります。

しかし、従業員、組織、取引先、権限、請求先のような情報が、それぞれの場所で別々に管理され始めると、次のような問題が起きます。

特に危ないのは、正本が曖昧になることです。正本とは、あるデータについて、他のシステムや業務がそれを基準にする、公式な一つの出どころのことです。

マスターデータは、単に「よく使うデータ」という意味ではありません。組織の中で、他のシステムや業務が参照する土台になります。ISO 8000-110:2021 は、組織間やシステム間で master data（特性データ）をやり取りするときの構文や意味づけ、データ仕様への準拠を扱う標準です。正確性や来歴そのものは、同じ ISO 8000 シリーズの ISO 8000-130（正確性） や ISO 8000-120（来歴） が個別に定義しています。本稿としては、ここから「マスターデータは、仕様に準拠し、正確性や来歴まで説明できる状態に保つことが重要だ」と読み替えています。

もちろん、標準の話をそのまま日常の情シス運用に持ち込めばよいわけではありません。それでも、マスターデータを雑に扱うと、後でシステム間連携、監査、業務改善のすべてに影響するという見方は重要です。

個別最適を許すなら、少なくとも「これは暫定であり、正本ではない」「将来はこのマスタへ寄せる」「このSaaS側の情報は参照用途に限定する」といった線引きが必要です。

全体最適の罠は、設計が目的化したときに起きる

では、個別最適が危ないなら、すべてを全体設計してから始めるべきなのでしょうか。

私はそうは思いません。

全体最適の罠は、設計が目的化したときに起きます。現場課題を解くための設計だったはずなのに、いつの間にか「設計が完成していないから動けない」という状態になる。これが危ない。

分析や設計は大事です。むしろ、何も考えずに進める方が危険です。ただし、分析や設計が意思決定と実行に接続されていないなら、組織に学習は起きません。

改善サイクルの説明としてよく参照される PDSA Cycle は、Plan、Do、Study、Act を通じて、継続的な改善のための学習を得るプロセスとして説明されています。ここで大事なのは、計画だけでも、実行だけでもなく、実行結果を観察して次の行動へ反映することです。

この記事では、PDCA/PDSAの起源論には踏み込みません。ここでは単に、改善には「やってみて、結果を見て、次を変える」サイクルが必要だという意味で扱います。

情シスの全体最適も同じです。

きれいな設計図を作ることが目的ではありません。設計した仮説を、小さな導入、運用、ログ、利用者の反応、例外対応で検証し、次の設計へ戻すことが大事です。

IPAのDX推進指標 も、経営者や社内関係者が現状や課題の認識を共有し、アクションにつなげるためのものとして説明されています。現状把握は、止まるためではなく、次のアクションを選ぶためにあります。

全体最適を考えることと、動かないことは違います。

情シスが先に決めるべき5つの要素

では、全体最適を考えながら小さく進めるには、何を決めればよいのでしょうか。

私は、最初から詳細な全社アーキテクチャを描くより、案件ごとに次の5つを確認する方が現実的だと考えています。

この5要素を表で整理すると、次のようになります。

この5つを決めるだけでも、個別最適の危険度はかなり下げられます。

案件メモに落とすなら、たとえば次のように書けます。

たとえば、部門から「問い合わせ管理を早く改善したい」という要望が出たとします。全社共通のCRMやITSMを導入するには時間がかかる。だから一時的に部門向けのSaaSを使う。

この判断自体は悪くありません。

ただし、そのときに、正本、責任者、連携先、暫定運用、撤退条件を、上の案件メモのように具体的に書き留めておく。

ここまで決まっていれば、小さく始めても、あとで全体最適へ戻せます。

逆に、これを決めずに「便利だから使う」で始めると、数年後にはそのSaaSが業務の中核になり、誰も外せなくなります。マスタも権限も連携も後付けになり、結果として全体最適から遠ざかります。

小さく始めても、後で統合できるようにする

小さく始めることと、雑に始めることは違います。

小さく始めるとは、最初から完璧を目指さない代わりに、後で学べるようにしておくことです。

ここで参考になるのが、IPAの プラットフォームデジタル化指標 で説明されている考え方です。そこでは、現在利用しているITシステムをベースに、追加、変更、廃棄などを実施しながら段階的にDXに対応できるITシステムを目指すことが一般的だと説明されています。また、問題点を見える化し、優先順位やロードマップ、対策実行につなげることも重視されています。

この考え方は、情シスの日常にもそのまま使えます。

全体最適を考えるとき、最初に必要なのは完璧な未来図ではありません。現状の地図です。

• どのSaaSに、どのデータがあるか
• どのデータが手入力で、どのデータが連携されているか
• どのアカウントや権限が、どの業務に紐づいているか
• どの運用が属人化しているか
• どのシステムを今後も残し、どれを統合または廃止したいか

この現状把握がないまま全体最適を語ると、設計は空中戦になります。

一方で、現状把握だけを続けても前には進みません。台帳を作る。重複を見つける。重要度を分ける。次に統合する対象を決める。小さな改善を入れる。結果を見る。必要なら設計を更新する。

この循環が重要です。

データ管理の観点でも同じです。DAMA International は、データマネジメントを、データと情報資産の価値をライフサイクル全体にわたって届け、統制し、保護し、高めるための計画、ポリシー、プログラム、実践を策定・実行・監督することとして説明しています。つまり、データ管理はきれいな定義表を作ることだけではなく、組織がデータを使って判断できる状態を維持する活動です。

情シスに必要なのは、全体最適の図を一度描いて終わりにすることではありません。現場で起きたことを受けて、図を更新し続ける運用です。

先に設計を厚くするべき領域

ここまで「小さく始める」話をしてきましたが、何でも軽く始めればよいわけではありません。

先に設計を厚くするべき領域もあります。

代表的なのは、次のような領域です。

• ID基盤、認証、認可
• 人事、組織、雇用形態
• 会計、請求、支払い
• 顧客、契約、取引先
• 監査証跡、ログ、証明責任
• 法令、規制、契約上の保存義務があるデータ

これらは、正本や責任分界を間違えると手戻りが大きくなります。特にID、人事、会計、契約、監査証跡は、後から「やっぱり別の正本にします」と言いにくい領域です。

このような領域では、スピードよりも先に決めるべきことがあります。

大事なのは、重い領域では何もできない、という話ではありません。

重い領域ほど、より小さく切る必要があります。たとえば、全社ID基盤を一気に作り替えるのではなく、まず退職者停止の流れだけを標準化する。全社データ基盤を作る前に、顧客マスタの正本と更新責任だけを決める。

「全部やるまで始めない」ではなく、「間違えると戻れないところから決める」のです。

全体最適を理由に止める案件、進める案件

ここまでの粒度の話を、案件ごとの判断に落としてみます。

実務では、最終的に判断が必要です。これは止めるべきなのか、仮置きで進めてよいのか、後から統合する前提で進めるのか、今すぐ標準化すべきなのか。

最初に確認する質問は、次のようなものです。

• 正本を壊さないか
• 退職者や異動者の権限を止められるか
• 監査証跡や変更履歴が残るか
• 責任者と期限が決まっているか
• 後から統合、移行、廃止できるか

先に挙げた5要素で案件を仕分けると、次のように分けると考えやすいと思っています。

判断の軸は、理想に近いかどうかだけではありません。

今どれだけ困っているか。どれだけ手戻りが大きいか。正本を壊すか。利用者体験を悪化させるか。後で統合できるか。運用責任者を置けるか。

これらを並べて、情シスが選択肢として提示することが大事です。

弊社ブログの「情シス・情報セキュリティはどう経営と対話すればいいのか」でも、リスクと効果を事業の言葉で整理する考え方を書いています。全体最適の話も同じで、「正しい設計です」と説明するだけではなく、効果、リスク、必要な管理策が違う選択肢として出す必要があります。

よくある質問

全体最適と個別最適は、どちらを優先すべきですか

どちらか一方ではありません。正本、責任者、連携先、暫定運用、撤退条件を押さえられない案件は止めるべきです。一方で、その5つを決められるなら、仮置きで小さく始めて、結果を見ながら全体像を更新する選択肢があります。

全体最適の設計は、どこまで先に決めるべきですか

最初から全社の完成図を細部まで決める必要はありません。ただし、ID、人事、会計、契約、監査証跡のように、正本や証跡を誤ると戻りにくい領域は先に厚く見ます。軽く始める領域と、先に設計を厚くする領域を分けることが大事です。

情シスが現場要望を止めるべきなのはどんなときですか

正本が壊れる、権限停止できない、監査証跡が残らない、責任者が置けない、撤退条件を決められないときです。逆に、範囲と期限を切れて、後から統合または廃止できるなら、止めるよりも管理された仮置きとして進める方がよい場合があります。

まとめ

全体最適は大事です。

個別最適を放置すると、マスタが乱立し、機能が重複し、責任が曖昧になり、組織が大きくなるほど苦しくなります。情シスが全体像を見ずに個別対応だけを続けると、いつか自社の運用を自社で説明できなくなります。

でも、全体最適に固執しすぎても前には進みません。

完璧な設計ができるまで何も作らない、何も変えない、何も試さない。これでは、現場の困りごとは解決せず、組織の学習も進みません。

大事なのは、全体最適を「全部を先に決めること」と捉えないことです。

正本、責任者、連携先、暫定運用、撤退条件を決める。重い領域では設計を厚くする。軽く始められる領域では、小さく試して、結果を見て、全体像を更新する。

これが、情シスが全体最適の罠を避けながら前に進むための現実的なやり方だと思います。

私がこの話を書きたかったのは、情シスの仕事が「止める側」か「何でも作る側」の二択で語られがちだからです。

本当は、その間にかなり大きな仕事があります。組織全体で後から困らないように要所を押さえ、それでも現場が前に進める道を作ることです。

まずは、今進んでいる1つの案件を、正本、責任者、連携先、暫定運用、撤退条件の5つで棚卸ししてみるのがよいと思います。

全体最適は、スピードを殺すための言葉ではありません。安全に、説明可能に、そして継続的に前へ進むための考え方として使っていきたいですね。