この記事では、システム開発会社を探したり選定するときのポイントについて書いていきます。
内部の現役PM・エンジニア目線で、システム開発の成功を第一に忖度のない内容となっているので、システム開発会社を探している・今後探すことになるといった方には是非ご参考いただければ、と存じます。
前提
システム開発会社を探すといっても様々なケースが想定されるため、まずこの記事の前提を記載します。
スコープ
- 小 ~ 中規模までのプロジェクトを対象とします。
システム開発案件の金額は通常人月(※1)で考えるもので、金額規模でいうと 1,500 万円くらいまでのイメージです。 - 開発会社に一括で開発を依頼し、システム開発会社にてスケジュールやリソースの管理などのプロジェクトマネジメントを行うプロジェクトを対象とします。
- そのため、以下のようなトピックは本記事の対象外とします。
- エンジニア派遣をしてくれる派遣会社の探し方
- 開発チームのレンタル（ラボ型開発）の探し方
- クラウドソーシングでのエンジニアの探し方
(※1)
人月とは、1 人が 1 ヶ月働くことを 1 人月として、必要な工数を人数 × 期間で表す考え方です。
例えば、3 人で 4 ヶ月かかるプロジェクトの場合、12 人月となります。
仮に 1 人月 100 万円とすると、100 万 × 3 人 × 4 ヶ月 = 1200 万 といった計算になります。
この記事の対象
この記事は以下のような方を対象としています。
- システム開発やシステム開発プロジェクトのマネジメントの機能が社内になく、パートナーとなるシステム開発会社を探している。
- 既存で取引のあるシステム開発会社がないか、あっても課題があり新しく探している。
- システムで実現したいことや解決したい課題がある。それらの「まだふんわりしている」「詳細まで要件が定義できている」といったレベル感は問わない
モチベーション
以前自分自身も開発会社を探したことがあり、システム開発会社は非常に多く、Google 検索だけですぐに 100 社を超える企業が見つかりました。HP を詳しく見ても実際の技術力は分かりづらく、全ての企業と面談するのも現実的ではありませんでした。
また、「システム開発会社 おすすめ」「SIer 探し方」などで検索しても、比較サイトや受託開発会社の自社ブログが中心で、内容が偏っている印象を持ちました。
そこで、システム開発会社での勤務経験と PM・エンジニアとしての経験を活かし、なるべくフラットに良いシステム開発会社の探し方や見極め方について記載します。
筆者のバックグラウンド
自分はシステム開発において以下のような経験があります。
- 経験のあるプロジェクト
- スクラッチ開発
- クライアント企業向けシステムの開発
- 自社システムの開発
- ローコード / ノー・コード
- Salesforce を基盤としたアプリケーションの開発
- Kintone と連携するアプリケーションの開発
- Headless CMS のフロントのアプリケーションの開発
- SaaS やパッケージシステム
- SaaS やパッケージシステムの導入
- SaaS やパッケージシステムと連携するアプリケーションの開発
- Web（HP）制作
- スクラッチ開発
- 経験のある役割
- PM（プロジェクトマネージャー）
- ソフトウェアエンジニア
- デザイナー（少しだけ）
PM とエンジニアは大体半々くらいの経験、小規模プロジェクトであれば双方を兼務するようなこともありました。また、現役でもシステム開発の受託プロジェクトでエンジニアとして業務にあたっています。
システム開発会社に発注する立場だったこともあるので、発注側・受注側双方の視点含め以下にシステム開発会社を探す・選定する時のポイントを書いていきます。
システム開発会社を探す・選定する時のポイント
優秀で技術力のあるメンバーがアサインされるか
個人的には優秀で技術力のあるメンバーがアサインされるか、が何にも優先されると考えています。
ここでは PM（プロジェクトマネージャー）とエンジニア（※2）に分けて、どのように判断すればよいか、について書いていきます。
(※2)
体制によっては明確に PM という肩書の人員がいない場合もあると思いますが、要件の取りまとめ、プロジェクトのスケジュールやリソースの管理、ステークホルダーとのコミュニケーションなどをといった機能を担う人を想定しています。
エンジニアも領域によって複数いたり、エンジニア以外にもデザイナーがいることもありますが、現場でものづくりをする役割全般のイメージで記載しています。
PM（プロジェクトマネージャー）
システム開発会社によりますが、通常以下の流れの中でどのような PM がアサインされるかの情報を得ることができます。
- 営業活動や提案の場に PM が同席する
- 提案書の中に PM の経歴が記載される
可能であれば発注前に PM にアサインされる予定の方と面談をし、コミュニケーションを取れると良いと考えます。
PM はクライアント側とのコミュニケーションを多く取ることになり、例えば現場部門へのヒアリングの場で多くの現場担当者と接点を持つようなこともあるので、自社のメンバーと広く良好な関係を築けそうなイメージを持てると嬉しいです。
また、経歴などからシステムについての造詣が深いかどうかもある程度判断できます。
特に小中規模のプロジェクトだと PM が手を動かして問題解決をするような場面も発生するので、例えばもともとソフトウェアエンジニアをやっていたような方であれば、いざというときになんとかしてくれそうな期待が持てるかもしれません。
エンジニア
今回あらためて「良いシステム開発会社の見つけ方」に関するいくつか記事を読みましたが、「技術力がある会社に発注するべき」「最新の技術に強い会社が好ましい」といった内容を多く目にしました。
これについては自分も同意なのですが、発注側が開発会社の技術者のスキルや技術力を判断するのは結構難しいのではないかと感じております。
そこで、ある程度システム開発会社内部のエンジニアの優秀さや技術力を図る基準として「その開発会社にエンジニアの採用力がありそうかと見る」方法をおすすめできればと思います。
IT 業界でエンジニアは基本的に売り手市場で、特に優秀層は引っ張りだこであり、採用力がある = 優秀なエンジニアが集まっているはずだ、と判断できるためです。以下に具体的に記載します。
- 給料が高い
- HP にエンジニア紹介ページやエンジニアのプロフィール があり、個々のエンジニアが見える
- 技術ブログ（技術に関する発信をするブログ）を運営している
- OSS（オープンソースソフトウェア）や技術的なイベントのスポンサーをしている
2 つめと 3 つめは、社内に優秀なエンジニアがいることや技術力があることを発信することで、同様に優秀なエンジニアを呼び込むことを狙っている場合が多いためです。
実績があるか
実績があるか、も重視される要素です。特に開発を依頼するものに近いシステムの開発実績があることが望ましいのですが、もう少し深堀り、以下の 2 つの軸で説明します。
システムが対象とするビジネスや業務が似ている
システムは例えば以下のように、どんなビジネスや業務を対象とするかで呼ばれ方が変わってきます。
- EC サイト
- 会員向けマイページ
- 顧客管理システム
- 社内業務システム
- 予約管理システム
- 在庫管理システム
- データ分析ダッシュボード
今回構築したいシステムと同じようなシステムの開発経験がある場合、その実績から以下のようなことが期待できます。
- 開発会社側からから要件や実現方法についての提案がされやすい
- 洗い出せていない要件があったとしても、開発会社側が補ってくれる
例えば会員向けマイページの開発経験がある場合、
- 「会員のログイン方法は "メールアドレスとパスワード" に加え "Google 連携" などのソーシャルログインはどこまで実装しましょう? 多すぎると会員が迷ってしまいログインに関する問い合わせが殺到するので増やしすぎには注意が必要です。」
- 「メールアドレス変更の機能が要望の中に入っていないませんが、必要ですよね? 適宜補っておきます。」
といった先回りの提案やサポートにつながる可能性が高まります。
システムに含まれる要素（機能）が似ている
エンジニア視点で見ると、システムに含まれる要素（機能）が似ているものでも開発実績があると好印象になると考えられます。
例えば「チケットサイト」と「願書受付システム」は一見全く別のシステムに見えますが、特定のタイミングになると一気にアクセスが集中するといった点では似ていると言えます。
そのような場合、突発的なスケールアウトにも耐えられるようなシステム構成や、大量の DB 更新をさばけるような仕組みが必要になったりします。
このように要素として似ているものは別のジャンルのシステムでも構築経験が活かせるため、注目すべき実績です。
上記の例以外にも例えば以下のような要素が挙げられ、さらにこれらに限りません。
決済機能 / 多言語対応 / 秘匿性の高い情報管理 / リアルタイムデータ処理が必要 / 外部システム連携 / 高度な認証・認可要件 / データ分析・可視化 / モバイル対応 / 高可用性要件 / コンプライアンス対応 / バッチ処理 / AI・ML 機能 ...
これらの要素は、異なる業種のシステムでも共通して必要とされることが多く、開発会社の技術力を評価する重要な指標となります。特定の要素で高度な実装経験を持つ開発会社は、その知見を活かして品質の高いシステムを構築できる可能性が高いと言えます。
実績の確認方法
多くのシステム開発会社の HP には実績が紹介されていますが、実績はクライアントから許可されたもの以外は基本的に公開できないので、面談や提案の中で聞きたいところです。
その際に上記のような類似の実績があるかを問い、かつその実績が今回構築を依頼するシステムとどのように似ているかを説明してもらえると良いでしょう。
実現にあたって豊富なケイパビリティがあるか
様々なツールが乱立する現代のシステム構築では、同じ要件でも実現方法が多岐にわたります。特に具体的な実現方針が固まりきっていない場合、様々な選択肢を持ち合わせ最適な提案ができる開発会社を選定できれば、結果的にコスト削減や保守運用性の高さにつながります。
以下に、ケイパビリティの幅として考えられるものを記載します。
ノーコード/ローコードプラットフォーム
一般的な要件や社内利用のシステムは、ノーコード/ローコードツールを活用することで、低コストかつ迅速な開発が可能です。
HP 上に以下のようなツールが扱える旨の記載があるかを確認するとよいかと思います。
- Salesforce：CRM 機能を中心とした業務システム開発
- Kintone：データベース型の業務アプリケーション
- その他にも Bubble、Microsoft Power Platform、Airtable .. などなど
クライアントの既存の IT の活用や連携
クライアント企業の基幹システム、既存の SaaS ツールなどの状況を加味し、それらと新規構築するシステムを俯瞰してあるべき姿を検討できると、より長期的に活用されるシステムの設計につながります。
例えば以下のようなツールは一般的なものなので、開発会社によっては HP 上で対応可能である旨や連携開発実績を謳っている場合があります。
- オフィススイート（Microsoft 365, Google Workspace など）
- コミュニケーションツール（Slack, Microsoft Teams など）
- プロジェクト管理（Jira, Trello など）
- ファイル管理（Box, Dropbox など）
適切な体制を組めるか
通常その開発会社がどのような体制を組んでプロジェクトを進めているか、も重要なポイントです。
体制について、自分はこれまでの経験から小中規模のプロジェクトであれば、基本的に少数精鋭で進めつつリスクを低減する方針が好ましいと考えており、その前提に立った内容になっています。
実際、以前自社サービスではありましたが優秀なリードエンジニアと自分（サブエンジニア兼 PdM のような立ち位置）の 2 人でシステムを開発した際は、効率的に品質の高いシステムを低コストで作ることができました。
「少数精鋭型」と「組織型」の考え方
少数精鋭型
- 必要最低限の人員で構成され、意思決定が早く、コミュニケーションコストが低い
- 人員が少ないため、人月コストも抑えられる
- 優秀なメンバーで構成されれば、高品質なシステムを効率的に開発できる
- メンバーの離脱や交代時のリスクが大きい
組織型
- 役割を細分化し、複数人で対応することで属人化リスクを軽減
- レビュアーなど品質管理の役割を設けることで、一定の品質を担保
- 人員が多いため、人月コストやコミュニケーションコストが増加
- メンバー間の認識齟齬による品質低下のリスクもある
そのため、以下についての考え方やしっかり担保されているか、を確認すると良いと考えます。
- 前述した、人員の習熟度や技術力
- エンジニアは領域によって分かれているか
例えばバックエンドとフロントエンドでエンジニアが分かれていることはよくあります。ただ、昨今の小中規模のシステム開発であれば 1 人で全ての領域を開発することも可能なので、何人のエンジニアがアサインされることになるかを確認します。 - シニアエンジニアとジュニアエンジニアが分かれているか
開発会社によっては人材育成を目的として、内部的にはシニアエンジニアがジュニアエンジニアの教育を担うような体制を組む場合があります。 - デザイナーがアサインされるか
toC のアプリケーションや高いユーザビリティが求められるシステムの場合、UI/UX のデザインが重要になります。そのような場合、デザイナーをアサイン可能かも確認すると良いでしょう。 - 多重下請け構造になっていないか。再委託がある場合、その範囲と理由は適切か
- バックアップ体制
同じメンバーが徹頭徹尾システム構築を遂行することが望ましく、基本的にシステム開発会社側もその方針でいるはずですが、万が一交代があるような場合、どのようにリソースを確保するかなどについて確認しておきます。 - 提案段階と実際の稼働メンバーの差異
例えば提案段階は営業担当しか出席しておらず、プロジェクト開始後「提案段階と話が違う」といった齟齬が起きないよう、提案段階にもプロジェクトメンバーが参加しているか、もしくは営業担当がプロジェクトにも参加する予定か、といったことを確認します。
契約形態
システム開発会社が請負契約と準委任契約のどちらを想定しているかも確認したいポイントです。
一般的に請負契約はシステム開発会社側がリスクを負うため、クライアント企業としては請負契約にて発注したいと考えられるかもしれません。
しかし、請負契約には多くのリスクがあり、プロジェクト全体で考えると好ましくないケースも多々あります。
以下に請負契約と準委任契約の特徴やリスクをまとめます。
| 観点 | 請負契約 | 準委任契約 |
|---|---|---|
| 責任範囲 | 成果物の完成に対する責任 | 善管注意義務の範囲内での責任 |
| 費用 | 固定費用 要件追加変更の際は追加費用が発生 |
工数に応じた変動費用 |
請負契約のリスク
- 初期段階で要件を明確にする必要がある。漏れがあると後で要件が追加になる
- 要件追加や変更の際には、追加費用の是非の判断や見積もり、それらに伴う調整といったプロセスが発生する
- 受注者側では費用内で完成させることが重視されがちで、発注者側が注意して品質の確認（検収）をする必要が出る。見落としがあると後で追加改修が発生し、費用がかかることもある
- 要件の解釈の違いによるトラブルが発生しやすい（「仕様書にはそこまで書いていない」といった議論）
上記より、請負契約の場合クライアントとシステム開発会社の間でトラブルに発展しやすく、プロジェクト全体の空気が悪くなったり、（本来プロジェクトからすると不要な）交渉や調整で工数がかさむといった危険性があります。
そのため、請負契約にて発注できるからと安易にそのシステム開発会社を評価するのではなく、以下の点を念頭にシステム開発会社がどのような理由でどちらの契約形態を提案してくるかをしっかりと見るべきだと考えます。
- 自社に要件定義や品質チェックの機能があるか
- 不確実性や変動要素がどの程度存在しているか
保守フェーズ
開発を担当した会社が保守・運用フェーズもサポートできる場合、以下のメリットがあります。
- 品質へのコミットメント
- 保守を見据えた設計・実装を行うため、保守性の高い品質の良いコードが期待できる
- 「作って終わり」ではなく、長期的な視点での開発が行われる
- 効率的な保守対応
- 開発メンバーが内部構造を熟知しているため、問題の特定や修正が迅速
- システムの背景や経緯を理解しているため、適切な改善提案が可能
- スムーズな引き継ぎ
- 保守・運用フェーズは別メンバーが実施する場合でも、社内での統一された技術スタックやノウハウの共有により、スムーズな引き継ぎが期待できる
保守・運用体制について
開発会社が保守・運用フェーズもサポートできる場合、どういった内容や条件になるか、具体的に以下のような項目について確認すると良いでしょう。
- 保守・運用の対応範囲
- 障害対応
- セキュリティアップデート
- 機能改善・追加開発
- パフォーマンスチューニング
- 運用監視
- ユーザーサポート
- SLA（Service Level Agreement）の有無と内容
- 稼働率の保証
- 障害時の対応時間
- 定期メンテナンス
- 報告体制
保守性を考慮した開発になるか
保守フェーズを見据えた開発ができるかも重要なポイントです。以下の点について、開発会社の方針を確認します。
- どのようなドキュメントを作成するか
- 自動テストはどのように整備するか
これらは保守・運用フェーズに入り開発時と異なる人員によって修正や改修が行われる際に、その作業をスムーズにすることはもちろん、一定の品質を保つことに繋がります。
自動テストとは
プログラムが正しく動作するかをチェックするプログラム。定期的・任意のタイミングでプログラムに問題がないかを確認できる。
さらに「仕様書」としての役割も果たすため、新しくプロジェクトに参加したメンバーが、自動テストのコードを読むことで「この機能はこういう動作をすることを期待されている」ということが分かる。
ドキュメントは何らか残されることが多いですが、自動テストはプロジェクトの納期や予算の兼ね合いから整備されずに進んでしまう .. といったことも少なくはなく、中長期にわたり運用するシステムの場合は自動テストもしっかりと残しておきたいところです。
システム開発会社に伝えたい情報
と、どのような観点でシステム開発会社の良さを判断するべきかを記載してきましたが、依頼する側にも開発会社を判断するための情報をうまく引き出すための適切な情報提供が求められます。
通常システム開発会社に問い合わせや提案依頼を行う際には、どのようなシステムの開発を検討しているかを伝えますが、その内容についてのポイントを記載していきます。
必ず伝えたいこと
システム開発会社がクライアントの状況や実現したいことを正確に理解できるようにするため、目的ベースで以下のようなことを洗い出せるとよいと考えます。
- 解決したい問題点や課題点
- 実現したいビジネスや企画内容
- いつまでに達成したいのか。それはなぜか
- 社内の体制やどのような人材がいるか（※3）
できれば伝えたいこと
いわゆる要件定義にて洗い出すような内容についても、可能であれば事前に取りまとめられるとよいです。
しかし要件定義はシステムやプロジェクト進行についての一定の知識や経験が求められるため、社内にそういった機能が無い場合はシステム開発会社側に協力してもらうことをおすすめします。
要件定義で実施/定義する事項の例
- 現行システムの調査
- 現状の業務フローの整理
- 問題点や課題点の洗い出し
- 機能要件の作成
- 非機能要件の作成
- 実装するページ（画面）一覧の作成
- ユーザーストーリー策定
- スケジュール
要件定義の遂行をシステム開発会社にリードしてもらう場合でも、現状理解や望ましいシステム仕様の検討のためにはクライアント企業の協力が欠かせません。
前述の（※3）は開発会社側がクライアント側からどのような方に参加してもらうべきかを検討するためにもインプットしたい内容です。
たまにクライアントにはノウハウがあまりないにも関わらず、機能要件一覧が作成されている、といったシーンに遭遇します。
現場目線では欲しい機能だとしてもシステム開発目線だと実現が難しいもの、ということもあり、見積もりや実装もその機能要件を前提として進んでしまい、最終的にプロジェクトが炎上する .. といったリスクにつながります。
ただ、システム開発会社に要件定義をお願いする場合、基本的に彼らにシステム開発を発注する前提での依頼となり、その場合システム開発会社のケイパビリティの範囲で実現できるような要件に限定されてしまう、という懸念もあります。
そのため、要件が明確でない状態でシステム開発会社を選定する場合「実現にあたって豊富なケイパビリティがあるか」が重視されると良いかと思います。
長い内容になってしまいましたが、最後までお読みいただきありがとうございます。
システム開発会社を探している・これから探すという方の一助になると嬉しいです。