◯アーキテクチャ設計の戦略

ここからは、どういった戦略を持ってアーキテクチャを設計すべきかについてお話します。

Cloud Adoption Frameworkの一つに、5Rプランというものがあります。

リホスト、リファクター、リアーキテクト、リビルド、リプレイス。

それぞれの頭文字のRを取って5Rと呼びます。

リホストしながらリファクターする。あるいはリファクターからちゃんとリアーキテクトに持っていくなど、色んなシナリオがありますが、そのシナリオをこの5Rプランから作っていく。

ただ、どのシナリオであろうと、最小構成のAzure管理システムを最初に作るべきです。

それも用意されていまして、これがCAF（Cloud Adoption Framework）基盤ブループリントです。

ブループリントは様々なテンプレートではあるものの、このCAF基盤ブループリントはAzureのランディングゾーン、いわゆるサブスクリプション全体を管理する最小構成が入っているんですね。

この中にガバナンス、管理を継続的にできるような運用を入れる、それがDevOpsなのです。

こういう風に、既に用意されているツールやテンプレートを上手く使いながら自分たちのビジネス展開について考えるわけです。

◯スクラムの5つの価値基準

Cloud Adoption Frameworkにははっきりとは書かれてませんが、一応私の知見も含めてお話します。

アジャイルやる時にはスクラムの話になります。

ここでスクラムでの価値基準があります。

スクラムを活用して良い結果を生むには「スクラムの5つの価値基準」を取り入れていく必要があって、これが非常に重要です。

確約：それぞれの人がゴールの達成に全力を尽くすことを確約する

勇気：正しいことをする勇気を持ち、困難な問題に取り組む

集中：全員がスプリントでの作業やゴールの達成に集中する

公開：すべての仕事や問題を公開することに合意する

尊敬：お互いを能力ある個人として尊敬する

これらの価値基準をチームの中に取り入れる。逆にこれらの価値基準からずれたことはスクラム内ではやらない。そして良い方向に向かって行けるよう常に修正していく。

これが継続的改善だと思います。

あとはスクラムを構成するプロダクトオーナー、開発チーム、スクラムマスターの役割もあります。

この3つの役割を経営の中に取り込み、「ピザ2枚法則」ではありませんが、すごくコンパクトなチームで経営の意思決定を下すようなやり方も、最近増えてきています。

なので、この3つの役割については技術者に限らず、意思決定者の方も理解するといいと思います。

特にスクラムマスターですね。

スクラムマスターには「スクラムが上手くいくようにする」という役割があり、その中で論理的解決していく役割になります。

スクラムは自己組織化したチームを信頼することで、不確実性や変更のある環境で製品開発を行うわけですが、要は確実なロードマップはなく、不確実性や変更があるのです。

従って、成果が継続的にアウトプットできるためには、メンバーのリーダーシップを引き出すのが重要になります。

この考え方、アジャイルかどうか実はあまり関係ないかなと思っています。

ウォータフォールも同じで、ヒエラルキーがあろうがなかろうが、チームの安定こそがプロジェクト成功への近道であることに変わりありません。

リーンソフトウェアの原則を忠実に守り、組織内の円滑なコミュニケーションを促していくこと。

スクラムは単に仕組み作りだけでは上手くいかないのです。

そして、そのコミュニケーションの中で最も重要なのが情報です。

このプロジェクトの目的とは何か。価値とは何か。このプロダクトが解決する課題は何か。

これは一貫してチーム内に共有され、浸透されていることが重要で、これを担うのがテックリードであり、ここで活用するのがCloud Adoption Frameworkなのです。

◯組織あり方が設計に影響を及ぼす

最後にコンウェイの法則というのがあります。知っている方もいらっしゃると思います。

これはメルヴィン・コンウェイさんという方が提唱した法則で、ヒエラルキーが強い組織が作るシステムはモノリシックなシステムになりやすいというものです。

要は組織構造がそのまま設計に反映され、実装されてしまう。

クラウドネイティブな構成、いわゆる疎結合なマイクロサービスは、ヒエラルキーが強い組織では難しいんですね。

これもぜひ知っておいた方がいいかなと思います。

それでは、今回は以上になります。（おわり）

☆本記事はオルターブースYouTubeチャンネルの配信動画をもとに再構成しています。

☆配信動画の本編をご覧になりたい方はこちらから！（小島発表パート 24:05～41:46）