アジャイルなプロジェクト管理
2020/02/10
アジャイルとは、ソフトウェア開発の進め方のひとつです。ソフトウェア開発において常に発生する変化を受け入れ、高品質なソフトウェアを定期的に提供し続けるための思想、方法論、フレームワークでもあります。
現在ではソフトウェア開発だけでなく、多くのビジネスやプロジェクト管理においてアジャイルの思想が適用されつつあります。今回はアジャイルについて概説し、他分野のビジネスにも応用できることを示します。
アジャイルとは？
アジャイルとは英語で「agile」と表記し、元々は「素早い」「俊敏な」という意味を持ちます。つまりアジャイル開発とは「素早い開発」を意味しています。
例えば、ある企業のWebサイトを3ヶ月で構築する、というプロジェクトがあったとしましょう。プロジェクト管理者があなたなら、どのようにこのプロジェクトを進めようと考えるでしょうか？
多くのプロジェクト管理者は、プロジェクトの計画段階においてすべてのタスクを洗い出し、タスクを細分化し、ガントチャートを作成し、実行段階ではガントチャート通りに進んでいるかを監視します。問題が発生したらその都度対処していき、完全に構築したWebサイトを3ヶ月後に納品する、という流れを採るでしょう。工数の見積もりが正確になりますし、作業をどのように進めればいいのか、というビジョンも明確です。
ですが、アジャイル開発では上記の進め方とは全く異なるプロジェクト管理になります。アジャイル開発では、成果物を毎週納品します。つまり、ある週には構築するWebサイトにおける特定の機能を作ることへ注力し、作成したらすぐに顧客へ納品します。まさに「素早い開発」とでも言うべき進め方であり、実際にモノを作りながらブラッシュアップしてく手法となります。
とはいえ、アジャイル開発は無計画に進むわけではありませんし、プロジェクト管理を行わないわけでもありません。ソフトウェア開発という現場では「物事が計画通りには進まない」という残酷な現実が存在するため、この現実に対応できる体制を整えるためにアジャイル開発というスタイルが採用されているのです。
アジャイル開発における計画の立て方
アジャイルを採用したプロジェクト管理では、まず大まかな計画を立てます。この時点で厳密な計画が立てられる必要はなく、箇条書きにタスクの概要が書かれ、顧客が優先順位を付け、プロジェクトメンバーが見積もりを付ければ、プロジェクトの計画は立てられたことになります。こうして作られたプロジェクトの大まかな計画をアジャイルでは「マスターストーリーリスト」と呼びます。
3ヶ月でWebサイトを構築する、という先述のプロジェクト管理であれば
- トップページを作成する
- ユーザーアカウントを作成する機能を設ける
- 会社のブログを開設する
- FAQとお問合せフォームを作る
- 利用規約を作成する
- 運営会社に関する情報を掲載する
- 決済機能を設ける
といった項目がマスターストーリーリストに設けられます。見て分かるとおり、実態としてはかなり大まかな ToDo リストで、「マスターストーリーリスト」とはやや気取った呼び方をしているにすぎません。
このマスターストーリーリストを消化するため、開発チームは「イテレーション」と呼ばれる単位でマスターストーリーを実際に動くソフトウェアへと変換していきます。イテレーションの長さはおおむね一週間から二週間程度です。このとき、イテレーションは優先度の高い順番、つまり顧客にとって最も重要なものから開始されます。
イテレーションを繰り返すたび、開発チームは自分たちが実際にこなせる仕事量を把握できます。これにより、マスターストーリーがどのくらい実現可能なものかが見えてきます。
もしマスターストーリーが実現不可能なものであった場合、アジャイル開発では二通りの方法を採ります。やることを減らすか、計画を現実的なものに変えるかです。前者を言い換えるならば「作成できない機能は作成しない」ということです。後者を言い換えるならば「納期を延ばす」ということです。
それこそ非現実的であると思われるかもしれません。契約上、やらなければならないと定められていることもあります。このため、アジャイル開発では顧客とのコミュニケーションにおいて「誠実かつオープンであること」を求めています。顧客は十分な情報を得た上で、機能や予算、期日といった計画の変更に対して判断を下します。つまり、顧客もまた「物事が計画通りには進まない」ことを事前に了承している必要があるわけです。
顧客との折衝にあたるのはプロジェクト管理者です。アジャイルにおけるプロジェクト管理者は、チームメンバーだけでなく、顧客もプロジェクトの一員として巻き込む必要があるのです。
アジャイル開発におけるプロジェクト管理
アジャイル開発におけるプロジェクト管理で最も重要なことは、仕事の「完了」を定義することです。なにをもって完了とするのか、チームメンバーは元より、顧客とも合意を取っておく必要があります。
ソフトウェア開発では「リリースできるか否か」で完了を定義することが一般的です。つまり、ある仕事で作成したソフトウェアの機能を業務でも使ってよいなら、その仕事は完了していることになります。逆に、その機能が業務では使えない不完全なものであるなら、その仕事は完了していません。
なにをもって完了と判断するのかは、実のところ人によって異なります。これを明文化し、ステークホルダーへ共有しなければ、ところどころ不完全なソフトウェアが出来上がってしまいます。
他分野のビジネスについても同様です。なにをもってタスクを「完了」とするのか、ステークホルダー全員に周知しなければ、仕事が不完全なものとなってしまいます。プロジェクト管理者は、なにが完了しているのか、なにが完了していないのか、完了させるためにはどうするべきか、常に考える必要があります。
また、自分だけで考えるのではなく、メンバーや顧客と積極的にコミュニケーションを取り、解決策を探ることでメンバーや顧客もまた仕事に対して自発的に取り組むようになります。
アジャイルにおけるプロジェクト管理者の役割は、ああしろ、こうしろ、と支持を出すことではありません。メンバーや顧客が一丸となってプロジェクトへ取り組めるよう、コミュニケーションをデザインすることです。
アジャイル開発が受け入れる3つの現実
アジャイル開発では、プロジェクト管理者だけでなくステークホルダー全員が以下の現実を受け入れることが前提となります。
1つめの現実は、言い換えるならば「情報がすべて出揃っていなくてもプロジェクトを開始できる」ということでもあります。プロジェクトの核となる情報があるならば、細部の情報は後からでも集められます。また、実際にプロジェクトの仕事が進んでいる際、すべての情報が活用されることは稀でしょう。先述したWebサイトの例で言えば「会社のブログを開設する」というタスクに対して「利用規約を作成する」というタスクに関する情報はほとんど必要ないでしょう。
2つめの現実は、言い換えるならば「変化を恐れる必要はない」ということです。起きるものは起きると割り切り、起きうる変化に備え、起きた変化へ対応して計画を変更しながらプロジェクトを進めていく方が現実的です。先述したWebサイトの例で言えば「トップページを作成する」というタスクに対して「デザインを変更する」という割り込みが入るかもしれません。
デザインの変更をのっけから拒否するのではなく、デザインの変更を見越して変更しやすい作り方にしておく方が現実的です。あるいはデザイン変更の要求を受け入れる旨を先方へ通達しておき、代わりに要求の期日を設ける、という対策でもよいでしょう。
3つめの現実は、言い換えるならば「優先順位を付け、本当にやるべきことに注力することが重要である」ということです。先述したWebサイトの例で言えば「トップページを作る」や「ユーザーアカウントを作成する機能を設ける」「決済機能を設ける」といったことは重要であると想定できますが、「利用規約を作成する」や「会社のブログを開設する」は後回しでもいいはずです。イテレーションごとに成果を顧客へ届け、現状を共有し、顧客と密にコミュニケーションを取ることで、協働して問題の解決を図ることができます。
ここまで述べたことでお気づきの方もいらっしゃることでしょう。アジャイルとはプロジェクトを迅速に開始するための思想であり、変化を受け入れるための方法論であり、タスクを効果的に処理するためのフレームワークです。プロジェクトをアジャイルに実施する方法は一つではありません。上述した3つの現実をステークホルダー全員が受け入れられるのであれば、詳細なやり方はプロジェクトごとに異なってもよいのです。
アジャイルはソフトウェア開発だけでなく、変化の激しい現代ビジネス全般へ応用できるプロジェクト管理の思想、方法論、フレームワークとなりえます。そして実際に、海外の企業ではビジネスの現場でアジャイルが実践され、効果を上げているのです。
アジャイルとウォーターフォールの比較
従来のソフトウェア開発は「ウォーターフォール」と呼ばれる手法で進められることがほとんどでした。ソフトウェア開発に限らず、多くの仕事はウォーターフォール型でした。ウォーターフォール型の進め方は以下のようになります。
要件定義：顧客の要望を聞く
基本設計：要望を整理して大まかな設計図に落とし込む
詳細設計：基本設計の内容をどのように実現するか
開発：実際に作る
検証：設計通りに動くか、要望に添うものであるかテストする
運用：実際に利用し、改良する
ウォーターフォールという名前は「滝のように工程が下流へと流れていく」ことから名付けられました。
ウォーターフォールはシンプルで分かりやすく、顧客に納得してもらいやすい、というメリットがあります。見通しも立てやすく、契約にあたって必要な事項（金額等）を見積もりやすくなります。
ですが、ウォーターフォールには致命的な欠陥がいくつもあることが指摘されています。
まず、ウォーターフォールは工程が一方通行です。要求の変化にとても弱く、ある要求の変化によってプロジェクトの全体像が変化し、それまでの作業が無に帰す、ということも珍しくありません。かといって顧客の要求を全て拒絶すると、顧客との間に軋轢が生まれます。
ウォーターフォールは大きな変更がかからない仕事、例えば建設現場のような仕事には向いているのですが、変化の激しいビジネスに対しては根本的に向いていません。
また、ウォーターフォールは「事前の工程において間違いがない」ことを前提にしています。もし事前の工程に間違いが発生していた場合、発見が遅くなるほど致命的です。ウォーターフォールによるプロジェクト管理が成功するためには、類似のプロジェクトが過去に失敗している必要がある、とまで言われるほどです。再び建設現場を例に挙げますが、建設という仕事は過去に類似する事例が大量にあり、次の仕事に再利用できる失敗の知見が多く得られます。したがってウォーターフォールによって効率的な仕事が可能になるわけです。
逆に、明確な正解の無いビジネス、全く新しいサービス、といった仕事については、ウォーターフォールはなかなかうまく機能してくれません。
アジャイルを他のビジネスへ応用する
昨今、ビジネスの現場は激しい変化に晒されています。仕事を始める前に情報が揃っていることは稀で、物事は必ずと言っていいほど計画通りには進まず、仕事に期待される価値は常に大きなものとなっています。
このような現実に対応するため、ソフトウェア開発におけるアジャイルの思想、方法論、フレームワークを、ビジネスの現場にも導入しようという動きが盛んになっています。
例えば「快適なウォーキング体験を提供する新しい靴の開発」というプロジェクト管理を考えてみましょう。開発現場からは様々な機能が提案されることでしょう。また、マーケティングの担当者からも様々な要求がなされることでしょう。
それらの提案や要求をすべて作り込んでから販売する、という方法も考えられますが、失敗した場合のリスクはとんでもなく大きなものになります。特に、製造業における最終的な顧客は一般消費者であるため、開発中に継続的なフィードバックを受けるためには大胆な工夫が必要となります。
このプロジェクト管理へアジャイルの思想を適用してみましょう。まずは最初のイテレーションにおいて、最も重要な機能だけを搭載した靴を作成し、様々な人にテスターとして履いてもらいます。例えば「とても軽い靴」という機能を開発した場合、テスターからは「クッション性に乏しい」「値段が高い」「デザインが悪い」といった様々な意見が出されることでしょう。
ここで一旦、イテレーションが完了します。次のイテレーションではテスターからのフィードバックをもとに、新たな機能を開発することになります。
マーケティング戦略においても同様のことが言えます。靴を販売するターゲット、セグメント、自社のポジションなどについて、イテレーションごとに分析を行うことで、より最適なマーケティングを進めることができます。
まとめ：アジャイルなプロジェクト管理
今回はソフトウェア開発において適用されている「アジャイル」の概要を解説し、様々なプロジェクト管理へ応用できることを示しました。アジャイルとはプロジェクトを迅速に開始するための思想であり、変化を受け入れるための方法論であり、タスクを効果的に処理するためのフレームワークです。
アジャイルは「三つの現実」を受け入れ、解決するためにステークホルダー全員が取り組むことを前提としています。
これらの現実は特にソフトウェア開発の現場において如実に表れたため、解決の方法としてアジャイルが考案されました。ですが実際には変化の激しい現代ビジネスの現場においても有用な手法なのです。
最初は導入することが難しい、と思われるかもしれません。導入が難しい場合の Tips として「これから2週間であなたが抱えている課題を何か1つ解決します」と宣言する、というものがあります。実践し、解決し、フィードバックを受ければ、次第にチームも顧客もアジャイルに慣れてくることでしょう。
