こんにちは、初めましてmatsuです。初投稿になります。よろしくお願いします。
弊社では技術系の投稿が多いですが、たまにはマネージメント系の投稿もどうかなと思い、今回スケジュール作成についてお話しします。
スケジュール作成について
どんなプロジェクトでもスケジュールなしで動き出すことはありません。
スケジュールが曖昧だったり精度が低いと、炎上プロジェクトになる可能性が高くなります。
では、どうやってスケジュールを作成していくのか、一般的なポイントに個人的な意見を踏まえてまとめていきます。
以下の順でスケジュールを作成、管理していきます。
目標とマイルストーンの設定
↓
タスクの分解と設定
↓
リソースの割り当て
↓
定期的な確認と調整
↓
ツールで管理
目標とマイルストーンの設定
はじめにプロジェクトの全体目標を明確にし、それを達成するための主要なマイルストーンを設定します。
こうすることで、進捗を段階的に確認でき、プロジェクトの方向性を見失うことがありません。
簡単に思えるかもしれませんがこれが意外と難しいです。
要因としては主に以下が挙げられます。
・要件の不確定性(あるあるですかね)
・技術的な複雑さ(先に検証は済ませておきたいところ)
・リソースの制約(納期という呪縛)
・コミュニケーションの課題(意外とみんな会話しない)
・変更管理(今回は対応しないという方針も十分あり)
これらの課題を克服するためにも、綿密な計画と柔軟な対応が求められます。
柔軟な対応と簡単に言ってますがまさに調整力を求められるところでありプロジェクト管理者の腕の見せ所?と思っています。
タスクの分解と設定
プロジェクトを小さなタスクに分解し、それぞれのタスクの開始日と終了日を設定します。この期間は2週間以内で設定するのが望ましいです。期間が長いと進捗遅れの際のキャッチアップが難しくなるためです。
昔々1機能をあるメンバーに3ヶ月で任せていたのですが蓋を開けたら全くできていなかったことがあり苦い経験があります。
逆に詳細ってどこまで詳細化すればいいのか?1時間で終わるタスクを設定するか?というとそうではないと思っています。
洗い出しとしてはいいですがそれらを集約し1つのタスクとして管理し、タスクの中で作業としてそれぞれ記載すればいいのではと個人的には思っています。この辺は匙加減だと思うのでそれぞれ管理者の個性ができるのではないかと。
またタスクの依存関係も明確にしておくことで、スムーズな進行が可能になります。
チーム間や他システムとの連携の場合は致命的になる場合もあるので特に気をつけましょう。
簡単なようですがいざタスクの洗い出しをしようとすると意外と難しい。
開発工程でもただ作成すればいいだけではなく、成果物に対してのレビューが必要だったり、その結果に対しての修正や再レビューもあります。つまりこれらもタスクになります。いや製造内に入るタスクでしょと言う人もいるかもしれませんが、あるメンバーはこれらのタスクもわかっているのでスケジュールもそのつもりで進めますが、別のメンバーはその認識がなくスケジュールギリギリまで実装し、レビュー期間が足りないと言うこともあります。つまり全員の認識齟齬が発生しないためにもタスクは詳細化すべきです。
メンバー | 8/23 | 8/24 | 8/25 | 8/26 | 8/27 | 8/28 | 8/29 | 8/30 | 8/31 |
---|
Aさん | 製造 | 製造 | 製造 | 製造 | 製造 | 製造 | レビュー | 修正 | 修正 |
Bさん | 製造 | 製造 | 製造 | 製造 | 製造 | 製造 | 製造 | 製造 | 製造 |
9人日で製造タスクのスケジュールを引いた場合、メンバーによる考え方の違い。Bさんのレビューと修正期間が足りなくなる。
さらに重要なのは、各メンバーのタスクは詳細化されスケジュールが組まれることが多いですが、PL、TLのタスクは詳細化されないことが多いため、そこも対象とすることです。
みなさんのプロジェクトでもなんだかいつもリーダーだけ忙しくしていることがあったりしませんか?
先ほど書いたレビューの話でもメンバー分のレビュー、再レビューをやるだけでもそこそこ工数を取られるのに、時間が取れなくてレビュー待ちみたいなことになっていませんか?さらには次工程の準備などやるべきことは多いのですが、製造部分以外って意外と詳細化されていないことがあります。
上位層のタスクを最初に洗い出せていないと、プロジェクトが円滑に進まない可能性が高く、高稼働や作業負荷になり、離任リスクも高まります。
とはいいつつも、完璧に洗い出せるケースは少なくちょくちょく追加タスクが発生してしまい毎回申し訳なく思います。
リソースの割り当て
詳細化した各タスクに必要となるリソースを割り当てます。
そのためには正確な見積もりが必須となります。
何も考えないで工数、工期で各タスクに当てこんでいけばいいというわけではないのです。
個人的には最重要なのではと考えています。
がこの話は長くなるので「見積もり」「リソースの割り当て」については、後日書けたらと思います。
この2つは一般的なやり方が通じないもので、考え方も個性が出ると思っていますので一番面白い話になると思います。
定期的な確認と調整
最初に詳細化したスケジュール通りに進むのが理想ですが、実際はそうはいきません。
スケジュールは固定されたものではなく、プロジェクトの進行に応じて柔軟に調整する必要があります。
各タスクの進捗状況や追加タスクの発生等を定期的に確認し、必要に応じてスケジュールを更新をしましょう。
この調整をするのがPM等のお仕事だと思うのでみなさんは遠慮せず正しく速やかに報告しましょう。
ちなみに、PMが「なんで遅れてるの?」と聞くのは怒っているわけではなく、原因を正確に知りたいだけです。
中にはメンバーが勝手に仕様変更を受けてて進めてたってこともありました。
しかし進捗報告も難しいですよね。今50%終わっていますと言っても定量的に出しているわけではなくあくまでも感覚値ですからね。
この「進捗率を正確に算出するには?」もいずれ別でお話できればと思っています。
ツールで管理
みなさんはどんなツールで管理していますか?
ExcelやGoogle スプレッドシートが多いでしょうか。
柔軟性があり、どんなプロジェクトにも対応できるので使われています。
Excelは共有するとファイルが破損しやすいので、Google スプレッドシートの方が共有には適しているでしょう。
他にもJIRAやAsana、Trelloなどの有名なツールがありますが、少し高価です。
使えれば有料のツールを、なければExcelやGoogle スプレッドシートを使うといった感じでしょうか。
規模によっても使いやすい、使いにくいがあると思います。
前に大規模プロジェクトでJIRAを使っていましたが紐づくチケットが多すぎてガントチャート開くのに毎回数分かかっていたことを思い出しました。
いずれにしても管理対象となるプロジェクトやチームによって適したものを利用するのでよいと思います。
またツールで管理するのはいいのですが、どのツールでも更新していかないと意味がありません。
勝手に進捗は変わりませんしステータスも同様です。
毎回進捗定例前に猛プッシュして更新してもらったりと。。。
この辺りも開始前にプロジェクト関係者全員に徹底させたいところです。
さいごに
初めてのブログでしたが、大枠のお話だったので結構テンプレに近いことしか書けませんでした。
マネージメント系の資格や参考書を見ていると同じようなことが書かれています。
ではこの通りやれば失敗はないのかというとそんなことはなく、最初に挙げた課題次第で失敗することが多々あります。
途中にも描きましたが、後日記載予定のテーマは各管理者の個性?が出ると思うので、その際は私個人の主観がいっぱい入ってくると思います。※私が正しいとは思っていないのでみなさんの意見も頂戴したいところです。
また技術者に比べてマネージメント業務を担当する人の数が少なく、日々どういうふうに考えているかみたいなことをディスカッションする場が少ないので、この場を借りて勝手に自分はこう考えているを発信できていければと思います。
次回もよろしくお願いします。