上流工程で四苦八苦
直近で、上流工程を担当することがあり、「要求定義」や「要件定義」みたいな工程を担当しております。
私自身はこういったかっちりした工程を担当したことがあまりなく、四苦八苦しながらなんとかやっております。
んで、これを機にどういったフェーズかといったことを自分なりにまとめてみようと思います。
そもそもシステム開発とは
私は業界歴自体は10年ちょっとなんですが、手を動かすことが多く、今でもプログラミングが好きです。
そうするとどうしても技術的な部分にフォーカスしがちなのですが、システム開発のそもそもの目的は「ユーザー側の課題解決」になります。
ただ難しいのは「そもそも何が問題なのか」を明確にすることです。
システム開発って目に見えないものをつくるだけに、出来上がってから「こんなんじゃなかった」ってことが頻発しますよね。あるあるなのは、ユーザーの言うとおりにいっぱい機能いれたけどあんまり使わなかったとか・・・
これらを完全に防ぐことは難しいんですが、ユーザーの問題や要望、解決策をまずしっかり定義するのが要求定義と要件定義になります。
フェーズの順序的には以下のようになりますかね。
- 要求定義 - ユーザーの悩みや課題の整理
- 要件定義 - システム化する内容の具体化
- 基本設計・詳細設計・実装...
要求定義とは
目的
(システムと離れて)ユーザーが何に困っているのか、どのような問題を解決したいのかを明確にすること
要求定義は、システム開発以前の段階として、「システム化する前に何が悩みだったんだったけ?」ということを考えるスコープです。
システムから離れてまず何に困っているんだけ?ってことですね。
そのためにはまずユーザーが普段どんな行動をとっているのか?っていう現状を把握するところ(AsIs)から始まります。
具体的な方法
- ユーザーの日常行動の観察: 登場人物が誰で、日常的にどんな行動をしているかを把握
- 課題の洗い出し: 困っていること、悩んでいること、改善できたらいいことをリストアップ
- 丁寧なヒアリング: ユーザーの日常をなるべく詳細にヒアリングすること
そして、これができたら、「次に解決すべき課題はなにか」「どのようにしたらそれが解決できるか」のあるべき姿(ToBe)を定義します。
成果物
- 関係者間の悩みの整理
- 理想像の明確化: AsIs(現在の状況)とToBe(理想の状況)の比較
-
要求一覧: ユーザーの悩みやニーズをカテゴライズしてまとめたもの
- 各要求の背景やニーズの詳細なヒアリング結果を含む
そう考えると要求定義はシステムうんぬんよりはマーケティングに近い領域かなぁと思います。技術的な解決策ではなく、ユーザーの課題を発見することがメインになるので。
この場合、エンジニアの本ではないんですが、マーケティングコンサルの佐藤義典さんの本はめちゃおすすめです。
(今回のケースだと『実践マーケティング思考』がドンピシャ)
要件定義とは
目的
要求定義をもとにシステムとして実現するために具体的な仕様を決定すること
要件定義は「ユーザーの悩みをいかにシステムに落とすか」を決めるフェーズです。
ここはユーザーの悩みや希望がわかっており、それを解決するためにシステムに機能をどう落とし込んで行くべきなのかというフェーズになります。
具体的な方法
- システム化範囲の決定: 要求定義で整理された課題の中で、具体的に何をシステム化していくかを決める
- 業務フローの設計: 業務がどのように流れていくかを整理
- 機能の具体化: システムで実現する機能を詳細に検討
要求定義よりはシステム開発の具体的な機能群の話になってきます。
成果物
- 画面遷移+ユーザーごとのアクション: 業務フロー図
- 大まかなデータフロー
- 機能要件一覧: システムで実現する具体的な機能
- 非機能要件一覧: 性能、信頼性、セキュリティ、操作性など
- システムの概略: 目的や大まかなスコープ、使用される技術を取り決めたもの
- 画面遷移図: おおまかな画面の流れ
- データモデル: 業務上のデータの関連(ER図のもとになっているもの)
要求定義と要件定義のまとめ
まとめると以下のようになりますかね・・・
- 要求定義 = 「何に悩んでいるか」を明確にする
- 要件定義 = 「それをどうシステムに落とすのか」を決める
項目 | 要求定義 | 要件定義 |
---|---|---|
焦点 | ユーザーの課題・悩み | システムでの解決方法 |
アプローチ | マーケティング的 | システム開発的 |
成果物の性質 | 問題の整理・理想像 | 具体的な仕様・設計 |
関係者 | エンドユーザー中心 | 開発チーム中心 |
要求定義段階で重要なこと
- 先入観を持たない: 既存の解決策にとらわれず、本当の課題を探る
- 現場の声を大切にする: 実際にその業務を行っている人の生の声を聞く
- 背景を深掘りする: 「なぜそれが課題なのか」の背景を理解する
要件定義段階で重要なこと
- 要求との紐づけ: 各機能が要求定義のどの課題を解決するのかを明確にする
- 実現可能性の考慮: 技術的・予算的・スケジュール的な制約を考慮する
- 優先順位の設定: すべてを一度に実現するのではなく、段階的な実装を計画する