導入

ユーザーのための要件定義ガイド

情報技術者試験を主催するIPAが公開している要件定義についての資料。

「ユーザーのための」とあるようにシステム開発を依頼する側に必要な視点だが、ユーザーはそもそもそういう考えに至らない可能性も高いので開発者側も知っておく方が良い。

図など込みで7章に分けて500ぺージ近い資料があるので1章ずつすごく雑に要約していく。

今回は第2章

本題

第2章は「要件定義の問題認識」
第1章の焼き直し的な部分もある。
それだけ経営層が要件定義に参加することを強く主張したいのかな、という感じ。

経営層が意識すべきこと

良き構想なくして良き要件定義はない。

構想が悪かったら全部台無し。
不備があるなら整備する時間をかけるべき。

プロジェクトの体制

システム部門にお任せ！じゃダメ。

経営層の参画

経営層がプロジェクトとして思い描いた構想を業務部門に伝えても、業務部門は実務中心で考えてしまう。
本来の目標を理解している経営層が積極的に要件定義へ参画し、確認する必要がある。
「経営層」は社長とかだけじゃなくて企画担当スタッフとかも含まれるよ。

非機能要求

性能や拡張性、および事件や災害時の事業継続性・セキュリティ
企業の社会責任として捉えましょう。

要件定義工程で十分な工期、工数を割り当てる

規模が大きくなったら開発期間全体に対して要件定義の比率が小さくなるデータ

要件定義工程で気付いた修正は作業負荷少ない。
設計、実装、総合テスト、稼働後と工程が先に進むほど修正の作業負荷は大きくなる。
要件定義の工数をケチろうとしない方がいい。

既存システムの現状認識

ブラックボックス化したシステム
「現行通り」は要件定義ではない
「現行機能」を提示できないなら要件定義は終了できない

IPAの提示する17個の原理原則

原理原則[1] ユーザとベンダの想いは相反する
原理原則[2] 取り決めは合意と承認によって成り立つ
原理原則[3] プロジェクトの成否を左右する要件確定の先送りは厳禁である
原理原則[4] ステークホルダ間の合意を得ないまま、次工程に入らない
原理原則[5] 多段階の見積りは双方のリスクを低減する
原理原則[6] システム化実現の費用はソフトウェア開発だけではない
原理原則[7] ライフサイクルコストを重視する
原理原則[8] システム化方針・狙いの周知徹底が成功の鍵となる
原理原則[9] 要件定義は発注者の責任である
原理原則[10] 要件定義書はバイブルであり、事あらばここへ立ち返るもの
原理原則[11] 優れた要件定義書とはシステム開発を精緻にあらわしたもの
原理原則[12] 表現されない要件はシステムとして実現されない
原理原則[13] 数値化されない要件は人によって基準が異なる
原理原則[14] 「今と同じ」という要件定義はあり得ない
原理原則[15] 要件定義は「使える」業務システムを定義すること
原理原則[16] 機能要求は膨張する。コスト、納期が抑制する
原理原則[17] 要件定義は説明責任を伴う

経営者「情報システムの問題はよく分からない」
何について、どんな説明が必要か考えて。
• 当社の本質的問題と関係付けて説明せよ
• 英語の 3 文字単語は使用しないで説明せよ
• 開発上のリスクは何か
• 開発、運用の最適責任者は誰か、成功させる信念をもっているか
など具体的に指示して、内容を理解した上で企画の採否を行う努力をして欲しい。

業務部門が意識すべきこと

経営や業務に貢献する

システムが経営や業務へどう結びついたか。これは業務部門の問題。

ビジネスプロセス改革・改善

業務プロセス自体が変わらないならITシステムを業務に対するサービスとして捉える。
ビジネスプロセスにシステムを組み込む。

業務部門のリーダーシップ

システムからどのような効果を引き出すかは業務部門の責任

現行業務、システムの理解

作業を人、機械、システムに分けるときの効率を考える。
「次のシステムへの要望」「使っていない機能」「今の環境にふさわしくない機能」
をあらかじめ整理した方がよい。

もっと顧客に喜んでもらえる機能や仕組みがないかをヒアリングするのもよい。

合意形成

ステークホルダ方針・意見・課題
できるできないを切り分けて合意形成へもっていく

仕様変更が生じた場合を想定した予算確保

プロジェクトのうち約8割は仕様変更が生じたというデータ
仕様変更予算を10%程度持っていくと円滑になりやすいらしい。

システム部門が意識すべきこと

既存システムの状況の明確化

「システムが動いているならレガシー化していない」と認識する経営層もいる。
システム部門が経営層に課題として認識させる必要がある。

システム部門のパラダイムシフト

要件定義は業務部門責任が基本ではある。
システム部門が主導してIT技術活用を提案していく姿が理想。

これはベンダ側も同様(営業だけに任せるんじゃないよ)

プロジェクトマネジメント

要件定義特有のマネジメント
・膨らむ要求のコントロール
・どうなったら要件定義の完了か
・要件定義の品質をどう担保するか

ベンダ企業の意識すべきこと

要件定義の契約基本形は準委任契約

基本としてユーザー企業主体で進める。
請負より準委任になったことで問題が減少したらしい。

ユーザ企業課題解決貢献

ビジネス変革先行型「ビジネスのためにこんな技術が必要」
IT技術先行型「IT技術で何かできるのでは？」

ユーザの課題は何かを一緒に考える必要

見積り

見積りの誤り
・楽観的　(根拠があいまい)
・早期　(作るものが決まっていない)
・目標と見積もりの混同　(営業や顧客の事情)
・一度決まったら修正されない
・時間に余裕がない　(そもそも短すぎる)

実際作り始めたら見積りの精度上がる。都度見直しが必要。
安くすることに力を注ぎ本来あるべき見積りを見失いがち。

要求仕様の凍結

要件定義があいまいでプロジェクトに仕損が出ることもある。
要件定義完了時点で凍結させる努力が必要。

よくある契約上の工夫
・要件定義後の変更は仕様変更として費用計上
・期間の延長ありうるものにする
確実に決められるようベンダ側が統制し、コントロールする

問題の抽出と整理

ベンダ企業とユーザ企業に要件定義の問題をアンケート

図と表で解決のための勘どころを列挙しているので割愛
ここに関しては原典を読んでほしい。