
弊社ではシステムやアプリの受託開発会社、デザインやホームページの制作会社の営業・マーケティングの支援事例があり、今回は受託開発会社の営業マンが初回商談で確認、ヒアリングすべき内容を記載します。
以下関連記事
目次
商流と依頼者の業態
商談相手が広告代理店か事業会社かによって、商流が変わってきます。
例えば
エンド→広告代理店→自社の場合 間に1社挟まっているので 要件確認などは代理店と行う必要があります。
もちろん商流は浅い方がいいですが、エンドが大手の場合は広告代理店や大手SIerが依頼してくる場合もあり商流の確認は重要です。
以下参考
要件を出している方の職種
システム開発の要件を出している人の職種は、
・システム開発のバックグラウンドがあるか?
・PMや要件定義の経歴があるか?
などを判断する要素になります。
職種がプランナーやディレクターの場合は企画面の仕事なので、システムの要件設計は弱いため自社で提案していく必要があります。
一方、リードエンジニアやPMなどの職種の場合はある程度技術を理解できているので、商談時に技術的な部分を詰めていくことが可能です。
オフラインの場合は名刺に職種や役職の記載がありますが、オンライン営業の場合は職種を知ることができません。会話の内容、SNSで担当者名を検索して経歴を確認する などの手段で推測していきます。
新規システムか改修か
システム開発は新規システムの方が難易度が低く、既存システムの改修の方が難易度が高くなります。
一般的に他者が書いたコードを読み解くのは時間がかかりますし、
既存システムはドキュメントがなかったり、ドキュメントが更新されていなかったりするので、工数の算出も難しいためです。
構築するシステムの目的
MVPのためなのか、すぐに売上を上げるためのシステムなのか、業務効率化するためのシステムなのか
目的によって最終的なゴールが変わってきます。
誰が利用するか?
目的に付随しますが、利用する人が社員のみなのか?個人の場合はどのくらいの年齢層、職種、年収なのか などによってシステムの提供形態が変わってきます。
社内向けの利用ならPCでの提供が優先されSSOなどの要件が発生しますし、個人の場合スマホアプリでの提供が優先されます。
どれくらいアクセスされるかの想定
アクセス数によって、ロードバランサーの有無やサーバーのスペック選定に影響しますので、
非エンジニアでもどれくらいのアクセスが発生するか?は確認する必要があります。
商談相手が推測できない場合もあるので、開発対象のシステムを利用する人や目的からある程度自社で決めていく必要もあり、一般的には社内利用の場合、そこまで大規模なサーバーは必要ありません。
会員や承認機能、決裁機能の有無
会員機能、承認機能、決裁はシステムを構築する際の技術選定に関わってきます。
会員機能や決裁機能はシステムのフレームワークで完結しますが、どのプログラミング言語のどのフレームワークを利用するかに影響してきます。また承認機能は一般的にフレームワークで提供されていないので、新規開発の工数算出に関わってきます。
推定レコード数
レコード数はシステム設計とデータベースの設計に関わってきますので、ある程度必要になってきます。
一般的に社内向けシステムの場合はレコード数が少なくなります。
利用する技術領域の指定
指定するプログラミング言語やフレームワーク、サーバーがあるか確認します。
技術領域は自社のエンジニアが対応できるか?似た要件の対応が過去あるか?を考える材料になります。
契約形態
準委任契約か請負契約か?の指定があるか確認します。
準委任契約は開発リソースの提供という契約なので、システムの完成責任はありません。
一方請負契約は完成責任が発生するので、完成しなかった場合は損害賠償も発生します。
希望納期と予算
希望納期と予算は自社対応できるか否かの判断になるので必ず確認する必要があります。
以上になります。