「要求は開発するもの」らしい

もう8月も終わるので夏の宿題を片付けないと。

（そういえば，実家の松江では8月の最終日に武内さんのお祭りがある。 それまでに夏休みの宿題を終わらせないと祭りに連れてってもらえなかったので，そりゃあ必死こいて宿題をしたものであるw）

だいぶ前の話で恐縮なのだが，8月3日に広島市内で「概念モデリング（Conceptual Modeling）」のセミナーが開かれ参加した。

• 概念モデリング再入門 ～今さら人に聞けない人のための基礎講座～ ＋ ちょっとだけDDDの話も - 広島Javaユーザーグループ | Doorkeeper

このセミナーはこの前に東京で行われた「要求開発アライアンス」の定例会で発表された内容を再構成したものらしい。 つまり「要求開発」には「概念モデリング」は必須の道具であるということだ。

スライドも公開されている。

当時メモしたことを箇条書きで書き出しておく。

1. モデルが正解かどうかにこだわらない
2. モデリングの利点は「分からない」ことがわかること
3. 初期概念モデルから段階的に最終形に持っていくプロセスをとる
4. 途中経過を（できるだけ）正規のドキュメントとして残す
5. モデリングを習慣づける
6. 5W3H (when, who, whom, what, where, how, how match, how meny) でザクっと描いて洗練させていく
7. 関連を考える上で多重度は必須。多対多の関連を放置しない（多対多の関連は実装できない）
8. 関連は双方向で考える
9. 2つの概念間に複数の関連があるかもしれない
10. 関連のロールを明らかにする
11. （商品の）種類か現品か
12. 知識（ルール）か操作・運用（オペレーション）か
13. 理解のための概念モデルと設計のための概念モデルは分けて考える
14. 概念モデリングを使って顧客と一緒に掘り下げていく（難しいことをやってると思わせない。概念モデルでやりましょう、なんて言わなくていい）
15. 概念と言葉（用語）の関係。言葉の意味を掘り下げていく

多分これが核心だと思うが「概念モデリングに唯一の『正解』はない」。 たとえばファウラーの勘定パターンのような「定石」はあるにしろ，それに強く拘る必要はない。 むしろ重要なのは「概念モデリング」を挟んで顧客と対話することにより，顧客すら思ってもみなかった「隠れた要求」を引き出すことにある。 まさに「要求は開発するもの」というわけだ。

個人的には「『概念モデリング』を使って顧客と対話する」という発想に「目から鱗が落ちる」思いだった。 また，モデル図は何度書き換えてもよく，書き換えていくプロセスが重要だというのは，割と納得する話だった。 つまり「完成図書」を保持するだけではダメで，「そこに至る過程」も併せて保持しておかなければならない。

たとえば，私のような「流しのプログラマ」がプロジェクトに最初から参加することは稀で，大抵はプロジェクトが本格的に動き出してからの参加となる。 このとき，要件定義から参加できていればまだいいが，そうでない場合には，完成図書としての「要件定義書」だけを見てもピンと来ないことも多く，結局はあちこち訊きまくるハメになる。 こんな時にそれまでのやりとりが履歴として残っていれば早い理解に到達できる。 ただし，履歴は雑然とそこにあればいいというものではなく，「あとから来たもの」にも分かるように，ある程度整理されたものではければならない。 このへんの匙加減がきっと難しいんだろうな，とは思う。

セミナーでは DDD（Domain-Driven Design）についても少し言及があった。 DDD は（名前は似ているが）TDD のようなものとは異なり，設計時のデザイン・パターン を指す。たとえば以下の様な構成である（これ人によってだいぶ違うんだよなぁ）。

レイヤが縦構造ではなく横になっているのはデータの流れを意識してほしいから。 左から右が入力（request）で右から左が出力（response）である。 つまりユーザはもっとも左側にいることになる。

この図の中の Domain Layer にビジネスロジックが入る。 つまり DDD というのはビジネスロジックを取っ掛かりとして設計を始めましょうということで，これをやるためには上述の「概念モデリング」が必須の道具になるというわけだ。