「フロントエンドは React と Vue のどちらにしますか」「インフラは AWS で問題ないですか」。システム開発をベンダーに発注すると、こうした技術選定の判断を求められる場面が必ず訪れます。けれど社内に技術が分かる人がいなければ、根拠を持って答えるのは難しく、つい「お任せします」と返してしまうものです。
問題は、その「お任せします」が後から響いてくることです。「その技術を選んだせいで毎月の保守費が想定より高い」「別の会社に引き継ごうとしたら断られた」——開発が終わってから、あるいは運用に入ってから、技術選定の影響に気づくケースは少なくありません。技術選定は技術者だけの問題に見えて、実はコストと事業の継続性に直結する、発注者にとっての経営判断でもあります。
とはいえ、発注者がプログラミング言語やクラウドの優劣を自分で判断できるようになる必要はありません。必要なのは「技術を理解すること」ではなく「技術選定の妥当性を確認する判断軸を持つこと」です。技術名は分からなくても、コスト・保守性・乗り換えやすさという3つの観点から質問できれば、ベンダーの提案が自社にとって適切かどうかは十分に確認できます。
本記事では、技術選定とは何かを非エンジニア向けに整理したうえで、発注者が確認すべき3つの非機能要件、ベンダーに聞くべき5つの具体的な質問、ロックインを避ける考え方、そして「選んだ技術がまずかったかも」と後から気づいた場合の対処までを順に解説します。読み終えたとき、「お任せします」から「根拠を持って合意する」へ一歩踏み出せる状態を目指します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
技術選定とは何か｜なぜ発注者が関与すべきか
技術選定とは
技術選定とは、システムをつくるときに「どの道具を使って開発するか」を決めるプロセスです。具体的には、プログラミング言語（システムを記述する言葉）、フレームワーク（開発を効率化する土台。React や Vue がこれにあたります）、インフラ（システムを動かす基盤。AWS や Google Cloud などのクラウドサービス）、そしてデータベースや各種ツールといった構成要素を、複数の選択肢の中から選び出す作業を指します。
家を建てるときに「木造か鉄骨か」「どのメーカーの設備を入れるか」を決める工程をイメージすると分かりやすいかもしれません。同じ間取り（機能）の家でも、選ぶ素材や工法によって、建築費はもちろん、住んでからの修繕のしやすさや、将来のリフォーム費用まで変わってきます。システムの技術選定もこれと同じで、同じ機能を実現する場合でも、選ぶ技術によって開発後のコストや拡張性が大きく変わります。
重要なのは、技術選定は「正解が1つだけ」のものではないという点です。多くの場合、どの技術にも長所と短所があり、プロジェクトの目的・規模・予算・将来計画によって最適解が変わります。だからこそベンダーは発注者に意見を求めますし、発注者の側も「どれが正しいか」ではなく「自社の事情に合っているか」という視点で関わることが求められます。
なぜ「お任せします」が危険なのか
技術選定をベンダーに丸投げすること自体が、必ずしも悪いわけではありません。信頼できるベンダーであれば、適切な技術を選んでくれることも多いでしょう。問題は、発注者が判断軸を持たないまま丸投げすると、後から取り返しのつきにくい3つの後悔につながりやすいことです。
1つ目はコストの後悔です。開発時の費用（初期費用）だけを見て発注すると、運用が始まってから「毎月のクラウド利用料が想定の倍だった」「使っているソフトウェアのライセンス更新費が年々上がる」といった事態に気づきます。技術選定の段階では見えにくいランニングコストが、長期的には初期費用を上回ることも珍しくありません。
2つ目は保守の後悔です。選んだ技術が特殊だったり、ドキュメント（仕様書や設計書）が整備されていなかったりすると、ちょっとした改修にも多くの工数と費用がかかります。「ボタンを1つ追加するだけで数十万円」といった見積もりに驚く発注者は少なくありません。
3つ目は乗り換えの後悔です。あまり世の中で使われていない技術や、そのベンダー独自の仕組みでつくられたシステムは、別の会社に引き継ごうとしても「うちでは対応できません」と断られることがあります。結果として、不満があっても今のベンダーから離れられない状態に陥ります。これがいわゆるベンダーロックインで、のちほど詳しく説明します。
これらの後悔に共通するのは、いずれも開発が終わってから、あるいは運用に入ってから初めて表面化するという点です。だからこそ、技術選定の段階で発注者が最低限の確認をしておく価値があります。
発注者が関与すべき範囲・しなくてよい範囲の線引き
「関与すべき」と言われると、技術を勉強しなければならないのかと身構えるかもしれませんが、そうではありません。発注者の関与には「任せてよい範囲」と「確認すべき範囲」があり、この線引きを理解しておくことが大切です。
任せてよい範囲は、技術そのものの優劣の判断です。「React と Vue のどちらが優れているか」「このデータベースは適切か」といった技術的な良し悪しは、専門家であるベンダーに委ねて構いません。発注者がここを無理に判断しようとすると、かえって的外れな指示になりかねません。
一方で確認すべき範囲は、その技術選定が自社の事業にどう影響するか、という点です。具体的には、長期的なコスト、改修のしやすさ、将来の乗り換え可能性。これらは技術の中身が分からなくても、ベンダーに質問することで確認できます。
つまり、発注者がやるべきは「技術を理解すること」ではなく「事業への影響を確認すること」です。次の章では、その確認のための具体的な3つの軸を見ていきます。
技術選定で発注者が確認すべき3つの非機能要件
技術選定の妥当性を発注者が確認するとき、技術の中身に踏み込む必要はありません。代わりに、その技術が事業にどう影響するかを「非機能要件」という観点から見ます。非機能要件とは、システムの機能そのものではなく、コストや保守性、安定性といった「使い続けるうえでの性質」を指す言葉です。
ここでは、発注者が特におさえるべき3つの軸——コスト、保守性、採用市場と乗り換えやすさ——を順に説明します。この3つで質問できれば、技術名を覚えなくても選定の妥当性を確認できます。
コスト｜初期費用に隠れたランニング・ライセンスコスト
技術選定がコストに与える影響を考えるとき、見積書に書かれた開発費（初期費用）だけを見るのは危険です。システムは作って終わりではなく、動かし続けるためにお金がかかります。
ITの世界にはTCO（Total Cost of Ownership：総所有コスト）という考え方があります。これは初期費用だけでなく、運用・保守・人件費・ライセンス更新費用まで含めた、システムを所有し続ける期間全体の総コストを指します。技術選定によってこのTCOは大きく変わります（アイティークロスメディア）。
発注者が確認すべきコストには、主に次のようなものがあります。
- ランニングコスト：クラウドサービスの利用料など、システムを動かすために毎月かかる費用。選ぶ構成によって月額が数倍変わることもあります
- ライセンス費用：使用するソフトウェアやツールによっては、利用や更新に継続的な費用が発生します。無償で使える技術を選べば、この費用は抑えられます
- 改修・拡張コスト：将来機能を追加したり修正したりするときの費用。これは次に説明する保守性と深く関係します
ポイントは、初期費用が安くてもランニングコストが高ければ、数年単位では割高になり得るということです。発注者としては「この技術選定で、初期費用以外に継続的にかかる費用はいくらか」を必ず確認しておきましょう。
保守性｜改修のしやすさ・ドキュメント・属人化の回避
保守性とは、システムを後から修正・改善しやすいかどうかを表す性質です。一度つくったシステムも、事業の変化に合わせて機能を足したり直したりする必要が出てきます。このとき保守性が低いと、わずかな変更にも大きな工数と費用がかかります。
保守性を左右する要因はいくつかありますが、発注者が確認しやすいのは次の2点です。
1つ目はドキュメントの整備状況です。システムの設計や仕様が文書として残っていれば、後から別の担当者やベンダーが見ても内容を理解できます。逆にドキュメントがなければ、改修のたびにコードを一から読み解く手間が発生し、その分の費用がかかります。
2つ目は属人化の回避です。属人化とは、特定の人にしか分からない状態を指します。マイナーな技術や、その担当者だけが知っている独自の仕組みでつくられていると、その人が抜けた途端に誰もメンテナンスできなくなります。一般的で広く使われている技術を選び、仕様を文書化しておくことが、属人化を防ぐ基本です。
発注者としては「このシステムは、開発担当者が変わっても問題なく改修できる状態になりますか」「設計や仕様のドキュメントは納品に含まれますか」を確認するとよいでしょう。
採用市場と乗り換えやすさ｜マイナー技術が生むリスク
3つ目の軸は、選ぶ技術が世の中でどれだけ使われているか、という観点です。一見すると発注者には関係なさそうですが、実は乗り換えやすさやコストに直結する重要なポイントです。
技術を採用するときには、その技術がエンジニアの市場でどのくらい流通しているのか、その技術を扱える人材や会社がどれだけ存在するのかを見ることが重要だとされています（株式会社アイティークロス）。広く使われている技術であれば、それを扱える人材や開発会社が世の中にたくさんいます。
一方、コミュニティが小さくドキュメントが乏しいマイナー技術を選ぶと、バグ修正やバージョンアップ時に対応できるエンジニアが見つからず、外注費や採用費がかさむリスクがあります。具体的には、次のような問題が起こり得ます。
- 改修を頼める会社が限られ、相見積もりが取れず費用が高止まりする
- 今のベンダーに不満があっても、別の会社が対応できず乗り換えられない
- 担当エンジニアの採用が難しく、内製化したくてもできない
これらはすべて、特定の技術や会社に縛られてしまう「ロックイン」につながる伏線です。発注者としては「この技術を扱える会社や人材は、世の中に多いですか」「将来、別の会社に引き継ぐことは現実的に可能ですか」を確認しておくと、乗り換えの自由度を保てます。ロックインそのものへの対策は、のちほど詳しく扱います。
発注者がベンダーに聞くべき5つの質問
ここまでの3つの軸——コスト・保守性・採用市場と乗り換えやすさ——を、そのままベンダーへの質問に落とし込んだものが、この章で紹介する5つの質問です。技術の中身が分からなくても、この5問を投げかけ、返ってくる答えの質を見れば、技術選定の妥当性をかなりの精度で確認できます。
5つの質問とその意図
以下の5つを、ベンダーから技術選定の提案を受けたタイミングで質問してみてください。質問の意図とあわせて示します。
質問1：この技術を選んだ理由を、他の選択肢との比較で教えてください （意図：選定に根拠があるかを確認する。比較検討した形跡があれば、その場の都合や慣れだけで選んでいない証拠になります）
質問2：初期費用以外に、継続的にかかるコストはどれくらいですか （意図：ランニングコストやライセンス費用を可視化する。TCOの観点で長期的な負担を把握します）
質問3：将来この技術を扱える会社・人材は確保しやすいですか （意図：採用市場での流通度を確認する。乗り換えや内製化の自由度に関わります）
質問4：ソースコードとドキュメントの権利はどちらに帰属しますか。納品に含まれますか （意図：成果物の権利を明確にする。これが曖昧だと、後で乗り換えができなくなります）
質問5：将来、別の会社に保守や改修を引き継ぐことは可能ですか （意図：ロックインの有無を直接確認する。引き継ぎを前提にした設計になっているかを問います）
これらの質問は、ベンダーを問い詰めるためのものではありません。むしろ、発注者がこうした観点を持っていることが伝われば、ベンダー側も長期的な視点で誠実に提案してくれるようになります。よいベンダーであれば、これらの質問を歓迎するはずです。
ベンダーの回答に潜む赤信号
質問することと同じくらい大切なのが、返ってきた答えをどう読み取るかです。技術の専門知識がなくても、回答の「姿勢」から注意すべきサインを見抜くことはできます。以下のような回答が返ってきたら、赤信号として一度立ち止まって確認しましょう。
質問 | 赤信号となる回答 | なぜ問題か |
|---|---|---|
選んだ理由 | 「弊社の標準なので」「これが一番慣れているので」のみ | 自社の都合が優先され、案件に合っているかの検討が見えない |
継続コスト | 「運用してみないと分かりません」で終わる | 概算すら示せないのは、コスト意識が低いか、見せたくない事情がある可能性 |
扱える人材 | 「うちにしか分かりません」 | 属人化・ロックインを前提にしている可能性が高い |
権利の帰属 | 明言を避ける／「弊社に帰属します」が当然という態度 | 成果物の権利が発注者に残らず、乗り換えが困難になる |
引き継ぎ | 「引き継ぎは想定していません」 | 一度発注したら離れられない設計になっている恐れ |
もちろん、これらの回答が即座に「悪いベンダー」を意味するわけではありません。事情を丁寧に説明してくれるなら問題ないこともあります。大切なのは、赤信号が出たときに「なぜそうなるのか」を遠慮なく掘り下げて聞くことです。納得できる説明があるかどうかで、そのベンダーの誠実さが見えてきます。
ベンダー選びそのものの基準については、システム開発のベンダー選定基準6項目もあわせて参考にしてください。
ロックインリスクを避けるための技術選定の考え方
5つの質問のうち、質問4と質問5は「ベンダーロックイン」に深く関わるものでした。ここでは、このロックインについて発注者目線でもう少し掘り下げ、技術選定の段階で打てる予防策を整理します。
ベンダーロックインとは｜発注者にとっての実害
ベンダーロックインとは、特定のベンダーや技術に縛られて、他社への乗り換えや内製化ができなくなる状態を指します。発注者にとっての実害は、主に次の3つです。
- 価格交渉力を失う：他社に乗り換えられないと分かっていれば、ベンダーは強気の価格を提示できます。相見積もりが取れず、保守費や改修費が高止まりします
- 品質に不満があっても離れられない：対応が遅い、ミスが多いといった問題があっても、引き継げる会社がなければ我慢するしかありません
- 事業のスピードが落ちる：改修のたびに特定のベンダーの空き状況に依存し、機動的に動けなくなります
ロックインは一度発生すると解消が難しく、解消しようとすればシステムの作り直しに近いコストがかかることもあります。だからこそ、技術選定の段階で予防することが最も効果的です。
技術選定の段階で打てる予防策
ロックインは、技術選定と契約の段階でいくつかの手を打つことで、大きく軽減できます。発注者が意識しておきたいのは次の3点です。
1つ目はオープンで標準的な技術を選ぶことです。広く使われている標準技術や、無償で使えるオープンソース（誰でも利用・改変できる形で公開された技術）を採用すると、その技術を扱える会社が増え、特定ベンダーへの依存度が下がります。APIやデータの形式が標準化されている技術を選ぶことも、乗り換え時の障壁を下げます（マネーフォワード クラウドERP）。
2つ目はソースコードとドキュメントの権利を確保することです。システムの設計図にあたるソースコードと、その仕様を記したドキュメントが発注者の手元に残れば、別の会社に引き継ぐことが現実的になります。ソースコードを含め、著作権・所有権がベンダーと自社のどちらにあるのかを契約時に明確にしておくことが重要です。この点は技術の話というより契約の話なので、発注者が主導して確認すべき領域です。
3つ目はデータの可搬性を確保することです。システムに蓄積されるデータ（顧客情報や取引履歴など）を、標準的な形式で取り出せるようにしておけば、たとえシステムを乗り換えても資産であるデータを引き継げます。
ベンダーロックインの全体像と回避策については、ベンダーロックインとは？発注者が知るべきリスクと回避策で詳しく解説しています。技術選定とあわせて確認しておくと、予防の精度が上がります。
技術選定のミスが後から発覚した場合の対処
ここまでは、これから技術選定に関わる発注者に向けた予防の話でした。けれど、すでに発注済みで開発が進んでいたり、運用が始まってから「選んだ技術がまずかったかもしれない」と気づいたりする方もいるでしょう。その場合でも、打てる手はあります。大切なのは、過去の判断を悔やむのではなく、これからの損失を最小化する動き方に切り替えることです。
まず確認すること｜影響範囲と原因の切り分け
「技術選定を間違えたかも」と感じたとき、いきなり作り直しを考えるのは早計です。まず、問題の影響範囲と原因を切り分けることから始めます。
確認したいのは次の点です。
- 何が実際に困っているのか：保守費が高いのか、改修ができないのか、性能が出ないのか、乗り換えられないのか。漠然とした不安なのか、具体的な実害が出ているのかを区別します
- 原因は本当に技術選定なのか：問題の原因が技術そのものにあるのか、それともベンダーの体制や進め方にあるのかを見極めます。技術を変えても解決しない問題であれば、作り直しは無意味です
- 影響範囲はどこまでか：システム全体の問題なのか、一部の機能に限った問題なのか。範囲が限定的なら、部分的な対応で済む可能性があります
この切り分けは、社内に技術者がいなければ難しいかもしれません。その場合は、後述するセカンドオピニオンの活用が有効です。
取りうる選択肢と判断基準
影響範囲が見えてきたら、対応の選択肢を検討します。現実的には、次の3つの方向性があります。
1. ベンダーへの相談・部分改修 まずは現在のベンダーに、困っている点を具体的に伝えて相談するのが基本です。問題が一部の機能や設定に限られるなら、部分的な改修で解決できることもあります。このとき、感情的に責めるのではなく「この課題を解決するには何が必要か」と建設的に問いかけると、対応を引き出しやすくなります。
2. セカンドオピニオンの活用 現在のベンダーの説明に納得できない、あるいは社内に判断材料がない場合は、別の開発会社や第三者の専門家に意見を求めるセカンドオピニオンが有効です。医療と同じく、利害関係のない第三者の視点は、問題の本質と現実的な選択肢を明らかにしてくれます。「今の技術選定は妥当か」「作り直しは本当に必要か」を客観的に判断する材料になります。
3. 全面リプレース（作り直し） 技術選定が事業の足かせになっており、部分改修では解決できないと判断した場合は、システムの全面的な作り直し（リプレース）も選択肢になります。ただしこれは最もコストの大きい選択なので、次の基準で慎重に判断します。
- 現状維持を続けた場合の累積コスト（高止まりする保守費など）が、作り直しの費用を上回るか
- 事業の成長や変化に、現在のシステムが対応できなくなっているか
- 乗り換え可能な技術・ベンダーが確保できる見通しがあるか
これらが揃って初めて、リプレースは合理的な選択になります。逆に、感情的な不満だけでリプレースに踏み切ると、新たなロックインを生むだけに終わりかねません。
技術選定に限らず、システム開発でつまずく原因の多くは発注側の判断にあるとも言われます。事後対応を考える前に、システム開発の失敗、原因の8割は発注者の判断ミスで典型的なパターンを確認しておくと、同じ失敗を繰り返さずに済みます。
まとめ｜発注者は「技術」ではなく「判断軸」を持てばよい
技術選定というと、発注者にとっては「専門家に任せるしかない領域」に見えがちです。けれど本記事で見てきたように、発注者に求められるのは技術そのものを理解することではなく、技術選定の妥当性を確認する判断軸を持つことです。
最後に、本記事の要点を整理します。
- 発注者の関与範囲：技術の優劣はベンダーに任せてよい。確認すべきは「その技術選定が事業にどう影響するか」
- 3つの非機能要件：コスト（初期費用に隠れたランニング・ライセンス費）、保守性（改修のしやすさ・ドキュメント・属人化の回避）、採用市場と乗り換えやすさ（その技術を扱える人材・会社の多さ）
- ベンダーへの5つの質問：選定理由・継続コスト・扱える人材・権利の帰属・引き継ぎ可能性。回答の姿勢から赤信号を読み取る
- ロックインの予防：オープンな標準技術の採用、ソースコードとドキュメントの権利確保、データの可搬性
- ミスが発覚した場合：まず影響範囲と原因を切り分け、部分改修・セカンドオピニオン・リプレースを基準に沿って判断する
技術名を覚える必要はありません。コスト・保守性・乗り換えやすさという3つの軸を持ち、ベンダーに具体的に質問できれば、技術選定に主体的に関与できます。「お任せします」から「根拠を持って合意する」へ。その一歩を踏み出すための判断軸が、本記事から持ち帰れていれば幸いです。
技術選定の次のステップとして、そもそも信頼できるベンダーをどう選ぶかが気になる方は、システム開発のベンダー選定基準6項目もあわせてご覧ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
