はじめに
日々、システム開発をする上で、開発内容について納得感を持って進めたいと思っています。
どのような観点で要件について考えれば、納得感を持てるのかまとめました。
要件例
TODOアプリを例にして、各観点について説明していきます。
このアプリは世の中の課題解決をスムーズにすることを目的としており、
課題とゴールを入力するフォーマットが特徴です。
要件の実現にかけてもいいコスト感はどれくらいか？
ビジネスとしてサービスを提供する以上、適切なQCDでシステムを開発することが求められます。
あらかじめコスト感について合意することで、ビジネスとして成立するラインの指標を把握します。
コスト感を超過するとき、仕様やシステム設計を作り込み過ぎていることを検知できます。
そのコスト感の程度や根拠によって、ビジネス全体における目的の重要度について把握することができます。
例）
- 早く世の中に出すことでフィードバックを受けることを優先して、1ヶ月のコスト感としたい。
期待される成果は何か？
ビジネスとしてサービスを提供する上での指標があるはずで、
今回の要件を実現することでどの指標に寄与する成果を出すのかを把握します。
ビジネスの戦略の中で今回の目的や要件を位置付けることができます。
例）
- KPIとして掲げている利用者数の向上に寄与する。
- 課題解決の研修事業を展開する上で、補助教材となるアプリを開発したい。
要件が前提としている事実は何か？
前提を洗い出すことで、目的の背景や思い描くストーリーや世界を聞くことができます。
例）
- 課題とゴールを明確にして行動することで、世の中の課題解決がスムーズになることが前提としてある。
その事実は十分に検証されているか？
前提とする事実について、根拠の有無を把握し、目的をより明確に知ることができます。
- 十分に検証された事実をもとに成果を出したい
- 前提となる事実を確実なものにするための検証をしたい
例）
- 上記の事実は課題解決の論文を根拠としており、その論文で検証されている。
- 検証された事実をもとにした要件なので、成果を出すことを目的としている。
目的を達成するために他に検討したことは何か？
目的を達成するための手段はいろいろあるはずです。
他の手段を検討する中で、目的を達成するためによりコストがかからない手段が見つかるかもしれません。
検討内容と不採用理由について明らかにすることで、今回の手段がよりよいものであることの納得感を得ます。
手段について検討することで、別の前提としている事実が得られたり、
各手段を比較することで、今回の手段のメリットやデメリットが見えてきます。
例）
- TODOアプリという手段が適切か？スケジュール管理アプリのアドオンの方が使ってもらえるのではないか？
- フォーマットを設けることで本当に目的を達成できるのか？形骸化しないか？
要件によるリスク
要件によるリスクを把握することで、最悪の事態が発生したときに緊急で対応することへの納得感を得ておきます。
- 期待通りに動作しないときの影響
- スケジュール通りにリリースできなかったときの影響
まとめ
以上の納得感を得ることで、やらされてる感がなくなります。
また、その要件の背景や考え方に対する深い理解につながると感じました。
やらされてるどころか、よいサービスを提供することに対して貢献している感覚を持てます。
明日は @weakboson さんの「docker build を使わずコンテナの中身をいぢる」です。お楽しみに！