著者の羽生章洋さんより献本御礼。
本書の特徴を一言で言うなら、「これ以上に必要なことはないが、足りていないことは何もない」という絶妙なバランス感です。サラッと読める分量にしているのに、各章を良く読み込んでいくと気付かされることが多く、豊かな行間があります。
要件定義というテーマはとても扱いが難しくバランスをとるのが難しいのに、本書は170p弱でまとめあげている。しかも、イラストも結構多い。この分量で大丈夫なのかと勝手に思ったが、最後のほうではDB設計の話も出てくる。データ設計も要件定義の範囲として捉えているのも、実装を重んじる羽生さんらしいアプローチだし、そこまで考えないと要件として不十分だよねっていう。
以下、僕自身の要件定義のアプローチと照らしあわせてながら、重要だと感じたポイントを書いていきます。
要望と要求と要件を分けて考える
11pに書いてあるのですが、皆さんこれちゃんと意識されてます？ これすげー重要な絵ですからね。羽生さんのOK出たので、キャプチャ画像貼ります。
まとめると、こんな感じになります。
| 要望 |
システムによって叶えたい思い・未来像 |
| 要求 |
要望を叶えるために必要な能力や成果物 |
| 要件 |
要求を満たすために必要な条件 |
要件定義が出来ているというのは、この「要望⇔要求⇔要件」が分割統治されていることが大切です。つまり、要件に落としこむまでに然るべき理由がそこに存在しているか、その要件でなければならない理由は語られているか、そういうことをチェックするには分割統治するしかないからです。やりたいことと、やらねばならない理由と、要求を満たすためにやらなあかんことが分けて考えられていないと、要求自体の間違いに気が付かないことになります。
最悪なのは、間違った要望に対する正しい要件や仕様です。間違った前提ほど怖いものはありません。
要件定義はそのシステムに関わる「全ての」ステークホルダーの要求を可能な限り実現する必要がありますが、その全体像をこうまとめると簡単だよって絵がありました。これはわかりやすい。
システムを中心とし、ステークホルダーでレベル１を作り、その要望をレベル２として書いているマインドマップ、と言いますか。要求一覧表なんかよりもわかりやすい。そのシステムを使うことで別のステークホルダーの負担が増えたり、何かが犠牲になったりするということが、要件定義の過程で結構あります。大抵それが地雷になりますので、早めに地雷を摘むためにも全てのステークホルダーの要求をキチンと整理しましょう。
システム化対象業務の設計ポイント
全体図だけでは設計に移れませんので、ドリルダウンして実際の作業とシステムの関係を明確にしていく必要があります。羽生さんは「行動シナリオ」の作成を薦めています。業務フローとの厳密な違いは正直良くわからなかったのですが、僕の理解では下記の情報が整理された実際のお仕事の流れをまとめたものです。
- その仕事を行う人(役割)
- その仕事の判断・完了基準
- その仕事の受け渡し先
特に自分の仕事が終わった！と判断できる基準が最も大切。知りたいのは行動を決めるための判断基準。その基準を満たせない場合は例外処理やバリデーション対象になる。要件定義の時点でそこまで見ていく必要があります。また、下記の２つも考慮ポイントです。
- 差し戻される場合はどういう時か
- やり直したい・中止したい場合はどうしているのか
この２つも重要なので考慮して下さい。前者は例外処理やバリデーション、後者はCRUDが発生した場合に仕様として足りていないものがないかを確認できます。バリデーションが通っても次の作業に渡せないってこと、あり得ますからね。キャンセル発生とか。受注取って在庫引き当てたけど訂正入ったんで引当を戻して再度引くとか。
この設計したシナリオを元にユースケースが生まれて要件が見え、要件を満たすための仕様を考えるフェーズに移っていく、と。
システム仕様検討はUIファーストで
僕もこのアプローチに大賛成。まずはUIをスケッチしないと。UIが先、データが次。そのUIからこのデータになるには何の処理が必要だっけってのが、プログラム。それは最後。
UIを作りながら作業に必要なデータを洗い出して構成をまとめ、仕事に必要な情報を定義してまとめていきます。一語多義にご注意を。最終的に、必要なのはレイアウトとアクションと生み出されるデータ。これが定義されていないとシステムの機能が正しいかどうか、ユーザーが判断できない。
| レイアウト |
UI部品。タブ、コンボボックス、テキストボックス、ボタン、表など。 |
| アクション |
クリック、スワイプ、キーダウンetcのUIのイベント。 |
| データ |
その画面で最終的に作られる or 表示されるデータ。 |
どの作業中に何をして欲しいかを明確にして、ユーザーが何を判断してどんな仕事を完了したいかを詰めていくのが良いと思います。これがこう出来ていればあなたのお仕事は完了できますよね〜っていうアプローチ。
UI設計は入力系の画面から。まずは何を入れるかを先に決めないと。マスタメンテじゃなくて、行動シナリオの中で受け渡して流れていく情報を作って保存するための画面のUI設計からはじめて下さい。いきなり帳票設計とかやめてくださいね。インプットが決まらないのに検索項目の話とかしないでね。
UIを決める→データを決める→そのデータを作り出すためのプロセスを決める、という流れで僕はいつも考えています。
要件定義は困難だけど楽しい
読み進めていく内に、僕自身の要件定義のアプローチを再考したことで、書評の半分が「オレはこうやって要件定義を進めている」話になってしまいました。要件定義は困難な作業だってことを改めて思い知らされましたが、楽しい工程です。
要望から最終的にシステムに落とすためにはこれだけのことを考えないといけないってのを最大限コンパクトにまとめてあり、UIもデータも定義していなければエンジニアに実装の依頼が出せないよねって「しっかりと」書いてあるのが誠実で良いと感じました。
エンジニアの方には「この要件定義は出来損ないだ、何も作れねぇよ」と間違った要件定義をガツン！と是正して欲しい。ユーザーの方には、エンジニアがシステムを作るに何が必要なのかを知って欲しい。共通言語がないと善し悪しが伝わらないので。そのために、本書をあたってもらいたいと思います。
皆さんのプログラムが最大の効果を発揮するために、良い要件定義が出来ますように。
