増田亨さんによる「設計の考え方とやり方」勉強会書き起こし5ページ目です。最初からお読み頂く場合は、こちらから御覧ください。

資料

書き起こしリンク

質疑応答

質疑応答は参加者の皆様でモデルにしました。こちらを是非御覧ください。

質疑応答

安西：ありがとうございました。ではせっかくなので、質疑応答の時間にしたいと思います。けっこう質問が集まっております。イミュータブルデータモデルに関する話題がけっこう人気があったんですけど。

イミュータブルテーブルについて

増田：イミュータブルデータモデルについては、当たり前だけど私のオリジナルじゃなくて、日本だと川島さんという方が専門なんです。川島さんが多分DB PRESSの9月号、8月の下旬に発売されるものに記事を書かれているんで、それをまず参考にしていただきたいなと思います。

質問：DBの容量は？

増田：DBの容量という話は最近よく出てくるんですけど、最近はもう心配ないです。皆さんがとんでもないデータ量を使っていらっしゃるんだったらそれは別途考えてほしいんだけど、昔の業務アプリケーションの感覚で言うと、クラウドのおかげでデータ量は本当に気にしていなくて。ディスク容量なんてタダみたいなものですから、今は。データ量が増えた時も小さなテーブルでインデックスが効いているとほぼ問題がないです。

質問：ミュータブルは常に悪でしょうか？使い分けることはありますか？

増田：ミュータブルなデータモデルにすることは私はないです。ただ、性能が出ない時にキャッシュ的な意味合いで最新のレコードだけ書いておくというようなことはやっています。でもそれはデリートしてインサートしているんで、アップデートはしてないんです。

当たり前ですけど、皆さん自分で咀嚼するために質問していただいていると思います。私は私の考え方を言っているだけですからね。経験的にはそうしていますと。さっきのデータ容量もそうです。論理的にデータ量多くなるよねとかそういう議論をしているのではなくて、私自身がやってみてデータ量が気になったことはないですね、という話を参考情報として伝えているだけです。

質問：gitもミュータブルだなと思いました。

増田：gitもイミュータブルですね。git、データ量なんて気にせずにガンガンやってるよね。

「とっとと作る」について

安西：勉強方法、「とっとと作る」というところも人気がありますね。とっとと作る順序とか、設計の精度。これらについて何かありますか？

質問：とっとと作る場合どういった順序で作り始めますか？仕様が動かなそうな詳細からでしょうか？

増田：作る順番というのはさっきお見せした通り、ドメインモデルが中心で、ドメインモデルの中でもここはけっこう重要になるだろうとか、ここは複雑になりそうだというところに当たりをつけながらやっていきます。百発百中じゃないけど、逆に大外しもしないんで、そういうところから作っていく感じです。逆に、とっととどこから作るかということの判断とか、「何が重要なんだっけ？」とか「何が依存の大元、基礎の方になりそうなんだっけ？」「依存される側になりそうなんだっけ？」みたいなチームでの認識合わせをすること、作る順番についてみんなで意見を出し合うみたいなこと自体が価値があるかなという感じですね。原則は複雑になりそうなところとか、重要だと思われるところに手をつけてみる。

質問：設計の精度と「とっとと作る」のバランスが知りたいです。

増田：そういう意味では設計のスキルを磨きながらとっとと作るということですね。パターンを覚えたりとか、リファクタリングでこういうやり方よりこういうふうになっていた方がわかりやすいな、とか、こうすればつまらないバグ入らないよな、というようなことを地味に身につけながら、とっとと作るようにしていく。とっとと作るイコール設計をないがしろにして、ということじゃなくて、設計スキルを上げながらとっとと作るというのをやっていくという感じですね。

開発組織、開発チームについて

安西：まさに学びながらやっていくという感じなんですね。ほかに、組織の話も人気がありますね。

質問：このような考え方をチームに伝播させていくのに意識していることはありますか？

増田：私の経験談はあまり参考にならない。僕は上司を納得させられたことはないですね。好き勝手やって、上司がそれを許容できるかできないか勝負をかけて、上司が許容できなかったら会社辞めてるから。でも自分がいいと思うことじゃないとエネルギーが出ないでしょう。

質問：チーム開発の場合はある程度仕様の認識を合わせて行うのがよい？

チームメンバーの話は、実際に私がお手伝いしているところではどこでも必ず出てくる問題です。チームメンバーの大半がこの考え方が必要というのは、もちろんゴールとしてはそうです。ただスタート地点ではそういうことはあり得ないんで、まず何をするかというと認識合わせですよね。うまくいったパターンで言うと、その時に「変更が楽で安全でないとやってられないよね」みたいな、そういう共通の目標意識というか方向性を持てたチームは、反対意見に対していろいろ議論していってもそんなにはぶれない。トランザクションスクリプト方式とドメインモデル方式はどっちがいいかと議論してもしょうがないんで、「変更を楽に安全にするにはこういうのがいいよね」とか、「こういうのが変更が凄く大変だよね」というような認識が合ってくると、それに対してどうするんだといった時の考え方はそんなにはぶれない。逆に今までの作り方だと変更がやっかいで危険だからそこをなんとかしなきゃいけないということが、そこの意識が合ってないとちょっと厳しいですね。技術論では共感が取れないですね、これは。

正直いってうまくいったプロジェクトもあれば、全然浸透しないプロジェクトもあって、浸透しているチーム、割と広がっていってるプロジェクトは「こんなシステムじゃ俺ら仕事やってられない」というような所ばかりですね。ねえ安西さん。安西さんが私を呼んでくれた理由はそこでしょう？そこから脱却したかったというのが唯一最大の理由ですよね。

安西：本当にそういう課題感というか、想いベースで始まっていますから。

リファクタリング、テストについて

安西：あと人気があるのは、リファクタリングについて、テストについてです。

質問：テストはどれぐらい書きますか？

増田：テストはサービスクラスをデータベースとか通信とかを連携して、end to endのendって言ってもユーザーのendっていう意味じゃないんですけど、サービスクラスの機能が一式ちゃんと動くというものに対するテストは書くというのが基本方針です。

逆に言うとそれ以外は書かない。ドメインモデルは原則私は書かない。今まで書いた経験があるのは、他通貨の換算ロジックを小数点以下8桁までの精度でやれというのがあって、それはさすがに設計だけじゃ担保できないんでコードを書きました。あとは状態遷移の複合のところは最初はテストコードを書いていたのだけど、結局区分をリファクタリングして区分がスッキリしたら条件の組み合わせが非常に単純明快になったので、テストの方を消しました。構造的にそこは担保できてるはずだったんで。もちろん機能として状態が変わるテストはend to endで機能テストとしては担保してあるんで、ドメイン側で単独で状態遷移が判断ロジックをテストするというのも消しました。

要するに型を使って契約プログラミングを徹底できると、ドメインモデルについてはテストより設計で品質担保するということに時間を使った方がいいんじゃないのかと私は思います。これはドメインモデルの話です。アプリケーション全体としてテストを書かなくていいということを言っているつもりではないです。

安西：ありがとうございます。あとは何か答えやすい質問、答えた方が良さそうな質問とかありますか。

質問：リファクタリングする際にはすべてテストコードを書くのでしょうか？

増田：基本的には、さっきもちょっと言いましたけど、タイポとか、体裁を整える感じです。「改行がちょっとずれているな」に近いような感じでやるレベルのリファクタリングというのは相当やっていますね。

これは正直言うとリファクタリングという感覚じゃないです。名前の変更とか、サブパッケージを作るとかいうのは、ウンウン唸るよりはとりあえず、クラス数が多くなってきたらパッケージ突っ込んでみるか、みたいなことをちょっとやって、駄目だったらまた消して元に戻すとか。そういうのは凄く簡単にできるようになったんで。まずはやってみるという感じですね。

相当大きなリファクタリングもとりあえずやってみる感じですね。50ファイルくらいに影響出ちゃったようなやつでも、とりあえずやってみて、IDが文句言わなかったから、コンパイラーとIDが文句言わなかったからまあいいか、みたいな。

こんな時はどうすれば

安西：時間が過ぎちゃっているんですけど、最後もう一個ぐらいいきましょうか。こんな時どうすれば、という話と、勉強方法について。

質問：継承地獄で苦労しているのですが、何か処方箋はありますでしょうか？

増田：継承地獄、僕は使わない主義なんで使うなとしか言えない。リファクタリング何かあったよね、継承階層を薄くしていくみたいな。継承はやめたほうがいいです。

私が継承にぶち当たった時の経験則としては、昔やっていたのは、やっぱり継承よりコンポジションにするということですね。スーパークラスが持っているクラスを、継承元ではなくてオブジェクトとしてまず部品を作って、そのオブジェクトを使うような形にする。スーパークラスがロジックを持っていて、サブクラスがそれを使うんじゃなくて、サブクラスに当たっていたクラスが一番のメインのクラスになって、それがスーパークラスが持っていたようなロジックを持つ部品オブジェクトを使うみたいな、いわゆる継承よりコンポジションということを地道にやるという感じですかね。

質問：今の現場がアジャイルでトランザクション方式を使用していますがおかしいですか？

増田：これは私の個人の意見を求められているんだったら、おかしいと思いますとしか言いようがないんです。でももうちょっと言わせていただくと、正直言って興味がある。作り逃げができるんだったらそれもありなのかなと思うけど、メンテナンスがどうなるのかなという。アジャイルでトランザクション方式でやっていく時に、インクリメンタルなやり方というのはできないかな、という感じがしますけど。

勉強方法について

安西：勉強について、何かありますか。

質問：設計スキルを上げるための練習問題的なものはあったりしませんか？

増田：これは一般論じゃないんですけど、私自身は現場と、いわゆる設計手法的な本との間で行ったり来たりして、練習のためとか勉強のための問題集というのはやったことがないんです。現場主義なんで。私が紹介できるような練習問題はないですね。イベントなんかでやったのは、新幹線の料金モデルとか、かとじゅんさんがやっていた割り勘モデルとか。

ドメイン駆動設計のワークショップやったところでよく使っていたのは、ホテルの季節料金とか子供料金とか、団体割引とかというような計算をしたりとか、駐車場の料金で1時間いくらで最大何時間で2日目以降は繰り越すみたいなものがあります。ルールを見つけてクラスをやってみるというのは、イベント的な意味ではやっていましたね、ワークショップ的には。

質問：技術書は月何冊読みますか？

増田：僕は冊数としてはそんなに読んでないかな。同じ本を何度も読む。たとえばエヴァンス本。全部読むわけじゃないけど。

安西：ぜひ3冊ぐらい、増田さんがこれを読むべし、みたいなものを教えていただけると。

増田：それはその人の勉強とか状態にもよるから。そういう意味では私の本に挙げてある参考文献は今でもおすすめです。そこでは書いてなかったんだけど、最近出た佐藤正美さんのデータモデリングの本「事業分析・データ設計のためのモデル作成技術入門」はちょうど今読んでいます。テイストが人によっては合わないかもしれないけど、私自身には参考になっています。

質問：名前付けのボキャブラリーの増やし方

安西：増田さんは文学部でしたよね。そこから違うなといつも思っているんですけど。

増田：名前付けのボキャブラリーの増やし方というのは二つあって、一つはやっぱり読むことですよね。割とおすすめなのは利用規約とか、製品カタログとか、商品について説明したもの。あるいは製品の購入の仕方について説明したものというのはビジネスルールの宝庫なんで、そういうものを読むと、日本語でどう言っているのかということに関しては相当ボキャブラリーが増えてきます。

英語に関しては、一つは日英の対訳みたいなもの。業務分野大手に、たとえば物流辞典の英語版みたいなものがあったりするんで、そういうものを使うとか。あるいは私がECサイトばかり作っていた頃は、Amazonのオンラインのヘルプとかマニュアルを徹底的に読みましたね。出荷とデリバリーというのは意味が全然違うんだ、とか。

あとは半分以上趣味になりますけど、類義語辞典と語源辞典は私の友です。

安西：持っているんですね、昔から。

増田：昔も持ってたし、今は非常にいい情報がオンラインであるから。たとえばDictionary.comのThesaurusなんていうのは愛用しています。 iPhoneには日英漢、15〜6種類は辞書を持っています。

安西：つまり学ぶ要素は身の回りにいくらでもあるということですね。

増田：こんな言い回しなんだとか、こんな言葉があるんだということにアンテナを立てれば、ネタは格安で転がっているんで。使わないほうがいいのは日英辞典ですね。英英辞典とか類義語辞典はどっちにしようかなという意味で、意味としていい名前を見つけられるけれど、だいたい日英辞典って嘘が書いてあるから、本来の英語の意味と違う訳語がついていたりするから。

質問：日本語をそのまま使うのが好きなのですが嫌われがち。どうなのだろう？

安西：増田さんはけっこうそのまま書かれていますよね。

増田：変数名とメソッド名は日本語を使うようにしています。逆に型名とパッケージ名は英語を使うようにしています。

安西：その使い分けはどういう意図なんですか？

増田：オブジェクトモデルは日本語で、クラスモデルは英語。クラス宣言は英語を使って、そのクラスがオブジェクトとして変数名として参照する時には日本語を使う。そういうコードの書き方をすると、いい感じで濃淡がつくんですね。やっぱり英語より日本語のほうがパッと目に付くじゃないですか。ソースコード自体は静的なクラス定義なんだけど、オブジェクトが生まれてオブジェクトをどう使っているかというオブジェクトモデルが日本語としてソースコードから読み取れる、と私はしています。

某社で型名に日本語を使っていらっしゃるところがあるんですけど、個人的にはないと思っています。混在のほうが、ハイブリッドのほうがいい感じだと思っています。

安西：ありがとうございます。