nokoのブログ

こちらは暫定のメモ置き場ですので悪しからず

マネジメントするときに意識しているポイント2020

マネジメント全般

はじめに

  • 直近、プロジェクトでマネジメントをすることになったんですが、その時に意識していたことメモです。
  • プロジェクトマネージャとは「プロジェクトのゴール達成に責任を持つ、プロジェクトのゴールを定め、ゴール達成のために資源（ヒト・モノ・カネ）の最適分配の意思決定をしていく人」だと今のところ思っています。
  • オーナーは別にいて、現場責任を持って任務遂行していく人、のイメージ。
  • ドラッガー的には、マネジメントとは「投入した資源の総和よりも大きなものを生み出す」 + 「緊急の必要性と未来の必要性を融和させる」ことだそうです。
  • （リーダとマネージャの違いとかPjMとPdMの違いとか色々あるけどまぁつらつら書きます）

マネジメントするときに意識しているポイント

1. ピープルマネジメント

■顧客から頼もしいと思われる&相談しやすい人

全般

  • 期待値を上げるか下げるか。目的を持って・意思を持ってコントロール。
  • 自分が・会社が・プロジェクトが、今どう見えているか・どう思われているかを把握してから全てのアクションを組み立てる。
  • 会議は毎回、一回はいい雰囲気の瞬間を作る。

プロジェクト開始前

  • 2回同じことを話したら、かなり気にしているということ。きちんと拾ってあげる。
  • 強気な案を当てるときは、一人がダメ元で強気な案を出して、顧客の様子を見てもう一人が顧客側に立って否定してフォローして、折衷案を模索していくとかもあり。
  • お金の話はシビア。WBSレベルで把握しておいて、組み替えられるように。
  • 持ち帰らない。交渉する価値がないと思われる。
  • 相手を選ぶ。意思決定権のある、交渉する価値がある人かどうか見極める。
  • 予算取りのスケジュールとフローをおさえる。
  • いい人で終わらない。顧客の無茶な要望を飲むでも突っぱねるでもなく、Win-Winになるアイデアを即興で考えて返す。

プロジェクト開始後

  • 車を作っていくときに、タイヤから作らない（見せない）。スケートボード（最低限目的を果たすもの）を見せる。
  • 技術より、効果の大きさを語る。
  • 苦労も適宜見せていく。
  • メンバが担当したことも、リーダが説明しきる。おどおどとメンバに振らない。
  • 顧客が質問してくるときは、不安か怒りが背景にあるので注視する。
  • 断るべきときは断る。ぶっちゃける。言い方と準備が大切。
  • 顧客との関係が悪化したときにどうするか、がリーダーの仕事。だいたいのプロジェクトは失敗する。

メンバーについていく価値があると思われる&相談しやすいリーダ & タスクをいい感じに振って管理してくれるマネージャ

■メンバーについていく価値があると思われる&相談しやすい人

  • 最初に、プロジェクトの意義と、メンバー個人として参加するメリットを伝える。
  • はやめに、リーダとしての力を示す（統率力があるところ、細部まで・先まで見据えていること、個のエンジニアとして手が動くところ、etc）
  • （刻一刻と変わる）プロジェクトの状況はタイムリーに同期していく。ただし過剰に会議は開かない。各メンバーの責務から逆算して、必要十分に共有していく。
  • 心理的安全性の高いチームとは
    1. 何を言っても許される
    2. 困ったときはお互い様
    3. とりあえずやってみよう
    4. 異能どんとこい -> リーダの心理的柔軟性が大切。正論ではなく、役に立つことをする。変えられるもの:「行動」にフォーカスする。
  • トラブルが発生したときに、「それはちょーどよかった」と唱える。
  • できたことではなく、抱えている課題についてシェアしてもらうようにする（顧客との関係においても）
  • 批評家にならない。一緒に前向きに。
  • 相談してすぐ対応してくれないと、相談する気が無くなる。
  • プロジェクト状況が追い込まれたとき、先が見えないときこそ、雰囲気よくできるか。
    • ピンチはチャンスだが、メンバーの気持ちに気を付ける。
  • リーダ（年長）であっても、のび太力は大事。

■タスクをいい感じに振って管理してくれる人

  • プロジェクトの始めにスコープ決め->WBSに落とし、懸念点の洗い出しと共有までスピーディに実施する
  • -> その後基本的に権限を委譲してボヤが出たら入る、だが、途中で一度は手を動かして情熱とスキルを見せる
  • メンバーの能力に応じてタスクを振る
    • 目的を話してダメなら役割を与える
    • それがダメなら対象を絞る
    • それがダメなら基準と納期を示す
    • それがダメなら方法を教える
  • レビューは、文面での指摘はきつく見えるので慎重に。口頭でフォローする。
  • インクリメンタルなタスクか、割り込みタスクか区別して扱う。
    • 割り込みタスクは、見積もらない。
    • 割り込みタスクを振られると、ストレスがたまる。

2. テクノロジーマネジメント

■テクノロジー面の責任を持つ人

  • 観点
    1. 最適なアーキテクチャを選定する
    2. ソフトウェア品質を担保する
    3. 開発者体験を整備する
    4. 運用負荷を最小化しておく
  • テクノロジーマネジメントを遂行するために、引き出しの多さ + 足りない部分を適宜判断してスペシャリストを巻き込んでいく必要がある。
  • 仕組みを作って支えていく。

3. プロジェクトマネジメント

■責任を持ってプロジェクトをステークホルダーが納得するゴールまで落とし込んでいく人

  • 油断せずにリスクの早期発見・早期潰し込みをし続ける
  • 最初に下記をステークホルダーと合意する
    • 背景、課題
    • ゴール
    • スコープ
    • 役割分担
    • スケジュール
      • 次のステップに進めるかを判定するタイミング
    • 成果物
    • 体制、窓口と意思決定者
    • 会議体、コミュニケーションツール
    • 前提条件
      • 追加工数が発生するケース
      • スケジュールがずれ込むケース
    • 見積もり

4. プロダクトマネジメント

■プロダクトの未来について答えられる人

  • プロジェクトとしては現実的な落としどころを意識し、プロダクトとしてはよりビジョンを意識する
  • 一見非合理なポイントを盛り込んだ、ストーリーとして語れる戦略を立てる
  • やるべきこと

参考

おわりに

  • マネージャは広く・先まで見据えて意思決定していく必要があるので、とにかく基本に忠実にバランス型でいよう思っている。（色んなスタイルがあると思うが）
  • （一方でエンジニアとしては尖っていたい。楽しいから。）