システム導入で問うべきは、作るか買うかではない – Build or Buy より業務の継承を考える

運用業務では、チケット管理、ナレッジ管理、申請管理、承認管理などの仕組みが必要になります。こうした仕組みが不足していると、「自社向けにシステムを作るべきか、それとも既存製品を導入すべきか」という議論が始まります。いわゆる Build or Buy の議論です。

チケット管理やナレッジ管理のように、すでに多くの製品が存在する領域では、既存製品を使う方が合理的に見えます。一方で、自社の業務には独自の事情があり、出来合いの製品では合わないという意見も出てきます。

しかし、本当に重要なのは、作るか買うかではありません。自作システムでも、業務を批判的に検討したうえで設計されていれば合理的なものになり得ます。反対に、既存製品を導入しても、現在の業務を無批判に再現するために大量のカスタマイズを加えれば、実質的には独自システムと変わりません。

システムを作ったか、買ったかではありません。現在の業務を検討し直したか、そのまま継承したかが問われます。

自作すると、業務の癖が保存されやすい

自作システムには、自社の業務へ柔軟に合わせられる利点があります。画面、入力項目、承認経路、通知方法、例外処理まで自由に設計できます。しかし、この自由度は同時に危険でもあります。現在の業務に含まれている癖や偶然まで、要件として取り込めてしまうからです。

• 過去の組織構造に由来する承認経路
• 特定の担当者しか理解していない例外処理
• 用途が明確でない入力項目
• Excel 台帳をそのまま置き換えた画面
• 昔の事故をきっかけに追加された確認工程
• 会議でしか決められない担当振り分け
• 部署ごとに異なる独自のステータス

これらをすべて忠実に実装すれば、現在の業務にはよく適合します。しかし、それは業務が合理的に設計されているから適合しているのではありません。現在存在する複雑さを、そのままソフトウェアへ移しただけかもしれません。

その結果、業務を改善するシステムではなく、現在の業務の癖を保存するシステムができあがります。要件定義が現行業務の聞き取りだけで終わると、この問題が起こりやすくなります。

既存製品でも同じことは起きる

これは自作システムだけの問題ではありません。既存製品を導入しても、現行業務を一切変えずに再現しようとすれば同じことが起きます。標準機能では足りないとして、独自の入力項目、承認フロー、ステータス、画面、連携処理を次々と追加するためです。

• 製品標準のマニュアルをそのまま使えない
• バージョンアップのたびにカスタマイズの影響確認が必要になる
• ベンダーの標準サポートから外れやすくなる
• 自社固有の教育資料と操作手順が必要になる
• 製品経験者でも社内業務を理解できない
• データと業務が製品固有の構造へ固定され、移行が難しくなる

システム本体は既製品でも、カスタマイズ部分が業務の中心になれば、実態としては高価な自作システムです。自作だから閉鎖的になり、既製品だから標準化されるという単純な関係ではありません。閉鎖性を生むのは開発方法ではなく、現在の業務を無批判にシステムへ継承することです。

既存製品は業務を検討し直すための外圧になる

それでも、一般化された領域では既存製品を使う意味があります。既存製品には、標準機能、データモデル、一般的な用語、想定されたワークフローがあります。自社の業務がそのまま製品へ入らない場合、組織は標準から外れる理由を説明しなければなりません。

• なぜ、この承認が必要なのか
• なぜ、この入力項目が必要なのか
• なぜ、この部署だけ別のフローなのか
• なぜ、標準のステータスでは表現できないのか
• なぜ、この例外を恒久的に維持する必要があるのか

既存製品が有効なのは、必ずしも製品の設計が絶対に正しいからではありません。現在の業務をそのまま実装することに、費用、設計変更、保守負担という摩擦を生じさせるからです。この摩擦が、業務の正当性を再検討するきっかけになります。

出来合いのシステムに業務を合わせることには意味があります。ただし、それは製品へ無条件に従うことではありません。製品を、現在の業務を外部の一般性に照らして検査する道具として使うということです。

一般化された領域は固定的には決められない

何が一般化された領域で、何が組織固有の領域なのかは、機能名だけでは決まりません。チケット管理は一般的で、監視アラートからの自動起票は組織固有だと単純に分けることもできません。監視連携、構成情報の補完、定型作業の自動実行なども、製品や自動化基盤によって一般化され続けています。

一般化の境界は、技術と市場の成熟によって移動します。そのため、「一般化されているか」は印象ではなく、複数の観点から判断する必要があります。

多くの組織で目的が共通しているか

インシデントの記録、担当者の割り当て、履歴の保存、全文検索、権限管理などは、多くの組織で目的が共通しています。組織ごとの差が目的そのものではなく、設定値や運用方針にとどまるのであれば、一般化しやすい領域です。

共通の用語やデータモデルが存在するか

インシデント、問題、変更、優先度、SLA、エスカレーションなどの共通語彙があり、複数製品で似た構造が採用されている場合、その領域は一定程度一般化されています。社内独自の言葉でしか説明できない場合は、本当に固有なのか、単に整理されていないだけなのかを検討します。

複数の製品や実装方式が存在するか

複数の製品、OSS、クラウドサービス、API 仕様で類似機能が提供されているなら、その問題は市場で一般化されていると判断しやすくなります。一社の製品にしか存在しない機能は、一般的な要件ではなく、その製品固有の思想である可能性もあります。

外部人材が知識を持ち込めるか

新しく入った人や外部ベンダーが、過去の経験を使って理解できるかも重要です。一般的な製品知識や運用知識を利用できるなら、組織の知識は外部と接続されています。社内固有の操作方法と用語を一から覚えなければならないなら、その知識は閉じています。

独自化が競争力や制御能力につながるか

独自化によって顧客価値、判断速度、サービス品質、技術的優位性が高まるのであれば、自社で設計する意味があります。現在の社内手順を維持するためだけの独自化なら、保守対象を増やしているだけかもしれません。

判断軸	一般化しやすい状態	固有性を残す理由になり得る状態
目的	多くの組織で共通する	事業・契約・安全性に固有の目的がある
用語とデータ	共通語彙や交換可能な形式がある	独自概念が顧客価値や判断精度に直結する
市場	複数製品や OSS で実装されている	市場に代替手段がなく、自社で制御する必要がある
人材	外部経験をそのまま利用できる	内部知識が競争力として管理されている
維持コスト	標準機能で継続的に更新できる	独自性の価値が開発・試験・教育費を上回る

一般化されているかどうかは二択ではなく、程度の問題です。一度独自化した領域でも、現在では標準機能や一般的な連携製品で実現できることがあります。定期的に外部の一般性と比較し直す必要があります。

標準と製品仕様は同じではない

既存製品へ業務を合わせる際には、一般的な標準に合わせることと、特定製品の都合に合わせることを区別する必要があります。ある製品の画面構成やデータ構造は、業界標準ではなく、そのベンダーが選んだ実装である場合があります。

• 製品独自の用語が社内標準になる
• 独自のデータ形式から抜けられなくなる
• 価格改定に業務コストが直接影響される
• 機能廃止や仕様変更に業務が振り回される
• 他製品への移行コストが高くなる
• 本来必要な業務能力まで製品仕様に制約される

既存製品を導入すれば、自動的に組織がオープンになるわけではありません。一般的な概念、交換可能なデータ、標準的な API を維持しながら製品を使う必要があります。標準化とは特定製品への従属ではなく、製品を交換しても残る概念を明確にすることです。

業務を製品に合わせることで失われるものもある

標準化には利点がありますが、常に正しいわけではありません。製品の標準フローへ合わせる過程で、本当に必要な差異まで削ぎ落とす可能性があります。安全性、法的責任、顧客契約、サービス固有の品質基準に関わる判断は、一般的な製品フローでは十分に表現できないことがあります。

現場で長年使われてきた例外処理にも、単なる慣習ではなく、過去の事故や失敗から得られた合理性が含まれる場合があります。問題は独自であることではありません。なぜ独自である必要があるのかを説明できるかです。

製品に合わないから業務を捨てるのでも、現在の業務だから無条件に残すのでもありません。それぞれの差異について、残す理由と維持するコストを比較します。

会社の価値なのか、会社の事情なのか

独自機能や独自フローを残すかどうかを判断するときは、「その仕様は会社固有の価値なのか、それとも現在の会社事情を反映しているだけなのか」と問います。

会社固有の価値とは、顧客への提供価値、技術的優位性、リスク管理能力、判断精度などに結びつくものです。会社の事情とは、現在の部署構成、人員配置、承認者、過去の経緯、特定人物の好みなどです。

組織図が変わっても必要か

部署名や担当者が変わると不要になる仕様なら、組織の一時的な事情である可能性が高くなります。組織構造をデータモデルや承認フローへ直接埋め込む場合は、変更時の影響も要件として扱います。

社外の人に合理性を説明できるか

「昔からそうしている」ではなく、リスク、契約、品質、制御上の理由として説明できるかを確認します。説明できない独自性は、単なる慣習かもしれません。

その独自性は判断能力を高めているか

独自フローによって判断速度や精度が上がるのか、それとも確認者と入力項目が増えているだけなのかを見ます。工程数ではなく、どの判断を改善しているかで評価します。

維持コストに見合う価値があるか

独自仕様には、開発、試験、教育、監査、移行、障害対応のコストが発生します。そのコストを払ってでも保持すべき能力なのかを判断します。検討を経て残された独自性であれば、自作であっても閉鎖的とは限りません。

閉鎖的な知識は、独自コードではなく無検討な業務から生まれる

独自システムを作ると、独自のステータス、用語、権限、教育資料、例外処理が増えます。その結果、社員が身につける知識は「その会社の、そのシステムの、その時点での使い方」になりやすくなります。

しかし、閉鎖的な知識を生む原因は独自コードそのものではありません。業務の背景や判断基準が整理されず、操作手順としてしか残されていないことにあります。

自作システムでも、一般的な概念を使い、標準的なインターフェースを持ち、判断理由が文書化されていれば、外部と接続可能な知識になります。反対に、一般製品を使っていても、「A 票を起票し、B 承認を通し、C 状態になったら第二運用課へ回す」という手順しか説明できなければ、その知識は社内に閉じています。

重要なのは製品名ではなく、業務をどの抽象度で説明できるかです。概念、目的、判断基準として説明できる組織は、知識を外部と共有できます。操作、画面、担当者名としてしか説明できない組織では、知識がローカルな方言になります。

システムを層に分けて考える

Build or Buy をシステム全体で一度に決めると、議論が粗くなります。運用管理システムなら、次のように層へ分けて考えます。

層	例	基本的な考え方
共通基盤	記録、検索、履歴、権限管理	市場で一般化されており、既存製品を優先しやすい
共通モデル	チケット、ナレッジ、インシデント、変更	標準語彙を利用し、製品を越えて意味を保つ
業務フロー	通知、承認、エスカレーション	標準フローを基準に、必要な差異だけを残す
連携	監視、構成管理、チャット、API	一般的な connector と固有の接続処理を分ける
判断	優先度、リスク、実行条件	組織が基準を握り、製品設定や rule として表現する
経営・サービス判断	継続、停止、例外承認	責任主体と判断根拠を組織側に残す

記録、検索、権限、履歴などは一般化されやすく、リスク判定、実行条件、サービス継続判断などは組織固有性が高くなりやすい領域です。中間の連携や自動化では、仕組みは一般製品を使い、ルールや判断条件だけを組織側で持つ構成が考えられます。

箱は既存製品を使い、判断や接続部分だけを作る。 ただし、接続部分まで一般化されているなら、そこも作らない方が合理的です。

何を作るかは機能名ではなく、一般化の程度と独自性の価値から判断します。箱の部分でも、事業上の制約から自社管理が必要なら、独自に持つ合理性があります。

作るか買うかの前に、業務を検討する

システム導入では、早い段階から製品比較や開発方式の議論が始まりがちです。しかし、その前に現在の業務を分解し、それぞれの目的と判断への接続を確認する必要があります。

• 何のために存在する業務なのか
• どの判断につながっているのか
• 実行しなかった場合に何が起きるのか
• 一般的な製品や標準ではどう扱われているのか
• 自社独自である必要はあるのか
• 組織変更後も必要か
• 独自性を維持するコストに見合うか
• 製品を変更しても、データと判断基準を引き継げるか

この検討をせずに自作すれば、現在の業務をコードへ移すだけになります。この検討をせずに既存製品を導入すれば、現在の業務をカスタマイズへ移すだけになります。開発方式が違っても、結果はあまり変わりません。

何を作るかではなく、何を継承しないか

何でも自社で作る組織は技術力が高く見え、既存製品を導入する組織は合理的で標準化されているように見えます。しかし、外形だけでは判断できません。重要なのは、そのシステムに何が継承されたかです。

• 検討された判断基準が実装されたのか
• 本当に必要な独自性だけが残されたのか
• 過去の慣習や組織事情がそのまま固定されていないか
• 外部と共有可能な概念で説明できるか
• 製品を変更しても知識とデータが残るか

システム設計では、作るか買うかを決める前に、現在の業務の何を残し、何を捨てるかを決めなければなりません。既存製品は、そのための有効な外圧になります。しかし、製品に従えば自動的に正しい業務になるわけではありません。

標準化も自作も、それ自体は目的ではありません。一般化できるものは外部の一般性へ接続し、本当に固有の価値だけを組織に残すことが目的です。

参考書籍

まとめ

システム導入で問うべきなのは、Build か Buy かという二択ではありません。自作システムでも業務を検討し直していれば合理的になり、既存製品でも現行業務を大量のカスタマイズとして再現すれば閉鎖的になります。

重要なのは、一般化できる機能、会社固有の価値、現在の会社事情を分けることです。記録や検索の箱は既存製品を使い、判断基準は組織が握るといった層ごとの選択もできます。

作るか買うかを決める前に、何を残し、何を捨て、どの知識を製品の外側へ保持するのかを決める必要があります。検討したのか、それとも継承しただけなのか。 その違いが、組織に残るシステムと知識の性質を大きく左右します。