プロジェクト管理はどうしたら良いのか　Udemyから学んでみる

この記事で伝えたいこと

プロジェクト管理をするのが初めての人が、どのような手順を踏んで取り組む必要があるのかもわからない。そんな人が大まかなステップを理解してプロジェクト管理を進めることができることがゴールとなっています。

記事を出す理由

僕自身が、プロジェクト管理という観点でPJに関わったことが少なく、どのように動けば良いのかわかりませんでした。

そのため、新人リーダーのためのITプロジェクト管理を学習して、自分なりの言葉でまとめてお伝えします。

もしこの記事がよかったらぜひUdemyの講座も実際に購入して試してみてくださいね!

リーダーとしてどのように振る舞い、行動するべきなのか

リーダーに求められること

計画

リーダーの役目としては計画を立てることにありますよね!
計画とは以下を指します

• いつまでに
• 何を
• どのように

また方針やルールを決めるのもリーダーの役目ですね

計画をするときに必要なのは全体を見ることです(これがむずい)
次に発生しうる問題や課題を事前に潰していく必要があります。例えば、次のフェーズでは〇〇の申請が必要だから準備しておこうとか、調査がいついつまでに必要だから準備しておこうなどです

必要となれば事前に準備しておくことが大切ですので、常に先を見て動くことを意識しましょう。見るのはゴールであって目の前の作業だけやっていたら地雷を踏んじゃいます

また、計画を決めたら最終的には関係者に合意を取るのもリーダーの役目なのでお忘れ無く!

実行管理

実際に計画を立ててもそれを実行しないといけません。

スケジュールに沿って実行していくこと。そして、計画からずれないように管理することが大切だとされているんですよね

計画通りに行っているのか?
もし計画通りにできていないなら、原因を見つけて対策を打つ必要がある。この課題や問題の発見を早期に見つけて打ち手を出していくことを常に意識してみましょう

事前に課題を見つけられる人はすんごい重宝されるかと思います。←これが一番難しいので

これは現場でもよく意識しろっていわれているな…常にリスクを考えて事前に打ち手を出せって

WBSの作り方

計画を立てるときにはWBSは不可欠ではないでしょうか?

WBSとは作業を分解したもの
ガントチャートは横軸に日付を追加したものを指します。

WBSを分解した後に、その分解した結果のワークフローを考えつつ、時間軸も考慮したものをガントチャートとする。　

ガントチャートでは以下のような項目が必要とされているので意識してみてください

• タスク
  • 担当者
    • 作成者
    • レビュー
  • 予定
    • 作成(開始、完了、工数)
    • レビュー(開始、完了、工数)
  • 実績
    • 作成(開始、完了、工数)
    • レビュー(開始、完了、工数)

ガントチャートを作成する時の流れは以下です

作成の流れ

1. 成果物、タスクの洗い出し
2. タスクの依存関係整理
3. タスクの見積もり
4. 調査
5. 方針検討
6. タスクに対して、人と日付を入れる

注意点
WBS作成において、変数は無数にあるので、必要に応じて修正していくこと前提に進めましょう!

タスクの洗い出し

ここでは基本的に要件定義以降とした際を想定しますね!
タスクを洗い出すためには機能一覧、もしくは要件定義の資料をもとに洗い出して作っていきます。

現場によると機能一覧など正式なドキュメントもない可能性があるので要件定義に出てきた資料をもとに何が必要なタスクなどを頑張って洗い出しましょう

また方針など、共通化したいものもしっかり洗い出すのを忘れずに!(セキュリティ、認証など…)

タスクの実施順

依存関係
タスクは上から順番にやれば良いわけではないので、共通機能や流れがあるものなどを考慮してくださいね

効率化
また、類似機能を作る時には、どの機能をベースにするのかなども考えて、コピー先の機能は後で実装するなど効率よくプロジェクトを回せるように依存関係と合わせて効率的にはどうすればよいのか?というのを考えてみましょう!

工数見積もり

自分は工数の見積もりが結構苦手なんですよね…
どうしてもあーこれなら〇〇日でできるな。とか考えていても、結構遅かったりするんです。←実装スピードあげてぇええええええええ

その工数を見積もりをする時には次のようなことを意識してみてください!

作成フローを意識する
まずは、自分が作成するイメージをします

• どれくらいのページ数必要？
• 成果物は何があるのか？
• etc…

見積もる時はアバウトで良いです

ここで大切なのは、できるだけ細分化してあげるというのは考えましょう。
3~5人日になるようだったら分割すると良いそうですよ。
なぜなら、１つのタスクが長くなってしまうと進捗がわかりにくくなるので管理側が大変だったりします。
また進捗が分かりにくいことで、、実装者も大変なので、できるだけ細かくするのをタスク分解時には意識してみてください!

あと注意点としては、毎日8時間働けるわけではないというのは認識していてくださいね!

なぜなら各自、他の仕事もあるので実際に作業できる時間は限られているので毎日8時間とは考えない方が良いでしょう

優先度

また、優先度も常に考えることが求められるでしょう
そこでは期日と重要度を意識することが大切っす

重要度とは、要件にあるコア機能、タスクの依存関係などを考慮して出される度合いを今回は指します。

ちなみに、期日と重要度どっちも大切なものが出てきたら、重要度が高いものを優先した方がよさそう！

結局大切なことだから!

進捗確認

進捗管理では基本的に、着手しているかどうかも大切ですが、一番は完了しているかどうかが大切となっています!
なぜなら、途中の進捗などに関しては個人の尺度でしかないからですね。

ただ、大切にする必要があることがもう一つあって、それは遅延はないか?ということです。遅延するにも2つあって、本人の進捗が悪くて遅延するケースと、他のタスクの依存関係による遅延です。

他タスクが原因で遅延が発生する時
そんな時にはどのような対応が必要でしょう?他チームが原因であれば、リーダー、PMから別チームに対して声をかける必要がありますし、他にも正式なうち合わせの場でメンションするなどがあります。

もし、自分のチーム内のタスクが原因であれば、声かけが大切ですし依存関係を考慮して進められなかったのも原因ですのでチケットの見直しなども実施しするのが良さそうですよね。

正しい報告を受けるために

リーダーとして大切なのは、遅延をなくすこともそうですが、他にも遅延を正しく報告してもらうということもあります。

• 基本的には完了かどうかをチェック
• 着手遅延はないかを確認
  • 他タスクに依存しているケースがあるから

遅延が分かった時にはどんな行動を取れば良いのか?

• 原因と対策を考える
  • その時には、正しい報告を受けるようにリーダーは工夫をする必要がある
• 原因と影響
• いつまでにリカバリ可能か

常に課題があれば、それには複数の原因があります。その原因に対して複数の打ち手があります。その時の最適な打ち手を出していくのがリーダーとしては必要ですよね

もし、何か問題があった時には何が原因なのかをしっかりヒアリングする必要があるんですよね。
遅延しているところは「なにに困っている?」「どこに困っている?」という聞き方が良いでしょう。高圧的に聞いちゃったらいいこと一つもないです。とにかく相手の立場に立ちましょう

遅延の時にはまず正しい報告を受けれるようにしましょう。

どこかがボトルネックになっている場合には以下対応が必要です。

• 正式な場所で伝える。
• 問題があるならエスカレする。

品質管理

開発工程では静的テストを実施します。GitHubとかでやるPRとかは静的テストのことを指します。
また、テスト工程でのテストは、動的テストという風な呼び方になります。

テストに必要なのは、最終的な結果報告から何が必要かを考えて逆算することですね
←最終的に必要なものは何か考えるのはテスト以外でも必要ですよね〜

設計工程の品質分析は非常に重要です
上流で不具合を摘み取っておくことができればできるほど手戻りがなくなるので無駄な工数が削減されます。

品質評価の際には、常に問題を見逃しているでは? という観点で確認しましょう。どうしてもチェックする時には、「いけてるやろー」って思っちゃうので、絶対なんかバグってるから。って気持ちでテストするのが必要です。

ここでは嫌な奴になっちゃいましょ!
「バグ見つけたろっと」みたいな

ここで問題が発生した際には暫定対応と、恒久対応の2つを考える
障害、課題が発生した場合には、なぜなぜ分析をして何が原因だったのかを考えます

リーダーとしては、最後の確認をして責任を取ることが必要です
不具合が上がってきた時は、自分の言葉で理解できるようにしてください。
原因、対応に関しては自分の言葉で説明できるようにしておくことで上部に報告する時にもしっかり説明できますよね。

それがリーダーなんです!!!!!

課題管理

問題は現状とあるべき姿のギャップ

QCD

• 質
• 量
• 時間

問題が定義された後に問題を解決する方向性、方針のことを課題という

リスクは潜在的かつ、不確実性のある事象

課題チケット

チケットを切る時には以下の注意点を意識して切ってみてください

• 問題が明確か
• 課題(論点)が定義されているか
• 解決に向けた道筋が立っているか
  • 問題解消に向けたToDo、タスク
    • 5w1h
    • 誰が、いつまでにを意識

メンバーへ課題の振り方は次を意識しましょう

• メンバーのレベルを意識して課題を振る
• 複数にフル
  • アウトプットを定義する
  • アウトプットを出す手順を教えてあげる
• どのフェーズでチェックしてあげるかはメンバー次第で考える

課題処理の優先決めはQCDを意識します!

課題が溢れた時

結局プロジェクトを回していたら、課題って溢れちゃいますよね
なので困った時には改めて、課題の優先度を見直して、誰が何をするのかを考え直してみてください

振り返り

プロジェクトが完了した際にはぜひ振り返りをするまで意識してください!
振り返りを終えるまでがプロジェクトです!!!

• フェーズ単位で振り返る(人は最初を忘れるから)
  • フェーズ開始時点で振り返り用のExcelを準備する
  • フェーズ内で振り返りを行う

良かった点、改善したい点を途中で挙げてもらいましょう
振り返り会の前にまとめる
よりよくするとめ、再発させないためにどうするか
具体的な改善アクションをタスク化しておく

• 種別
  • 進捗管理
  • 品質管理
  • 課題管理
• 懸命
• 概要
• 記入日
• 記入者
• Good/Bad
• 原因
• アクションプラン
• チケット
  • 実施されるような仕組みを作るように
• 備考

振り返りは、仕組み化することが大切なので意識
仕組みが増えた時には、断捨離しよう

• Keep
• Problem
• Try
• Action
  • 最終的に行動に移すもの

まとめ

結局色々まとめてきましたが、リーダーは難しい!

常に先を見て課題、リスクに対して打ち手を出して、プロジェクトをスケジュール通りに進める必要が出てきます。

これができたら困らんけど、これがなかなか難しいのよなあ…