ネットの海の片隅で

技術ネタの放流、あるいは不法投棄。

モデリングについて

モデリング 戯言

カフェで設計を考えていたらいろいろ思うところがあったので、カフェでのツイートを中心にしつつ自分向けにまとめてみる。

モデリングとは

ここで言うモデリングは「人間の営みをコンピュータで実装するために分割して名前をつける行為」くらいの意味を意図している。 また、普段書いているのが Web アプリケーションなので、その前提を含んでいる。

人間の営みを理解するためには分析や対話を通じて概念を見出していく必要がある。

そして、実装するためにはだいたいロジックとデータが必要なんだけど、良い振る舞いをするモデルを得るためにはどちらかに偏ることなく総合的に考える必要があると思っている。 プログラムにはプログラムの、データベースにはデータベースの都合があるが、どちらかに寄せてしまうともう一方の表現力がなくなったり得意なことが活かせなくなったりしてしまう。

これ自体は前から意識していたことだが、自分で思っているよりも遥かに頻繁に意識の切り替えを行なっていたことに気付いた。

良いモデリングをするためには概念を発見する力を磨くとともに、プログラムとデータベースの両方に対する知見を深めていく必要がある*1。

モデリングの難しさと個人的な感覚

上の定義では「分割して名前をつけるだけ」のモデリングだが、個人的にはかなり難しいことだと思っている。

半ば冗談でよく言っているのだけど、これは人間が高性能すぎるのが悪い。

だから、直感に基いてモデリングすると、実は分割が足りなかったみたいなことがよく発生する*2。

もちろん、初めからより良いモデルに到れれば良いんだけど、神ならざる身である我々が完璧なモデルをつくれるわけはないのでモデルを修正する必要が生じること自体は問題じゃない。 むしろ、現在のモデルが現実をうまく扱えないときはより良いモデルに至るチャンス。

こういった「初めから100%は無理」「少しずつ良くしていく」というような心境があって「ドメインを掘る」「モデルを磨く」といった語法を使うことが多い。

さらにポエミーなツイートを引用しておくと、こんな感じ。

モデリングの重要性

こんなにも難しいモデリングだが、モデリングを頑張ると何がうれしいのか。 大きく3つあると思っている。

ドメインに対する理解

モデルを考えていく過程でドメインを掘っていく必要がある。 この営みはだいたい「◯◯とは？」のような問いを通して概念を明確にしていく作業になるので、結果としてドメインに対する明確な理解が得られるようになる。

堅牢さと柔軟性

残る2つ、堅牢さと柔軟性は相反するように見えて相関しているのではないかという仮説が浮かんだのでまとめて書く。

明確に認識された概念に基づいたモデルは「それが何であるか」が非常に明瞭になっている。

そのため、各モデルに対してしっかりとした制約を課すことができるし、仕様変更や認識のアップデートが発生した場合にもどの箇所にどういった変更を加えるかが明白になる。

一方、適切に分割されていない貧弱なモデルを元に実装すると、柔軟性を確保するためにデータをゆるく持つことで対処する必要が生じてデータのカタさが失われるし、分割されていないモデルに対してロジックを追加していくと神モデル的な何かが生まれたりする。

難しさを伝える難しさ

ここまでいろいろと書いてきたモデリングだが、その難しさを人に伝えるのも難しいと思っている。

貧弱なモデルを元に実装してもとりあえずのところは動くし、生産性の測定などをするにしても生産性の測定自体が難しいのに生産性に対するモデルの影響となるともっと難しいので、価値を示しにくい。

また、仕事で行なったモデリングは大半の場合において公開できないだろうし、モデルはドメインがあって初めて存在するので単体で OSS にするなどは難しそうなので、外部から観測することも難しい。

このあたりはなんとかしていかないといけないと思っている。

おわりに

コーヒー代830円の代わりに得たいろいろな気付きや思いをつらつらと書いてみた。

難しく大変な領域だと思うが、昔から好きな領域なので今後も引き続きやっていきたいと思う。

*1:ここではよく使う RDB を挙げてツイートしているが、他のデータストアももちろん考慮する必要がある。

*2:逆の「別だと思っていたことが実は同じだった」もあるけど、相対的に少ない。

『ベタープログラマ』を読みました。

技術書

この本です。

前から気になってたので年末年始の休みを利用して読んでみました。

感想

端的に言ってしまうと、あまりオススメしません。

訳がしんどい

原文を読んだわけではないので、本当に訳が良くないのか、そもそもの文章が良くないのかはわからないんですが、結果だけ見れば文章が非常に読みにくい。

日本語としてかなり不自然な文章が結構な頻度で出てくるので、読書中の集中を持っていかれるという点で厳しいし、そんな訳を見ていると原著の文意がちゃんと訳されているんのか不安になる。

具体性が薄い

目次を見た時点ではかなり期待していたんですが、実際に読んでみると内容がそれほど深くなくて説得力があまりない。

代わりに読んだほうば良さそうな本

総ページ数や金額としてはペターブログラマ1冊より多く/高くなってしまいますが、以下のような本を読んだほうが得るものは圧倒的に多そう。

達人プログラマー

ちょっと古いですが、いわずと知れた名著だけあってやっぱり良い内容。

具体的なプラクティスやそれを支える考え方みたいなものを紹介してくれているのでそのあたりの深さというか具体性もあって良い。

情熱プログラマー

エモ担当の本。 プログラマとしてどう行きていくべきかみたいなところはこの本のほうが良いと思う*1。

Teem Geek

人付き合い部門。

『ベタープログラマ』では人間関係とかコミュニケーションについても触れられているんだけど、そのあたりの基本的な心構えは『Team Geek』が良いと思っている。

コード部門

『ベタープログラマ』第1章ではコードの書き方について触れているんだけど、コードの書き方なら『オブジェクト指向設計実践ガイド』かなーと*2。

あとはベタだけど、『リーダブルコード』とかも良いんじゃないかな。

おわりに

先述したように、訳が気になってしまったのもあってあまり集中して読めていないかもしれないので、『ベタープログラマは良い本だぞー！』という意見があったらぜひ聞きたいです。

*1:わりと合う合わないはありそうな気がするけど。

*2:Ruby （とダックタイピング）を前提にしているので他の言語の人には合わないかもしれない。わからん。

2017年振り返り

日記 戯言

去年に引き続き、簡単に今年を振り返ってみます。 （帰省する電車の中で書くのが恒例になりつつある）

去年は時系列で書いたけど、今年はトピックごとに書いてみる。

いろんな場所に行った

首都圏を除くとこんな感じ。

いつ どこに なぜ
5月 名古屋 友人の結婚式
石川 プロデューサー業
6月 大阪 プロデューサー業
静岡 プロデューサー業
7月 松江 開発合宿
9月 広島 RubyKaigi 2017
博多 旅行
10月 石川・岐阜 旅行
11月 ラスベガス re:Invent 2017

わりと出不精なので1年間でこんなにいろんな場所に行ったのは初めて。

ライブで遠征したついでに観光するのが非常に良い体験だったので、今後も機会があれば（財布とご相談の上で）やっていきたい。

ライブ行きまくった

いろんな場所に行ったというのと多少かぶるけど、LV 含めてめちゃくちゃライブに行った。

いつ どこ 一言だけ
1月 プロミ @現地 765PRO AS 揃って最高（いつか + で）。
2月 SideM 2nd @LV 1日目だけしか行けなかったけど315だった。
3月 ミリオン 4th @LV 全日 LV だけど本当に良かった。たねちゃんゆっくり待ってる。
台湾 @LV ステージのミンゴスは本当に輝いてるなー！（パンダの人も）
5月 シンデレラ 5th 宮城 @LV ちぇりめりがかわいすぎて死んだんだけど、何よりも座長（感謝しかない）
シンデレラ5th 石川 @LV/現地 2日目だけ現地行けた。多田李衣菜担当として最高だったとしか言えないんだけど、私色ギフトで泣いた。
6月 シンデレラ 5th 大阪 @現地/欠席 大空師匠とかも良かったんだけど、やっぱり個人的にはさっつん。あと、今井麻夏さん。
シンデレラ 5th 静岡 @現地 ありがとう青木一族。あと、あっさむの尊さよ……。
7月 シンデレラ 5th 幕張 @欠席/LV るるるるるるるるるる。るる、真ん中、尊い。めちゃくちゃ立派なセンターだったよ！
シンデレラ 5th 福岡 @LV 松井恵理子のパフォーマンスよ……。2nd SIDE もそうだけど、ライブで聴いて印象がガラッと変わる。
8月 シンデレラ 5th SSA @現地 「全員揃う」という暴力。ありがとう。KMMD 良すぎ。赤崎さんのダッシュで泣いた。他にもいろいろあるけど余白が足りない。
9月 ミリオン MEG@TON VOICE！ @中継 新しい2人。すごい人たちが来た。
10月 765 MILLION Hotch Potch @現地 良すぎてだいたい発狂してた。BD はよ。

ライブ行くたびに語彙がなくなって「最高」とかしか言ってないけど、本当に最高なのでこれからも行きます。

年明けすぐの初星宴舞も両日現地なので楽しみ。

世の中に出た

ちょっとだけ真面目なことも。

Cookpad TechConf 2017 で喋ったり、omotesando.rb に行って喋ったりした。

いろんなところで喋ろうとするというのはわりと大事だと思っていて、

  • 自分の存在を示す
  • 喋るに足ることを普段からやる

という2つがあると思っている。

特にふたつめが重要で、Web アプリケーションを書く仕事をしていると、ともすれば「ただ Rails を書いてるだけ」みたいなことになりかねないので、そうならないように技術的だったりサービス的に意味があることをやっていかないといけない。

覚悟が必要

この1年、仕事をしていく中で自分でやれることとか任せてもらえることがグッと増えた。

嬉しいし好ましいことなんだけど、それにともなって何かを決めるというシーンが増えた。

限られた時間の中で、諸々の事情を考慮しつつ最善と考えられる選択をしないといけないんだけど、どこまで行っても「最善と考えられる」であって「最善である」にはならないので、どこかで腹を括ってエイヤとやる必要がある。

当然、決断をしたらそれが間違っている可能性もあるが、決断しないのは100%間違っているので失敗を恐れずに（あるいは失敗を恐れつつも）やっていかないといけない。

去年は「挑戦と失敗が足りない」みたいなまとめをしてた気がするけど、今年も似たような感じになった。

おわりに

今年1年間ありがとうございました。