ごきげんよう、Zei(ゼイ)です。
個人開発をするにあたって、「個人開発ではありながらも、しっかりとシステム開発のプロセスを踏んで形にしていこう」と決意しておりました。
前回要求定義とは何ぞやをまとめましたが、今回はさらに要求定義を深堀します。
一番時間がかかり、かつプロジェクトの成功を左右する『依頼者と開発者の協議』をまとめました。
以前の要件定義とは何ぞや記事↓
【【依頼者も開発者も大事な工程】要件定義は何をすればいいの？】
以前の決意した記事↓
【超個人的なWEBアプリを作りたい】
システム開発の工程全体を説明している記事↓
【システム開発の流れと開発手法を知ろう】
良いシステムを開発するための要求定義のために、依頼者と開発者の話し合いを深堀しています。
参考はこちら
家づくりで理解する要求明確化の勘どころ ～システム構築を成功させる要件定義のポイント～[5.09 MB]
要求定義を用意した前提で進めています。
テンプレートはこちら
初期要求（ニーズ）を明確にする
依頼者のシステムに対する希望を聞き出す
- 既に存在する要求をまとめる
- 企画・構想の立案時の要求をまとめる
- 実態の把握
スタート時の要求(初期要求)を明確にし、ここからさらに変化したことを明確にする必要がある
要求抽出：どんなシステムを作るかの前に、どんなことをしたいか
新しいシステムを導入することで業務や経営をどうしたいのか、
『どんなことをしたい(どのような業務にする)か』にフォーカスを当てる。
「これ作りたい！それもあれも！」とわっさわっさと要求を出したとしても、
本当の要求が不明瞭になってしまうため、作る！ではなく、こうしたいをまとめる。
※あくまでシステムは業務を遂行する手段である。
ビジネスプロセスが変わらないIT投資は認められない。
現状の把握とTo-Beの変化の明確化『As-Is/To-Be分析手法』
- As-Is/To-Be分析手法を用いる
- 現状の把握・分析を行い、何がどれくらい良くなるか明確にする
※要求を精査すると意外と現状と変わらないことがよくある。
要件定義は何を作るかをただただ聞き出すだけではなく、
何がどれくらい良くなるかなど、依頼者の課題を共に考えるビジネスアナリストの資質が必要。
ステークホルダを洗い出す
誰が関係者なのかを明確にする
みんなみんなステークホルダ、このシステムに関わる人は全員ステークホルダ。
システムを開発するにあたっての関係者を洗い出す必要がある。
- 現場
- 事務部門
- 顧客
- 取引先
- コンシューマー など
ステークホルダを全て洗い出し、そこから要求の抽出、合意形成が必要な対象を選出。
⇒ここを誤ると本当に必要な要求や合意形成が行えない。
ステークホルダ要求を引き出す
ステークホルダから、くまなく要求を収集することが重要。そして要求を整理する。
依頼者当人たちだけの要求だけでなく、関係者の要求も引き出す。
それにより自分たちが意識していなかった要求や、自分たちの要求と衝突する要求も出てくることがある。
声の大きい関係者に流されたり、必要な要求がなかなか出てこないことも起こるので、
特性や傾向を把握し、要求を拾い出す。
非機能要求など、その他の要求を引き出す
- 要件定義工程から明確にする
- 非機能要求とそもそもの要求との整合性を確認する
- 利用時の品質も確認する
セキュリティなどの非機能要求も明確にする。
事業継続や、ユーザビリティ、UXなども考慮する必要がある。
要求の目的展開（要求の妥当性検証）
『なんのため』に『何をよくしたい』のか
- 目的と手段の違いを意識する
- 要求の価値を明確にする
- 営業や業務価値への貢献度を明確にする
始めの「要求(～したい)」は「目的/ゴール(～をよくしたい)」と「手段(～を実行したい)」が混在していることが多い。
⇒それらを整理し「目的/ゴール(～をよくしたい)」を明確にすることが必要。
『それによって何がよくなるのか』と目的をはっきりさせる。
目的から手段を再検討する（要求の充分性検証）
最初の手段に縛られる必要はない
目的を明確にしたので他の手段も出てくる。
最初の手段だけではなく、効果の高い手段を探す。
要求を厳選
営業や業務への貢献度(価値)で絞りこむことにより、複数のステークホルダも納得しやすくなる。
どうしても要求は膨らむものなので、要求の価値(効果)を照らし合わせ貢献が少ない(効果の小さい)要求を、勇気をもって切り捨てる。
※要求が膨らんで失敗するプロジェクトは意外に多い。
潔く切り捨ててしまった方がいいこともある。
制約・前提条件を明確にする
制約（コストや納期など）の洗い出し
- 制約条件と前提条件は混同しない
- 制約条件を明確にし、前提条件を設定する
- 前提条件はリスクを伴うので、随時監視し、見直す必要がある
プロジェクトでは変更できない外からの条件
- 予算
- 納期
- 契約事項
プロジェクトで確証なく設定した条件
- 業務知識がある
- すぐに答えを変更できる
- 人のリソースは確保できる など
制約条件や前提条件を洗い出し、この条件の中で要求が実現できるかを検討する必要がある。
制約条件や前提条件を考慮した実現性の検討
- パッケージや既存サービスの利用を検討
- パッケージ・既存サービスの利用には注意も必要
- カスタマイズ要求を極力減らす
全ての機能を要求に合致するように作りこむのではなく、既存のサービスやパッケージを利用し、一般的な要求レベルで妥協させることと、費用や品質を担保する方法がよく用いられる。
※最大のコストダウンは『作らないこと』
全てを一から作成するのではなく、既存物をうまく組み合わせることを考える。
要求の優先順位付け
- 膨らむ要求を抑える
- 経営や業務への貢献度だけではなく、総合的に評価する
(費用・現実性・緊急性・必要性etc…)
予算・期限が守れるように要求を絞り込むことも必要になってくる。
要求を絞り込むだけではなく、さらに優先順位をつけ、いざとなったら今回は外す。という合意をとることも必要だったりする。
高価やコストだけではなく、あらゆる視点から比較する必要がある。
変化と価値をまとめる
- 実現する要求、断念する要求、稼働後以降に対応する要求を明確にする
- 説明資料を準備する
- 現状の問題点、対策、変わるところ、効果、保留中事項をまとめる
「To-Be 業務の確認」をする。
色々増えたり減ったりした要求を最終的に整理して再確認する。
初期要求とかなり変わっていることもある。
結局どうなったのかを要件定義のまとめとして整理し、まとめ結果を確認してもらう。
ステークホルダと合意形成する
- ドキュメントはスケジュールの半分までに作成する
- 要件定義は時間がかかるもの
- それでも要件の決まらないものが残る
関係者(ステークホルダ)の合意形成が重要。
ここをおろそかにすると後からの仕様変更や使われない機能の作りこみになってしまう。
要件定義が遅延する理由は合意形成に時間を要するから。
それを踏まえて要件定義のプロセスを組む必要がある。
要件(仕様)として定義
- 仕様として要求を具体化
- 既存と同じでも仕様を提示
- 抜け、漏れ、曖昧なくドキュメントを記載
要求を具体化し『仕様』として作成しないといけない。
現行踏襲要求も仕様として提示する必要がある。
現在のシステム開発は・・・
昨日の完全性よりスピードが大切
60点や80点で素早く作り、運用の中で評価、徐々に成長させ90点に上げていくことが重要。
コラムからの面白トピック
ちょこちょこコラムが入っていたので私的に興味深かったものをピックアップ
これからの「要件定義」の話をしよう
IT システム開発失敗原因の 80% は要件定義に起因している
家づくりで理解する要求明確化の勘どころ ～システム構築を成功させる要件定義のポイント
⇒依頼する際は要求定義の段階でも、しっかり自分らの希望を明確にしておきたいと思いました。
自分が要件定義をする際は、気を引き締めて挑みたいと思いました。
「システム機能」はビジネスの成功を実現する「手段」でしかない。経営や業務に影響を
及ぼす要求をリストアップし、「それを実現することでビジネスにどのくらい貢献できるか」
の視点から検討することが重要だ。家づくりで理解する要求明確化の勘どころ ～システム構築を成功させる要件定義のポイント
⇒システム機能をああしたい、こうしたいではなく、これでビジネスをどうするかのマインドにする必要がある、忘れないようにしていきたいです。
「とりあえず始めて実世界で評価しながらシステムを成長させていく」「評価してダメなら潔く諦める」という“柔軟”な姿勢
家づくりで理解する要求明確化の勘どころ ～システム構築を成功させる要件定義のポイント
⇒絶対完璧なものを作らないといけないと感じていましたが、そうでもなく、一旦リリースしてみて様子を見ながら成長させていく。という考えがあったので気が楽になりました。
高難易度な機能は、意図的に人に委ねたほうがよいことがある。
「それは本当に必要か？無理にシステム化するより人で実施したほう
がよいのでは？」をしっかりと見極めよう家づくりで理解する要求明確化の勘どころ ～システム構築を成功させる要件定義のポイント
⇒人の介入の方がミスが出ると思っていたのですが、『意図的』には意外でした。
全部全部盛りしなくてもいいのかと、こちらも気が楽になりました。
「漏れ」「ヌケ」が発生するメカニズム
「知を獲得する」（他者から文書や言葉などの“媒体”を使って『知を』受け取る）
「知を伝達する」（他者に文書や言葉などの“媒体”を使って『知を』伝える）
「知の獲得」では 3 つ、「知の伝達」では 2 つのギャップを発
生させる“落とし穴”がある。家づくりで理解する要求明確化の勘どころ ～システム構築を成功させる要件定義のポイント
- インプット自体が漏れている※知の獲得
- 引き出せない※知の獲得
- 理解できていない※知の獲得
- 表現できない※知の伝達
- 伝達できない※知の伝達
このコラムはぜひ読んでほしいです。
通常の業務でも、というより、コミュニケーションで大事なことだな～と感じました。
感想
読んでみて、すごく良かったです！！
これだけ読むとシステム開発ってより、コミュニケーションだなと感じました。
開発技術をもって、依頼者とより良いシステムを作るための協議。
技術だけ持っていてもダメで、ペラペラお話しできるだけでもダメで。
相手に寄り添う気持ちと、
自分が持っている開発技術で相手の問題をどう解決するか、
自分の持っている開発技術でもどうしても難しいことは諦めてもらうとか。
どんなにITが進んでも、結局は人がシステムを作るわけで、人の想いありきだと感じました。
コメント