学習記録：12月10日(月)：はじめよう！要件定義 Chapter-03＆Chapter-04
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の10日目のエントリーです。
かつ、学習記録：12月1日(土)：はじめよう！要件定義 Chapter-01＆02 の続きでもあります。
たぶん1日目にも言った気がするんですが、現在の業務にも密接に関わってくる内容だし、著者の羽生さんに教えを受けた（主催の勉強会に参加した）身としては、通読して業務に活かさなければならない。
というわけで続きを読み進めてみます。
前回までのあらすじ
第1部 要件定義ってなんだろう？、の以下を読み進めていました。
Chapter-01 要件定義＝要件を定義すること
あらすじというか、書籍から得たものはだいたい以下の2つに集約される気がします。
依頼した人が
— まみー (@mamy1326) 2018年11月29日
出来上がったものに対して
「これならOKです」
と言うために
「何がどうなればいいのか」
ということを明確に定めたもの
なるほど、となる。
人と人とは「簡単には」わかり合えないっていう前提で、っていつも言います
— magnoliak (@magnolia_k_) 2018年11月29日
お互いに驚くくらい思い込みによる暗黙の前提で喋っている
あと、関心があることしか喋ってない
Chapter-02 要件定義の基本的な流れ
クライアントの思いをクライアント自身が外に出すのが要求。 それを受け取ったら、実現可能性を含めて検討し、提案する。 提案には当然プロの視点が含まれているし期待されており、実現できたとしてもより良い方法があれば提案する必要がある。
しかし代替案を出すのは相手を否定することから始まるので、プロセス、理由、伝わりやすさを考えて正しく伝える必要があるよね、と。ここから受けた僕の印象としては、やっぱりお互いに尊敬を忘れないのが大事だなとも思いました。
そしてこのプロセスを繰り返し回すことで要件定義にたどり着くけど、それを面倒臭がっちゃいけない。人間はわかりあうことが難しい。諦めたらダメよ、と。
クライアントとの対話をしていく。そこから全てが始まるよって、要件定義とは お互い良い仕事をしていくための知恵 だよ、というところで、結ばれていました。
では引き続きChapter-03へ。
Chapter-03 定義すべき要件の内訳
ゴールから逆算する
ゴールから逆算するってどういうこと？の解説から入ります。
「目玉焼きを提供する」の例
これがクライアントから出てくる要求である、と理解してます。
- ゴールはこの「目玉焼きを提供する」という成果を出すのがゴール
- 目玉焼きが欲しいから
- 目玉焼きがある、という状態を実現するため
- 目玉焼きを作る、という依頼をコックさんに出す
ソフトウェア開発の場合
要件がないとダメよね、ということが解説されています。実現可能性や代替案を考える前の情報交換かな、と理解しました。
- コックさんの代わりにプログラマ
- 完成したソフトウェアを存在する、という状態を実現する
- では完成したソフトウェアとは？
- 作ってと言われて「はいわかりました」とは言うには情報が足りない
- だって完成したソフトウェアがこの時点でどういうものかわからない
- 要件が足りないよね
要件として必要な内容とは
ここで初めて、要件定義をする、実現可能性や代替案を考えるための情報が揃ってくることになるのかな、と思いました。
- プログラマがソフトウェアを完成させるために必要な情報
- UI
- 機能
- データ
というわけで上記3つの解説に入っていきます。
UI
ユーザーに接するものだよね、そしてそれは現代における概念に寄せるよね、というようなことが書いてあると理解しました。ごくごく当たり前のことですが、古くは帳票、パンチカード、などなど、様々な歴史がありました。
僕のようにそこそこ年齢がいっていると、それら全てを経験してたりします。が、それに囚われず、時代に合わせた表現や概念は重要だなって思います。
- User Interface
- ユーザーに接するもの
- 古くは、画面や帳票
- しかし今は古い概念
- スマホ当たり前の時代だから
- 業務システムでは今でも重視される要項のひとつ
- だがしかし、これ以降はUIといえば画面系、で進める
機能
つまりはソフトウェアにやらせる仕事の総称。コンピュータへの入力から仕事をし、結果を出力する流れである、という基本的なことが書かれており、機能も処理も同じ意味ですよ、とあります。
言葉の定義は大事ですよね。
データ
消費税、なんとか金額、など。ここはさらりと触れて終わってますが、UI（画面）、機能、データ、どれも重要だし、画面とデータは密接だし、色々考えるところあるなあと思いつつ読んでました。
UI、機能、データを定める
この3つの要素が明確に定まって初めて、プログラマはソフトウェアを作れますよ、と。
つまりはこの3つの要素がソフトウェア開発における要件に必要な情報となりますね、と。
余談ですけど、定まってないのにとりあえず作るとかあるなとか、その場合うっかり実装まで行っちゃうことあるよなとか、サクッとモック作って見せるのが最強だよなとか、色々思いながら読んでいました。
で、ここでもゴールから逆算するのが重要なので、大雑把な流れを見ていくことになります。
Chapter-04 3つの要素の定め方
何はともあれUI
そりゃそうだよな、と思うことも、こうまで徹底して解説されると最高の納得感があります。
そもそも何を持って完成したと納得できるのか
と言う問いかけが文中にありますが、ほんとこれを常に意識し続ける必要あるよなって思います。
開発してるとついつい実装に没頭して忘れちゃうことあるし。
作り手がいくら「できました！」と言っても、完成の定義からずれてたり、定義そのものが曖昧なら「完成」を迎えるのは難しいですから。
では完成とはどう確認するのかと言うと
UIを通じてソフトウェアを操作すること
と断言されています。 僕自身にも異論は全くないです。
UIって？
自動車を例にすると、エンジンも回るしタイヤも向きが変わるしブレーキも効きますよと言っても、それぞれむき出しで実装されたら「いやいや普通の人が運転できないでしょこれ」ってなるよね、と。
ソフトウェアも同じで、完成したことを確認できる為にも、操作者が使うことのできるUI でなくてはならない、と書かれています。
心の底から同意します。 利用するのにテクニックや熟考が必要な時点で、UIは破綻してるよな、って常々思います。
操作に対して機能が動作すること
綺麗な画面だろ、でもこれ動かないんだぜ…なんて言語道断。完成したとは言えないよね。 UIを通じて操作すると、期待通り動かないと納得できない。
操作に対してきちんと機能が動作すること
が必要である、と書かれています。当たり前ですけど、自己満足でもいけないし、拡大解釈すると、押せそうな感じになってて押せないとか、押せなさそうなのに押さないと進まないとか、そういうのもダメだよなって思いながら読んでます。
機能に必要なデータが揃っていること
すごく当たり前なことが例に書かれてますが、ネットショップで買い物して注文データが記録されなかったら大変だよね、と。
機能が必要とするデータがきちんと揃っていること
これが必要である、と。
これを必要なこと三人衆の最後に持ってくるのは意味があるのかな。どれもこれも大事だけど、僕自身は 最終的に永続化されるデータ に落として初めて回りだすと思ってもいるので…うん、どれもこれも並列で大事だな。
やっぱりどれかを大事にするんではなく、三位一体で回していくことが重要、要求、要件の検討と提案、を繰り返す、その中の三本柱とも言えるんだな、と一人納得しながら読んでました。
UI、機能、データを決める
このように、ユーザーが何をしたいのか、ゴールから逆算すると言うことは
- 納得する順序を把握して
- それを満たすために必要なことを決めていく
ということだと書かれています。これまたごくごく当たり前ですけど、これを間違って酷いことになった現場やプロジェクト、サービスを結構な数見てきました。
で、完成したソフトウェアという成果をだすための要件を決めるには
- UIを決める
- 機能を決める
- データを決める
大雑把だけど、この流れで進めていくんだよ、と。
じゃあ具体的にこの3つをどう決めていけばいいのか。
UIを決めるとはどういうことか。機能とは具体的にどんなことを定めるのか。
というわけで、第二部からは要件定義の詳細を順番に見ていくことに。今から楽しみです。
要件定義の心がけ
要件定義のために要件定義をするなよ、とあります。
なんのこと？と思わなくもないですが、なんとなく予想もできます。
依頼主が求めること
完成したソフトウェアであり、そのソフトウェアがもたらしてくれる便益である、と。
それを達成し、本当の意味で 完成としての納得が得られる よねと。
便益（ベネフィット）はどう得るの？
実際にソフトウェアが完成して利用し始めないと、つまり運用してみないと判断できないですよね。 ゆえに何はともあれ 完成して利用できる状態にする のがゴール設定である、とあります。
品質は一定以上ないとダメですけど、そのチームの状態（人員、リソース、スキル）、予算、期間を鑑みて、ゴールするにはどうするのかを考えて要件定義をし、チームを作り、開発を進め、リリースしていく。
そうして初めて、クライアントの要求に応えるための第一歩を踏み出せるのだよな、と改めて思ったりしてました。
ソフトウェアを利用できるには何が必要？
ユーザーが使えることが大前提。デプロイですよねと。どうでもいいんですが、デプロイって「配備」って意味なんですね。知りませんでした。
とはいえ、デプロイしたからって言ったって、品質がボロボロじゃあどうにもならん。すなわちテストせねばならんよな、と。
プログラマは行き当たりばったりで作ってもだめだし、要件に基づいて作業せねばならん。 その結果として、一定の品質のソフトウェアができてこと利用できるってことだよなって改めて考えつつ読みました。
ソフトウェア開発プロセス
企画->業務設計->要件定義->設計->実装->テスト->導入->リリース
という一連のプロセスがある。 このプロセスの中には、書籍のスコープから外れる「プロジェクトマネジメント」の理解も必要。 とはいえいっぺんに理解は難しい。
しかし利用できないソフトウェアは無価値。
ソフトウェアを実現するために要件定義という工程が必要。要検定義をせずに後工程に先送り（設計でカバーとか）すると、必ずそこで要件定義は発生するよねと。
定まってないものは作れないし、たとえ先行で作ったとしてもそれは完成には至らないし、出来上がらない、つまり事実上作っていないものはテストできない。テストできてなければデプロイできない。
後工程につなぐための要件定義
であることを忘れるなよ、とあります。
後工程に対する理解を深める
後工程に繋ぐことをおざなりにしたら、それは要件定義が終わってないということ。それで前に進むのは 要件定義のでっち上げ になる。
でっち上げた要件で作ったものは納得を得られないし、ちゃんとできたとも言えない。 そのようにならないためにも要件定義をやり、これなら自分でも作れるぞ、という 後工程への理解 を深める必要があるんだなってことが書いてあります。
後工程の理解を深めない＝不要な人
要件を定義さえすればいい、後工程は実装者が考えるから自分はそれ以降知らなくていい、なんてことで進めた要件定義は実務に耐えられない。
結果、後工程で要件定義をやり直さないとプログラミングできないなら、その要件定義を行った人は無価値である。つまり不要な人員であることを示すことだよね、と。
本当に「ですよね！」と思うことがこれでもかと書いてあります。
でかいプロジェクトあるあるで「要件定義するだけの人」「基本設計書を書くだけの人」「詳細設計書を書くだけの人」「プログラミングするだけの人」「テストするだけの人」「リリース判定するだけの人」「ISOの審査基準を判定するだけの人」なんてのを何度か体験したことがあります。
それに対して公に何かいう気は全くありませんし、ここまで書けば何を言いたいかわかっていただけるとも思ってもいます（笑）
それくらい、工程同士の繋がり、プロセスの繋がり、チームでの様々な共有、などなど、1つの生き物として捉えないと死ねるよな、って思ったりしています。
要件定義は楽じゃない、急がば回れ
簡単ならこの本を読まなくてもいい。でも実際は難易度が高い。その高い難易度、そこからくる後工程の理解不足のギャップをどう埋めるのか。
それこそ後工程との連携であり、クライアント、チーム内で合意形成をしていきながら要件定義をしていく。
これなら進められるぞ、ということを後工程の人と検討しながら進めていく。
実際非常に手間のかかる要件定義。でも後回しにすればするほど破綻する。個人的には1つでも後回しにしたら緩やかに破綻に向かい、一定の境界を超えたらいきなり破綻、くらいでちょうどいいのでは、と思ったりします。
そのためにも、僕の上司のように まずサクッとUI、画面、データをヒアリング してから、 素早くモックに落とし込み、モックベースで要件を詰めていく のって最強なんだろうなあと思います。
急がば回れ。そしてできれば「急がば回りつつも可能な限り速く回る」ためのテクニックは持っていたいなって思うのでした。
読んでみて
UIってただ機能が動けばいいってもんじゃないし、それは操作者であるユーザーが扱えるUIじゃなきゃ意味がない。要検定義のための要件定義するなよ、ソフトウェアを作るのが目的じゃなく、利用して便益をえることだぞ、手間がかかるけど急がば回れだぞ、と言うメッセージが響きました。
— まみー (@mamy1326) 2018年12月10日
要件定義の話でここまでワクワクすることは今まで一度もなかったと思います。スラスラ読める本に出会ったこともなかったし、自分のやってきたことを客観的に振り返ることもなかったと思います。
しかしこの本は、僕にそれらをもたらしてくれています。
読みやすいというのもあるんですけど、1つ1つの言葉の解説、進め方が非常に丁寧で、絶対に脱落させないという強い意志を感じます。
著者である羽生さんの厳しさに裏付けられた優しさみたいなものも感じます。
実はあとがきの一番最後に、本当にシビれるしあったかくなる言葉が直球で書かれていたりします。
僕も書籍でこういうことが言えるような仕事人生を歩もう。とまで思わせてもらいました。
掛け値無しにいい本です。エンジニア、コードだけ書いていたいと思うこともあるかと思いますし、僕もそういう瞬間あります。
が、この本を読むことで、ちょっとだけでも考えや印象は変わるんじゃないかなって思います。
引き続き、読み進めていきます。
