IPA-SEC「超上流から攻めるIT化の原理原則17ヶ条」
発注者と受注者の行動規範


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

出典:IPA-SEC「超上流から攻めるIT化の原理原則17ヶ条」より編集