モデリングの学び方：座談会 - connpassを見たよメモです。ディスカッション形式だったので、話の流れになぞらえてまとめていきます。
本日の話し手
この会でメインで喋られていたのは以下の方々
本日の趣旨説明と増田さんの考えるモデリングに関して
まずは下記の資料を使いながら今日の催しの趣旨説明と増田さんの考えるモデリングに関しての話があった。
speakerdeck.com
上記の資料にもあるが以下の話が冒頭で行われた
- 今回の話し手の属性に関しての話(共通的な部分もありつつも自社サービスを持つ人たち3人と、受託開発を主に行う人たち3人という構成)
- まずは前提の話としての増田さんのモデリングの考え方のダイジェスト説明
- 効果的なモデリングの考え方（要点をうまく表現する名前を見つける、認知不可の軽減）
- モデリングで目的とするところ（要点の発見、個人の思考整理、チームへの伝達、オプションとしてのドキュメント、など）
冒頭の話のあと大きく2つのトークテーマが出された
トークテーマ1「普段はどんなモデリングをしていますか？」
このパートでは各話し手ごとに話が展開されていったので各々の話者ベースでざっくり話したことを書いていきます
増田さん
スライドの資料にあったものと同じで、要点をまとめるときや語彙をシェアするのにモデリングを行う。またモデリングに関して3つのアプローチをしている旨の話がありました。
上記の3つのアプローチから、中核となるものと周辺的なものを切り分けて中核のユースケース、中核のデータ、ドメインモデルを使ってドメインモデル中心な形でつくっていくということを話されていました。
かとじゅんさん
Chatworkではレガシーからの脱却というのがあり、ソフトウェア考古学（いわゆる稼働中のソースコードからの発掘作業）が必要なため増田さんのあげた「要点」の発掘が必要となる。この発掘の工程も我流でやると抜け漏れが多いのでRDRA v2などを使って洗い出しているとのことでした。また、現状のシステムを理解してモデルを再構築するなどしているため、モデルなどを図でかいて同意してもコードを書いたら（良くも悪くも）ズレがでてくるのでその行ったり来たりで苦労している側面があるという話もあった。
すでに稼働中のため外部仕様をいきなり変えるのは難しい。またビジネスの表層のモデルと、より深い部分の深層のモデルがあるが、表層のモデルですら変えるのに苦労する場面がある。またドメインモデルを改善変更する際は既存のモデルのデータの改善あるため、必然的にマイグレーションが必要になり、セットで考える必要があるという話もされていました。
なお、絵などを起こすものはクラスモデルのような図も書くことがあるがアクターモデルの図をかくケースがあるということでした。
原田さん
普段はアジャイルコーチをされている原田さんはモデリングの中心としては個人の理解ではなくチームの理解という話をされたいた。
受託開発のため、まずはビジネスとして何に困っているかをヒアリングして、そこから語彙のモデリングなどを行い、受託開発を発注したお客さんとの意思疎通を図りに行ってちゃんと問題がないかを意識する形にし納得してもらいながら進めていくという。ただ納得していても正解かわからないので、モデルに書く・コードに起こす・テストする・試しに見てもらうというのがアジャイルの形だとできるのでそこで問題が解決したかをお客さんに問いやすく、いわゆるうずまきモデルのシナリオが解決できているかというところを含め、シナリオとコードの行ったり来たりをしていると話してました。
また、お客さんの言葉にも抽象度の高い言葉も具体的な言葉もある。その抽象度を合わせるために概念モデルを作って相互理解を図るということもしているという話だった
ミノ駆動さん
現職の会社に入られてからまだ4〜5ヶ月のミノ駆動さん、その中で新しいものを開発することになったが複雑化することが想定されるためしっかり分析から始めようとしている。そのためには既存のビジネス理解も含めて俯瞰して理解しないといけないため、DDDのコンテキストマップをカスタマイズしながら利用し、会社でやっているドメインやコンテキストを洗い出し、図示化したという。
また、先日のDevelopersSummitで以下の講演を発表した話から「目的」という部分の話も展開された。
speakerdeck.com
会社の中でドメインエキスパートや有識者にヒアリングを行った際に、各々達成したい目的が違うということがある。そういう場合も図に起こして、目的の中にドメインができる構図になる。そのため、そこにモデルをおいて目的とあっているかが評価しやすく、目的に沿っているかが評価しやすくモデルだけ起こすときに起きがちな目的を見失うことがすくないというお話だった。
hirodragonさん
受託開発を行なっているhirodragonさんことヒロさんだが、受託開発という性質上、長くビジネスに寄り添うというよりかは毎年やる案件が変わるという話が多く、すべての案件に関していろはに沿って丁寧にモデリングしているかというとそういうわけでもないと話していた。
ただ、そんな中でも必ず「概念モデル」を作るという。
受託開発のため、システム化する対象は案件紹介のときに初めて聞いて何も知らないところからスタートする、そのときに時間かけたり複雑なことにはしたくないので、用語や関連、時々多重度を書くぐらいの概念モデルを作るという話だった。ここに更に必要な場合はユースケース図やロバストネス図を書くとのことだった。
また、ヒロさん自身がクラス図はモデリングという切り口ではなく、思考を整理してコーディングを行うためのものとして書いているという話だった。
藤岡さん
現職に入社したのが2年前の高崎さん、会社がつくられたのが6年前なのでアプリケーションが作られた当時を知るエンジニアや関係者がいないところのスタートだったので、前述のかとじゅんさんと同じような「ソフトウェア考古学」という状態で、動いているソースコード以外要件がわからないという状態だったという。そのため、ソースコードを追いかけながらやっていることを類推して拾い上げていく作業を既存部分の読み取りではやっているとのこと。
対して新しいことをやりたい要望もあるので、そちらはユースケースを作ってドメインモデルのようなものを作りながらプロダクトオーナーと「やりたいことはこんな感じですかね？」を聞いていくという。またモデリングは図をつくるわけではなく、クラスを作ってそれをツール（Jig）を使って可視化している、そうすることで相互参照などを発見しやすく、修正も行えるとのことだった。
昔は図をきっちり書くということもされていたということだが、いまではコードで書くことをしており、必要であれば手書きでかくなどをしているとのことだった。
高崎さん
広く一般的なSIerとやっていることは変わらない、という高崎さん。モデルを中心に開発するためDSLやモデルから自動生成するツールなどを活用しながら開発をしている。モデルは書くものの、要件定義をして仕様をつくるような従来からあるSIerのつくりかたと変わらないがクラス図を書いたりしてみんなで認識を固めるなどしているという話だった。
ただ、案件の内容や忙しさによってはモデリングをうまく作ろうという余裕がなくなってくるのでモデリングよりもコードを書こうとチームメンバーがなりがちになる、ただそんな中でも意識しているのは「語彙のモデリング」ということはやっている。どんなに忙しくても「どんな言葉がいいんだろう」ということをしているというお話でした。
モデリングをやるときはRDRAを使ったり、匠Methodを使ったりしている。集まったメンバーのよってどんなことをどこまでやるかというのはかえているとのこと。
トークテーマ2「どうやってモデリングを学んできた感じですか？モデリングの学び方のすすめはありますか？」
一通り、話し手の話を聞いたあとに、流れる形でどのように学んできたかという話になっていった。ここでは複数の人が掛け合いながら話が進んだので、やりとりをサマリでまとめていきます。
どうやって学んできたか
交流での学び（高崎さんの場合）
まずは高崎さんが学んできた経緯の話となり、キャリアを歩み始めたときにデータモデリング入門の本に出会い、データモデリングを学び、その後オブジェクト指向のブームの当事者だった人たち（今回の主催の増田さんなど）と交流していくことで色々な経験を積んでいった。そんなご自身のキャリアを振り返ったときに、静的なものであるデータモデリングと動的なものであるプロセスモデリングという区分けをしたときにデータモデリングから学んだほうがいいんじゃないか、という仮設があった。
仕事での学び（藤岡さんの場合）
その話の流れで藤岡さんはどうだったか、という流れになり特異なケースと話しながらキャリアの話となった。藤岡さんのキャリアとしてはSIerとして増田さんの案件にアサインされ、そのプロジェクトに入ったことにより、仕事ととして取り組んだことがスタートだった。そのため自身で学んで行ったと言うよりかは仕事としてやらざるを得なかったという側面が強かったとのこと。
また、高崎さんのデータモデリングをやったかという話題に関しては当時のプロジェクトのリーディングであった増田さんと一緒にやったが、当時は増田さんがテーブル設計などをしていたので、あまりやったとは言える形ではなかった。
原田さんの経験の話になり、一番最初は画面や帳票の分析（今で言うInfomationArchitecture）をどういう情報の塊かという分析をしていた。そこからT字型ER図に出会いモデリングの内容に興味を持つことになった。そこからお客さんの話を聞いてモデルを起こすということをやってきて、そしてDDDの着目し、お客さんからの要望をモデルに起こしていくというようなことをやってきた。その中でスクラムをうまく回すにはユーザーストーリーからいきなり実装に起こすのは難しく、モデルを作ってやると良さそうという考えができ、アジャイルとモデリングを両方できるところは…というところで現職にたどり着いたという話だった。
コマンドとクエリ（かとじゅんさんの場合）
かとじゅんさんの経験としては、もともとはSeaserで開発をしておりトランザクションスクリプトもドメイン駆動も両方やってきた。当時の楽々ERDレッスンやグラスを片手にデータベース設計などの書籍を見ながら学び、データベース設計は業務で腐るほどやってきた、とのことだった。そんな中エリック・エヴァンスのドメイン駆動設計に出会った。その中でDDDはHTTPでステートレスなウェブの開発とは相性が悪いのではという葛藤があったがコマンドとクエリに分離して考える考え方にたどり着き、手応えを感じた。
コマンドとクエリの考え方は一旦クエリはおいておき、コマンドに着目してモデルを考え、コマンドの振る舞いにフォーカスして、そこにデータを持つようにすることでスッキリとしたモデリングになった。
知識を追いかけて身につく（hirodoragonさんの場合）
ヒロさんの場合は「どうやって学んできたか」と聞かれるとモデリングを学ぼうと思って学んできた形ではなかったという。
もともとのキャリアスタートも職業訓練校からエンジニアになり、先輩もいない中で手探りでやってきたのでプログラムを書くということだけで必死だった。そのため最初は継承などもノリで使うなど、オブジェクト指向型言語のうまい使い方がわからない状態で使いづらさを感じていた。
そんな中外部のすごい人と仕事をする機会があり、その案件で「DDDをやります」ということになり、DDDとはなんだ？という軸で調べて行きドメイン駆動設計の思想に触れて、クラスがどういう単位であるべきかなど腑に落ちた。そしてDDDの知識を深めるにはオブジェクト指向の知識が必要となり、そこからオブジェクト指向をやるならクラス図を読めないと駄目というところからクラス図のUMLの勉強をはじめたというような流れでモデリングにたどり着いた。
そのためDDDを知りたかったというところが起点で色々知らなければいけないことを学んでいったらモデリングにつながっていった。
自分の力として身につける方法
この話の流れでミノ駆動さんから「モデリングしたらどういう旨味があるのか、モデリングはひどいコードにぶちあたったときに効果が出るのではないか」という話になり、ミノ駆動さん自身が巨大クラスと対峙するためにモデリングをしてきたという経験という話があった。また、問題があるモデルと対峙するという経験から様々なオプションを考えることができ、そこから役に立つモデルなどを考えることができる。ただモデルは一人で作るものではなく、公開して色々な人から意見をもらって討論したりフィードバックを求めることが大事。
形から入って覚える
ひどいコードだけではなく、良いコードから得るものもあるという話もあり、きれいなコードの構造としてどういう構造があるかというところから学びもあるという。その中で形から入るという意味ではオブジェクト指向エクササイズは有用なこともある。まずは形から入ることでカプセル化したコードを作るようになり、クラス設計の書き筋がよくなったという例や、エッセンスだけでも意図のズレや作りたい方向がズレが起きずに実装される例などもあった。
Tell,Don't Ask
モデリングをするときに気をつけている考え方として Tell, Don't Ask を徹底しているという話になった。メッセージパッシングのようなタスクを依頼してデータをとる形でないとオブジェクトを加味したモデリングではなく、ただのデータモデリングになりトランザクションスクリプトになってしまう。またオブジェクト同士のデータのやりとりという観点では、CRCカードというワークショップという一人ひとりがオブジェクトとして経ってやりとりをすると理解が深まるケースもある。
どうやって伝えるか、身につけるか
話し手の人たちは、時代の流れなどで一通りやってきているひとなのでやはり学ぶのは難しいのではないかという話になった。（ひろさんが追っかけて覚えた人だったのでしんどいという話もセットであった）そんな中オブジェクト指向プログラミングを半年間で学べた例として、レガシーコード改修をペアオペで行うという事例の紹介があり、その場合は新人さんが半年程度でオブジェクト指向の考え方が身についたという話だった。そういう話からも伝える側と伝えられる側の相性がよければ「ペアオペなどを通じて暗黙知的な知識の共有」のような話のほうが伝承しやすいのではないかということだった。また、体系化はしづらい側面があるという話もあった。
やはりペアオペの例でも養殖されたサンプルコードよりも、身近なプロダクトコードをベースに手を動かして学ぶのが、得るものが大きいのではないかという話もあった。
機会のない人たちへのアプローチ
実際の開発でモデリングができる状態が望ましいが、多くの人がそうとは限らないのでそういう人を救うためのワークショップなどがあれば…という話になり、やはり学びは一緒に学習してぶつけ合う人がいると学びの一歩が早く切れるという話もあった。
また、そもそも近年のエンジニアはクラス図をつくるという経験をしたことがない人も多くいる場合があり、「初めてのクラス図」などの入門的なものも意義のあるものではないかという話があった。
この会話の流れで色々なコミュニティなどの紹介があった
振り切って、戻る
Javaを使えば、クラス図はコードからリバースできるのでJavaのソースコードをマークアップ言語として捉える振り切った考えもできる。経験者であればそういうコードから入ってモデルを追うのはできるが、初級者に求めるのは酷な側面もある。
ただ、振り切った経験というのは必要な場面もあり、振り切った経験をすることでその経験が糧となり、駄目であれば戻るという選択肢をとることができるようになる。ただエクストリームな選択肢ではあるので、もっとふんわりしたものも提供したい側面はある。
会全体の感想
- 自分自身概念理解はなんとなくしているが、ツールやHowとしてのモデリング知識はからっきしなく、実際やったことがないので、UMLをはじめとしたクラス図の書き方とかを叩き込んだほうがいいなというのが今回の率直な感想でした（hirodragonさんと同じ轍を踏みそう）
- いざ実際の現場でどういうことをしてきたかという面の話は学びが多く、以下に他の人に意識を伝搬していくかという点に関しては後々活かせる話も多かったように思えます。
- どうしても複雑な業務ロジックなどがない開発だと、概念整理してモデルをつくろうというよりかは既存の考えの模造でつくる方に倒れがちな気がしているので、立ち上げた瞬間は問題ないがあとからしんどくなってくるケースがあるからチームで開発する場合はしっかりと向き合う、意識をしてもらうという
ことが大事だなと思いました。
- 歴史をなぞったりすると、日本語文献では情報がなかったり、日本の当時の歴史背景が追いづらい（ピアソンショックとかもあったりした）ので歴史を体感してきた人たちに日本のソフトウェア開発の歴史みたいのをまとめてもらえると、追っかける側としてはそこを道標に色々な情報に手を伸ばしやすいのかな…とも思いました。
関連リンク
話に出てきた書籍
