プロジェクトマネージメント奮闘記

【IIJ 2023 TECHアドベントカレンダー 12/2の記事です】

はじめに

本稿は私が体験したあるプロジェクトマネージメントにおいて、短納期、広範囲のものに対して、どのように考え、対応したのかを紹介します。

「プロジェクトマネージメントを任されたけど、どうすればよいのかわからない。」や「（同じような）課題に対して、どう対応すればよいのかわからない」といった方の参考になれば幸いです。 

特にプロジェクトマネージメントの目的や流れ、PM、PLといった用語に関する説明は本項には含まれていませんので、必要に応じてお調べいただければと思います。 

序章 

ある日、上司に呼ばれて、設定された打ち合わせに参加した。 

 

上司「今、進行していた○○プロジェクトにおいて、進捗が芳しくなく漏れも多い。そこで引き継いで遂行してほしい」

自分「え？PMとしてですか？そうなるとメンバーなどが必要ですが、私には人的リソースを管理する権限ないですので、それを出来る役職の方がされる方が適切かと思います。」 

上司「人員については△課の人員を使ってくれて構わん。」 

自分「承知しました。ちなみにいつまでにでしょうか？」 

上司「〇月までだ」 

自分「（規模の大きさに比べて）短納期ですね。そもそもこのプロジェクトがうまくいっていないのは、目的、目標も不明確でそれによって開発なども方向性がバラバラだったりしています。上位者の方々でゴールを揃えていただきたいのですが…」 

上司「ちょっと、待ってろ。…えーと、確かこの辺に」 

上司「あったあった。この資料を見れるようにしておくから確認しておくように」 

自分「承知しました。確認しておきます」 

上司「不明点などあったら確認するように。以上、解散」

 

こうして 短納期かつなかなかハードなプロジェクトマネージメントが始まった。

プロジェクトの始動準備

プロジェクトの目的、目標の設定 

この時点で貧乏くじを引いたなと思いつつ、まず上司から示された資料を確認しました。プロジェクトに関する大雑把なデザインがあるのみで、目的、目標まで掘り下げられていないように見えました。 

また、デザインレベルであるがゆえに曖昧な書き方で示されており、言葉をどういうイメージで使っているかという点やニュアンスを確認する必要性を感じました。 

 

そこで共有いただいた資料を元に具体的なレベルまで目的、目標を試しに書き下ろしてみて、関係のありそうな上司やその上位者との打ち合わせを設け確認しました。 

 

結果としては、この打ち合わせをしておいて良かったと思います。 

• 上司’sのイメージしているデザインを具体化することにより、方向性や達成レベルを確認できた
• 上司’sの中でもやはり各項目に対して、認識のずれがあり、「え？そういう意味で書いたっけ？」みたいなやつがあったのを統一できた

この二つを序盤に潰すという点で、プロジェクト終盤でひっくり返されるような憂き目に合うことなく進められたと思います。 

プロジェクトの引継ぎ 

さて、プロジェクトの目的、目標は確認して統一が果たせたといっても、範囲は膨大であり普通にやっていたのではとてもじゃないですが期日は満たせません。 

また、引き継いだものの同じ轍を踏むわけにもいきません。 

 

プロジェクトを引き継ぐにあたって、まずは目標を達成するために何をするべきなのかを確認して、列挙していきました。いくつかの目標に対し、少し掘り下げて何をすべきかを上げていく要領です。 

次に、引継ぎ時点で、何が・どこまで完了しているのかを確認しました。 

ここでの確認方法は担当していた人に聞くというのはもちろん行いました。その際には「何が・どこまで」完了しているのかを事前に確認していただいたうえで、打ち合わせを入れてくださいとお願いしました。この理由は、計画的に物事を進められていない場合、個人の記憶に頼っているケースが多く、引継ぎの際に漏れが出ることが想定されるからです。それを避けるために必ず事前に準備をしていただくようにお願いしました。

※もちろん上記をやっても漏れがあるのは分かっていたので、開発チケットを片っ端から確認していく作業もやりました。

ここまでの情報を元に、目標に対して実施すべき事項に対しての進捗状況を埋めていき、出来ているところ、未達のもの、そもそも着手されていなかったものを確認しました。

プロジェクトの問題点の確認 

引継ぎ前までの今回のプロジェクトは何が良くなかったかを確認するため、運営方法や進捗を改めて確認しました。 

 

見えてきたのはプロジェクトを進めるにあたって、「PM/PLが兼任であり、プロジェクトにおける範囲を網羅するには広すぎること」、「進めている各タスクが別タスクを考慮したうえで連携していないこと」であることを確認しました。 

プロジェクトの再編 

前項までの問題点を踏まえプロジェクトをいくつかに分割し、それぞれにおいて、目標、目的、達成基準を設けることにしました。 

プロジェクトの分割 

どう分けるかというので時間をかけて悩んだ結果、今回のプロジェクトにおいてコストを平均化しつつなるべく近い分野は同じようになるようにという考えのもと、

1.  ホスト設計・開発 
2.  ソフトウェア開発全般 
3.  新規開発物を運用に取り込むための手順や監視システムなどの準備 
4.  新規開発物への移行対応準備・遂行 

といったように分けました。 

分割したプロジェクト（子プロジェクト）における編成 

プロジェクトの分割は出来たとして、それぞれ人的リソースとそれを動かす人が必要になります。 

悩みどころとしては、上司に「今回使ってよいよ」といわれた〇課については比較的若いメンバーで構成されており、プロジェクトのメンバーとしては参加したことがあっても、それ以上の立場で参加したことのある人がほぼいませんでした。 

そこでプロジェクトリーダーを抜擢する必要がありましたので、下記の基準で選出しました

1. 与えられた業務を理解し、独善に走らない（よくある自分はこういう方が良いと思うからいつの間にか明後日の方向に進むみたいなことがない人という意味です。） 
2. メンバーとコミュニケーションが取れる 
3. タスクにのめりこむことなく、一定の視野を持ち続け、広く見渡しながら与えられた業務が遂行できる 

必要数のリーダーを選出して、次に考えたのはどの子プロジェクトに割り当てるかです。よくある「その分野に詳しい人！」みたいなアサインが今回できないものも存在していたため、それぞれの子プロジェクトにおいて求められる資質を考え、任せることにしました。

例えば、ホストの設計・開発であれば専門的知識の他に慎重かつ堅実であること、ソフトウェアの開発であればロジックを正当に評価できる論理的思考が得意であるリーダーに子プロジェクトを割り当てていきました。

メンバーの選定は上記とほぼ同じですが、かかるであろうコストによる人数比、リーダーとの相性（個人間のものもあるが、行き詰ったりしたときにお通夜のような雰囲気になりにくいような人柄の組み合わせ）を考慮し決定しました。

プロジェクト承認・始動 

承認前の下準備 

プロジェクトデザインに基づき、プロジェクトにおける目的、目標を定め、それを遂行するにあたり、引継ぎ前までの反省事項を活かした組織編制、スケジュールに関する資料を作成し、承認を受けるまでの準備を行いました。 

この時の報告、承認先がちょっと歪な感じがしたので念のために確認（体感的にままあること）。プロジェクトにおいて△課の人員を使うものの、あくまでプロジェクトについての報告先・承認する人の確認は△課長ではなく、プロジェクトオーナーであること（今回で言えば部長クラスの方であること）の確認を行いました。

この理由は報告先が無数にあると、これどうなっているとなどの興味本位の質問ならともかく、「あーしろ、こうしろ」などといった横やりが入る可能性があったからです。報告を受けていると何か言わなきゃとなったりして混乱を生む元になるので、やるとしても報告ではなく共有までとすることにしました。

資料準備 

この手の資料を作るときに重要なのは、報告の受け手が求めている情報をわかりやすく伝えることであると思っています。（伝わらなければ無意味）

なので、今回のプロジェクトオーナーに該当する部長クラスの方の立場に立って、何が重要であるかを考えてみると、少なくともディティールの話は重要ではなく、引き継ぐ原因から推測できる「期日までに堅実・確実に進めること」が自分に求められていることだろうと考えました。

ということで、

• 期日については遅延リスクを避けたいのだろうと推測し、スケジュールを説明するページに進行に要する日数・バッファを盛り込んでおき余裕を確保したうえで進める
• 堅実にプロジェクトを進めるということを示すために、反省点を簡単にまとめ、それら解決するためのプロジェクト体制の構築する
• 確実にプロジェクトをゴールに到達させるということを示すために、引継ぎ時点での漏れなどもチェックして、それらを盛り込んで開発を実施する

ということを資料に盛り込むことにしました。資料の流れとしては、与えられたデザインから、目的・目標をこう考え、それに伴ってこういう開発を進めますというのを簡単にまとめ、その後、実際の線引きのスケジュール（ディティールは扱わずある程度の規模ごとでまとめたスケジュール）という流れにしました。

承認 

上記資料ができたため、プロジェクトを進めるにあたっての承認をいただくための説明を行いました。説明時については、話の流れにそって、上司の立場に立った時に大事だと思われるところを中心になる様に注意しました。求められていた情報は概ね想定通りであったようで、全体として見たときに遅延せず、堅実・確実に進めることを求められているようであり、記載事項の細かい開発について興味程度の質問はあったものの特に指摘なく、承認いただけました。

プロジェクトリーダーへの事前説明

プロジェクトリーダーへの説明については時間を確保して、特に下記を重点的に説明しました。

• プロジェクト全体での目的、目標
• 各プロジェクトごとの担当内容、責任分界点
• スケジュール

上記を説明時に強調した理由としてはいくつかあります。

• プロジェクトを割るときにある程度タスク分解したが、それでも全部はカバーできていないだろうからカバーしてもらう必要がある。また、プロジェクトリーダーが優先順位を自分で決めたうえで主体的に考え動くときにはそれが必要であるかどうかなどの判断材料が必要であること
• プロジェクトを進めるにあたって、どうしても他のプロジェクトと連携したりする必要があり、その時に曖昧だとどちらも担当しているつもりがないみたいなお見合いが起きたり、重複して実施してしまうなどが起きるため
• あれもあると良いみたいな沼にはまらず、確実に進めることができるようにスケジュールを共有することにより時間への意識を持たせるため

メンバーへの事前説明

メンバーについては、リーダーのもとで動くことを想定しておりリーダーほど自主性などを求めていないことから、下記の事項を重点的に説明しました。

• プロジェクトの重要性
• 各プロジェクトごとのチーム編成

上記の理由は、プロジェクトを進めてもらうにあたってプロジェクトの重要性を理解していないと後回しにされそうだったのと、チーム編成がはっきりしていないと誰の指示で動いたらいいのか分からないなどといったことを避けるためでした。

始動 

プロジェクトの再計画、承認をいただきようやくプロジェクトが始動しました。

恒常的にチケットなどの更新頻度や抽出でやり取りを確認しつつ、各チームの進捗状況を確認していました。

最初こそ、今までとは違う組織化された体系での業務遂行となったため戸惑いらしきものなどが見て取れましたが、各リーダーのもとやるべきことを理解した後は順調に進めていました。

プロジェクト管理

先述の通り、恒常的にチケットを眺めたりするほかに、週次でリーダーを集めて進捗状況や各リーダー間での情報共有や依頼する場を設けました。

進捗状況については、何が終わっていて、残るところは何工程といった形で報告してもらい、進捗がよろしくなかった場合は何が原因であるかの確認を行って改善していくようにしました。

各リーダー間での情報共有や依頼などは、始めこそ少なかったですがそれ以降は活発に行われるようになっていました。

うまく回りだしたなと感じて以降は極力手を出さず、各リーダーに考えることを含めて任せるようにしました。

見舞われる想定外のトラブル 

順調に進めていたと思っていた矢先、以下のような件によりプロジェクトは危機に瀕しました。

案件対応 

こういう時に限って連日持ってこられる案件対応は、プロジェクト参加人員と被っているものが多かったためリソースを消費するので何とも大変でした。

このため、業務の定型化や自動化などを含めた効率化を導入できる範囲で進めました。また、特定の人に負荷が偏っている場合はそれを解消するなどして影響を減らすように工夫しました。

やったことと言えば、小手先の対応で終わらず、根本原因を確認して、その時点でとれるものは恒久的な定型化や自動化対応を行い、そうでないものについては入力回数を減らすなどの半自動化対応を実施してしのぎました。

やっと連日起きていたやつが落ち着いたかと思った頃に、別の大口の案件対応が起きてスケジュール的にもう無理だなと思っていたところ、部長より「複数の課員や部の方を使って対応しなさい。自身のグレードより上であっても気にせず使ってもらって構わないから、この問題を解決してくれ」という言葉を頂き、プロジェクトに参加していた者の拘束時間を極限まで減らし、ある意味ドリームチームのようなメンバーで対応するといった貴重な経験をさせて頂きました。

特命事項によるリソース逼迫 

 案件対応以外での困ったことと言えば、上司とのリソース競合による逼迫がありました。これは、上司との間に限らず起こりますが、仕事を任せる側はこれくらいの時間で完了するだろうと思っていても、任される側は依頼内容の内容理解のために用語を調べたり、依頼に関係する部課との確認が発生して結果として数日かかったというものになります。

もちろん、特命事項が悪いとかの話をするつもりはありませんし必要なのも分かっていますので、この時は上司に「プロジェクトは優先度がかなり高いというオーダーのもとで動いています。プロジェクトと比べて優先度が低かったり、今でなくても良いものは後に回していただけると助かります」といった形でお願いしましたところ、以後は特命事項が減り予定通りに進めることができました。

既存のソフトウェアにおける課題

これはプロジェクト終盤に見つかったものになります。スケジュールを逼迫したという話ではありませんが、もともとあった既存のソフトウェアに改良したほうがよさそうな部位が見つかった時のことです。

この時、プロジェクトの計画時間、到達目標（ゴール）を再確認したのちに、改良したほうが良いのはどの程度であるのか・時間をどれくらい要しそうであるかを確認しました。

結果としては、改良のために設計・実装・試験からやり直すとなるとプロジェクトを遅延させるであろうし、改良も今すぐでなくても十分であろうというので、改良点はプロジェクト完了後に別課題で管理して対応することにしました。

 完成 

 様々なことが起きたり・発見されたりしましたが、どうにか最後まで進めることができ、リリース判定・リリース作業まで行うことができました。

このプロジェクトを進めるにあたって、協力して頂いた方々には感謝しています。

特に各リーダーは今回独断と偏見で選抜して遂行してもらったので負担が大きかったと思います。もし、成長の糧となったり、良い経験になっていれば幸いです。

終わりなき改良 

さて開発などに携わっている方はご存知だと思いますが、開発物は作って終わりというわけではなく、作り終わってからも維持や性能向上のため、継続的に手を加えていく必要があります。ゆえに完成とは言いつつもあくまでその時点で達成目標に到達したという話なので、「こういう機能があると良いよね」みたいに新たに要望が出現し、開発・改修するといったことが起きます。これは開発に携わる人であれば常にそうなので、開発部署に行ってものを作ることだけを想像している人がいらっしゃいましたらそれだけではないよというので知っていただけると、想像していた開発業務と実務のギャップが減るかと思います。

最後に

私の経験に基づく、プロジェクトの各工程における着眼点、人選やチーム編成、プロジェクトに対する考え方を書いてきました。

もし、これを読んだ誰かの参考にでもなれば幸いです。

ここまで読んでいただきまして、ありがとうございました。