10→100フェーズ：事業拡大に伴うシステムの拡張限界と機能間調整問題を解決する

小さな機能追加でもシステムに大きな影響を及ぼすことがある

　トラフィックの問題以上に課題になるのが機能拡張です。

　新規事業開発のほとんどのケースでは、「0 → 1フェーズ」で発見したコアな顧客だけでは大した事業規模にはなりません。複数セグメントの顧客を取り込んで初めて、一定規模の事業規模になります。複数セグメントの顧客ニーズに応えるための機能拡張が必要です。

　加えて、競合他社が、先行する自社の顧客を奪うべく、さまざまな機能を追加してきます。競合に既存顧客を奪われないためにも素早い機能拡張が要求されます。

　新規事業開発においては、しばしば「拙速は巧遅に勝る」と言われます。ですがシステム開発では必ずしもそうとは限りません。第2回で触れたように、リリースを急ぐがために整合性のない実装をしてしまい、技術負債を貯めてしまいがちだからです。

　技術負債が貯まると開発のスピードはどんどん遅くなっていきます。新規事業におけるシステム開発の一番の要諦は「いかに開発スピードを落とさずに進められるか」にあります。顧客からのフィードバックを基に、どういった機能追加が必要か、優先すべき機能はどれかを判断しながら開発を進めていくことになります。

　この機能拡張段階で出現するもう1つの課題が、機能間調整の問題です。システムでは、ある箇所で発生した処理結果を別の箇所で利用することが少なくありません。そのため、機能追加や仕様変更自体の作業工数が小さくても、システム内の別の箇所に影響する可能性があります（図3）。

図3：システムの機能追加や仕様変更では、他の箇所に及ぼす影響を考慮しなければならない

　この、ある箇所の変更が別の箇所に影響を及ぼすことを「依存」と呼びます。依存関係が複雑であればあるほど、テストと修正の工数が大きくなります。これが機能間調整の問題です。

　予期せぬ箇所に影響が及んだ結果、バグが発生することがあります。たとえ小さな変更だったとしても、他の箇所への影響をテストし、必要に応じて修正するための工数がかかります。

機能間調整問題をマイクロサービス化で解決

　これらのような問題を解決するために取り組まれているのが「マイクロサービス化」です。システムの各機能を小さなユニットに分け、ユニット同士の「依存」を極限まで減らす開発手法です（図4）。

図4：機能を小さなユニットに分けた「マイクロサービス」として開発する

　システムが互いに依存しない小さなユニットで構成できれば、変更が発生した場合も、その箇所に変更を加えるだけで済みます。他の箇所への影響を調査したり、その影響による問題を解決したりする必要がないだけに、新規事業開発においては、もはや必須の取り組みといえるでしょう。