アートな設計を、どう科学に寄せるか

設計をしていると、判断基準がいつのまにか「課題が解けるか」から「構造として美しいか」にすり替わっていることがあります。

責務の置き場所が揃って、依存の向きが一方向になって、美しい図が完成する。
ドキュメントを書き終えた瞬間が、そのアーキテクチャに対する満足度のピークです。

設計にはアートが入り込みます。しかもそれは、意志が弱いから起きるわけではないと思っています。
書きたいのは、それをどう科学の側に寄せるか、という話です。
例として、少し前に終えたアプリケーションのバックエンドリポジトリのアーキテクチャ再定義を使います。ディレクトリ構成はオニオンアーキテクチャを意図しているのに、依存の向きが逆転している箇所がいくつもある、という状態からのスタートでした。

理想として正しいことと、いまやるべきことは別

理想形が美しいのは、それが終点だからです。
終点には、新旧の置き場所の並存も、繋ぎのためだけのコードも存在しません。
ところが、理想系に至る途中の状態をチームは経験します。
美しさは終点にしか無いのに、コストはその途中で発生します。

なので今回、最初に決めたのは大々的なリファクタリングはやらないということでした。

たとえばユースケースにインターフェースを切るかどうかという問いですが、理屈の上では、切っておいたほうがテストしやすくなります。
ただ今の実装は、切らなくても困っていないので省略し、必要になったときに入れるとしました。

外部連携の抽象化も同じです。本来はそこが直接実装を持つべきなのに、既存サービスの形が合わないので、橋渡し役を暫定で挟んでいます。理想形からは明確に汚いので、だから TODO を残して、条件が揃ったら消すとしました。

アートに寄っている設計は、理想としては正しいのに、いま誰の課題も解いていない。
だいたいこの顔をしていると思っています。

設計は、科学になりたくてもなりきれない

では科学であるべきかというと、そう書くだけでは当たり前の話で終わります。もう少し踏み込むと、設計は科学になりたくても、なりきれない構造を持っています。

科学の条件は、仮説を立て、検証し、間違っていたら棄却できることです。設計でも仮説は立てられます。ただ、効果が出るのは半年後、一年後で、同じプロダクトを二度は作れないので比較実験もできない。そのころには書いた本人がいないことも多い。つまり、検証サイクルが人とチームの変遷より遅いこともあります。

構想段階のドキュメントには、開発速度が何割上がるとか、新人が戦力になるまでの期間が縮むとか、目標値を並べた表を書くと思います。
書いてから半年ほど経ち、一部では効果が出ていますが、真の意味であれが正しかったと言える日は来ないでしょう。

一方で、美しさは書いた瞬間に返ってきます。この時間差が罠で、検証できない空白を、即時に手触りのある美意識が埋めてしまう。アートに寄るのは、この空白がある限り自然に起きることだと思っています。

寄せられるのは、理想形そのものではなく周辺

だとすると、打ち手は理想形の精度を上げることではありません。判断が人に依存しない状態をどう作るか、のほうです。今回やったのは4つでした。

判断を一本のルールに落とす。 個別に悩む回数を減らすほど、判断はぶれなくなります。今回は、いつ・何を通知するかはドメインの知識、どう送るかは技術の詳細、と切りました。メール送信もキュー投入も、この一本で置き場所が決まります。

好みが入り込む余地を潰す。 規約に書いていないことは、レビューで美意識の勝負になります。今回はパッケージの命名、import の別名、ファイルを分割する目安まで書きました。地味ですが、「こっちのほうが綺麗じゃないですか」という議論は、だいたい元の課題の話をしていません。

作らないことを、わざわざ明文化する。 理想形を描くと一式そろえたくなるので、歯止めを文章にしておきます。今回はポートの整理方針に「各領域が実際に必要とするものだけ定義する。不要なものは作らない」と書き足しました。

手本を先に一つ仕上げる。 文章より、動いているコードのほうが正確に伝わります。今回はある集約だけ先に完成させ、あわせて移行手順を番号付きで書きました。何を新規作成し、どこの参照を切り替え、最後に旧ファイルを消すか。各段階でビルドとテストが通ること、まで含めて。

どれも、聞いている問いは同じです。

この判断は、自分がいない場所でも再現されるか

科学かどうかを分けるのは美しさではなく再現性なので、ここだけがその場で判定できます。あとから機能を足す人が、自分に聞かずに判断できるか。できないなら、その理想形はまだ自分の頭の中にしかありません。それは設計ではなく作品です。

おわりに

美しさに反応できる感覚自体は、大事な武器だと思っています。ダメな構造に気持ち悪さを感じられるのは才能です。ただ、それを判断基準に昇格させた瞬間におかしくなります。

そして、答え合わせが中長期の領域で強くなれるかは、検証できない空白をどれだけ小さくできるかで決まるのかと思います。設計に限らず、組織づくりも開発プロセスも、たぶん同じ構造です。

みなさんが去年いちばん綺麗に書いた設計は、いま誰かに引き継がれていますか。