Modelessnessと現実

ふとオブジェクト指向について調べ直して、User IllusionやModelessness、OOUIと考えを巡らせた。
その中で雑多に頭に浮かんだことを書き連ねる。

頻発される『モデル』という単語一つとっても、メンタルモデル、ドメインモデル、データモデルなど、あらゆる補助線の引き方がある。
日頃の開発における『モデリング』も同様の複雑性を含んだものである。

しかし一方で、現実のモデリングはそうした学術的な空中戦のすごく手前側にあることが多い。

たとえばドメイン駆動設計をしている現場で、ドメインモデルとデータモデルが区別されている現場を少なくとも自分は見たことがない。データモデルがまずあり、それと同名のドメインモデルをただ単に定義するような開発スタイルばかりだった。DIPでわざわざインフラ層の依存を切っているにもかかわらず、本質的にインフラ層ありきなのだ。

またユーザのメンタルモデルを考える以前に、チーム内でメンタルモデルが揃ってないことも多い。他職種と揃ってないどころか、フロントエンドとバックエンドで揃ってないことすら多々ある。バックエンドがOrganizationと呼ぶものをフロントエンドではCompanyと呼んでいたりする。そして実態はOrganizationでもCompanyでもなくTenantだったりする。

そうしたすごく手前の世界で、どこまで『正しいモデリング』を追求するべきなのだろうか。もちろん個人の仕事として妥協するべきではないが、それをチームで追い求めすぎることは不毛だ。少なくとも全員が正しいモデリングができることを前提にした構造は良くないだろう。

ゼロイチの設計において、やはり誰もが『綺麗な設計』をしたがるものだ。しかしその人の手が離れるにつれ、根幹的な思想の部分を共有できる人はいなくなり、混沌とした世界が待っている。

結局のところ現実で大事なのは『すごく初歩的な部分の崩壊』を防ぐ手法であり、何も考えなくてもそこまでおかしくならない世界こそが中長期的には成功する。
シニアエンジニアでも実装に迷うような環境より、１年目の新卒でも問題ないコードを書けるような環境のほうが、結果的に良いコードになっているのだ。

個人としてはこうした勉強は好きで実践した結果どういう世界が待っているのかは気になるが、ビジネスの成功を目的に置いたときに重要なのはもっと手前側の課題解決能力なのだ。

Modelessness

ふわっとしたことしか書いてなかったのでModelessnessについて今の考えを書いておく。

Modelessnessを意識すると１画面に情報を収める必要性が出てきて、情報を整理する技術が必要となる。またフロントエンドの実装としても、１ページの責務が増え煩雑になりやすい。

もちろんそれらを適切にハンドリングできる現場であれば、それに越したことはないだろう。一方で『ふつうの現場』において『Modelessness』という言葉だけ一人歩きしたときに危険だと感じる。画面内は雑多に情報やボタンに溢れ、コードとしても煩雑になり変更可能性が落ちる未来が見える。
UI設計もページごとに適切に行われる必要があり、UXがページによって変わってくることも予想される。

一方Modalであれば割と思考停止で作っても崩壊しづらい。「一覧」「詳細」に分かれて下部のボタンで可能なアクションを表現する、という大部分を共有可能なインターフェースで統一できる。特にベンチャーにおいては下手に個別最適化するより少ないコストで開発でき、かつUI・UXが崩壊しづらいこうしたアプローチの方が良いだろうと思う。