freee 技術の本 freeeにおけるマルチプロダクト開発

システムアーキテクチャ

freee 技術の本 freeeにおけるマルチプロダクト開発を読んだ。

  • 業務系SaaSだと、共通業務(申請・承認)というドメイン領域で切り出せるのか、なるほど。申請・承認といってもコンテキストが違うとワークフローが違ったり、扱うデータも当然違うと思うので、難しそう。権限や通知と比べると抽象化が難しそうな機能分割っぽさがある。基盤としては申請に関する内容は扱わないようにしているらしい。扱わないようにしているが故に各アプリケーションと密なコミュニケーションが生じてしまうという課題があるらしい。なるほどトレードオフだなぁと思った。
  • システムのリプレースをフィーチャー開発とのバランスを取ってどう進めるのかという課題には、開発制限方針を設けたという話、わかりみが深い。両方のバランスを取り続けるのは難しいし、成果の最大化もしづらいと思う。
  • サービス分割、リーアーキテクチャの成果を計測するのは大事だと思った。何を指標にするのかは基盤開発のOKRにつながる部分だと思う。技術的な指標だけでなく、ビジネス的な指標にも関連づられるように考えるのが個人的には重要だろうなと思った。基盤開発は性質上技術ドリブンになりやすいと思うが、「顧客の課題を解決すること」に焦点をおかねば基盤としての価値を最大化ができないと思うので、それを明確にすべきだと思った。
  • SaaS開発のコツ「適度な余白をつくる」「概念定義をとことんやる」「拡張性・保守性・共通化・標準化」。
    • 余白を作るは、選択肢を残すことだと感じた
    • 「うん、コーディングレベルだとそうだけど、概念レベルの場合は「ここに共通 の概念があるはずだよね」という発見は予めしておかなきゃいけない。(p.41)」
      • すごい共感した。自分はこれを抽象化と捉えている。
  • 適応度関数の事例が載っていた。適応度関数は実際現場でどういうふうに定義するんだろうと思っていたので参考になった。