アジャイルとは何ですか？ 実践を通じて発展する哲学
公開: 2022-07-22もともとソフトウェア開発チームのために考案されたアジャイルは、現在、世界中の業界や企業にとって最高のプロジェクト管理アプローチです。 魅力は、そのシンプルさと柔軟性にあります。アジャイルには規範的な慣行がないため、非常に採用しやすくなっています。 それでも、いくつかの企業でアジャイルの変革を導くとき、この柔軟性がアジャイルであることの意味についての誤解を招くことにも気づきました。 多くの企業は、哲学自体を理解することよりも、アジャイルから派生したフレームワークを順守することを優先しています。
代わりに、プロジェクトマネージャーとコーチがアジャイルチームを編成して指導することから始めて、アジャイルの考え方を採用するようにトレーニングし、哲学のコアバリューと原則を本質的に内面化する必要があります。 そうして初めて、プロジェクトの要件に最適なものに基づいて、アジャイルフレームワークのプラクティスを組み合わせたり、カスタマイズしたり、省略したりする必要があります。
この記事は、アジャイルの歴史的発展をたどり、その設立原則を企業やチームの特定のニーズに結び付けることで、プロジェクトマネージャーがアジャイル変革の最適な未来を創造するのに役立ちます。 以下の事例が示すように、アジャイルは厳密にプロジェクト管理アプローチとして考えられるべきではなく、実際に継続的に進化する製品開発哲学として考えられるべきです。
アジャイルの前例
2001年に最初に編集された「アジャイルソフトウェア開発のマニフェスト」は、4つのコアバリューと12の原則の簡潔なコレクションであり、ルールと一連のドキュメントが満載の線形でプロセスの多いアプローチに対する根本的な対応でした。 しかし、アジャイルの歴史は、数十年前に工業生産を合理化する方法から始まりました。
反復的な改善に焦点を当てた哲学の前身であるPlan-Do-Study-Actモデルは、1930年代にベル研究所の物理学者で統計学者のウォルターシューハートによって開発されました。 第二次世界大戦後、彼の弟子であるW.エドワーズデミングは、それをトヨタの列車管理者に適用しました。 この方法は、効率的な構築-測定-学習ループを備えたリーン思考の主な源であるトヨタ生産方式の開発に不可欠でした。
1970年代に、BarryBoehmがソフトウェアの開発に必要な労力と時間を正確かつ客観的に見積もるための反復プロセスを使用してワイドバンドデルファイ手法を提案したときに、この概念はさらに発展しました。
1980年代半ばにパソコンが普及するにつれ、製品やサービスとしてのソフトウェアが人々のビジネスの要となることが明らかになりました。 専門家がソフトウェアエンジニアリングへの漸進的で反復的なアプローチに真剣に注意を払い始めたとき、アジャイルは優れた開発および管理アプローチとしてウォーターフォールプロセスを上回りました。
研究者は、競合他社よりも迅速にイノベーションを起こしているメーカーが、製品のライフサイクルを通じて製品を動かすために、学際的でチーム指向の方法を採用していることを発見しました。 これは、1993年にスクラムフレームワークを発明したジェフサザーランドのインスピレーションと広く見なされており、バグを最小限に抑えながら、表面上不可能なプロジェクトをスケジュールどおりに予算内で完了することができました。
理論上のアジャイルの価値は、これらの前例から生まれたものであり、反復型開発、協調的なチームワーク、正確な推定に重点を置いて、実際にアジャイルを使用することで裏付けられています。
理論におけるアジャイルとは何ですか？
企業がアジャイルな働き方を採用し続けると、哲学のフレーマーがこれまで意図していたよりも規範的になるリスクがあります。 私の経験では、アジャイルを採用したいと考えているリーダーは、フレームワーク、または特定のプラクティスとそれに関連する命名法のセットに焦点を合わせすぎており、価値観と原則に十分に焦点を当てていません。
アジャイルの原則を伝えることに進んだ実務家がよく知っているように、アジャイルの変革を目指すすべての組織は、自分に合ったアプローチを見つけて適応させる必要があります。 マニフェストの価値観と原則に従う方法をチームに示し、スクラム、かんばん、エクストリームプログラミング（XP）などのフレームワークからインスピレーションを得て、それらを実際に実装することで、この学習プロセスを促進します。
マニフェストの信条は、今ではアジャイルプロジェクトマネージャーの第二の性質です。
- プロセスとツールを介した個人と相互作用
- 包括的なドキュメント上の実用的な製品
- 契約交渉をめぐる顧客のコラボレーション
- 計画に従った切り替えへの対応
ただし、マニフェストでこれらの信条に従う警告は、見過ごされがちです。「つまり、右側のアイテムには価値がありますが、左側のアイテムには価値があります。」 多くのアジャイル実践者は、右側の値を無視し、左側の値のみに焦点を合わせることになります。 結果？ プロセスが多いフレームワークを盲目的に追跡するのとは反対です。プロセスがまったくないため、同様に問題があります。
左右のアイテムの適切なバランスをとることが、アジャイル変換をガイドする方法の鍵になりました。 また、Apple、Google、Amazon、Facebook、Netflixでの管理アプローチによっても例証されていますが、いずれも単一のアジャイルフレームワークにサブスクライブしていません。 彼らは、マニフェストの原則を何よりもまず具体化し、その一方で、彼らにとって最も効果的なものに基づいて、さまざまなフレームワークの一部をフォローまたは変更しました。 その結果、彼らは市場の変化に適応し、新製品を迅速に提供することができます。
アジャイルは実際には何ですか？
次の概要では、マニフェストの値の元の表現を変更しました。 セマンティクスの変更は、実際にアジャイル値を適用する方法を明確にするのに役立ちます。
最初の値では、アジャイルであることはチーム指向であることを意味するため、「個人」という用語を「人」に置き換えます。 2つ目は、ソフトウェアが「機能している」必要があることは明らかであるため、現在は成功したタイムリーな「配信」に重点が置かれています。 3番目の値は、単に「コラボレーション」です。これは、一緒に作業する同僚とクライアントと作業するチームに等しく適用されるためです。 最後に、「フレームワーク」は「計画に従う」に置き換わるものです。これは、計画を完全に放棄する必要があるという誤解を未然に防ぐためです。
プロセスを超えた人々
アジャイル変換は困難です。これは主に、ほとんどの企業がプロセスに厳密に従うことに慣れているためです。 革新的な製品を開発する代わりに、特定のツールセットを使用して特定の数のステップを完了することが、最終目標になります。
この考え方が収益性の高い「アジャイル産業」を生み出すのを見て、私はがっかりしました。 アジャイルの創設者であるウォードカニンガムとジョンカーンが説明するように、多くの企業は、企業が「アジャイルになる」のに役立つと主張するソフトウェアを販売しています。 しかし、アジャイルになるということは、ソフトウェアを使用せず、それが規定するプログラムに従うのではなく、哲学を採用することを意味します。
適切なバランスを実現することは、手順を排除することではなく、各チームの開発目標を最もよくサポートする手順を見つけることです。 私のクライアントの1つである大企業の技術組織のために、IBMで開発されたアプローチであるDisciplinedAgileを実装しました。 スクラムやかんばんなど、複数のフレームワークの多くのプラクティスを組み合わせています。 反復型開発を利用しますが、スクラムによって残されたギャップを埋めることを目的としているため、特に初期段階では、従来のアジャイルよりもプロセスが少し重くなります。 組織が非常にプロセス指向であったため、DisciplinedAgileはこのクライアントのために働きました。 これにより、チームに途中で会い、賛同を得て、スクラムワークフローを採用するように説得することができました。
チーム内およびチーム間のコラボレーションを促進するために、バックログ改善会議、レビュー会議、および毎日のスクラムを組み込みました。 バックログの詳細化はスクラムガイドの一部ですが、詳細化会議はそうではありません。 これらを追加して、今後のスプリントに特定の機能を実装することを計画した理由について健全な会話ができるようにしました。これは、アジャイル初心者に役立ちます。 また、ウォーターフォールプロジェクト管理で使用される用語である「マイルストーン」という命名法を選択しました。これは、クライアントにとってより馴染み深いためです。 レビューと毎日のスクラムインタラクションは、スクラムガイドの従来の要素ですが、スケジュール、期間、フローの観点から、より構造化されています。
さらに、スクラムを厳密に順守することで、各人がスクラムガイドに記載されている役割の1つに完全に専念することになりますが、クライアントのチームには、スキルセットが1つの役割にうまく適合しない人がいました。 Disciplined Agileメソッドを使用することで、これらのポジションの責任を複数のチームメンバーに分割し、関係者の強みを生かしたプロセスを作成することができました。
ドキュメントを介したソフトウェア配信
1つのフレームワークに厳密に準拠するよりも、カスタマイズされたスクラムまたはかんばんのワークフローを好むもう1つの理由は、目標として最小実行可能製品（MVP）を計画に追加する機会を与えてくれるからです。 リーンから派生したMVPを作成する方法は、反復型開発と一致しており、アジャイル実践者の間で人気のある手法になっています。 これにより、チームは高品質のソフトウェアやその他の商品を効率的にユーザーに提供し、フィードバックに基づいてそれらを改良することができます。 主にスクラムまたはかんばんに基づくハイブリッドアプローチの一部としてそれを適用することで、顧客のニーズを満たす製品を作成するための私のチームの能力が強化されました。
私は現在、米国を拠点とするスタートアップと協力しており、NFTの暗号通貨マーケットプレイスを構築する際にこの方法を採用しています。 MVPの作成に重点を置いているため、現時点で必要な最小限のドキュメントのみを作成しています。 このアプローチは幅広い製品に効果的ですが、急速に変化する新しい実験的なカテゴリにある暗号通貨とNFTに特に役立ちます。 完全な仕様と機能を作成し、リリース前に繰り返し変更する必要はなく、その時間をユーザーのフィードバックを取り入れて市場開発を強化することに費やすことができます。
契約をめぐるコラボレーション
前述の大企業の技術組織は、多くの固定費プロジェクトの契約に大きく依存していました。 契約では、作業を完了するために使用する方法と、各タスクを担当する特定の個人について概説しました。 一度署名すると、長いリクエストプロセスなしに契約を変更することはできませんでした。
変革の一環として、私はこれらの厳格な合意よりも優先的なコラボレーションを主導しました。 私たちが実施した計画では、契約書が1ページのドキュメントに置き換えられました。 それぞれが、指定された開始日と終了日の間に、アジャイルを使用して、お客様だけでなく、さまざまなチームのチームメートや同僚と協力して作業することに同意したと述べました。 コラボレーションから生まれたものは何でも結果になります。 完成品が何であるかについての詳細は含めませんでした。 お客様からのフィードバックを求めて製品開発に取り入れていたため、計画書から仕様を削除することで、お客様の反応を受け入れやすくなり、より積極的に協力していただくようになりました。
経営陣を参加させるために、必要な変更が問題を悪化させる前でさえ、開発時間が長すぎるという懸念を表明した1人の小さなクライアントと協力する1つの小さなチームで概念実証をリードするように依頼しました。 この顧客に製品所有者と直接協力してもらうことで、開発の途中で変更を加え、納期を大幅に短縮することができました。
これらの結果により、経営陣は計画をより多くのチームに展開できるようになりました。 全体として、合理化された契約とアジャイルワークフローにより、製品機能の開発と市場投入に必要な時間が短縮されました。
フレームワークに対する適応性
私の別のクライアントであるヘルステック企業も、アジャイルの価値の両面の重要性を認識しているという点でバランスをとることができませんでした。つまり、計画に従った切り替えへの対応です。 ただし、この場合、エンタープライズテクノロジークライアントが抱えていた間違いとは正反対でした。プロセスを厳密に追跡する代わりに、プロセスをほとんど無視しながら、柔軟性を過大評価していました。 優先順位やスケジュールがなかったため、エンジニアは自分たちが何に取り組むべきかをほとんど知りませんでした。 彼らは毎日それを理解しようとして時間と生産性を失い、より重要なタスクの前に重要性の低いタスクを完了しました。
私はスクラムの実装をCEOとCTOに提案し、スプリントはエンジニアに毎日何をするかを決めるのではなく、2週間ごとに訓練と計画を強いることになると説明しました。 また、チームの製品説明責任の欠如を修正するために、製品所有者を雇うことをお勧めしました。 私は経営幹部に、結果を期待できるようになる前に、チームと協力するために3〜4か月を与えるように依頼しました。
彼らの承認を得て、私は最初にアジャイルの価値観と原則を紹介し、次に製品のバックログと、エピックやユーザーストーリーの作成、サブタスクの作成など、それを配置するためのさまざまな手法についてチームをトレーニングしました。 ワークフローに含めたテクニックと会議は、スクラムガイドに表示されないという点で、従来のスクラムとは異なります。 トレーニング中に叙事詩、ストーリー、サブタスクがチームの共感を呼び、会議が生産的な議論を促進したため、私はそれらを計画に統合しました。
また、速度の概念も含めました。これは、XPに最近追加されたもので、各製品の反復におけるすべてのユーザーストーリーの総労力の見積もりを測定します。 ただし、私は「キャパシティ」という用語を使用しました。これは、タスクを完了する速度ではなく、チームメンバーがどれだけの作業を引き受けることができるかを強調するためです。
見積もりのために、私はTシャツのサイズ設定から始めました。これは、プロジェクトとタスクを小、中、大のいずれかに測定する手法です。 チームが進むにつれて、私はストーリーポイントに切り替えました。これは、より伝統的な見積もり手法です。 ストーリーポイントは、アジャイルに慣れていないチームによって誤用されることがよくあります。チームは、ストーリーポイントを労働時間または日数に変換しようとし、時間枠に過度に焦点を合わせ、期限を守る能力に基づいて人々を判断します。
Tシャツのサイズはより抽象的なものであり、チームがこの落とし穴を簡単に回避できるようになっています。 ただし、精度も低くなります。 そのため、チームが相対的な見積もり方法を理解したら、私はチームをより洗練された手法に移行しました。
チームが2回のスプリントを完了するまでに、上級管理職は従業員がより生産的に働き、より効果的にコミュニケーションをとることができるようになりました。 開発者は、初めて利害関係者や経営幹部と関わりました。 彼らはカスタマーサポートチームに会い、実装した機能がユーザーの生活をどのように改善しているかを理解しました。
このアプローチにより、すぐに会社のソフトウェアの品質が向上し、新機能の納期が数か月から数週間に短縮されました。
アジャイルの未来は何ですか？
COVID-19のパンデミックは、チームを同じ場所に配置できなくなるという新しい現実を生み出しました。これは、アジャイルが考案されたときにアジャイル内で作業するための好ましい方法でした。 ただし、このままにしておく必要があるという考えは神話です。リモートワークが一般的になるにつれて、ビデオ会議ソフトウェアを使用して緊密な通信が完全に可能であることが明らかになりました。 現在作業しているチームは完全に分散されており、リモートでトレーニングを提供しています。 一部のチームは、NotionやLoomなどのツールや、StanduplyなどのSlackプラグインを使用して、非同期で作業することを選択しています。
コラボレーションの分散モデルは、敏捷性を中心とした新しい仕事の世界です。 リモートチームに提供されるワークライフバランスは、士気とメンタルヘルスにプラスの影響を与え、生産性と品質を向上させます。 それは人々をプロセスに置き、柔軟性と適応性を備えているため、典型的にはアジャイルです。
アジャイルコーチ、スクラムマスター、およびプロジェクトマネージャーは、哲学のルーツに戻り、マニフェストのフレーマーが行ったように、柔軟で動的な一連の開発および配信ガイドラインを提示する必要があります。 彼らは、プロジェクト管理からインスピレーションを得ることができますが、アジャイルでは実際には何も管理していないことを経営幹部やチームリーダーに教える必要があります。彼らはチームを導き、最高の仕事をするために解放します。