システム開発で後悔しない！開発パートナー評価の秘訣！

前回、システム開発パートナーの選び方の投稿で、システム開発パートナーからの提案を受け、比較検討することについて解説をしました。その際、比較検討については特に重要なところなので改めて説明します、とご案内していましたので、今回はその解説をさせて頂きます。

また、比較検討シートを作成しましたので、よろしければダウンロードしてお使いください。
（→ダウンロードはこちら：比較検討シート）

システム開発パートナーの候補からの提案をどのように評価すべきか分からない、悩んでいる方。

そんな方がこの投稿をご覧頂きますと、システム開発パートナーを選ぶ際に、どのような点に注目し、どう評価すべきかをご理解頂けますのでぜひ最後までご覧ください！

このコラムの内容は動画で公開しています。
「システム開発で後悔しない！開発パートナー評価の秘訣！」Youtube版はこちらをご覧ください。


前回投稿した開発パートナー選定内の、ステップ⑥比較検討にて11項目の検討基準をあげていました。改めて順に説明いたします。

1．提案力の評価

前回の投稿では、提案力を評価するに際して、提案を聞いたとき技術的なこと以外で「なるほど、そういう考え方もあるね」と思ったなら、提案力があるということですと説明していました。とても簡単な説明にとどめていましたので、もう少し噛み砕いて見ていきたいと思います。

そもそも「なるほど、そういう考え方もあるね」と、言えるのはなぜか？そこを紐解いてみましょう。

実際、提案で期待したいのは何かと言うと、自分たちが考えた自社の課題の解決策、それに対して御社の解決策はこうでしたが、この方法を取ればもっと良くなる、ということ。
あるいは、自分たちでは答えが出せなかったことに対して、このようなシステムの仕組みで解決できます、と提案してくれることです。

提案ができるという事が意味することは、問題認識能力に長けている。そして、調査・分析のスキル、加えてクリエイティブ思考ができると言えます。

まず問題を認識できなければ、解決策は出てきません。それも、表面的な問題ではなく、本質的な問題を認識できなければなりません。他社事例、現在の技術を知識として貯えており、問題を分析して、クリエイティブ思考によって、どう解決できるかという提案につなげることができるのです。

例えば、どんな提案かを考えてみました。
自社で会員登録をネットからしてもらいたい。その際は、会員の正当性を担保したい。つまり、違法な会員登録をさせたくない。という要件があるとします。

これは銀行の口座開設のようなケースですよね。そうすると一般的なサイトでの会員登録のようにメアドを入れてどんなメアドでも許可をして、いくつでも会員登録ができてしまう、と言う仕組みではいけないわけです。

じゃあそれを具体的にどうやるのか？
ネットの黎明期だと、フリーメールのアドレスは使わせないなどありましたが、いまはそんなサイトは見かけませんし、その方法では他に問題もあります。例えば、会員登録の際に、免許証やパスポート等本人確認書類の写真を撮って送ってもらって、それで本人かどうか間違いなく確認すると言ったことです。

あるいは学校の制服は、生徒しか購入できないようにするため、受験番号と生徒名、電話番号で承認するという方法があります。こういった仕組みについては1度経験したことがある人であればわかることですが、その経験がない、あるいは忘れてたりするならば、直ぐに解決策が思いつかないわけです。

こういったことに対してこういう例がありますよと提案してくれるパートナーであれば心強いことでしょうし、そんな提案をされたとするならば、評価点があがるのではないでしょうか。

もし、提案ができないパートナーを選んでしまった場合のデメリットは、開発が始まってからの自分たちの作業負担が大きくなりますし、自分たちが考える以上のシステム発展が期待できなくなります。

提案ができないパートナーだと、開発の様々な場面で質問が来ます。仕様を決めるにあたっても、ここはどうしますか、あれはどうしますか？エラーメッセージはどうしますかと言った具合です。そこは自分で考えてほしい、と思う内容まで聞いてきますので、ユーザ側にかかる負担は非常に大きいです。

しかし、提案ができるパートナーであれば、同じ質問においても、まずは自分たちで考え、その上でこのように考えたんですけれどもいかがでしょうか？
あるいは、A案、B案、C案があります。A案のメリットは何、デメリットは何。B案のメリットは何で、デメリットはこうです。我々としては、今回のケースでは、こういう理由でA案をお勧めしますが、いかがでしょうか？と、そんな風に質問を投げてくれます。

これは質問と言いながらも、選択肢を提案してくれる。そうするとユーザとしては、その中から選ぶということだけで済む、あるいはそれらの出てきた案から、自分たちのアイディアをミックスして、新しいものを作り上げていくと言うことができるので、作業負担は軽減され、より良いシステムができる可能性が高まって行くわけです。なので、しっかりと提案力は見極めてください。

2.技術力

開発したいシステムの企画を理解し、上流工程、つまり要件定義から、設計、開発、テスト、運用までの経験が十分にあるかを見るということを説明していました。

提案してくるITベンダーなので、システム開発はあまり得意ではありませんなどという企業はあり得ませんが、どこの工程が得意・不得意かはなかなか口に出してくれません。
　
自分自身の過去を振り返ってみますと、創業したての頃、知人の会社へ営業活動へ行ったときに「何でも開発できます。」と言っていました。そこで返された言葉は、「何でもできる。は、得意分野がないの裏返し」ということ。

確かに、その通りでした。「何でも開発できます」は、仕事が欲しいばかりに出た言葉。もちろん、開発力には自信があったからこそ言った言葉でもありましたが、そうは相手に受け止めてもらえないのです。むしろ、「当社の強みはこれです。ここは弱いですが、このように補っています。」そう伝えるべきでしたし、聞く方も誠実さが伝わるのではないでしょうか。

さて、システム開発の工程には、要件定義、設計、開発と複数工程がありますが、システム開発経験が少ないユーザ側の方ならば、”システム開発”ひとくくりで考えてしまうのではないでしょうか。普段目にするのは、登録フォームのようなプログラムが作り出す画面ですから、プログラムができる会社ならばいいだろうと思ってしまいます。実際、簡単なシステムの仕組みであるならば、ある程度のプログラミングさえできればできてしまうものです。

簡単に言ってしまえば、システムは、複数のプログラムの塊です。だったら1本1本のプログラムができていればいいじゃないか、と言えないこともないですが、実際は一つ一つのプログラムの役割があり、それぞれが連携し合い、全体として整合性が取れて、入力する機器やサーバが一体化して、はじめてシステムとしての体をなすわけです。

そのためには、1本1本のプログラムは当然ながら、設計がしっかりできているのかどうか、そして設計はシステムの要件を反映しているのかどうかといった具合に、開発工程は上流に遡っていきます。これらの工程に対して、それができるエンジニアの数を見てみると、このように三角形の状態です。

実際にこの人数が何人か、というところまでは、統計資料もないので証明はできませんが、少なくともIT関係者としては共通認識となっています。

では、その会社技術力を評価するときに、要件定義や設計、つまり上流工程ができる質の高いエンジニアがいるのか、それは本当なのかと言うことを評価するポイントはどこなのか？
実は私も、これを判断すれば間違いない、と言う確実な答えは持っていません。

仮に上流工程の経験はありますか？　できますか？と、質問したところで、当然イエスと言ってくるでしょう。経験もありますとも言ってくるでしょう。しかし、確実な答えはないとは言え見分ける手段が全くないかというとそうではありません。過去の上流工程に対する経験を聞いてみましょう。

どのようなシステムで要件定義を経験されましたか？設計をされましたか？その時、どんな工夫をされたのでしょうか？
などです。

その際に、気をつけていただきたいことがあります。これはこの件についてだけの話ではなく、相手に対する質問の際、全てに関して言えることなのですけれど、まるで面接官のような高圧的な態度にならないということです。

こちら側が決める側なんだから、遠慮する必要などないじゃないかとも言えるかもしれませんが、もしその会社を最終的に選択することになり、今後一緒にシステム開発をしていく相手となるのであれば、相手側にも選ぶ権利はあるわけで、「なんだかこのクライアントは、随分と高圧的に物事を言ってくる人だ」と思われては、こちらがいいと思ったところで提案を降りられると言う可能性だってあるわけです。

ですから、「私たちはシステム開発の経験が浅いためわからないのですけれども、素人に対してわかりやすく解説していただけるとありがたいです。」と言うようなニュアンスに変えて聞いてみるようにしてほしいです。そうすると、素人に対して分かりやすく説明ができるかと言う点の評価にもつながります。

また、実は得意な工程を見極めるためのなる1つの材料があります。それはその会社のホームページや会社案内を見ることです。そこで、取引先の企業を見てください。

取引先の企業は通常名前が知れたところを優先して掲載します。信頼を高めるために大手の名前が並んでた方が、外部から見ても信用が高まるの当然ですよね。そこで、取引先の企業名に、大手のシステムインテグレータ、同業のシステム会社が並んでいたとしたら？　そこの企業へエンジニアを常駐させたり、あるいはそこから仕事を受けていると言うことですので、多くの場合、開発工程が主体。もちろん、できるエンジニアがいたなら設計・要件定義もありますが、最も上流の工程を任されるということは少ないです。

このように、経験を聞いてみる。あるいは、ホームページの取引先をチェックしてみることで、技術力の評価につなげてみてください。

3.業務知識・専門知識

ここに関しては、ユーザ側の専門分野ですから、提案書のプレゼンの際には、実際に利用する部門の人達の参加を募って見極めましょう。

ただし、注意して頂きたい点があります。例えば、経理システムを作りたくて、経理システムのパッケージやクラウドサービスを提供しているITベンダーから提案を受けるならいいのですが、そうでない場合、業務に関わる専門知識はユーザには適うわけがありません。ですから、細かい質問をし過ぎて、そんなことも知らないのかという判断は厳しすぎます。

業務について話した時に、こんな事が困っているのだけど、システムではどう解決できますか？などと質問してみて、相手の質問に対する理解度や、回答があまりにかけ離れた事を言っていないかと言う点を見てください。

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

開発したいシステムと同様のシステム開発実績があるか、それはどれくらいの数を経験してきているのか。と説明しましたが、大切な点は、そのシステムにどのような立場で関わったのかという点です。

他社が主体で開発しているプロジェクトに、「プログラマとして参加しました。」「テスターとして参加しました。」それですと、システムの全体像を把握しておらず、同様のシステム実績があると言うには厳しいところです。

これが「要件定義だけ行った。」ということならば、それは価値があります。設計から入ったというならば、システム全体のどのくらいの範囲を設計したかによって実績としての価値が上がります。

私流の解釈ですが

• 要件定義、プロジェクトマネージャーとして同様のシステムに参画してるなら、1件の実績。
• 設計で参画してるなら、0．3～0．5件の実績。
• プログラマだったなら、0．1件の実績。

そのくらいの感覚です。このような形で、同様のシステム実績の数を評価してください。

5.開発体制

プロジェクトマネージャー、開発者、デザイナーなどプロジェクトに必要なメンバーが含まれているか。その経験はどうか。ということでした。「そもそもシステム開発に必要なメンバーが分からない」という事もあるかと思いますので、そこから説明をします。

システム開発に必要なメンバーは、システムの規模・種類によっても異なりますが、このような役割の人たちが関わります。

ここに登場した役割は、システム規模が小さい場合、兼務することが多々あります。
10人月ほどの規模であれば、プロジェクトマネージャと、プロジェクトリーダが兼務。システムエンジニアとプログラマが兼務ということはよくあります。

ただし、兼務になりにくいのがデザイナーです。その理由は、システムの設計、プログラミングとデザインのセンスは別のスキルだからです。時にはシステムエンジニアやプログラマが画面のデザインも行うこともありますが、それでいいデザインができあがるかと言えば、難しいと言うのが正直なところです。社内だけで使うシステムであれば、デザイナーがいなくとも役目を果たせる画面にはなるかもしれませんが、WEBやアプリで一般の人たちが使うシステムだとするならば、デザイナーは必須です。

これらの役割のメンバーですが、ITベンダーの規模を問わず、一社だけで全ての必要メンバーを揃えていることが正解ではありません。随分と昔のシステム開発の考え方なら、一つのメーカーのコンピュータ(※)で、そのメーカー独自の言語で開発する以外選択肢がありませんでした。
（※汎用機というコンピュータです）
しかし今や、いやいやもう何年も前からですが、複数社の端末、サーバ、ソフトを組み合わせて一つのシステムに仕上げる事は常識となっています。

ですから、提案の際、複数の企業や、フリーランスとと共同で体制を組むことは、全くマイナスではありません。但し、メンバーはこの案件を受注できたら探します、というのは心もとないので、これまで幾つものプロジェクトをともに開発してきた外部のパートナーとともに体制を組みます、という方が心強いのは間違いありません。

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

システム開発プロジェクト全体を統括するプロジェクトマネージャーは、過去にどのようなシステム・どのような規模のシステム開発を経験しているのかを知りたいところですが、その評価方法は、先に説明した技術力の評価同様、経験に対する質問の回答で判断してください。

しかし、提案時点では具体的にどの人をアサインするかが決まっていないというケースもありますので、その場合は当然評価のしようもなく、会社として信頼するかどうかという判断基準にせざるを得ません。
では、会社の資本金が大きければいいのか、とか、メーカー系列だから安心と言い切れるかというと、そうではないので難しいところです。私としては、やはり契約前には、実際に担当されるプロジェクトマネージャと話しておくべきだと考えます。

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

相性は補足するまでもありません。直接お話をして、相性を確かめましょう。

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

全体の妥当性を判断するには困難ながら、自分たちが関わるこれらの工程が短すぎないかは最低限確認して頂きたいと説明しました。今回は具体的に10人月程度の規模の場合を例にとって説明します。

開発規模が10人月、半年の期間の開発の場合ですと、それぞれの開発工程はこのようになります。

ちなみに、開発規模、つまり開発工数と期間は一致しません。見積工数＝期間とはなりません。それは、各期間、各工程に投入するエンジニアの人数が変わってくるからです。

例えばこの例だと、要件定義に1名、2カ月目から設計に1名入り、3カ月目にさらに設計に1名、開発に1名追加。4カ月目にさらに開発に1名追加、5カ月目はテストに2名、6カ月目に受入テストサポートに1名という具合です。

注意すべきポイントは納期が短いからといって、各工程が重なり過ぎていないかということ。要件定義と設計を同時にはできませんし、設計と開発もまた、同時にできません。先行して設計した機能は、全ての設計が完了する前に開発に入ることはありますが、もし作業工程が重複する期間があるなら、具体的にどのように考えているのかは聞いた方がいいでしょう。

9.保守体制

安定運用、機能追加のためにも保守体制は重要であると前回説明しました。
経験上、最初に開発した機能のままで使い続けることはないと言っていいほど、機能の追加・変更は発生します。どれだけ腰を据えて要件定義、設計フェーズで考え、プロトタイプを作って使用感を試したとしても、実際に使ってみると思ったのと違う、かゆいところに手が届いていないということが必ず起こるのです。

より良いシステムを作る為には、完成後も安定稼働、そして改善を進めるためには、しっかりとした保守体制が必要になるのです。

10.見積もり

見積書の見方・評価については、これだけで結構なボリュームになりますので、また次回に改めてご説明いたします。

11.企業の安定性

開発パートナーとして選定した企業が安定に事業を続けていけるのかを判断する必要性は前回説明したとおりです。

まとめ

開発パートナー選定について、深掘りして解説しました。
例えが適切か分かりませんが、人生のパートナー探しでも、自分の理想全てに合致すると言うのは、なかなか出会えないものかと思います。システム開発パートナーも全ての評価ポイントが満点というのはなかなかお目にかかれないでしょう。

しかし、その中で自分たちが、特にここを補完してほしいという点から、優先順位をつけ、選んで共に開発をして、結局は長い良いお付き合いになったね！と言えるITベンダーが見つかるといいですね。