超上流から攻めるIT化の原理原則17ヶ条
超上流から攻めるIT化の原理原則17ヶ条¶
原理原則 | 行動規範 |
---|---|
ユーザとベンダの想いは相反する | 1. お互いの責任、義務、思いを知る 2. 受注者との役割分担を明確にし、プロジェクトに積極的に参画する 3. システム開発を理解する |
取り決めは合意と承認によって成り立つ | 1. 合意プロセスと承認ルールを明確にし、それに基づいて行動する 2. 良否判断を仰ぎやすい提案を心がける |
プロジェクトの正否を左右する要件確定の先送りは厳禁である | 1. 未確定要件の先送りは厳禁であり、現工程を延ばしてでも確定させる 2. 主要要件の実現の目処がたたないままプロジェクトを進めない 3. 未確定要件によるリスクを早期に低減する施策を打つ |
ステークホルダ(利害関係者)間の合意を得ないまま、次工程に入らない | 1. ステークホルダの合意確認を自らの仕事と心得る 2. 合意を得ないまま開発に入ると、要件定義自体がひっくり返るおそれがあると心得る 3. 合意確認の作業支援はできるが請負(責任)はできないことを明示する 4. ステークホルダが誰か、漏れはないかを確認する |
多段階の見積もりは双方のリスクを低減する | 1. 事業リスクを低減するためにも、多段階見積もりを活用する 2. 見積もりリスク回避のため多段階契約を活用する 3. 要件定義段階では非機能要件に保証できないものがあることを説明する |
システム化実現の費用はソフトウェア開発だけではない | 1. 依頼する範囲、内容を漏れなく洗い出し、提示する 2. 見積もりに含まれる内容と根拠を明確化する 3. 運用・保守も見据えた計画・体制を作る |
ライフサイクルコストを重視する | 1. システムのライフサイクルにわたって投資対効果(ROI)を算定する 2. 業務パッケージを採用する場合は、カスタマイズを前提としない 3. 対象システムの特定をよく見極めて開発技法・環境・ツールを運用する 4. 運用性・保守性を高める提案をする |
システム化の方針・狙いの周知徹底が成功の鍵となる | 1. 情報システム構築の目的を明確にする 2. 情報システム構築の方針・狙いをステークホルダに周知徹底する 3. 方針・狙いを理解して、情報システムを構築する |
要件定義は発注者の責任である | 1. 「我々が要件を決め、責任を持つ」という意識を社内に浸透させる 2. 業務部門とIT部門が、二人三脚で要件定義を進める 3. 要件定義段階で受注者をうまく活用する 4. 発注者側に立った支援を提供する |
要件定義書はバイブルであり、事あらばここへ立ち返るもの | 1. 安易に変更できない「重み」を認識して要件定義書を提示する 2. 容易に回避できない「責任」を認識して要件定義書を受託する 3. 以降の変更はすべて要件定義書をベースとして議論する |
優れた要件定義書とはシステム開発を精緻にあらわしたもの | 1. 機能要件、非機能要件などを漏れなく洗い出す 2. 特に非機能要件の定義で専門家としての支援をする 3. 双方の協力で、システムの総費用を固める |
表現されない要件はシステムとして実現されない | 1. 文書・モックアップなどの手段を講じて、要件を表現しつくす努力をする 2. 行間を読むのではなく、きっちり確認をとって進める |
数値化されない要件は人によって基準が異なる | 1. 双方が協力して、定量化できる要件は極力数値化しする |
「今と同じ」という要件定義はありえない | 1. 現行システムと同じ機能の実現であっても、要件定義を実施する 2. 既存機能だけを見て要件とするのではなく、使われ方まで十分調査し、要件とする 3. 「今と同じ」要件を具体要件まで問い直す |
要件定義は「使える」業務システムを定義すること | 1. 常にビジネス要求の視点から、システム要件の妥当性を検証する 2. シンプルな業務設計を心がける 3. 運用要件を要件定義の中で定義する 4. オーバースペックを是正し、コストショートを進言する |
機能要求は膨張する。コスト、納期が抑制する | 1. 必要最低限のシステム構築からスタートする 2. 要求を抽出する段階と、要件として絞り込む段階を分ける 3. 要件の優先順位付けをする 4. 納期限界を超える開発量と判断したら、段階的可動を提案する |
要件定義は説明責任を伴う | 1. 受注者に要件を正しく説明する 2. 要件を理解して、理解した内容を発注者に確認する |