はじめに
2024年9月から参画したプロジェクトで、PL（プロジェクトをリードする立場）を務めました。
過去関わったプロジェクトはすべてメンバーでの参画であり、PLとしてははじめての参画。
思ったように進まず苦労したポイント、反省点がたくさんありました。
今回のプロジェクトでの経験を汎化させ自分の学びとして蓄積できればと思い、
アドベントカレンダーという機会で振り返りと発信をさせていただきます。
読者の皆さまにも参考になる部分があれば幸いです。
参画したプロジェクトの概要
会計システムの導入支援を実施しました。
0からの導入ではなく、前身のプロジェクトがあり、
そこで未完成だった部分について評価および修正を行いました。
反省点と学び -はじめに-
以下3点をキーワードとして、それぞれを深堀する形で記載します。
- プロジェクト管理
- WBS
- メンバーとの作業分担
キーワード①：プロジェクト管理
メンバーとして参画していたときの違いの一つが、"プロジェクト管理を主体的に行うこと"でした。
プロジェクト管理そのものの難しさ
プロジェクト管理が難しいと感じた理由は以下2つでした。
(1)明確なゴールがないタスクであること
メンバーのときに割り振られるタスクは、ゴールが明確なものが多かったです。
例えば、「帳票を作成する」、「ユーザーからの問い合わせ対応をする」など
一方、プロジェクト管理はプロジェクト開始から終了するまで、継続して実施するため明確なゴールを認識できず、今何を行うべきか分からず迷子になってしまう期間がありました。
(2)プロジェクトをとりまく環境の変化に適応する必要があった
プロジェクトの概要に記載したとおり、今回のプロジェクトは進めていく中で前提が大きく変化しました。
こうした変化にどう対処すべきか分からず、プロジェクト管理に思ったより時間がかかった一因だと感じています。
プロジェクト管理と他業務との両立の難しさ
PLという立場でありながら、プロジェクト管理のみ行えば良いことはなく手を動かす部分（メンバーの役割を担う）もありました。
プロジェクト管理に苦労する中で、他の業務に手が回らず、結果プロジェクトの後半に無理をしなければ間に合わないという事態に陥ってしまいました。
上記を踏まえた学びは以下の通りです。
リーダ業務/メンバー業務 それぞれの工数を明確にする
どちらかに比重が偏ってしまうことを防ぐために、あらかじめ自分の工数を確認した上で
プロジェクト管理とメンバーとしての作業、それぞれどれくらいの時間を割くことができるかあらかじめ把握しておくことが重要だと思いました。
プロジェクト管理を楽に行う仕掛けを作る
プロジェクト管理は難しいからこそ、効率と質を担保するために楽に行う仕掛けをつくっておくことが必要だと痛感しました。
（例：進捗管理のフォーマットを作成し、週1回メンバーに記入してもらう）
キーワード②：WBS
WBSはプロジェクトのタスクを分解して構造化することで、プロジェクトの管理手法として活用するものとして知られています。
今回、プロジェクト規模のWBS作成・管理にはじめて取り組みました。
WBS作成におけるポイント-最後まで分解する
WBS作成のためには、細かな作業（Work）に分解（Breakdown）する必要がありますが、
今回のプロジェクトで作成したWBSを見返すと、分解しきれておらず抽象的な表現となっている箇所がありました。
抽象的なひょうげんとなってしまっている原因としては、必要な作業だと漠然に認識している一方で具体的な作業は分かっていないため、
一言で言えば作業の目的が明確になっていないためでした。
WBS運用におけるポイント-定期的な見直し
プロジェクトのはじめにWBSを作成しましたが、目先のことはイメージしやすく適切に分解ができている一方で
プロジェクトの後半や終盤のことはあまりイメージできず、分解が不十分になりがちだと感じました。
上記を踏まえた学びは以下の通りです。
作業の分解は具体的な作業になるまで行う
WBSを作成したら全体を見て、他と比較して抽象的な表現になっている箇所がないか確認をします。
その結果、分解し切れていない箇所は作業の目的が明確になっていないサインと捉えて再度検討、メンバーへの相談等を行い、作業を明確にしておくことが重要だと思います。
WBSを見直すタイミングを決めておく
一度WBSを作成したらそのまま運用し続けのではなく、定期的に見直して分解できていない部分や変更が生じた箇所はは修正することが必要です。
キーワード③：メンバーとの作業分担
今まではPMやPLから指示をもらって作業することがほとんどでしたが、
PLを務めることで、社内メンバーやお客さまに対してタスクをお願いすることが多くありました。
指示に対する認識の改め-ふわっとした指示でも良い
PJ序盤は誰かに何かを依頼するとき、指示された側がすぐに手を動かすことができる位具体的に指示しなければならないと思い込み、
指示するための準備（想定する成果物のフォーマットを作成、作業の洗い出しなど）に多くの時間をかけていました。
指示の準備が負担になっていることをPMに相談した際に、「指示する側が具体的に指示を出す必要はなく、メンバーに考えるとこからお願いするのはどうか」と助言をいただきました。
認識すりあわせの重要性
メンバーに作業依頼をしたとき、依頼者と作業者で考えや方針がずれていないかすり合わせながら進めることが重要になります。
今回のプロジェクトでは他業務（主にプロジェクト管理）に多くの時間を割いてしまい、作業途中のすり合わせや成果物のレビューが不十分なまま終わってしまうことがありました。
＊本題とは少しずれますが、果物の目的を正しく認識できていなかったことも反省点です。
「成果物をつくること」が目的になってしまい、その成果物が後続作業でどのように使われるかがイメージし切れていなかったと、後になって気づくことも多かったです。
上記を踏まえた学びは以下の通りです。
分担できる作業は積極的に分担する意識を持つ
自分がやるべきタスクに注力するためにも、分担できる作業はどんどんお願いすることは意識していきたいです。
PJはお客さまも含めてチームで進めていくものだ、という認識を大切にしていきたいです。
認識のすりあわせやレビューする時間を計画に入れる
作業途中のすり合わせや成果物のレビューを適切に行うために、これらにかかる工数を認識してスケジュールに組み込むようにします。
作業者とのすりあわせであれば、決まった周期でいったんカレンダー登録してしまうことも有効だと思っています。
おわりに
今回の記事を書くにあたってプロジェクトを通じた学びや気づきを洗い出すところからスタートしましたが、
思っていたよりも言語化して整理することは難しく、時間がかかってしまいました。
それと同時に、最近は目の前のプロジェクトを進めることに必死で、
俯瞰的に振り返りすることを疎かにしてしまっていたと気づくことができました。
記事の中では上手くいかなかったことや反省点にフォーカスをあてましたが、
プロジェクトを一つやりきることができたことは良かったと思っていますし、
今までメンバーとして参画したプロジェクトで得た学びを活かすことができた点も多くありました。
貴重な経験ができた4か月でしたが、ここで得た学びを自分のものにして、
この先のプロジェクトにつなげていきたいと思います。