受託開発の現場でモノリシックシステムを適切なサービス単位に分割するための戦略
はじめに
タイトルではモノリスであることがあたかも悪であるかのように書いていますが、アーキテクチャの良し悪しは、ビジネスや現場の特性に依存すると考えています
つまりモノリシックアーキテクチャも、ビジネス判断や状況によっては悪い選択肢ではないというスタンスです
この記事では、当人たちが望まない形でモノリスになってしまったシステムをどう改修するか、をテーマとしています
記事は受注側（開発ベンダー側）目線で書いており、技術要素よりも文化要素を重点的に記載しています
そもそも何故モノリスになっていくのか
一般的に、受託開発は、自社開発の場合に比べて、アーキテクチャの劣化が進みやすい環境です
理由は何点か上げられます
まず一つに高いリファクタリングのハードルがあります
発注者の中でリファクタリングがそもそも視野にないことが多い
発注者に直接的な便益が発生しないため、リファクタリングの予算・決済がおりない
受注者（開発者）がビジネス現場の温度感が理解できず、リファクタリングするべきタイミングが想像できない
機能の今後の成長方針が分からないため、リファクタリングするべきか放置でもいいのか判断できない
アーキテクチャの変更に伴う業務影響説明のコストが大きい（そして、心理的に１つでもデメリットがあれば、１０のメリットがあっても通らないことがある）
さらに、劣化を加速させる要因もあります
増えることはあっても減らない機能達
システムの発注部署が全ての仕様を決めているのであればまだ救いはありますが、多くの場合はそうではありません
大抵、システム発注部門の奥にはビジネス部門が存在し、発注部門とビジネス部門の間で、時には政治的なバランスを取りながら作る機能を決めています。例えば、システム化を実現することで評価につながるような制度がある場合、本当に必要性が疑われる機能であったとしても、新しく機能を作ろうという判断が下されやすいです。逆に、減らすことで評価につながるような制度は中々無いでしよう
このような背景から、だんだんとシステムは肥大化し、比例してチームも巨大化していきます
デプロイは困難になり、デプロイ頻度は下がり、失敗率も上昇していきます
デプロイに失敗した際のロールバック判断も行えず、システムが停止したまま長時間が経過してしまうようなことも起きます
テスト環境へのデプロイ段階ですら緻密な情報共有が必要となり、機敏な開発はどんどん難しくなっていきます
構成管理も至難の業となり、構成管理だけを専門で実施していかないと回らなくなっていきます
これらの問題を解決していくために、確かにアーキテクチャは重要ですが、その根本にある組織の問題に目を向けないことには、状況は好転しないでしょう
まず、現実の組織の問題に目を向ける必要があります
理想を考える
基本的にシステムはユーザありきです
個人開発ならまだしも、事業会社、開発ベンダーが協力してシステム開発をする目的は、システムによってビジネス成果を得たいからに他なりません
理想的なアーキテクチャや組織文化とは、「ほしい時にほしい機能を入手できる」ことを実現できるものであると言えます
メンテナンスに忙殺されることもなく、肝心の開発以外のコミュニケーションコストに忙殺されることもなく、本来のビジネス成果にフォーカスを当てた仕事ができること。言い換えると、ビジネス的なアジリティを確保できること
それがアーキテクチャの良し悪しを判断する軸になります
ではどうすれば
基本的なマインドは、可能な限りビジネスとITの距離感を縮めていく、ことです
発注⇔受注という構造的な特性はあるものの、ビジネスを考える人とＩＴを考える人を明確に分離してしまうと、上記のような問題につながり、結果的にビジネス損失になっていきます
システムの目的はビジネス成果の獲得であるので、理想としては、全員がビジネス意識をした上でシステムを利用できる状態を目指しましょう
段階としては次のようなイメージです
信頼貯金を貯める
密なコミュニケーションに基づいた価値ある組織改善は、お互いの信頼を燃料にして駆動します
信頼関係がない状態でいきなり発注者に改善提案を持って行ったところで、相手にされることはないでしょう（むしろ怒られるかも）。最初から体制や仕事の仕方を劇的に変えるのではなく、今のチーム状況・アーキテクチャでまずは最大限の成果を出せるようにしましょう
それには、チームとして成長していく必要があります。アジャイルには「ふりかえり」や「チームビルディング」という改善を進めていくためのプラクティスが重要視されていますが、そのマインドを取り入れましょう
今のチームをもっと良くするためにはどうすればいいか？もっと高い成果を出せるためには何をすればいいか？ を考えて、成果を向上させるところから始めましょう
過去の自分達と比べて相対的に向上できればいいのです。成果が良くなれば、信頼も生めるはずですドメイン知識（業務知識）を獲得しにいく
最良のアーキテクチャは、ドメイン知識なくしては生まれません
開発しているシステムを使って回しているビジネスはどういう構造のものなのか どういう登場人物がいて、どういうデータが生まれるのか
ビジネス部門は今後の姿をどう描いているのか、徹底的に情報を仕入れに行きましょう
業務理解を進めようとして悪い印象は受けないと思いますし、コツコツとコミュニケーションを重ねることで、更なる信頼関係の醸成に寄与してくれるはずです少しずつモノリスを千切っていく
ドメイン知識が付けば、ビジネス的な結合度合いが見えてくると思います。データ的にどこが疎結合にできるのか、モノリスから切り取れるところを見つけて、まずは１つ外だししてみます。Four Keysなどを参考にまずは小さく改善提案してみしょう。小さく始めることが大事です
APIを介して開発を進めるということにまずは慣れましょう
また、まずは専任でいいので、千切ったドメインを開発・運用するチームを作りましょう
チーム人数はコミュニケーションコストの最小化とシナジー効果の最大化を狙って、なるべく５～９人程度になることが望ましいです実際に運用をしながら千切っていく工程を継続
急ぎすぎず、ビジネスの状況や今後の方針などを考慮しながら切り出しを継続します。開発効率の向上や不具合が減ることが分かれば、発注者も反対はしないでしょう。ただし、分割すること自体が目的にはならないように。ドメイン横断なチームを作る
開発の本来の目的は、「ほしい時にほしい機能を入手できる」であるはずです
そのためには、１チーム＝１サービスのような形にしてしまうと、あまりにもムラが大きいです
チーム間の交流や、勉強会などを通じて、全てとは言わないまでも複数のサービスを１チームで担当できるようになりましょう
そうすることで、ビジネス的に必要な順番でムラなく開発ができるようになります
ユーザ体験を重要視することになるので、どのサービスでどのような修正が入ったのかは全体で共有します。そういったことをしないと、仕事の目的意識を忘れて、自分たちのサービスを守ることや、壊さないことに意識が向きすぎて、チーム間を監視しあうような形になってしまいます
このように、発注側と受注側全員で全体のユーザーストーリーを意識し、その時々によってどのサービスを育てるのかを共通意識のもと決定する
時にはお客様のもとへ出向き、時には集まって勉強をする
こうすることによって、組織と、お客様と共に進化を継続できるようになる それがビジネス成果と、真に楽しい開発体験を提供してくれるはずです
そうてはなく、プロジェクトを立ち上げて一気に負債返済をするようなアプローチをとってしまうと、コミュニケーションや信頼関係、知識の習得面で問題を産み、新たな負債を生んでしまう結果になりがちです。やってみないと分からない要素は常に多分にあるものなので、継続的に取り組みができる体制を目指しましょう
手に入れた技術力を使って、世の中を便利にしている実感が得られる
それがモチベーションになるエンジニアさん、多いのでは？
「早くいきたいのであれば1人で、遠くまで行きたいのであれば皆で」ということわざ（？）があります
どうすれば皆で仕事ができるのか考え続けましょう
この記事が気に入ったらサポートをしてみませんか？