僕の要件定義アプローチを整理してみる

あとでメインのブログにまとめようと思うので、軽めに書いておきます。

先日要件定義の手伝いを頼まれたことも踏まえて、少し自分の考えをまとめたいと思います。

コンピュータに出来ることは少ない

最初に訪れる問題は、システムで行えること・達成できることを大風呂敷を広げた状態で考えていないかどうかの確認です。Amazonと同等のレコメンドエンジンが欲しい！って言われても、はいそうですかと出来る話ではございません。

打ち合わせをしていくと「コンピュータに任せればあとはよしなにしてくれる」という空気感は、必ず所々に出てきます。そこを詰めていかないと認識がずれたままなので、いかにコンピュータでやることを具体化出来るかというのが要件定義の最重要課題だと思います。

業務フローを書こう

細かいのは要らん。決めたいのはシステムを利用する仕事の世界地図。見積から受注までの管理が必要なのか、売上のBIを分析したいのか、ネットショップの注文と在庫を連動したいのか。色々あるやろ、やりたいこと。

で、やりたいことは複数の作業の集合体になるから、それを１つずつバラしていくのが業務フローを作る意味。ここで確認しないといけないのはこの２つ。

• その仕事を行う人(役割)
• その仕事の判断・完了基準

特に自分の仕事が終わった！と判断できる基準が最も大切です。その基準を満たせない場合は例外処理になるんだけど、その話は後でゆっくりしよう。今は世界地図を作ることが先だ。何カ国の世界なのかをね。

システムでやりたいことを決めよう

As-Is書いたら次はTo-Beだ・・・って言っても、そんなに仕事の内容は大きく変わらない。ここでは何をシステムにやらせて、何を人間がやらないのかを検討する作業です。システム化したい対象の仕事を決めていきます。これはまだ要望の段階で要件じゃない。やりたいことと、やらなあかんことは、全く別。

この段階でシステムにやらせたい要求がだいたいまとまる。業務フローからシステムの世界地図を作っていける。

ユースケースを書く

システムでやることを俯瞰するために、ユースケースを書きます。どんだけのドメインがあって、どんだけのことを各ドメインでやらなあかんかを決める工程です。ただ、ユースケースを書いてもこの機能が軽いのか重いのか、判断に悩むところです。ユースケースは業務の複雑度を図る指標にはならないことが多いので、あくまで登場人物とシステム化対象のマッピングぐらいしか使えないと思う。

UIスケッチ

UIを書こうね！ワイヤーフレームとかいうんですか？ ま、とにかく実際の画面を構成する要素を決めるため、仕事に必要な情報を定義していきます。業務フローに従って。HTMLのプロトタイプ(紙芝居)を作る。僕はUIファーストです。機能一覧とか要らん。必要なのはUIとアクションとその結果だけ。

業務上の細かい仕様は全部ユーザーマニュアルで吸収する方向で。細かい話って８割がバリデーションだし。

UI設計→DB設計→プログラム設計

インプット決まらないのにプログラムの話するやついないよね。まずは何を入れるかを先に決めないとダメだよね。だからUIが先。次にそのデータの整合性・メンテナンス性を保つために、DB設計をする。DB設計は羽生さんのERD本読めば大丈夫。あの本さえ手元にあれば生きていける。

最後にUIとDBをつなぐ、プログラムを設計する。といっても、設計の８割はModel部分のアーキテクチャ。DB連携部分はORマッパー使うと思うので、そいつを内包しつつ頑張る。ViewとModelを繋ぐ部分についてはスマホ or GUIアプリだとMVVMになるかもしれん。WebアプリだとMVCやね。何にせよ、V→Mはオッケーだけど、M→Vの直接アクセスはダメよ。

アジャイルか滝か

どっちでもええよ。でも、フェーズ分けしたいよね。