学習記録：12月19日(水)：はじめよう！要件定義 Chapter-07 ［準備編］全体像を描こう（前編）
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の19日目のエントリーです。
昨日は要件定義からかなり脱線して、家事育児をどうするかを考えてたりしました。結論は 家事育児は生き物、人間のコピーを作れないのと同じ ってことがわかりました。個別に切り出してタスク化することはできても、それは家事育児を生き物として扱ってる人からみたら本質の解決にはならんよ、ということを学びました。
閑話休題。
というわけで、前回の 学習記録：12月18日(火)：はじめよう！要件定義 Chapter-06 ［準備編］企画を確認する（つづき） に引き続き要件定義の学習を進めます。今週はずっとこれです。
Chapter-07 ［準備編］全体像を描こう
どんなものができたら嬉しいのか、を描いていくんだろうな、という予想をしながら読み進めます。
全体像を描くプロセス
企画を確認（プロジェクト仕様）したら、これから作るソフトウェアの全体像（オーバービュー）を描こうとあります。
仕事とは行動と成果がセットなので、という意図で以下の図が書かれているんだと思います。
- 材料：企画
↓ - 仕事：全体像を描く
↓ - 成果：全体像
全体像とは
確認した企画の中の、 「何を」の部分をビジュアルに表現したもの 、コンテキスト図と呼ばれる場合もある。
利用者が何を使ってどうなるのか、を大枠で書いていくのかな、と想像します。
描き方のポイント
緻密さよりも大枠で、とあります。よかったあってたっぽい。
大枠の理解を共有することが主眼であり、この枠を超える要件はスコープ範囲外だということが関係者に伝わるものを描く、とあります。
なるほど、今まで僕はちょっと誤解してたな。全体像を描く＝必要と言われてること全部を「納まるように描く」ことあったなって思いました。
んで、今から作ろうとするソフトウェアのパンフレットを作る、企画から確認したプロジェクトの紹介から、全体像として プロジェクトの成果としてのソフトウェアの紹介 を作っていくことだとあります。
- 材料：企画
↓ - 仕事：ソフトウェア開発プロジェクト
↓ - 成果：ソフトウェア
全体像を描く理由
これは企画を確認する理由とほぼ同じで、 何が出来上がったら完成なのか という問いに こういうものを実現しようとしているんだよ と提示できるようにする、ということとあります。
なので、要件定義そのものじゃなく、その前段階で描かれていて然るべきものである、と。
よくある話
企画書の一部に「実現する機能の例」としてスクリーンショットが貼られていることがあるが、これは断片的であり、全体像ではないし、全体像ではないのに全体像っぽい資料に描くことで、逆に 目に見えない重要な機能が漏れることがある とあります。
で、その重要な機能とは 実現できて当たり前 と企画立案者が考えているためであり、当たり前のことに対しては あーそりゃそうよね って感じでぞんざいに扱うので、重要なのに忘れられがちだよ、と。
結果として、次の要件定義の段階でも大雑把に検討されたり、そもそも忘れたれたりするぞ、と。
要件定義って 企画者と、ソフトウェアを実現する側の当たり前を漏れなく定義するもの だと僕は認識しているので、あーなるほどな、そうだよな、って思いながら読んでました。
なので、指差ししながら「こういうことを実現するよ」と言える状態にする、上空からの俯瞰図を用意する、とあります。
全体像を描く手順
把握できればどんな形でもいいけど、最低限これだけは欲しいよね、ということで解説が始まります。
ソフトウェアを真ん中に置く
- 真ん中に四角を描く
- これが今回作るソフトウェア
というわけで広いキャンパスの真ん中に、ぽつねんとソフトウェアを描きます。
利用者を配置する
ソフトウェアを利用するあらゆる人を描く感じですかね。
利用者が行うことを書く
それぞれの利用者に、このソフトウェアを使って行うことを書き込んでいきます。おお、全体像っぽい。
解説
全体像を逆からいうと このソフトウェアは利用者に対してこういうことを行えるようになることを提供する ことを示すとあります。
細かい機能は書ききれないし、要件定義を進めていくと修正なども出てくるのは大前提、とはいえ 全体像が杜撰だと合意形成が迷走しやすくなります よ、と。
んで、全体像を描いていくうちに、意外といろんな疑問が生じるので、要件定義の前にたくさんのことが確認できる。ゆえに この時点での疑問はしっかり確認を取り、その確認結果を、前行程の企画書、本行程の全体像に反映 させましょう、という内容で、全体像を描く手順が締められています。
この時点ですでに、前工程との回転が始まり、ブラッシュアップがされていくのだな、と認識しました。
読んでみて
なるほどこれをやれば、当たり前を見える化できるな、と思いましたし、発注側の業務の当たり前は、おそらく発注段階で必ず漏れるんだろうなって思いました。
実際に漏れてる要求の方が圧倒的に多いし、以前RFPの仕事をした時も、ソフトウェアを開発する際に必要なもの、という観点でお客さんに接した記憶が蘇ります。
要件定義って 企画者と、ソフトウェアを実現する側の当たり前を漏れなく定義するもの だと僕は認識している、と書きましたけど、まさにこれを漏れなく見えるように落とし込んでいく工程なのだなと思っています。
余談
僕がこの業界に入ったのは1992年、バブルが崩壊したと同時でした。今から見ると、まだまだ旧態依然とした体制だったし、古い言葉の定義から、新しい世界へと一生懸命変わろうとしすぎて、言葉ばかりが一人歩きしていた時期でもあったなあと思います。
が、古いと言っても悪いわけじゃなくて、枯れた言葉や技術って、普通に有用だったりするし、むしろないがしろにしてはいけない筆頭になることの方が多いと僕は思っています。
何が言いたいかというと。
上流工程、下流工程っていう表現はなんだかアレなので別の表現を使った結果、かえってわかりにくい場面が往往にしてあるな、ってことです。
いいんですよね、上流下流で。別にどっちが偉いわけでもないし、使役されるわけでもない。
どっちもがないと何も生まれない。
けど、これも日本的文化なのかもしれませんが、職人気質をずっと引きずっているがために、つまんないところで民族的なプライドが顔を出すのかなあ、などと妄想したりもしました。
余談2
先日の研修でも面白い話が聞けて、英語圏と日本語圏ではそもそもいろんなことが違うよ、ってことがありました。
英語圏の彼ら、特にアメリカは、ジーザスに誓いを立て、自分の言葉と行動と結果に嘘偽りがないことを無意識に証明しながら動いている、というような意味のことでした。それをやることで、死後の世界が約束される、ってのが染みてるんだよと。
だからこそひとつひとつの意味を明確にしていくし、そこに自分は何ができて何ができないのかはっきりさせるし、呼ばれたMTGでの役割やMTGのBefore-Afterの定義が曖昧な場合は「なんやねん」っていうし、などなど、興味深い話でした。
ここはもっと思考を深くして、色々検証したいなと思ってはいますが、主題と大きくそれるのでこの辺にしときます。
別に日本の文化を否定してるわけじゃないんですけど、そう考えた方が自然に仕事ができるよな、という話のうちの1つとして書いておきたかったのでした。
というわけで
小出し小出しにいきますが、研修が終わってその結果をインプットし、アウトプットし、回転させるまでは、しっかりとやっていくぞ。
