今更ながらWBSの重要性を説く
ご存知WBS（Work Breakdown Structure）
以前はプロジェクトキックオフまでに作成する事を義務付けられ、進行中も重宝された伝統的プロジェクト管理ファイルの一つだ。
現在Webでサービスを展開する事業会社でプロダクトマネジメントをしていると
この古典ファイルWBSを作成しているプロマネが少ない事に気づく。
代替手段としてのReadmineやBacklog、Jiraなどタスク管理ツールで補わられているように見えるが、個別のタスク管理とプロジェクト管理とは大きく異なる。
多いのが、保守など工数サイズの小さい案件（ここでは１，２タスクに近いようなサイズの意味）をそれなりに回して、いざ大きな案件（ここではタスクも去ることながらチーム横断や部署横断などのタスクが目的レベルでのみ連携しているという状態の意味）
を担当してみた時に、従来のタスク管理ツールで管理しようとする。
最初は各担当者と個別に対応内容、スケジュールなどを調整し、あたかも出だしはスムーズのように見える。
進行中も問題無さそうに思えていたら、とある担当者の遅れが複数の担当者へと影響が波及し、その場になってあわてて招集するとクリティカルパスだった。
なんてことも大いにある。
何が言いたいかというと、やってる人からするとそんなこと、というような事が
根本的に理解できていない、知らない、という教育の穴があるという事だ。
ここ5年で本当にシステム開発というものの敷居は優れたツールにより低くなった。
なんちゃってエンジニア、なんちゃってマネージャーでも小さいプロダクトであれば
モノもできてしまうし、運営もできてしまう。
そこに成功体験を積んだ次のチャレンジでプロジェクトを放り投げてしまうと前述している事が往々にして起こる。
タイトルはWBSという部分的な管理手段のみ取り上げたが、無くしてはいけない手段があるという事をしっかりと後に続く人たちに伝えていきたいと思う。
結果、不要でした。もっと良い管理手法が今はありますよ。
という事であれば、それで良いと思う。
今更ながらのWBSの重要性を説いた。
優先順位の明確化やっていますか？
あなたがプロジェクトマネージャーに指名されたとして、どの程度人材（リソース）確保に対して権限を有しているだろうか、もしくは関われているだろうか。
プロジェクトは常に並列で複数動いており、人数はあてがわれたとしても
他プロジェクトとの兼務につぐ兼務で、アサインメンバーの覇気が無い、鼻息が荒くなっているのは自分だけという事は私の経験だけのものではないはずだ。
このままスタートすると、自分の担当しているプロジェクトが動いていなかったり
頑張り過ぎる人が疲弊し、離脱してしまうといった懸念が拭えない。
『優先順位の明確化やっていますか？』
と題したのは、そんな経験のある、もしくはこれから同じ事態に陥りそうな際の
プロジェクトマネージャー目線でのリスクヘッジポイントを自戒の念を込めて残しておこうと思う。
１．人材配分に対する決定権を持つ人たちとの合意
⇒自分の思い通りに配分できれば良いが、並列稼動による固定費の逓減化を量りたい事もあり、人材の追加可能性は低い。
であるならば、相対的な優先順位を上げるというのがリスクヘッジの一つだ。
当然上位であればあるほど融通も利き易いし、上位であるが故の人材追加交渉はまだ可能性も出てくる。
その為にも、決定権を持つ人たちとの揺ぎ無い優先順位の合意は意味を成してくる。
ただし、この時にケースとしてあるのが、優先順位が低くなってしまったプロジェクトに関わる人達との軋轢だ。
面白く無い人もいるなかで、QCDの期待値コントロールを一緒に考える事は大事だと思う。そうして プロダクト観点での整理整頓ができれば心置きなく個別プロジェクトにもコミットできるというものだ。
２．合意した内容のプロジェクトメンバー全員との認識あわせ
⇒優先順位が決まれば、速やかにプロジェクトメンバー及び、先ほど述べたプロダクト観点であればプロダクトに関わる全員に方針として速やかに共有すべきだ。
得てして「聞いていない」も軋轢を生む。
そして軋轢は問題が顕在化してからマネージャーの耳に入る。
精神的安全性の担保はむしろマネージャーに必要だと思うが、このような種を蒔かない為にも、変化に順応しやすい環境と情報提供は重要だと思う。
１．２．共に至極当然の事だ。でも実際できていないのである。
変数が多い時代で、スピードも速い、何が正解かわからない中で模索する。
ただし、人間同士が仕事をする中で、核となる普遍的なやりかたは存在する。
当然おかれている状況、組織によっても進め方や課題感としての重みは全く異なると思うが、誰かのもやもやが一人でも解決できるなら本望である。
