$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

「リモートワークの達人」読んだ

最近ほとんど全員がリモートで働くことになり、今までのやり方ではそこそこ困っているので読んだ。

「いやな言葉」「感情的な対立」「悪いムード」を徹底的に排除する

という部分が非常に良い言葉だなあと思う。

読書ノート

* 毎日4時間はみんな同じ時間に働いたほうが良い。コミュニケーションもうまくいくし、チームの一体感が出る 688
    * 気づき: フレックスのコアタイムも4時間は被せる
* 進み具合を共有するために、週に一度「最近やっていること」というテーマで話し合いの場を設ける。この1週間でやったことと翌週にやることを手短に書き込んでいく 788
    * 気づき: 書き込みでやっていくの、スプリント会に導入しても良いかも
* リモートとは単に遠隔地という意味ではなく、時間と場所に縛られない働き方 814
* リモートで世界的な視野を手に入れれば、顧客によりよいサービスを提供することに繋がる 1087
    * 気づき: 多様性を上げやすくなるということかな
* リモートだとむしろチームの雰囲気を盛り上げてくれるような人柄が重要になる 1133
    * 文字だけでやり取りする時、人は悪い方に流されやすくなる
* リモートワークをマネジメントするときは、棘のあるコメントや逆ギレの反応などの小さな行動をひとつひとつ注意していく。割れ窓にならないように 1142
    * 最終的に社員全員がおたがいに指摘できるようになると効果的
    * 「いやな言葉」「感情的な対立」「悪いムード」を徹底的に排除する 1151
* 地域で賃金差別をしない 1211
    * 気づき: 家賃手当とかでも同じようなことになるので注意する
* 候補者の仕事ぶりを知るためのベストな方法は、本格的に採用する前に1~2週間お試し採用をして、給料を払い、小さなプロジェクトをやりとげてもらうこと 1284
    * 現在働いているなら副業的にやってもらうでも良い
* リモートでは働きすぎをふせぐため、あえて休暇を増やすなどをする必要がある 1536

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

マネジャーをやっていると、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