- この記事について
- ソフトウェアの状態がアウトカムに影響を与えるのか
- 品質と速度のトレードオフという観点に関して
- モジュラモノリスに向き合い始めるまでのSpirの状態
- なぜモジュラモノリスを選択することにしたのか
- モジュラモノリス化の向き合いかた
- そして現在
- We are hiring
- 諸々これまで参考にしてきた記事値など
- 他の記事
この記事について
今年半年をふりかえり、株式会社Spirのプロダクト開発で向き合い始めた、モジュラモノリス化に想いを馳せていきます。
この記事の一つ前に、プロダクトマネジメント全体に関して書かせていただきましたが、今回は記事内で触れた「Delivery」の中でとても重要になってくるソフトウェアに関して書き進めたいとおもいます。
ソフトウェアの状態がアウトカムに影響を与えるのか
モジュラモノリスの話に入る前に、そもそもアウトカムとソフトウェアの状態がどのように関係してくるのかから考えを書いていければと思います。
ここで書く「状態」は少し複雑で、現時点のソフトウェアに存在する「技術的負債」「既知・未知のバグ」や「Maintenability」「Security」などを始めとした品質に関する特性などを「状態」という言葉でまとめて意味しています。
この記事内では「状態」に関して細かく書く事は避けますが、どれだけアイデアが素晴らしくても大きすぎたり時間をかけ過ぎたりなど、顧客に届くまではまだ価値があるかないかわからない「在庫」の状態となります。更にアイデアとして素晴らしくても時間をかけた結果そのときにはハマらなかったり、顧客が求めていたものとは異なり受け入れられなかったりなど、結果アウトカムにつながらない事も起こりえると思います。そういった不確実性が高い状態だからこそ（意味ある単位で）小さく早くだして検証して育てて行くことが重要になってくると考えております。
前置きがながくなりましたが、例えばソフトウェアの状態が、Readableでは無く把握が困難だったり、Maintenabilityが低く複雑でどこに何をかけばいいかぐちゃぐちゃだったりすると、変更点を把握して、変更を実施するという１回１回のサイクルが遅くなるため、結果としてアウトカムを高めるために必要な検証サイクルを高速で回す事ができないためアウトカムを高める事に影響が大きくでてしまうと考えております。
品質と速度のトレードオフという観点に関して
ここでは少し「状態」に関しても深堀りをさせていただきます。よくSNSや様々な開発プロジェクトで見聞きする事が多い言葉として「スピードと品質のトレードオフ」があると思っています。
こちらに関しても色々書き出そうかと思いましたが、僕なんかが書くよりt_wadaさんのスライドを引用させていただくことが一番良いとおもいましたので、そちらにおまかせしようと思います。
書きたいことの殆どが、上記スライドで説明していただけておりましたので、こちらで引用とコメントだけで進めさせていただきます。
（質とスピード（2022春版）: https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition?slide=78 から引用）
（質とスピード（2022春版）: https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition?slide=39 から引用）
つまり状態をより良くしていく事が最高の品質に繋がり、最高の品質が最高のスピードを生み出し続ける。そして最高のスピードが結果として最高の品質を生み出すことにもつながると信じております。ゼロから開発する状態ではないため、時間はかかるとは思っておりますが、私達はまず短期的には品質に向き合い続ける事で、徐々に徐々にスピードを高めるサイクルを目指していく考えです。
モジュラモノリスに向き合い始めるまでのSpirの状態
- コードの責務違反、あるいは責務設計の不在
- 例に上げると「repositoryってどこから呼び出していいのか？」という悩みが発生すると実装が遅くなる
- 業務ドメインの境界がコードに現れておらず不明瞭
- 「TeamのusecaseでUserRepository呼んでいいの？」みたいな悩み
- あとは「TeamってUserとリレーションあるけど、TeamのドメインエンティティってUserのIDを持つの？実体を持つの？」など
- 組織規模が大きくなったときにマイクロサービス化という手段を取りにくい
- 技術的責任でレイヤーが分離されており異なる業務で同じコードに依存している状態
- これは技術的責任ストラクチャが原因ではないですが、前述した責務設計がうまくワークしていなかった事で課題となってきております
- そもそも設計に関しての議論が活発ではなかった
- これはSpirの組織拡大速度が一つの原因ではありますがエンジニア2名体制から半年ほどで7名に拡大した事で2名の時は無くても問題なかったことが急激に問題となって現れたということでもあります。
- テストに関しての作成コストが高い
- 技術的責任で分離されているからではないですが、依存が複雑が故に依存先の依存先までmockをつくるとかDIするとか色々書くコード量が増えていました
などなどここだけでLT登壇とかできるかもしれませんが、Spirという事業や組織が急拡大した事で、当初は問題なかったことが大きな問題として現れ始めた形です。
なぜモジュラモノリスを選択することにしたのか
そもそもSpirは表から見える業務のほか、裏側でも様々な業務が行われております。
これまではモノリスという選択でしたが、もしかしたらマイクロサービス（モノレポ・マルチレポ）という選択肢もあるかもしれません。
※厳密にはFrontend(SPA)とBackendは同じリポジトリですので、モノレポという言葉が当てはまるかもしれませんが、今回はBackendにフォーカスを当てます。
前述した課題の解決を、今のSpirの組織や文化、メンバーで向き合うには、そしてちょっと先の未来も見据えるとしたら何がいいか考えた結果、今回はモノリスのまま責務を明確にして、より業務設計に集中していける形から初めていく事から始めよう。もし（本当にもし）デプロイも分離したり分ける方が好ましい状況になったらマイクロサービス化するなど検討しましょう。今は業務を明確にしてモジュールごとに開発できる状態にする事になりました。
以下は、これらの課題に対して社内のエンジニアからモジュラモノリスの提案が上がった際の声です。
- 実装前に業務の分割が強制される
- モジュールの独立性が高まるのでそれぞれが自由に構成を変えられる（今はほぼ全部同じ構成になってるけど）
- 依存関係を可視化しやすい
- でもデプロイは一つなので楽
- モジュール境界をミスっても比較的変更しやすい
モジュラモノリス化の向き合いかた
モジュラモノリスをSpirとして考え始めたのは、2022/08/15ですので、今で4ヶ月目という所になります。
立ち上げ時期であれば最初からですので、「俺がモジュラモノリスだ」と言い切れるとおもいますが、弊社はもともとはモノリスではありますが、途中からモジュラモノリス化への移行を選択したので、まだまだ始まったばかりの状態です。
そのため弊社では以下のとおりモジュラモノリス化を進めております。
- バグやUX改善系以外の開発時（新しく向き合うMVPの機能開発時）に生み出されるコードはすべてモジュラモノリスを前提として議論・実装を行う
- 詳しくは組織編のブログで説明できればとおもいますが、モジュラモノリスを提案してくれたメンバーがプロダクト開発ではなく、Spirの開発全体がモジュラモノリス化を推進できる文化・状態を作る形でリードする役割としてコミット（社内ではDX Chapterと呼んでいます）
- 新しい開発時に業務整理やモジュール設計の議論に参加して壁打ちやリード
- 初期はドキュメントや勉強会（説明会）を通して何故モジュラモノリスなのか？などコンテキストをSyncしていく
- reactiveなイベントが無いタイミングでは、proactiveに既存のコードのモジュール化を検討して移行するなど、改善を実施
2番のDX Chapterは関しては組織としてモジュール化が当たり前になってきたタイミングで解散予定です。Chapterや現在の体制Squadに関しては改めて記事かさせていただきます。
そして現在
一つ前の向き合い方に書いたとおり、新しいところから新しく進めている事もあり、徐々にモジュールが育ち始めている状態です。また半年後などにその時点のスナップショットをお見せできればと思います。
We are hiring
Spirではこのようにプロダクトを通して顧客のアウトカムを高める続けるために、顧客課題に向き合う事はもちろんですが、より多くの顧客課題をより早く解決し続けられる土台を作ることにも積極的に投資を進めております。まだまだまだまだ本当に課題ばかりではありますが、変化を一歩一歩、時には飛躍的に起こしていければと考えておりますので、「私ならもっとこうできるよ」「私もJoinしたい」「興味はないけど話くらいはいいよ」などどんな目的でも大歓迎ですので、ぜひお話する機会をいただければと思います。Spirのプロダクトがよりアウトカムを生み続けるために力を貸してください！お待ちしております！
