[builderscon 2019]僕のスケジュール帳に CM 撮影が入った日

一寸先は闇。人生何が起こるかわかりません。
自分のスケジュール帳に CM 撮影が入る日がくるなんて誰が予想できるのでしょうか。

CM

あとがき

というわけで CM に出演しました。
まさか勘違いされる方はいらっしゃらないと思いますが念のため言っておきますと、この CM は自分の所属会社であるGMOインターネット株式会社の CM です。
見ればわかりますよね。間違いようがありませんよね。

撮影風景はこんな感じです。

なんだこの絵面。
撮影中はずっと「レフ版まじでまぶしい、熱い」って思ってました。
ついで自分が台本苦手ということに気づかされたり。
（CM のセリフは大筋決めつつすべてアドリブ。）

なおこちらの CM は冒頭画像（スケジュール）を見ると分かるのですが SekkeiKaigi （https://nrslib.com/sekkeikaigi/）の当日朝に撮影しております。
なんというハードスケジュール……。

このようになった経緯も少しお話しましょう。
まず builderscon 幕間 CM のスポンサー応募をするにあたり、CM を作ることになりました。
コンセプトはまじめすぎて１日中話してしまう開発者。
問題となるのは「誰」が出演するのかということです。

アサインされる人はある分野においてある程度の知識をもっていなくてはなりません。
その上でもうひとつ大事な条件があります。
そう、露出を厭わない人であるということです。

どこかにフリー素材になりそうな人いないかなー。
肖像権を気軽に放棄してくれそうな人いないかなー。
NG とかなさそうな人いないかなー。

そんな方はなかなかいらっしゃいませんよね。
というわけで CM に出演することになったのでした。

一歩間違えば炎上必至ですので出演自体も悩みましたし、語る内容についてはそれに輪をかけて悩みました。
そうして悩んで悩んで悩み抜いた結果、それでも思い入れ深いのはやっぱりこれかなぁ、と思ったのがドメイン駆動設計でした。

自分が露出し始めたきっかけはやはりドメイン駆動設計です。
ボトムアップドメイン駆動設計という記事（https://nrslib.com/bottomup-ddd/）を書いたり、
ドメイン駆動設計の講演をしたり（https://nrslib.com/event-after-bottomup-ddd-1/）、
挙句の果てには

お知らせ
この度ドメイン駆動設計の入門書を書くことになりました
初稿は書き上げ、年末出版に向けて頑張ってます！
みなさん、お楽しみに！

— nrs (@nrslib) July 16, 2019

本を書くことになったり。（いまは必死で修正作業などしています。）

今の自分があるのはドメイン駆動設計のおかげだと考えています。
語るならやはりドメイン駆動設計を語りたい。
恐れ多くも語るテーマはドメイン駆動設計にさせていただきました。

これを機にドメイン駆動設計のことを知った方が入門してくれたらうれしいなぁ、と思う次第です。
あとみなさん、気軽に肖像権は手放しちゃいけませんよ。
といったところで黒歴史の言い訳はおしまいです。

インターネットは黒歴史を作るために存在しているからね

— nrs (@nrslib) August 29, 2019

さて、この CM が流れている builderscon ではなんと私もセッションをいたします。

タイトルは「フロントエンドのつくりかた – シンプルなコードを達成するためのセオリー」です。
https://builderscon.io/builderscon/tokyo/2019/session/e756585d-5773-4c0e-88ac-6d42491a0f27
ここまでドメイン駆動設計を推しておいてセッションがフロントエンドというのは、いい感じにちぐはぐですね。

フロントエンドの特定技術について語られることは数あれど、フロントエンドのつくりかたについてはあまり語られたことがないように感じます。
私は今でこそ Web 系でフロントエンドとバックエンドに携わっていますが、それ以前はデスクトップアプリを作ったり、ゲームを作ったりしている人間でした。
ひたすら画面やユーザが触れる部分のプログラムに携わっておりましたので、それらのコードに共通する大事な勘所というのを知っているつもりです。
そこでこのセッションで渡り歩いた結果として得られた GUI プログラミングに共通する「こうするとシンプルになるよ」というコードの組み立て方をお伝えいたします。
時間は 8/31 (土) 13:00 ～。もしご興味あればご聴講くださいませ。

最後に、台本を見てみたいという声もいただいたので、今回の CM のために作った台本（5000 文字弱）を折角ですので紹介してお別れいたしましょう。
内容はちょっと乱文です。すこし大目にみていただければと思います。
ちなみに他にも「クリーンアーキテクチャ」「フロントエンド」「オブジェクト指向プログラミング」といった台本もあったりします。
それらはまたの機会かな。……またの機会なんてあるのかなぁ。

台本

ドメイン駆動設計はドメインを基軸にした設計手法です。といってもよく分からないですよね。
そもそもドメインとはなんぞやみたいな。
私たちはインターネットのドメインを販売していますけど、そのドメインとは違うもともとの意味に近いです。
つまり「領域」。
とりわけソフトウェア開発の文脈上ではドメインは「ソフトウェアを適用しようとする領域」のことを指します。
たとえば銀行システムのドメインには貨幣や取引なんていう概念がありますし、物流システムには配送とか荷下ろし、それ以外にトラックとかもあります。
こういったドメインの内部のモノやコトに正対しながら設計開発を行うというのがドメイン駆動設計です。
なんだか難しそうに思えますよね。でもこれってすごく当たり前なことなんですよ。
だって、そうじゃないですか。ソフトウェアって利用者のために、つまり利用者の問題を解決するためにあるじゃないですか。
彼らの問題を知るには彼らが見えてる世界を見る必要があるでしょう。
でも残念ながらそうではないケースが多いんです。
問題となるケースはだいたい３種類に分けられます。

ひとつめは技術者は技術に傾倒しがちという事実です。
技術者というのは技術が好きです。問題に相対すると技術をうまくつかって解決したがります。これがときに問題になります。
たとえるなら、ネジを留めるのにハンマーで叩くようなもんですかね。普通はドライバーを使うでしょう？でもピカピカのハンマーを使いたくなっちゃうんです。

ふたつめはドメインに精通する人が協力的でないときです。
ソフトウェアを適用する領域、つまりドメインをよく知る人ってどんな人かご存知ですか？
ステークホルダーじゃないですよ。
ドメインをよく知る人はドメインの実践者、つまりドメインの世界に生きる人たちです。
なぜ、彼らの協力を取り付けるのが難しいのかというと、まずそもそも彼らは根本的に忙しいです。
誰だって自分の仕事に手いっぱいですよ。その上でソフトウェア開発に協力してください、といってもなかなか難しいものがあるでしょう。
さらに、残念ながら彼らの多くは自分たちの仕事を助ける可能性があるソフトウェアの力を軽視しています。
しかたないですよね。人は目の前にないものの力を信じるというのがニガテです。
「あなたを助けます。だから協力してください」って言われても胡散臭いイメージしかしませんよね。

みっつめのケースは橋渡しができないときです。
運よく技術者がドメインを理解することに協力的で、運よくドメインの実践者がソフトウェア開発に協力的だったとしましょう。
でも、彼らはマネージャーとか管理者経由でないとやりとりができないっていうプロジェクトがたまにあるんです。
私たちは会話をする生き物です。会話ってすごいんですよ。文脈や行間、ニュアンスっていったところに多くの意味が込められている。
ドメインの活動、すなわち人の営みはそもそも複雑です。それを文字だけで表現しようとするとものすごい膨大な文章が必要になっちゃいます。
会話であれば５分で終わるものも文章にすると数千文字になったりすることがあって、そういったときに待ち受ける結果としてよくあるのが「諦め」です。
情報のやりとりが面倒に感じると、そもそもの情報のやり取りをやめてしまうんですよね。

そういったわけで一言に「ドメインを基軸として開発をする」という単純にみえることを実現するのは実は難しいんです。
ドメイン駆動設計はそれに真っ向から立ち向かったものです。

従来的な開発手法は設計と開発を分けて考えることが多くありました。
ある人が設計を行い、その開発を別の人が行う。これはまさにドメイン駆動設計とまったく正反対ですね。
たとえ設計というフェーズでドメインについてアレやコレやの議論があったとしても、開発段階ではすべてなくなります。
当然のごとくドメインの知識というものは失われ、ソフトウェアにドメインの知識は反映されません。
当面はそれで動作するときでしょうが、問題となるのはドメインが変化したときです。
世界が動いているようにドメインも刻一刻と変化します。
ドメインの変化を伝えるのに、ドメインを表現したものとそうでないものではどちらがうまくいきそうですか？
ソフトウェアというのはいつだって、新しく作るよりも既にあるものを変化させる方が難しいのです。

ドメイン駆動設計はドメインとコードをモデル–ドメインの概念を抽象化したものです。それを通して繋げます。
開発者たちは担当を分けることはありますが、開発者はすべからくドメインを理解します。
そうしてコードにドメインを込めるのです。コードはドメインの別の姿です。
そうなっていればドメインの変化をソフトウェアに伝えるもの簡単ですよね。変化をそのままコードに反映すればいいのですから。
と、言葉でいうのは簡単なのですが、そこに至るまでの道のりは途方もないです。
ドメイン駆動設計はそこに至るまでのプラクティスを説いているのです。

そのプラクティス、どういうものか気になりますよね。
ドメイン駆動設計を学び始めると、ユビキタス言語、ドメインエキスパート、エンティティ、境界付けられたコンテキスト……いろいろな用語が出てきます。
正直な話、引きますよね。怖いって思いますよね。
そんなわけで敷居が高いと思われがちなのがこのドメイン駆動設計です。
自分はドメイン駆動設計を説明するとき、そのテーマがパターンとモデリングのふたつに分けられるというお話をします。
まずパターンはすなわちコードの直接的な書き方です。これはサンプルとして示しやすく、開発者にとって受け入れやすいものです。
次にモデリングはどのようにドメインの知識をかみ砕くかといったことです。パターンに比べると若干マインドに近い話の為、理解に落ちるまで少し時間がかかります。
入門する際にお勧めしているのは前者、すなわちパターンです。ただ、口頭の場合はモデリングの方が理解しやすいと思うのでモデリングについて具体的な内容をお話しますね。
もちろんこれはモデリングだけ行えばすなわちドメイン駆動設計であるということは意味しません。
ドメイン、モデル、コードとみっつ並んでるとしたら、ドメインをモデルにするのがモデリング、モデルをコードに落とし込むのがパターンです。いずれに傾倒してよいものではありません。

ドメイン駆動設計の代名詞といえばドメインエキスパートとユビキタス言語だと思います。
ドメインエキスパートというのはドメインの精通者です。
ドメインの知識を多く持っている方ですね。ドメインの実践者でもあるはずです。
開発者は彼らと対話することでドメインを理解していきます。
ドメインを理解するにはドメインを生きる者との対話が必要なのです。
さて、この対話ですが、どういう対話になるでしょうかね。
技術者って技術のことで頭がいっぱいなのですよ。
ドメインエキスパートがドメインの重要な概念について話していたとしても、それをデータベースに保存するとかそういったことに意識がいきがちです。
だからたとえばドメインエキスパートが「ユーザを登録する」って表現したとしても、開発者は「ユーザを新規保存する」とか言ってしまう。こういうわずかな言葉のズレが実は厄介なんです。
ドメインに対する鋭い洞察というのは刹那的で、それを見逃さないためには集中する必要がある。
けれど、言葉が違うとその言葉の翻訳にコストを取られてしまう。結果としてドメインの重要な概念が見つけられない。
そんなことが発生してしまうのです。

どうすればよいか？　簡単です。共通の言葉で話せばいい。ユビキタス言語はまさにそのようなコンセプトです。
ユビキタスは「いつでも、どこでも」という意味です。それを関するユビキタス言語はプロジェクトにかかわるみんなが共通の言語を話すようにするということです。
これ、簡単そうに見えてすっごく難しいんです。
言葉は文化ですからね。相手の言葉を知り、その言葉で話すことは相手の文化を知ることです。
つまり、ユビキタス言語を策定するということは相手の文化を知ることと同義です。
開発者はドメインエキスパートと協力して、ドメインを知ることに努めなくてはなりません。
ここでミソになるのが「協力して」というところです。
そう、ユビキタス言語は開発者だけでは作れないんです。ドメインエキスパートの協力が必ず必要になる。
もちろん「協力」なので、開発者はドメインエキスパートの言葉をそのまま話せばよいわけではないです。
ドメインエキスパートはドメインのことをよく知っていて、ドメインの話をできますが、私たちが作りたいのはソフトウェアです。
ユビキタス言語はプロジェクトのためにあります。ドメインのすべてが必要ではないのです。

たとえば物流システムにトラックという概念があったとしましょう。
トラックが荷物を運べるという概念は物流システムにとって重要ですよね？
燃料とか運転手とかそういった概念も重要でしょう。
でもキーをまわすとエンジンがかかるとかアクセルペダルを踏むと前進するとかいった情報はほとんど有効ではないですよね。
ドメインエキスパートはその取捨選択はできません。ソフトウェアにとって何が重要かわからないから。
私たち開発者はそれを引き出してあげなくてはいけない！

また、反対にドメインエキスパートの言葉が漠然としすぎて曖昧すぎる場合もあります。
コンピュータは人間の曖昧さというものがとても苦手です。
開発者はドメインの用語の曖昧さを指摘し、明確にしなくてはいけない。
こうして双方向のコミュニケーションを行い、プロジェクトのための共通言語を作るのがユビキタス言語です。
決して単語帳を作るとかそういった話ではありません。

壮大すぎますよね。実際そうだと感じています。
ドメイン駆動設計はもう十年以上も前に打ち出された考えで、一定の評価を受けているものです。
しかし。その壮大さゆえにドメイン駆動設計は未だ普及しきっていません。
もしも本当に普及してたらドメイン駆動設計という言葉は消えているはずです。
だってそうでしょう？　生活するのに「呼吸しなきゃ」とか思わないですよね。酸素を意識しながら呼吸しないですよね。

本来であればドメイン駆動設計が求めることは当然のことです。
三角形をえがくのに、三角形のことを知らなくてはいけません。
内角の和が180度であるとか、底辺×高さ÷２で面積が求められるとかそういった情報です。
何かをするにあたって、その対象を知るということは当然のことです。
そしてソフトウェアにとって重要な概念を抽出する、つまりモデリングという行為はプログラミングをする上で必ず必要な行為です。
ドメイン駆動設計はまさにそんな当たり前のことを実践するために必要なことをまとめたプラクティスです。