外部システム協力会社の利用時の注意点

今日も、情報システムの構築計画をお手伝いする際に相談されることについての話をします。
「情報システムを構築した際、外部システム協力会社に騙されることが多いんです。なので、見積もりやシステム要件定義の際に参画してください。」という相談をされることがあります。

情報システムを構築する際、外部システム協力会社も、発注者をを騙そうとしているわけではないのですが、システムを構築する際、協力会社が提示する見積金額の提示の仕方についてある程度前提知識がないと、システム会社に騙されたという印象を持つ結果になります。

外部システム協力会社に作業を依頼する際に注意するのは、下記の2点です。

1. 情報 システムを構築する際は以下の5つの作業があり、外部のシステム協力会社は、システム全体の見積もりは、下記の2．要件定義が終わらないとシステム構築全体の金額提示はしてこないこと。

2. 情報システムは、目に見えないものが大半になるので、2 要件定義・3　設計　の段階で発注側の求めるシステムとして、狙ったものがすべて記載できているかを要件定義書・設計書を通して、細かくチェックし、疑問に思ったことはすべて外部システム協力会社に質疑応答し、発注者が必要とするシステムと齟齬がないことを確認する必要があること。

情報システム構築の５つのステップと注意点

情報システムを構築する作業としては、基本的に、下記の５つのステップから構成されます。（情報システム化のアプローチにより、さらにステップがありますが、それは次回以降に説明します。）

1. システム化計画
   システム化の目的、範囲、利用者、スケジュール、社内体制のそれぞれを大まかに定義し、外部システム会社に説明できる資料（システム化計画書）を準備する。

2. 要件定義
   システム化計画書の範囲について、発注者の関係者にどのような機能が必要か？、それらの機能がどの組織にどういう業務で使われるか？をヒアリングし、システムの機能概要、それぞれの機能で必要となる画面の数、機能の複雑性を明確にし、前提条件付きであるものの、システム構築までのスケジュールとシステム構築するまでの金額・システム協力会社の支援体制を見積もる。

3. 設計
   要件定義に従って、システムの細かい機能を設計する。要件定義では、大まかな機能を明確にしているものの、この段階で画面遷移、画面で表示される項目、各画面で表示されるデータを明らかにします。
   なお、要件定義で見積った前提条件から外れる事象が出てきた場合、（例えば、想定以上の機能があきらか　など）この段階で外部協力会社からシステム化全体のコスト・スケジュールの見積りに修正を加えることがあります。

4. 開発・テスト
   設計時に定義された画面遷移・画面・機能に従って、プログラムおよびシステム環境を構築する。なお、システム環境は通常、システムを実際に稼働させる環境に加えて、システムを開発・テストする環境の最低２つの環境が必要になります。そのため、開発環境についてもコストとして含まれているか？というのを確認する必要があります。

5. データ移行・稼働
   ４でテストが行われ、必要となる機能が正しく動いていることが確認された後、システムを稼働させるためのデータをシステムに投入し、稼働させます。

注意が必要なのは、1は発注者側が作成し、2以降が外部協力会社の作業となるのですが、システム化の全体コストを計画を決めるのは、1　システム化計画　2 要件定義　3設計が重要な作業となります。

システム化計画の段階で、いくつかの外部協力会社に見積もり依頼すると思いますが、ほぼすべての協力会社が提示する見積もりは、2　要件定義にかかるコスト、体制、外部協力会社がもっている知見、システム化方針が提案されます。

そのため、発注者は、システム全体のコスト感を理解する前に、どの協力会社を選ぶかを決めないといけないですが、一度、外部協力会社に要件定義をお願いすると、70％近くの確率で、設計以降の作業は、その協力会社にお願いすることになります。

その一方で、システム構築全体の見積もりに関しては、要件定義の作業かが完了しない限り金額は提示されないため、要件定義の段階での金額と、設計以降の金額の想定があまりに違うことによる想定金額の違いが出てきます。これが、結果騙されたという印象になります。

では、その意識のずれの違いを防ぐには、ある程度、システム化計画の段階で、発注者もシステム全体にかかるコストの概算の見通しをもっておく必要があります。（正しく見通すことはできないですが、この金額で納めたいというものは経営者側にはあります。それと大きくずれてしまうと、そもそも情報システムが必要か？という議論になります）
そのため発注者社内にも、ITの知見の持った人を外部アドバイザリーでもよいので、依頼できる人を確保し、要件定義の段階から参画させておくことが重要になります。

見えないものを可視化する

情報システムを構築する場合、発注者の意図とする要求を満たすものがスケジュール通りに作成できているか？があまり見えてこない。ことが発注者の悩みとして多いです。それは、構築されるシステムが、最終的に形になるものとして見えてくるのが、4．テストする段階にならないとわからないことに起因してます。

では、外部協力会社に作業をお願いした段階で、意図としたものがスケジュールどおりに進捗しているかを何で測るか？というのは、下記の方法で測っていきます。

２. 要件定義・設計時
　必要とされる文書の数に対して、発注者が確認済とした文書の数

３．開発時の場合
　開発しなければならないプログラムの数に対して、テスト済としたプログ
　ラム本数

４．テストの場合
　事前に計画したテストシナリオに対して、正しい結果でテストが完了した
　シナリオの本数

これに加えて、システムの品質に関しても4．テスト　の段階で下記の点を測っていきます。
４．テストの段階
　事前に計画したテストシナリオに対して、欠陥が出た数

これらを測ることで、事前に計画したスケジュール通りに終わるか、スケジュールが遅延するかは、システムの規模が小さい場合は、消化率で測りますが、テスト時には進捗とともにテスト中に発見された欠陥の数により、スケジュールが前後に揺らいできます。

テストの段階では、事前に計画したテストの完了予定と欠陥を修正した後でのテストを行うため、プログラムの修正時間と再テストの時間を計算に入れる必要があります。複数の指標を考慮にいれるため、テストでは統計的手法により完了予定を予測します。（その手法については、システム構築論になるため、また別の時に解説します）

基本的に、これらは外部協力会社が作成する文書になるので、発注者はそれらの書き方などは知る必要はないですが、それらの文書・スケジュールを見て、その精度が正しいのか？というのはチェックする必要があるため、情報システムを持つ側の意識としては、多少なりとも文書のチェック能力・スケジュールの正しさなどを評価できる能力は持たなければなりません。

そのチェック能力に不安がある場合は、内部で知見のある社員を探す・その方の協力が得られない場合は、信頼できるシステムの知見がある外部アドバイザーを頼ることで解決することを検討するのがよいと思います。