分けるべき境界と、まだ分けない判断

架空事例：青葉機材の予約、料金、通知を、どの単位で変更・公開するか検討する。組織や開発期間の条件は説明用であり、特定方式の導入事例ではない。

三つのサービスを、いつも同時に公開している

予約、料金、通知を別々のプロセスへ分けた。構成図には三つのサービスが並び、見た目は整理された。ところが、料金の項目を変更すると予約側も修正が必要で、通知も新しい項目を使うため、結局いつも三つ同時に公開していた。

プロセスを分けたことと、独立して変更・配備できることは同じではない。

三つが同じDBの内部テーブルを直接読み書きしていれば、保存形式の変更も共有される。呼出し先の新版だけが返す値を呼出し元が直ちに要求すれば、公開順序も結び付く。ネットワークを間に挟んでも、契約の依存は残る。

マイクロサービスの利点を評価するには、何を独立させたいのかを定める必要がある。Fowlerの比較でも、配備やスケールの独立性と、分散化に伴う複雑さは、同時に引き受けるトレードオフとして扱われている。1

同じ実行単位でも、責務は分けられる

青葉機材の開発担当者は少人数で、予約と料金のルールはまだ一緒に変わることが多かった。一方、通知は外部の配送先へつなぎ、独立した障害が起きる。この条件なら、全機能を同じ粒度で分散させる必要があるだろうか。

一つのアプリケーションの中で、予約、料金、通知の責務と呼出し口を分ける案がある。内部の参照を制限し、共通の契約でやり取りすれば、同じ配備単位でも変更の影響を整理できる。逆に、フォルダを分けても互いの内部を自由に参照するなら、分離の効果は小さい。

実行・配備の単位を分けるかどうかは、その後の別の判断になる。通知だけを別の実行枠へ移し、予約は一つのアプリケーションに残す案もある。段階的に分けることは、中途半端だから誤りなのではない。得たい独立性と、そのために増える運用を比較した結果であり得る。

本事例の比較では、次の問いを先に置く。料金だけを別の頻度で公開する必要があるか。予約と独立して大きく増設する必要があるか。異なる運用責任者がいるか。障害を別の資源へ隔離する必要があるか。どの条件もないのに、サービス数を増やすことだけを目標にしない。

変える境界によって、引き受ける問題が違う

分ける対象	得たい性質の例	新たに確かめること
モジュールの責務	変更理由を分離し、内部への依存を減らす	公開する契約、循環依存、共通化の意味
実行資源	一つの待ちや過負荷の波及を抑える	資源配分、共有部分、滞留と監視
配備単位	異なる頻度・順序で公開する	新旧互換、ロールバック、設定と依存先
データの管理主体	更新の責任を明確にする	他側への反映時点、重複、整合性の境界
チームの責任	判断と保守の担当を明確にする	契約変更の調整、当番、障害時の引渡し

この表は、青葉機材で比較するための整理である。すべての境界を同じ場所に揃える規則ではない。一つのチームが複数サービスを管理する場合も、一つの配備物を複数の担当が扱う場合もある。

ただし、異なる境界がずれた場所では、調整が必要になる。別チームが管理するサービスへ直接DB更新を依頼するなら、どちらが保存の制約を守るのかを決めなければならない。通信方式より先に、責任の所在を明らかにする。

シラバス4-7と8-4は、必要な機能とシステム方式を結び付け、その実現性や運用・保守を評価することを求めている。2 流行する方式の名称は、評価の結論ではない。

公開順序を考えると、互換性が具体的になる

予約APIへ新しい項目を追加し、通知がそれを利用する。予約側と通知側を独立に公開したいなら、どちらが先でも業務を壊さない期間を作る必要があるかを検討する。

例えば、予約側が新しい任意項目を返し始めても旧通知側が無視できるなら、予約側を先に公開できる可能性がある。その後、新通知側が項目を利用する。だが、新通知側がその項目の存在を前提とするなら、旧予約側との組合せでは動かない。必要な依存関係を明示し、公開順序や機能の有効化時点を合わせる。

ロールバックも同じである。プログラムの旧版へ戻せても、新版で保存したデータを旧版が読めなければ、業務を元に戻せない。コードを戻す操作と、データや外部への副作用を回復する操作は違う。予約を確約した後にプログラムを戻しても、顧客への約束は消えない。

独立配備を選ぶなら、この互換期間、状態、回復の責任まで引き受ける必要がある。逆に、全体を一度に止めて整合した組合せへ切り替えることが業務上許されるなら、その単純さにも価値がある。許容停止時間と変更頻度の条件から判断する。

小さく作ることには、異なる目的がある

要求が十分に定まっていないとき、小さな試作品で利用者の理解を確かめることがある。同じ対象を繰り返し改善するなら反復の観点、機能の一部ずつを利用可能にするなら増分の観点になる。両者は併用できるが、同じ意味ではない。リスクの識別と低減を反復へ組み込むのが、スパイラルモデルの重要な特徴である。3

青葉機材では、点検情報を使って営業が判断できるかという未知と、外部サービスを所定時間内に照会できるかという未知がある。前者には業務シナリオや画面の試作、後者には一連の処理を通した技術検証が役に立つ。未知を分ければ、何を小さく作るべきかが変わる。

一方、必ず守るべき契約条件や、決まった稼働開始日がある場合、その制約まで「後で考える」対象にしてよいわけではない。段階的な開発でも、各段階で成立する業務と、まだ提供しない範囲を明示する必要がある。

ウォーターフォールという名称だけで変更を禁止することも、アジャイルという名称だけで合意を省くことも適切ではない。要求の確定度、技術の不確実性、変更の費用、関係者の判断方法を踏まえて進め方を選ぶ。

スクラムのイベントと、完成の基準

スクラムガイド2020では、Sprintはほかのイベントを含む枠として扱われる。その中で、Planning、Daily Scrum、Review、Retrospectiveが異なる目的を持つ。Reviewは成果と今後の方向を検討し、Retrospectiveは仕事の進め方の改善を扱う。Daily Scrumを、管理者への単なる進捗報告会と同一視しない。4

また、利用可能な成果物であるIncrementには、Definition of Doneを満たすことが必要である。Sprint Reviewが終わるまでリリースしてはいけないという規則ではなく、ガイドではReviewを価値提供の関門として扱わない。4

青葉機材の例では、「画面が表示できる」と「予約の確保条件、権限、必要な確認を満たした機能が使える」は違う。作業が終わったかの基準が担当者ごとに異なれば、部分的に動くものを、業務へ使えるものとして受け渡してしまう。

一つの予約機能の受入条件と、成果物全体に必要な品質の基準も、混ぜずに扱う。前者では、どの条件で何を確定できるかを確認する。後者では、その成果物を使うために共通して必要な状態を定める。名称を増やすことではなく、何をもって利用可能とするかを共有することが目的である。

変化に対応することと、判断の根拠を残すこと

アジャイルソフトウェア開発宣言は、動くソフトウェアや協調、変化への対応を重視する。同時に、対比された側の項目にも価値を認めている。文書や契約や計画を不要とする宣言ではない。5

青葉機材で、確認中の依頼を確定数へ含めないと決めた理由が残っていなければ、別の担当者が「在庫を先に押さえた方が親切だ」と変更するかもしれない。それが業務上の別の設計であることに気付けなければ、予約数の意味が途中で変わる。

長い議事録を残す必要が常にあるわけではない。しかし、採用した条件、代替案を採らなかった主要な理由、影響を受ける契約は、次の変更を判断できる程度に残す。自動テストも、何を約束した結果なのかが分からなければ、不必要な制約なのか重要な安全条件なのかを区別しにくい。

方式を選ぶ仕事は、一度きりの大きな決断ではない。何を内側で管理し、何を外側へ渡し、どの変更を独立に行えるかを、要求と証拠に合わせて調整する仕事である。まだ分けないという判断にも、分ける判断と同じだけ、具体的な根拠が必要になる。

知識を答案へ戻す

午前Ⅱ。 モジュール分割、分散実行、独立配備を同義にしない。反復と増分、ReviewとRetrospective、完成の基準と会議の実施を区別する。手法の名称ではなく、対象と目的を読む。

午後Ⅰ。 開発・公開の制約を、方式の選定理由へ使う。小規模チーム、変更頻度、新旧の同時稼働、停止可能時間など、本文にある条件から答える。「マイクロサービスだから優れる」といった一般論を追加しない。

午後Ⅱ。 得た独立性と引き受けた負担を両方述べる。通知だけを分けたなら、通知先の停止が予約を巻き込まない目的と、未通知の監視・再送をどう担ったかを説明する。

立ち止まって考える：三つのプロセスが別なら、独立配備できるか

別プロセスでも、新旧のAPI契約、共有DB、設定、業務状態が結び付いていれば同時公開が必要な場合がある。どの版の組合せが動き、どの順序で変更できるかを確認する。物理的に分かれていることを、変更の独立性と取り違えない。

出典と照合範囲

[1] Martin Fowler, Microservice Trade-Offs：独立した配備・スケールなどの利点と、分散化・運用上の複雑さを比較する観点を参照した。本文の青葉機材の構成比較は独自の例である。著者公開本文

[2] IPA「SAシラバス Ver.5.2」：4-7、4-15、5-6、8-4。方式、実現可能性、開始時期、方式評価との対応を照合した。公式PDF

[3] コンプリートテキスト第6〜9・24章：責務、分散化、ライフサイクルモデル、アジャイル、合意の基礎を発展させた。

[4] Scrum Guide（2020）：Sprintと各イベント、Increment、Definition of Done、Reviewとリリースの関係を照合した。青葉機材に特定の会議体を必須とするものではない。公式ガイド

[5] アジャイルソフトウェア開発宣言・公式日本語版：価値の対比が、文書・契約・計画の価値を否定するものではないことを照合した。宣言