エンタープライズアジャイルとNoOpsとマイクロサービス
最近、以下の2つの講演をしました（資料は記事末に貼っておきます）。
「エンタープライズアジャイルでチームが超えるべきこと」（2018/10/17） エンタープライズアジャイル勉強会 2018年10月セミナー
「MicroserviceでのNoOps戦略」（2018/10/26）NoOps Japan Community NoOps Meetup Tokyo #2
アジャイルとNoOps（DevOps）というのは実装を挟む両輪なので、話は違えど、目的は同じです。
現在のITサービス（特にSoE/mode2）において大事なことは「素早く届け、素早くフィードバックを反映し、また届ける」というサイクルです。これを高速にしていくためには
- アジャイルのような短期タイムボックス型でのタスク管理
- NoOps/DevOpsのような運用作業の事業化
という両輪がなくてはならないものでしょう。
そして、これらの概念を統合するのは「マイクロサービス」という言葉です。言葉が拡がるきっかけとなった記事「Microservices」ではマイクロサービスを示す9個の特徴が挙げられていますが、いかの3つの観点が含まれていることが分かります。
- サービス分割、API連携、分散データ管理、進化的設計など実装面
- チーム構成、プロダクト思考、脱中央集権などの組織面
- インフラ自動化、対障害設計などの運用自動化面
マイクロサービスについては、来週11/2はAWS Dev Day Tokyo 2018でマイクロサービス化デザインパターンという話をさせていただきます。マイクロサービスはいきなり完成形でシステムができあがるものではなく段階的に「マイクロサービスになっていく」ものです。なので「マイクロサービス"化"」という言葉を使っています。
もちろん、全体の土台となるのはアーキテクチャ設計です（僕の中心はここ）。今月10/12には翔泳社でアーキテクチャ設計実践講座（10/12）というワークショップ型のセミナーを開催しました。これは、また来年早々に開催する予定なので日程が決まればお伝えします。
相変わらず、色々、散らかっているようで繋がった話をしているつもりなのでお付き合い＆フィードバックいただけるとうれしいです。
あ、僕が会長を務めさせていただいている日本Javaユーザーグループの1000人規模イベントJJUG CCC 2018 Fallは12/15（土）です！そろそろ、募集が始まるはず。
エンタープライズアジャイルの成長過程について
2018年7月23日におこなわれた要求開発アライアンス2018年7月定例会で「エンタープライズアジャイルにおける要求探索の勘所」という話をさせていただきました。資料は以下。
ウォーターフォール開発の環境が整備されている中で取組むアジャイル
のことです。で、こういう現場の支援、あるいは自社で開発していると以下のような段階で成長していっているなぁと感じています。
1.PO本人がスコープ管理をちゃんとできるようになる
2.企画組織内でPOがリードタイムの管理をちゃんとできるようになる
3.他部署ともルールをきめてプロセスの共有をちゃんとできるようになる
というわけで、そういったところを資料にしてあります。
まだまだ、エンタープライズアジャイルには辛いところも多いですし、進化の過程だなと思うところもたくさんあります。しかし、こういった取組みを深めていってこそ、日本のシステム開発の現場がまともになっていくものだと信じています。ぜｈ、フィードバックなどくださいませ。
アジャイルにおける事前合意について
昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます！。
ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか？」ということを書きたいと思います。
アジャイルは最初に全てのCDSを決めない
まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS（品質/コスト/期日/スコープ）ですが、Q（品質）というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。
ウォーターフォール型開発というのは、
- 「スコープは最初に確定」し、
- 「コストや期日はスコープを達成するために必要な分を最初に設定」し、
- 必要なリソース（人員など）を調達する
というシンプルな考え方です。そして、スコープを決めるために要件定義工程を実施します。この手法の問題点は、規模が大きくなるほどコストや期日の予測が難しくなる、開発期間中にスコープを変更したくなる、リリース間近にならないと品質の確認ができない、といった点です。
- とりあえず要員を固定化し、
- 「スコープは定期的に見直す」ことで、
- 「期日はリリースできるようになったらリリースする」ことになり、
- 「コストは人員を維持した期間分だけかかる」（ゼロにしたければ開発を止めればよい）
となります。つまり、アジャイルは「要員の固定化による調達オーバーヘッドの排除」「スコープの定期的な見直し」という仕組みによって、CDSを開発期間中に調整可能にしてしました。
整理すると「スコープを決めたら最適なコストと期間で作る（終わるまでスコープは変更はしないでくれ）」なのか「コストが固定的にかかるが、定期的にならスコープを変えていいし、リリースはなる早でやる」なのか、です。
（だから内製化してコストを人件費で処理できるとアジャイルのメリットが際立つことになります。SIerによる準委任的なアジャイルが顧客から見て投資対効果が見えにくくなる原因でもありますね）
チームはどこを他者と合意し、どこを自分たちで決定するのか
アジャイル開発プロセスは「最初に全部を決めなくてよい」のですが、仕事としては「最初に何も決めなくてよい」とはなりません。
特にステークホルダー（利害関係者）とは、ある程度の合意を事前にした上で開発を進める、というのが一般的です。
例えば顧客やオーナーとであれば、大まかな目標と期日、そしてコストの合意をするでしょう。これら全てを「やってみないと分かりません」というのは普通は許されないのです。
あるいは関連部署との業務手続きや関連システムとの連携、運用部門への引き継ぎなどもリリース間近になって「こうしてください」とはいきません。ある程度は事前的に合意をし、検討するべきは検討し、用意すべきものは用意するというタスクを起こしていきます。
他にもマーケ部門や広報部門とデザインルールやブランドイメージへの準拠、マーケ部門とはネタとしての機能合意などもあるかもしれません。これも勝手に決めることはできません。
ウォーターフォールは「最初に（決められないことでも）合意するしかない（から無理が来る）」ことで嫌われていたのですが、アジャイルは逆に「手法としては最初に全部決めなくていいが、仕事としては最初にそれなりに合意しないと後で面倒」という状況になります。これはシステム開発の規模や企業の規模に関わりません。
（というか、そもそも仕事とはそういうものですけども）
つまり、チームにとって「合意相手と合意すべきところ」と「チームが自ら決定するところ」があり、それらをきちんと整理して分別し、適切に管理することが必要になります。
事前合意は厄介なもの
そもそもアジャイルに限らず、チームにとって「利害関係者と合意する」というのは厄介な作業です。利害関係者というのはそれぞれの分野の専門家であり、その分野における常識や規則に縛られています。つまり、話が合わないのが普通です。とはいえ、多様な専門家の集まりが組織的な強さを発揮すれば高い成果に結びつくわけで互いに意見をぶつけあって、よりよい合意を目指すことが重要です。
もちろん、チームの状況によっても難易度は異なります。極端な例とすれば経営者がチーム内にいて、しかも自己資金でやっているITベンチャーなら一切の事前合意は不要かもしれません。逆にエンタープライズになれば事前合意を強く求められ、結局はウォーターフォール的に進めるしかないこともあります。
さて、特にエンタープライズのアジャイル開発においては1.ビジネスのコンセプトと、2.他システム連携の事前合意に問題が生じることが多いです。
どの機能が儲けにつながるのか？
ビジネスのコンセプト、というのはシステムのコンセプトとは違います。ビジネスのコンセプトとは端的に言うと「いかにして儲けるか」、そして「どの機能があると儲かるのか」ということです。
アジャイル型開発では「優先度の高い機能から作る（そして定期的に優先度を見直す）」のですが、優先度を判断する上で重要なのが「その機能があれば儲かるのか？」ということです。
ウォーターフォールの場合は最初に全てを決める必要があるので「全ての機能を抜け漏れなく洗い出す」ことが優先されます。アジャイルであれば「必要になったら、なる早で作る」という安心感があるのですが、ウォーターフォールでは「最初に言わないと、いつ出来るかわからない（少なくとも最初のリリース後）」という不安もあり、網羅性が重視されます。
結果として「その機能が儲けにつながるのか？」というような判断よりは「使う可能性があるなら作ることにしておこう」となりがちです。
例えば運営者が使う管理画面のようなものは、最初はなるてもなんとかなることもあります（ここは儲かる儲からないではなく、業務部門とのせめぎ合いもあるでしょうが）。
ウォーターフォールは「最初に作るべき機能を定める」こともあり「システム開発をする」という感覚に陥りがちです。一方のアジャイルは常に「ビジネス的に優先度の高いものから作る」ことを考えるので「ビジネス開発をする」という感覚が必要になります。
この違いを共有するためにも「ビジネスのコンセプトを事前合意する」は重要です。表現としてはビジネスモデルキャンバス、ユーザーエクペリエンスマップ、より詳細にはユーザーストーリーのようなものがあげられます。
大事なのはビジネスのコンセプトからシステムの機能まで線を引き、その機能の必要性をビジネスの観点から考えることです。
いかに基幹と繋ぐか
次がシステム間連携です。特にエンタープライズなアジャイル開発では、SoRな基幹系システムと連携することが重要になります。
企業がアジャイルでシステム開発を判断する場合、多くは新たなサービスを作り、既存顧客からの新たな売上獲得を目指します。既存の営業チャネルや取引チャネルを活用しつつ、試行錯誤の部分を「じゃ、アジャイルで」となります。
このような案件では既存顧客のデータ（アカウント、取引履歴、支払い、請求など）との連携が重要です。この連携があることで顧客にとって支払い先を集約するメリットが生まれます。
システム連携の難しさは技術論ではなく、ドメイン間にはインピーダンスミスマッチに起因します。既存サービスを成立させるとために作られてきたモデルは、必ずしも新しいサービスとは整合しません。この場合、どのようにミスマッチを解決するかは事前に考える必要があります。
ミスマッチを解決する1つの方法は「既存システムが新しいサービスのために新たな連携を開発する」ということですが、大抵の場合は時間もコストも合いません。よって、ミスマッチがある既存の連携を流用し、新しいサービス側がなんとかすることになります。
もちろん、最初からきちんとしたシステム連携をする必要はなく、手動でも問題はありません。でも、概念がズレていることは事前に理解しておく必要があります。この事前合意を怠るとシステムが破綻するか、それを手動でリカバリする業務が破綻します。
事前合意するためには、やはり、ある程度は踏み込んで既存システムの概念やコンセプトを理解した上で、連携項目1つ1つを丁寧に検証する必要があります。
アジャイルでやっていると、どうしても表側の機能開発に気を取られ後回しにしがちですが、システム連携の合意が遅くなるほど必ず手戻りが増えてしまいます。この点にも注意が必要です。
アジャイルを機能させる外枠について
2017/12/15のエンタープライズアジャイル勉強会 2017年12月セミナーの企画は僕がやらせてもらいました。
テーマは「アジャイルを機能させる外枠」とし、アジャイルチームがうまく機能するために、あえてチームの外側で解決した方がいいこと、を整理してみたいと思いました。
アジャイルチームというのは、実際にモノを作り、サービスを動かし、ユーザーからのフィードバックを付けて改善を行っていくことが目的です。その目的を達成するためにはアジャイルチームの外枠をちゃんとする必要性があると考えています。
アジャイルを機能させる2つの外枠
1つ目の外枠は「何を作るべきか」という観点。チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん（@papanda）にお願いしました。市谷さんの講演は「アジャイル開発はWhyから始まる」というタイトルで、機能開発の前にWhyとしての仮説検証を行うことで開発が右往左往しなくなる、という話でした。「顧客開発をプロダクト開発よりも極端に優先するとチームが右往左往する」という指摘はその通りですね。
2つ目の外枠は「どう作るべきか」という観点。ただし、これはプロダクト本体の作り方ではなく、プロダクトの外側と連携する部分の作り方の話です。これは僕が「アジャイルを支えるアーキテクチャ設計とは」というタイトルで、アーキテクチャ設計にも、プロダクト本体の作り方を考える「小さなアーキテクチャ」と、プロダクトの外側の作り方を考える「大きなアーキテクチャ」という紹介をしました（参照：大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp）
というわけで、アジャイルチームを機能させる外枠は「仮説検証というビジネスの話」と「大きなアーキテクチャという技術の話」があるのでは、という整理をさせてもらいました。だいぶ振り幅があるテーマになったな、と思う一方で、けっこう実感もあります。アジャイルを導入しようとしている人の悩みってプロダクトオーナーかアーキテクトに落ちてくる気がします。
見積もれないことをチームに持ち込まない
なお、これは「チーム内にいるエンジニアは外側のことは考えなくていい」と言っているわけではありません。もちろん、外側のことを考えてもいいし、場合によっては解決に携わってもいいのですが、ただ、それはチームの作業としてカウントすべきではないと考えています。そうしないとアジャイルプロセスがうまく回らないからです。
アジャイルプロセスをうまく回すコツは「チームが見積れないようなバックログを積まない」ことです。スプリントプランニングにおいて「曖昧で見積もりができない」「リスクが大きすぎてタスク化できない」というようなことは避けるべきです。そういうものを無理やり見積もっても「勘と経験と度胸（KKD）」になってしまい、生産性を計測することができなくなります。そうするとチームのベロシティが把握できず、結局、安定したチーム運営ができなくなります。アジャイルは期間とリソースを安定させることで開発速度を安定させ、それによって将来における変更対応を担保しています。この根幹が揺らいでしまうと、プロダクトオーナーと開発チームの信頼が崩れてしまうのです。
いまだにアジャイルは「適当だ」という認識の方がいるかもしれませんが、実際は逆で、アジャイルでは適当さが許されなくなります。ウォーターフォールではバッファと呼んで規模やスケジュールに紛れ込ませて適当にやってきたことを、アジャイルでは明確にしないとプロセスがうまく回りません。
そもそも、外枠の話はウォーターフォールでも一緒、ですよね。過去、プロセスに紛れて適当にやってきたがために、明確に議論できなくなっているだけなのでしょう。結局、エンジニアに良い仕事をしてもらうためには「何をすべきか」「制約がなにか」を先に明確にしておいたほうがよい、という当たり前の結論になっただけかもしれません。
最後に
呼びかけに応じて参加してくれた市谷さんに感謝します。付き合いは長いですが、こうやって2人で縦並びで話をするのは初めてな気がします。たぶん。全然違う話を1つの線でつなげられるというのは、とても刺激的ですね。これからもよろしく。
大きなアーキテクチャ設計と小さなアーキテクチャ設計
2017/12/15（金）にエンタープライズアジャイル勉強会2017年12月セミナーで「アジャイル開発を支えるアーキテクチャ設計とは」という話をしました。資料は以下から。
僕の話したかったのは「アーキテクチャ設計といっても『大きなアーキテクチャ設計』と『小さなアーキテクチャ設計』というレベルがあり、後者はチーム内で解決すべきだが、前者はチーム外で解決すべきだ」ということです。
大きなアーキテクチャ設計：システム間連携のレベル→アジャイルチームの外で実施
小さなアーキテクチャ設計：システム内連携のレベル→アジャイルチームの中で実施
なぜ分けるのか、というと、それぞれのレベルで求められる性能も可用性も保守性も違うからです。
小さなアーキテクチャ設計は「チームが好きにすればいい」わけですが、大きなアーキテクチャ設計は「チームをまたがって企業内でそれなりに最適化されるべき」です。
よって、「チームがアジャイルに、自治的に小さなアーキテクチャ設計を進められるようにするためには、大きなアーキテクチャ設計をチームの外に意図的に出すべきである」という考え方になります。これを混ぜたまま進めようとすると、
- 大きなアーキテクチャ設計についてチーム内の部分最適で判断したために余計な問題やコストが発生した
- 小さなアーキテクチャ設計に関わることなのにチーム外が全社最適で判断しようとしてチームが動けなくなってしまった
というようなことが発生します。特にアジャイルチームではチームが小さいがゆえに、大きなアーキテクチャ設計に巻き込まれるとリソース不足に陥ったり、スケジュールの遅延が発生し、なによりもモチベーションを著しく下げることになります。「なんでもいいから早く結論を出してよ。それに合わせてサービスの実現度はPOと話して決めるからさ」みたいな。
一方で、このレベル感を混乱させるのがマイクロサービスアーキテクチャ（MSA）です。MSAでは「システムを構成するコンポーネント（＝マイクロサービス）同士をネットワーク越しに連携させる」ことが主流になっています。一方で、昔から「システム同士をネットワーク越しに連携させる」というのは一般的です。
だからこそ、その連携が「システム同士の連携」なのか「マイクロサービス同士の連携」の差というのが分かりくくなっている気がしています。もちろん、あるサービスにとって、それが「システムからの連携」なのか「システム内のコンポーネントからの連携」なのかは見分けがつきませんし、付ける必要もありません。これまでのシステム間連携だって同じことですから。
MSAは、これまで大きなアーキテクチャ設計でしか語られていなかったシステム連携を、小さなアーキテクチャ設計に持ち込みました。ネットワーク連携の様々なオーバーヘッドを許容できるだけの技術の発展があり、その変化を許容しやすくなるメリットが享受できるようになったからです。
というわけで、MSA環境では大きなアーキテクチャと小さなアーキテクチャは見分けにくいのですが、見分けないといけません。繰り返しますが、それは技術論ではなく求められる性能も可用性も保守性が違うから、です。
MSAでは前者をプラットフォームよび、後者をマイクロサービスと呼ぶことで分離していくのでしょうね。プラットフォームチームはアジャイルチームから分離すべき、です。
「大きなアーキテクチャと小さなアーキテクチャ」はエンタープライズ界隈でアジャイルに取り組もうとするときに問題になりがち、という実感のうえで提唱しました。まだまだ粗い整理なので議論の余地もあります。
エンタープライズ界隈でも、改めてアーキテクチャ設計が重要性が高まっているからこそ、無用な混乱を避け、各エンジニアが的確な活動ができる助力になればと思います。
MSA化レベル定義 - 低レベルなマイクロサービスはただのファイル連携と見分けがつかない
「低レベルなマイクロサービスアーキテクチャ（MSA）」というのは「ただの基幹システムとのファイル連携」でいいんだよ、という話。
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つを考えてみました。
MSA化レベル定義
そして、レベル感は以下のようなものを考えています。レベル上げのポイントや取り組むべき具体的な作業については別途。
| Lv | 疎結合化 | 自動化 | 基盤化 | 自律化 |
|---|---|---|---|---|
| 0 | 完全に統合されたシステム | ビルドは職人芸、コードは個別管理 | 物理インフラ | 厳格なトップダウン型 |
| 1 | 大きなシステム、ファイル連携やデータ共有 | ビルドはコマンド化、CVS/SVN | インフラの仮想化 | ウォーターフォール、標準化強め |
| 2 | 大きめなサービス、キューによる非同期連携 | ビルドパイプライン、Git/ブランチ戦略 | 認証/ログなどの基盤化、パブリックPaaSの利用 | アジャイル風、標準化弱め |
| 3 | 適度なサービス粒度、データ分離 | ブルーグリーンデプロイ | 様々な汎用基盤サービスの活用 | 複数のアジャイルチーム、個別最適 |
| 4 | 小さなサービス、非同期ストリーム、イベントソーシング | コンテナオーケストレーション | 様々な独自基盤サービス | たくさんのアジャイルチーム |
| 5 | かなり小さなサービス、独自プロトコル連携 | 数万ノード、数百回リリース | 自作基盤をOSS化 | すごくたくさんのアジャイルチーム |
いかがでしょうか？これも軸にあるべきだとか、このレベルにはこういうものが必要だ、とかあれば、ぜひ教えてください。
