【第1回・前編】 エンジニア和田卓人の今を形作る技術

・伊藤 直也さん / 株式会社 一休　執行役員 CTO

新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務めた株式会社はてなでは「はてなブックマーク」などの開発を主導。グリー株式会社では統括部長としてSNSを担当した。2016年4月、一休に入社し執行役員CTOに就任。

 

・和田 卓人さん / プログラマー、テスト駆動開発者

学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。

『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『事業をエンジニアリングする技術者たち』（ラムダノート、2022）編者。テストライブラリ「power-assert-js」 作者。

Twitter: @t_wada
GitHub: @twada

 

 

 組織のエンジニアリング文化に外部から影響を与える仕事

 

 

伊藤さん：和田さんというと、「テスト駆動開発の人」っていうイメージが強いですよね。
それに加えて、最近では「質とスピード」という講演を通してその名を知ったという若い人も少なくない気がします。

 

和田さん：そうかもしれません。「質とスピード」という講演は、もともとはエンジニアリングマネージャー向けのカンファレンスでの演目だったんですよ。

「質とスピードはトレードオフの関係にある」という思い込みは、それこそおそらく幼少期からいろんな形で我々に刷り込まれるわけですが、ソフトウェアに関しては必ずしもそうではない。それをデータとロジックで伝えようという講演でした。

その講演後に、いろいろな会社の人から「社内向けにやってほしい」という再演依頼を何度もいただいて、今に至っています。

 

伊藤さん：再演の依頼は、どういう会社のどういう立場の人からくるんですか？

 

和田さん：自分が技術顧問としてお手伝いしているソフトウェア系の企業のこともあれば、自社サービスを開発している企業や、いわゆる「JTC（ジャパニーズトラディショナルカンパニー）」と呼ばれる企業まで、様々です。

依頼をくださるのも、そうした企業の社長とか部長とか、エンジニアリングマネージャーとか、あとはプロダクトマネージャーとか、いろいろです。

 

伊藤さん：自分も昔、いくつかの会社に「内製のほうが良い」と話していたことがあって、あれはトップマネジメントにとって時間の短縮にはなったかもしれない。

とはいえ、和田さんは「ソフトウェア開発では質とスピードは必ずしもトレードオフの関係にはない」という話をしにいくわけですよね。
そういう話って、非エンジニアの人たちに対してどれくらい響くものなのでしょうか？

 

和田さん：講演させていただく企業では、社内でSlackを使っているところが多いのですが、そこに講演の実況チャンネルを作ってもらい、そのチャンネルを社内の人たちに広く見てもらうようにしています。

そこで講演の内容をエンジニアが実況して、それがリアルタイムにどんどん盛り上がっていく様子が、みんなに見える。
「場を見せる」ことが舞台装置となって、ソフトウェア開発者たちの意識や文化が意思決定層にも伝わるんですよね。

質とスピードの話の中身ももちろん大事なんですが、どちらかと言うと、その舞台装置を通じて意識を変えて文化を根付かせに行く感じかもしれません。

 

伊藤さん：なるほど、必ずしも内容そのものを理解してもらうのではなくて、組織を動かすために事の重大さが伝わるようにするわけですね。
コンサルティング的なお仕事に近いものがありますね。

 

和田さん：まさに同じような感じです。
いろいろな会社でコンサルティング業とか技術顧問業をやっていますが、最初は「テストのハウツーについて教えてほしい」みたいな依頼で声をかけていただくことが多いんですよ。

でも実際に行ってみると、テストが書けないというのは結果としての現象であって、原因ではないことが見えてくるわけです。

それで原因のほうを探っていくと、背後にある文化的問題や構造的問題、たとえば「テストを書いても報われない構造」や「そもそもテストが書きにくい状態」などをいろいろなアプローチで解きほぐしていくことになります。

その会社に応じた問題解決のお手伝いや人材育成のお手伝いをやっていくことになるので、特定のアウトプットを保障するというよりは「なんでもやる」になり、契約としても技術顧問っぽい形になることが多いです。

 

伊藤さん：継続的に見ていく感じですね。
そういうやり方だと、あまり多くは掛け持ちできなそうです。

 

和田さん：今は週に1回、「この曜日はぼくがいる」という具合で3社か4社のお手伝いをしています。
それ以外の曜日はSlackでメンションしてもらえば対応する、という感じで。

昔は月に1回くらいの関与でやらせてもらうこともあったんですが、その頻度だとあまり結果を出せないことが多いんですよ。

 

伊藤さん：翌月になると、だいたい前回やっていたことを忘れてしまいますからね…。

 

和田さん：月1でもうまくいく形はありまして、たとえば具体的にはピクスタさんです。

ピクスタさんは取引が最も長いお客さまで、以前は週1日以上かかわっていました。

いまは若いCTOの後藤さんに代替わりしまして、自分としては愛弟子みたいな感覚なんですが、彼が切り盛りして独り立ちできているから、近頃は月一で「最近どう？」って聞きに行くおじさん役をやっています。
これは技術顧問としてはかなり幸せなケースですね。

 

伊藤さん：他の会社ではどんなことをされているんでしょうか？

 

和田さん：お客さまによって課題感とか規模感が違うので、やっている仕事は割とバラバラです。

社内読書会や社内研修みたいな教育に力を入れている会社もあれば、チームでモブプログラミングを行って問題解決していく場合もあるし、テストの自動化まわりのお手伝いをすることもあります。

 

 

コードが書けない匂いを帯びたくない

 

 

 

伊藤さん：ぼくも一時期、コンサルティング業を中心にやっていた時期があったんですけど、それを辞めて一休っていう会社に入ることにした背景に、「このままやっているとたぶんソフトウェアエンジニアとしては賞味期限切れになるな」という危機感みたいなものがあったんですよ。
和田さんはそういうのはないですか？

 

和田さん：そういう意味では、個人で受託開発もやっているので、実はソフトウェアエンジニアとしての業務も続けているんですよ。

 

伊藤さん：ぼくは、コンサルティング業をやっていた間は受託開発などをまったくやっていなかったから、それこそ現場の開発をしない期間ができてしまった。

 

和田さん：あと、受託だけでなく、自社で商用製品のコードを書いて、そのライセンス販売なんかもしていました。

 

伊藤さん：和田さんの会社って、規模的にはそんなに大きくないですよね。そんなにいろいろやっていたなんて、全然知らなかった。

 

和田さん：知らなかったでしょ。二ッチな分野のクローズドな製品なので無理はないと思います。

具体的にはワークフローエンジンを作って、それをグループウェアの会社などに組み込んでもらったりしていました。
2010年前後はそのあたりをずっとやっていたので、技術顧問業が収益の柱になったのは、実は2015年くらいからなんです。

 

伊藤さん：現在の売上的には、やはり技術顧問業のほうが多いんですよね。

 

和田さん：はい。受託開発などは割合としては微々たるものです。

 

伊藤さん：おそらく収入面やキャッシュフローに関しては技術顧問業で十分なのに、そこに留めずに受託開発なんかを今でもやっているのは、やはり腕を鈍らせないようにでしょうか？

 

和田さん：それ以外の理由はほぼないと思います。

 

伊藤さん：それ以外の理由が、ない…！

 

和田さん：まあもちろん、お客さまのビジネスをお手伝いする手応えもあります。ありますが、とはいえ、腕をキープするという思いも大きいです。

技術顧問業は、手に余るようになってきている大きな既存プロジェクトを俯瞰して引き分け以上に持っていく、みたいな仕事も多かったりするわけです。
コードを書くこともありますが、誰かと一緒にコードを書いて、その過程を見せるのも仕事の一部なので、基本はペアプロとかモブプロです。つまり技術顧問業はソロではコードを書かないんです。

自分で書いたコードを動かして不具合が出て冷や汗をかく、そのコードで利益が出たり損害が出たりする、デプロイを自分でキックする、運用で障害が起きたらオンコールが飛んでくる、そういうギリギリの現場感とつながっているためには、「最初から最後まで自分でやる」という機会を持ち続けるしかないと考えています。

それを続けないと、本当にコードを書かなくなっちゃって、結果的に技術顧問業にも跳ね返ってくると思うんです。説得力がなくなってしまう。

ソフトウェアエンジニアって、「ああこの人、もうコード書いてないな」みたいな感覚が匂いでわかるじゃないですか。

 

伊藤さん：わかる。
同年代のソフトウェアエンジニアと会話すると、結構な人がもう書かなくなっていて、「あ、この人書いてないな」って話の端々から良くも悪くもわかってしまいます。

 

和田さん：自分の若い頃の経験から言っても、その当時に年上の人を見て、「偉そうなことを言っているけど、コードは書いてないな」みたいな匂いには敏感でしたよね。

結果的に、やっぱりコードを書いている人の説得力のほうが高いわけです。

良し悪しはありますが、「コードを書ける人の言うことなら聞いてもいいかな」みたいな感情もありますよね。
「正しそうなことを言うけどわかっていなそうな人」じゃなくて、「ちゃんとコードを書ける人」というところを頑張って維持したい。

 

 

PofEAA読書会を通して得られたもの

 

 

伊藤さん：実際、講演などをとおして日頃の和田さんの活動を拝見していると、圧倒的な知識量に裏付けされた話をしているので、「勉強量がすごいなあ」と思っています。

この期間はあんまり勉強してないなという様子もなく、コンスタントにずっと学習されているなっていう印象です。

そもそも、ぼくが和田さんに初めてお会いしたのも、技術書の読書会だったんですよね。

 

和田さん：そうでした。
PofEAA（Patterns of Enterprise Application Architecture）の読書会だったでしょうか。

 

伊藤さん：そうです。2006年くらい。その読書会にいったら、和田さんがいたんです。

ほかにも、その当時からRubyのコミュニティで活発に活動されていた角谷さんや高橋さん、それに角さんとか舘野さんみたいな著名な人もたくさん参加されていて。

ぼくが勉強会みたいなところに行くようになったのは、あれが最初です。

 

和田さん：1995年ごろから2005年ごろにかけては、Pearson Educationという出版社から割と大事な本がいくつか出て、PofEAAもそういう本の1つでした。

『エンタープライズアプリケーションアーキテクチャパターン』という書名で2005年には翻訳も出ていたんですが、翻訳だと原著の意図が完全には読み取れなかったりしたので、みんなで原書を持ち寄って月1くらいの間隔で1章ずつ読もう、と。

 

伊藤さん：自分も、大事なことが書いてある本だからどうにかして理解したいと思ったけれど、いかんせん難解で、一人では読み切れなかったんですよね。

でも、実はあの読書会が自分にとって重要だったのって、PofEAAという本を理解したことよりも、むしろ和田さんとか角谷さんみたいな界隈の人たちと繋がれたことだったかもしれません。

難しい書籍を読破しようという意気込みのある人たちの関心事をフォローしていくことで、自分が次に吸収すべきことの道筋が自然に見えていったというか。

 

和田さん：読書会の意義は大きかったですね。それ自体がコミュニティみたいな面がありました。

勉強会とか読書会って、今はオンラインでやっていることもありますが、あの当時はオージス総研さんとかが会場を提供してくれて集まっていたので、読書会の後で懇親会もあり、むしろそっちが本番みたいな。

 

伊藤さん：今みたいなご時世だと、集まって懇親会は難しいですよね。
オンラインは参加しやすくていいけれど、クローズドなオフラインの場でしかできない話がしたいという要望はなくならないと思うので、現代においてどうすればよいかは悩みどころかもしれません。

 

和田さん：同世代くらいで活発に話ができて、心理的安全性もある程度は確保された空間みたいなところが大事っていうのは、今も昔も変わらないですよね。

そういう意味では、Discordをつなぎっぱなしにしてオンラインでハッカソンやったりとか、競プロをやったりとかは、普通に行われている印象ではあります。

場が変わってインフラも変わったけれど、オンライン上でもやれている人はやれているように見えます。
言語ごとに規模が大きくてわりと活発なSlackがあったりするんで、発言しなくてもいいから入ってみるとかもよさそうですよね。

 

伊藤さん：そういう場で読むべき本を知るみたいなのもありそうですよね。

PofEAAの読書会でも、「この本を読んだら次はこれ」っていうコモンセンスみたいなのもあって、すごく参考になりました。
PofEAAを読み終わったあとなら「次はエリックエヴァンスのDDD（Domain-Driven Design）だ」とか。

 

和田さん：エヴァンスのDDD本、あの水色の表紙の原書ですよね。

あの本を「これ面白いよ」とPofEAA読書会に持っていったのは、実はぼくだったんですよ。
「PofEAAの中にもリポジトリパターンの話が出てくるけど、こっちの本にはもっと詳細に解説されているよ」って。

 

 

価値のある技術書は、きちんと翻訳出版されてほしい

 

 

伊藤さん：あの当時、エヴァンスのDDD本はまだ翻訳もなかったんですよね。

 

和田さん：2003年には原書が出ていたけれど、翻訳版はけっこう時間がかかってしまいました。
翻訳が出版されたのは、ようやく2011年になってからです。

 

伊藤さん：覚えてます。QCon Tokyo 2012に行ったら、みんながDDDの話をしてました。
あのときのQConにはエリック・エヴァンスさんご本人もきていたんですよね。

 

和田さん：翻訳の出版までそんなに時間がかかってしまったのは、実は自分にも一因があったんですよ。

翻訳書の出版社である翔泳社の方に知り合いがいて、DDDってちょっと特殊感がある内容だったこともあって、自分も翻訳についていろいろ相談されて。

私自身が訳者の形としては関与できなかったんですが、和智さんを訳者として紹介したり、DDDコミュニティでレビューを行ったりしました。
そうやって慎重に進めてもらった結果、完成までだいぶ時間がかかってしまった感じです。

やっぱりこういう本の翻訳って、いったん悪い形で出てしまうと業界にダメージを与えるわけです。

ぼく自身もそうなんですが、あの当時の読書会に出ていた角谷さんや角さんが多忙な中でいろいろな本の翻訳に腐心しているのって、その辺の危機感からというのが大きいと思います。

 

伊藤さん：翻訳がまずいと業界にダメージが残るという話、すごくわかりますね。

それこそDDDなんて、2003年に原著が出ているのに、20年近く経った今になってようやくWeb業界の人たちの間でも「これが良いんじゃないか」って広く認識されるようになり、ある程度は使いこなせるようになってきた。

自分自身、最近になって「いままでの理解では間違っていた」みたいな気づきがあり、いまだにちゃんと理解したとは言い切れない。
まさか2003年に原著が出た本から20年後に学ぶことがこんなにあるなんて、当時はまったく思っていませんでした。

これだけ長く話題になるような本が、翻訳の善し悪しによって、この熱量が存在しなかったことになってしまうかと思うと大変なことですね。

 

和田さん：良い具合に生き残った本だと思います。

 

伊藤さん：翻訳というと、これもDDDの本なんですけど、ちょっと前に“Domain Modeling Made Functional”という本を翻訳したいという話をみかけたんですよ。

タイトルに“Functional”ってあるとおり、いわゆる関数型のアプローチでDDDをやろうという内容で、実装例に使われている言語もF#です。

それで、はてなのCTOであるmotemenさんがこの本のレビューを書いていて、そのはてなブックマークに「翻訳したけど出版社が見つからない」っていうコメントを残している方がいて。
「それはもったいない」と思って、ツイッターで拡散したんです…。

 

和田さん：実は、伊藤さんのツイートを見かけて、自分もその方にDMを送りました。

 

伊藤さん：和田さんが巻き取ってくれてたとは！

 

和田さん：どうやらその方は、ある出版社に持ち込んだけれど、そこでGOが出なかったらしいんです。

なので、「出版社への翻訳の持ち込みは、企画を練り直して再チャレンジできるから、諦めないで一緒にやりましょう」と伝えました。

翻訳出版企画が通るかどうかのラインは、持ち込む出版社によっても違いますし、少しだけ練り直して持っていけば、売れる本として出すこともできるかもしれません。

実を言うと、そうやって別の出版社に持っていって形になったケースは、自分が巻き取ったものだけでもほかに何冊かあります。

 

伊藤さん：ちなみにそれって、和田さんに何か見返りがあるわけではなく、ボランティアでやっているんですよね？

 

和田さん：ボランティアです。

どちらかと言うと、私自身も良い本だと思っている洋書が、「売れそうにない」みたいな切ない理由で出版社から翻訳企画を断られてしまうことに心を痛めている、という面もあったりします。

ちゃんと舞台を変えれば売れるし、世の中に出せるぞというのを、見せたい。

“Domain Modeling Made Functional”にしても、出版社で却下される理由は「F#で書かれているから売れないだろう」とかなんですよ。
本としての価値が見えてないから、「そうじゃないんだ」ということがわかるようにして別の出版社に持っていくだけで、話が前進したりするわけです。

 

伊藤さん：そのへんのプロセス、ずっと不思議だったんですよ。

英語で書かれた技術書で、ぼくらエンジニアからすると「この本は絶対に和訳したほうが良い」みたいなのって何冊もあるじゃないですか。

中には、なんでこの本の和訳を誰もやらないんだろうな、というものがあったり。
裏で和田さんが一度ポシャった企画を復帰させたりしていたんですね。

 

和田さん：自分だけじゃなくて、ほかにも何人かそういう動きをしている人がいると見ています。

ただ、最近の傾向として、そもそも本が売れなくなっているのは事実なので、やっぱり翻訳企画の難易度は上がっています。

以前は、それこそ「俺を信じろ」みたいな雑な説得の仕方で企画がとおることもあったけれど、最近はそうもいかないので、もうちょっと丁寧に企画として練り直しが必要になっていますね。

 

伊藤さん：ソフトウェアエンジニアの人口自体はかなり増えているはずなのに、技術書が売れなくなってるのは、どうしてなんでしょうね。
ぼくは、ソフトウェアエンジニアっていうのは本を読んで勉強する生き物だと勝手に思い込んでいるので、体感として書店のコンピュータ技術書の面積は狭まり続けているのが不思議なんですよね。

 

和田さん：学び方が変わっているのかもしれません。
Webサイトや動画、それにスクールも増えて、以前のように学ぶ手段が本だけじゃなくなった。

 

伊藤さん：確かに。最近話題になっていた「タイパ（タイムパフォーマンス）」の話ですよね。
最近の若い人たちにとっては、漫画でさえタイパが悪いらしくて、動画にしてくれと。

ツールの使い方とかプログラミング言語のシンタックスを確認するだけなら、動画とかWebでもいいんですけど、DDDの本みたいな古典的な内容って本以外の形で吸収できるもんなんですかね。

 

和田さん：個人的にも、さすがにそれだけだと厳しいと思うので、できるところは巻き取って出版の機会を増やしたいんですよ。

技術顧問として社内読書会をやることも多いのですが、それには「本を読んで勉強するってこんな感じだよ」というのを教えている側面もあります。
そうすると、「技術書ってコスパが良いんですね」という、実に印象深い感想が出たりするわけです。

 

伊藤さん：「技術書ってコスパが良いんですね」って言ってくるっていうのは、明らかにカルチャーギャップがあるってことなので、それはちょっと衝撃的ですね。

 

 

技術の進化と受容は「らせん」を描く

 

 

伊藤さん：エヴァンスのDDD本の話に戻るんですが、2003年に出た書籍に書いている話を、20年経ってもまだ「こう解釈すべきではないか」「ここがよくわからない」と議論している現状は、これはこれでどういうことなんだろうって思う側面もあります。

これって、翻訳が遅れた日本ならではの現象なんでしょうか。
それとも、英語圏でもやっぱりDDDについていまだに議論されているのか。その辺の温度感ってどうなんでしょうか？

 

和田さん：英語圏でも、いまだにDDDについて議論されていたり、参照されたりしています。
そういう意味では日本国内と同じですね。

ただ、参照されている文脈にはちょっと違いがあります。

もともと英語話者にとっては、DDDで言うところの「ユビキタス言語を使おう」みたいなことは、当たり前の話としてずっとあったんです。

ところが最近になって、「境界づけられたコンテキスト（Bounded Context）」をマイクロサービスの分割の観点として使おうという話が増えてきました。

Sam Newmanのマイクロサービスの本が出た当時、みんな分割の仕方をいろいろと試して、わりと痛い目にあうこともありましたよね。
「データベースのリレーションシップを見て一番少ないところで切ってみよう」とか。

 

伊藤さん：データベースの構造に合わせて分割するって、今でこそアンチパターンなんですよね。
でも、うちの会社を含め、そういう間違えた切り方によるマイクロサービスの試みは漏れなくありました。

 

和田さん：基本的に、マイクロサービスの分割の境界線をどういう切り口にするかは、難しいんですよ。

それが、海外では「DDDに出てくるBounded Contextがマイクロサービスにおけるサービスという単位にうまくフィットするのでは」と議論されだして、「マイクロサービスが出てきてからDDDに光が再度当たるようになった」みたいな感じで捉えられている印象です。

 

伊藤さん：Bounded Contextって、エリック・エヴァンスの本では最後のほうの戦略的デザインのところに出てくる話で、いわばDDDの本懐ですね。

 

和田さん：そう。
マイクロサービスや分散システムを戦略に照らして分割するにはどうするか、という話です。

あとは、ドメインイベントやEvent Sourcingに関する議論もよく見かけます。

たとえば企業のシステムを作ろうというとき、企業の活動というのはいろいろな人が関与するプロセスだから、データ構造の前に「仕事の流れ」を考える必要があるだろう、と。

その流れにはコンピューターも参加するし、人も参加するから、コンピューターの時間だけでなく人の時間でやる処理、つまり「長いトランザクション」なんかも考慮しなければならなくなるわけです。

そこから、「誰がいつ何をやって、次にシステムが何をするか」といった観点でプロセスをモデリングしようという、後のEventStormingみたいな話につながってきます。

ただし、こうしたプロセスモデリングの話って、エヴァンスの本にはあまり出てきません。

エヴァンスの本が出た2003年ごろはまだUMLとかDOA（データ中心アプローチ）が全盛で、どちらかと言うとドメインイベントやEvent Sourcingのような動的な側面よりも、エンティティのような静的な構造のほうに光が当たりがちでした。
それこそエヴァンスの本が出るまでは世の中としては「コードを書かなくてもいい」みたいな過剰なマーケティングもありました。

エヴァンスの本にしても、UMLに対して中立的な立場を取りつつもクラス図をよく使っていたり、プロセスモデルよりもデータモデルのほうが大事みたいな傾向があったりします。

構造とかデータモデルに光を当てて設計すべきか、それともイベントに光を当てて設計すべきかみたいな議論って、それこそ1960年代ごろから追いつけ追い越せでずっと続いてきたわけです。

 

伊藤さん：エヴァンスの本は2003年に出ているんだけれども、その後の20年で概念が整理、成熟、進化しているから、一概に「俺たちは2003年の話をいまだに議論している」というわけではないってことですね。

 

和田さん：まさにそうで、こうした議論は「らせん状」に発展していくものなんですよ。

 

 

20年前のDDDの議論がそのまま繰り返されているわけではない

 

 

伊藤さん：そういえば、CQRSとEvent Sourcingの関係みたいな話も、ここ数年になってよく話をみかけるようになりましたね。

CQRSは、どうも整理していくと単に「呼び出しのモデルと書き込みの更新のモデルを別々にしてもいい」という話が発端のようですが、当初に話題になったときは「Event Sourcingが不可欠」と語られていた記憶があります。

そのせいか、今でもGoogleで検索すると両者がセットで出てくるんですが、実際は必ずしもセットにする必要はないようですね。
“Domain Modeling Made Functional”にもはっきりそう書いてありました。

みんな、そのことにどこかの時点で気がついた。

 

和田さん：何らかの概念が登場すると、どうしても、企業はそれにかこつけてサービスやミドルウェアを売ろうとしがちなんですよね。
「CQRSをやるならEvent Sourcingが必要ですね、そこで弊社の分散メッセージング環境を導入してください」みたいな話になりがちなんです。

UMLツールなんかでも同じことがありました。

 

伊藤さん：エンタープライズ業界でよくあることなんですね。
大昔にXML Web Servicesでエンタープライズ企業がミドルウェアを開発して、盛んにマーケティングを繰り広げていたのを思い出します。

若い人向けに昔話をすると、今でこそHTTPでAPIを叩いてJSONを取得してパースするのが当たり前だけど、そういう概念が登場した当時はJSONなんてまだなかったし、全部XMLでやり取りしようとしてたんです。

XMLなので、メタデータを駆使すれば単純なAPIだけじゃなくRPCみたいなこともできるし、ステートフルな通信も含めて分散トランザクションができるじゃないか、と。

めちゃくちゃ盛り上がったんですが、結局、そんな大袈裟なことをしなくてもJSONをHTTPで交換すればOKだよねという部分だけが最後に残って今に至るわけです。

そういわれると、「壮大なエンタープライズの仕様から引き算されてシンプルなものが残る」っていう経験、過去に何度かしていますね。

 

和田さん：ベテランになるというのは、そういう「らせん」が見えるようになって、商売っ気を引き算して大事なところが読み取れるようになることなんだと思います。

 

伊藤さん：Web APIに関しても、今は逆にJSON over HTTPSだけじゃ難しいからと肉付けをしてgRPCだとかGraphQLだとかが別に登場してきているので、まさに「らせん」ですね。

ところでGraphQLというと、DDDの話に戻ってしまうんですが、いま作っているGraphQLバックエンドではCQRSパターンを適用してDDDをやっているんですよ。

GraphQLのクエリ側の実装パターンって、普通にやるとDDDととても相性が悪くてですね。
集約単位でエンティティを復元しましょう、というDDDの実装パターンと、欲しいリソースのスコープをクライアント側で自由に決められるGraphQL Queryのコンセプトが合ってない。
そこで読み取り側のモデルと書き込み側のモデルをCQRSによって完全に分離して、読み込み側であるQueryではDDDをあまり意識しない。

一方、書き込み側のMutationについては、しっかりDDDでやれる。

この辺もぼくがDDDについて近年になってようやくちゃんと理解できたなと思っている部分の1つなんですが、DDDって本来「状態を更新する際に、集約を使ってきちんとドメインオブジェクト全体の整合性を取りましょう」という話に重点が置かれてるんですよね。
「ドメインモデルを変更するときはその境界と整合性を維持しよう」というか。

逆に、読み取り側である参照系は、誤解を恐れずに言うと、DDDの主眼ではない。

でも2015年ごろは、読み込みのほうが重要なBtoCの大規模なWebサービスなんかで、ドメインモデルを作り込んでDDDを適用しようとしてミスマッチになってしまうことがありました。

そういうところではCQRSを適用すればいいんだよ、みたいな情報が見つかるようになったのも、自分の理解ではここ数年だったと思います。

 

和田さん：2010年代初頭に出た本にも、すでに情報としては出ていたんですが、あんまり話題になっていませんでしたね。
みんなが議論するようになったのは、確かに最近だと思います。

というのも、やっぱりエヴァンスの本が出た2003年と現在とでは文脈が違うんですよ。

2003年って、まだWebがそれほど巨大ではなくて、大量のトラフィックをさばくような話はあんまりないんです。
本に出てくるのも、船舶の荷物の運搬に関する整合性みたいな題材で、Webのシステムとは全然価値観が違う。
アクセスが集中しても、たかだか社員数プラスアルファぐらいなもので、BtoCのハイトラフィックに晒されるとかは考えなくていい。

あくまでも「企業の活動を破綻なく、かつ欠損なく確実に記録していく」というのが大事で、そのためにDOAとかSystem of Recordっていう話が出てくるわけです。

 

伊藤さん：確かに、エヴァンスの本はBtoBのバックエンドの業務システムみたいなものがサンプルになっている印象はありますね。

特に翻訳が遅れた日本では、そういう文脈が欠けた状態でWeb業界でDDDが話題になって、「BtoCのWebアプリケーションもこれで作ればいいのかも？」となった面はあると思います。

で、コンテキストが抜けていることに、けっこうな数の人が気付いていない。
ぼくもそうでしたが、「DDDは大事、でもこれ、そのまま適用してもなんか上手くいかないね…」みたいなことは多くの人が経験したことではないかと思います。

 

和田さん：エヴァンスの本が出た2003年って、DHHというデンマークの若者がRuby on Railsを発表してWebシステムの作り方をすっかり変えてしまう事件より1年前なんですよね。
だからエヴァンスは、当然、Railsのことを知らずにあの本を書いているわけです。

それ以前といえば、Enterprise JavaBeansとかJSPとかで「戻るボタンを押すと壊れる」ようなシステムを作っていた。
Webに関する理解の深さも、整合性に対する考え方も、トラフィックに対する考え方も違っていた。

それが翻訳が出た2011年となると、もうクラウドコンピューティングが普通になり始めたころなんですよね。

トラフィックに関する考え方や、ステートの持ち方に関する考え方はもちろん、システムをエラスティックにスケールさせる云々の話も出てくる。
[Twelve-Factor App]もそろそろ出てきて、そういう考え方はすでに実感として広がっていた時代です。

 

伊藤さん：それでもエヴァンスの本はいまだに価値があって、こうやって面白い話ができる。

 

和田さん：エヴァンスの本も、技術を扱っているパートは思いっきり2003年のJavaのコードだから、そこに出てくるイディオムとかデザインパターンとかは今では時代遅れな部分もあります。
実装に関しては賞味期限切れのところも多い。

DDDの実装面は、当時からDDDのコミュニティをYahoo!のメーリングリストで追いかけていると、中には技術面に先鋭化して「アーキテクチャ宇宙飛行士」のように迷走してしまったグループもありました。

でも一方では、コミュニティの中からEvent SourcingやEventStormingみたいな多様な観点も出てくるわけです。そうしてバランスが取れるようになった。

考えてみると、エヴァンスの本より前の時代って、書いたコードもフィードバックループの源になるという考え方はもちろん、コードを書きながらフィードバックを回していくという考え方すらほとんどなかったわけです。
「アーキテクト様が図を書くから、お前らは粛々とコードを書け」という世界でした。

それに対して、この本でエヴァンスが示したユビキタス言語とかBounded Context、あるいは「そもそもみんなで設計しよう」とか「人の話を聞こう」みたいな当たり前な部分は、今でもすごく大事です。

「データをみんなでモデリングしよう」、「イベントもみんなでモデリングしよう」、「コード書きながらフィードバックを回していこう」、「コードとモデルを一致させよう」、「同じ言葉遣いにしよう」といった、コアで大事な考え方が本を通してしっかり残っているんだと思います。

 

 

編集協力：鹿野桂一郎（ラムダノート株式会社）

撮影協力：タワーズレストラン「クーカーニョ」／セルリアンタワー東急ホテル
東京都渋谷区桜丘町26-1 セルリアンタワー東急ホテル 40F