要件定義からテスト設計までの流れで個人的に思うところのメモ（２）
自分の経験の整理
の続き
いきなりモデリングはやめよう
（また？）
理由
モデリングのような抽象度の高いことよりも、個別具体のところから整理していった方がユーザーにとっても開発側にとっても分かりやすいと思うから。
モノを明確にする
まずは業務フローという「アクター」と「コト」の整理。
しかも、ユーザーにとって分かりやすい表現に留めてシステム設計的な色合いの極力ないもの。
次は「モノ」の整理をしましょう。
取っ掛かりとして簡易
「こういうコトがしたい」に対して、「どういうモノを通じて」という肉付けをしていくのは ユーザーにとってイメージやすいと思います。
イメージしやすいということは 共有・共感もやりやすいです。
既存システムや既存運用がある場合、実際に使用している資産（帳票とか画面とか）を題材にして、先に作成をした業務フローとの関連付けを行います。
新規の場合は 先に作成した業務フローを実現するために必要となりそうな項目のラフスケッチを作成します。
「こういうモノがいるよね」を明確にすることが目的です。
必要なモノに対して、必要そうな項目を列挙しながら、すべての業務フローを総なめ出来れば良いと思います。
レイアウトなどのデザインは考えなくていいです。というよりも、考えない方が良いです。
ユーザーにとって分かりやすい表現
業務用語など含めて ただ要素を列挙しているだけなので 何よりもユーザーにとって分かりやすい表現です。
ユーザーにとって分かりやすいけど、開発側にとって曖昧であったり分かりにくい内容は 質問する事で、ユーザーにとっても「そうそう そうだね。業務担当外の人からすると そういう表現だと分かりやすいですね」となって*1、フロー（コト・動詞）に関連する名詞（モノ）について、ユーザーと開発側に知識が共有・蓄積していきます。
ファンクションポイントが明確になる
いわゆるファンクションポイント（入力・出力・記憶）の基本情報が把握できるので、システムで実現したい目的の目的語が明確になります。
「この結果の根拠って どこからやってくるんでしたっけ？」「この結果は 誰の（どこの）何をするときに使うんでしたっけ」を把握することが大事です。
目的語のバリエーションについて 業務フロー（動き）だけでは分かりにくい実態が見えてきます。
帳票や画面についてはレイアウトではなく要素が重要です。似て非なる目的のものは、別物として扱った方が良いでしょう。既存システムがある場合、出力項目名称は同じでも意味の違う帳票や 意味が同じだけれどレイアウトが異なる帳票について「なんで これは違うの？」ということは フローよりも実物を対象に会話をする中で明確になりやすいです。
Note
とにかく一気に！
業務フローを作業量の分母として、とにかく一気に早く「モノとの関連」を整理することが大事だと思います。
要件の整理は時間をかけすぎると 要望を盛り込み始めてしまいます。要件は漏れなく整理しないといけませんが、初心に描いた「これはやりたい」は業務フローとして作成されています。このフェーズは「やりたいこと」の整理ではなく、「実現するために必要なもの」の整理です。設計の時間を経ることで「この要件が満たされるのであれば、これも出来るよね？」と発散していっている可能性があります。
「このシステムの意義と実現したいこと」をブレなく意識して取り組む熱量を維持できる時間は そんなに長くはありません。
少なくとも一通り早くスルーすることを第一の目標とすることをお勧めします。
デザインは考えないこと
レイアウトデザインや画面遷移のようなプロセス分割は考えないことです。
個別具体なものは あくまで「モノ」を整理するためのインプットであって アウトプットではありません。
業務フロー（コト）におけるモノとして必要な要素と緩い要素の集合の関連の整理に留めて、１つ１つに時間をかけるよりも「フローとの違和感のなさ」「モノの表現の共有」を優先することを常に意識することが大事です。
ユーザーと開発側のコミュニケーションにおいて デザインやレイアウトを除外して、モノの整理をするのは地味ですが 結構な胆力がいるかもしれません。
どうしても帳票や画面など「具体的な作成したいもの」を目にすると それに注意を向けてしまいますが、それは良くありません。もし、ユーザーと開発側の整理の中で デザイン に関する事で紛糾することがあったら いったん、その題材は保留して 次のモノの整理をするなど 少し時間を空けるなどした方が良いと思います。
ただし、既存システムがあって デザインに業務的な意味がある場合、開発側は議論をせずヒアリングに徹して デザインの裏にある本音の収集に努めてください。
実現可能性の担保が目的ではない
業務フローに対する実体の洗い出しと それを通じて個別具体な用語の共有が目的です。
整理したモノが実現対象ではありません。この点については ユーザー側にも十分理解しておいてもらうことが大切です。毎回の会議都度 枕詞のようにいうくらいしておいても良いでしょう。それくらいでも気が付いたら「これは対応される出力資産だと思っていた」と言われかねません。同様に開発側も実現可否を匂わせるようなことを不用意に言わないことです。重複になってしまいますが、そういうこともあって 変に実現性を匂わせることになりかねないので デザインに関することを ここで深掘りしないことが大事だと考えます。
向き合うのはシステム
（前回の考察と同じですが、大事だと思うので繰り返し）
ユーザーの要求に応じてシステムを構築するのがスタートかもしれませんが、最終的にはシステムが作り出す付加価値に向き合うことです。
この付加価値は得られるサービスからの直接的な便益だけではなくて 運用コスト（改修コスト）や開発コスト（品質など）も含めた話です。
ユーザーの要求を全てに行き渡らせると多分実現不可能なシステムになります。ここで言う「全て」というのは、例えばデータ保存、通信方式、分散制御について ユーザーが「要求」してくることがありますが それをそのまま受け止めると実現できるものも出来なくなります。
そういうことを言いそうだなぁ、と思ったときに ユーザーに 現時点で あなたたちが注力すべきは システムの目的ですよ という拠り所として 業務フロー＋モノ（何をもって目的が達成されるのか）を活用すると良いと思います。
Hint
モノの整理の成果物は 業務フローとペアとなる項目名とその説明の表があれば十分だと思っています*2。あとは項目名の列挙だと扱いにくいので分類・識別となる表題があると良いでしょう。
（同様に業務フローは図示せずとも 表で表現しても良いと思っています。）
項目名についても、短縮しすぎて全て「名前」に集約するくらいだったら「顧客名」「ユーザー名」「操作者名」と一見似ているんだけど違いがあると分かる表現の方が良いと思います。また、端的に意味を示す単語を考えるくらいなら だらだらと意味を並べたような項目名でも良いと思います。とにかく大事なのは違いがあるのなら そうとわかるようになっていれば良いので 早さを優先した方が良いです。
モノからコトを検証する
とにかく、早く一旦はやりきりましょう、という理由は１回１回の密度よりも 観点を変えた繰り返し回数を増やしたいためです。
コトからモノを整理したら、次にモノからコトの関係を検証・整理します。言い換えたり、より良い説明ができたり、 不足または不要な項目の発見が必ずあります。
モノを通じて具体的に考える中で 作成済みの業務フローとは 似て非なるフローが必要になりそうだ、ということが往々にして見つかります。また同様に始めは違う業務フローと思っていたけれど本質的には同じじゃないか？という業務フローも見つかるかもしれません。
設計は上下左右色々と角度を変えてみると、どんどん肉厚でしっかりしたものになると思います。
モノとモノを整理する
ここまでくると、アクター（主語）・業務フロー（述語）・モノ（目的語）、を通じてユーザーと開発側で同じストーリーを話せるようになっているのではないかと思います。
少なくとも それを手助けする資産は手元にあります。
次の工程にむけて モノとモノの関連やグルーピングを簡単にします。
規模にもよるとは思いますが、基本的にすべてのモノを何の分類もせず扱うことは難しいです（単純に記憶しきれないというレベルを含めて）。
ユーザーと開発側で理解しやすい表現に分類をしてください。
分類は意味で行うだけでなく、たとえば組織という要素も加味するようにすると良いでしょう。
「お客様の情報だから、これはお客様管理だね」とすると、巨大な集約になりかねません。「クレーム対応部門 お客様情報」「お歳暮部門 お客様情報」という感じで 個々の項目で見た場合、重複があっても良いです。そのあたりの正規化のようなことよりも、意味と役割を優先してください。場合によっては表題に対して項目名を追加してください。
課題は無いの？
あります。
上述のアプローチは「データ中心アプローチ」に近しいものだと考えています。
データ中心アプローチの欠点としては、データ項目の網羅的な洗い出しが分析の基本となるため、特に大規模システムでは分析に時間がかかることが挙げられます。 アーキテクトの審美眼(P43)より
という指摘は もっともだと思います。
その点については、マイクロサービスのように「組織」を整理の基準の１つとして盛り込むことで、網羅的な項目洗い出しの範囲を限定することで多少は軽減出来るのではないか と考えています。
データの分析を網羅的な全体のデータ項目とすると、常に全体を把握しなくてはならず 分析が直列的になってしまいますが、業務フロー（つまり組織としての実行プロセス）をペアに検討すれば 、業務フローを中心とした作業分割ができて組織毎に並列的に分析ができると考えます*3。
ここまでで、業務フロー（コト）とモノのベースが整理できました。
作成された成果物は、業務フローと それに関連する項目名が列挙された表 です。
UMLなどの〇〇図みたいなものではありません。
古式ゆかしきものかもしれませんが、ユーザーと開発側の共有資産として意味があり、困ったときの原点回帰するためのドキュメントです。
まだモデルは設計しない
まだ（？）モデル設計はしません。
ここからは あまり賛同を得られることも難しいだろうと 逃げの一手を先に言っておきたいと思います。
テーブルの物理設計をしよう
モノの情報と そのグルーピングを元に「テーブルの物理設計」をすることをお勧めしたいと思います。
なぜ物理設計から？
概念設計（モデリング）のようなトップダウンアプローチには分析者（設計者）の力量による影響が大きく出てしまうからです。
ブレの無い分析が行える点もデータ中心アプローチの特長の１つです。
アーキテクトの審美眼(P42)より
というところに私は共感しています。
限られた物理的・人的リソースの中で やりきるのであれば 私はこの「ブレの無い（もしくは少ない）」アプローチを選択した方が良いと考えます。
既存のシステムがあったとしても、ユーザーが そのシステム内部の分析者足りうる存在であるとは言えません。時としてユーザーが分析者として振る舞うがゆえに炎上することすらあります。あくまでそのシステムは様々な制約の元で構築されたものであって これから構築するシステムに適合するアーキテクトでは無いからです。
それをするくらいなら、ボトムアップアプローチで具体的なテーブル定義をしてしまった方が まだマシだと考えます。
概念的・論理的な整理を全くしないでテーブル定義は作成できないかもしれませんが、少なくとも成果物はDDL（もしくは それを出力するツールのデータ）として、それ以外の成果物はスキップして良いと思います。
変更への心理抵抗を減らしたい
概念→論理→物理 という設計をしましょう、というのが王道だというのは分かっていますが、私の経験として、形式美になっていることが多いように思います。
むしろ、ウォーターフォールといわれる開発において、このプロセスを歩むがゆえに 工程として物理設計まで確定したテーブル設計を変更することに対して、心理的な抵抗が生まれているとすら思っています*4。
開発する側としては 実際のテーブルに対してSQLを実行できれば、プロトタイプの実装や 性能検証ができるので開発の選択枝が増えることは好ましいと思っています。
際限なくテーブル設計を変更しても良いということはありませんが、机上で実装をしない人たちによる喧々諤々よりも 実装を通じてリファクタリングをする方が 結果として無駄が無いというのが私の実感です。
そんなこと出来るの？
一定の割り切りさえすれば出来ると考えています。
モノの整理ができていれば、ラフであるにせよ 業務フローの実現に必要な要素は列挙されています。
項目の属性を集約としてのテーブル（エンティティ）と関連をもって正規化をすれば「草案として」のテーブル設計は出来ると考えています。
割り切りとしては、関連の有無、項目の有無に絞って、項目の桁数は暫定とする、というようなことです。
Hint
とはいえ、テーブル設計そのものってどういう感じでやったらいいの？というところがあると思います。
個人的には「楽々ERDレッスン」がお勧めです。
レシートからデータ設計を試みる、というような身近な個別具体的を用いた事例などが記載されていて 取っ掛かりとして良いと思います。
![楽々ERDレッスン （CodeZine books） [ 羽生章洋 ]](http://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/7981/79811066.jpg?_ex=128x128 "楽々ERDレッスン （CodeZine books） [ 羽生章洋 ]")
本書のER図について、私の考えと異なるものもありますが、大事なことはモノがあればテーブル設計はできる、ということです。
ちなみに
前回と同じく、このまま設計・実装をしていくと、フローを中心とした旧来型と言われる開発手法になると思いますので、簡単に手続き型のシステムが出来上がります。
私はDDDとかオブジェクト指向とか良いと思っています。
でもドメインの知識（システムに関連するコトとモノ）を整理せず それに取り組んでいないでしょうか？
コトとモノを実現するだけで事足りる開発に使う手法として適当でしょうか？
さいごに
改めて言いますが、私はDDDとかオブジェクト指向とか良いと思っています。
でも、それはシステムの価値を向上させるための手法であって、やりたいことの蒸留器ではないと考えます。
やりたいこと（関心事・ドメイン）の源泉とは別です。
やりたいことの主語は、ユーザーです。やりたいことが明確になった上で、関心事（ドメイン）の整理がスタートするのではないでしょうか？
私の経験としては、途中参画をして*6ドキュメントは整っているような気はするんだけど、しっくりこない感覚を覚えたプロジェクトは、このあたりが原因だったように思います。
開発側は開発する事に目が向くため実装をしていくとアリの目になりがちです。そういう時に生きてくる鳥の目ドキュメントが業務フローとテーブル定義だと思います。
さて、今回はこのくらいで終わろうかと。
