自社に合うカスタムソフトウェア開発会社の選び方

開発会社を選ぶときは、実際に必要な仕事を一つ示すと話が具体的になります。誰が作るのか、動くことをどう確かめるのか、利用開始後は誰が面倒を見るのかを聞きましょう。その答えに見合う根拠も示してもらいます。

各社に同じ課題を伝える

卸売業を営んでいると仮定します。これは架空の例です。従業員が注文を入力し、在庫を引き当て、配送を手配します。全員が同じ注文記録を使えるようにしたいとします。

ある会社は見栄えのよい注文アプリを見せます。別の会社は、在庫を引き当てた後に顧客が注文を変更したらどうなるかと尋ねます。どちらの話からも分かることがあります。アプリはソフトウェアの一例を示し、質問はその会社があなたの仕事のどこを理解しようとしているかを示します。

候補に残した各社に、対応が難しいケースも含めて同じ例を渡しましょう。提案する前に何を知る必要があるか、説明してもらいます。システム全体を無償で設計してもらわなくても、仕事への向き合い方を比べられます。

英国政府の調達ガイダンスは、製品と供給者を選ぶ際に、中心となるニーズ、利用できる能力、契約、継続的な供給者管理を結び付けています。政府向けの指針ですが、買い手にとっての問いは広く使えます。その契約と体制で、実際に必要な仕事を支えられるでしょうか。

事例から何が分かるかを確かめる

関連する事例があれば、さらに詳しく聞けます。その会社が何を作り、何を引き継ぎ、今もどの部分を担当しているかを確かめましょう。顧客が話せる場合は、その顧客の了承を得てから、自社に重要な点を尋ねます。

注文システムには、正確で信頼できる在庫記録と、顧客情報へのアクセス制限が必要かもしれません。見栄えのよい店舗サイトだけでは、こうした点は分かりません。日々の業務に似た要件があるなら、異業種の案件のほうが参考になることもあります。

実際に仕事を担う人に会う

営業担当との話が終わった後、誰と仕事をするのか確かめましょう。技術面を決めるのは誰か。開発とテストは誰がするのか。従業員に進み具合を説明できるのは誰か。担当者や外注先が変わった場合も、結果に責任を持つのは誰か。

こうした質問をするために、チームの規模や技術を先に決める必要はありません。小さな変更を一つ取り上げ、依頼からリリースまでの流れを説明してもらいましょう。各段階の担当者と、あなたが判断する場面が分かるはずです。

成果をどう見せ、どう受け入れ確認するかを決めます。先ほどの卸売業なら、承認された注文変更によって元の在庫引き当てが解除され、承認者が記録されるかを確認できます。デモでは実際の注文が変わらないよう、別のテスト環境で架空の記録を使います。これは架空の事業に対する確認案です。自社の確認項目は、実際の仕事から決めてください。

利用開始後のことまで考える

システムを動かし、障害を監視し、更新を入れ、他のサービスとの接続が切れたときに対応するのは誰かを聞きましょう。問題の報告方法、対応可能な時間、支援の範囲と費用も決めます。

Googleのサービス運用の責任移管に関する説明では、準備状況の確認、研修、文書、移管中の支援が取り上げられています。小規模な会社がGoogleのチームや手順をそのまま採用する必要はありません。引き継ぐ人が仕事をするには、十分な知識と準備が必要だという点が参考になります。

契約前に引き継ぎを話し合いましょう。必要なアカウント、アクセス権、データの書き出し、文書、ソースコードを洗い出し、何が提供されるかを決めます。ライセンスと第三者による制限も確認してください。開発費を払うだけで、どの権利や資料が得られるかは決まりません。

比較に役立つ候補リストを作る

各社について、示せる関連案件、責任者、進捗を見て受け入れ確認する方法、利用開始後の対応を書き出します。まだ確かめる必要があることも横に記します。

作業範囲、費用、時期が変わる場合、承認前にどう説明するかを聞きましょう。価格は、その価格に含まれる仕事や継続的な責任と合わせて判断します。重要な答えが欠けているなら、プレゼンの印象で補わず、確認するための具体的な次の一歩を決めます。

私たちは業務に合わせたソフトウェアを開発しています。依頼を検討中なら、実際に必要な仕事の例をお聞かせください。作業範囲、納品、サポート、引き継ぎの条件は案件ごとに取り決めます。

選ぶ前によくある質問