arclamp

ITアーキテクト 鈴木雄介のブログ

アジャイルにおける事前合意について

昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます!。

ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか?」ということを書きたいと思います。

shaking-hands_CapitolMall

アジャイルは最初に全てのCDSを決めない

まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS(品質/コスト/期日/スコープ)ですが、Q(品質)というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。

ウォーターフォール型開発というのは、

  • 「スコープは最初に確定」し、
  • 「コストや期日はスコープを達成するために必要な分を最初に設定」し、
  • 必要なリソース(人員など)を調達する

というシンプルな考え方です。そして、スコープを決めるために要件定義工程を実施します。この手法の問題点は、規模が大きくなるほどコストや期日の予測が難しくなる、開発期間中にスコープを変更したくなる、リリース間近にならないと品質の確認ができない、といった点です。

これに対してアジャイル開発プロセスというのは、

  • とりあえず要員を固定化し、
  • 「スコープは定期的に見直す」ことで、
  • 「期日はリリースできるようになったらリリースする」ことになり、
  • 「コストは人員を維持した期間分だけかかる」(ゼロにしたければ開発を止めればよい)

となります。つまり、アジャイルは「要員の固定化による調達オーバーヘッドの排除」「スコープの定期的な見直し」という仕組みによって、CDSを開発期間中に調整可能にしてしました。

整理すると「スコープを決めたら最適なコストと期間で作る(終わるまでスコープは変更はしないでくれ)」なのか「コストが固定的にかかるが、定期的にならスコープを変えていいし、リリースはなる早でやる」なのか、です。

(だから内製化してコストを人件費で処理できるとアジャイルのメリットが際立つことになります。SIerによる準委任的なアジャイルが顧客から見て投資対効果が見えにくくなる原因でもありますね)

チームはどこを他者と合意し、どこを自分たちで決定するのか

アジャイル開発プロセスは「最初に全部を決めなくてよい」のですが、仕事としては「最初に何も決めなくてよい」とはなりません。

特にステークホルダー(利害関係者)とは、ある程度の合意を事前にした上で開発を進める、というのが一般的です。

例えば顧客やオーナーとであれば、大まかな目標と期日、そしてコストの合意をするでしょう。これら全てを「やってみないと分かりません」というのは普通は許されないのです。

あるいは関連部署との業務手続きや関連システムとの連携、運用部門への引き継ぎなどもリリース間近になって「こうしてください」とはいきません。ある程度は事前的に合意をし、検討するべきは検討し、用意すべきものは用意するというタスクを起こしていきます。

他にもマーケ部門や広報部門とデザインルールやブランドイメージへの準拠、マーケ部門とはネタとしての機能合意などもあるかもしれません。これも勝手に決めることはできません。

ウォーターフォールは「最初に(決められないことでも)合意するしかない(から無理が来る)」ことで嫌われていたのですが、アジャイルは逆に「手法としては最初に全部決めなくていいが、仕事としては最初にそれなりに合意しないと後で面倒」という状況になります。これはシステム開発の規模や企業の規模に関わりません。

(というか、そもそも仕事とはそういうものですけども)

つまり、チームにとって「合意相手と合意すべきところ」と「チームが自ら決定するところ」があり、それらをきちんと整理して分別し、適切に管理することが必要になります。

事前合意は厄介なもの

そもそもアジャイルに限らず、チームにとって「利害関係者と合意する」というのは厄介な作業です。利害関係者というのはそれぞれの分野の専門家であり、その分野における常識や規則に縛られています。つまり、話が合わないのが普通です。とはいえ、多様な専門家の集まりが組織的な強さを発揮すれば高い成果に結びつくわけで互いに意見をぶつけあって、よりよい合意を目指すことが重要です。

もちろん、チームの状況によっても難易度は異なります。極端な例とすれば経営者がチーム内にいて、しかも自己資金でやっているITベンチャーなら一切の事前合意は不要かもしれません。逆にエンタープライズになれば事前合意を強く求められ、結局はウォーターフォール的に進めるしかないこともあります。

さて、特にエンタープライズアジャイル開発においては1.ビジネスのコンセプトと、2.他システム連携の事前合意に問題が生じることが多いです。

どの機能が儲けにつながるのか?

ビジネスのコンセプト、というのはシステムのコンセプトとは違います。ビジネスのコンセプトとは端的に言うと「いかにして儲けるか」、そして「どの機能があると儲かるのか」ということです。

アジャイル型開発では「優先度の高い機能から作る(そして定期的に優先度を見直す)」のですが、優先度を判断する上で重要なのが「その機能があれば儲かるのか?」ということです。

ウォーターフォールの場合は最初に全てを決める必要があるので「全ての機能を抜け漏れなく洗い出す」ことが優先されます。アジャイルであれば「必要になったら、なる早で作る」という安心感があるのですが、ウォーターフォールでは「最初に言わないと、いつ出来るかわからない(少なくとも最初のリリース後)」という不安もあり、網羅性が重視されます。

結果として「その機能が儲けにつながるのか?」というような判断よりは「使う可能性があるなら作ることにしておこう」となりがちです。

例えば運営者が使う管理画面のようなものは、最初はなるてもなんとかなることもあります(ここは儲かる儲からないではなく、業務部門とのせめぎ合いもあるでしょうが)。

ウォーターフォールは「最初に作るべき機能を定める」こともあり「システム開発をする」という感覚に陥りがちです。一方のアジャイルは常に「ビジネス的に優先度の高いものから作る」ことを考えるので「ビジネス開発をする」という感覚が必要になります。

この違いを共有するためにも「ビジネスのコンセプトを事前合意する」は重要です。表現としてはビジネスモデルキャンバス、ユーザーエクペリエンスマップ、より詳細にはユーザーストーリーのようなものがあげられます。

大事なのはビジネスのコンセプトからシステムの機能まで線を引き、その機能の必要性をビジネスの観点から考えることです。

いかに基幹と繋ぐか

次がシステム間連携です。特にエンタープライズアジャイル開発では、SoRな基幹系システムと連携することが重要になります。

企業がアジャイルシステム開発を判断する場合、多くは新たなサービスを作り、既存顧客からの新たな売上獲得を目指します。既存の営業チャネルや取引チャネルを活用しつつ、試行錯誤の部分を「じゃ、アジャイルで」となります。

このような案件では既存顧客のデータ(アカウント、取引履歴、支払い、請求など)との連携が重要です。この連携があることで顧客にとって支払い先を集約するメリットが生まれます。

システム連携の難しさは技術論ではなく、ドメイン間にはインピーダンスミスマッチに起因します。既存サービスを成立させるとために作られてきたモデルは、必ずしも新しいサービスとは整合しません。この場合、どのようにミスマッチを解決するかは事前に考える必要があります。

ミスマッチを解決する1つの方法は「既存システムが新しいサービスのために新たな連携を開発する」ということですが、大抵の場合は時間もコストも合いません。よって、ミスマッチがある既存の連携を流用し、新しいサービス側がなんとかすることになります。

もちろん、最初からきちんとしたシステム連携をする必要はなく、手動でも問題はありません。でも、概念がズレていることは事前に理解しておく必要があります。この事前合意を怠るとシステムが破綻するか、それを手動でリカバリする業務が破綻します。

事前合意するためには、やはり、ある程度は踏み込んで既存システムの概念やコンセプトを理解した上で、連携項目1つ1つを丁寧に検証する必要があります。

アジャイルでやっていると、どうしても表側の機能開発に気を取られ後回しにしがちですが、システム連携の合意が遅くなるほど必ず手戻りが増えてしまいます。この点にも注意が必要です。

アジャイルにおける事前合意について

アジャイルという開発手法は「最初に全てを決めなくてもいい」という意味で優れています。ですが、それに甘んじて利害関係者との事前合意を疎かにするとうまくいきません。

その事前合意をどう進めるのか、というのに唯一の答えがあるわけではありません。要件定義期間を設けるもよし、チーム自身が進みながらやるもよし、専任部隊をチームの外に用意するもよし、状況に応じて適切な対応が求められる、というだけかと思います。

アジャイルを機能させる外枠について

2017/12/15のエンタープライズアジャイル勉強会 2017年12月セミナーの企画は僕がやらせてもらいました。

テーマは「アジャイルを機能させる外枠」とし、アジャイルチームがうまく機能するために、あえてチームの外側で解決した方がいいこと、を整理してみたいと思いました。

アジャイルチームというのは、実際にモノを作り、サービスを動かし、ユーザーからのフィードバックを付けて改善を行っていくことが目的です。その目的を達成するためにはアジャイルチームの外枠をちゃんとする必要性があると考えています。

All Along the Watchtower

アジャイルを機能させる2つの外枠

1つ目の外枠は「何を作るべきか」という観点。チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん(@papanda)にお願いしました。市谷さんの講演は「アジャイル開発はWhyから始まる」というタイトルで、機能開発の前にWhyとしての仮説検証を行うことで開発が右往左往しなくなる、という話でした。「顧客開発をプロダクト開発よりも極端に優先するとチームが右往左往する」という指摘はその通りですね。

2つ目の外枠は「どう作るべきか」という観点。ただし、これはプロダクト本体の作り方ではなく、プロダクトの外側と連携する部分の作り方の話です。これは僕が「アジャイルを支えるアーキテクチャ設計とは」というタイトルで、アーキテクチャ設計にも、プロダクト本体の作り方を考える「小さなアーキテクチャ」と、プロダクトの外側の作り方を考える「大きなアーキテクチャ」という紹介をしました(参照:大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp

というわけで、アジャイルチームを機能させる外枠は「仮説検証というビジネスの話」と「大きなアーキテクチャという技術の話」があるのでは、という整理をさせてもらいました。だいぶ振り幅があるテーマになったな、と思う一方で、けっこう実感もあります。アジャイルを導入しようとしている人の悩みってプロダクトオーナーかアーキテクトに落ちてくる気がします。

見積もれないことをチームに持ち込まない

なお、これは「チーム内にいるエンジニアは外側のことは考えなくていい」と言っているわけではありません。もちろん、外側のことを考えてもいいし、場合によっては解決に携わってもいいのですが、ただ、それはチームの作業としてカウントすべきではないと考えています。そうしないとアジャイルプロセスがうまく回らないからです。

アジャイルプロセスをうまく回すコツは「チームが見積れないようなバックログを積まない」ことです。スプリントプランニングにおいて「曖昧で見積もりができない」「リスクが大きすぎてタスク化できない」というようなことは避けるべきです。そういうものを無理やり見積もっても「勘と経験と度胸(KKD)」になってしまい、生産性を計測することができなくなります。そうするとチームのベロシティが把握できず、結局、安定したチーム運営ができなくなります。アジャイルは期間とリソースを安定させることで開発速度を安定させ、それによって将来における変更対応を担保しています。この根幹が揺らいでしまうと、プロダクトオーナーと開発チームの信頼が崩れてしまうのです。

いまだにアジャイルは「適当だ」という認識の方がいるかもしれませんが、実際は逆で、アジャイルでは適当さが許されなくなります。ウォーターフォールではバッファと呼んで規模やスケジュールに紛れ込ませて適当にやってきたことを、アジャイルでは明確にしないとプロセスがうまく回りません。

そもそも、外枠の話はウォーターフォールでも一緒、ですよね。過去、プロセスに紛れて適当にやってきたがために、明確に議論できなくなっているだけなのでしょう。結局、エンジニアに良い仕事をしてもらうためには「何をすべきか」「制約がなにか」を先に明確にしておいたほうがよい、という当たり前の結論になっただけかもしれません。

最後に

呼びかけに応じて参加してくれた市谷さんに感謝します。付き合いは長いですが、こうやって2人で縦並びで話をするのは初めてな気がします。たぶん。全然違う話を1つの線でつなげられるというのは、とても刺激的ですね。これからもよろしく。


大きなアーキテクチャ設計と小さなアーキテクチャ設計

2017/12/15(金)にエンタープライズアジャイル勉強会2017年12月セミナーで「アジャイル開発を支えるアーキテクチャ設計とは」という話をしました。資料は以下から。

僕の話したかったのは「アーキテクチャ設計といっても『大きなアーキテクチャ設計』と『小さなアーキテクチャ設計』というレベルがあり、後者はチーム内で解決すべきだが、前者はチーム外で解決すべきだ」ということです。

大きなアーキテクチャ設計:システム間連携のレベル→アジャイルチームの外で実施
小さなアーキテクチャ設計:システム内連携のレベル→アジャイルチームの中で実施

なぜ分けるのか、というと、それぞれのレベルで求められる性能も可用性も保守性も違うからです。

小さなアーキテクチャ設計は「チームが好きにすればいい」わけですが、大きなアーキテクチャ設計は「チームをまたがって企業内でそれなりに最適化されるべき」です。

よって、「チームがアジャイルに、自治的に小さなアーキテクチャ設計を進められるようにするためには、大きなアーキテクチャ設計をチームの外に意図的に出すべきである」という考え方になります。これを混ぜたまま進めようとすると、

  • 大きなアーキテクチャ設計についてチーム内の部分最適で判断したために余計な問題やコストが発生した
  • 小さなアーキテクチャ設計に関わることなのにチーム外が全社最適で判断しようとしてチームが動けなくなってしまった

というようなことが発生します。特にアジャイルチームではチームが小さいがゆえに、大きなアーキテクチャ設計に巻き込まれるとリソース不足に陥ったり、スケジュールの遅延が発生し、なによりもモチベーションを著しく下げることになります。「なんでもいいから早く結論を出してよ。それに合わせてサービスの実現度はPOと話して決めるからさ」みたいな。

f:id:arclamp:20171218134824p:plain


一方で、このレベル感を混乱させるのがマイクロサービスアーキテクチャ(MSA)です。MSAでは「システムを構成するコンポーネント(=マイクロサービス)同士をネットワーク越しに連携させる」ことが主流になっています。一方で、昔から「システム同士をネットワーク越しに連携させる」というのは一般的です。

だからこそ、その連携が「システム同士の連携」なのか「マイクロサービス同士の連携」の差というのが分かりくくなっている気がしています。もちろん、あるサービスにとって、それが「システムからの連携」なのか「システム内のコンポーネントからの連携」なのかは見分けがつきませんし、付ける必要もありません。これまでのシステム間連携だって同じことですから。

MSAは、これまで大きなアーキテクチャ設計でしか語られていなかったシステム連携を、小さなアーキテクチャ設計に持ち込みました。ネットワーク連携の様々なオーバーヘッドを許容できるだけの技術の発展があり、その変化を許容しやすくなるメリットが享受できるようになったからです。

というわけで、MSA環境では大きなアーキテクチャと小さなアーキテクチャは見分けにくいのですが、見分けないといけません。繰り返しますが、それは技術論ではなく求められる性能も可用性も保守性が違うから、です。

MSAでは前者をプラットフォームよび、後者をマイクロサービスと呼ぶことで分離していくのでしょうね。プラットフォームチームはアジャイルチームから分離すべき、です。


「大きなアーキテクチャと小さなアーキテクチャ」はエンタープライズ界隈でアジャイルに取り組もうとするときに問題になりがち、という実感のうえで提唱しました。まだまだ粗い整理なので議論の余地もあります。

エンタープライズ界隈でも、改めてアーキテクチャ設計が重要性が高まっているからこそ、無用な混乱を避け、各エンジニアが的確な活動ができる助力になればと思います。

MSA化レベル定義 - 低レベルなマイクロサービスはただのファイル連携と見分けがつかない

「低レベルなマイクロサービスアーキテクチャ(MSA)」というのは「ただの基幹システムとのファイル連携」でいいんだよ、という話。

f:id:arclamp:20170926233520j:plain
Level 5 | Richmond, Virginia | Rebecca Morgan | Flickr

MSAというのは「どこかに存在する完成されたシステム」ではなく、現状のシステムを不断の努力によって進化させていった結果です。MSAに決まった構成はありません。あくまでもプラクティスやパターンがあり、それらの実現を手助けするソフトウェア製品(OSS)があるだけです。

というわけで、「MSAに取り組む」というのは道は遠くても(見えなくても)「目の前のシステムの継続的な改善に取り組む」ことでしかないのですが、最先端の話しかないと差が大きすぎてどう取り組めばいいのか分からない、あるいは再構築しか道はないと感じてしまうのだと思います。そこで段階的なレベル上げができる、というか、段階的なレベル上げをするしかない、という説明をしたいと考えています。つまり、MSA化のレベル定義。

MSAのレベル感

原典であるMartinFowler.comのエントリ「Microservices」に書かれたMSAの特徴をゆるめに表現すると以下のようになります。

  • 全体システムを、機能別のシステム同士が連携することによって実現させていること(Componentization via Services)
  • ビジネス機能にそった開発チームが組織されていること(Organized around Business Capabilities)
  • WF型の一括構築ではなく、継続的に新機能開発を行うこと(Products not Projects)
  • SOAのESBやEAIのような連携基盤を頼りすぎず、サービス自身が同期/非同期API連携を整備していること(Smart endpoints and dumb pipes
  • 開発規約やフレームワークなどを標準化をしすぎないこと(Decentralized Governance)
  • マスタデータは可能な限り個別システムで管理すること(Decentralized Data Management)
  • インフラ関連の作業は可能な限り自動化すること(Infrastructure Automation)
  • 連携先システムが停止しているケースを想定すること(Design for failure)
  • 一括再構築を避け、段階的に部分再構築をしていくこと(Evolutionary Design)

こう書いてしまうと、実は常識的なことしか書いてありません。MSAの基本的な考え方というのは複数のシステムが連携して、全体が機能することを目指しており、そのために最適な組織や障害要素を低減する必要がある、というだけです。

ですから、従来型のシステム群であっても、ファイルとはいえシステム同士が連携はしますし、チームは業務によって組織されています。その他のトピックするもやれるだけは取り組んでいるのではないでしょうか。これがレベル1。

そして、これらを突き詰めていくと最先端の企業の事例にあるような「最小サービスは1週間ぐらいで作れる大きさ」であり「1画面で数百のサービス」が動き、それらが「数万ノードに自動デプロイ」され、「リリースは1日の数十回~数万回」も行われている、ということになります。これがレベル5。

MSA化モデル軸

次にMSA化をモデル化する軸として、以下の4つを考えてみました。

  • 疎結合
    • 目的:サービスの独立性維持、レジリエンス向上
    • 手段:システム間連携の非同期化、データの分離管理など
  • 自動化
    • 目的:リリースコスト/インフラ管理コストの低減
    • 手段:コードから稼働までの自動化、繰り返し作業の自動化など
  • 基盤化
    • 目的:構築スピードの向上、全体最適
    • 手段:横断的関心事の基盤整備、基幹システムのサービス化など
  • 自律化
    • 目的:ビジネス改善、個別最適化
    • 手段:小さなチームによる継続的な作業、個別の技術選択、個別のKPI設定など

MSA化レベル定義

そして、レベル感は以下のようなものを考えています。レベル上げのポイントや取り組むべき具体的な作業については別途。

Lv 疎結合 自動化 基盤化 自律化
0 完全に統合されたシステム ビルドは職人芸、コードは個別管理 物理インフラ 厳格なトップダウン
1 大きなシステム、ファイル連携やデータ共有 ビルドはコマンド化、CVS/SVN インフラの仮想化 ウォーターフォール、標準化強め
2 大きめなサービス、キューによる非同期連携 ビルドパイプライン、Git/ブランチ戦略 認証/ログなどの基盤化、パブリックPaaSの利用 アジャイル風、標準化弱め
3 適度なサービス粒度、データ分離 ブルーグリーンデプロイ 様々な汎用基盤サービスの活用 複数のアジャイルチーム、個別最適
4 小さなサービス、非同期ストリーム、イベントソーシング コンテナオーケストレーション 様々な独自基盤サービス たくさんのアジャイルチーム
5 かなり小さなサービス、独自プロトコル連携 数万ノード、数百回リリース 自作基盤をOSS すごくたくさんのアジャイルチーム

いかがでしょうか?これも軸にあるべきだとか、このレベルにはこういうものが必要だ、とかあれば、ぜひ教えてください。

おじさんにも分かるITトレンド説明と日本のエンプラITの限界

タイトルは煽りです。某勉強会向けに作成した資料ですが許可を得て掲載します。


2001年アジャイル、2006年クラウド、2009年DevOps、2014年マイクロサービスという一覧のトレンドを解説しつつ、最後は「日本のエンプラITはついて行けていないよ」という話。1時間ぐらいで話せますので、自社のことを考えて残念な気持ちになりたいというドM気質のエンプラ企業の方はご連絡をお待ちしております。

ハイライトは以下のページですかね。

f:id:arclamp:20170911232004p:plain
f:id:arclamp:20170911232015p:plain
f:id:arclamp:20170911232024p:plain

合わせて読みたい:事業会社におけるマイクロサービス化について

事業会社におけるマイクロサービス化について

がちがちのエンタープライズ系で既存システムのマイクロサービス化に取り組むときに注意したいこと。

儲かる機能をマイクロサービス化する

マイクロサービスの最大の目標は「サービス化された機能のリリースサイクルを、その機能を管理するチームが独自に決定できるようにする」ことです。つまり、システム内の他の機能や他システムとの調整をしないで、いつでも好きなようにリリース可能であることが大事です。もちろん、日中に。

それは何のためかというと「機能をどんどん改善して儲けたい」からです。これまでは、儲かる機能を改善をしようとしても、その他の機能や他システムとの調整や影響範囲調査やリグレッションテストに時間がかかってリリーススピードをあげることができませんでした。この問題が解決できればウハウハできるはずです。

マイクロサービスのサービス分割点について聞かれることが多いですが、それは「ビジネス部門が『早くリリースできたら儲かる』って言っている部分で切ればいい」です。マイクロサービス化によって儲かる度合いが増える、というのが大事です。で、それをビジネス部門と合意する。

とはいえ、そんな自由に切れないわけで、エンジニアはビジネス部門がやりたいことを理解しつつ、良い感じの分割方法や制約条件を整理します。もちろん、できないこともあるでしょう。ただ、それは「基幹システム側の都合に引きずられるからであって、このシステムのせいではない」ことを説明しましょう。そっちに言ってくれ、と。それ以外にも疎結合化(非同期化)は、かならずシステム間で不整合を生み出す可能性を持っています。ビジネス部門に制約を提示し「儲かるから、その制約は飲むよ」と言ってもらうことが大事です。ここでビジネス部門をちゃんと巻き込みましょう。

意思決定システムや運用ルールを変えていく

「機能を改善して儲ける」というのは「儲かる機能を考える」「その機能を作る」「その変更を含んだリリースをする」という一連の流れを前提としています。つまり「作る速度を上げる」という話では、まったく足らないということです。

そこで問題になるのが「儲かる機能を考える」や「その変更を含んだリリースをする」といった部分のプロセスです。

「儲かる機能を考える」の代表的なプロセスは稟議であり「事業部門が儲かる機能を企画して、見積をとって、稟議書を書いて、多層的にROIをチェックされ、なんか指摘に対応し、開発ベンダーを計画書を書かせ、それを精査して、契約を取り交わす」ということをになっています。普通に1ヶ月かかったりします。遅い、遅すぎる。

「その変更を含んだリリースをする」の代表的なプロセスやISMSなどに従った運用プロセスであり「変更を説明する資料を作り、それが安全な変更であることを証明する資料を作り、いろいろなテスト結果を説明し、リリース要員を手配してスケジュールを確定し、多層的に承認を取って、リリース資産を作成して登録し、それをしずしずと本番環境に転送し、サーバ停止しますと掲示を出して、本番環境を1つ止めちゃアップデートし、全部ができたらテストをして、問題なかったら掲示を外してアクセスを許可する」ということになっています。普通に1ヶ月かかったりします。遅い、遅すぎる。

いずれも現在のルールをすぐに変えることはできないでしょう。でも、なんとかしないとスピードが上がらないことも事実です。なんとかするように企画部門と運用部門にも頭をひねってもらう必要があります。

追記:ルールを変えられないなら「リリース内容も決まっていないけど3ヶ月先のリリース日を先に決めて、締め切り駆動でプロセスを進める」というのが推奨になります。

エンジニアをチームでおさえる

良いエンジニアをチームでおさえましょう。少なくとも1年間はチームを維持することを前提にすべきです。チームのサイズは4-8名程度が良いでしょう。ざっくり単価100万だとするなら、年間で5000万円~1億円ぐらいは払うつもりがあるべきです。もちろん、1つのサービスだけで維持できないこともあるでしょうから、その場合は複数のサービスを管理してもらってもよいです。

なお、エンジニアを外部調達に頼る場合には準委任問題が出てきます。出てきますが、なんとかするしかありません。会社同士の関係が良好であれば請負契約(+変更管理)でも対応できます。内製化もよい判断でしょう。ただ、経験者は必要です。最初は外部メンバーに入ってもらい、段階的に内製化を促進していきます。

分割に備えてプラットフォームを整備する

実際にサービス側のチームとは別にプラットフォーム側のチームが必要になります。システムを分割していこうとする場合、多くのサービスは同じような課題にぶつかります。そういったものはプラットフォームとして提供(あるいは外部のPaaSを採用)することになります。代表的なのはSSOとログです。

1つのシステムだったものを2つに割る場合、それらの2つの間で認証情報を共有する仕組みが必要になります。OAuthのように認証画面から丸投げできる機能を構築してもいいですが、そこまで不要であれば認証情報をキャッシュする先を用意するだけでもよいでしょう。

2つに割れると、統合的にログ分析したくなります。そこでログエージェントをいれて、ローカルの吐かれているログを集約して検索可能にする仕組みがあると便利です。サービス間でAPI連携するならトランザクションIDを発行してログに載せるのも有効です。

プラットフォームを整備するチームは個別のサービス管理するチームとは別に用意しましょう。目的が異なるため、同一にするとサービス管理チーム側にオーバーヘッドがかかり、本来の生産性が測りにくくなるからです。

僕はプラットフォームまで含めた全体配置を考えるのを「大きなアーキテクチャ」と呼び、個別のサービス内の構造や構成を考えるのを「小さなアーキテクチャ」と呼びます。大きなアーキテクチャはプラットフォームチームの管轄であり、小さなアーキテクチャはサービス管理チームの主管です。標準化すべきはプラットフォームへのアクセスインターフェースだけにすべきで、各サービスのフレームワークではありません(プラットフォームを利用するためのクライアントライブラリとかはいいです)。

Agile、Cloud、DevOps、Microservices

マイクロサービスというのは「アジャイルを機能させるための技術的な基盤」であると言えます。2001年のアジャイルソフトウェア開発宣言から、我々はITサービスの提供サイクルを最適化しようと努力をしてきました。2006年のクラウドの登場により、インフラ構成やミドルウェア構成をコード化できるようになり、DevOpsムーブメントは運用機能を自動化し、コードによってオペレーターを不要にしていくようにしていました。結果として、管理ノードの増加に耐えられるようになりMicroservices的な仕組みが実現できるようになったのです。

マイクロサービス化というのはアジャイルソフトウェア開発宣言からの16年間を一気に学ぶ、ということです。いろんなものをすっとばして「サービス分割すりゃいいんでしょ」じゃないんです。マネジメント論と、それを実現するアーキテクチャ論であることをきちんと理解しておくべきでしょう。

明日から取り組め。できないなら、一生できない

マイクロサービス化は明日から取り組めます。ウォーターフォール型で「次回の再構築はマイクロサービスで」ではありません。そんなの絶対にうまくいきません。ちょっとづつ取り組みましょう。

取組みの開始はシステム分析でもビジネス部門の啓蒙でも経営層の説得でもいいです(大抵の場合は経営層から下りてきている話でしょうが)。結局、上記に書いたような様々な変更を行う際に障害になるものを取り除かなくはなりません。その障害を「再構築のタイミングで全部変える」というのはムリです。絶対にムリ。結局、既存のしがらみから抜け出せず、中途半端な理想論と技術論の結果、意味もなくサービスが分割されて、制約ばかりが増えて再構築自体が意味が無かったことになります。

最初に書いたとおり、まずは「儲かる機能を見つけて、分離する」ということをしましょう。そして、それをやるための障害を少しずつ乗り越えていくのです。そうやって3年もやれば良い感じになってきます。そのぐらいかかりますが、再構築で3年使うよりも、よっぽどマシな結果が得られるでしょう。

まとめ

最近、マイクロサービス化のご相談をいただくことがありますが、僕は技術的な実現手段はなんでもいいと思っています。AWSでもAzureでもオンプレでも。大事なのは会社の戦略プロダクトとしてITサービスを捉えてもらい、会社の営みとして持続的にITサービスの提供を行うようにしていくことです。これが僕の考えるマイクロサービス化です。

マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017

2017年月31日開催されたAWS Dev Day Tokyo 2017で「〜マイクロサービスを設計する全ての開発者に送る〜クラウド時代のマイクロサービス設計徹底解説!」という講演をしました。

f:id:arclamp:20170601101415p:plain

諸般の事情でタイトルは煽り気味ですが、40分しかないのに徹底解説というのもあれなので僕としては「マイクロサービス化設計入門 」ぐらいの雰囲気です。マイクロサービス化にむけて設計をする場合に気にすべき点について整理をしています。資料はこちら。

巨大なシステムであってもマイクロサービス化によって柔軟な変更が可能になります。ただし、既存のモノリシックなシステムから品質方針の変更が必要になります。

モノリシック

  • 単一システム内で不整合を発生させない
  • 障害を発生させない

マイクロサービス

  • 複数サービス間で不整合が発生する前提で頻度やリカバリ方式を検討する
  • 障害が発生しても影響を一部に抑えてシステム全体をダウンさせない

講演後のQAでも、ここらへんの進め方について「ビジネス部門に不整合発生をどうやって納得してもらうか」という質問をいただきました。

回答としては「サービス分割自体は適切に検討した上で、サービス間の不整合の発生を前提として、その『発生回数を減らす』『リカバリを自動化する』といった方式についてコストを提示していくしかない」になります。サービスを分割する以上、技術的限界もあって完全に不整合を排除することはできません。この割り切りがうまくできるほどマイクロサービス化したメリットが高くなります。

何かを得れば、何かを失う。
そして何ものをも失わずに次のものを手に入れることはできない。

とは小説家 開高健の名言ですが、まさにその通りなのです。

ここら辺を掘り下げる話も、どこかでしてみたいですね。

2017/6/15追記。動画が公開されました。