こんにちは蒼海 隼（あおみ じゅん）です！
この記事では、日常生活でも役に立つ「アジャイル型のプロジェクトマネジメント」の概要を解説します。
プロジェクトマネジメントと聞くと仕事の話と思いがちですが、プロジェクトの定義に立ち戻ると日常生活でも十分に役に立つノウハウ集としての側面が浮かび上がります。
プロジェクトと日常生活の共通点についてはこちらの記事をご覧ください。
この記事はこんな人にオススメ！
- 就職活動、転職、結婚、子育てなど人生の大きな岐路にこれから立ち向かう人。
- リーダーにならないといけないが何からやればいいのかわからない人
- 仕事でプロジェクトマネージャを目指す人。
今回は最近のトレンド、アジャイルについてです
よく耳にするのですが、いまいちピンときまセン。
そうですね。具体的にこうするというのがあればわかりやすいのですが、どちらかというと思想や考え方の比重が大きい概念です。
難しそうですネ。
取っ掛かりさえ乗り切れば非常に有用な手法であることは間違いないです。食わず嫌いせず頑張ってみましょう。
ぜひお願いしマス。
では見ていきましょう！
アジャイルとは？
「アジャイル（Agile）」という言葉は、元々英語の形容詞で、「敏捷な」「機敏な」「素早い」「軽快な」といった意味を持っています。転じて、ビジネスやソフトウェア開発の分野では、この言葉が「変化に柔軟に対応し、迅速に価値を提供するための」というニュアンスで使われるようになりました。
すなわちアジャイル型のプロジェクト管理とは、変化に柔軟に対応しながら、短いサイクルで開発（作業）と改善を繰り返す手法を指します。計画よりも変化への対応を重視し、顧客との連携を密にしながら、価値の高い成果物を迅速に提供することを目指します。
アジャイルの歴史
従来型の開発手法（ウォーターフォールモデル）の限界
アジャイルについて語るためには対立概念であるウォーターフォールモデルについて知っておく必要があります。ウォーターフォールモデルとは、ソフトウェア開発における伝統的な開発手法の一つであり、その歴史は1950年代に遡ります。ウォーターフォールモデルの概念は、1956年に発表された論文「Digital computer programing—the AUTONATH business information system」で初めて提唱されました。この論文では、ソフトウェア開発を段階的なプロセスとして捉え、各段階が前の段階の成果に基づいて進むという考え方が示されました。
1970年代から1980年代にかけて、ウォーターフォールモデルは大規模なソフトウェア開発プロジェクトで広く採用されました。この時期は、コンピューターシステムの導入が急速に進み、大規模な基幹システムや業務アプリケーションの開発が盛んに行われた時代でした。計画に基づいて段階的に開発を進めるため、大規模プロジェクトの管理に適していると考えられたのです。
現在でも、ウォーターフォールモデルは、要件が明確で変更が少ない大規模なシステム開発や、高い品質が求められるミッションクリティカルなシステム開発などで採用されている重要な手法です。
PMBOKも第6版まではウォーターフォールモデルの影響が色濃く出ています、というよりもウォーターフォールモデルを体現し、牽引したのがPMBOKと言っても過言ではありません。だからこそ第7版での改訂が大きな衝撃を持つこととなりました。
PMBOKの版による特徴については下記の記事を参照ください。
アジャイルの誕生
1990年代に入ると、ソフトウェア開発を取り巻く環境が大きく変化し、ウォーターフォールモデルの限界が見え始めます。ウォーターフォールモデルでは、途中で仕様変更が発生した場合や、顧客のニーズが変化した場合に、柔軟に対応することが難しいという課題があり、莫大な予算と期間をかけた結果、顧客の要望からかけ離れたモノが出来上がる、あるいはそもそも出来上がらない、といった自体が発生するようになったのです。
そんな中ソフトウェア開発の現場では、より柔軟で変化に対応できる開発手法が求められるようになりました。そして2001年、ソフトウェア開発者たちが集まり、「アジャイルソフトウェア開発宣言」を発表し、アジャイルの考え方が広く知られるようになりました。「アジャイルソフトウェア開発宣言」については下記で日本語版を読むことができますので是非御覧ください。
変化への対応が謳われていることがわかりますね。
アジャイル手法
様々な流儀がある
アジャイルという言葉がいまいち掴みづらいのは、これぞアジャイルという明確な手順なり手法なりが定まっていないことにあります。先述のアジャイル宣言に適合すればすべてアジャイルということもできるでしょう。PMBOK7版はアジャイルを意識して、具体的なプロセスではなく指針や方針を示しているのですがこれもアジャイルの特徴からすると自然な流れだったと言えそうです。
以下に代表的な手法を示します。今の段階ではこんなのがあるんだな、程度に頭の片隅に留めておいていただければ十分です。今後詳細に取り上げていく予定です。それぞれ、サイクルを短期間で回して状況変化に随時対応いく、顧客の要望を随時取り入れると行った共通の特徴を有していることが見て取れます。
スクラム (Scrum)
- 概要:
- 少人数のチームで協力し、短い期間（スプリント）で開発と改善を繰り返すフレームワークです。
- 毎日の短いミーティング（デイリースクラム）で進捗を確認し、問題点を早期に解決します。
- チームワークとコミュニケーションを重視し、変化に柔軟に対応します。
- ポイント:
- スプリントと呼ばれる短い開発期間を繰り返す
- デイリースクラムと呼ばれる短いミーティングを毎日行う
- チームで協力して開発を進める
XP（エクストリームプログラミング） (Extreme Programming)
- 概要:
- 技術的なプラクティスを重視し、高品質なソフトウェアを迅速に開発することを目指します。
- ペアプログラミングやテスト駆動開発などのプラクティスを実践します。
- 顧客との密なコミュニケーションを重視し、変化に柔軟に対応します。
- ポイント:
- ペアプログラミングと呼ばれる2人1組でプログラミングを行う
- テスト駆動開発と呼ばれるテストを先に作成してからプログラミングを行う
- 顧客とのコミュニケーションを重視する
カンバン (Kanban)
- 概要:
- 視覚的に作業の流れを管理し、ボトルネックを早期に発見・解消することを目指します。
- カンバンボードと呼ばれるツールを使用し、作業の進捗状況を可視化します。
- 継続的な改善を重視し、効率的な開発プロセスを実現します。
- ポイント:
- カンバンボードと呼ばれるツールを使用して作業の進捗状況を可視化する
- 作業の流れを管理し、ボトルネックを早期に発見・解消する
- 継続的な改善を重視する
4. リーンソフトウェア開発 (Lean software development)
- 概要:
- トヨタ生産方式をソフトウェア開発に応用したもので、無駄を徹底的に排除し、価値のある機能に集中します。
- 「無駄をなくす」ということを重要視し、開発プロセス全体を最適化します。
- 継続的な改善を重視し、顧客に価値を迅速に提供します。
- ポイント:
- 無駄を徹底的に排除する
- 価値のある機能に集中する
- 開発プロセス全体を最適化する
アジャイルが元々ソフトウェア開発の文脈から発生した概念なので、ソフトウェアやプログラミングに言及していますね。ただ、手法そのものや考え方は広くマネジメントに応用することができます。特にスクラムは汎用性が高く、いろいろな種類のプロジェクトのマネジメントに応用されつつあります。スクラムについては別の記事で詳しく紹介します。
まとめ
この記事では最近主流になりつつあるアジャイル型プロジェクトマネジメントついて紹介しました。刻一刻と変化する状況に柔軟に対応していく手法です。日常生活でも前提が変わってしまったり、目標そのものが変化する状況は往々にしてあるので、アジャイルの考え方がきっと役に立つでしょう。
どうでしたか？
概念や意義についてよくわかりまシタ。でも、具体的に何をすればいいのかまだピンときまセン。
！
そうですね。各手法や日常のどの場面で活用するのか今後詳しく見ていきましょう！
わかりまシタ！
プロジェクトマネジメントの考え方を活用して日常生活を豊かにしていきましょう！
