部下の困りごとをマネジャーが解決しすぎない方が良い

マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと！」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。

これを続けていると、例えば

• 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある
• 部下の問題解決能力、相談能力などの向上機会を奪ってしまう
• 細かい問題を解決しているだけで時間がなくなってしまう
  • 結果的にスケールもせず、解決に取り組めない問題が増えていく
  • 本当に解決すべき重大なチーム課題に取り組む時間がなくなる

などといったことが起こりうる。こうなると実際には自分が色々問題を解決できていると満足感を得られているが、チームは良くない状態に向かっていく。

ではどうするか。僕は基本的には部下に困りごとを解決してもらうという前提を持った上で、問題を場合分けして、対処を変えるようにしている。

• 例えばメンタルに強いダメージを受けているといった緊急で重大なものは、マネジャー側で一気に解決する
• 少し大きめな問題は、部下と一緒に取り組む
  • アクションを出す時に、部下が取り組むアクションと、マネジャーが取り組むアクションの2つを考えるとか
  • オープンな場で議論してOKなものなら、小さいプロジェクト化をして、部下に担当大臣になってもらうとか
• 小さな問題は、部下に解決策を考えるところも含めて取り組んでもらい、自分はサポーターくらいになる

また、もちろん部下の問題解決能力の習熟度に応じて、本人にやってみてもらうか否かは調整する。全く手が出ないわけではないけど挑戦的な問題解決をやってもらうことで徐々にスキルを伸ばせるというのが一番ベストだろう。この辺の塩梅をうまくやるはマネジャーのスキルと言える。

こうしていくことで、徐々にチーム内の問題解決スキルも向上していき、より改善や提案が自発的に行われるチームに育っていくのではないか。

参考文献

うまく部下に問題解決していってもらう時はコーチングというスキルが役立つことが多い。以下昔紹介した本たち。こういう書籍を元に技術組織のマネジメントやメンタリングをしている。

blog.shibayu36.org

「プロジェクトマネジメントの基本」読んだ

プロジェクトマネジメントをちゃんと学ぼうシリーズ。今回はプロジェクトマネジメントの全体像を知るために、「プロジェクトマネジメントの基本」を読んだ。

プロジェクトマネジメントの基本　この１冊ですべてわかる

PMBOKなどの情報を知ることができ、アジャイルやスクラムなど現代の開発フローへの流れを理解できたのが良かった。その中でもこれまではあまり視点を向けてこなかったステークホルダーとの関わりや、リスクとの関わりについての話が興味深かった。

読書メモ

* プロジェクトマネジメントですべきこと 289
    * 企画段階
        * 1. プロジェクトのゴールを明確にし、達成シナリオを考える
        * 2. ステークホルダーを見極め、そのプロジェクトへの期待を理解する
        * 3. ステークホルダーの期待をすりあわせ、プロジェクトの成功を定義する
        * ステークホルダーとのすりあわせがうまくいけば協力してくれ、うまくいかなければ足を引っ張ろうとする
    * 計画段階
        * 4. 成功に必要な成果物を明確にするとともに、すべき仕事を明確にする
        * 5. スケジュールを決める
        * 6. 成果物と予算、スケジュールのトレードオフを調整する
        * 7. プロジェクトを取り巻くリスクを最小化する
        * 8. プロジェクトの計画をドキュメントにする
    * 実行と進捗管理
        * 9. 進捗計測の基準を決め、進捗を管理する
        * 10. パフォーマンスの高いチームを創る
        * 11. ステークホルダーとのコミュニケーションを行い、良好な関係を保つ
    * 終結
        * 12. プロジェクトで学んだことを整理し、組織内に水平展開する
* プロジェクトマネジメントの流れ 495
    * [image:1CC137A2-D1E6-4CCA-84D5-C9A5CEAE0C8F-28287-000006D10620CDFF/写真 20201116 93336.jpg]

* プロジェクトマネジャーに必要なリーダーシップとは、プロジェクトに関わる人（チームメンバー、スポンサー、ステークホルダー）への影響を通じて 496
    * 1. プロジェクト価値を創造し
    * 2. 重要な目標について実現体制を構築し
    * 3. 必要な人材能力、および、チームを育成し
    * 4. 計画実行のための課題を解決して、プロジェクト目的を実現に導く行動である
    * 最も重要になるのが、プロジェクトスポンサーを通じて上位の組織を動かすこと
* リーダーシップ行動
* プロジェクトを成功させるポイント5つ 537
    * 1. ゴールの共有
    * 2. ゴールまでの道のりと責任の計画化、および計画に基づく管理
    * 3. 的確なスコープのコントロール
    * 4. コミュニケーションの活性化
    * 5. 上位組織によるプロジェクト支援
* 共有したい範囲のステークホルダーがwin-winの関係になれるように、プロジェクトのゴールとして 546
    * 上位組織のミッションへの理解が反映されたゴールになっている
    * 顧客の価値が理解され、実現されていること
    * プロジェクトの成果がチームのビジョンと関連していること
    * 気づき: ゴールの条件が明文化されたのはありがたい
* 上位組織を見方だと考え、なにか事情があるんだろうと考えてコミュニケーションを取ることで、初めてステークホルダーの協力を取り付ける事ができる 683
* 目的と目標 1631
    * ゴールが意味するのは「目的」と「目標」がある
    * 目標と目的の間には、複数の「目標の達成」によって、「目的を実現」するという関係がある
    * 目標には達成目標と行動目標がある
    * 「6ヶ月で商品開発をする」「シェア〇〇%を取る」のような達成目標だけでは言いっぱなしになることがあるので、「〇〇のデザインに500時間かける」のような行動目標を立てる
* 戦略ゴールの正体は「目的」「達成目標」「行動目標」の3つ 1676
    * 気づき: リーンキャンバスやインセプションデッキ、5W2Hなどは、これらを明確にするツールの一つと言える
* ステークホルダーを探す視点 1900
    * 気づき: これを元に隠れたステークホルダーを探すのは良さそう
* ステークホルダーの性質4種類 とコミュニケーション態度1933
    * チアリーダー: 支援の重要性が低く、コミットメントも小さい
    * 完全参加: 支援の重要性が高く、コミットメントも高い
        * 信頼を得て、一層の協力を引き出すために、オープンなコミュニケーションを心がけ、プロジェクトメンバーと同じ情報を常に提供し、要になる意思決定では必ず意見を求める
    * 良心的兵役忌避者: 支援の重要性が高いのに、コミットメントが低い
        * プロジェクトの成功はこのタイプのステークホルダーのコミットメントをいかに高めるか
        * プロジェクトの成功が相手にとってどれだけ意義のあることかを説得し続ける
    * 熱狂的支持者: 支援の重要性は低いが、コミットメントは高い
        * ある意味厄介。何かと口出ししてくる
        * 機先を制し、プロジェクトから、ひょっとすると役に立つかもしれない手や作業を依頼する
        * プロジェクトとして役立っていることを認める
        * コントロールするためにオープンなコミュニケーションは好ましくない
        * 扱い方を間違えると敵対するので注意
* プロジェクトの目的の中にきちんと織り込みたいもの 2015
    * 1. 上位組織、プロジェクトスポンサーの目的
    * 2. プロジェクトオーナーがこのプロジェクトに関心を持つ理由
    * プロジェクトマネジャーやプロジェクトメンバーがこのプロジェクトに参加する理由
* プロジェクト構想のための5つの質問 2039
    * プロジェクトのミッションは何か
    * プロジェクトのステークホルダーは誰か
        * プロジェクトの顧客となるステークホルダーは誰か
        * プロジェクトのパートナーとなるステークホルダーは誰か
    * ステークホルダーにとっての価値は何か
        * 顧客となるステークホルダーにとっての価値
        * パートナーとなるステークホルダーにとっての価値
        * ステークホルダーに学ぶべきことは何か
        * どのようにしてステークホルダーに学ぶか
    * プロジェクトにとっての成果は何か
    * プロジェクトの目標は何か
* プロジェクトのリスクの見方
    * プロジェクトの目的実現そのものをあやうくするリスクと、目標達成を危うくするリスクのどちらか 2125
    * 計画に対するリスクなのか、プロジェクトそのもののリスクなのか 2153
* リスク戦略 2663
    * リスク回避、損失軽減、損失予防、リスク転嫁、リスク受容
    * 危険衝撃度と危険発生確率のマトリクスの位置によって戦略を変える。レッドゾーン（衝撃高発生高）は回避/転嫁、グレーゾーン（衝撃低発生高）は予防、イエロー（衝撃高発生低）は軽減など
* コミュニケーションルールを決めるときのポイント 2707
    * コミュニケーションの種類、発動の基準、発動者、受動者、タイミング、機会と方法、受動者のとるべきアクション
* メンバーにプロジェクトを納得させるには、期待を語ることも必要 3145
    * 期待には、プロジェクトマネジャー自身の期待もあれば、もっと上位の組織の期待もある

最近読んだプロジェクトマネジメント本

blog.shibayu36.org blog.shibayu36.org

「デッドライン」読んだ

最近プロジェクトマネジメントをちゃんと学ぼうと思って色々読んでいる。今回はデッドラインを読んだ。

デッドライン

読み物として普通に面白かった。また「チームの結束については、既存のチームを探して利用する」「新しい仕事を引き受ける意欲のある結束の固いチームは、プロジェクトの成果の一つとみなす」辺りは新しい観点に触れられたと感じてよかった。

読書メモ

* 脅迫は、結果を挙げさせる手段としては不完全である。どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない 823
    * 気づき: 「もう少し〇〇してほしい」というのも一種の脅迫だと思う。それをやりたいと思うような理由をうまく作る必要がある
* 新しく採用した人材には、1回は実証済みの能力レベルのプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする 1197
* 最も採用したいと思った人物は、ほかの優れた人材を知っている可能性が高い 1197
    * 気づき: 採用後すぐに、リファラルを求めるというのは良いかも
* チームの結束については、既存のチームを探して利用する 1560
    * 新しい仕事を引き受ける意欲のある結束の固いチームは、プロジェクトの成果の一つとみなす
    * 気づき: 別プロジェクトにいたペアをそのまま次プロジェクトのペアとする方法が良いことを知った
* 相手を好きになり、気づかわなければ、人にちがうことをさせることはできない。相手を変えるには、相手の考えていることとその理由を理解し、尊重しなければならない 2934
    * 気づき: よく軽んじてしまうので戒めなければならない。「人を動かす」とかも読まないといけない
* 仲裁はわずかな投資で学習できる 3837
    * 気づき: どうやって学んだらいい？
* 理想の人数配分は、プロジェクトの期間の大部分を少人数のコア・チームで行い（特に初期）、プロジェクトの終盤に人数を大幅に増やす 4149
    * 初期に人数が多いと、重要な設計作業を省略せざるをえない。設計が完成する前に大勢に仕事を割り当てると、人や作業グループの間のインターフェースを最小化できない
* プロジェクトには目標と予想の両方が必要だ 4841
    * 気づき: 意欲を高めるための目標と、実際の締め切りみたいなのは別でも良い

最近読んだプロジェクトマネジメント本

blog.shibayu36.org