2019年7月31日水曜日

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

いろいろいいことが書かれている。
章ごとに良い上司悪い上司を上げるなどして対比でわかりやすく解説してくれるので良い。
そんなにたくさんの章があるわけではないので章ごとにまとめていく。

マネジメントの基本

1on1は、多少は私生活に触れること、また、検討事項を定期的に議論すること。定期報告ならメールとかでもよいかも。
フィードバックを求めよう。また、アドバイスを求めるのはおだての効果もあるので聞くのは悪いことではない。
上司は、トレーニングや社内の人を紹介する必要がある。

メンタリング

傾聴するのは当たり前。明確に何を期待しているのか?何を成果としてだしてほしいのか?を伝達する。
人脈づくりの一環でもある。
アルファギークがメンターや上司になると最悪。アルファギークは、簡単にいうと自分が一番頭がよくて他はみんなおろかで、愚か者は公然と侮辱しても許されると思っている人。実際にいるので、人の管理などにはかかわらせないことが大事。
メンターをつけるのであれば、その目的とゴールを明確にしよう。

テックリード

テックリードは、会社によっても違うけどEMみたいな感じもある。ただ、人の管理はしない可能性もある。
テックリードに求められるものは、各メンバーとの1on1、各メンバーのキャリアアップや作業状況のsyncと改善を行う、各メンバーの能力開発に協力する、である。
テックリードは、システムアーキテクト、ビジネスアナリスト、プロジェクトマネージャーなどの役割も担うことがある。
プロジェクトの管理の簡単なコツは
・複数の工程に分割すること
・細部への引っ掛かりや道の要素にくじけない。
・プロジェクトは調整しながら進める
・変化に対応する
・プロジェクトの終盤では最後の詰めをする(premortemとか)
プロセスは、チームのニーズや目的を満たさなければならないという前提をきちんと理解する必要がある。
プロセス警察みたいなことはしてはならない。

人の管理

信頼関係や親近感を構築するために1on1は行おう。
新しい部下には1ヶ月、2ヶ月、3ヶ月の計画を建てさせる。
オンボーディングのドキュメントはきちんと整備して新人に更新してもらう。

1on1では、ドキュメントできちんと記録をとろう。
部下から、話し合いたいtopicを上げてもらう。
四半期ごとにフィードバックを行おう。
管理職どうしなら、経過報告もあり。

管理職を育てるのであれば、
・自分が出たほうがよいMTGを新人管理職と相談して決める。
・詳細を報告してもらったほうが良さそうなものを一緒に決めて進めていく。

実践としては
・成功とは何かを定義して、そのための数値の収集方法を提示してもらう。一緒に作る。
・システムから情報を収集する。
・プロジェクトの状況に合わせて収集すべき情報を修正していく
・基準を設ける。修正後に単体テストをどの程度加えるべきか。など。

情報は常にオープンにするほうが良い。

継続的なフィードバックが当たり前になるように継続し続ける。
フィードバックの内容自体は、
・1年全体に目を向ける。
・具体例を上げる
・長所も上げる
・改善点は簡潔に記述する
・決して驚かせてはいけない。定期的なフィードバックを行いながらいきなり悪い評価に驚くようなことはしてはいけない。

ローパフォーマーがいる場合は、改善計画を立てる。
何がダメで、どうなったら良いのか?いつまでそれを行うべきなのか?それを明確にして短い期間でのフィードっバックを行う。その際に、人事などにも入ってもらうのが良い。

チームの管理

ITスキルの維持には気を使おう。
人間関係の問題は早めに手を打とう。様子を見ても大抵は改善はしない。
過労には気を使う。ある程度期間が過ぎたら継続性を重視する
息抜きも大事なので飲み会や雑談は行うようにしよう。

チームが意思決定をできるように支援するには?
・データ重視にする
・顧客とは誰で何を求めているのかを明確にする
・将来のことも考えておく。
・意思決定の振り返りを行う。
・選択肢を提示して、意見や情報などのフィードバックを求める

問題行動のあるメンバーには早めに対処する。
何が問題かを明確にして、あまりに無礼であれば全体の前で批判することの重要になる。
その場合は、上司に相談するか人事に相談する必要があるだろう。

複数チームの管理

時間管理と優先順位付けはきちんとしなければいけない。
重要でない緊急の仕事に惑わされてはいけない。
頻繁な仕事は基本的に難しくても簡単でも移譲したほうが良い。
なぜならボトルネックになるから、難しい仕事はフォローしながらも任せることが重要。
頻繁でない複雑な仕事の代表は、勤務評価や人材募集計画だ。それは移譲していった方がよい。

なにか許可を求めてきた場合に、何回も同じことを言っていたら、ポリシーを決めるときが来たと思うべき。

チームの健全性は数値でみる。deploy頻度、インシデントの発生頻度、コードの生成量など。

チームのアイデンティティに、メンバーの得意なものを求めない。求めるとイングループが生まれる。

良いチームは
・リーダーがいなくなっても立ち直れる
・目標を駆動条件にする
・直属の部下ではなく、自分と同じレイヤーの人がチームであると認識する

複数管理者の管理

・スキップレベルミーティング
現状のプロジェクトの状態を現場から知ることと、うまく言っていない上司がいるのかを見極めることにもなる。
・責任を課する
どんな責任があるのか、何を明確に伝える必要があるのかを明確にする。上司が喜ぶことだけを言う人は実際にいるので、その人から情報が吸い上げられるようにしよう。

問題のある管理者がいた場合、その人の苦手な部分を手助けしてくれるような人をサポートでつけるのもありだ。例えば、プロジェクトマネージャーとか。


率直に言って、経営幹部の章と文化の構築については概念的な話が多いように思う。
だが、キャリアラダーをどのように作るのかなどは参考になるし、自分が管理職になってキャリアラダーに明確さがなくてみんなが困っているかもしれないと感じたら、参考にして作成するのが良い気がしている。

確証のチェック項目があるので、それをチェックするだけでも価値はありそう。

  • マネジメントの基本
    • できる上司のどのような行動や業績を素晴らしいとおもったか
    • 1on1が現状確認になっているなら他の手段があるか
    • 私生活の一大事を上司に話せるか
    • 上司からフィードバックがあるか。フィードバックを与えられているか
    • 目標設定で手助けをしてくれたか。手助けを出来たか。
  • メンタリング
    • インターンのメンターを希望しますか
    • 新人研修のアプローチはどのようなものですか
    • 新人のメンターを受けたいと上司に提案したいですか
    • そばらしいメンターがいたとしたら、どんなところが素晴らしかったですか
    • 成果が上がらなかったケースがあったら、それを今なら同会ゼインしますか
  • テックリード
    • テックリードがいるならば、Job descriptionは明確にありますか
    • プログラム以外の仕事もしなければ行けないし、コードは熟知していなければなりませんが、そのような人ですか
    • テックリードの期待値を上司とすりあわせているか
    • 最高のテックリードを見たことがあるなら、どんな行動でしたか
    • 不満があるテクリードがいるとしたら、どんな行動に不満でしたか
  • 人の管理
    • 定期的な1on1を計画していますか
    • 前回のキャリアアップについての内容をもう一度持ち出すことができる状態にしていますか
    • フィードバックを与えていますか
    • 最後にみんなの前で誰かを褒めたのはいつですか
    • 問題行動のあるメンバーにフィードバックをしたのは、問題行動からどのくらい時間が立ってからですか
    • 問題行動のフィードバックは、個人的にでしたか
    • 無駄な勤務評価が合ったとしたら、それをどうすれば改善できましたか
    • 一番有益だったフィードバックはなんですか
    • 昇進の手続きは公開されていますか
  • チームの管理
    • チーム管理者の責務とは
    • チーム管理のために他の人に譲った作業はなにか
    • チームがデプロイやサポートで日々直面している課題はなにか
    • 作業完了の報告頻度は
    • 最後にコードの変更を行ったのはいつか
    • 問題行動を起こすメンバーがいた場合の対処方法はみえているか
    • 仕事以外の話をメンバーで最後にしたのはいつか
    • 意思決定のルールはあるか
    • 管理者が下す意思決定に基準はあるか、それはどんなものか
    • プロジェクトの振り返りをして目標との差分をかくにんしたのはいつか
    • チームが担当しているプロジェクトをチームが持っているべき理由はあるか
    • プロジェクトで削ったことがあるならば、何で判断基準はなにか
  • 複数チームの管理
    • 最後にスケジュールの見直しをしたのはいつか
    • 過去3週間のスケジュールと今後3週間のスケジュールで、何を成し遂げて何を成し遂げたいか
    • 就業後にまでコードをかいているならばその理由は
    • 最後に移譲した仕事はなにか、複雑か単純か、いまはその作業は問題なくじっしされているか
    • 有望な管理者がいるなら、その人の昇進のためのコーチングはなにをしているか
    • プロジェクトのルーティーンはスムーズか、最後に大きい問題が発生したのはいつか、その時のチームの対処方法はなにか
    • プロジェクトの範囲を削る命令をしたのはいつで、なにか。スコープか品質か
    • 週末にメールしたか、それは返信が必要なものだったか
  • 複数管理者の管理
    • 自分に届く情報を受動的ではなく積極的に取るためにどのような手段をとっているか、それにどの程度時間をさいているか
    • 各管理者に期待していることはなにか、どんな責任をおっているか、その管理者の評価結果をどう評価しているか、彼らに必須の成功の条件とはなにか
    • 上の期待値と会社のJob descriptionに差分はあるか
    • 各管理者において研鑽が必要な項目はどこか、底に対するフィードバックの時間をとっているか
    • 自分がよく知らない分野の進捗や成功具合を聞いている頻度はどれくらいか
    • 自分がよく知らない分野で外せないポイントや成功の条件について担当管理者からレクチャーしてもらったか
    • スムーズなチームがあるならば、そのチームの他との違いは何か、どんな連絡方法をとっているのか
    • 管理者候補の面接では、哲学を聞いているか、メンバーと面談させているか、身元照会は行っているか
    • この四半期の目標はなにか、技術的な目標とどうすり合わせているか
  • 経営幹部
    • コーチングは社外のプロになる可能性が高い。自腹でもやる価値はある。
    • 社外に経営者仲間はいるか、ネットワークを持っているか
    • 尊敬する技術幹部がいるなら、どんなところか
    • 優先順位を変えた場合に、どうやって進めたか、その時の反応はどうだったか、いまならどうすすめるか
    • 会社が目指す方向を把握しているか、その時の技術的な戦略はなにか
    • 会社の近い将来の目標を達成するために各チームが当てるべき焦点はどこか、開発速度、人材採用、技術革新
    • 首脳陣は、自分の優先順位をどの程度理解しているか
    • チームに、自分がどの首脳陣と仲がよくて、どの首脳陣と仲が悪いか、わかるか聞いてみる。どう見えているか
    • 自分がロールモデルとなっているか
    • 業務で定期的に顔を合わせない部下に話しかけたのはいつか
    • シニアエンジニアに守って欲しい基本原則はなにか
  • 文化の構築
    • 会社や部署のポリシーはなにか、文書はあるか、最後の更新はいつか
    • 企業理念は、各チームでどのように体現されているか
    • キャリアラダーは定義されているか
    • キャリアラダーは、現在の反映か、将来の理想か
    • 重大なリスクはなにか、メンバーに不必要なプロセスを押し付けることなくリスクを避けられるか

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド   Camille Fournier https://www.amazon.co.jp/dp/4873118484/ref=cm_sw_r_tw_dp_U_x_YxsqDb7BTVJ09

0 件のコメント:

コメントを投稿