アジャイル・フルーエンシーモデルでアジャイルに技術的負債対策を組み込む
🐳この記事は 「ログラスサマーアドベントカレンダー2023」 の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス(スクラム、エクストリームプログラミング等)を併用していました。 その中で、 ...
https://zenn.dev/loglass/articles/cefa77e65aa6ce
※この記事はログラスEMの松岡がZennにて投稿した記事です。
🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。
こんにちは、ログラスの松岡です。
ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス(スクラム、エクストリームプログラミング等)を併用していました。
その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。
面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。
一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるというものが大項目として定義されている」という点です。技術的卓越性とは、技術的なスキルや専門知識が高度であり、大きな成果を上げている状態を指します。
私は、アジャイル文脈では価値への向き合い方やチームとしての働き方などの話題が多く、スクラムなどの手法でそこが体系化されているのに対して、技術的負債への対策や具体的な技術に関しては体系的に語られることが少ないことに不足感を持っていました。どこのチームでもそこには大きな課題を抱えているのに!(個人的主観です)
そこに対して、フルーエンシーモデルでは「価値に向き合う」ということと並列して 「技術的卓越性によるアジャイルの持続可能性」 を定義しており、さらに紐づくさまざまな技術的プラクティスが整理されています。「技術的負債を作ら"ない"」という後ろ向きな定義ではなく、「持続可能性を高める」という能動的な概念として定義し、具体策まで整理されているということがすごく価値が大きいと思っています。
(詳細は『ゾーン②「デリバリー」(技術的卓越性によりアジャイルの持続可能性を高める)』の節で紹介しています。)
また、それだけでは無く、もう一つ同列で 「市場に合わせた製品計画の最適化」 というプロダクトマネジメント要素も包含しています。(詳細は『ゾーン③「最適化」(市場を理解して製品計画を最適化する)』で紹介しています。)
モデル提唱者のDiana Larsen、James Shore曰く、彼女らがアジャイルのコンサルティングをして来た中で、多くの企業が抱える典型的パターンをモデルとして定義したとのことでした。ログラスでもプロダクト開発をする上で、全体感を持ってどこに課題があるのかを考えるのに役立てられています。
もう一つのポイントは、アジャイルによって成果を出すためには、開発チームだけでは限界があり、組織のサポートが必須である と、フルーエンシーモデルの中でも繰り返し書かれていることです。
なぜかというと、アジャイルのプラクティスを最大限活用するためには、時間的・金銭的投資、組織構造の変更、評価軸の変更などが必要になるためです。技術的投資や負債解消という意思決定も、大きなものになると個々のチームだけではなく組織としての決断がどうしても必要になります。
そのためには、一定以上の規模の組織では権限が必要になり、実際はマネージャーがその一端を担っていることが多いでしょう。
アジャイル文脈では時にマネージャー不要論が提起されることもある中で、この必要性が明示されているということはとても面白いと思っています。(もちろん、上記の必要なものが満たされれば「マネージャー」という手段でなくても良いでしょう)
この詳細は後半の「活用方法③」の説で紹介しています。
本記事では、フルーエンシーモデルの概要と、それに関連するプラクティスの一部を紹介、最後にモデルの活用方法を紹介します。
なお、原文を基にしながら、一部わかりやすいよう噛み砕きや、筆者による解釈が入っている部分があります。正式な記述は以下の原文をご覧ください。
出典:
AGILE FLUENCY PROJECT
martin fowler.comフルーエンシーモデルに関する紹介記事
アジャイル・フルーエンシーモデルは、アジャイルのアイデアを最大限に活用するためのモデルです。チームが現在位置を理解し、進化のロードマップを作成するのに役立ちます。
アジャイルチームは、学習するにつれて流暢さ(フルーエンシー)の 4 つの異なるゾーンを通過します。
引用元: https://www.agilefluency.org/model.php
図としては4つのゾーンが連続的につながっていますが、チームはその時点の課題に合わせて着手するゾーンを選ぶことができます。
流暢さとは「意識的な努力なしにスキルを発揮している状態」を示します。「当たり前にできている状態」と言ってもいいかもしれません。これは「チームの」特性であり、特定の個人がもつものではありません。
また、流暢さはチームメンバー全員がそのゾーンに関連するすべてのスキルを持っていることを意味するわけではありません。チームとして必要なスキルを持つ人材がいて、適切なタイミングでスキルを発揮できれば良いのです。
それでは、各ゾーンをそれぞれ紹介します。
フォーカスゾーンはアジャイルの基本である、ビジネスの結果に焦点を当てること、チームとして働くこと、オーナーシップを持つこと、について述べています
このゾーンに精通したチームは、チームの中核目的に開発を集中させ、最も価値のある機能を最初にリリースし、ビジネスニーズの変化に応じて方向を変えます。彼らは常に組織の最も価値のある優先事項に焦点を当てています。
フォーカスゾーンに精通したチームは、次のような特徴があります。
これを実現するために、主にスクラム、カンバン、およびエクストリーム プログラミング(非技術的な部分)からプラクティスが紹介されています。
代表的なものは、ホールチーム(チーム全体による)アプローチ、アジャイルな見積もりに基づく計画、ステークホルダーへのデモや信頼獲得、レトロスペクティブなどがあります。
詳細はボリュームが多くなるため、フォーカスゾーンのプラクティスをご参照ください。
アジャイルなチームはいつでも計画を変更することができます。しかし、多くのチームでは、これによりコードの品質が徐々に低下します。そのようなチームでは費用対効果の高い変更を加える能力を徐々に失っていきます。最終的には、作り直し、リアーキテクチャが必要になってしまうこともあります。
流暢な「デリバリー」を達成するチームは、技術的卓越性によってこの問題を防ぎ、技術的品質と開発生産性を高く維持します。アジャイルに価値を出し続けることを持続可能(サステイナブル)にするということです。
そのために、エクストリームプログラミング(技術的な部分)、DevOpsから、プラクティスが紹介されています。
代表的な物としては、コードの集団所有権、ペアプロ/モブプロ、継続的インテーグレーション、テスト駆動開発、インクリメンタルな設計、フィーチャーフラグ、進化的アーキテクチャ、インシデント分析…など非常に具体的な技術的プラクティスが詰まっています。
こちらも全量は多くなるので詳細はデリバリーゾーンのプラクティスのページをご覧ください。
「最適化」を流暢に行うチームは 製品計画と予算に責任を持ち、実験と学習を繰り返すことで、製品計画を最適化します。 市場をリードするソフトウェアを作成できるようになります。。
これには組織構造の変更が必要です。最適な計画を作成するには、ビジネスと製品の深い専門知識を持つ人々が常に注意を払う必要があり、これは製品と市場の専門家を開発チームにフルタイムで参加させることを意味します。また、これらのチームに製品の予算と計画に対する全責任を与えることも意味します。
そのために、デリバリーの基盤(スクラム、エクストリームプログラミングなど)から始めて、リーンソフトウェア開発、リーンスタートアップ、Beyond Budgeting(その時々の状況に合った財務目標を立てて短期的に見直していく経営管理モデル)などのプロダクト中心のプラクティスを活用します。
チームは、より大きな組織システムにおける自分の役割を理解し、そのシステムをより成功させるために積極的に取り組んでいます。
自分達のチームの目的は他のチームとどう一致するかを理解し、その戦略をより成功させるために積極的に取り組みます。また、組織内に専門的知識を意図的に広め、他のチームから学ぶ機会も求めます。
筆者(松岡)解釈になりますが、このゾーンは、「アジャイルのその先」に対する期待であり、「このゾーンがどのような形になるか完全に確信があるわけではありませんが、流暢なチームが提供できるメリットについて結論を引き出すのに十分な例を確認してきました。」という記述もあるので、具体的なプラクティスなどは定義されていません。
そのため、活用の上ではまず他の他3つのゾーンに集中してみるのがよいと解釈しています。
ここまで、各ゾーンを紹介してきましたが、最後にこれらをどのように活用すればよいかを紹介します。
なお、各ゾーンの紹介は原文に書かれていることをかみ砕いて解説したものになりますが、活用方法に関してはそれに加えて、筆者(松岡)の意見が入っているものになります、ご了承ください。
各ゾーンから、「ビジネス価値と向き合う」「技術的卓越性によりアジャイルの持続可能性を高める」「市場を理解して製品計画を最適化する」といったエッセンスをチームの目標や価値観に加えることで、チームの行動に変化をもたらします。
例えば、「スケジュールに合わせてリリースすることが正義!」というチームが、上記の要素を一つでも加えることができたとしたら、チームの行動が大きく変わるでしょう。
また、「技術的負債を産ま"ない”」という後ろ向きの表現ではその価値が伝わりにくい部分がありますが、「持続可能性を高める」という前向きな表現として定義することで、必要性を感じやすくなる、評価・賞賛が生まれやすくなり行動が促進されるなどの効果が生まれます。
チームが開発における課題を感じた際、具体的なプラクティスを参考にして取り入れることができます。
Agile Fluency Projectのページには抽象的なモデルの紹介のみで(ワークショップ紹介はありますが日本人には少し敷居が高いですね)、具体的なプラクティスは書いてありません。それを補完できるのが”The Art of Agile Development, 2nd Edition”です。これは著者がモデルの提唱者の方であり、本の中でもフルーエンシーモデルに基づいた内容になっています。
これは残念なことに英語版しかないのですが、翻訳しながら読み進めることをお勧めします。
細かいTipsとしては、O'Reilly Online Learningで契約すると、Chromeで内容を見られるのでブラウザでGoogle翻訳を使って読むことができるので、英語が苦手な方でも読みやすいです。
2009年出版の1st Editionと2021出版の2nd Editionがあり、ますが、1st Editionのみ日本語版があります。2ndはフルーエンシーモデルに則った構成ですが1stはそうではなく、本全体の構成が大きく異なりますが、各プラクティスは大きく変わっていない物も多く、1stのものでも十分に参考になります。まずは1st Editionの日本語版から読んでみるのも良いと思います。
最後に、非常な重要なポイントとして、アジャイルの効果を十分に発揮するには、組織のサポートが必要です。これはフルーエンシーモデルの中でも繰り返し書かれています。
例えば、アジャイル持続可能性を高めるために必要な技術がチームになければ、外部の力を使ってでも学習しなければなりません。新しいプラクティスを試そうとしたら、一時的な生産性の低下を受け入れる必要があります。このような金銭的・時間的投資を行わなければ、大きな成果を引き出すことができません。
それだけではなく、体制変更や評価基準も検討することが必要です。「最適化」ゾーンでは、市場に合わせて製品計画を最適化できるように、チーム横断での意思決定や、体制変更の必要性が示されています。また、アジャイル持続可能性が高い行動を推奨しながら、納期の達成だけを評価していては結局評価に人の行動は引きずられてしまいます。
本記事冒頭でも書きましたが、「組織のサポート」の実現方法としてはこれらの執行権限を持つのはマネージャーであることが多いでしょう。(もちろん役割分担として別の手段でも構いません)
フルーエンシーモデルでは、各ゾーンごとに、どのような投資や体制変更などが必要かが明示されています。これを参考にしながら、投資が必要であることを認識し、そのためのアクションを取ることで大きな成果を持続的に出し続けられるようになります。
以上で、アジャイル・フルーエンシーモデルとその活用方法について説明しました。
アジャイルな開発をする上で非常に参考になり、実用的なモデルだと思いますので、ぜひ参考にしていただければと思います。
なお、ログラスでは、創業期からアジャイルを活用して価値あるプロダクト開発に取り組み続けています。それがどんなカルチャーとして浸透し、どんな魅力があるかについては以下の記事で紹介しています。
ログラス社の情報はこちらです。