「〇〇に則ってないから悪い」と言うのはやめよう
※この記事は2023年1月に社内で共有したものの転載です。
最近、X-BFF（※クリーンアーキテクチャを採用したプロダクト）の成功で、クリーンアーキテクチャがLIFULL社内でめちゃめちゃ流行っている。
設計の議論が活発なのはいいことだけど、逆に「このアプリの設計がクリーンアーキテクチャに則ってないから悪い」というような言葉も見かける気がする。
こうした言質はハレーションを生むはずだし、次のようにいくつかの問題がある。
①自信過剰で新しい学びに閉じている
まず、「変更に強い設計にすること」というような大目的があるはずだが、それ以外に自分が把握していない制約条件や事情があったり、自分が把握していない別の論点がある場合もある。
現実のアプリケーション実装では、それらのトレードオフを把握し、いい感じにバランスを取って実装しなえければならない。
例えば「このアプリケーションではPresenterが変わることはまず無いから、あえて一部で層を厳密に分けなかった」という判断が下されていた可能性もあるし、例えばライブラリやMVP用の「捨てることが分かっているプロトタイプ」は議論の範疇にない。
少なくとも「なんでも厳密にクリーンアーキテクチャで設計すべきだ」という極論は明らかに間違っているはずだ。
実はなにかの事情でビジネスロジックが不必要に入り組んでいて、設計手法自体の問題より、仕様を落とす方向で議論したほうがいいこともある。
「クリーンアーキテクチャに則ってない」という主張は、他の論点を把握する必要だった場合でも、そこで議論が終わってしまう。
②相手への適切なフィードバックになっていない
また、一方的に主張することで、「クリーンアーキテクチャに則ってないから悪い」は、相手への具体的なフィードバックになっていない。
NO RULESを元に長沢さんが言っていたように、フィードバックは次のようにするといいと思う（し、これに大きな異論のある人は居ないと思う）
フィードバックを与える、受けるときのルール。前半の2つは与える側。後半2つは受ける側の意識すること。また、フィードバックは即座に与えることが大事。
* 相手を助けようとする気持ちで(AIM TO ASSIST)
* 行動変化を促す(ACTIONABLE)
* 感謝する(APPRECIATE)
* 取捨選択(ACCEPT OR DISCARD)
ここの「行動変化を促す」ためには、むしろ「〇〇に則ってない」というより、「ここは変更される可能性が高いから問題だ（だからここではクリーンアーキテクチャに則って層を分けよう）」という順に具体的な実装について話したほうがいい。
これは①の話にも通じることで、この形で議論を始めれば、「いや、このコードはこういう事情があって〜」という、自分が把握していない論点があったときに、きちんと指摘してもらえる可能性が高い。
これはコードレビューみたいな明確な場ではみんなやっていることだが、そうではない場ではできてないことが多い。
（ここには「成功するには組織の習慣を変えよう」という前提があり、実は「自分が圧倒的に得意な分野だから腕力でやっちゃう」という別ルートが存在する）
じゃあとにかく寛容で柔軟にやればいいかというと、これには別の、更に大きな問題がある。
③だからといって、何かしらの理想を持たないことは危険だ
①②の落とし穴を避けられたとしても、次にありがちなのは「個々の事情があるから仕方ないよね」といって、際限なく妥協してしまうことだ。
このスタンスに陥ると「実装期限があるから仕方ない」と考えるだけになり、長期的なシステム設計にかなり深刻な悪影響を与えるし、自分の専門性も育たない。
過去のLIFULLのシステム設計はむしろ妥協しすぎていて、長期的なアウトカムのための適切な設計をするのではなく、短期的なアウトプットのために「とりあえず出す」という志向が強かったように思う。
ここは長期的に満たすべき「理想」と、暫定的な手段としての「仮の方向性」の二段階で分けて整理するといいと思う。
- 理想: 「変更に強い設計にすること」「人がコードを見てドメイン知識を得られること」…
- 仮の方向性: 「クリーンアーキテクチャを採用すること」
本当は他のいくつかの方法もあるはずだし、将来的に別の解決策が生まれる可能性もあり、我々はその中から暫定的にクリーンアーキテクチャ（や他の設計方法）を採用しているにすぎない。
（楽観的かもしれないが、もうすぐAIが大発展して、自動生成した多少汚い実装でも人間の認知能力を越えなくて、膨大なケースのテストケースを力技で用意して、それをリリースするというやり方も可能になり、シリアスな設計の議論も不要になるかもしれない）
じゃあどうすればいいか？
すでに少し話をしてしまっているが、私は、次のような点を押さえるといいと思う。
- 「理想」と「仮の方向性」を分けて整理する
- 他人に指摘する場合は、「理想」を踏まえて、コードについて「このコードのままだと〇〇の点で問題が起こる」みたいにと具体的なケースについて設計を議論し、他の論点を洗い出せるようにする。これなら、自分と相手の両方の学びに繋げられて、win-winな関係に持ち込みやすいと思う
- 具体的なケースでは「他の論点のほうが重要だから厳密でなくてもいい」場合がある
「理想」が間違っていることは少ない（変更に強い設計のほうがいい？当たり前！）はずで、環境の変化や学習によって「仮の方向性」を修正すればいい。
この方法では、直接「理想」にダメージを受けることを回避できるので
- 心が折れづらく、やり方を工夫して柔軟に次のチャレンジに向かいやすい（伝え方を変えようとか、より手法の理解が深まったりとか）
- 理想を踏まえて、「仮の方向性」を洗練させられる可能性が残される。教条的になりづらい
というメリットもある。
これは多分、プロダクトマネジメントの「仮説のミルフィーユ」みたいなものにも通じる考え方だし、他のことで無理なく組織改善するときにも役に立つ視点だと思う（多分）。
参考文献
- 信仰と想像力の哲学 ジョン・デューイとアメリカ哲学の系譜: デューイは社会改善活動にも取り組んだ思想家で「理想」と「理想的目的（現実に合わせてその都度修正するもの）」を分けて、「どう理想を見失わずに社会改良に取り組むか」みたいな議論をしていたらしい
