見出し画像

プロジェクトマネジメント初心者の気づき

山内翔大

初めまして！
株式会社GA technologies、AI Strategy Center（以下AISC）の山内です。
現在、Data Scienceチームのチーフとして働いています。


今回の内容


今回の記事のテーマはプロジェクトマネジメントです。
去年の5月頃、チーフになるにあたってプロジェクトマネジメントという概念を学びました。そして、半年間ほど実践することを心がけて業務に取り組みました。今回は、その振り返りをモチベーションとして書いた記事になります。
注意点として、あくまでプロジェクトマネジメント初学者が書いた記事ですので、温かい目で読んで下さると助かります。
具体的な内容としては

  • 私が勉強したプロジェクトマネジメントの内容紹介

  • 実践してみて得た気づき

となっています。

私が勉強したプロジェクトマネジメントの内容紹介

プロジェクトマネジメントは、非常に多くの情報を持った概念です。なので、その全てを網羅しようとすると、途方もない長さの記事になってしまいます。
なので今回は本を読んだり上司から教わったりする中で、大切そうな以下の要素に焦点を当てて紹介させていただければと思います。

  • ステークホルダーマネジメント

  • スケジュール、コスト、スコープ

  • WBS

今回参考にした書籍は以下になります。


ステークホルダーマネジメント

ステークホルダーとは、プロジェクトの利害関係者です。
例を挙げるならば、プロジェクトマネージャーやプロジェクトチームメンバー、会社のマネジメント層や経営陣、そして顧客などです。
ステークホルダーマネジメントでは、ステークホルダーの洗い出しや、ステークホルダー達との適切なコミュニケーションが求められます。


スケジュール・コスト・スコープ

プロジェクト3大変数は、スケジュール、コスト、スコープからなります。
スケジュールはプロジェクトの期間を、コストはプロジェクトの費用を、そして、スコープはプロジェクトの範囲を表します。
この中の１変数でも変化すると残りの変数も変化します。たとえば、スケジュールを短くする上で当初と同じスコープを達成しようとすると、より多くのコストがかかります。
プロジェクトを進める上では、スケジュール、コスト、スコープのバランスに注意を払うことが非常に重要になります。
また、上記のバランスについて各ステークホルダーと合意を得ることも重要です。
なぜならステークホルダーの中にはさまざまな立場や利害関係を持つ人々が存在するためです。例えば、経営陣にとっては適切なスコープでも、顧客にとっては不十分なスコープと見なされてしまう可能性があります。


WBS

WBSはWork Breakdown Structureの頭文字をとったものになります。
WBSはタスクを構造的に分解する方法です。
たとえば、「卵かけご飯をつくる」というタスクをbreakdownすると以下のようになります。

卵かけご飯を作るというタスクのWBS

WBSを書くことで、「卵かけご飯を作る」というタスクをこなすために必要な具体的な作業の洗い出しができます。
WBSを書く際には気をつけるべきルールがいくつかありますが、ここでは一番大切なルールを紹介します。それはMECEにするというものです。
MECEは「Mutually Exclusive and Collectively Exhaustive」の頭文字をとった造語です。日本語では、「もれなく、ダブりなく」というふうに表現されます。
したがって、WBSをMECEにするということは、breakdown先がbreakdown前のタスクをもれなくダブりなく表現している状態にするということです。
今回の例で言うと、「材料の準備」と「調理」の2工程で「卵かけご飯を作る」というタスクをもれなくダブりなく表現できているかを確認する必要があります。


実践してみて得た気づき

私は後輩の業務をサポートするにあたり、上記で述べたプロジェクトマネジメントの重要要素について実践をしてみました。以下は、実践してみて得た気づきになります。

ミーティングは準備が重要である

ステークホルダーとのコミュニケーションを行う上で、ミーティングは必ず発生するものです。私はミーティングのファシリテーションを通して、準備が重要なのだということを思い知らされました。ステークホルダーの方々に、とあるテーマでディスカッションをしてもらうという趣旨のミーティングを組んだことがあります。ミーティングの開始時にディスカッションしてほしい内容と、その背景の説明を行いました。その後、ディスカッションが開始されれば、活発な議論が始まり、何かしら意見がまとまると思い込んでいました。しかし、ディスカッションは全然盛り上がりませんでした。私は非常に焦りました。幸い上司がフォローしてくれたおかげで議論は着地点に向かうことができたのですが、自身の準備不足を痛感しました。
いろいろ反省点はありますが、一番大きな反省点は

  • 自身の中で議論の着地点を想像し、議論が停滞した際に選択肢として提示できるようにしておくべきだった

ということです。
上司がしてくれたフォローがまさにこれでした。上司はあらかじめ議論の着地点を想像し、ステークホルダー達にその選択肢を提示することで、議論をまとめたのです。

アジャイルによるスコープ調整が重要

私がサポートした後輩の業務は、賃貸業務をサポートするWebアプリケーションのプロトタイプを構築するというものでした。
このプロトタイプ開発、利用者の要望をただただ実装するだけではうまくいきません。
要望通りのプロトタイプを作ったとしても、いざ利用してもらうと、何か違うな、と判断されてしまうことが多々あります。
すなわち、相手の要望通りにスコープを設定したとしても、結果として、そのスコープは潜在的なニーズを満たさないことがあるのです。
ここでアジャイルによるスコープの調整が登場します。
具体的には

  1. 作る

  2. 利用者に使ってもらう

  3. フィードバックをもらう

  4. 1~3を繰り返す

というサイクルを高速に回すことにより、利用者の潜在的ニーズを満たすスコープの調整を目指します。
結果として、プロトタイプは現場で徐々に使用されるようになってきました。

潜在的なニーズは、プロジェクト開始時に見つけられないから潜在的ニーズなのです。こういったアジャイル的工程を用いることで、潜在的ニーズを顕在化させてあげるプロセスが重要なのだということが大きな気づきでした。


アジャイルの元でWBSをMECEに保つことは難しい

先述した通り、アジャイル的プロトタイプ開発においては、利用者のフィードバックを元にして機能を開発する工程が多発します。その際、新たに増えた工程をWBSに追記していくのですが、WBSをMECEに保つことが非常に難しいと感じました。
というのも、高速でアジャイル開発をしていく際、常に業務の見通しが良い訳ではないからです。やることが完全に決まっていて、ゴールが明確な状態ならばWBSを更新しながらMECEに保つことは可能だと思います。しかし、ゴールが決まっていない、見通しが悪い状態でWBSをリアルタイムに更新し続けると、MECEに保つことが難しくなってしまうのです。
上司に相談したところ、やはり、アジャイルの元でWBSをリアルタイムに更新することはお勧めしないとのことでした。WBSはたまに見直しておかしい箇所がないかを確認するくらいにして、実際の工程管理はTodoリストを使うと小回りがききやすくて良いというアドバイスをいただきました。
現在は、大枠のWBSをMECEに書き、細かな業務はtodoリストで管理するという流れで業務を行っています。慣れてきた暁には、大枠のルールは守りつつ、自分にとって最適な業務管理方法を検討していきたいです。


終わりに

今回、記事を書いてみて思ったのは、プロジェクトマネジメントは非常に奥が深く難しい概念であり、一朝一夕で身につくものではないということでした。一方で、プロジェクトマネジメントの能力をしっかりと身につけ、扱うことができるようになれば汎用的に役に立つんだろうなという予感もあります。
なので、今後も同様の経験を積ませてもらい、このスキルを頑張って身につけていこうと思います。


この記事が気に入ったらサポートをしてみませんか？