Goでの開発を外注しようとするとき、あるいは「Goを使いたい」という要望が社内から出たとき、発注側がつまずきやすいのが「RFP（提案依頼書）や要件定義書に、Goという技術選定をどう書き込めばよいのか」という点ではないでしょうか。多くの発注者は機能要件（何を作るか）は書けても、「なぜGoなのか」「Goを採用する要件は自社に揃っているか」という技術選定の要件を言語化できず、ベンダー任せにしてしまいがちです。その結果、性能が要らない領域に過剰にGoを使ったり、逆にGoの強みを活かせない構成になったりと、後から後悔する技術選定に陥ります。
本記事は、Goの採用をRFP・要件定義書・提案依頼書にどう落とし込むかを、発注側・長期リスクの視点から解説する「要件定義特化」の内容です。Goを採用すべき要件（並行性・性能・耐障害性・拡張性）の言語化、採用市場やTCOといった発注者だからこそ書くべき非機能要件、そしてベンダーロックインを避けるためにRFPへ盛り込むべきコーディング規約・ドキュメント納品・保守契約まで、マネーフォワードやBaseconnectの国内事例の知見も交えて整理します。読み終えるころには、「Goでお願いします」ではなく「これこれの要件があるからGoが妥当だ」と書ける状態になります。なお、Go開発の全体像をまだ把握していない方は、まずGo開発の完全ガイドから読むことをおすすめします。
RFPに書くのは「Go」ではなく採用要件
RFPや要件定義書で技術選定を扱うとき、発注側が陥りやすい罠が「Goで作ってください」と技術名を先に固定してしまうことです。本来書くべきは技術名ではなく、その技術が解決すべき要件です。ここでは、Goが活きる要件をどう言語化し、なぜ技術名の固定が危険なのかを解説します。
技術名を要件に固定してはいけない理由
「Goで開発してほしい」とRFPに書くと、一見すると要件が明確になったように見えます。しかし実際には、発注側が技術を固定することで、ベンダーは「なぜGoなのか」を考えずに言われた通り作るだけになります。もしその要件にGoが過剰であれば、開発速度が落ち、コストが膨らみます。逆にGoが不足なら、後で性能の壁にぶつかります。技術の妥当性を判断する責任が、発注側に丸ごと乗ってしまうのです。
正しいRFPの書き方は、「想定する同時アクセス数」「許容するレスポンス時間」「将来の機能拡張やトラフィック増の見込み」「非同期処理の要否」といった要件を数値や条件で示し、「これらを満たす技術構成を提案してください」と問う形です。こうすれば、複数のベンダーが各自の根拠でGoや他言語を提案してくるため、提案内容を比較して妥当性を判断できます。技術選定はベンダーの腕の見せ所であり、要件は発注側の責任という役割分担が、健全な発注を生みます。
もちろん、社内に既存のGo資産があり標準化したい、といった明確な理由があれば技術を指定しても構いません。その場合も「なぜGoを指定するのか」の理由をRFPに明記しておくと、ベンダーは前提を理解したうえで最適な設計を提案できます。重要なのは、技術名を「思考停止のラベル」にしないことです。
Goが妥当になる4つの採用要件を言語化する
では、どんな要件が揃ったときにGoが妥当な選択になるのか。要件定義書には、次の4つの観点を具体的に書き込むとよいでしょう。
1. 並行性：通知・バッチ・集約など、同時に多数の処理をさばく要件があるか
2. 性能：CPU/メモリ効率やレスポンス時間に厳しい要求があり、既存言語で限界が見えているか
3. 耐障害性：一部が落ちても全体が止まらない設計が必要か（決済・通知などの基幹的な非同期処理）
4. 拡張性：マイクロサービス化や内部API連携を前提とし、サービスを分割していく見込みがあるか
これらが複数当てはまるなら、Goは有力な候補になります。
ウォンテッドリーがAmazon SNS＋Goでお知らせ機能の耐障害性を高めた事例（媒体：Findy Engineer Lab）や、BaseconnectがRailsからGoへ移行してBFFを構築した事例（媒体：Baseconnect Tech blog）は、いずれも上記の要件が揃った典型例です。逆に、同時実行性が低く性能要求も緩い管理画面やコーポレートサイトでは、これらの要件がほとんど立たないため、RailsやLaravelの方が開発速度で有利になることもあります。
要件定義の段階でこの4観点を自社の言葉で埋めておけば、「Goを使うべきか」という問いに自分たちで答えられるようになります。ベンダーの提案を鵜呑みにするのではなく、要件と照らして妥当性を検証できる状態を作ることが、技術選定の主導権を発注側に取り戻す第一歩です。
発注者が書くべき非機能要件とTCO
機能要件（何を作るか）はベンダーも気にかけますが、発注者が能動的に書かないと抜け落ちやすいのが非機能要件です。とくに採用市場・TCO・通信方式は、長期の事業運営に直結するにもかかわらず、要件定義書から漏れがちです。ここでは、発注者だからこそ書くべき非機能要件を整理します。
採用市場・定着を要件に織り込む
技術選定は、開発のしやすさだけでなく「その技術のエンジニアを将来どれだけ確保・定着できるか」という採用戦略と切り離せません。将来的に内製化や保守の引き取りを見据えるなら、その言語のエンジニアが採用市場で確保しやすいか、相場の単価はいくらかを要件定義の前提として把握しておく必要があります。たとえばPythonエンジニアの1人月相場はジュニア55〜75万円、ミドル75〜110万円、シニア110〜160万円とされ（媒体：ripla）、Django案件のフリーランス平均年収は905万円・案件の88.7%がリモートというデータもあります（媒体：INSTANTROOM）。
Goは比較的新しい言語で文法がシンプルなため学習コストが低く、モダン技術を好むエンジニアからの人気が高い一方、母数はRubyやPHPに比べてまだ限られます。だからこそ、「Goを採用要件にするなら、その人材をどう確保するか」までを要件定義で考えておくべきです。モダン技術を採用することが優秀なエンジニアの採用・定着のブランディングになる、という経営視点も、要件として明文化する価値があります。
発注側への示唆は、「目先の開発しやすさだけでなく、5年後に誰がこのコードを保守するか」を要件に織り込むことです。内製化のしやすさ、採用単価、リモート可否といった人材の観点を要件定義書に書いておけば、技術選定が採用戦略と整合し、長期で破綻しにくくなります。
TCOと通信方式を要件定義に明記する
発注者が見落としがちなもう一つの非機能要件が、TCO（総保有コスト）です。初期の開発費だけでなく、インフラ費用、保守費用、そしてフレームワークやライブラリのバージョンアップ費用までを5年スパンで見積もる必要があります。Goはシングルバイナリでリソース効率が良く、サーバー費用やデプロイ運用を抑えやすい一方、エンジニア単価や移行コストは別途かかります。要件定義書に「5年TCOの内訳を提案に含めること」と明記すれば、各ベンダーの提案を費用面で比較できます。
もう一つ要件に書くべきが、内部通信の方式です。マネーフォワードは帳票API=gRPC・マスタAPI=RESTと用途で使い分け、gRPCを内部通信に使うことでAPIレイテンシを10〜50msに抑えています（媒体：Findy Engineer Lab）。RESTのレイテンシが50〜200msであることを踏まえると、内部通信の速さが要件なら、gRPCを使うかどうかを要件定義の論点に含めるべきです。逆に外部公開APIでキャッシュやブラウザ互換を重視するなら、RESTが妥当になります。
これらの非機能要件は、要件定義書に一行入れておくだけでベンダーの提案の質が変わります。「TCOを5年で示す」「内部通信の方式と根拠を提案する」と書くことで、技術の妥当性を費用と性能の両面から検証できるようになります。発注側がこの非機能要件を主導することが、後悔しない技術選定の核心です。
ロックイン回避と引き継ぎ性のRFP条項
技術選定の要件と並んで、発注側の長期リスクを左右するのが「ベンダーロックインの回避」と「引き継ぎ性の確保」です。これらは技術そのものより、RFPと契約に何を書くかで決まります。ここでは、別会社へ引き継げる状態を保つために、RFP・要件定義に盛り込むべき条項を解説します。
コーディング規約とドキュメント納品を必須化する
引き継ぎ性を決めるのは、実は技術選定そのものよりも、コーディング規約の順守と設計ドキュメントの納品、そしてインフラが属人化していないかどうかです。Goはgofmt（フォーマッタ）が標準で備わり、コードの書式が自動で統一されるため、他言語に比べて属人化しにくい特性があります。この強みを活かすためにも、RFPには「Goの標準フォーマットおよび合意したコーディング規約に従うこと」を明記しておくべきです。
あわせて、設計ドキュメント・API仕様書・インフラ構成図の納品を要件に含めます。Baseconnectが移行時にDIコンテナ「dicon」やモック自動生成ツール（impast/mocker）を整備し、Response Layerでレスポンスの型を明確にした事例（媒体：Baseconnect Tech blog）が示すように、設計の意図がドキュメント化され、テストが整っていれば、別のチームでも保守を引き継げます。逆に、コードだけ納品されてドキュメントもテストもない状態では、どんなに優れた技術でも引き継ぎは困難になります。
発注側への教訓は明確です。「納品物にソースコードだけでなく、設計ドキュメント・API仕様・テストコード・インフラ構成を含めること」をRFPに書くだけで、ベンダーロックインのリスクは大きく下がります。技術を選ぶ前に、引き継げる状態を契約で担保する——これが発注スキルの核心です。
保守契約とバージョンアップ責任を取り決める
「納品されたら数年そのまま使える」という発注側の思い込みは危険です。Go本体も、依存ライブラリも、定期的にバージョンアップが必要で、これを怠るとセキュリティリスクが蓄積します。要件定義の段階で、「リリース後の保守範囲」「バージョンアップを誰がいくらで継続するか」「脆弱性が見つかった際の対応フロー」を取り決めておくことが不可欠です。
他言語の例を見ると、Laravelは13が2026年3月リリース（必要PHP 8.3以上）、Djangoは6.0が2025年12月、Java 25 LTSが2025年9月リリースと、フレームワークや言語のメジャーアップデートは継続的に発生します（媒体：Wikipedia／アットエンジニア）。Goも例外ではありません。バージョンアップを放置すれば、サポート終了（EOL）に伴うセキュリティリスクや、新しいライブラリが使えなくなる技術的負債を抱えます。これを「誰の責任で、どの頻度で、いくらで」行うかを保守契約に落とし込むことが、長期リスクを管理する要件定義の仕事です。
riplaは、フルスクラッチ受託と国内開発の立場から、技術選定の要件化だけでなく、ドキュメント納品・保守契約・バージョンアップ方針までをRFP段階から一緒に整理します。Goの機能・特性そのものを採用要件へどう翻訳するかは、後述の機能に関する関連記事で詳しく解説しています。要件と機能を行き来しながら、自社に最適な技術選定を固めてください。
まとめ
GoのRFP・要件定義書・提案依頼書で最も大切なのは、「Goで作ってください」と技術名を固定するのではなく、Goが活きる要件——並行性・性能・耐障害性・拡張性——を発注側の言葉で言語化し、それを満たす手段としてGoが妥当かをベンダーに提案させることです。ウォンテッドリーの耐障害性向上やBaseconnectのGo BFF構築は、これらの要件が揃ったときにGoが力を発揮する好例です（媒体：Findy Engineer Lab／Baseconnect Tech blog）。
さらに発注者は、採用市場（人材確保・単価・リモート）、5年TCO（インフラ・保守・バージョンアップ）、内部通信方式（gRPCは10〜50ms・RESTは50〜200ms）といった非機能要件を主導して書き、コーディング規約・設計ドキュメント納品・テスト・保守契約・バージョンアップ責任といった引き継ぎ性の条項をRFPに盛り込むべきです。これらを押さえれば、過剰なGo採用も、Goの強みを殺す構成も、ベンダーロックインも避けられます。riplaはフルスクラッチ受託と国内開発を組み合わせ、要件から逆算した技術選定と、引き継ぎ性まで担保したRFP作りを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。