システム開発パートナー（発注先）の選び方　Part2【選定する】

今回も前回に引き続き、システム開発パートナーの選び方について解説をします。
まず最初に、前回の内容を簡単におさらいします。

システム開発パートナーの選定には、次の7つのステップがあります。

開発パートナー選定の7ステップ

①何を探すかを知る
②候補を探す
③会ってみる
④提案を依頼する
⑤提案を受ける
⑥比較検討する
⑦決定する

このうち、①から③について解説しました。
候補を探す前に、
①どんなシステムを得意とする相手を探すかを整理し、
②ネット、紹介、身近なところなどで候補を探し、
③提案を依頼する前に、一度会ってみる。
そんな内容でした。

前回の投稿をご覧頂けていない方は、こちらからどうぞ。

このテーマは2回に分けて投稿します。第2回目となる今回は、システム開発パートナーの候補の選定について説明します。
→第1回目はこちら「システム開発パートナー（発注先）の選び方　Part1【候補を探す】」

このコラムの内容は動画で公開しています。
システム開発パートナーの選び方 Part2【選定する】Youtube版はこちらをご覧ください。

④提案を依頼する

この一つ前のステップにて、提案をしてほしい企業を選びました。
前回、解説し忘れていましたが、候補は少なくとも3社は上げておきたいところです。
1社であれば比較のしようもないですし、10社ともなると提案を聞いて検討するのも大変。3社～5社位に絞り込んでおくのが適当なところでしょう。

提案を依頼する方法は、RFPつまり、提案依頼書を出す。と、一般的には言われています。RFPなんて言うから難しく聞こえるのですが、単純に「提案の依頼書」のことです。専門用語を使いたがるのは我々の業界あるあるですね。
経験上、お客様から提案依頼をされたときに「これがRFPです。」のように頂いたことは、ほとんど記憶にありません。もちろん、文書がないという意味ではありませんが、提案依頼書のように体裁が整ったものは少ないです。それがリアルです。

重要なことは、作りたいシステムについて、システム開発パートナー側が誤解なく理解できるように、必要な情報が記されているという事です。では、提案依頼書には何を書けばいいのかをご説明します。

この解説をする前に、ネットで提案依頼書を検索してみました。
なぜかというと、AI時代になって何か画期的な変化が起こり、以前と違いが生じてはいないかと思ったからです。まず、提案依頼書について情報提供をしているのは、当然といえば当然ながら、ITベンダー、システム開発パートナー側です。

いくつか見つけて読んでみました。AI時代だろうがそこは関係なく、多少の違いはあれど概ね同様なことが書かれています。その内容は、ITベンダーとして、自分たちが聞きたいことを提案依頼書の項目にあげています。「それは、当たり前だよね？」とも言えるのですが、ユーザ側から見た場合に、ITベンダーが求めている情報を完璧に提供できるのだろうか？と申し上げたい。

もし、10億円を超えるようなシステムであるならば話しは別です。そのくらいのシステムを発注できる企業には、必ず経験豊富なシステム担当者がいます。

しかし、そうではない小中規模案件ならどうでしょう？間違いなく、書けないことが多々あります。例えば「非機能要求」と言われて、ピンと来ますか？「設計要求」と言われても分かりませんよね？　実は、プログラマや、経験の浅いSEだって説明できない人はたくさんいます。それがリアルです。

私の考えとしては、ユーザ側は自分たちが作る提案依頼書を完璧にするのが正解ではなく、ユーザ側でしか作ることができない、自分たちでなければ分からない情報を提供し、それ以外のシステムの技術的な情報はITベンダーが自ら提案してくれる、また必要に応じて、ユーザから引き出し提案をしてくれる。そうあるべきだと強く思ってます。

例えばITベンダーが、ユーザ企業に対して「『セキュリティ要件』を明確にしてください。」というのではなく、「このシステムであるならば、セキュリティに対してはこのように考えるべきだ。あるいは、選択肢として、1，2，3がある。我々としては、1をおススメする。なぜなら理由はこうだから。」そんな風に提案をすべきなのです。

繰り返しになりますが、ユーザ側はITベンダーと比べて圧倒的に開発経験が低いのですから、ITベンダーが率先してリーダーシップを取るくらいの意識がないといけません。ユーザ側は、そんなITベンダーを選定して、開発のパートナーに相応しい相手を見つけるのです。

では、話しを戻して提案依頼書には何を書くべきか、改めて説明します。
上記のとおり、ユーザ側が書ける範囲を前提とすると、以下の内容となります。

システム開発の背景
目的
課題
解決策と期待する効果
要求機能
プロジェクト実施体制
スケジュール
予算

もし、これまでの投稿をご覧頂いている方であればお分かり頂けますが、システム企画書の内容そのものです。システム企画書の解説にも記載しましたが、システム企画書は提示する相手によって、必要に応じその内容を変えてください。

つまり、システム企画書が社内向けだとするならば、公表できる内容・できない内容の選別、書き方の表現の変更などを行って、体裁を提案依頼書に書き換えてしまえばいいのです。

⑤提案を受ける

一般的に、提案は無料です。ITベンダー側から見れば、提案書の作成は結構なコストがかかります。ITベンダーが持っているパッケージの提案ならまだしも、新規のシステム開発の場合、営業担当、SEなど複数人が知恵を寄せ集めて提案書に仕立て上げます。

何をお伝えしたいかというと、提案を受ける側も真剣に向き合ってほしいということです。提案依頼をした後、提案を受けるまでは何もないかと言うと意外にそうではありません。提案依頼書に記載していないことを質問されます。ITベンダー側が真剣なほど、質問は生まれてくるでしょう。それに対しては、できるだけ速やかに真摯に答えを返してください。

しかしながら、直ぐに回答できるもの、時間の問題ではなく回答を用意できないものが出てくるはずです。回答しにくい質問の典型的なものは、主に技術的な質問です。例えば、システム開発のサーバOSは何にしますか？開発言語は？データベースは？どこのクラウドを使いますか？などが、それに当たります。技術的な質問、つまり、技術的な要件は、「当社の提案依頼に対して適切だと思われるものを提案してほしい。」と答えましょう。

それ以外、自社でなければ回答できないことについて、回答しなければならないのはもちろんですが、即答できないようなことならば、いつまでに検討をして返事をするという日程は直ぐに答えましょう。これは提案をしてくれた相手に対する基本的な礼儀であり、ビジネスの基本です。じっくり検討したい、他部署との調整が必要、あるいは稟議の都合などで回答が遅れそうな場合には、早めにお知らせしてください。

質問回答などを経て、いよいよ候補の各社から提案を受けます。提案を受けるに際しては、説明の順番が前後してしまいましたが次項の比較検討項目に沿って評価できるよう、聞くための準備をしてください。最終的に、候補各社から提案を受けたら、こちらもまたいつまでに回答するかは伝えてください。

⑥比較検討する

言うまでもなく、システム開発パートナーは見積もり金額だけで決めてはいけません。家電のように、メーカーも機種も同じであるなら、金額だけの比較もしやすいですが、システム開発はそうはいきません。同じ仕様を求めていても、でき上るものの品質が同じであるとは言えません。そのため、次に説明するような基準をもって比較検討してください。

1.提案力

その企業独自の提案があるか、という点について見てください。開発ができることと、提案ができることは別のスキルです。提案力を難しく考える必要はありません。提案を聞いたとき、技術的なこと以外で「なるほど、そういう考え方もあるね」と思ったなら、それは提案力があるということです。

2.技術力

開発したいシステムの企画を理解し、上流工程、つまり要件定義から、設計、開発、テスト、運用までの経験が十分にあるか。
システム開発ができると言っても、実は苦手な工程がある場合もあります。どの工程も重要ですが、設計・開発よりも、要件定義など上流工程ができる企業は少ないです。

3.業務知識・専門知識

開発したいシステムが、業務システムならばその業務に対する知識を持っているか。さらには、その業務が関係する専門的知識までを持っているか。

4.同様のシステムの実績

開発したいシステムと同様のシステム開発実績があるか、それはどれくらいの数を経験してきているのか。

5.開発体制

プロジェクトマネージャー、開発者、デザイナーなどプロジェクトに必要なメンバーが含まれているか。その経験はどうか。　

6.プロジェクトマネージャーのスキル

開発のかじ取りをするプロジェクトマネージャーは、過去にどのようなシステム・どのような規模のシステム開発を経験しているのか。

7.プロジェクトマネージャーとの相性

プロジェクトマネージャーとは、長期に渡って接する機会があります。最初の時点から、「いい印象がない、なんだかしっくりこない」という場合、その予感は大切にすべきでしょう。人事部から配属された社員ではないのですから、決める権利はこちらにあります。

8.スケジュールの妥当性

開発スケジュールには、要件定義、設計、開発、テストのように、開発工程が分かれて書かれています。ユーザ側が密に関わるのは、要件定義、受け入れテスト。全体の妥当性を判断するには困難ですが、自分たちが関わるこれらの工程が短すぎないかは最低限確認して頂きたいです。

仮に要件定義工程が2週間だとしましょう。すると、打合わせは週一回。多くても週2回。だとすると、合計2回～4回です。それで、話がまとまるのかと想像してみてください。

あるいは、打合わせは毎日と言われた場合、それを受け入れられるのか？最後の方に行われる受け入れテストの時期に、自身の重要な仕事が重なってないか？を確認してください。

9.保守体制

システムは開発して終わりではありません。ここから使い始めるのですから、むしろ始まりと言った方が正しいのです。安定運用はもとより、機能追加にも対応できる保守体制を敷いてくれるのかどうかは重要なポイントです。

10.見積もり

見積金額は最初に目が行きがちです。もちろん、予算あってのことですから、当然のことと言えます。ただし、見積もりは全体的な評価ポイントの一つであるということは忘れないでください。また、当初の開発費用のみならず、ランニングコスト。つまり、保守・運用費用はどれだけかかるのか。保守・運用費用は毎月、かつ使い続ける間発生するものです。

11.企業の安定性

さきほど説明したとおり、システム開発が終了した時点から、システムの使用がはじまるわけです。極端な話し、システム開発完了直後に、開発した会社がなくなったらどうでしょう？

仮に、自転車が壊れた時、そのメーカーがもしなくなったとしても、きっと近所の自転車屋さんが修理してくれることでしょう。しかし、システムはそう簡単にはいきません。開発パートナーは、将来に渡って、保守できる企業を選定する必要があるのです。

⑦決定する

これから長くお付き合いする、パートナーになる相手です。システム開発をすると、そこからは長いお付き合いになるのが普通です。一度動き出してしまうと、そう簡単には入れ替えることはできません。システムのスイッチングコスト(※)はとても高くつきます。
(※現在利用してる、システム・サービスを別の会社に切り替える際に発生するコストのこと。)

比較内容に主観的な視点が入っていないか、見落としはないか。できる限り自分の出した結論を、他の人に説明し意見をもらって最終的な確認を怠らないようにしてください。

契約締結の際には、契約書をよく確認してください。全て合意できる内容になっていますか？
どうしても譲れないことががここで出てくる可能性もあります。それが決定の最後の作業です。契約書を締結するまでは間に合います。結論を出す前は、慎重に慎重を重ね決定してください。

この比較検討は特に重要なところですので、別の投稿でさらに詳細に説明をするつもりです。

まとめ

一度決めたシステム開発パートナーとは、長いお付き合いになります。最初の開発が済んでも、機能の追加・改善は続くでしょう。安定的にシステムを稼働させるための保守作業も必要です。

私はあえて「外注」という言葉を使わずに、「パートナー」と表現しています。その理由は、システム開発を外部の会社へ委託するという意味ではなく、外部のシステム会社と共同でよいものを作り上げていく、という思いを込めてシステム開発パートナーと呼んでいます。

みなさまの会社も、いいシステム開発パートナーを見つけ、いいシステムを構築し、事業の発展に寄与することを祈っています。