◆本論の目的
経営情報戦略を企画する際、ＩＴコーディネータが注目すべき品質には大きく３つあります。
１、契約品質（ベンダーとお客様との約束の仕方の品質）
２、プロセス品質（ベンダーの仕事の進め方の品質）
３、プロダクト品質（開発したソフトウェアの品質）
特に安価でいいかげんなシステム開発では、この３つが守られていないことが数多くあります。いいかげんなソフトウェアによって被害をこうむるのは依頼者側です。ソフトウェアを導入して便利になるはずが、慣れないシステム用語に追われながら、プロダクト品質のひどさを立証しないといけないからです。
そこで、契約品質とプロセス品質をチェックし、プロダクト品質がある程度確保できる目途を立てておくことが、ＩＴコーディネータにとっての大きな仕事となります。
擬態的なチェック内容や行動の中には、企業体質を改善するような大きなものもありますが、多くは今すぐ見直せることや実行できることです。そうした積み重ねの中で品質が向上してゆくのです。
この論文では、経営情報戦略を立案、調達、開発してゆく中で、特に契約品質に焦点を当て、すぐに行動できるチェックポイントを述べてゆきます。
◆１、提案、見積もり依頼時：客観的で明晰な見積もり依頼書を
契約前の確認で手を抜くと、あとでリカバリーすることが非常に難しくなります。特に見積条件書に書く技術的な事項は、経営陣は把握できないことが多いので、技術者の眼で厳しく精査し、ＩＴコーディネータが再確認することが重要となります。特に、思い込みや世間の常識だと思っている用語が、自社内独自の用語であったりする場合があり、そういった部分をＩＴコーディネータがつぶしておく必要があります。
また、契約時に困らないような見積もり依頼の条件設計をしましょう。例えば見積もり範囲に対する認識のギャップ等を防止するように気をつけます。やりたいことはたくさん書くが、「やらないこと」「すでにある機能」については書き洩らすことが多いものです。こうした部分をきちんと書くのは依頼書を書く際のポイントとなります。
◆２、発注者ビューガイドラインを活用しよう
ＩＰＡは、「発注者ビューガイドライン」を出している。これは大手ＳＩベンダー９社が集まって作成した、実践的アプローチに基づく外部設計仕様の作り方のノウハウ満載の資料である。こうした資料に基づいて見積もり依頼や見積書のチェックを行い、提案が触れていない見積もり部分があるかどうかを確認すると漏れが少なくなる。（ただし、見積もるために要求資料が多くなってしまいがちなので、ＩＴベンダーが提案しやすい環境づくりに配慮する工夫も必要である）
◆３、見積書は、数字以上に条件書に注意を
見積依頼書に対して提出された見積書については、数字よりも条件書の方に注意を払いましょう。このときの見積条件がそのまま受注条件となり、最終的には納品物を規定することも多いからです。
品質面からは標準を意識した網羅的な記述があるかどうかを確認し、担保しないものについてははっきりと「担保しない、関知しない、見積もり範囲外、費用別途等」と記載されているかどうかを確認しましょう。
また多くの場合、いくつかの作業フェーズで見積もりを何度か取り直し、精度をあげてゆく必要もあります。これはＩＴベンダーでさえ、要件があいまいな内は正確な見積もりができないからです。
◆４、見積書等に載せる作業工程の設計
ＩＰＡは、「発注者ビューガイドライン」を出しています。これは大手ＳＩベンダー９社が集まって作成した、実践的アプローチに基づく外部設計仕様の作り方のノウハウ満載の資料です。こうした資料に基づいて見積もり依頼や見積書のチェックを行い、提案が触れていない見積もり部分があるかどうかを確認すると良い。
◆５、契約書をよく読もう
開発委託契約を締結する際に、見積依頼時に漏れていた様々なリスクをできるだけ明らかにしておきましょう。複数のベンダーに見積もり依頼をし、各ベンダーから説明を受けると、自分たちだけでは気付かなかった様々な指摘を得ることができます。ですから見積依頼書作成時と契約締結時とでは発注者はＩＴに対する理解が進み、考えが違っている場合があります。
多くの場合、開発委託契約は見積依頼時の条件で話が進む場合が多いのですが、こうした部分を考慮して契約を締結すると、リスクが低減されるなどして、発注者、ベンダーの双方にとってメリットが出てくる場合があります。
また、開発形態も大きなポイントになります。受託、準委託、派遣等の形態をうまくつかい、開発リスクをヘッジすることも可能です。
◆６、スケジュールと役割分担は特に重要
契約書にはマスタースケジュールや役割分担等の主要ドキュメントを参照する場合があります。そこに載っている事項は作業工程も含め、重要な契約要素になるので、ないがしろにしないようにしましょう。参照される主要ドキュメントがしっかりしていれば、後工程でトラブルが発生したとしても責任の所在が明確になり、大きく揉めることがありません。
◆７、責任の所在、特にコントロール責任は誰
開発の当初は、とかく仕様変更が起こりがちです。特に開発期間が短く「仕様変更する時間はほとんどありませんよ」とベンダーに言われたプロジェクト等では特に注意が必要です。発注者側の誰が仕様変更を承認するのか、現場の意見をどの程度取り入れるのか、これが開発が混乱するかしないかの大きな差となります。
◆８、その他契約書締結前に確認すること
その他、問題が先送りになった場合やベンダー側の進捗が遅れている場合はどのようにするのか、どのレベルの品質を誰がどうチェックするのか、責任者と関係がない人が仕様に関して、できる、できない等文句を言ってこないように封じる手段はあるか、担当者が変更になって口約束が白紙に戻った場合でも問題ないか、ＩＴベンダーの能力不足が露呈した場合、どこかで縁を切るタイミングはあるか、お金はどこまで払えばいいのかなど、さまざまな状態を想定して契約書を読み直してみましょう。
◆９、契約締結後
契約締結後、キックオフまでにやるべきことは、プロジェクトの進め方のルールの決定とその説明準備です。システム開発は、契約という大きなルールの中に、契約で決まっていない詳細なルールを作りこんで共同で進めてゆきます。物事の承認、打ち合わせの流れ等は、キックオフ時までにベンダーと認識のずれが無いことを確認してゆきます。それぞれの企業文化の違いから、「議事録」ひとつをとっても全く違うイメージを抱いている場合があります。
新規に契約するベンダーの場合は、ここでズレを発見するようにしなければいけません。ズレが発見されない場合は、ルールが甘いかベンダー側か発注者側のいずれかが管理にルーズになっているはずです。発注側がルールに無関心の場合は、あとで必ずどんでん返しが来るので、ＩＴコーディネータとしてはしっかり押さえておくべきポイントです。ベンダーの挙動が怪しい場合、ＳＥの能力不足が疑われる場合は、議事録ルール等をきっちりと固めて、あとで約束が反故にされないよう、理論武装しておく必要があります。
ＩＴコーディネータ／太田垣博嗣
