Amazon Web Services ブログ
システム開発のモダナイズ、パート2 – 最初の一歩
前回の投稿では、モダンアプリケーションを分析し、それを構築するために使用される典型的なアプローチについて提示しました。
- スコープを縮小する
- 仕事に適したツールを選択する
- 差別化につながらない部分をオフロードする
- ビルディングブロックを接続する
- すべてを自動化する
AWS は、仕事に適したツールの選択、差別化につながらない作業のオフロード、ビルディングブロックの接続、すべての自動化を容易にするサービスを構築し続けています。マイクロサービスやAWS Lambda などのサーバーレスサービスは、変更のスコープを縮小することの助けにはなりますが、完全に「高頻度の組織」（high-frequency organization）となるにはビジネス面での変更が必要です。
プロジェクトではなく、製品
多くの企業はいまだにプロジェクトを立ち上げ、実行することで、ソフトウェア・デリバリーに取り組んでいます。これらのプロジェクトは、発足時に目的、チーム、スケジュール、予算、およびスコープを設定します。プロジェクトは開始と終了の期日が決められます。多くの場合、プロジェクトの完了時にチームが解散すると共に知識も分散し、システムの運用と維持管理はプロジェクトの成果物を長期的に担当(所有)するチームに委ねられます。
モダンなアプローチでは、そのようなやり方ではなく、長期的な「ツーピザ・チーム」（2つのピザを食べるのに十分な小さなチーム、通常は5〜10人）を形成し、そのチームに製品/サービス/機能の完全な所有権を与える方法をとります。Cox Automotiveでは、ツー・ピザ・チームを固定されたタイムライン、たとえば2週間のスプリントでも実行しました。この様な体制で組織し、計画し、デリバリーすることで、私たちは非常に多くのことを成し遂げました。このやり方の中で、我々はいくつかの変数(可変的な条件)を取り除き、定数化(固定の条件)しました。例えば、チームの大きさ、タスクの内容、タスクの期限、そして、様々な方法を使い、設定した時間枠（2週間）で取り組むことができるタスクのサイズを定数化しました。タスク完了の定義がプロダクション環境にリリースすることを意味する場合、機能をオフにする形にしてでも、調整して、すべてのスプリントで価値が提供できるようにしました。今、あなたは「彼は制約を守るために、すべてを小さくしただけだ。それは、良いやり方だろうか、これがどのように価値を高めることにつながるのか？」と、考えているかもしれません。 さて、もう一歩進めましょう。
この大きく固定化された環境には、価値提供のペースと量を改善するために操作できる変数が2つ残っています。ツー・ピザ・チームの数と、私たちが何に取り組むかの選択です。このモデルでは、上手に優先順位を付けることを強いられます。これは、私の経験では、ほとんどの企業にとって難しい作業です。しかし、私はこれが、ビジネスにおいて最も重要なことだと考えています。良いアイデアの花を咲かせられる様に、悪いアイデアを取り除く割合を上げる事が。優先順位づけの改善に集中すると、いくつかの重要な要素を検討する必要が出てきます。下記の様な問いを良く考えます。
- これがお客様にとって価値があるか、どうやったらわかりますか？
- これよりそれが、なぜ重要なのですか？
- これにより達成できる価値は、それと比べてどれくらいですか？
- これが十分に良くなったと、どうやったら分かりますか？
データがあなたを救ってくれます。先ほど説明した条件を固定化した環境は、実験に最適です。スプリントの1〜2回を使ってアイデアをテストするのは簡単で比較的低コストで行えます。仮説となるアイデアがある場合は、仮説を成立または不成立と確定させるためのデータを収集します。その仮説が顧客にとって価値があるかどうかを、データが教えてくれるはずです。もし価値があるなら、その価値がどれくらいか確認することができるはずです。
データ収集が日常業務の一部になると、チームは成果指向の開発にフォーカスする様になります。アジャイルで反復的な開発手法は、対応すべき範囲や解決策は事前には分からず、次第に明らかになるという考えに基づいています。成果指向の開発により、求める成果から見た解決すべき問題に対して、集中して取り組める様になります。
課題の例を考えてみましょう。家族連れの旅行者として、安全で親しみやすく、信頼性が高く、費用対効果の高い、清潔な移動手段を必要としているとします。この課題からUberかLyftがすぐに思い浮かびます。しかし、それらが存在する以前では、主な解決策は、自分の車を運転するか、車を借りるか、または車のサービスに追加料金を支払うことでした。私の経験では、タクシーでは提供されるエリアが限られているからです。
この場合に、チームがフォーカスできる結果には次の様なものがあるでしょう。リピートユーザーの数/割合、複数の都市で利用しているユーザーの数/割合、清潔さに対するユーザーの満足度、オペレーターに対するユーザー満足度、および数/ユーザーが交通手段を取得するために失敗または長時間待つ回数の割合、など。これらは対応すべき範囲や解決策を表すものではなく、単に課題に対して、問題が解決されたかどうか示す主要な指標に測定値を設定しているだけです。結果の値が定義したレベルで満たされ、顧客がその方法に価値を感じることで、課題が十分に解決されたかどうかを知ることができます。
マイクロサービス
ここで、デリバリー環境とマイクロサービスを組み合わせて考えてみましょう。マイクロサービスは、単独でスケーラブルでデプロイ可能な機能単位で、小規模なチームが所有し、運用できます。ツー・ピザ・チームで成功する為にマイクロサービスは必須ではありませんが、アーキテクチャを進化させて、データとデータコンシューマー間、またはビジネスロジック同士でAPIという強固な規定を作成することで、さらなる自律性と俊敏性をもたらすことができます。これらのマイクロサービスは、規定を維持する限り、利用者とは無関係に変更できます。変更セットが小さくなり、分離されることで、変更（及び、障害）の影響範囲が小さくなるため、デリバリは加速します。マイクロサービスは通常、独自のコードリポジトリ、配信パイプライン、監視と運用のサポートを備えています。つまり、チームは独自のタイムラインでマイクロサービスを進化させ、開発のイテレーションを回すことができます。多くの場合、チーム間の調整の必要性も少なくなります。これにより、チームはより迅速に動き、価値をより頻繁に提供することができます。
最初の一歩を踏み出す
ここまでで私が説明したアプローチは、ジャーニー（旅）です。プロジェクト方式から一直線に成果重視の開発に進める人はいません…もし居たとしても、私は聞いたことがありません！
最初のステップは非常に簡単です。分離することで、小規模なチームに所有権を与えられる製品/機能/サービスを特定します。難しいことですが、既存のスタッフからそのチームを結成し、アジャイル開発の手法を適用するために細かく調整します。2週間のサイクルで配信（本番環境にリリース）できるように、タスクを分解する方法を理解するには、時間がかかるでしょう。
並行して、優先順位付けという難しい作業も開始します。まもなく、彼らは製品/機能/サービスを所有し、固定されたタイムラインで業務を行う固定サイズのツー・ピザ・チームになります。タスクは小さく、2週間ごとに配信できるタスクの数は大体固定されており、あなたはタスクの優先度の判断を定期的に行っていることでしょう。
おめでとうございます！ あなたのジャーニーは正式に始まりました。私が2012年にDealer.comで初めてこのジャーニーを開始した時（その後に、Cox Automotive で Scaled Agile Framework を稼働させた時も）、経験豊富なアジャイル開発トランスフォーメーションのリーダーが側に居て、私と私のチームがサーヴァントリーダーになるのを助けてくれました。あなたにも、ジャーニーのガイドとなってくれるパートナーを見つけることをおすすめします。
モダンアプリケーションは、人、プロセス、テクノロジーに対する最新のアプローチを活用します。AWS は、自動化のために設計された API を備えた幅広いサービスを提供しており、AWS は急速なペースでイノベーションを続けています。クラウドジャーニーとともにアジャイル開発プラクティスを実践することで、モダンアプリケーションを構築する際の人材やプロセスの部分に取り組むことができます。これは旅であることを思い出してください。終了日はありませんが、開始日はありますが、今すぐ始めましょう！
ブライアン・ランダーマン
エンタープライズストラテジスト & エバンジェリスト @ AWS
@bryanlanderman
brylando@amazon.com
著者について
ブライアン・ランダーマン
ブライアン・ランダーマン は 2019 年 2 月にエンタープライズストラテジストおよびエバンジェリストとして AWS に入社しました。この役割において、ブライアンは企業のエグゼクティブと協力して、クラウドがスピードと俊敏性を高めながら、より多くのリソースを顧客に捧げるのに役立つ方法についての経験と戦略を共有しています。AWS に入社する前は、ブライアンはコックスオートモーティブのCTO でした。
翻訳は Solutions Architect 多田が担当しました。原文はこちらです。