LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

社内にCTO（最高技術責任者）がいないまま、開発を外部エンジニアに頼んでいる。使う技術も、どこまで自社で作るかも、気づけばその時々の提案どおりに決まっている——。こうした会社では、システムごとに作り方がばらばらになりがちです。アーキテクチャ方針とは、システムの構造をどう決めるかの原則のことで、技術を選ぶときの基準、設計で守る決まり、そして誰がどう決めて見直すかをまとめたものを指します。

本記事では、IPA（情報処理推進機構）の「DX実践手引書 ITシステム構築編」をもとに、CTO不在の会社が外部エンジニアの力を借りながらアーキテクチャ方針を決め、守っていくための考え方を整理します。方針の軸になる3つの要件、自社で作るか外部のサービスを使うかを業務ごとに分ける2つの競争性、外部エンジニアとの役割の分け方、見直しの時期を順に取り上げます。

アーキテクチャ方針とは

アーキテクチャ方針に書くことは、大きく3つに分けられます。1つ目は技術を選ぶときの基準で、どの領域は自社で作り、どの領域は既製のパッケージやクラウドのサービスを使うかという線引きを含みます。2つ目は設計で守る決まりで、システム同士のつなぎ方やデータの持ち方などが当たります。3つ目は決め方で、誰が案を出し、誰が承認し、いつ見直すかを指します。方針は個々の案件の設計書と違い、案件をまたいで使います。

方針が要る理由は、構造の決め方が後の手間を左右するためです。DX実践手引書は、アプリケーションの構造を決めるのはアーキテクチャであり、どのアーキテクチャを採るかによって修正の容易さや影響範囲が変わり、工数や期間に影響が出るとしています。^*1 最初の案件で選んだ構造は、その後の改修の費用や期間にまで効いてきます。

手引書はDX（デジタル技術による事業の変革）に取り組む企業向けの資料で、2024年3月27日に完成第1.1版が出ています。大企業の事例が多いものの、自社で作る範囲の決め方は、技術の責任者がいない会社でも方針の下書きに使えます。

CTO不在で起こりやすいこと

社内に技術の判断をまとめる人がいないと、技術の選択は案件ごとに、そのとき加わった外部エンジニアの得意な技術に寄りがちです。案件ごとには筋の通った選択でも、会社全体では言語やクラウド、データの持ち方がそろわず、担当が替わるたびに引き継ぎの手間が増えます。

任せ方にも注意が要ります。手引書は、競争の要素がない領域の業務を一つのサービス提供者にまとめて任せきりにすると、業務がブラックボックス化するおそれがあると指摘しています。そうなると、より効率的で安いサービスが出てきても選びにくい、いわゆるベンダーロックの状態になることがあるとしています。^*1

一方で、外部の力を借りないという選択も現実的ではありません。IPAが東証一部上場企業を対象に行ったアンケート（回答92社、2019年5月公表）では、DXの推進で社外との連携が「必要不可欠である」と答えた企業が55.4%、「どちらかと言えば必要である」が26.1%でした。連携の目的（2つまで選ぶ形式）では「自社にない技術力を獲得するため」が78.3%で最も多くなっています。^*2 問われるのは頼るかどうかではなく、何を自社の手元に残すかです。

方針の軸になる3つの要件

手引書は、先行事例企業への調査をもとに、DXを実現するためのITシステムで重点とされているポイントを3つの観点に分けています。社内外のシステム間の連携を目指す「社会最適」、データ活用を中心に据えて新たな価値を生む「データ活用」、システムとその開発運用の体制が変化に俊敏かつ柔軟に対応できる「スピード・アジリティ」です。^*1 方針を書くときは、この3つを見出しにすると抜けが出にくくなります。

社会最適は手引書が付けた呼び方です。競争領域と非競争領域を明確にし、非競争領域ではすでに社会にある外部のサービスを使うことで生まれる割り勘効果によって、自社のIT投資額や開発・保守の体制を最適化し、その分の資源を競争領域に回すことを指しています。

スピード・アジリティについて、手引書は2つの言葉を分けて定義しています。スピードは、一定の機能や品質を保ったシステムをどれだけ俊敏に構想・設計・開発・運用できるか。アジリティは、市場や環境の変化に応じて臨機応変に軌道修正できる柔軟性です。そのための要件として、アプリケーション同士が密結合せず、機能単位で疎結合に分かれていて、APIなどで接続と切断が容易に行えることを挙げています。

3つの要件をどこまで求めるかは会社によって違います。手引書も、すべての企業が各要件を最上級にしたハイエンドモデルを必要とするわけではなく、「ビジョンに即したもの」を目指せばよいとしています。^*1 自社が各要件をどの程度求めるかを短く書いておくと、大がかりな構成が提案されたときの判断材料になります。

業務ごとに2つの競争性で分ける

自社で作るか、外部のサービスを使うかを決める物差しとして、手引書は2つの競争性を挙げています。事業的競争性は、他社と同様な業務を行っていて、その事業や扱っている情報が差別化の要因になっているかどうか。技術的競争性は、他社に比べて特徴的な技術を使っているかどうかです。^*1 この2つを縦横に組み合わせると、業務は4つの領域に分かれます。

事業的にも技術的にも競争の要素がない領域は、パッケージソフトウェアやSaaS、業界の共通基盤を使うのが望ましいとされます。事業的には競争性があるが技術的にはない領域は、競争力の源になる情報を生み出し活用する部分を社内で作り、その情報を処理する部分は外部の技術コンポーネントを取り入れます。事業的にも技術的にも競争性がある領域は、内製開発に投資と人を集中させます。^*1

残る、事業的な競争性はないが技術的な競争性がある領域は、内製開発で技術の強みを生かし、商品の価格を下げるなど事業全体の競争性につなげる道があるとされています。CTO不在の会社では、まず主なシステムを業務ごとに書き出し、4つのどこに入るかを経営と業務の担当者で決めます。手引書は、競争性を判断する範囲を明確にしておく必要があるのに、それができていない組織もあると述べています。

外部とつなぐ部分の決まり

どの領域に入るシステムでも、方針に共通して書いておきたいのが外部とのつなぎ方です。手引書は、競争領域と非競争領域のいずれでも、外部との接続仕様はセキュリティを担保しつつ世の中の標準的なものに合わせ、容易に連携できるようにしておくべきだとしています。^*1

もう一つは、業務と業務のつなぎ目を自社で握っておくことです。手引書は、競争の要素がない領域でも、業務間のインタフェースを自社でコントロールできることが望ましいとしています。さらに、外部のサービスを使う領域でも、自社でその業務ロジックと業務間インタフェースを把握しておく必要があると述べています。中身の実装は外部エンジニアが担っても、システム同士が何をやりとりしているかの一覧は社内で持っておく、という分け方です。

外部のサービスを選ぶときに比べる点も、手引書が整理しています。デメリットとして挙げているのは、自社固有の業務に合わせた細かいカスタマイズが難しいこと、契約の仕方によっては自社のノウハウが流出すること、ブラックボックス化で障害やセキュリティリスクへの対応が長引くおそれがあること、提供者の都合で値上げやサービス終了がありうることなどです。^*1 方針にこれらを確かめる項目として並べておくと、外部エンジニアの提案を同じ物差しで比べられます。

外部エンジニアとの役割の分け方

手引書は、企業の変革を共に進めるパートナーの役割として、顧客が内製開発する部分と外部のサービスを採用する部分の決定をサポートすることを挙げています。^*1 外部の技術者は決定を支える立場で、決めるのは発注する会社だという整理です。

技術の優劣は外部エンジニアのほうが詳しくても、どの業務で他社と差をつけるかは社内でしか決められません。承認する人は技術に詳しい人でなくてもよく、情報システムの担当役員や事業部門の責任者が受け持つ形もあります。会社として重要な決定にあたるかどうかの整理はCTO不在で外部エンジニアに頼むとき、取締役会に残す決定とはで扱っています。

決めた理由の記録は、外部エンジニアが替わったときに効いてきます。選んだ案だけでなく、ほかの案となぜ選ばなかったかを短く残しておくと、後任が同じ検討をやり直さずに済みます。

方針を見直す時期

業務がどの領域に入るかは固定されたものではありません。手引書は、ある事業や技術が競争領域にあるかどうかは時系列で変化するとし、変化の例を2つ挙げています。技術の進歩で、以前は特徴的だった技術を他社でも実装できるようになること。業界での合意や法制度、規制によって業務が標準化され、事業的な競争性が失われることです。^*1

変化に合わせて、外部のサービスの使い方も変えていくことになります。たとえば内製してきた業務のうち、世の中の技術が進んで外部のほうが高度な技術を提供するようになった領域は、その技術を技術コンポーネントとして取り入れることで、事業をより効率的にできる可能性があるとされています。

手引書は外部サービスの活用方針のまとめとして、「競争性は時系列で変化するので、定期的に再評価し、その結果によって方針を見直せ」と記しています。^*1 この検討は開発のときだけでなく、サービスの運用中にも定期的に行うべきだとしています。きっかけには、契約の更新、大きな改修の前、使っているサービスの値上げや終了の知らせなどがあります。

つまずきやすい点

1つ目は、方針を立派に書きすぎることです。最上級の構成を前提にすると、小さな改修にも重い手順がかかり、方針が守られにくくなります。まずは主なシステムの領域分けと、外部とのつなぎ方の決まりだけから始める形もあります。

2つ目は、既製品を入れたのに作り込みを重ねてしまうことです。手引書は、パッケージ製品は業務を標準化して標準の機能をできるだけそのまま使い、追加の作り込みやアドオン開発の規模を可能な限り抑えることが望ましいとしています。^*1 競争の要素がない領域と決めたシステムで作り込みの提案が出てきたら、方針に照らして止める役目が社内に要ります。

3つ目は、方針が外部エンジニアに届いていないことです。新しく加わる人に方針と理由の記録を最初に渡し、設計の確認で方針から外れていないかを見ます。設計を確かめる進め方は外部エンジニアの技術レビュー、契約で分ける検証と監査の違いにまとめています。

まとめ：アーキテクチャ方針で決めておく3つの点

CTO（最高技術責任者）不在の会社が外部エンジニアの力を借りてアーキテクチャ方針を決めるうえで、押さえておきたい点は3つです。第一に、社会最適・データ活用・スピード・アジリティの3つの要件を軸に、自社がどこまで求めるかを書くこと。第二に、業務ごとに事業的競争性と技術的競争性を判断して自社で作る領域と外部のサービスを使う領域を分け、外部とのつなぎ方は標準的な仕様にそろえて自社で把握しておくこと。第三に、外部エンジニアには選択肢と比較の材料を頼み、領域の判断と方針の承認は社内に残したうえで、競争性の変化に合わせて定期的に見直すことです。開発を担う人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA（情報処理推進機構）「DX実践手引書 ITシステム構築編 完成第1.1版」（PDF）（https://www.ipa.go.jp/digital/dx/hjuojm000000gx4n-att/000094497.pdf）。出典：令和6年3月27日 完成第1.1版発行。第3章（p.57〜76：社会最適・データ活用・スピード・アジリティ）、4.3.1（p.104）、4.7.4〜4.7.8（p.184〜191：外部サービス利用のメリット・デメリット、2つの競争性、デジタル産業の企業4類型との関係、競争性の変化、外部サービス活用方法のまとめ）を参照（確認日2026年10月2日）（2026年10月確認）
2. *2　参考：IPA（情報処理推進機構）「デジタル・トランスフォーメーション推進人材の機能と役割のあり方に関する調査 報告書本編」（PDF）（https://www.ipa.go.jp/jinzai/chousa/qv6pgp000000buyg-att/000073700.pdf）。出典：令和元年5月17日。東証一部上場企業を対象としたアンケート調査（回答n=92）のうち、p.43「社外との連携の必要性に対する認識」とp.44「社外との連携の目的」を参照（確認日2026年10月2日）（2026年10月確認）

Tweet