見出し画像

チームリードのためのプロジェクトマネジメント_v0.01

はじめに

どうも、おゆです😋
新卒で外資系総合コンサルファームに入社し、いまはシニアスタッフとして働いています。

1年目から人手不足PJでチームリードを任され(任せていただき)、そこから失敗もたくさんしながら、チームマネジメントがどうあるべきかを考えつつ仕事を進めてきました。
また、体系的に知識を整理したり、知識の凸凹を均したりしていくことを目的に、理論的な部分もインプットしてきました(去年めでたくIPAのプロジェクトマネージャ試験に合格しました!)。

今回、現在のプロジェクトのロールオフにあたり、良いタイミングだなと思ったので、自分がチームリードとして気を付けていたことを箇条書き的に言語化しておきたいと思います。また強くなったら立ち戻ってこれるように・・・

賛否はあるとおもうので、皆さんの思うあるべきマネジメントについてぜひ教えてください!

※粒度は揃ってないです。構造化は気が向いたらします。とりあえずアウトプットすることが大事ですね(言い訳)

1.スコープ

  • スコープ管理=スコープ外を弾いてスコープを死守する、というよりもスコープを可視化してアラインするためのものとしてとらえる

  • スコープ外の作業依頼は、頼られている証拠としてとらえ、ポジティブに受け入れる(むしろ積極的にスコープを広げていく姿勢)

  • 一方スコープだけ広がっていってもリソースは必要なので必要なリソースを提示して握りにいく(=案件規模の拡大)

  • リソースは割り当てられないがスコープだけ広がる、、という事態は避けるようにする

  • 明らかに別チーム・別部署・別プロジェクトでやるべき内容についてはオーナーシップをもってつなげていく

2.スケジュール

  • スケジュールをたてるときは、逆算式・積上げ式両側面から現実的なラインを考える

  • クライアントや上司に対してコミットする部分と、コミットしない部分(=チームの裁量として管理させてもらう部分)を分ける

    • どうでもよい部分で遅延がどうで再発防止がどう、などというコミュニケーションコストを費やすことは双方にとってLose-Lose

  • スケジュールを立てる際は、マイルストンから考える

  • メンバーに割り当てるタスクの工数は、メンバーに見積もってもらうか少なくともメンバーが納得できるよう一緒に見積もる

    • 1:1.6:1.6^2の法則を意識し、メンバーのコミットメントを引き出す

3.コスト

  • 少なくとも自分の経験プロジェクトにおいて、コストの大部分=チーム全体の労働時間とみなせる

  • チーム全体の総労働時間の中でいかに効率化していくかを考える

  • プロジェクトとしての利益率や各種社内ポリシーを確認し、モニタリングの際の指標に組み込む(この辺りはまだ経験がほぼないけど、オーバーしてから詰められてるM+をみつつ気をつけなきゃなあと備忘的に記しておく)

  • EVMなどの考え方を参考に、進捗状況と残存工数をモニタリングしておくことで、早期に手を打てるようにしておく

    • どこまでかっちり管理するかは規模やリスクなどによる。大まかに見ておけばいい場合に工数をかけて細かく見る必要はない

    • 余命が長ければ長いほど打てる手の選択肢は広がる

4.品質

  • プロジェクトの進行上、そこまで重要ではないものについては、80点で妥協する

  • 過剰品質は個人としては目指すといいと思うが、チームやプロジェクトとしては害になる場合がある

    • とはいえ、ブランド価値という意味でも最低限の品質は意識する必要性がある

    • 進めばいいだろ、とアラインメントやフォントがガタガタの資料を出しちゃったりするのはNG

  • 品質が高い=クライアント・上司の満足度が高い、は必ずしも成り立たない

    • 期待値コントロールという言葉は個人的にはあまり好きではないが、実務上できるようになっておく必要性

  • メンバーへのフィードバックの際も、今回はXXXという状況だからこれでいいけど、XXXという状況の場合はXXXまでやる必要がある、などと説明をしておく

5.組織

  • 組織体制や役割分担はきちんと定義をすること(しようとすること)が大切である

  • R&Rの整備・適切なデリゲーションを行うことで、メンバーのモチベーションの維持向上につながるとともに、タスク遂行上もメリットがある

  • OBSとWBS/タスクや、共有フォルダなど、一貫性を持たせるように努める

    • 属人化を防ぐために、また責任の所在をはっきりとさせるためにも重要

  • とはいえ、サイロ化しないようなカルチャ醸成・コミュニケーションを心掛ける

    • 「うちのチームでやるべきことじゃないですよね?」といったコミュニケーションは丸投げというイメージをもたれるケースがあり好ましくない

    • できる範囲で手伝うけど、組織図的にはこっちでやったほうがいいですよね、という暫定処置と恒久対応を分けて議論していく

    • 例えば、Aチームの人がBチームがもつべきタスクを手伝うケースにおいて、Bチームの仕事を手伝っている、という建付けにすることを意識する

  • 建て付けがいけてねーな、上司のせいだ、という気持ちは痛いほどわかりますが、今できることを考えるべき。上司に現状の組織構造の問題点とあるべきをつたえ再編に動いてもらう

6.コミュニケーション

  • 適当な会議体を設計する

    • 会議不要論もあるが、個人的には下記の観点で有用と考えている

      • マイルストンとして機能させることで、タスク進捗管理が容易となる

      • メンバーにアジェンダレベルで進行を依頼することで、コミットメント向上・成長機会となる

      • クライアント・上司の生のリアクションを定期的にインプットすることで、品質をコントロールできる

      • わざわざメールすることでもないちょっとした情報が得られることで、新規提案やリスクの早期把握に役立つ

      • リレーションの構築

      • オンデマンドの会議調整コストの低減

  • メール・個人チャット・チーム・ドキュメントなどの特性を理解し、適切なコミュニケーションを心掛ける

    • 経験の浅いメンバーがいる場合は、なぜこの手段を使うのか?なぜこの人をCCに入れるべきなのかを言語化してフィードバックする

    • アサイン間もないメンバーの場合は、コミュニケーション前にレビューをする。指摘部分がほとんどなくなったタイミングでレビューを外す

      • この時も、なぜレビューをするのか?なぜこういう書き方をするのか?を言語化して伝えることで、キャッチアップ早期化を図る

      • 「面倒だとは思うんですが、一旦慣れるまでは送信前にチェックだけさせてください!」みたいな感じ

    • クライアント・上司から見た時にチームとして言っていることが微妙にずれていたりすると、不信感を抱きやすい。CCに入れてもらって送信後に訂正するやり方だと、メンバに対する信頼度が醸成しにくい(リーダーの工数はいつまでたっても減らない)

    • 共有フォルダやクラウドに管理表やスケジュール等を配置し、いつでも参照してください、こちらも最新に保っておきます、といった形で合意しておくことで、コミュニケーションコストを低減させるのとともに、透明性を上げ信頼を醸成する

7.リスク

  • 小さなチームであっても、「あれ、これ起きたらめんどそうだな」「なんかまだ固まってないけどXXが起きるらしい」のような気付きをえたら簡単な管理表などに起票をしていくことから始める

  • 上記をチーム内やクライアント・上司等に共有し、対策をかんがえつつモニタリングをしていく(「そういえばXXってどんな状況なんですかね・・・?」みたいな感じで聞き出していったり、予防策を実施していく)

  • 先に共有してモニタリングしておくことで、クライアント・上司からの理不尽な詰めを防止できる可能性が高い

  • あらかじめ積極的に動いておくことで、チームが不利な状況に陥らないように意識する

  • チーム外で発生した事象のせいで、自チームの状況が悪くなることはよく起こること。そういったことが発生しても、ネガティブな対応をとらない。むしろ、あらかじめ把握しておかなかったリーダーの責任である(くらいの心構えでいると精神衛生上もよい)

  • 他チームにも把握したリスクは共有していく

8.調達(主に人について)

  • 属人化を防いだ仕組みで回していくことで、突然の離脱・参画に備える

  • チームリードとして、メンバーが抜けてもすべての業務を巻き取れるようにしておくとともに、自分が何をやっているのかをメンバー・上司が分かるように可視化しておくことで万が一自分が稼働不可となった場合に備える

    • タスク管理表等に自らのタスクもきちんと起票しておく、ステークホルダーとのコミュニケーション履歴を共有する、たまにメンバーと一部のタスクを交換してみる、など

  • WBSやR&Rに基づき、要員に対する要件を言語化し、妥協可能なポイント、アサイン後の育成幅を考慮して調達を行う

    • 部屋探しのようなもの。すべての条件を満足することはできない

  • メンバーとの良好なリレーションを築き、早期に調達計画を練ることでよりよい人材の確保につとめる

  • チームリードクラスであっても契約条項を確認しておくことがリスク低減につながる

    • M+が強めであれば、やってはいけないことをきちんとあらかじめ連携してくれたり、アラートをあげてくれたりするが、全M+がそうしてくれるわけではない

    • 特に、契約形態・スキームにおける作業指揮権有無に留意

    • 新規雇用メンバの場合、雇用条件や雇用時に口頭で伝えている条件との乖離があると、エンゲージメントが低下するため留意する

  • 外部ベンダーやサブコンに手伝ってもらう場合、社内ポリシーや各種手続きを丸投げせずに、M+と一緒にすすめることで実態との乖離を防ぐことができる

  • 契約をまいたら一安心、ではなくコミュニケーションをとりつつモニタリングをしていくことが肝要(納期遅延やコスト超過、品質低下など、調達先のQCDが適切かどうかをみるのも我々の責任である)

  • クライアント常駐先への入室権限やID申請、端末貸与やカード発行のロジ周りはきちんとプロセスをまとめておき、周到にする。稼働日が減る=お金をドブに捨てている

9.ステークホルダ

  • クライアント

    • 部署・役職・名前・顔・声を早々に一致させておく

    • 各部署・クライアントの力関係を把握する

    • コミニュケーションの順番を考える(基本的には自分の対面から順に上げていき、スキップしない)

    • 合理性のみでクライアントは動いてくれないのがデフォルト。情理を駆使する。あくまで我々の目的はプロジェクトの推進による契約主体へのバリュー提供である

    • 基本姿勢としては、プロフェッショナルとしての姿勢が疑われるもの以外は全開示を心がける。クライアントとワンチームで進めていく姿勢

      • スケジュール、リスク、スコープ、体制、やっていきたいことなど出来るだけ透明性を高めていく。期待値コントロールにもつながるし、そこで生じるディスカッションにてよりよいものになっていく

      • もちろん開示の仕方、表現は要検討

      • 例えば、上司が寝坊してて、、とかメンバーがミスっちゃって、、などはNG。「別件で緊急対応が入ってしまい、本日は私にて対応させてください」「確認が不足しておりお手数をおかけしました。以後気をつけます」などと言い換える

      • 自分の株を相対的にあげるのではなく、会社として、チームとしてどうみられるのかを考えた言動を意識

    • 早めにクライアント対面とは良好なリレーションを築くようにする。チャットや1on1など小出しにやってみて、リアクション次第で深めていく

      • とはいえ、情報が対面と自分のみでクローズドにならないよう、要所要所での関係者ccメールや報連相を怠らない

    • 対面が契約主体でないことがほとんどだと思うが、あくまで我々は契約主体の利益の最大化でフィーをいただいているので、対面の意見に盲目的・全面的に従うだけではNG。むしろ対面をリード・説得していく気概を持つ

    • チャームを忘れない。自分の身の上話を少し挟んでみたり、ちょっとしたお土産を渡してみたり、相手を慮るような言動を心がけたり、などなど(もちろんパフォーマンスは前提として)

    • いい意味で対等な関係を築く。(そのためにはクライアントだけでは達成が難しいバリューを出さねばならない)

  • 社内

    • ボールを明確にする。インターナルだとぐずぐずになりやすい。期限までに返ってこないことはざらなので、見越してスケジュール設定する

    • 適切なリマインドをする。2回目は個人チャットでリマインドするなど、できるだけ味方刺しをしないようにする

    • それでも進行が困難な場合は、上のレイヤー経由で事態の解決を試みる

    • ベースとして、別チームには(にも)ギブアンドテイクを心がける。そのためには他チームが困っているときに積極的に手助けする。難しければ、少なくとも相手チームの状況をわかろうとすること

    • 概して社内には厳しい態度をとりがち(自分がそうだった)だが、自分のチーム外は全てクライアントと思うことでより円滑に進めることができるようになった

10.統合

  • 各種管理表を形骸化させず"きちんと"使っていく

    • WBS/マスタースケジュール

      • 上位階層についてはクライアントや上司と握っていくと思うが、下位階層についてはある程度緩みを持たせておき、実態に即して柔軟に変更していけるようにする(ローリングウェーブ的な形)

      • 全てがブレークダウンされて最初から最後まで完全なウォーターフォールで進められるのが理想だが、現実的には最初に決めたものからズレてしまうことは往々にして生じる。その乖離が形骸化を招くことが多い

      • 常に最新化し、どの変更の場合に報告するかを考えておく

    • Todo

      • 各々のタスク管理手段に任せるのみでなく、チームとしての現在のタスク一覧を可視化することは重要

      • 細かい規則や入力事項がたくさんあると、入力がだんだんと形骸化していく。入力すべきものはまず最小限にしておき、少しずつ必要に応じて欄を追加していく方法がよさげ

      • できれば、各TodoがWBSと紐づいている状態が理想だが、まずは起票して管理するという習慣を導入することが大事

      • 各タスクに主担当と副担当を設定し、引き継ぎの容易さと品質担保、コミットメントを促進するのも良い

      • 誰が何個のタスクを持っているかを可視化し、チーム内負荷状況をいつでもみれるようにしておく

        • 可視化しておくと、新規タスクが生じた際に負荷が一番低いメンバーが自発的に担当してくれることが多くなる効果もある

      • 終わったタスクを眺めるとチームで達成感を共有できてエンゲージメントに寄与する(かも)

        • メンバーのパフォーマンス評価の際も、担当タスクや対応履歴を一覧で眺められるので客観的評価をしやすい

      • タスクの対応履歴を日付ベースで書いていくことで、状況把握が容易になり引き継ぎも容易。レビューも楽

    • 課題/リスク

      • フォーマットはTodoと似た形で良いが、クローズできないものが多いので別表としておくのが良い

      • 課題の担当者を決め、課題に対する対応策をかんがえてもらう

      • リスクについては対応策検討次第、モニタリングをしていく

      • できればチーム外とも共有をしていく

    • 進捗サマリ

      • WBSやtodo表などで、半自動的に進捗サマリが見れるようにしておくとよい。パワークエリとか使えると捗る

      • 更新・共有の手間が出来るだけ少なくなるようにする

  • 管理表での管理を形骸化させないために、定期的に確認する枠を設定したり、入力負担が軽くなるように工夫したりしていく

  • リーダー自身が起票する姿勢をみせる。また、起票されてないことを発見したらきちんと書くようこまめに伝えていく

11.その他

  • 理想論だ、忙しくてこんなの全部できないよ、と以前は感じていた。しかし、こうあるべきだよね、でも現状こうだからまずはこれをやろうね、という姿勢が重要だとわかった

  • アジャイル的に管理手法をアップデートしていく。管理についてどうあるべきかをメンバーと議論し、自分ごととして捉えてもらう

  • メンバーに、わかってないな、とか常識だろ、とか思うことは多々あるかもしれないが、大抵は言語化しないと伝わらないし、仕組みがいけてないことも多い。自責思考でのマネジメントを今後も心掛けていきたい

おわりに

現時点での所感を雑多にかいてみました。思ったより長くなった…
チームリード初心者のみなさんにちょっとでも参考になったら幸いです🥺
逆にベテランのみなさん、これはこうしたほうがいいよ、などがあれば是非教えてください🙇‍♀️

また思いついたらどんどん更新していこうと思います〜

この記事が気に入ったらサポートをしてみませんか?