アンチパターンに見る、「You build it, you run it」が与える示唆
マイクロサービスを進めていく時に陥りやすいアンチパターンにはどんなものがあるだろうか。最初に塚田氏が挙げたのが「システムアーキテクチャ上はマイクロサービスにしつつも、組織体制と責任分界点が、依然として各サービス開発チームと横串の運用チームとで分かれているケース」。
ここで誤解のないようにしたいのは、必ずしも組織図上のチームが分かれていること自体が悪いのでない。運用のスキルに長けた人材が運用のことに集中するのは自然なことだ。大切なのは、マイクロサービスにするのであればチームの構造もそれを考慮した形態であること、そして各サービスを担当する開発と運用メンバーが共通のオーナーシップを持つことだ。
このケースに現れる行動としては、開発チームから運用チームに「環境作ってください（セルフサービスになってない）」「デプロイしてください」「このSQLをたたいてログください」などを依頼し、運用チームが色々なサービスに関する依頼対応を横串で行うようなものが挙げられる。
これでは承認待ちや、チーム間での上下関係が生まれてしまうこともある。塚田氏は「開発チームが柔軟に動けなくなるとか、自分の責任から運用を外してしまうことになります。自分が書いたコードがサーバーにどんな負荷を与えているか分からないと、いい開発はできなくなります。運用で生じた課題を開発にフィードバックして改善するなど、一気通貫したオーナーシップを持つことが大事です。これを実践するためにAmazonが採っている方法が「You build it, you run it」であり、Amazonでは開発者がそのまま運用にも責任を持つ形態を取っているのです」と話す。
また、きちんとマイクロサービス化ができていないと、他のチームへのブリーチ（侵略）が起きることもある。本来マイクロサービスでは「このサービスＡは、別のサービスＢのことは知らない」という独立性を保つことができる。一方でこの独立性を保てないと、1人の開発者がサービスＡもＢも知ることになり、チームの境界が侵略されることになる。これではマイクロサービスが形骸化してしまう。
Amazonでは自社のシステムが巨大なモノリシックとなったため、2002年前後にマイクロサービスに舵を切った。ジェフ・ベゾス氏が「全てはAPIで会話するように」と言ったそうだ（API Mandate, The Bezos Mandateなどと呼ばれる）。他チームのプログラム内部は知る必要はない、むしろ知ってはいけない、例外は一切認めない、ということだ。
マイクロサービスで各サービスが独立性を保つメリットが実感できないと、開発と運用を分けて考えてしまいがちだ。例えばスタートアップでは、最初は小規模だから開発も運用もチーム内で担っていたが規模が大きくなるにつれて、運用専任のチームができることがある。それが正解になる場合もあるが、塚田氏は「開発した人が最もシステムを知っていますし、運用のことを考えられる人が開発したほうがいいですよね。だから開発した人が運用をやるほうがいい、というのがAmazonのYou build it, you run itです」と話す。
もうひとつ、Amazonでもよく言われるのが「ピザ2枚（ルール）」。チームの最適な人数を表す目安で、2枚のピザを食べるのにちょうどいい人数でチームを組むことが推奨されている。これならマイクロサービスの開発と運用をひとつにできる。
チームをサービスに合わせて分割しても、うまくいかない場合もあるという。原因の可能性として塚田氏は「適切な権限委譲ができていない」ことを挙げる。先述したように、チームがまるで小さな企業のようにサービスの全ての工程において責任を持つことが理想となる。しかし権限がない時、例えば技術選択する上で承認が必要になるなどの組織的な構造が足かせになってしまうことがある。各マイクロサービスのチームは、担当範囲においてエンドツーエンドのオーナーシップを持つことが重要だ。
ほかにも「CI/CDやオブザーバビリティなど自動化のためのツールがそろっていないケース」もある。これらは「マイクロサービス以前の問題」と塚田氏は断じる。前述の通りマイクロサービス化の目的がはっきりしていれば、こうした自動化ツールを整備しておく必要があるのは自明だからだ。
新しい技術へのチャレンジはスキルアップにつながる
組織体制を変革するとなると、数か月や数年単位で取り組む必要がある。さすがに開発者だけで手がけられる問題ではない。現場がCTOや経営層と情報共有をしながら進めていく必要があるだろうし、CTOや経営層のコミットメントが必要だ。
開発者が運用についても考える必要性や、技術論から組織論にも話が及んだところから、腰が引けてしまう開発者もいるかもしれない。しかし、新しい技術に挑戦できることはエンジニアにとってチャンスであることに変わりはない。それがモチベーションを高めることにもつながる。
「新しい経験ができる会社はエンジニアから見て魅力的な会社ではないでしょうか。ぜひポジティブにとらえて、スキルアップのチャンスとして生かしていただけるといいと思います。ぜひ新しいことにチャレンジして、自分の財産としてください」
