RFPや要件定義書には、「Go」という技術名よりも、Goが活きる要件を書きます。この考え方は、Goでの開発を外注するとき、あるいは社内から「Goを使いたい」という要望が出たときに役立ちます。並行性・性能・耐障害性・拡張性のうち複数が当てはまれば、Goは有力な候補になります。
Go開発の全体像をまだ把握していない方は、まずGo開発の完全ガイドから読むのがおすすめです。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
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を採用要件にするなら、その人材をどう確保するか」を要件定義の段階で考えておくべきです。
モダン技術の採用が、優秀なエンジニアの採用・定着のブランディングになるという経営視点も、要件として明文化する価値があります。
採用と保守の観点では、次の2つを要件に書いておくとよいです。
- 採用の見通し：その言語のエンジニアを確保しやすいか、相場の単価はいくらか
- 内製化や保守の引き継ぎ：社内や別のチームが、将来このコードを保守できるか
発注側が書き込むべきは、目先の開発しやすさだけでなく、5年後に誰がこのコードを保守するかです。内製化のしやすさやリモート可否といった人材の観点を要件定義書に書いておけば、技術選定と採用戦略がそろい、長期で破綻しにくくなります。
TCOと通信方式の要件化
発注者が見落としがちなもう一つの非機能要件が、TCO（総保有コスト）です。初期の開発費だけでなく、インフラ費用、保守費用、フレームワークやライブラリのバージョンアップ費用までを、5年スパンで見積もる必要があります。
Goはシングルバイナリでリソース効率が良く、サーバー費用やデプロイ運用を抑えやすい一方、エンジニア単価や移行コストは別途かかります。
発注側は、要件定義書に「5年TCOの内訳を提案に含めること」と明記すれば、各ベンダーの提案を費用面で比較できます。
もう一つ要件に書くべきは、内部通信の方式です。マネーフォワードは、帳票APIにgRPC、マスタAPIにRESTと、用途で使い分けています。
内部通信にgRPCを使う構成では、APIレイテンシを10〜50msに抑えています（媒体：Findy Engineer Lab）。
RESTのレイテンシが50〜200msであることを踏まえると、内部通信の速さが要件なら、gRPCを使うかどうかを要件定義の論点に含めるべきです。
外部公開APIでキャッシュやブラウザ互換を重視するなら、RESTが妥当になります。
要件定義書には、次の2点を書き込んでおくとよいです。
- 費用：インフラ・保守・バージョンアップを含む、5年分の見積もり
- 通信方式：用途ごとの方式と、選んだ根拠
こうした非機能要件を書いておくと、ベンダーの提案を費用と性能の両面から検証できます。発注側がこの非機能要件を主導することが、後悔しない技術選定の核心です。
ロックイン回避と引き継ぎ性のRFP条項
技術選定の要件と並んで、発注側の長期リスクを左右するのが「ベンダーロックインの回避」と「引き継ぎ性の確保」です。これらは技術そのものより、RFPと契約に何を書くかで決まります。
別の会社へ引き継げる状態を保つために、RFPや要件定義に盛り込むべき条項を見ていきます。
コーディング規約とドキュメント納品の必須化
引き継ぎ性を決めるのは、実は技術選定そのものよりも、コーディング規約の順守と設計ドキュメントの納品、そしてインフラが属人化していないかどうかです。
Goはgofmt（フォーマッタ）が標準で備わり、コードの書式が自動で統一されるため、他言語に比べて属人化しにくい特性があります。
あわせて、設計ドキュメント、API仕様書、インフラ構成図の納品も要件に含めます。
Baseconnectの事例では、移行時にDIコンテナ「dicon」やモック自動生成ツール（impast/mocker）を整備しています。また、Response Layerでレスポンスの型を明確にしています（媒体：Baseconnect Tech blog）。
設計の意図がドキュメントに残り、テストも整っていれば、別のチームでも保守を引き継げます。逆に、コードだけ納品されてドキュメントもテストもない状態では、どんなに優れた技術でも引き継ぎは困難になります。
RFPには、次の2点を盛り込みます。
- 規約：Goの標準フォーマットと、合意したコーディング規約に従う
- 納品物：ソースコードに加え、設計ドキュメント、API仕様、テストコード、インフラ構成
RFPに条項を書いておくだけで、ベンダーロックインのリスクは下がります。
技術を選ぶ前に、引き継げる状態を契約で担保する——これが発注スキルの核心です。
保守契約とバージョンアップ責任の取り決め
「納品されたら数年そのまま使える」という発注側の思い込みは危険です。Go本体も依存ライブラリも定期的にバージョンアップが必要で、これを怠るとセキュリティリスクが蓄積します。
要件定義の段階で、「リリース後の保守範囲」「バージョンアップを誰がいくらで継続するか」「脆弱性が見つかった際の対応フロー」を取り決めておくことが不可欠です。
他言語の例では、Laravel 13が2026年3月にリリースされ（必要PHPは8.3以上）、Django 6.0は2025年12月にリリースされています。
また、Java 25 LTSも2025年9月にリリースされました。フレームワークや言語のメジャーアップデートは継続的に発生します（媒体：Wikipedia／アットエンジニア）。
Goも例外ではありません。バージョンアップを放置すると、サポート終了（EOL）に伴うセキュリティリスクを抱えるうえ、新しいライブラリが使えなくなり技術的負債も積み上がります。
これを誰が、どの頻度で、いくらで行うかを保守契約に落とし込むことが、長期リスクを管理する要件定義の役割です。
保守契約では、次の2点を取り決めておきます。
- 保守範囲：リリース後に、どこまでを誰が受け持つか
- バージョンアップ：頻度と費用、脆弱性が見つかったときの対応の流れ
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作りを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。