top of page

システム開発会社を選ぶとき、実績だけでは分からない5つの確認ポイント

  • 2 日前
  • 読了時間: 9分

システム開発会社を選ぶとき、まず目に入るのは開発実績や対応技術です。しかし、実際に発注した後の進めやすさは、実績一覧だけでは分からない部分もあります。


特に確認したいのは、過去に何を作ったかだけでなく、今回の案件を誰がどのように判断し、どのような体制で進めるのかです。


事業会社の担当者とシステム開発会社の技術者が、業務システムの画面を見ながら開発方針を確認している様子

はじめに:似た実績があるだけでは、発注後の進め方までは分からない


システム開発会社のWebサイトを見ると、業務システム、Webサービス、クラウド、API連携など、さまざまな開発実績が掲載されています。


自社が依頼したい内容に近い実績があることは、開発会社を選ぶうえで重要な判断材料です。


ただし、「似たシステムを作ったことがある」という情報だけでは分からないこともあります。


たとえば、その案件で要件整理から担当したのか、実装の一部分だけを担当したのかでは、経験の意味が異なります。


また、提案時には経験豊富な担当者が説明していても、実際の開発が始まった後に誰が技術判断をするのかは、別の話です。


発注先を選ぶときは、会社全体の実績を見るだけでなく、今回の案件が実際にどのように進むのかまで確認しておくと、発注後の認識違いを減らしやすくなります。



結論:会社規模より、技術判断と品質管理が機能する体制かを見る


発注前にすべての社内事情を細かく確認する必要はありません。


システム開発会社を比較するときは、次の5点を見ると、その会社の仕事の進め方が見えやすくなります。


  1. 近い実績で、実際にどこまで担当したのか


  2. 提案時の説明と、実際の開発体制がつながっているか


  3. 技術的な判断について理由を説明できるか


  4. 特定の人しか分からない状態にならない進め方か


  5. 協力会社や外部エンジニアを利用する場合、誰が技術と品質に責任を持つのか


会社の人数や規模そのものを比較するのではなく、今回の案件に対して、必要な技術判断と品質管理が機能する体制になっているかを見ることがポイントです。



発注前に確認したい5つのポイント


1. 近い実績で「実際にどこまで担当したか」


「似たシステムの開発実績があります」という説明を受けたら、もう一歩だけ具体的に確認してみます。


たとえば同じ業務システムの開発でも、


  • 要件整理や設計から担当した


  • バックエンド部分を担当した


  • 既存システムの一部機能だけを改修した


  • 他社が設計した仕様に沿って実装した


では、経験している内容が異なります。


重要なのは、実績の件数そのものよりも、今回依頼したい仕事と、その会社が過去に担った役割が近いかです。


発注前には、


「今回と近い案件では、どの部分を担当しましたか」


と聞いてみると、実績の中身を確認しやすくなります。


2. 提案時の説明と、実際の開発体制がつながっているか


商談や提案の段階では、経験豊富な担当者が説明してくれることがあります。

そのこと自体は問題ありません。


確認しておきたいのは、開発が始まった後も、提案時に説明された技術方針や判断がきちんとプロジェクトへ引き継がれるかです。


たとえば、


  • 誰が設計方針を決めるのか


  • 開発中に技術的な問題が出たとき誰が判断するのか


  • 実装内容を誰がレビューするのか


といった部分です。


ここで見るべきなのは「商談した人がそのまま全作業を担当するか」ではありません。


提案時の説明と、実際の開発工程が分断されていないかを見ることが重要です。


発注前には、


「開発開始後の技術判断やレビューは、どのように行いますか」


と確認しておくと、その会社の進め方が分かりやすくなります。


3. 技術的な判断について「理由」を説明できるか


システム開発では、同じ要件でも実現方法が一つとは限りません。


データの持ち方、処理のタイミング、システム構成、既存機能への変更方法など、複数の選択肢が考えられる場面があります。


そのとき重要なのは、特定の技術を知っていることだけではありません。


なぜ今回の案件ではその方法を選ぶのかを説明できることです。


たとえば、


  • 既存システムへの影響を小さくするため


  • 障害時に切り分けやすくするため


  • 将来の機能追加を考慮するため


  • 必要以上に複雑な構成にしないため


など、判断には理由があります。


発注側がすべての技術を理解する必要はありません。


「なぜそうするのですか」と聞いたときに、専門用語だけではなく、メリットとデメリットを含めて説明してもらえるかを見ることが大切です。


4. 「その人しか分からない」状態にならない進め方か


経験豊富な技術者が案件へ深く関わることは、むしろメリットです。


一方で、


「この部分は○○さんしか分かりません」


という状態が増えすぎると、後から変更や確認が必要になったときに困ることがあります。


ここで重要なのは、担当者を頻繁に入れ替えられることではありません。


重要な技術判断や開発内容が、プロジェクトの中に残る進め方になっているかです。


たとえば、


  • ソースコードが適切に管理されている


  • 重要な設計判断を後から確認できる


  • 開発環境や設定が個人のPCだけに閉じていない


  • レビューを通して内容が共有されている


といった進め方です。


詳しい技術者がいることと、その人がいなければ何も分からない状態は別です。


発注先を見るときは、個人の専門性を活かしながら、プロジェクトとして情報を管理しているかを確認するとよいでしょう。


引継ぎのために何を残しておくかは、発注先を選ぶ段階とは別の論点になるため、分けて考えた方が分かりやすくなります。


5. 協力会社や外部エンジニアを利用する場合、責任の所在が明確か


システム開発では、案件の内容に応じて協力会社や外部エンジニアが開発へ参加することがあります。


外部の技術者が参加すること自体で、開発会社の良し悪しが決まるわけではありません。


確認したいのは、誰が案件全体の技術方針と品質を管理しているのかです。


たとえば、


  • 設計方針を誰が決めるのか


  • 実装内容を誰が確認するのか


  • 技術的な問題が出たとき誰が判断するのか


  • 発注側との窓口がどこにあるのか


が整理されていれば、複数の技術者が参加する案件でも進めやすくなります。


反対に、発注した会社から別の会社や技術者へ作業が渡され、元の開発会社が技術内容を把握していない状態では注意が必要です。


発注前には、


「外部の技術者が参加する場合、設計やレビューはどのような体制になりますか」


と確認する程度で十分です。


外部人材を使うかどうかではなく、発注した会社自身が技術判断と品質管理を担っているかを見ることがポイントです。



具体例:社内向け業務システムへ新しい機能を追加する場合


たとえば、現在利用している社内向け業務システムへ、新しい申請・承認機能を追加するとします。


複数の開発会社から、


「業務システムの開発実績があります」


という回答をもらったとしても、それだけでは違いが分かりにくいかもしれません。


そこで、実績そのものではなく進め方を確認します。


ある会社は、


「似たシステムではバックエンドの設計と実装を担当しました。今回も既存部分を確認したうえで設計方針を決め、実装後は技術責任者がレビューします」


と説明するかもしれません。


別の会社は、


「実績はあります。対応可能です」


という回答だけかもしれません。


どちらが必ず優れているという話ではありません。


ただ、前者の方が、


  • 過去にどこを担当したか


  • 今回どのように判断するか


  • 誰が品質を確認するか


が見えています。


システム開発会社を選ぶときには、実績の有無だけではなく、今回の案件をどう進めるのかまで具体的に話せるかが判断材料になります。



この5つを細かく確認する必要がないケースもある


すべてのシステム発注で、今回の5項目を詳しく確認する必要があるわけではありません。


たとえば、作業内容や手順が明確に決まっていて、成果の確認方法も単純な限定的な作業であれば、必要以上に選定を複雑にする必要はありません。


また、社内の調達基準によって開発会社の選定方法や確認項目がすでに決まっている場合は、そのルールを優先すべきです。


一方で、


  • 既存システムへ手を入れる


  • バックエンドの設計を伴う


  • 技術的な選択肢が複数ある


  • 開発後も継続して機能追加する可能性がある


といった案件では、価格や実績だけでなく、今回紹介したような開発の進め方を確認する意味が大きくなります。


大切なのは、確認項目を増やすことではありません。


案件の難しさに応じて、発注前に確認すべき部分を絞ることです。



プレイリーソリューションズでは、設計・技術判断・レビューまで一貫して管理します


バックエンド開発に特化したシステム開発会社 プレイリーソリューションズ合同会社では、設計・技術判断・レビューには技術責任者が入り、実装は案件規模に応じた体制を組みます。


技術責任者はシステム開発歴20年で、Javaを中心としたバックエンド開発、AWS、データベース、外部API連携、決済連携、既存Webシステムの改修などに携わってきました。


案件規模に応じて協力エンジニアが開発へ参加する場合でも、実装作業を外部へ渡して終わりにするのではなく、当社側で設計方針を整理し、技術判断とレビューを行うことを基本としています。


また、重要な技術判断を特定の実装担当者だけに閉じず、技術責任者が設計方針とレビューを把握する形で進めることを基本としています。担当者個人の経験を活かしながらも、技術判断を案件全体から切り離さないためです。


開発中に技術的な選択が必要になった場合には、単に「この方法で作ります」とするのではなく、既存システムへの影響や将来の変更も踏まえて方針を検討します。


発注側がすべての技術を判断する必要がないよう、なぜその方法を選ぶのかまで説明したうえで進めることを重視しています。



まとめ:実績一覧から「今回の進め方」へ一歩踏み込んで確認する


システム開発会社を選ぶとき、過去の実績や対応技術は重要な判断材料です。


ただし、それだけでは今回の案件がどのように進むかまでは分かりません。


発注前には、


  • 近い実績で実際に何を担当したのか


  • 提案時の説明が開発工程までつながっているか


  • 技術判断の理由を説明できるか


  • 特定の人だけに情報が閉じない進め方か


  • 外部の技術者が参加しても技術と品質を管理できるか


を確認してみてください。


すべてを細かく質問する必要はありません。


打ち合わせの中でいくつか確認するだけでも、その会社が今回の案件をどのように進めようとしているのかは見えやすくなります。


既存システムの改修を検討している場合は、以下の記事も参考にしてください。


事業会社の方で、バックエンド開発や既存システムの改修について、技術的な進め方を含めて相談したい場合は、プレイリーソリューションズへお問い合わせください


bottom of page