開発会社の技術力、提案書だけで見抜けるのか
複数の開発会社から提案を受け、実績も豊富そうだし、担当者の説明もそつがない。それなのに「この会社、本当に技術力があるのだろうか」という疑問だけが消えずに残る。そんな経験をしたことがある現場責任者は少なくないはずです。見積書の金額は比較できても、技術力という項目には点数がついていません。
実はこの疑問が消えない理由は、評価する側の知識不足というより、技術力そのものが「比較できる形」で提示されにくいという構造にあります。実績一覧やパンフレットの言葉だけでは、目の前の案件に対応できる力があるのかどうかを判断する材料が足りていないのです。
この記事では、なぜ技術力が外から見えにくいのか、その理由を整理したうえで、提案段階・面談段階で確認できる具体的な観点を紹介します。
なぜ技術力は「比較しにくい項目」なのか
見積もりの金額や納期であれば、数字として並べて比較できます。しかし技術力は「高い・低い」を示す共通の物差しがありません。使用している言語やフレームワークの名前が並んでいても、それが自社の案件にどう活きるのかは、名前だけでは判断がつかないのが実情です。
加えて、提案書や営業担当者の説明は、どうしても「できます」という前向きな言葉で埋まりやすい傾向があります。できないことや苦手な領域をわざわざ強調する提案書は少なく、結果として発注側には「良い面しか見えない」状態で判断材料が渡されることになります。これは営業担当者が不誠実というより、提案という場の性質上、そうなりやすいという構造の問題です。ここは、提案書を読むときに頭の片隅に置いておきたいところです。
さらに、実績として提示される案件の多くは守秘義務の関係で詳細を公開できず、「〇〇業界向けシステム開発」といった抽象的な記載にとどまります。似たような業界の実績があっても、自社が抱えている課題と本当に重なる部分があるのかどうかは、提示された一覧だけでは確認しきれません。
「できます」という言葉の中身を分解してみる
技術力を見極めようとするとき、つい「どんな技術を使っているか」という点に目が向きがちです。しかし実務上もっと重要なのは、その技術をどう使って過去の課題を解決してきたか、という部分です。
技術の「幅」と「深さ」は別の話
対応できる言語やツールの種類が多いことと、特定の技術を深く理解して難しい要件に対応できることは、別の能力です。幅広い対応をうたう会社が、自社案件特有の複雑な要件にも強いとは限りません。逆に専門領域を絞っている会社の方が、特定の課題に対しては的確な提案をしてくることもあります。
過去の失敗やトラブル対応をどう語るか
技術力が高い会社ほど、過去にトラブルが起きた案件の話を、隠さずに説明できる傾向があります。問題が起きたときにどう原因を特定し、どう修正したかという具体的なプロセスを語れるかどうかは、表面的な実績一覧よりも実務力を映す材料になります。「トラブルは一度もありません」という回答より、「こういう問題が起きて、こう対応しました」という回答の方が、実務上は信頼材料になりやすいところです。
提案書・面談で確認しておきたい観点
技術力そのものを数値化することは難しくても、確認の仕方を工夫することで判断材料を増やすことはできます。
- 担当予定者と話す場を設けてもらう:営業担当者の説明だけでなく、実際に手を動かすエンジニアやプロジェクトマネージャーと直接話す機会を作ってもらうと、技術的な質問への答え方から実務レベルの理解度が見えてきます
- 類似案件での課題と対応を具体的に聞く:「似たような案件はありますか」ではなく「その案件でどんな技術的な壁にぶつかり、どう解決したか」を聞くと、抽象的な実績紹介より多くの情報が得られます
- 設計書やテスト計画のサンプルを見せてもらう:成果物そのものは守秘義務で見せられなくても、過去案件で使った設計書やテスト計画のフォーマット(体裁)であれば提示できる会社も多く、ドキュメントの作り込み方から力量の一端がうかがえます
- 非機能要件への感度を確認する:性能やセキュリティ、保守性といった、画面には現れない要件についてどこまで突っ込んだ質問を返してくるかも、技術力を測る一つの手がかりになります
経済産業省が公表している「情報システム・モデル取引・契約書(第二版)」では、受発注者間の取引の適正化を目的として、契約締結前の体制確認や役割分担の明確化が重要な論点として整理されています。契約を結ぶ前の確認作業は、技術力という見えにくい項目を補う実務上の手段として位置づけられます。
なお、技術力の見極めは単体の論点ではなく、見積もりの前提条件や要件定義の粒度とも密接に関わっています。技術力が高くても要件の伝え方が曖昧であれば、結果として実力が発揮されないこともあるため、見積もり比較前に確認したい「要件の粒度」の話も合わせて確認しておくと、判断材料がさらに整理しやすくなります。
まとめ
- 技術力は金額のように比較しやすい数字で示されにくく、提案書の言葉だけでは判断材料が不足しがちという構造があります
- 技術の「幅」と「深さ」は別物であり、過去のトラブル対応をどう語るかが実務力を映す材料になります
- 担当予定者との面談、類似案件の具体的な対応内容、ドキュメントのサンプル確認などを通じて、提案書だけでは見えない情報を補うことができます
執筆
サイバーコネクト編集部
誇張や決めつけを避け、現場で実際に判断材料になる情報だけをお伝えします。
監修
しんすけ
PM
株式会社サイバーコネクトのPMとして、要件定義・進行管理・品質管理を担当。オフショア(フィリピン)チームが担う実装フェーズの成果物について、日本側で最終品質チェックを行う体制の運用に携わっている。前職ではホームページ制作会社に勤務し200件を超えるホームページを制作。
まずはお話をお聞かせください。
要件が整理されていない段階でもご相談いただけます。
関連記事
「動けばいい」で進めた開発が後で重くなる理由
「動けばいい」で進めた開発がなぜ後の見積もりを膨らませるのか。技術的負債の仕組みと発注側が確認すべき観点を整理します。
担当エンジニアが辞めたらプロジェクトは止まるか
担当エンジニアの退職でプロジェクトが止まるのではという不安を、属人化の構造から整理し、発注側が事前にできる備えを解説します。
フリーランス発注、退職リスクをどう見るか
フリーランスエンジニアが突然いなくなったら、という不安を「契約」と「情報管理」の視点から整理し、事前の備えと離脱後の選択肢を解説します。
情報の取り扱いと免責:本記事は一般的な情報提供を目的としており、個別の状況に対する助言ではありません。 統計・数値等は出典を明記したもの以外は掲載していません。内容は公開時点の一般的な傾向を示すものであり、 実際の発注・契約にあたっては個別の事情に応じて専門家・取引先とご確認ください。