【アジャイルの基礎から応用まで】プロダクトマネジメントの新たな視点、そしてアジャイルの本質

アジャイルという言葉を耳にしたことはあるでしょうか？

多くの方々がアジャイルを単なる開発手法と捉えています。しかし、実はその背景にはもっと大きな意味があります。

アジャイルは、変化に対応し、継続的な改善を目指す考え方です。それは製品開発にとどまらず、ビジネスのあらゆる面に応用可能なフレームワークです。

この記事では、アジャイルの基本的な理念やその進化、その普遍的適用を説明します。

アジャイルの本質を理解が重要です。その誤解を解消するための具体的な例や比較を紹介しています。変化に富んだ現代のビジネス環境でより柔軟で実践的な知見を提供します。

プロダクトマネジメント徹底解説: 初心者から中級者までを対象にしたざっくりガイド

プロダクトマネジメントに興味はあるけれど、「どこから始めたらいいの？」と思っていませんか？本記事は、プロダクトマネジメントの基本から、効果的な方法までを解説します。始めの一歩として、是非ご一読ください ...

アジャイルとは？

基本理念

多くの人がアジャイルを単なる開発手法と考えがちですが、実際にはそれ以上です。

アジャイルは、変化に柔軟に対応し、継続的な改善を重視する考え方です。製品開発だけでなく、ビジネスのあらゆる面で応用可能なフレームワークです。

キーポイントは、計画的で短期間での反復的な作業とフィードバックのサイクルです。それによって最終的な製品を徐々に洗練していくことです。これは複雑で予測不可能な環境においても十分な効果を発揮します。さらに、柔軟かつ迅速な対応を可能にします。

アジャイルの起源とその進化

アジャイルの起源は2001年発表されたアジャイルソフトウェア開発宣言に遡ります。この宣言は、ソフトウェア開発における既存の重厚長大なプロセスに対する答えです。

（省略）
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
（以下、省略）

アジャイルソフトウェア開発宣言より一部抜粋

重要なことは、価値ある記述において左記の事柄の価値を認めているということです。この左記の記述がなぜか無視され、プロセスやツール、ドキュメントが悪！というように曲解されて伝わっていることが非常に多く見受けられます。

宣言に書かれた価値や原則は時間が経つにつれて、ソフトウェア開発を超えていきます。ビジネスの多様な分野に適用されるようになりました。
アジャイルは、変化を受け入れる。顧客のニーズに迅速に対応する。このスタイルが、マーケティング、製品管理、さらには組織運営においても有効です。

開発を超えた領域へ

ソフトウェア開発の枠を超えて、アジャイルの原則は大きな価値をもたらします。
新しいマーケティング戦略を立案する際にも役立ちます。

短いスプリント（作業の周期）を設定し、定期的なレビューを行うことで、戦略を迅速に調整し、市場の変化に対応することができます。

人材育成や組織開発においても有効です。アジャイルは自己組織化するチームを育成し、継続的な学習と改善を促進します。

長らくアジャイルの考え方で仕事をしていると良く分かります。もう開発領域以外でも当たり前のように適用できる、適用しています。以前の働き方が思い出せません。
それほど強力な思考であり方法論であると実感します。

アジャイルの本質と誤解

協働とフィードバックのサイクル

アジャイルの本質は、「協働」と「フィードバックのサイクル」です。

チーム全員が協力し合い、継続的にフィードバックを受け取る。そのフィードバックに基づいて製品やプロセスを改善します。

例えば、あるチームが新しいウェブアプリケーションを開発しているとします。アジャイルのアプローチでは、このチームはまず小さな機能から始めます。それをユーザーにテストしてもらい、そのフィードバックに基づいて改善を行います。次に、追加の機能を作成し、同じプロセスを繰り返します。このようにして、製品は継続的に成長し、ユーザーのニーズに合わせて進化します。

本当のことをいいます。何も動くものがなくても、ユーザーからのフィードバックを簡単に得ることできます。

アジャイルのプロセスを料理に例えてみます。料理人がゲストの反応を見ながら料理を調整するようなものです。料理人は最初に小さな一皿を提供し、ゲストの反応を見て、次の皿を改善します。料理の過程全体でゲストの好みや反応に対応しながら、最終的なコースを完成させます。

アジャイルは柔軟性と迅速な適応性を実現します。まず、固定的な長期計画に固執しない（計画を持つなとは言ってない）。短期間のイテレーションを通じて、継続的に製品を評価します。必要に応じて方向転換（ピボット）を行います。

アジャイルの守破離とは？

「アジャイル」と聞いたら思い浮かぶ永和システムマネジメント。その代表取締役の平鍋健児氏が「アジャイル宣言」の著者の一人でもある、Alistair Cockburn氏にインタビューした動画があります。アジャイルの本質について15分程度に要約されています。詳細知りたい方はご覧ください。（日本語で手動翻訳した字幕あり）

よくあるアジャイルの誤解

アジャイルに対する一般的な誤解には、いくつかの共通点があります。これらの誤解を解消し、アジャイルの真の意味を理解することが重要です。

誤解①：計画不要

アジャイルでは計画が非常に重要です。というより、アジャイルだけでなくすべての取り組みには計画と期待状態があります。
なぜか、アジャイルの話になると無計画でどんどん作っていっている実態が存在します。

計画は存在する。ただ、固定的ではなく、柔軟性を持っている。その柔軟性は、プロジェクトの進行とフィードバックに寄るものです。
アジャイルは計画を否定するのではありません。計画を「生きたドキュメント」として扱います。状況に応じて軽アックを適応させることを奨励します。

どういうわけか、開発チームほど、計画が変わることに嫌悪感を示します。
さんざんアジャイル風潮を浴びてきた職種にもかかわらずです。

誤解②：ドキュメント不要

ドキュメントも重要な要素です。ただ、過剰なドキュメント作成は避ける。必要な情報を効率的に記録することに重点を置きます。実際に価値をもたらすドキュメントに注力します。

正直に言うと、ここもアジャイルだけに限った話ではありません。注力するドキュメント以外は、すべて議論や意思決定を早めるための中間成果物です。この中間成果物の作成にとんでもなく時間をかける人がいます。それゆえ、価値ある成果量に差が生まれます。

注力するドキュメント → チームの生産性向上、教育コスト削減のためのストック資産

注力しないドキュメント → 議論や意思決定を早めるためのフロー資産

と考えておいてください。

誤解③：常に速い

アジャイルの目的は、単に速さを追求することではありません。むしろ、プロジェクトが必要とする速度で柔軟に対応しします。そして、品質を維持しながら、顧客のニーズに迅速に応えることにあります。

アジャイルは、迅速な対応と持続可能なペースを両立させることを目指しています。

なぜ速いと勘違されるのか。

一番は、週単位や月単位で機能リリースしているためかもしれません。表面を見るとそうみえます。しかし、より早く価値の高い機能を優先順位を付け、リリースしているに過ぎません。

明確な優先順位基準に基づいて、提供する機能を見極める。そして一括ではなく顧客提供価値が高くなる順で提供しているのです。

やみくもに期間内で収まる機能をリリースしてわけではありません。

誤解④：アジャイル＝規律の欠如

アジャイルは規律を重視します。その規律は柔軟で適応性のある枠組み内で行われます。

アジャイルチームは自己組織化され、責任と自律性を持って行動します。規律と自律性はアジャイルの重要要素です。

アジャイルは、これらの誤解を超えた場所に真価を発揮します。それは、変化するニーズに迅速に対応し、持続可能な方法で価値を提供することです。効率的で柔軟な方法でプロジェクトを遂行する。そして、継続的な改善を通じて最高の製品やサービスを提供することにあります。

アジャイルとウォーターフォール: 適切な方法を選べ

アジャイルとウォーターフォール開発の違い。

その観点がすでに罠に陥っているようなものです。

それぞれのアプローチの利点と制約を把握する上で重要です。これら二つの開発方法論は、しばしば対立するものとして描かれます。

実際にはプロジェクトの性質や要件に応じて選択されるべき異なるアプローチです。

ウォーターフォール開発

特徴	V字モデルの各フェーズ（要件定義、設計、開発、テスト、リリース）を逐次的に進むスタイル。 １つのフェーズが完了するまで次のフェーズは進まない。 リリースタイミングはほぼ１回。 市場からフィードバックを得られるまでの期間が長い。
用途	- 要件が明確で変更の少ない - 規制が厳しい業界や、高度な安全性が求められるシステム開発 - 外部要因による段階的な対応難しい法規制など
結論	こんなプロジェクトは、本当は少ないはず

アジャイル開発

特徴	短いイテレーション（スプリント）を通じて進行する。 各スプリントでは計画、設計、実装、テストが小規模に行われる。 頻繁に市場からのフィードバックを取り入れて製品を改善する。
用途	- 外部環境の変化が激しいプロジェクトに最適。 - 要件が途中で変わる可能性が高いプロジェクトに最適。
結論	市場からの早いフィードバックを受けるスタイルゆえに要件が途中で変わる。 というより、この状態がサービスやプロダクトづくりのあるべき姿。 ほとんどのプロジェクトがアジャイルであり、ウォーターフォール案件は本来は珍しい。

ウォーターフォールとアジャイルの違いを、家の建設に例えてみましょう。

ウォーターフォールでは、設計図を完全に固めた後に建設が始まります。途中での変更はほとんど行われません。

一方、アジャイルでは、家を部屋ごとに建てます。各段階で家主のフィードバックを取り入れます。次の部屋の設計を調整します。

ウォーターフォールは計画性と予測可能性に重点を置いています。
アジャイルは柔軟性と適応性を重視します。
プロジェクトの目的や環境に応じて、最適な開発アプローチを選択することが重要です。

この話、本当？

ここまでは教科書通りの話です。

経験談として、ほとんどのプロジェクトはスコープ分けできます。

分割できるため、優先順位が付けられます。段階的にリリース可能です。

なぜ分割できるのか？

得たいフィードバックが想定できているから。その想定から始めれば、何を作らなくてよいか明確になるからです。

プロジェクトによっては、分割によってデータの整合性がおかしくなることがあります。

しかし、そうでなければ、段階的に定義したスコープ単位でリリースできます。

参考: ビッグバンリリースに寄る損害

アジャイル開発の実践

とにかくアジャイルの本質を取り込むこと

アジャイルの価値はソフトウェア開発宣言で明確にされています。

アジャイルがどのように機能するか。そしてなぜ効果的なのかを理解する上で不可欠です。

個人と対話を重視する

チーム間の直接的なコミュニケーションは、成功の鍵です。対面での会話を通じて、誤解を減らし、より効率的な意思疎通を促進します。

そもそも、なぜ、対話を重視するか？

これは、アジャイルの最も重要な要素である「協働」につながるためです。

ソフトウェア開発は、基本的にチームで活動しています。価値を早くに提供するには何が大事か。それはお互いに達成したい目的に向かっている状態を維持できていることです。業務に没頭していると気づけば本来達成する目標を見失いやすくなります。自分たちが何を達成したいか、常に確認する必要があります。そのためには、対話が重要ということです。

動くソフトウェアの提供

ドキュメントや計画よりも、実際に動作するソフトウェアを早期に提供する。そして頻繁に提供することを重視します。

なぜかはもうおわかりですね？早く価値を提供する、市場からのフィードバックを得るためですね。

顧客との協調

アジャイルは顧客との継続的な協力を促進します。顧客のフィードバックは、製品開発における重要な指針となります。

フィードバックを無視したら、独りよがりの趣味なプロダクトが出来上がります。なにも事業価値やユーザー価値が生まれなくなります。

変化への対応

市場や技術の変化に柔軟に対応する。プロジェクトの途中でも要件の変更を受け入れることが可能です。

これらの価値は、開発プロセスの効率化、製品品質の向上、顧客満足度の高い製品の提供に貢献します。

実際の運用は、言うは易し行うは難し

４つの価値の要素を読んで、ふーんと思った方。ほぼアジャイル開発に失敗します。

この宣言だけでは、抽象度が高すぎる。具体的な行動レベルでチームメンバーが動けないのです。

では、なぜ具体的な行動レベルまで記述されていないか？だれが、具体的な行動レベルに落とし込むのか？

答えは簡単です。スクラムマスターではありません。アジャイルを適用するチームです。

何も決まっていません。上司がトップダウンで決めるものでもありません。そうなればそもそもアジャイルではなくなります。チーム全員で合意形成して決めていくのです。いやでも、対話しないと決まりません。アジャイル開発を導入したら上手くいくのが妄想だとよく分かるでしょう？誰かが決めてくれると思っているなら、アジャイルを適用するチームは崩壊します。いつも誰かが決めてくれる環境で育った人には難易度が高い方法論です。良く考えて参加するメンバーを決めてください。

アジャイルプロジェクトの具体的なステップ

アジャイルプロジェクトは、以下のステップで進行することが一般的です：

プロジェクトの計画とロードマップの作成

プロジェクトの目標、スコープ、および概略的なタイムラインを設定します。

スプリントプラニング

各スプリント（通常は1〜4週間）の目標を設定し、必要なタスクを特定します。

デイリースタンドアップ

チームメンバーが日々発生する課題を共有し、わざわざ集まって解決策を模索します。

デイリースタンドアップは、よくある進捗報告会ではありません。

もっとも勘違いしているイベントがこれでしょう。

進捗報告はわざわざ集まってする必要ありません。テキストで共有すればよいことです。

わざわざ集まっているのは、前日に発生した課題を智慧を出して解決するためです。

スプリントレビューとレトロスペクティブ

スプリントの終わりに、成果を評価し、次のスプリントに向けての改善点を議論します。

横文字しか出てきませんが、安心してください。やっているのは、目標を設定し、複数の単位に分け、優先順位を付けてPDCAしてるだけ。

あなたがいつもの業務で日報や週報とやっていることは何も変わりません。

プロダクト開発におけるアジャイルの適用

プロダクト開発にアジャイルの適用は有効です。

新規事業開発でも既存の改善施策でも同じアプローチが取れます。

アジャイルの本質や考え方は、プロダクト開発にだけにとどまりません。

繰り返しになりますが、あらゆるシーン、家の家事でも適用できるのです。

準備すること

アジャイル開発の一般的な課題

アジャイル開発を実施する上で、いくつかの挑戦が伴います。これらには以下のようなものが含まれます：

文化とマインドセットの変化

アジャイルは、組織全体の文化と考え方の変化を必要とします。自律的なチームワークへのシフトは、組織にとって大きな挑戦です。とはいえ、実際は一部のみがトップダウンな案件や部署横断的なプロジェクト。それら以外は部やチーム単位の取り組みが中心でしょう。まずは小さく始めるために、チーム単位で取り組むのがベスト。

適切なスケーリング

小規模チームから大規模プロジェクトへのアジャイルの適用は、正直分からない。
10人位のアジャイルチームなら、横展開はできる。

Amazonは、3000近くのスクラムチームがいるとスクラムマスターの方から聞いたことがある。大規模なプロジェクトなら、どうやってるのかな。ちょっとわからない。

不十分なトレーニングと準備

最初のアジャイルの適用の前に対面による講義や簡単なワークショップをやった方がアジャイルの運用は円滑に進みます。

不明瞭な要件と優先順位

アジャイルでは要件が流動的であり、これが計画の不確実性を高めることがあります。

それゆえ、明確な優先順位付けの基準が必要です。

課題に対するベストプラクティス

これらの課題に対処するためには、以下のような解決策を考慮することが重要です：

チーム、部のコミットメント

理想としては、アジャイルは単なる開発チームの取り組みではなく、組織全体のコミットメントを必要とします。

経営層からのサポートと理解が不可欠です。

ただ最初はチーム長、部長レイヤーの理解とサポートからお願いしましょう。

• 教育とトレーニング: アジャイルメソッドの効果的な実践には、適切なトレーニングと教育が必要です。定期的なトレーニングセッションとワークショップを通じて、チームのスキルと知識を向上させることが重要です。
• フィードバックと継続的な改善: 定期的なレビューとフィードバックを通じて、プロジェクトの進行状況を評価し、改善の機会を特定します。
• 透明性とコミュニケーション: チーム内およびチーム間での透明性とオープンなコミュニケーションは、アジャイルの成功に不可欠です。

トレーニングについては、仮でも良いので具体的なテーマに沿ったゲームをしてみるとよいです。

例えば、「24時間以内にコーヒー豆のECサイトを作る」というテーマでアジャイルのイベントを経験してみましょう。

1.要件の設定

プロダクトオーナーは以下のような特定の要件カードから選びます。例えば、「商品一覧ページを作成する (40ポイント)」、「アカウント作成機能を実装する (30ポイント)」、「ペイメントゲートウェイを設定する (50ポイント)」などがあります。

2.リスクと変更イベント

イベントカードには、「サーバーがダウンして作業が遅れる（次のスプリントのポイントは半分になる）」や「お客様からのフィードバックにより、レイアウトを一新する必要が出てきた（ランダムに選んだ要件が無効化され、新しいレイアウトに関する要件が追加される）」など、予期せぬリスクや変更が記載されています。

3.作業のスプリント

開発チームはどの要件を達成するかをスプリントプランニングで決定します。

4.イベントの発生:

各スプリントの最初にイベントカードを引きます。

5.スプリントレビューとスプリントレトロスペクティブ:

完了した要件に対してポイントが付与され、チームは反省会を開く。

実際のゲームの流れ（サンプル）

実際にゲームのイメージをプロダクトオーナー、開発チームメンバー数名が登場する会話劇で見てみます。

プロダクトオーナー (PO): 「新しいECサイト! これが今回のプロジェクトだ。」

開発チームメンバー1: 「ECサイト。いいね。どんな機能が必要なの？」

PO: 「とりあえず、商品一覧表示(40ポイント)、商品詳細表示(25ポイント)、カート追加(20ポイント)、会員登録ログイン機能（30ポイント）、クレジットカード決済機能（50ポイント）、レビュー表示機能（35ポイント）を考えているよ。」

開発チームメンバー2: 「なるほど、その機能があれば一通りのECサイトは動くね。この中から一つ目のスプリントで何を達成しようか？」

開発チームメンバー1: 「商品一覧表示と商品詳細表示を完成させれば、最低限でも商品を表示できるから、そこにしよう。」

開発チーム全員: 「了解！」

これでスプリントプランニングは終わり、開発を開始します。しかし、開発直後、開発チームメンバー1がイベントカードを引きます。

トラブル発生、そのときメンバーは……

開発チームメンバー1: 「あ、イベントカードを引いたら…"サーバーダウンで開発が遅れる（次のスプリントのポイントは半分になる）"って出たよ」

イベントの発生により、作業スピードが遅れが生じた。予定していた全ての機能を完成させることが困難に。優先的にビジネスバリューの高い「商品一覧表示」を完成します。そしてスプリントレビューへ。

開発チームメンバー2: 「商品一覧表示はできたけど、商品詳細表示は時間が足りなかった。」

PO: 「商品一覧は問題ないけど、商品詳細が出ないのは厳しいね。次のスプリントではそれを優先して進めよう。」

反省会でも、メンバーは同じように次のスプリントの改善点を議論します。「サーバーダウンは予想外だったけど、次からは予想外の事態に備えたタスク管理をしよう」と話されたとしましょう。……（続く）

いかがでしょうか？このようなゲーム形式を使うことで、アジャイルの本質がぼんやりつかめます。
価値の提供、フィードバック、インサイトの発見、優先順位見直し。改めてみると、目新しいものはありません。
そのサイクルを高速で回せる状態がアジャイルの真髄ですね。

アジャイル成功への道

アジャイル開発の成功にはいくつか要素があります。明確なビジョン、組織のサポート、適切なトレーニング、継続的な学習と改善。

組織は、アジャイルを単なる方法論として認識するだけでは足りない。ビジネスの根本的なアプローチとして受け入れる必要があります。

企業は、企業価値を上げるためにも、未来にお金が増えるような施策を常に模索しています。

既存事業からの収益の確保・収益改善だけではない。利益の一部を新規事業に投資するサイクルを回す仕組みが経営であるはずです。

そのためにも、特に知見のない新規事業領域では、高速で仮説検証を回したり、市場からのフィードバックを獲得して反映するためにも、アジャイルの考え方、アジャイルの仕組みの導入は相性が良いです。

組織文化とビジネス統合

結局、企業単位で変わることが重要

アジャイルが求めていることは、今に始まったことではありません。自律的なチーム、健全な価値評価基準、継続的な学習と改善。そもそもそのような性質であることが組織体の理想です。そのためには、トップダウンとボトムアップの両面から変化していくことが重要です。

ビジネスを意識したアジャイルでないと意味はない

アジャイルが経営に直結していなかったら、ただのごっこ遊びになります。ビジネスプロセスに統合することで、組織は市場の変化に対して迅速に対応し、顧客のニーズをより効果的に満たすことができます。

アジャイルと経営の連携

アジャイルが最大限の効果を発揮するためには、経営層との連携が不可欠です。経営層はアジャイルの価値を理解し、サポートを提供することで、組織全体のアジャイル変革を推進する役割を担います。経営層と開発チームが一体となってアジャイルを推進することで、組織は市場での競争優位を実現し、持続可能な成長を達成することができます。

すべての事業に適用するのは大きな改革にあるため、新規事業領域もしくは既存の事業の一部の改善案件に適用するのがはじめの着手に最適です。

アジャイル開発の高度な応用

大規模プロジェクトでのアジャイルの適用

大規模プロジェクトにアジャイルメソドロジーを適用する際には、さらなる調整と戦略的なアプローチが必要です。

これは、多くのチーム、複雑な要件、そして広範囲の利害関係者を扱う必要があるためです。

アジャイルの原則は同じですが、スケーリング戦略、クロスチームのコミュニケーション、およびリソース管理に特別な注意を払う必要があります。

フレームワークの中で、SAFe（Scaled Agile Framework）やLeSS（Large Scale Scrum）などが大規模プロジェクトのアジャイル適用を支援します。

LeSSについての実績は以下のLINEの取り組みが参考になります。

アジャイル開発における高度な技術とツール

アジャイル開発を成功させるためには、適切な技術とツールの利用が重要です。

例えば、カンバンボード、スクラムボード、アジャイルプロジェクト管理ツールなどがあります。

これらのツールは、進捗の追跡、タスクの管理、コミュニケーションの改善に役立ちます。また、DevOpsの導入は、開発と運用の連携を強化し、より迅速なデリバリーと効率的な運用を可能にします。

アジャイルを取り入れている米国の事例では、半数程度はほぼスクラムを採用してる。

 スクラムの知見も多い。横文字だらけだけども、和訳すると恐らく経験として知っていることが多いはずなのでビビることはない。

アジャイルチームとコミュニケーション

これは、なにを言っても難しいテーマだと思います。アジャイルのフレームワークがあっても、期待するコミュニケーションを判断するには結局、対話するしかない。やる気があるようにみえる伝わりやすさと、実際のやる気の量の２軸で見たときに、実際にやる気も伝わってやる気がある領域に全員いるわけではない。これはアジャイルだろうがそうでなかろうが、対話しないと分からない。つまり、コミュニケーションはアジャイルの適用によってなにか見えるようになるわけではない。

目的達成のための行動を成約する内容がオープンであること、そういう意味での心理的安全性を高めてアジャイルな環境作りができることの１つです。

心理的安全性と聞くと、プレッシャーやストレスが少ないことと解釈されている印象を受けるが、仕事でそんな状態はありえません。アジャイルは関係なく、仕事でプレッシャーやストレスがなかったら誰も何もしなくなると思って良いです。
心理的安全性とは、目的達成に必要な行動を制御するルールが見えないこと、不透明または意義が分からない慣習的なルールが存在することだとを理解している。

まとめ: 急がば回れ

逆説的ですが、アジャイルの本質は実践によって得られます。
想像以上に、アジャイルのサイクルの実施には脳を酷使します。毎日、意思決定の連続です。とにかく疲れます。
本質通りに実施していれば、最終的には、あの有名な「学習する組織」にたどり着きます。
フレームワークを通して、今までの思考を本質にシフトさせましょう。