学習記録：12月20日(木)：はじめよう！要件定義 Chapter-07 ［準備編］全体像を描こう（つづき）

これは 俺のインプットアウトプット記録 Advent Calendar 2018 の20日目のエントリーです。

昨日は全体像を描く手順として、アプリケーションを真ん中に置いて、登場人物とやることを書き込んでいく、というところまで進みました。 結果、ソフトウェアが利用者に提供するものが見えることで、迷走しにくくなる、取りこぼしが減る、という感じだったかと思います。

今日もみっちり要件定義の研修を受けてきて、一昨日以上に濃密なインプットを得てきたところです。毎回発見があるし、毎回腑に落ちるし、確実に自分が前に進んでいるな、って実感できるのは幸せなものです。

この研修、有料であるにも関わらず受けさせてくれる代表には本当に感謝です。

閑話休題。

というわけで、前回の 学習記録：12月19日(水)：はじめよう！要件定義　Chapter-07 ［準備編］全体像を描こう（前編） に引き続き要件定義の学習を進めます。今週はずっとこれです。

Chapter-07 ［準備編］全体像を描こう（つづき）

昨日に引き続き読み進めます。

全体像を描くときの注意点

2つあるとのこと。

システム管理者を忘れずに

あ、これうちの代表が言ってたやつだ。以前のエントリーに一言だけ追記した気がする。

というわけで 利用者としてのシステム管理者を忘れずに含める とあります。これ以上の詳細は書かれていませんが、書かなければ登場人物としての考慮が漏れることになります。

システム管理者は最高権限を持つユーザー。しかも使い回しではいけない。例えば複数いるシステム管理者のうち誰かが退職したとしたら、同じように最高権限を持つユーザーによって適切に削除されなければなりませんし、それは下位の権限のユーザーには実行できない。

そのほかにも書いてある通りの重要な機能があり、それらをうっかり定義し忘れてしまうと「あれ、ログ確認できない（残してない）ので監視できてなかった」などのトラブルを招きそうです。

連携するシステムを書く

外部、内部問わず、連携するシステムやソフトウェアがあればそれも書くとあります。他システムからCSV取り込んだり、逆に他システム用にCSV出力したり、API叩いたり、色々あると思います。

また、特に業務システムの場合は 旧システム（移行元、現行）から新システム の流れとしても、連携するシステムを書くのを絶対に忘れないとあります。

書籍の図にちょっと書き足すとこんな感じかな。

解説

システム管理者が「不正アクセスを監視する」のなら、それは逆に「システム管理者に対し、不正アクセスを監視できる仕組みを提供する」という要件を 定義しないと機能が実現できず漏れてしまう 、とあります。

なので、「この人が必要なものって他にあるかな？」と指差し確認できる必要があるよ、と。よかったさっきの認識間違ってなかった。

また、連携しているシステムやソフトウェアがあるなら、連携先の要求に応える仕組みを要件に追加しなくちゃいけない。 場合によっては連携先に追加や変更を依頼する必要も出てくる 。それをこの時点で洗い出すということと理解しました。

特に移行元のシステムがある場合、移行に必要な要件（データや一時的な機能などかな）、並行稼働のための要件が想像以上に出てくるよ、と。それらを常に確認できるよう、利害関係者（ステークホルダー）としての、連携するソフトウェア、システムを必ず記載すること、とあります。

感想

新しいシステムですから、なにがしかのデータ設計変更、もしくは作り直しが発生し、データベースが違ってくることの方が多いでしょう。

普通ならデータベースも刷新だと思いますし、その間の並行稼働やデータ移行は各所で苦労しているのを見かけますし、話題が尽きることもない気がします。

関係するものは最初から全部洗い出すのは、言われてみれば当たり前ですけど。普段からずっと使っていて当たり前になっていたり、滅多に連携しないけど重要なシステムがあったり、意識から外れてしまう、言語化されない、ということがあるよな、と思いながら読んでました。

連携する内容も忘れずに

連携先を書いたら、何を連携するのか描きましょうねと。全部書き切る必要はないよ、というのは登場人物（利用者）のところと同じです。極端な話として、移行先との連携は「移行対象データ」とだけでも構わないとあります。

そこに意識することができるのがまずは重要なんだなと理解しましたし、何も書かないとミスの遠因になるということなので、やはりそういうことだなと思います。

というわけで自分なりに書籍から内容を書き足して図にしてみます。

利用者不在のものも連携対象

IoTなど、利用者不在のセンサーコンピューティングでも、そのセンター端末がステークホルダーでもあるし、連携先でもある、というようなケースもあるよ、とあります。

その場合もきちんと明記しましょうね、と。

複雑なIoTの環境を構築しているのなら、書いておかないと絶対に漏れるなってのは容易に想像できます。

余談ですけど、農業でもIoTが利用されていて、ビニールハウスの温度湿度管理や、農作物の様子など、いろんな使われ方をしてる場合もあるなって思うし、これがクルマなら、これまた様々なセンサー類があるよなって思いながら読んでました。

全体像を魅力的にお化粧する

全体像を作ってきたわけですが、全体像はパンフレットのようなものでもあり、誤解を招かない程度に装飾するとあります。

社内業務システムならば、利用者つまりスタッフへプレゼンテーションもするでしょうと。お化粧にはUIイメージなども加え、より魅力やメリットを感じてもらわないと、先行き心もとないよね、ともあります。

使ってもらう人に魅力的だと期待してもらえるほうが良いですよね。（過度な期待を持たせない程度に）

というわけで、この全体像の枠内が今回の要件定義の対象範囲、つまりスコープであり、引き続きこの枠内を掘り下げていきます、ということで Chapter-08 に続きます。

読んでみて

登場人物から、連携するソフトウェアやシステムを書いて、全体像を把握する。それをスコープとする。今までなんとなく感覚で書いてたものが 明確な理由と根拠を示されながら解説された ことで、わかってるけど説明できなかったことが、なんとか説明できるレベルにはなったと思います。

で、研修でも出てきたんですけど、この説明ができないとプロとは言えないよね、ということがよくわかります。

当たり前のことなんですけど、その当たり前に敏感であれ、という話も聞けて、それは要件定義だけじゃなく、コードを書く場合にも言えることだなって思いながら研修を受けてました。

今日の研修では、要件定義するには層がいくつかあるという話もありました。

• ゼロ層
  • カスタマージャーニ、カスタマーエクスペリエンス
  • このソフトウェア、システムでBeforeがどうAfterで幸せになるのか
• 第一層
  • ユーザーシナリオ、ビジネスシナリオ
  • とにかくユーザーが何をやるのか書き出していく
• 第二層
  • サービスシナリオ
  • 業務側が何をするのかを、ユーザーシナリオと1対になりながら書き出していく
• 第三層
  • 操作シナリオ、UI
  • 操作の流れ、ユーザーが触れる部分
• その先
  • ソフトウェア要件

で、この層を意識しつつ、それぞれの層で抜け漏れなく、かつシンプルに分割していく。これって僕らが普段やっている単一責任の原則にも繋がるよなって思いました。

ここら辺の、いわゆるプロセス設計の話は別の書籍「はじめよう！プロセス設計」に詳しいので、次の課題図書だったりもします。

引き続き学習しながら、プロセス、要件定義からコード、運用まで、単一責任の原則（もちろんそれ以外もですが）を意識しながら今後の仕事を続けていこうと改めて思ったりした次第です。

追加変更しやすく。それは実装以前に始まってるんだなって思ったりした今日でした。