学習記録:12月21日(金):はじめよう!要件定義 Chapter-08 [準備編]大まかに区分けしよう
これは 俺のインプットアウトプット記録 Advent Calendar 2018 の21日目のエントリーです。
さて寝るまでが今日。ということで12月21日のエントリーです。
完全に余談ですが、今日は研修最終日。その打ち上げのあと、DBAのすごい人たちの忘年会に呼んでいただき、 23:45までたらふく食べ、うまい酒をたらふく呑んで 参りました。いやー最高だった。どちらの会も、世の中にはすげー人がいて、そんな人たちがすぐそこにいて、会ってお話できる機会があるんだな、とひとり感謝の夜だったりもしました。
閑話休題。
前回までは要件定義のスコープを決めましょう、そのために全体像を描こう、というところでChapter-07 が終わりました。
なんとなく雰囲気で要件定義をし、合意形成の成果物はこれです!と自信を持ってやってこなかった自分としては、 最初にやるべきことがこんなにも多く、そして、最初にやるからこそ後に繋いでいくことができる 、ということを学びました。
工場のラインのように、物理で次の工程ができるできないが完全にわかるのとは違い、ITの世界は見切り発車できてしまうし、わかった気になってしまう。そして日本の場合は多いのでしょうが、忖度してこそプロ、みたいなことあると思います。
しかしそうじゃないだろうと。どんなに細かいことでも合意できてなければ、それは取りこぼしたことと同じ。 合意できてない要件は定義が終わっていない ということ。
ってことを自分なりに学び取りました。
というわけで、Chapter-08に進みます。
Chapter-08 [準備編]大まかに区分けしよう
大きなソフトウェアの場合、「新規システム」など1つの四角で表現するのは難しいよね、ということでサブブロックの話が出てきます。
サブブロック図を作成する
- 1つのシステムの箱の中を
- いくつかの区画(サブブロック、サブシステム)に区分け
- 見通しをよくする
- 内部連携を図示
- それぞれの区画間で何を連携するか書こう
- ステークホルダーを書くとごちゃごちゃするなら
- 利用者の記載については「全体像を参照する」ことにし
- 省略してもOK
以下の図は書籍中にある図を再現したものです。自分で書かないと手に馴染まないので、僕個人としては必ず図は自分で書き起こします。
で、書いてて思ったんですが、サブブロック、層に分かれているな。もしかして第一層はプレイヤー、第二層はパラメータ担当、第三層はマネージャの層なのかな、ステークホルダー(利用者)によって分けられるんだろうな、と個人的に読み取りました。
サブブロック図を作成する手順
- 手順は非常に難しい
- 担当する人の経験、実力、センスに左右される
- 大抵は利用者がやることを大まかにくくる
- 同じような物をくくっていく
- 収まるところに収まる
あ、なるほど「利用者によって層が分かれてる」はあながち間違いじゃないなと読み進めて思わされてます。
ということで、サブブロック図のサンプルがあるので書いてみます。
これは製造業の生産、販売、在庫管理システムかな。
これは新規商材を開拓して売り込む商社とかのシステムかな。
やってみて
最初読んだ時、このサブブロックがあんまり理解できなくて、 何を根拠にブロックに分ければいいのかわかりませんでした 。
なので、サンプルをみても「乱雑に箱が散らばっている」としか見えず、慣れるしかないのかなあ、と思ってました。
が、今日の研修で繰り返し 基本的に三層構造である ことが出てきました。もっというとその前のゼロ層には企画があり、三層の向こうにはソフトウェア要件の層があるわけなんですが、ゼロとソフトウェア要件を除く三層はそれぞれ以下になります。
- 商売の流れ
- ビジネスフロー
- ステークホルダーがそれぞれ何をして
- 互いに何を受け渡すのか
- 最後にユーザーに何を提供するのか
- ユーザーシナリオ
- ユーザーはシステムの利用者
- エンドユーザーだけじゃなく、社内の利用者も主役
- ビジネスフローの個々の仕事を手順化、例えばレストランのホール係
- 顧客の注文を聞く
- 注文を登録する
- 注文を復唱する
- 注文を確定する
- ユーザーはシステムの利用者
- 個別の機能の操作手順(UI)
- ここがユーザーインターフェース(UI)
- 手元のスマホのPOSを想定
- アプリケーションを起動する
- メニューを表示する
- メニューを選択する
- 注文が登録される
- 手元のスマホのPOSを想定
- ここがユーザーインターフェース(UI)
で、この三層を考えた場合、Chapter-08のサブブロックは、第一層のビジネスフローをステークホルダー別に「さらに層に」分けたものかな、と理解しました。
以下の画像の場合を僕なりに「大まかに」解釈してみます。
- 商材を売り込む営業
- 需要開拓
- 開拓したレポート、外部システム連携による分析とか
- 商談管理
- 新規開拓した商材を売り込んだ履歴
- やりとりの経過や結果
- アフターフォロー
- 次の商談に繋げるためのアクションの管理
- もしかしたら他部門や他システムからのアドバイスあるかも
- 要質問事項
- 需要開拓
- 営業サポート
- 案件管理
- 営業が開拓してきた新規商材の管理
- 売り込んでいる進捗の案件管理
- 社内での情報共有とかあるかもしれない
- 要質問事項
- 案件管理
- 管理部門
- 外注管理
- 新規開拓した商材をどこに発注するのか管理
- 発注状況、納品状況、在庫状況を管理
- 製造を依頼するならその進捗管理
- 要確認事項
- 顧客管理
- 営業が開拓してきた顧客の情報管理
- 過去の情報も管理
- 未来の可能性としての見込み顧客管理
- 外注管理
どうでしょう。致命的に間違ってる感じではなく、むしろここから質問事項や確認事項を1つずつ丁寧に明らかにし、合意していくことで、 抜け漏れなく要件を定義していく出発点に立てそうだな、という感触 があります。
これが第一層だと認識したので、この次の第二層、第三層、アプリケーション要件層、と続いていく、繋げていくことで、抜け漏れなく進められるんだろうなと感じます。
余談
抜け漏れなく進めるには、必要なものがあると感じています。
- コツコツと丁寧に積み重ねる根気
- 根気を失わない1つ1つの小さな達成感
- 単一責任の原則に基づいた分解
何より必要なのは根気だと思います。書き出すことが、合意することが 多すぎて心が折れることが容易に想像できる んですが、決してそうではなく。
単一責任の原則 に基づいた分解を行い、次から次へと分解して明らかにしていき、 片っ端から合意形成 していくことで、 お客と自分の小さな達成感を次のモチベーションにしていく んじゃないかな、って読み進めて思いました。
前にも書いたかもしれないんですけれど、これってプログラミングだけではなく、 要件定義の時点から単一責任が考えられてしかるべき なんだな、って強く感じます。
日本語の魔術(漢字の羅列による、あたかも1つに見える言葉に潜む複雑さ、曖昧さ)に惑わされずに、分解し、明らかにし、つまり抽象化し、 確実に合意形成できた仕事 を選んでいく。
それこそが 使う側も作る側も幸せになれるシステム と言えるんじゃないかな、というところで今日のエントリーを締めます。
幸せになるために働くんだもんね。