maybe daily dev notes

私の開発日誌

トップ > 開発 > 会社をマイクロサービスアーキテクチャのシステムとして捉えたら

会社をマイクロサービスアーキテクチャのシステムとして捉えたら

開発 その他

はじめに

会社組織をマイクロサービスアーキテクチャとして捉える見方があります。この記事ではその概要、またそうした場合に考察される｢良い｣チームのあり方についてまとめます。

マイクロサービスの要点

ここでいうマイクロサービスとは、技術分野におけるアーキテクチャパターンのこと。マイクロサービスアーキテクチャ内の各サービスは以下の特徴を持ちます。なお、ここでのユーザーはそのマイクロサービスのユーザーを指します (エンドユーザーや他のマイクロサービスなど)。

  1. 各サービスはAPIを公開し、ユーザーはそれを通してのみサービスを利用できる
    • サービスの内部実装をユーザーに意識させてはならない
    • 注) ここでのAPIはHTTPでJSONを云々などの話に限らず、サービスを利用するインターフェースの決め事全般を指す
  2. APIはユーザーとの契約なので、基本的には破壊的変更を加えてならない
    • APIは変更しない限りは、マイクロサービス内部の実装は自由に変更できる
  3. サービスは満たすべきサービスのレベルをユーザーと合意し (Service Level Agreement, SLA)、そのレベルを満たすように努力する

他にも色々あるでしょうが、今日の話に関連する部分だけピックアップしました。 上記の特徴により、各マイクロサービスは独自に意思決定をし、迅速な改善を実現することができます。

マイクロサービスの例

マイクロサービスの代表的な例の一つとして、AWSの各サービス群が挙げられるでしょう。Amazon S3やSQSなど、それぞれのサービスは独自にAPIを定義し、そのAPIに破壊的変更を加えない範囲で継続的に改善することに成功しています。

Amazon CEO(当時)のジェフ・ベゾスが社内の開発者達に通達したとされるBezos Mandateはあまりにも有名です。2002年の話ながら、現代のマイクロサービスに必要な特徴と多くの点で共通しているので、ぜひ見てみると良いでしょう。

会社とマイクロサービスアーキテクチャの類似点

会社の各チーム(部署)は、それぞれがマイクロサービスであるとみなすことができます。 例えば、経理部のあるチームは経費精算申請のリクエストを送ると払い戻しが返ってくるサービスのようなものですし、特定分野のエンジニアが集うチーム(コミュニティ)は関連技術の質問を投げると答えが返ってくるサービスとしてみなすこともできるでしょう。

このように考えると、上記で上げたマイクロサービスの特徴を、会社内の各チームにも適用することができます。以下では、それぞれの類似点とその考え方をチームの運用にどう活かすかを考えてみました。

定められたAPIを通したサービスの利用

マイクロサービスは、ユーザーと取り決めたAPIを経由した利用しか許可されません。ここでいうAPIとは、そのサービスを利用する上での決められたインターフェースです。会社のチームの場合でも、例えば決められたツールでのみ経費申請を受け付けるとか、質問を受ける際は一定のフォーマットを強いるなどといった、ある種の｢入力｣に関してユーザーにルールを課すことがあります。

これにより、各入力を標準化された方法で処理することができます。入力のバリデーションや担当者の割り振りなどを自動化することも見据えることができ、非常に望ましい状態と言えるでしょう。

合意のないインターフェースを介した利用、例えばチーム内のメンバーに直接DMするといった方法はこの規則に反します。これは以下の点で望ましくありません:

  • ユーザーがチーム内の構成員というある種の内部実装を意識している
    • チーム内の内部実装の変化、例えば構成員の移動などが発生した場合に、ユーザーはこれまでの方法が使えなくなります
  • 上記の自動化プロセスを無視するため、サービス側の効率が低下

もちろん、これはシステム間の連携というよりは人間同士の繋がりの話なので、例外はあるでしょう。しかしながら、基本的には定められたAPIを通してやり取りをすることが望ましいのは共通です。

APIに破壊的変更を加えない

上記のAPIに破壊的変更が発生した場合、そのサービスに依存するすべてのユーザーは変更に適応する必要性が生じます。例えば、経費申請で入力すべき情報が増える、そもそも経費精算で使うツールが変わるなどといった変更です。

変更への適応には、確実にコストが伴います。こちらも状況にはよりますが、必要のない限りはAPIに破壊的変更を加えないというのも、同様に当てはまるでしょう。

また、APIに変更を加えないという前提であれば、それ以外の変更は自由に可能です。構成員の変更も内部の業務プロセスの改善も、APIが変わらないのであれば個別ユーザーへの相談は不要です。このためチーム内で意思決定を迅速にできるということが大きな利点となるでしょう。

サービスのSLA

会社の各部署でも、サービスのレベル(品質)についてユーザーと合意を得るべきです。技術文脈でSLAと言えば可用性のパーセンテージがよく想像されますが、実際はサービスの品質に関するあらゆる項目が含めることができます。例えば、経費申請してからN日以内に振り込むだとか、質問には平日の9〜17時JSTのみ回答しますというのも一つのサービスレベルでしょう。とにかく、ユーザーに提供するサービスの品質について、一定の計測可能なレベルを決め、ユーザーと合意を得ます。

チームはこのSLAを達成するための努力をすべきです。誰が担当するかやメンバーの急な欠勤などには左右されない、常にSLAを満たせる仕組みを作ることに尽力しましょう。

一方で、SLAを超える部分については、ある種の安全余裕です。SREの分野にもError budgetという考え方があり、その余裕を使ってリスクのある実験をするということもできます。チームの運用においても、案件の対応を適度に遅らせながら、合間に他の重要なタスクをこなすといったことが可能でしょう。

SLAを定めることで、サービス運用側は運用状況の良し悪しについて指標を得ることができますし、またサービス利用側はサービスに対して必要十分な期待で利用でき、計画も立てやすくなりますね。

SLAを超える仕事

まれに、SLAを超えた仕事をするメンバーがいる場合もあります。例えば、9〜17時JSTの対応で合意を得ている状況で、その人だけ深夜にも対応を行うなどです。この行為自体はユーザーからも歓迎されるものですし、問題ないでしょう。しかしながら、この活動によって、ユーザーが本来のSLAを勘違いしてしまうリスクがあります。｢XXさんは深夜対応してくれたのにあなたはしてくれないのか？｣などといったクレームが想像できますね。

このような状況を回避するためには、以下が重要と思われます:

  • SLAを超える対応をする人は、それが本来のSLAを超えた対応であること･他の対応者には同じ対応を期待してはいけないことを、ユーザーに対して強調する
  • サービスの運用側は、現在のSLAをわかりやすい形で常に告知する

また、SLAを超えた仕事をするメンバーは、それが本当にユーザーにとって価値のあることだと信じているのであれば、それをチーム全体のサービスレベルとして引き上げることを目指しても良いかもしれません。チームメンバーに働きかけ、SLA自体を向上させるわけです。

いずれにしても、こういった考慮をせずにSLAを超えた対応をするのは、実は周囲に思わぬ影響をもたらす可能性があるということは認識すると良いでしょう。

この例えの限界

実際の組織の意思決定プロセスは、上位のチームの承認が必要な場合があります。ある種、そのサブ組織のツリー内で分散モノリスができてしまったような状態と言えるでしょうか。この場合は意思決定を迅速にするというメリットは失われるかもしれません。

また、この話はチームの定型業務をサービスとしてみなした場合のみ成立すると考えられます。非定型業務で厳密なAPIやSLAを定めるのは非効率なためです。あえて例えに含めるなら、非定型業務はチームが新たに価値を発揮できる場所を探すPoCのようなものかもしれません。

まとめ

ということで、会社をマイクロサービスとしてみる話でした。この視点から見ると、技術的に良いマイクロサービスとはという話をチームの運用にも流用できることが分かります。あなたのチームはどのような役割を担うサービスでしょうか？

個々のチームの改善は自ずと会社全体の改善に繋がります。今回紹介したような考え方も使いながらチームを運用して、改善を加速しましょう。