こんにちは、ニーリーの佐古です。
現在プロダクト統括本部内のARCHチームというチームでテックリードとして開発速度や開発者体験の向上のため、取り組みの諸々を遂行しています。 今回はその一例を https://clas-istyle.connpass.com/event/329922/ で発表した内容をもとにご紹介できればと思います。
過渡的設計とは
プロダクトの成長の過程をざっくり書くと
- Minimum Viable Productの開発を行う
- Product Market Fitを狙う
- 業務の複雑さに対して開発がスケールする設計になる
になりますが、この2と3の間を埋めるための設計になります。 世の書籍、あるいは勉強会においてベストプラクティスとなる設計は多々示されていますが、そのベストプラクティスより(Complicatedであることを許容して)Easyな設計となります。
なぜ必要なのか
2から3の切り替えが容易でないケースというのは多々ありますし、皆さんも往々にして経験されているのではないかと思います。
切り替えで苦労する要素
1. 歴史的経緯
1から2の段階で、とりあえず商売になる最小限プロダクトを、といってもある程度この段階で複雑な仕様を表現しなければならないことはまず間違いなくあるでしょう。
その段階であまり将来のことを気にして手厚いレビューを行ったり内部品質を維持することの意味は薄く(というか、機能ならともかくプロダクト全体が売れる見込みもない時点ではやるべきではないですね。個人レベルで気を使って進められるならそれは素晴らしいことですが)、結果として早々に複雑で手を付けにくいコードベースが出来上がっていることは特段珍しいことではないです。めでたく「このプロダクトは行けそうだ」という話になった時点で「さあどうしよう」と頭を掻くことになるわけです。
2. チームの文化
サービス志向の非常に強い開発チームというのはとても素晴らしいもので、プロダクトの価値提供に関して検討を加える主体がBizサイドともう一つ存在するのは企業にとって間違いなくプラスなことです。プロダクトがバリューを生み出すまでの推進力の重要なファクターになります。
逆にテック志向のメンバーがもつそれこれのテクニックが役に立つのは後々になってというケースの方が多いわけで(特に顧客が開発者ではないタイプのプロダクトを扱うとき)、必然的にスタートアップの開発チーム組織はサービス志向に強く寄った状態になりがちです。
また、既存プロダクトと異なるパラダイムの導入を行う場合にもスキルセットの違いから学習コストが大きくなってしまう問題があります。
3. 切り替え時間の不足
はい。
それに対する解答案としての過渡的設計
このような要素が揃っているときに、無理にベストプラクティスの導入を図っても摩擦と苦労が増えるばかりで状況の改善は難しいと考えます(ストラングラーであってもなお)。
そこで、「あとでもう数段階改善する前提で、お手軽に投入できる改善としての過渡的設計」を導入しようというのが今回の取り組みになります。
過渡的設計においての意識
- 現在のコードベースとの衝突が少なく、切り替えやすいこと
- 導入コスト自体も軽いこと
- コケたらさっさとやめればよい
- ベストプラクティスの持つファクターの一部を持っていること
- いきなり全部は難しくても少しずつなら対応してもらいやすい
- 導入自体が学習コストの支払いを担える
- この後の改善を意識した設計を行うこと
例: 業務イベント基盤
業務イベントの履歴を確認したいケースというのはいくらでもあります。
多分、理想形
これを実現するベストプラクティスはイベント駆動アーキテクチャの導入だと考えられます(これが目的のアーキテクチャというわけでもないですが)。なにせすべてのイベントが管理されるわけですから。ただ、いきなり導入するのは先に述べた理由で困難なことが見えています。
とりあえず、これでいく
そこで業務的なイベントを明示的に記録する「ログ基盤」を提供しました。現在はその利用の拡大を図っているところです。 実装に当たってはなるべく簡単に導入・撤去できることを旨としています。
- 業務上のイベントを値オブジェクトとして定義し、永続化する
- 社員が権限上閲覧可能なイベントについては画面上で自由に検索できるようにする
- イベントの存在や内容を実装上で何らかの契機としては利用しない
この方法であれば既存実装との衝突なく導入が可能ですし、撤去を行う際にも何かに依存されていることがないので容易です。
今後の展望
基盤が普及したときに「これ、トリガーとして利用したいんだけど」という不満が挙がってくることを期待しています。そうなればしめたもので、メンバーにイベント駆動アーキテクチャ導入の動機が生まれたわけです。
リードとしてやるべきこと
問題に対して、ベストプラクティスを見出すことは一つの課題ではありますが、リードとしてはその先にある「どうやったらメンバーにプラクティスに乗ってもらえるか」を強く意識していきたいと考えています。
此れ即ち
則非知之難也、処知則難也。
知ることが難しいのではなく、知ったことにどう対処するかが難しいのだ。
–韓非子「処知則難」編凡説之難、在知所説之心、可以吾説当之。
およそ説くことの難しさとは、相手の心を知り、自分の説をそれに沿わせることなのだ。
–韓非子「説難」編
の心といえるでしょう。
プロダクトとベストプラクティスとの「繋いでいき」、開発チームへの「寄り添っていき」を磨いていきます。
