「現場で役立つシステム設計の原則」☓「カイゼン・ジャーニー」対談

エンジニア界隈で話題の書籍「現場で役立つシステム設計の原則 変更を楽で安全にするオブジェクト指向の実践技法」と「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで」のコラボイベントに参加してきました。

「現場で役立つシステム設計の原則」の著者である増田 亨さん（@masuda220）と「カイゼン・ジャーニー」の市谷 聡啓さん（@papanda）、新井 剛さん（@araratakeshi）の3人による対談形式のイベントでした。

会場は高円寺にある株式会社ヴァル研究所。「カイゼン・ジャーニー」の著者である新井さんの務める会社です。

両著とも話題の著者陣による対談ということで、興味を持たれる方も多いかと思います。取り急ぎ、現地で話を伺いながらメモした内容をザッと載せておきます。

増田さんから見た「カイゼン・ジャーニー」、市谷さん・新井さんから見た「現場で役立つシステム設計の原則」

増田さん：「カイゼン・ジャーニー」の内容はわりとマイルド。現場はもっと過酷かも。チーム、ドメインモデルという切り口の違いはあるが、体験、成長させていくという点は「現場で役立つシステム設計の原則」と共通してる。

市谷さん：「現場で役立つシステム設計の原則」は増田さんの思いの入り口に過ぎない。増田さんが言いたいことの本質はさらに奥深い。一緒に仕事をしているので小言などよく聞いている（笑）

なぜ、この本を書いたか？

新井さん：市谷さんのバスに乗り込んだ感じ。自分ごととして働くというエンジニアを増やしたい。受け身だとツラいので前のめりで仕事してほしい。これをしたいあれをしたい（want）をベースに働いてほしいといった思いを伝えたい。

増田さん：技術評論社の方にツテがあって、Javaの入門書とドメイン駆動開発の間の本がありませんよね？という提案を受け、自分の考えもまとめたかったので書くことにした。春先頃に出して新人教育に良いのでは？という名目で出した。

書いてみて、どんな変化が起きたか

新井さん：書いてる最中も大変だったが、書いたあともイベント等で時間を費やしている。決して悪いことではなく、非IT業界の人とのつながりがあったり、見える化やタスク化・ふりかえりの紹介ニーズはまたまだあるという発見があった。

増田さん：言語化することで自分の考えの整理ができた。本を書く際に調べなければならないことが多いのは収穫だった（参考文献を何度も読み直したり）おもしろいフィードバックがたくさんもらえた。広がりが嬉しかった。

書籍執筆の裏側の話、執筆フロー体験・挫折体験、本を書こうと越境する人へのアドバイス

市谷さん：2014年に書籍の話が出たが中々手を付けられなかった。2017年に違う出版社から話が出たので再開したが、最初は共著者が別だった（途中で心折れてしまったとのこと）条件は厳しかったが協力できそうな人に助けを求め、新井さんに声をかけた。おかげさまで最後までいけた。

増田さん：直接の催促はなかったが、Twitter上で編集者の方からプレッシャーがあった。やめようと思っていたことは何度もあった。挫折しまくったが年初めの目標に掲げて何とかやる気になった。執筆の体験をした上で、本を書いた方が良いと感じた。自分の思ってることを書いてみるのは良いこと。最初のドラフトをエンジニア仲間にレビューしてもらった。ツッコミもきつかったが技術的なフィードバックを受けることが出来た。本としての成功とは別に、自分たちの知見を言語化するトライアルは次の一歩に繋がるのでは。

新井さん：紙のメディアとして出たこともあり、妥協しなくてよかった。考えの整理になるし、言語化するのは自分たちがやらない限り発生しない。レビューしてもらった時にいろんな意見をもらった。参考文献の日本語訳・英語のリビジョン違いなどを見ることで、サラッと読み返していたところに新たな疑問が浮かんだりした。

それぞれの本で最も言いたいことは何か？

新井さん：市谷さんと自分で言いたいことは微妙に違う。最近はワーク・シフトやベーシックインカムなど話題になっていることもあり、自分の好きなことを仕事にした方がモチベーションも上がりやすいと感じている。受け身より自分ごとの方が楽しいはず。プログラミングやエンジニアリングが好きで働き始めたはずなのに、仕事をすることがメインになってしまっている人も多い。無理に働くよりは好きに働いてほしい。エンジニアになった人は好奇心があるはずなので、学ぶことの面白さを再度思い起こしてほしい。

増田さん：開発活動のコアはプログラミング。一番のメッセージは「コード書こうよ！」良いコードを書くには良い設計が必要。設計するためには分析・ドメインの知識が必要。それらをベースにした上で良いコードを書こう。

市谷さん：変えられない物の中でも、踏める一歩はかならずある。分の悪い状況で開発しなければならないケースは多々ある。制約のある中で自分の選択肢は思っている以上にある。苦しい中でも一歩前向きに変えていくことはできる。選択肢の幅を持ってもらう存在にしたい。

どんな問題を扱うか、問題の根幹・本質を見定める方法、問題解決のアプローチ方法

チームで開発する時にコミュニケーションの問題や考えの違いがある。事実は何なのかを見えるようにしよう。無駄をなくしながらプロセスをスムーズにしていこう。メンバーやお客さん、協力会社の協力を得ながら、利用者目線で価値のあるものを提供していこう。人というところの問題をどう解決したいかにフォーカスをあてている。期待値がずれているならすり合わせのために三種の神器（書籍参照）の方法論を用いる。同じ方向を向いて力をあわせていこう。

増田さん：問題意識は明確。ごちゃごちゃ、読みにくい、変更しにくいコードをなくしていこう。リファクタリングも重要だが、そもそもきれいなコードを書こう。オブジェクト指向を重視したアプローチ。基本のアプローチは画面入出力、DBアクセスの役割やドメインロジックの表現方法。関心事を明確に分けるのが基本。コードで表現するならこうするよね？というのをビジネスの計算や判断ベースで書いている。入出力パターンはある程度決まっているが、ビジネスロジックが絡むと複雑化する。そこを明確に分けてやっていこう。

人の問題とコードの問題の違いがある。その両方が時に起こる。業務を知っている人とプログラミングを知ってる人との暗黙知を無くそう。コミュニケーションしていくことで露出させていかなければならない。プロダクトを良いものにしていくためには露出していくことが大事。

何を学ぶのか、業務の関心事とエンジニアの関心事のすりあわせ、学びのコツ、どんなジャーニーを描くか

市谷さん：当事者の人が成長していく過程を表現したかった。積み重ねを意識しないとたどり着けないところがある。そういうところを意識していくことがある意味「ジャーニー」なのでタイトルとして付けた。

増田さんと市谷さんの間で『学習パターン（慶応義塾大学SFCのプロジェクト）』良いよね。ソフトウェア開発に適用できるのでは？という話があった。

増田さん：エンジニアなんだからコードを追いかけるのは当たり前。ビジネスルールに沿った答えを追い求めるのが本当の仕事。コードを書く人間がいかに業務のことを学ぶのか、というところを目指すべき。なんのために書くの？というビジネスのことを技術的なことと同じくらい考えよう。考えながらコードを書くことでビジネスのことも覚えていく、というのが良いかと。

経験則はすごく重要なので何でも怖がらず「やってみる」ことが大事。両著ともに参考文献も充実してるので、そこから学びの広がりもあるのでは。

どのようにはじめると良いか

新井さん：ひとりでできることは多々ある。自分のタスクの見える化、分解、前工程・後工程の管理など。自分のコントロールできる範囲からスモールスタートして広げていくのが良い。例えばアジャイルをいきなり全社導入！というのは無理なので、小さな成功体験を重ねていこう。

増田さん：自分ができる小さなことを見つけてとにかく始める。挫折したりはあるが、一休みしてどこかで再開すれば良い。続けること、回数を重ねることが結果的に大きいことに繋がる。繰り返すことで蓄積になる。

市谷さん：妄想大切。まわりと合わなくなってくることもあるが、いつか合うかな？が大事。達人プログラマーを読んで「こういう人たちと仕事したいな」と妄想を膨らませた。実際に実現できたのは何年も先だったが、その間に地道なつながりや基盤づくりを練りまくることで今の結果に繋がった。

大喜利 参加者からの質疑応答

Q. DDDを行うにはプログラマとビジネスの人達との相互理解、協働が必要と思います。とはいえバックグラウンドや経験が全く違うので大きなギャップがあるのも事実です。そのギャップを埋めるために先ずは何から手を付ければ良いでしょうか？

A. コードやビジネスロジックなどに興味を持てるようにする。会計なんかも勉強したほうがいい。業務知識を学ぶための方法はいろいろある。マインドは２つ必要。ひとつは自分が興味持つこと。自分が興味なければ始まらない。二つ目。相手も人間なので必ずの正解は無い。相手をリスペクトしてないということではなく、話を聞いた上で自分で分析したり考えることが大事。業務に詳しい人に整理を要求するのではなく、自分から協力していくことが大事。

足りないと気づいた人が自分から歩み寄るのが大事。話す上で相手側の専門知識は必要。最低限相手の言葉を理解できるレベルのものが必要。そこでお互いの状況を知った上で、一緒になって必要とされるプロダクトをつくることが一番。答えのない中で知恵を出し合って仮説・検証・フィードバックを繰り返しプロダクトづくりをしていく。

業務の言葉がわからない場合、わからない部分をほったらかさない。そこを一歩踏み越えて違和感やわからなさ感、気付きに敏感になろう。仕事の上でソリューションづくりをするにはズレのセンサーを上げていくことが大事。小さな違和感を重大なことだと思ってほしい。

Q. 本を書いた後にフィードバックをうけて、アップデートされた内容とかってありますか？

A. 「カイゼンジャーニー」はKindle版や紙の第2版に少し加筆あり。コラムの名前表示など。星取表の空白のマイナスを無くしたり小さなアップデートあり。

「現場で役立つシステム設計の原則」は大きな変更は無いが、自分が表現したいこと、考えなどがもっとクリアに言語化できるようになった。

Q. 増田さんの本では型を定義してそれを使うことを推奨されていたと記憶しています。個人的には好きな方法ですがプロジェクトのORMと合わなかったりで断念することが多いので、折衷案があれば・・・

A. 過激に言えばビジネスロジックのほうが大事なのでフレームワークの方を変えるべき。modelをもう一層設ける。modelとDBは必ずわけるべき。コストも処理的なオーバーヘッドもあるが頑張りどころ。折衷案ではないかもしれないが…

Q. 妄想がまわりのメンバから離れてしまった時、合流できる時が来るまでってどう過ごしていますか？

A. 市谷さん：孤独を飼い慣らす。コミュニティを作るのも良い（例えばこのDevLoveのような）。どこまで行ってもひとりなので、ひとりと付き合ってほしい（笑）孤独なので本ばかり読んでいた。

増田さん：我が道を行っていた。増田さんも本をよく読む。発信をするというのは良いこと。2、3年たって合流しても自分はさらに先の妄想をしているので…結果的に合うことがない（笑）

Q. システム設計の原則にすべて従って開発したらクラスとテーブルの数がえらいことになると思うのだが非正規化をどうされてますか

A. 増田さん：経験則から言って、基本的にえらいことにはならない。正規化すると意外とそれなりのところに収まる。えらいことになるところまでやってみることも推奨。

Q. お三方の経験として、人の問題とコードの問題が同時に起きていて大変だったと言うことはありますか？そういうときにどういうアプローチをとって解決されたのか気になります。

A. 増田さん：若いときはコードで押し切った。体力がなくなってきたら「もっと良い仕事ないかな…」というのは思っている。

新井さん：人の問題は体力・精神を使う。疲れることもあるが軸足を変える仲間がいると良いのかな。同時に解決できるかはわからないがそういうアプローチをしている。

市谷さん：問題を変えながらずっと戦い続けている。カイゼンジャーニーの根底にあるのは開発の問題なので、良いガイドブックになるはず。手に負えない規模なら手に追えるところに戻る。自分が得意とするところに一旦戻ってやり直す。そこからどうやって一歩進めるか作戦を立てる。

増田さん：コードでも同じ。ぐちゃぐちゃのものを一気に片付けるのは難しいので、小さなところから手を付ける。一番簡単な成果が出やすいところから初めて成功体験を重ねる。

Q. DDD 真面目にやる場合、DDD に興味持ってて、いいコードを書きたいと思っている人たちが集まることが最低条件な気がする。

A. 増田さん：なかなか難しいので、できる範囲で始めるのが良い。自分がドメイン駆動設計についての話をブログに書いてみたのがいろいろな広がりを生むきっかけになった。目的はしっかりしているので、コード上だけでなくともDDDの形になる。これを最低限の条件にするとスタートできなくなっちゃう。

Q. ドメインモデルの綺麗さと、パフォーマンスとの兼ね合いが悩ましい

A. 増田さん：業務的に正しいことをやってパフォーマンスが出なかった経験はあまりない。興味があるのでぜひ現場を見せてもらいたい。

最後にまとめ

増田さん：なんでも良いのでアウトプット、アクション起こしていくと良い。そこから新しいつながりを持てるのではないか。

新井さん：今日の公演で「妄想」という言葉が出てきたが、そういう勢いで考えを膨らませて、まずは自分の中で始めていく。

市谷さん：カイゼン・ジャーニー支援の活動を始めた。できることがあればぜひ協力したい。

現場の熱意をインプット、アウトプットしていくサイクル

個人的には久方ぶりのDevLOVEイベントへの参加でした。書籍は購入していたものの残念ながら読み終えていない状態での参加となりましたが、熱意のあるお話を聞けてとても良かったです。

ここ数年は仕事が忙しかったこともあり勉強会の参加も控えめとなっていましたが、定期的に様々なアプローチの勉強会に参加してインプット&アウトプットしていくサイクルをまた作っていきたいですね。書籍の方も時間を作って読み進めていこうと思います。

2018年で10年目を迎えたDevLOVEですが、201回目の開催が6月16日に予定されています。今回対談されたお三方も登壇されるので興味のある方はぜひチェックしてみてください。