プロジェクト管理について個人的なアドバイス
概要
最近プロジェクトのリーダーなどをすることもあるのですが、そのあたりのノウハウを自分の知識の整理という意味でもまとめてみようかと思います。
もうすぐ4月なので、新しく先輩になる方、プロジェクトリーダーになる方向けの記事になります。
WBSを作ることから始めよう
プロジェクトには何かしたら最終目的があると思います。例えば、ウェブサイトを作って納品する、のか、デザインを作って納品するのか、などです。
その場合は必ず、「納期」が存在します。
プロジェクト管理をまとめる人の責任としては、納期までに物を完成させる必要があります。そして、その完成、というのはお客様が納得できる形である必要があります。
自分たちができたと思っても、納品先の人が思うもの、もしくは合意している仕様からかけ離れたものができたとしても、それは完成したとは言えません。
では、納期までに完成させるために、何が必要なのでしょうか。
その一つの方法として WBS(Work Breakdown Structure) があります。
WBSの詳細なつくり方は解説しませんが、ポイントとしては以下だと思ってます。
- どんなタスクがあるのかを洗い出す
- マイルストーンとなるタスクを見つける、そのタスクが設定した期限までに完了していない場合、タスクが遅れていると判断してリソースの調整、納期交渉などを実施する必要がある
- WBSがしっかりとメンテされているかどうか、を管理する
- WBSに書かれているタスクが終わっているのに完了になってない、取り組んでいるのに作業中になってない、などが発生し始めるとプロジェクト管理が崩壊しているので注意が必要
WBSを作る理由としては、プロジェクトが順調なのか、遅れているのかを出来るだけ正確に把握するということです。
タスクの洗い出しができていない状態だと、今どの辺にいるのかが分かりません。マイルストーン(このタスクは必ず〇〇日までにできていないとダメ)が設定されていないと、今の状態が遅れているのかが分かりません。
日々の進捗管理もしっかりと行うこと
WBS作った後は、何をすればいいのでしょうか。
それは日々の進捗管理です。
これは重要なことなのですが、「報告は能動的には上がってきません」ということを心に置いておきましょう。
なにか困ったことがあっても、進捗が少し遅れているなと思っても、基本的に報告は上がってきません。こちらから聞くか、朝会などの場を設定する必要があります。
なので、本当にスケジュールが厳しいプロジェクトの場合は、毎日10分程度でもいいので簡単に進捗確認する場を設定するのがおすすめです。
何か起きたときのリスクヘッジも大切に
プロジェクトが順調に進むことは基本的には稀です。
プロジェクト管理する立場では、必ず何かが起きたときにどうするのか、ということも考えておく必要があります。
例えば、仕様の考慮漏れが発覚する、想定外の技術的課題が見つかる、などが起きたときにどうするのか、ということです。
事前にいくつかの引き出しを持っておくと、何か起きたときに迅速に対応ができます。
- 致命的な問題が発生した場合は、とりあえず上司に一報を入れる
- プロジェクトを管理する立場の人は、自分の報告・連絡・相談、の能力がある程度ないと後々炎上しますので注意が必要です
- 進捗が遅れている場合、追加の人員の確保ができるのかどうか
- 他の案件の兼ね合いで手伝ってくれる人を確保できる状態なのかを確認しておき、いざというときには誰々さんにサポートをお願いしよう、など
- 納期が遅れそうな場合は、早めにクライアントに相談して納期交渉をする
- 最悪、納期に間に合わない場合ももちろんあると思います。その場合は、クライアントに謝罪をして納期交渉をする必要があります。その場合、自分だけではなく上司も出席した場で謝罪する必要があり、いつまでならできそうなのか、なぜ遅れているのか、を丁寧に説明する必要があります。
見積もり？リソース管理？
作業の見積もりは非常に難しいので、正直なところめちゃくちゃ時間をかけても変更する可能性が高いので、ある程度概算でもいいのかなと思っております。
例えば、タスクAは結構難しいので約3日、タスクBはそこまで難しくないので1日、などで一度見積もりを作ります。
見積もりを作ったとに、タスクごとのスケジュールを引きます。
タスクには優先順位と方向性があります。
例えば、不確定要素が多いタスクは優先順位が高いです。想定外の時間がかかる可能性があるので、先に終わらせておく必要があります。
方向性とは、Aというタスクが終わらないと、Bというタスクを進めることができない、というタスクのことです。
この場合、Aというタスクがボトルネックになっており、Aの進捗が遅れるとタスクBのスケジュールに影響するので注意が必要です。
見積もりは少し多めにバッファを持たせて取りましょう。基本的にはスケジュールは早めに進むことはなくて、後ろに押すことがほとんどである、ということを意識しましょう。
見積もりが終わると、どのタスクを誰に割り当てるのか、という話になります。
誰かに少しチャレンジングなタスクをお願いした場合は、そのタスクの納期を少し早めに設定しましょう。
もし、その人が期間内にタスクが終わらなかった場合、誰かがそのタスクをカバーしないといけません。その期間を事前に頭に入れておきましょう。
単体テスト、結合テストも忘れずに
作ったものが想定通りの動きをするのか、をテストする必要があります。
当然見積もりにはテストの工数も含める必要があります。
テストをどのようにするのか、について詳細に解説しませんが、表でテストケースを作って、ひとつづつ確認していく方法が一般的かと思います。
また、テストコードの作成も有効な手段です。
テストを実施しないと、本当にその挙動をするのか、という保証ができません。
例えば、前はきちんと動いていたが、その後の改修で動かなくなっているかもしれません。
システムは巨大です。小さな修正でも想定外の部分に影響を及ぼします。
納品前にテストケースを一通り確認することで、その機能は間違いなく正しく動く、という保証ができます。
レビューは大事だよね
納品前のレビューはどのような形であれ実施しましょう。
仕様書の仕様がきちんと満たされているのかどうかは複数人でチェックしましょう。
WBSを引く場合も、必ずタスクの一つとしてレビューを含めて、レビュー後の修正期間も確保しておきましょう。
納品説明でお客様へお渡し
作っただけ、で終わるわけではありません。
作ったものを納品したのち、お客様側で内容の確認、検収という作業が発生します。
納品説明に必要な資料が存在する場合は、その資料作成もタスクとして挙げておきましょう。
最後に
あまりまとまった内容ではないですね。。。
コメントで質問頂ければ、できる限りは回答させて頂きます。
プロジェクトが炎上すると、だれも得しないので、いろいろな部分で予防策を講じておくことが大切だと思ってます。
Discussion