ソフトウェア以外のプロジェクトにアジャイルを使用する
学習の目的
このモジュールを完了すると、次のことができるようになります。
- アジャイル手法の価値と原則を説明する。
- アジャイルの価値と原則をソフトウェア以外のプロジェクトに適用する方法を説明する。
プロジェクトの成功に適切なレシピを見つける
画像クレジット: Sergey Nivens/Adobe Stock
夕食の準備をしている方なら、優れたレシピの価値がよくわかるかもしれません。優れたレシピには、材料、作り方、説明、ヒントがすべて含まれています。けれども、同じ料理なのに複数のレシピが存在する場合があります。ラザニアのレシピをインターネットで検索すると、数百、あるいは数千もの異なるレシピがヒットするかもしれません。
これはなぜでしょうか? 経験、好み、状況に違いがあるからです。料理の経験が豊富な人であれば、何年も使っているレシピを好んでいるかもしれません。簡単なレシピ、素早く完成できるレシピを使いたい場合や、夕食に招待した人の中に乳製品に敏感な人がいる場合もあるかもしれません。経験、好み、状況によって、調理内容が左右されることはよくあります。
これから Walden University が、プロジェクト管理の手法とアプローチが多くの点で料理のレシピに似ているということを説明してくれます。プロジェクトを確実に成功させるのに必要なステップ、ガイドライン、ヒントも紹介してくれます。経験豊富なプロジェクトマネージャーは、経験や好みに基づいてアプローチを選択する場合がありますが、プロジェクトの特徴と状況も考慮することが重要です。これはアジャイル型のプロジェクト管理の場合に特に重要です。
アジャイルの料理本 – アジャイル宣言
2001 年、17 人から成る経験豊富なソフトウェア開発者グループが、従来型のソフトウェア開発方法の問題 (特に、ソフトウェア開発プロジェクトの失敗率が非常に高いという問題) に対処する手段として、アジャイル宣言を作成しました。アジャイル手法の基礎となる 4 つの価値と 12 の基本原則が定義されています。
アジャイルの価値
Salesforce の V2MOM と同様に、この価値はアジャイル手法の使用者にとってアジャイル計画を策定する方法と重視すべき事項のガイドとなります。
- プロセスやツールよりも個人と対話
- 契約交渉よりも顧客との協調
- 計画に従うことよりも変化への対応
- 包括的なドキュメントよりも動くソフトウェア
アジャイルの原則
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、2 ～ 3 週間から 2 ～ 3 か月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・ツー・フェイスで話をすることです。
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイルプロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ (ムダなく作れる量を最大限にすること) が本質です。
- 最良のアーキテクチャ、要求、設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
アジャイル型は元々ソフトウェア開発を改善する目的で設計されましたが、多くの環境に適しています。組織全体の生産性とパフォーマンスを高めるためにアジャイル型を採用する企業が増えています。
プロジェクト管理の手法で従来型を使用した場合とアジャイル型を使用した場合で、結果がどのように異なるかについて例を見てみましょう。
あなたの組織が新しいオフィスビルを披露するオープンハウスを開催しています。従業員は、数年にわたり耳にしてきた新しいスペースをついに見ることができると大興奮です。噂によると、作業エリアはモダンな雰囲気で、チーム間のコラボレーションが促進するようにレイアウトを変更しやすい柔軟な設計になっているということです。会社の役員は、「マネージャーの列」というマネージャーと従業員とのコミュニケーションを高めるオープンドアコンセプトのデザインをとりわけ自慢に思っています。
プロジェクトマネージャーとしてマネージャーの列の設計と開発に携わったあなたは、マネージャー達の反応を早く見たくてうずうずしていました。その革新的なデザインを見て、全員からハイタッチを求められ、賞賛されると期待していました。ところが、その予想とはまったく異なる結果になりました。マネージャー達は、落胆の表情を浮かべ、黙って眺めていただけだったのです。
何が起きたのでしょうか? あなたとプロジェクトチームは、設計者や建築業者と緊密に連携してプロジェクトを計画しました。包括的なプロジェクト計画を作成し、ステップごとに従いました。すべての作業が終わり、プロジェクトはスケジュールどおり、予算どおりに完了しました。これは、プロジェクトが成功したということではありませんか? 本当です!
従来型のプロジェクト管理というコンテキストで、この状況を考えてみましょう。
従来型のプロジェクト管理は、綿密なドキュメントに大きく依存しています。作業を開始する前にプロジェクトのすべての要件が把握、確定されていることが想定されています。顧客やエンドユーザーは、計画フェーズに関与して要件を定義します。両者ともプロジェクトの状況とパフォーマンスについて報告を受けることはありますが、最後まで最終的な結果を見ることはありません。
顧客満足度という点で、このプロジェクトは期待に応えることができませんでした。
最良を意味する「A」は「Agile (アジャイル)」の「A」
一方、アジャイル型では、本質的にフィードバックループという仕組みが備わっているため、時間とコストに影響を与えることなく顧客と緊密に連携し、素早く簡単に変更を組み込む機会を得ることができます。
アジャイルアプローチが使用されていたら、ワークスペースプロジェクトの結果はどう異なった可能性があるでしょうか? 次の例を見てみましょう。
サイクル 1
最初のイテレーションでは、プロジェクトチーム、新しいスペースを使用するマネージャー、スペースを設計する建築家、そして建設業者が関与します。このイテレーションで期待される成果物は、顧客の要望に応える新しいスペースの試作図です。
マネージャーらが要望を伝えます。建築家はその要望を設計ソフトウェアに取り込み、チームにデザインの試作図を見せます。建設業者は、建築基準法へのコンプライアンスに関して見過ごすことができない情報を伝えます。建築家は、建築基準法に準拠するようデザインを変更します。セッションの最後には、期待された結果になったことに全員が合意します。
サイクル 2
同じグループが 2 回目のイテレーションのために集まります。建設業者が作るワークスペースの 3D モデルがこのセッションで期待される成果です。建築家がワークスペースの最新の図を提示します。建設業者は仮のモデルを提示します。モデルを確認した後すぐに、マネージャーが問題に気付きます。
マネージャーのオープンドアスペースでプライバシーが確保されません。マネージャーは従業員と内密に話せる必要がありますが、そのような話し合いのために会議室を見つけることは困難です。建築家と建設業者は、変更を加えたデザインを考案します。3D モデルが更新され、新しいデザインに全員が合意します。
サイクル 3
3 回目のイテレーションでは、建設業者が新しいスペースの部分的な工事を行うためのチームを引き入れます。作業員がセッティングする間、建設業者はプロジェクトチームと 3D モデルを確認し、マネージャーから要望のあったいくつかの小さな変更を取り入れます。工事作業員にゴーサインが出ます。
ここでプロジェクトチームがワークスペースを見る機会を得て、最終的な工事が始まる前に最後の意見を述べます。マネージャーの意見が考慮され、要望が満たされたため、マネージャーは結果に満足しています。
「レシピ」を変更することで、オープン日に驚かれる可能性を減らすことができました。
プロジェクトの提供
経験、好み、状況はさまざまなため、全員の希望に応えることができるようなレシピはありません。同様に、すべてのプロジェクトに万能なプロジェクト管理アプローチもありません。プロジェクトで変更を歓迎し、お客様への価値の提供に焦点を合わせた反復的なアプローチの利点を得るには、アジャイル型が魅力的な選択肢となります。ソフトウェア開発へのアプローチだったという歴史にかかわらず、多くの組織はアジャイル型の利点が無視できないくらい素晴らしいと理解しています。
これまで、Walden University がプロジェクトのライフサイクルと適用可能なさまざまな手法を説明してきました。次の単元では、プロジェクトで確実に組織に価値を提供する方法を学んで締めくくります。
