叫ぶうさぎの悪ふざけ

うさぎが目印のWebエンジニアが、得たことや思ったことを言の葉に乗せて叫ぶ場所です。

学習記録:12月21日(金):はじめよう!要件定義 Chapter-08 [準備編]大まかに区分けしよう

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

さて寝るまでが今日。ということで12月21日のエントリーです。

完全に余談ですが、今日は研修最終日。その打ち上げのあと、DBAのすごい人たちの忘年会に呼んでいただき、 23:45までたらふく食べ、うまい酒をたらふく呑んで 参りました。いやー最高だった。どちらの会も、世の中にはすげー人がいて、そんな人たちがすぐそこにいて、会ってお話できる機会があるんだな、とひとり感謝の夜だったりもしました。

閑話休題

前回までは要件定義のスコープを決めましょう、そのために全体像を描こう、というところでChapter-07 が終わりました。

なんとなく雰囲気で要件定義をし、合意形成の成果物はこれです!と自信を持ってやってこなかった自分としては、 最初にやるべきことがこんなにも多く、そして、最初にやるからこそ後に繋いでいくことができる 、ということを学びました。

工場のラインのように、物理で次の工程ができるできないが完全にわかるのとは違い、ITの世界は見切り発車できてしまうし、わかった気になってしまう。そして日本の場合は多いのでしょうが、忖度してこそプロ、みたいなことあると思います。

しかしそうじゃないだろうと。どんなに細かいことでも合意できてなければ、それは取りこぼしたことと同じ。 合意できてない要件は定義が終わっていない ということ。

ってことを自分なりに学び取りました。

というわけで、Chapter-08に進みます。

Chapter-08 [準備編]大まかに区分けしよう

大きなソフトウェアの場合、「新規システム」など1つの四角で表現するのは難しいよね、ということでサブブロックの話が出てきます。

サブブロック図を作成する

  • 1つのシステムの箱の中を
    • いくつかの区画(サブブロック、サブシステム)に区分け
    • 見通しをよくする
  • 内部連携を図示
    • それぞれの区画間で何を連携するか書こう
    • ステークホルダーを書くとごちゃごちゃするなら
      • 利用者の記載については「全体像を参照する」ことにし
      • 省略してもOK

以下の図は書籍中にある図を再現したものです。自分で書かないと手に馴染まないので、僕個人としては必ず図は自分で書き起こします。

で、書いてて思ったんですが、サブブロック、層に分かれているな。もしかして第一層はプレイヤー、第二層はパラメータ担当、第三層はマネージャの層なのかな、ステークホルダー(利用者)によって分けられるんだろうな、と個人的に読み取りました。

image.png (183.7 kB)

サブブロック図を作成する手順

  • 手順は非常に難しい
    • 担当する人の経験、実力、センスに左右される
  • 大抵は利用者がやることを大まかにくくる
    • 同じような物をくくっていく
    • 収まるところに収まる

あ、なるほど「利用者によって層が分かれてる」はあながち間違いじゃないなと読み進めて思わされてます。

ということで、サブブロック図のサンプルがあるので書いてみます。

これは製造業の生産、販売、在庫管理システムかな。

image.png (248.1 kB)

これは新規商材を開拓して売り込む商社とかのシステムかな。

image.png (266.2 kB)

やってみて

最初読んだ時、このサブブロックがあんまり理解できなくて、 何を根拠にブロックに分ければいいのかわかりませんでした

なので、サンプルをみても「乱雑に箱が散らばっている」としか見えず、慣れるしかないのかなあ、と思ってました。

が、今日の研修で繰り返し 基本的に三層構造である ことが出てきました。もっというとその前のゼロ層には企画があり、三層の向こうにはソフトウェア要件の層があるわけなんですが、ゼロとソフトウェア要件を除く三層はそれぞれ以下になります。

  1. 商売の流れ
    • ビジネスフロー
    • ステークホルダーがそれぞれ何をして
    • 互いに何を受け渡すのか
    • 最後にユーザーに何を提供するのか
  2. ユーザーシナリオ
    • ユーザーはシステムの利用者
      • エンドユーザーだけじゃなく、社内の利用者も主役
    • ビジネスフローの個々の仕事を手順化、例えばレストランのホール係
      • 顧客の注文を聞く
      • 注文を登録する
      • 注文を復唱する
      • 注文を確定する
  3. 個別の機能の操作手順(UI)

で、この三層を考えた場合、Chapter-08のサブブロックは、第一層のビジネスフローをステークホルダー別に「さらに層に」分けたものかな、と理解しました。

以下の画像の場合を僕なりに「大まかに」解釈してみます。

  1. 商材を売り込む営業
    • 需要開拓
      • 開拓したレポート、外部システム連携による分析とか
    • 商談管理
      • 新規開拓した商材を売り込んだ履歴
      • やりとりの経過や結果
    • アフターフォロー
      • 次の商談に繋げるためのアクションの管理
      • もしかしたら他部門や他システムからのアドバイスあるかも
        • 要質問事項
  2. 営業サポート
    • 案件管理
      • 営業が開拓してきた新規商材の管理
      • 売り込んでいる進捗の案件管理
      • 社内での情報共有とかあるかもしれない
        • 要質問事項
  3. 管理部門
    • 外注管理
      • 新規開拓した商材をどこに発注するのか管理
      • 発注状況、納品状況、在庫状況を管理
      • 製造を依頼するならその進捗管理
        • 要確認事項
    • 顧客管理
      • 営業が開拓してきた顧客の情報管理
      • 過去の情報も管理
      • 未来の可能性としての見込み顧客管理

image.png (266.2 kB)

どうでしょう。致命的に間違ってる感じではなく、むしろここから質問事項や確認事項を1つずつ丁寧に明らかにし、合意していくことで、 抜け漏れなく要件を定義していく出発点に立てそうだな、という感触 があります。

これが第一層だと認識したので、この次の第二層、第三層、アプリケーション要件層、と続いていく、繋げていくことで、抜け漏れなく進められるんだろうなと感じます。

余談

抜け漏れなく進めるには、必要なものがあると感じています。

  • コツコツと丁寧に積み重ねる根気
  • 根気を失わない1つ1つの小さな達成感
  • 単一責任の原則に基づいた分解

何より必要なのは根気だと思います。書き出すことが、合意することが 多すぎて心が折れることが容易に想像できる んですが、決してそうではなく。

単一責任の原則 に基づいた分解を行い、次から次へと分解して明らかにしていき、 片っ端から合意形成 していくことで、 お客と自分の小さな達成感を次のモチベーションにしていく んじゃないかな、って読み進めて思いました。

前にも書いたかもしれないんですけれど、これってプログラミングだけではなく、 要件定義の時点から単一責任が考えられてしかるべき なんだな、って強く感じます。

日本語の魔術(漢字の羅列による、あたかも1つに見える言葉に潜む複雑さ、曖昧さ)に惑わされずに、分解し、明らかにし、つまり抽象化し、 確実に合意形成できた仕事 を選んでいく。

それこそが 使う側も作る側も幸せになれるシステム と言えるんじゃないかな、というところで今日のエントリーを締めます。

幸せになるために働くんだもんね。