技術選定の失敗を防ぐ基準｜CTOのいない会社が、新しさや安さより先に確認すること

技術選定の失敗は、新しさや安さだけで選ぶことから起きます。社内にCTOのいない中小企業・スタートアップの経営者に向けて、「担当者が替わっても扱えるか」「移行時の費用」「自社の強みに関わるか」の3つの基準と、見積もりで確認する点を実例とともに解説します。

2026年10月30日

執筆者

運営者・AIエンジニア／ IT歴36年以上

技術選定の失敗を防ぐ基準｜CTOのいない会社が、新しさや安さより先に確認すること

要約

技術は「新しいか」「安いか」ではなく、「担当者が替わっても、ほかの人が扱えるか」で選びます。
安さで業者やサービスを選ぶときは、あとでほかのサービスへ移行する費用も、見積もりの段階で試算します。
自社の強みに関わらない業務は既存のサービスを利用し、他社との差別化につながる部分だけを自社で開発します。

システムを開発するとき、外注先から「今はこの技術が主流です」と新しい技術を勧められることがあります。最も安い見積もりに注目することもあるでしょう。社内に技術責任者（CTO：技術の最高責任者）がいない会社では、その提案が自社に合っているかを判断できる人がいません。

IPA（情報処理推進機構）は「DX動向2025」で、DXを進める人材の過不足を調べています。DXとは、デジタル技術で業務や事業の進め方を変革することです。人材が「やや不足している」「大幅に不足している」と答えた日本の企業は、合わせて85.1%でした。また、DXを進める人材の確保に取り組んでいないと答えた企業も、19.4%ありました。技術の分かる人が社内にいないまま、技術を選ぶ判断を迫られる会社は珍しくないのです。

この記事では、技術責任者のいない会社が技術を選ぶとき、新しさや安さではなく何を基準に決めるかをまとめます。この基準は、私自身がシステムを開発して運用し、事業を売却するまでの経験から定めたものです。

技術選定とは何か、どこで失敗するのか

技術選定とは、システムの開発に使用する技術を決定することです。対象は、プログラミング言語やフレームワーク、データベース、外部のサービスなどです。フレームワークは、プログラムを作るときの基礎になる部品と作法の集まりです。データベースは、顧客情報や取引の記録を保存しておく仕組みです。

技術選定の失敗は、選んだ時点では見えません。CTOのいない会社で私が何度も見てきたのは、次のような場合です。経営者が技術的に妥当かを判断できないまま、外注先の提示した金額や説明を受け入れてしまいます。そして数年後に、保守費用が高すぎることや、システムを思うように変更できないことが分かります。保守費用とは、システムを動かし続けるための修正や点検の費用です。

システムを理解している人が社内に1人だけで、その人の退職後に誰も扱えなくなった例も、私は複数見てきました。どちらも、技術の良し悪しより、選び方の問題です。

何を基準に選ぶか

基準は、「担当者がいなくなっても事業を継続できるか」です。私は具体的に、次の3つで判断しています。

基準	確認すること	私の経験
誰でも扱えるか	扱える人を採用しやすいか、資料が多いか、社内の体制で管理できるか	ASP事業（広告主とサイト運営者を仲介する事業）で、長く使われてきた技術を選び、担当者が替わってもシステムが止まらなかった
移行時の費用	その業者やサービスからほかへ移行するとき、どれだけの費用がかかるか	動画配信システムで、費用の安さだけでデータベースを選んだ。別のデータベースへ移行するとき、大規模な再構築が必要になった
自社の強みに関わるか	その部分が他社との差別化につながるか	経理や勤怠管理は既存のサービスを利用し、ASPの課金の仕組みと広告配信の仕組みは自社で開発した

この考え方を強く意識するようになったきっかけは、日本でライブドアへの事業譲渡を交渉した経験です。相手は技術面の審査で、次の3点を重点的に確認しました。1つ目はシステムの権利関係で、自社開発か、ライセンスを受けた製品かという点です。2つ目は、特定の個人しか扱えない部分がないかという点です。3つ目は将来の拡張性で、機能や利用者が増えたときに拡張できるかという点です。

なかでも、担当者が退職しても事業を継続できるかという視点は、その後の私の組織づくりを大きく変えました。技術を選ぶときも、最初に考えるのはこの点です。

「誰でも扱えるか」はどう確認するか

技術者の人数と資料の量、そして社内で実際にそのシステムを運用する体制で確認します。

日本でASP事業を立ち上げたときの話です。ここでのASPは、広告を出したい会社とサイト運営者を仲介するアフィリエイトの事業を指します。当時は独自のフレームワークが流行していましたが、私は長く使われてきた LAMP 構成を選びました。LAMP 構成は、PHP や MySQL などを組み合わせた、Webシステムの定番の構成です。PHP はWebシステムを作るためのプログラミング言語で、MySQL はデータベースの1つです。

理由は2つありました。1つ目は、扱える技術者を集めやすいことです。2つ目は、資料が豊富で、特定の人しか分からない状態（属人化）が起きにくいことです。担当者が交代してもシステムは止まらず、数年以上の運用を経て事業を売却できました。新しさではなく「誰でも扱えるか」を基準にしたことは、正しい判断だったと考えています（実務ケース）。

15年ほど前、知人の起業家が HTML と CSS だけで複雑なサイトを運営していました。HTML と CSS は、Webページの内容と体裁を記述する言語です。社内に技術者がいなかったため、私は WordPress での作り直しを提案しました。WordPressとは、管理画面からページを作成・修正できるサイト構築の仕組みです。WordPress を勧めたのは、技術者がいなくても、複数の人で管理や作業を分担しやすいからです。

私自身は、開発では Next.js を主に利用しています。Next.js は、Webサイトやアプリを作るためのフレームワークです。それでも、技術者のいない会社には、技術者のいない体制で運用できるものを勧めます。自分が慣れているかどうかではなく、その会社で誰が扱うかで決めるのです。

「長く使われてきた技術」なら安心か

安心とは言い切れません。長く使われてきた技術にも、バージョンごとにサポート期限があります。

サポート期限（EOL）とは、提供元が修正や更新を終了する日のことです。期限が過ぎると、セキュリティ更新も止まります。セキュリティ更新とは、発見された弱点を解消する修正です。PHP の公式ページによると、各バージョンは、正式に公開されてから2年間、全面的にサポートされます。その後の2年間は、重大なセキュリティ問題だけが修正されます。4年が過ぎたバージョンはサポートが終わり、修正されない弱点が残るおそれがあります。

主な技術のサポート期限は、次のとおりです。

技術	提供元が示している期限
PHP（各バージョン）	正式に公開されてから2年間は全面サポート、その後の2年間は重大なセキュリティ問題だけ。4年でサポート終了
PHP 8.2	全面サポートは2024年12月31日まで、セキュリティのサポートは2026年12月31日まで（2026年10月30日時点の公式の表）
Node.js（JavaScript でWebシステムを動かす仕組み）の LTS バージョン	LTS は長期サポートのバージョンのこと。重大な不具合の修正を、通常は合計30か月保証
AngularJS（Webアプリを作るためのフレームワーク）	2022年1月にサポートを正式に終了
Flash Player（Webページで動画やゲームを動かすための仕組み）	2020年12月31日にサポート終了。2021年1月12日から、Adobe がコンテンツの再生そのものを停止した
Windows 10	2025年10月14日にサポート終了。最後のバージョンは 22H2

長く使われてきた技術を選ぶことと、古いバージョンのまま放置することは別です。PHP を選んでも、バージョンアップ作業は継続して必要です。登場した当時は新しかった AngularJS や Flash Player も、すでにサポートが終わっています。

AngularJS のサポートは2022年1月に終わりました。しかし、サポートが終わった日にその技術で作ったシステムが消えるわけではありません。どの技術を選んでも、バージョンアップ作業や、別の技術へ移行する作業はいつか必要になります。したがって確認すべきは新しさではなく、その作業を誰が引き継げるかです。

安さで選ぶと、なぜ後から費用が増えるのか

安さの理由が、必要な工程の省略や、ほかへ移行しにくい設計にあることが多いからです。

20年ほど前、ある知人の起業家は、ビジネスマッチングサイトを PHP と MySQL で安く作れたと喜んでいました。私がサイトを確認したところ、セキュリティ上の欠陥がいくつも見つかりました。結局は修正に費用がかかり、初めから適切に開発する場合より高額になりました。

私自身も、安さで失敗した経験があります。日本で動画配信の仕組みを開発した際、私はデータベースを費用の安さだけで選びました。その結果、特定のデータベースに依存した設計になりました。のちに別のサービスへ移行しようとしたところ、大規模な再構築が必要になったのです。このように、特定の業者やサービスから離れられなくなる状態を、ベンダーロックインと呼びます。それ以来、私は見積もりを受け取った時点で、乗り換えが難しくなった場合の費用を必ず計算しています（実務ケース）。特定の業者から離れられなくなる仕組みと解消の手順は、ベンダーロックイン対策で説明しています。

クラウドでは、低価格で利用できる条件も、移行時の費用も、提供元が決定します。クラウドとは、サーバー（システムを動かすコンピューター）などをインターネット経由で借りるサービスです。

Heroku: アプリケーションを稼働させる環境を提供するクラウドサービスです。2022年11月28日から、無料プランの提供を終了すると発表しました。使われていないアカウントと保存データを、2022年10月26日から削除するとも発表しました。
AWS: 大手のクラウドサービスです。インターネットへのデータ転送料は、月100GBまで無料です。データ転送料とは、クラウドから外部へデータを送信するときの料金です。2024年3月5日には、AWS からほかへ移行する利用者を対象に、この転送料の免除を始めました。EU 以外の利用者が免除を受けるには、180日以内に移行を終える必要があります。

無料や低価格で始めたサービスでも、条件は変わることがあります。移行時の費用も、サービスごとに扱いが異なります。利用を開始する前に、条件の変更と移行時の費用まで含めて確認しておく必要があります。

見積もりでは何を確認するか

金額の大小ではなく、工数を確認します。工数とは、作業にかかる人手と時間のことです。私が見積もりで確認している項目は、次のとおりです。

確認項目	確認内容
工数の配分	設計・実装・テスト・保守のそれぞれに、どれだけの工数を割いているか
極端に安い見積もり	テストや運用保守の工数が抜けていないか
高すぎる見積もり	要件が曖昧なまま、「念のため」の余裕が積まれていないか
保守費	開発費の何%という目安ではなく、費用に何が含まれているか
移行時の費用	特定の業者やサービスに依存した状態になったとき、移行にどれだけの費用がかかるか

私はサーバーの性能や容量も、「念のため」ではなく、実際に必要な量をもとに決めています。あるプロジェクトでは、サーバーの性能や容量が必要以上に高く設定されていました。そこで私は、実際のアクセスログをもとに構成を見直し、月額費用を約半分に抑えました。アクセスログとは、サイトへのアクセスを記録したデータです。「不安だから多めに」という感覚をやめ、実測のデータで決めたことがポイントでした。

自社で作るか、既存のサービスを利用するか

経理や勤怠管理など、他社との差がつかない業務については、私は迷わず SaaS を選びます。SaaS とは、完成したソフトウェアをインターネット経由で利用するサービスです。一方、顧客に提供する価値に直結する部分は、自社で開発します。ASP 事業では、課金の仕組みと広告配信の仕組みがそれにあたります。

私は、費用と時間をかける価値があるかを、他社との違いを生む部分かどうかで判断しています。他社と差がつかない部分は、SaaSなどを利用した方が便利です（実務ケース）。

経営者は外注先の提案をどう判断すればよいか

技術の内容を理解する必要はありません。「コスト」「リスク」「時間」の3つの観点で確認し直しましょう。

私は技術が分からない経営者に説明するとき、技術用語は避けて、この3つで話しています。クラウドへの移行を例にすると、初期費用は下がる一方で、毎月の固定費は上がります。その代わりに、障害が起きたときの対応が早くなります。このように整理して、経営判断の材料として示します。

外注先から技術の提案を受けたら、次の点を確認してください。

この技術を扱える人は、ほかにどれくらいいるか。担当者が替わっても、ほかの人が扱えるか
別の業者やサービスに移行するとき、どれだけの費用と作業がかかるか
見積もりで、設計・実装・テスト・保守の工数の配分はどうなっているか。保守に何が含まれるか
システムの権利は誰にあるか（自社開発か、ライセンス製品か）
将来、機能や利用者が増えたときに拡張できるか

外注先が回答に詰まる項目があれば、その項目が将来のリスクになります。

よくある質問

Q: 新しい技術は選ばないほうがよいですか。

新しいこと自体は、選ぶ理由にも、避ける理由にもなりません。基準は、扱える人を採用しやすいか、資料が多いか、社内の体制で管理できるかです。私も開発では Next.js を主に利用しています。

Q: 社内にシステムの分かる社員が1人います。その社員に任せてよいですか。

任せること自体は問題ありません。ただし、その社員しか扱えない技術や作りは避けましょう。システムを理解している人が1人しかおらず、その人の退職後に誰も扱えなくなった例を、私は複数見てきました。

Q: 今のシステムが、どの技術で動いているのか分かりません。

まず、現状の可視化から始めます。私は以前、資料が一切ないシステムを引き継いだことがあります。ソースコード（プログラムの本文）には、コメント（プログラムに書き添える説明）もほとんどありませんでした。そのため、コードを読み解くことから始めるしかありませんでした。それ以来、私は引き継ぎの案件で、現状を可視化する調査を最初に行っています。利用している技術とバージョンが分かれば、サポート期限も確認できます。担当者の在籍中に残しておく資料は、記事「システムのブラックボックス化とは」で説明しています。

まとめ

技術選定の失敗は、選んだ時点では見えません。あとになって、高い保守費用や変更しにくいシステムとして表れます。
技術は、新しさではなく「担当者が替わっても、ほかの人が扱えるか」で選びます。ここでの「ほかの人」は、社内で実際にシステムを扱う人です。
長く使われてきた技術にもサポート期限があります。バージョンアップ作業や移行作業を、後から誰が担えるかを確認しておきます。
安さで選ぶときは、工数の配分と、その業者やサービスからの移行費用を、見積もりの段階で確認します。
他社との差別化につながらない業務は既存のサービスを利用し、差別化につながる部分だけを自社で開発します。

無料相談のご案内

PH Tech AI は、技術責任者がいない中小企業・スタートアップを支援しています。支援するのは、技術の判断と開発体制づくりです。外注先から提案された技術や見積もりが自社に適しているか、担当者が替わっても事業を継続できる体制になっているかを、一緒に整理します。無料でご相談いただけます。まずはお気軽にお問い合わせください。