【重複】■ 超上流の重要なポイントを短い言葉でまとめ、原理原則17ヶ条とした。
原理原則【1】 ユーザとベンダの想いは相反する
原理原則【2】 取り決めは合意と承認によって成り立つ
原理原則【3】 プロジェクトの成否を左右する要件確定の先送りは厳禁である
原理原則【4】 ステークホルダ間の合意を得ないまま、次工程に入らない
原理原則【5】 多段階の見積りは双方のリスクを低減する
原理原則【6】 システム化実現の費用はソフトウェア開発だけではない
原理原則【7】 ライフサイクルコストを重視する
原理原則【8】 システム化方針・狙いの周知徹底が成功の鍵となる
原理原則【9】 要件定義は発注者の責任である
原理原則【10】 要件定義書はバイブルであり、事あらばここへ立ち返るもの
原理原則【11】 優れた要件定義書とはシステム開発を精緻にあらわしたもの
原理原則【12】 表現されない要件はシステムとして実現されない
原理原則【13】 数値化されない要件は人によって基準が異なる
原理原則【14】 「今と同じ」という要件定義はありえない
原理原則【15】 要件定義は「使える」業務システムを定義すること
原理原則【16】 機能要求は膨張する。コスト、納期が抑制する
原理原則【17】 要件定義は説明責任を伴う
【重複】原理原則17ヶ条の構成
原理原則条項: 原理原則は「超上流」において必要とされる事柄を、格言のように短く表現したもの
基本的な考え方: 原理原則を理解しやすくするため、原理原則の基になる考え方を説明したもの
行動規範: 原理原則の基づいて、受注者・発注者のそれぞれが具体的にどのように行動すべきか示したもの
【重複】原理原則【1】 ユーザとベンダの想いは相反する
ITシステムの企画・開発の現場では、ユーザ企業とベンダ企業の相反する想いがあります。例えば、ユーザ企業は、要件はできるだけじっくり詰めたいし、予算は早期の投資判断を求められるので最終費用を早く確定してほしいとの想いがあります。他方のベンダ企業の想いはまったくその逆です。これがお互いにとってそもそもの不幸の始まりとなります
開発規模(工数)に見合った、最低限の工期を確保できなければ顧客満足を満たす開発はできません。受注者には開発規模に見合った工期を主張することが求められます。
【重複】原理原則【2】 取り決めは合意と承認によって成り立つ
【重複】原理原則【3】 プロジェクトの成否を左右する要件確定の先送りは厳禁である
要件定義は開発全体の成否を左右重要な工程です。曖昧な要件のまま開発が始まると、プロジェクトが失敗するリスクが大きくなります。
特に、システムの出来を左右する要件に高いリスクを抱えたまま、プロジェクトを進めることは危険です。あせってベンダに開発を依頼しても、先に進めず、かえって時間・コストがムダになることもあります。
解決の目処が立つまでは、先に進まない勇気も必要です。
【重複】原理原則【4】 ステークホルダ間の合意を得ないまま、次工程に入らない
プロジェクトを起こした業務企画担当者は、プロジェクト責任者として、これらステークホルダの方針、意見、課題などについて、漏れなく綿密に把捉し、できることとできないことをIT担当者、ベンダとともに切り分け、業務要件として取りまとめていく責任を果たす必要があります。
ステークホルダもまた、システムの供給側に立つ場合は、積極的にシステム開発要件の策定に参加し、利用者ニーズを確実に把握して、正確にシステム機能に反映していくことが必要です。
【重複】原理原則【5】 多段階の見積りは双方のリスクを低減する
不確定要素が多い中での見積りをプロジェクトの目標値として設定すべきではありません。
あいまいさがある段階の見積りを、はっきりした段階で見積り直せるルールづくりなどがプロジェクト成功の鍵となります。
要件の不確定さやプロジュクトの特性・リスクに応じて、適切な契約方式(多段階契約、インセンティブ付契約など)を選択することにより、発注者・受注者の双方にメリットが生まれます。多段階とは、受注先をその都度変えるということではなく、固まり具合に応じて見積り精度をあげていこうということです
【重複】原理原則【6】 システム化実現の費用はソフトウェア開発だけではない
【重複】原理原則【7】 ライフサイクルコストを重視する
【重複】原理原則【8】 システム化方針・狙いの周知徹底が成功の鍵となる
【重複】原理原則【9】 要件定義は発注者の責任である
要件定義とは、どのようなシステム、何ができるシステムを作りたいのかを定義することです。それはあくまでも発注者の仕事であり、発注者の責任で行うものです。要件定義があいまいであったり、検討不足のまま、受注者に開発を依頼した場合、その結果として、コスト増、納期遅れ、品質低下を発生させるおそれがあります。その責任を受注者に負わせることはできません。
受注者が支援する場合であっても、要件定義で作成した成果物に対する責任は発注者にあります。
【重複】原理原則【10】 要件定義書はバイブルであり、事あらばここへ立ち返るもの
【重複】原理原則【11】 優れた要件定義書とはシステム開発を精緻にあらわしたもの
【重複】原理原則【12】 表現されない要件はシステムとして実現されない
【重複】原理原則【13】 数値化されない要件は人によって基準が異なる
【重複】原理原則【14】 「今と同じ」という要件定義はありえない
「今と同じ」でも要件定義は必要です。
そもそも同じでよいなら再構築する必要はありません。よくないから再構築するというところから発想したいものです。
現行システムの調査をする場合は、システムの機能を洗い上げ、新システムの実像を明確にするだけでは不十分です。現行システムをどう使っているか、という点から調査をしなければなりません。
「そもそも今の要件はどうなっているのか」を問い直し、場合によっては具体的な要件にまで導くことも必要です。
【重複】原理原則【15】 要件定義は「使える」業務システムを定義すること
要件定義は、業務にとって「使える」、「役に立つ」、「運用できる」システムを定義することです。
発注者は、それまでのやり方にとらわれることなく、むだな業務や非効率な手順を客観的に評価し、新業務をゼロベースで再設計することが大切です。
要件定義の場に参加して、議論が横道にそれたり、枝葉末節に陥らないように助言するのは受注者の役割です。また、受注者は、要件として定義したものが、システム化計画で想定したコストや期間と比べて過剰なものや、逆にあまりに多くの費用を要さずとも実現可能な要件は勇気を持って変更を進言しなくてはなりません。
【重複】原理原則【16】 機能要求は膨張する。コスト、納期が抑制する
【重複】原理原則【17】 要件定義は説明責任を伴う
システム開発における万全なる準備は、正確な要件という情報の次工程に向けての伝達です。自分が次工程に伝える必要のある情報について、要件確定責任だけでなく説明責任を負う必要があります。
システム開発の受託側から見た原則は「受託した要件として、書いてあるものは実現させる。書かれていないものは作らない。」ことです。
もちろん、プロジェクトのスタート地点で、すべてを誤りなく責任をもって確定することはできません。「要件の行間を読め」ということを要求してはいけません。
基本的には当たりまえの前提や例外処理であっても漏れなく伝達する必要があります。