はじめに－どんなシステム会社が良い会社！？
今回の記事で指す「良いシステム会社」は、導入時はもちろん、導入後もシステムの改善に機動的に寄与してくれるシステム会社と定義します。
もちろん、この記事で取り上げる観点以外でも良し悪し（適する適しない）の判断基準はたくさんありますので、「良い」「悪い」はあくまでこの記事内での定義であるということ、事前にお断りさせていただきます。
ただ、我々もシステム業界にいる中で、よく耳にするトラブルを取り上げているつもりですので、この記事を読んでいただければ、事業の成長を後押ししてくれるシステム会社と巡り合える企業様が増えると、確信しております。
目次
【前編】
【後編】
トラブル①
－見積が何倍にも膨れ上がる！を防ぐ
まず初めは、システム業界で最も多く聞かれる、お金に関するトラブルを招きやすい会社を見分ける方法です。
システム構築に関する見積は、一般的に2段階に分かれます。
1段階目の見積りは、構築するシステムの用途や要件を確認するための「要件定義」に対する見積りです。2段階目の見積りは、「要件定義」で定めた構築内容に基づき、実際のシステム構築に対する見積りです。
営業時には、1段階目の見積りと2段階目の”概算”見積りを提出するのが一般的です。
そのため、2段階目の見積りは、要件定義の中で定める構築内容に依って大きく見積が変わることがあります。
もうお分かりかと思いますが、トラブルはこの2段階目の見積りが、当初営業担当が提出した2段階目の概算見積と大きく異なることから生まれます。
但し、2段階目の概算見積と正式見積が異なること自体はそれほど珍しくありません。
なぜなら、営業時には「こんなことをやるためのシステムが作りたい」といったざっくり要求に対する概算金額を見積もっており、詳細な開発内容は要件定義を行うまで分からないからです。
もちろん営業の段階から要件を細かく詰めることができれば、見積は精緻なものになりますが、「開発工数の3割が要件を定義する工数」と言われるほどシステムの要件化には時間を要することから、営業で詰め切ることはできません。
では、諦めるしかないかというと、そんなことはありません。
ここがベンダーを見分けるポイントです。
良いシステム会社（＝見積がズレない）の営業は、システムや業務に詳しく、見積に大きく影響しそうな要件を把握し、見積が後から大きく変わらない程度に要件を確認します。また、お客様からご要望がない要件であっても、システムを構成するに当然に必要となる要件を想定し、見積を作成します。
逆に、悪いシステム会社（＝見積がズレる）の営業担当は、システムや業務に詳しくないため、見積に影響しそうな要件が分からないうえ、お客様から言われたことだけを見積るため、実際に”使える”システムを構築する費用を後から追加することになります。営業時に想定されなかった要件が多ければ、その分2段階目の見積りは高額になっていきます。
実際には、意図的に他社より安く見える見積を作る営業担当者もいるため、なかなか見分けるのも難しいのですが、 お客様の業務に関してしっかりヒアリングを行えたり、システムのリスクなども具体的に話せない営業には気を付けてください。
特に「すごいシステムなのであれもこれもできます！」と、機能に関する説明ばかりする営業は、システム内部にあまり詳しくないことも多く、要注意です。
トラブル②
－できると言われたことができない！を防ぐ
次にご紹介するのは、認識相違によるトラブルを招きやすい会社を見分ける方法です。
システムの開発会社を選定するときは、一般的に複数のシステム会社から情報を集め、最適なシステム会社を選ぶ形になるかと思います。
その際、自社が期待する機能が、各社のシステムに標準で備わっているのか、標準で備わっていない場合には開発するのにどのくらいの費用がかかるのかを確認していきます。
純なシステムであれば、デモ（デモンストレーション）環境で実際に機能を把握できるかもしれませんが、ECサイトのように多量の機能がある場合には、すべての会社のすべての機能を実際に確認していくことはできません。そのため、選定の際には、機能要件を一覧にまとめ、各社に標準機能での対応可否や開発する場合の費用を確認していきます。
機能要件は、例えばECサイトの場合、「クレジットカード決済ができること」「在庫数に応じて、商品画面に残り〇個と表示できること」といった内容になります。
当社がコンペ（コンペティション）に参加させていただく際にも、実際にこうした機能要件をいただくことは多いのですが、この機能に関して言えば過半数のシステム会社が標準機能として回答されるでしょう。
では、どこで認識相違が生れるのでしょうか。
「在庫数に応じて、商品画面に残り〇個と表示できること」という要件でご説明すると、この要件はユーザー画面に残り〇個と表示できることが要件なだけで、 “自動”とは書かれていません。そのため、「手動で表示を切り替える必要がある場合」でも、「商品が残り3個以下になったら、自動的に表示が切り替わる場合」でも、標準機能で要件を満たしているという回答になってしまうのです。
例が極端なので、「こんなことあるの！？」と思われる方も多いと思われますが、「自動だと思った」のに「実際は手動」だったなどは、認識相違の典型的なパターンです。
こうしたトラブルを防ぐためには、要件を明確にすることが大事です。
”コツ”というよりは、地道な確認になってしまいますが、先の要件を記載する場合にも「在庫数が3個以下の商品に関して、フロントの商品ページで在庫数を表示できるようにする」と記載しておけば、祖語は少なくなります。
なお、こうした認識相違は、標準機能に対するものより、開発を伴う機能に対する部分で目立ちます。
パッケージシステムであれば、一般的に複数の会社で利用されているものかと思いますので、機能自体がある程度洗練されています。
しかし、新機能として構築する場合には、その機能を設計するシステム会社の設計者に依存します。
設計者が業務や運用に対する理解が薄い場合には、”普通に考えるとありえない”機能も構築されてしまうのです。
選定時に確認できる範囲にも限界はありますが、要件を詰める段階でどのようなドキュメントを使っているかを事前に確認すると良いかもしれません。 ドキュメントに記載された文章が明確ではない場合や、画面仕様書（画面イメージ）や業務フロー図など、しっかり画面や運用に関する認識を共有できる資料を作成しない会社は、認識相違が多くなると思ってください。
ドキュメント作成にも手間はかかるため、費用も相応にかかってしまいますが、ある程度大きな開発を行う場合には、構築前に要件を明確にしてくれるシステム会社をお勧めします。決して「なんとなく依頼したら、素晴らしいシステムができた！」なんてことはありません。[後編に進む]
