超上流から攻めるIT化の原理原則 17ヶ条

http://www.ipa.go.jp/files/000005109.pdf

ユーザとベンダの想いは相反する

ユーザ企業
  • 要件はできるだけじっくり詰めたい [後回し]
  • 予算は早く投資判断するため、早く欲しい [前倒し]
ベンダ企業
  • 要件は一刻も早く確定したものが欲しい [前倒し]
  • 予算はリスクがあるので、なるべく後に出したい [後回し]

取り決めは合意と承認によって成り立つ

全ての取り決めは、承認ルールを明確にして、実施しなければなりません。
誰が承認するか、どのように承認するかを明確にするとともに、承認の証跡を残すことです。

プロジェクトの成否を左右する要件確定の先送りは厳禁である

これは皆がわかってる事なんだけどできないって感じだ。

当初のスケジュールを絶対視するあまり要件確定が曖昧なまま進むケースが多い。
結果から見れば、今リスケするのか、後々になって大幅にリスケするのかの違いでしかないっと説得するしかないように思える。

スケジュールに幅を持たせるとかいった方法もありだな。
最短で5人日、最長で8人日。
5人日目で進捗確認して8人日を超えそうならリスケといった方法が柔軟そうだ。

ステークホルダ間の合意を得ないまま、次工程に入らない

ステークホルダ一覧表がいるな。
各工程ごとに浅い出さないとダメだな。

これが可視化できると相当な価値がある。

多段階の見積りは双方のリスクを低減する

要件の不確定さやプロジェクトの特性・リスクに応じて、適切な契約方式(多段階契約、インセンティブ付契約など)を選択することにより、発注者・受注者の双方にメリットが生まれます。

システム化実現の費用はソフトウェア開発だけではない

見積り範囲がソフトウェア開発のことだけを指しているのか、インフラ整備(システム基盤整備)などのような付帯作業も対象にしているかなど、スコープを明確にしていくことが大切です。

データ移行や外部連携は見積もりから抜ける事がありそう。

ライフサイクルコストを重視する

明言のオンパレードだわ。
良いことしか言ってない。

対象業務と扱う情報を分析し、それに合った開発技法を適用すべきです。

これが好き。

システム化方針・狙いの周知徹底が成功の鍵となる

システム化の目的はコンピュータやプログラムではなく、事業目標を達成するための情報システムの構築なのです。

要件定義は発注者の責任である

要件定義とは、どのようなシステム、何ができるシステムを作りたいのかを定義することです。
それはあくまでも発注者の仕事であり、発注者の責任で行うものです。

そもそもこの認識を植え付けること自体が難しい。
この資料をもとに説得していくしかないのかな。
この認識は発注者側の経営層に理解してもらわないと後々ややこしい事になりそうだ。

発注者の教育も工程に含めて印鑑が欲しくなるな。

要件定義書はバイブルであり、事あらばここへ立ち返るもの

ステークホルダ間の合意は、名目的な合意ではなく、実質的な合意であることが不可欠です。

これは色んな事に応用できるな。
プロジェクト体制図に名前だけいる人間とか、これに近い。

優れた要件定義書とはシステム開発を精緻にあらわしたもの

非機能要件はもっと意識しないとダメだな。
これは質問して意図を吸い上げて適切なサービスなりを提案するといった高度な事をしないといけない。

これができたら一流だろうな。

表現されない要件はシステムとして実現されない

システムは情報世界のものなのでトラブルになりやすいんだろうなぁ。

内部設計書レベルのものを発注者にレビューして貰い承認を得るのが一番なんだろうけど、そこまでできる発注者はいるのだろうか。
密に確認をとるしかないのか。

数値化されない要件は人によって基準が異なる

まさしくその通り!
定量化していく作業だ。

「今と同じ」という要件定義はありえない

「同じ」という言い方が正しく伝わるのは、具体的なプログラム、コード体系、テーブルなどそのとき存在する個別の形を持ったものについてです。

確かに。
ユーザが言う「同じ」は画面なのかタブ移動の順序なのか人それぞれだもんな。

要件定義は「使える」業務システムを定義すること

発注者は、それまでのやり方にとらわれることなく、むだな業務や非効率な手順を客観的に評価し、新業務をゼロベースで再設計することが大切です。

一つ踏み込んだ内容だ。
これが出来れば素晴らしい。

業務を俯瞰して、どこまでをシステム化すると良いって判断できる人間って、そうそういそうにないけどね。

機能要求は膨張する。コスト、納期が抑制する

限られた「期間」と「コスト」の中で必要な「機能を実現」して、初めて評価されるということを忘れてはいけません。

ここの内容は具体的で素晴らしい。
削る作業は必要だ。

要件定義は説明責任を伴う

システム開発における万全なる準備は、正確な要件という情報の次工程に向けての伝達です。
自分が次工程に伝える必要のある情報について、要件確定責任だけでなく説明責任を負う必要があります。