プロジェクト管理とは？発展の歴史を辿ると本質が見えてきた
プロジェクト管理に関わらず概念系の話はフワっとした説明になりがちで、なかなか理解した感じがしませんでした。
そんなときは経験則的に、歴史（時系列）でまとめると分かりやすいことを知っていたので、プロジェクト管理について調べてみると、プロジェクト管理の本質が見えてきました。
プロジェクト管理で抑えるべきポイントを知りたい方の参考になれば幸いです。
歴史に学ぶプロジェクト管理の発展
太古の時代｜大規模建設の進捗が記録される
プロジェクト管理の起源は、古代文明の建設物にまで遡ります。ローマのコロッセオや中国の万里の頂上などがありますが、現代の技術をもっても多大な労力がかかるものばかりです。
人々は自然と最終的なゴールから逆算して中間目標を置き、資源（ヒト・モノ・カネ）配分やスケジュールを事前に計画するようになりました。
2013年、ギザの大ピラミッド建設について記された日誌がフランスとエジプトの考古学者チームによって発見されています。4,500年前の日誌には、建設作業員の日々の生活や採掘された石灰岩について記載されています。
他にも食料補給や会計など、さまざまな情報が記録されていたようです。巨大プロジェクトゆえに全体の把握が難しいことの裏返しであると言えますね。
産業革命｜小さなタスクに分解して生産性UP
18世紀後半、蒸気機関の発明により生産体制は大きく変わります。製造コストを下げるため、同じ商品が大量に生産され、プロジェクトが大規模かつ複雑化しました。マネジメントもそれに適した形に変化していきます。
具体的には、製造プロセスは小さなフェーズに分けられ、分業体制が敷かれました。分割されたタスクを同時並行で処理することで、爆発的な効率化が可能になるからです。また、作業着や工具、教育プログラムも同じものを提供することで生産の標準化も図られました。人によって仕事の質が大きく違うと困るからですね。
この時代の鍵となる人物がフレデリック・テイラーです。工学者である彼は、19世紀後半から20世紀初頭にかけて、科学的なマネジメント手法を初めて編み出しました。発案者である彼の名前を冠してテイラーリズムとも呼ばれます。
【テイラーリズムの４原則】
1. 最も効率的な方法を科学的に選択
生産性と利益を増やすことに注力。
2. 人員の適材適所
スキルや得意なことが活かせる場所に労働者を配置。
3. 労働者のパフォーマンスをチェック
管理者は現場で発生したトラブルに速やかに対処して生産性低下を防止。
4. 管理者と労働者の役割分担
管理者は計画立案や労働者の教育を担当。労働者は計画実行を担当。
ガントチャートの登場｜大規模で複雑なプロジェクトを管理する
複雑なプロジェクトを細かいタスクにして分業体制。たしかに非常に効率的です。ですがその計画は、すべてのタスクが期日通りにきっちりと終わることが前提条件になっています。しかし、もし期日通りに終わらなかったら？
仮にECサイトを作るとして、ほぼすべての機能がOKだったとしても、肝心の決済機能が間に合わなかった場合、１つの遅延がドミノ倒しのように全体に波及していきます。
1910~1915年、機械学者のヘンリー・ガントが解決策を提示します。有名なガントチャートです。主な特徴は、タスクを進める順番（依存関係）や進捗状況が分かりやすくなることです。さきほどの決済機能のようなボトルネックになり得るタスクを可視化することで、プロジェクト全体が止まることを未然に防止することができます。
クリティカルパス法｜もっとも重要なタスクはどれ？
1950年代、プロジェクトはますます巨大化、複雑化していきました。複数のチームが何千ものタスクを同時並行で進めていくと、収拾がつかなくなっていきます。なぜなら、タスクそれぞれが網の目のように絡み合い、パッと見でどのタスクが重要か分からなくなるからです。結果としてプロジェクトの遅延や人員等のリソース配分のミスが頻発しました。
上記の問題に対処するため、開発されたのがCPM（Critical Path Method）という手法です。以下の項目をネットワーク図にまとめて、どのタスク経路にかかる時間が最長かを調べます。
プロジェクト完了に必要なタスク
タスクの実行時間
タスクの実行順
最も完了時間が長いタスク経路をクリティカルパス（critical: 決定的な, 重要な）と呼びます。その経路上にあるタスク群が遅延すると、プロジェクト全体も遅延してしまうため、それらのタスク優先順位を高めに設定することで遅延を防ぐことができます。具体的にはより多くの人員を投入したり、分業できる箇所がないかを検討してプロジェクト完了期間を圧縮します。
リーン生産方式｜状況把握から継続的なカイゼンへ
複雑に絡み合うタスクを整理し、期限内に終わらせるにはどうするべきか？これまでのプロジェクト管理はこの問題に対処するためのものでした。ビル１棟建てるプロジェクトならそれでOKですが、生産性向上を目指すプロジェクトだと言われたらどうでしょう？継続的な”カイゼン”が必要です。
1950年代、トヨタ自動車の豊田英二（後の初代会長）は、フォードの自動車工場を視察していました。そのときこう思ったそうです。「フォードの大量生産方式を日本市場に当てはめることはできない。日本市場はアメリカよりも小さく、小型車から高級車までニーズも多様化している。必要な製品を必要なだけ生産する効率的な方法が必要だ。」
トヨタ自動車75年史より引用
その後トヨタは、必要な物を必要な量、必要な時に供給する「ジャストインタイム生産方式」などの革新的な方法を発明し、世界の自動車市場を席巻します。
マサチューセッツ工科大学（MIT）のジェームズ・P・ウォマック博士と彼のチームは、1990年に「リーン生産方式が世界の自動車産業をこう変える」という著書の中でトヨタ生産方式を紹介し、少ない経営資源で顧客に価値を継続的に提供し続けるその手法をリーン（Lean：余分なぜい肉のない締まっている様子）と名付けました。
製品・サービスの無駄を継続的に減らすことで、スリムな経営が実現できる。
リーン生産方式はムダを排除して効率的な運用体制を実現するための原理原則なので、業務の進め方が具体的に決まっているわけではないのですが、現代のプロダクト開発にも影響を与えている重要な考え方です。
ウォーターフォール｜大規模システム開発の管理法が登場
1970年代、パーソナルコンピューターが世の中に広まりはじめます。すると、コンピューターの利便性を高めるために、さまざまなソフトウェアが開発されるようになりました。これまでの歴史にもある通り、複雑なものを制作するためには、それに適したプロジェクト管理が必要とされます。
1970年、Dr. Winston W. Royceは後のソフトウェア開発に影響を及ぼす記事を公開します（原題：Managing the development of large software systems）。その中でシステム開発を７つのステップに分解して紹介しています（注：現代のウォーターフォール開発工程とは若干異なる）。
システム要件
ソフトウェア要件
分析
プログラムデザイン
コーディング
テスト
運用
まさに滝のように上から順に処理していくため、ウォーターフォールと呼ばれるようになるのですが、Royceはこの手法の問題点も認識していました。それはテスト工程が最後の方にあることです。なぜなら、テスト段階で顧客から「なんか思ってたのと違う」と言われてしまうとプログラムの修正程度では間に合わないからですね。
Royceは企業の航空宇宙部門でプロジェクトマネージャーとして働いていた人物ですから、大規模システムを開発する際に大きな修正が入ることのリスクをよく認識していたのだろうと思います。
ウォーターフォール型開発は、進捗管理が容易であることや、一定の品質を担保できること、予算やリソースの確保がしやすいことがメリットとして挙げられるため、要件などの仕様変更が予想されないかつ大規模なシステム開発に向いているプロジェクト管理法だと言われています。
スクラム管理｜短期間で成果を出す時代の最適解
1990年代、グローバル化とテクノロジーの急速な進歩の中で、世界は不確実の時代に突入しました。VUCA（社会の複雑性が増大し、将来の予測が困難な状態）という用語が使われだしたのもこの頃です。
将来の見通しが立たなくなってくると、人々は短期スパンかつ変化に強いプロジェクト管理法を求めます。そんな中登場したのがスクラム型のプロジェクト管理手法でした。1987年に発行されたHarvard Business Reviewの記事「The New New Product Development Game」で初めて紹介されます。
ウォーターフォール型と異なり、5~7人くらいがチームになってプロダクトに必要なサービスをリリースしていきます。2~4週間単位でプロジェクトを進めていくため、比較的短期間で成果を出しやすく、途中の計画変更も容易です。常に改善が求められるマーケティングやWEBアプリ開発等に適していると言えるでしょう。
【スクラム型管理の流れ】
1️⃣ バックログの作成
バックログとは、顧客に価値提供できる機能や施策のリストです。顧客のニーズや置かれている状況をよく理解している人が作成するべきで、マーケターやビジネスサイドの人間が作成を担うことがあります。その機能や施策がどのように顧客に価値を提供するのかを示す「ユーザーストーリー」も添付します。
2️⃣ スプリントの計画作成
バックログから最も優先度の高いリリース目標を選択したら、実現のためのタスクと担当者、実行スケジュールを決めていきます。マーケティングやプロダクト開発によって違いますが、だいたい1~4週間でリリースできるように調整します。
3️⃣ タスクの実行
チームメンバーでタスクを消化していきます。デザイナーやエンジニアなど役割の違う少数精鋭チームを組織し、互いにコミュニケーションを取りながらタスクを消化していきます。デイリーミーティングを行いながら、問題と解決策を議論し、必要ならマネージャーがサポートします。
4️⃣ 作業のレビュー
マネージャー等がアウトプットをレビューし、リリースしても良い品質かどうかをチェックします。
5️⃣ 振り返りと改善
業務の進め方に無駄がなかったかなどを議論し、次回のスプリントに活かします。これからリリースする機能や施策についての情報も共有します。
Build a custom Scrum board in Notionより引用
スクラム型プロジェクト管理はアジャイル開発のフレームワークとして、現在でも活発に活用されています。クラウド型のプロジェクト管理ツールも増えてきているため、情報共有スピードが上がったことも柔軟なプロジェクト管理ができるようになった背景としてあるように思います。
プロジェクト管理で抑えるべきポイント
「management」の語源は、15世紀のフランス語「mesnager」がルーツであると言われており、馬術用語として「馬の手綱をその手に握る」という意味から来ているそうです。
歴史を振り返るとプロジェクトの手綱を握るために以下のような課題があったことが透けて見えます。それに伴い管理手法も発展してきたと言えるでしょう。
タスクや進捗を見える化
適切なタスクの優先順位づけ
スケジュール通りの正確な実行
アウトプットのクオリティ担保
柔軟なプロジェクトの方針変更
プロジェクト管理で抑えるべきポイントは、タスクに関するデータをさまざまな角度から見える化すること、数週間ごとにリリース目標を議論してチームに共有することです。
プロジェクト管理アプリ（Notion等）を使うことでカンバンボードやタイムライン/カレンダー等でタスクを管理することができます。これにより、プロジェクト進捗の全体感を捉えることができるでしょう。逆にガントチャートのみでの運用は避けるべきです。
数週間ごとにリリース目標をチームと共有するためには、継続的に顧客の声を吸い上げる仕組みが必要です。なぜなら、各リリースは顧客に価値を届けるために行うからです。具体的には、アンケートや営業担当から顧客の課題を吸い上げ、そこからリリース目標を立てていきます。既存顧客がいない場合、SNSやFAQサイトなどから仮説ベースでもいいので、情報収集しましょう。
面倒に感じている日々の業務を教えてください
プロジェクト管理といってもNASAのプロジェクトからチームで使えるフレームワークまで粒度がさまざまなので、まとめるのにけっこう苦労しました。
どうせブログを書くならみんなに役立つ形にしたいので、タスク管理やプロジェクト管理についての課題をシェアしていただけると今後のモチベーションにつながります！今後とも引き続きよろしくお願い致します！
この記事が気に入ったらサポートをしてみませんか？