Date
November 30, 2023
はじめに
aokiです。このたび社内研究発表会にて展開した内容を外部公開するとのことで、ブログを書いています。発表当日は、会場に30人ほど来ていただいたみたいでホッとしました。
発表内容について全部記載すると長くなってしまうのでポイントを絞ってご紹介していこうと思います。
発表するまで
プロジェクトマネジメントの知見を研究発表会で社内に展開してほしい、という依頼でした。
正直なところ発表するまではずっと気が重く、やらないといけないことがずっと頭の片隅にある状態で「早く完成させて安心したい」という気持ちが大きかったです。
それでも発表するからには誰かの何かの役にちょっとでも立つようなものにする必要があるなぁと考えていました。
資料が形になったのは発表の2日前。 構成をメモ的に残していたりしましたが、清書するといろいろ変わりますね。
淡々と価値を届けられるようになるために
ここからは発表内容を抜粋して紹介します。 まず、タイトルは「淡々と価値を届けられるようになりたい」と、自分の願いを込めました。 それでは紹介していきます。
全体をどう捉えるか
マネージメントする対象を何にするか？ということで観点を紹介しています。
- プロジェクト 📊
- 目的、計画、メトリクス、体制
- プロダクト 🚀
- 要件、価値提供の手段
- プロセス 🔄
- 要件をプロダクトに変換するための方法
- チーム 🧑🤝🧑
- プロジェクトの目的を達成するための集団、人
以降は aoki がマネジメントするにあたって意識したポイントです。
観察する
- まずは全体をざっくり俯瞰して見るターンを作る
- 気づいたことはメモして課題分析だけしておく
- 観察フェーズは観察のみする
作戦を練る
- 開発チームの自己管理化を優先
- 開発チームが自走しだしたらその周辺の課題に手を入れる
- 作戦を顧客に共有する
- アジャイルやスクラム関する勉強会を開催
変化のスピードと量に配慮する
- 人間は変化にストレスを感じる
- 安定したいので現状維持をしようとする力が働く
- 実際にチームの課題感が高まって自分事になってから対応する
- 結果的にチェンジマネジメントになる
余裕を持つ
- 最優先で取り組んだほうがよさそう
- 余裕がないと改善が回らない
→ 精神的余裕をつくる
- 漠然とした焦りが蔓延していたりする
- 自分たちのペースを把握できるように可視化する
- ex) ベロシティ測定
→ 物理的余裕をつくる
- こちらも可視化することでビジネス側に説明し、調整する
ドキュメントに働いてもらう
- 人員の入れ替わりがあってもURLを共有するだけで説明が終わる
- 関わる人が多いほど効果的
- 他の人が勝手に参照してくれる
開発チームが小さく失敗し、成功体験を積める環境にする
- 失敗しそうだなーと気づいてもその場ですぐに指摘しない
- 大丈夫？くらいの確認はする時もある
- クリティカルかどうかだけは気にしておく
- 越えられそうな目標設定をする
- スプリントゴールの適切な設定
- 成功体験を積むとそれを再現しようとする力が働く
全体最適を目指す
- 開発チームだけで無理矢理解決しようとしない
- エンジニアとPMでは見ている景色が異なる
- PMは全体を見渡せる視野を持っておき、認知のメガネを貸し出す
過去・現在・未来にバランスよくアプローチする
→ 過去
- 過去経緯が残るようにドキュメンテーションを地道に布教する
→ 現在
- 開発チームが集中できる環境を整える
→ 未来
- 少し先の準備ができているかチェックするしくみを作る
メトリクスを取れるだけ取っておく
- PMの基本装備
- 対外的に説明する時に事実として出せるようにしておく
- うまく測定できてなさそうだったら運用をアップデートする
- 副作用でカンバンが綺麗になったりする
Zenhubはこれを勝手にやってくれるので LOVE
リードタイムに着目する
- 全員が120％の力で稼働していてもリードタイムが長いと意味ない
- どうやったら実際に動くプロダクトを早くレビューできる？
- チケットの分割どうする？
- LeanとDevOpsの科学のFour Keysは指標として良さそう
- リードタイム
- デプロイ頻度
- 平均修復時間
- 変更失敗率
内容は以上です。何か役に立つことがあれば幸いです。
おわりに
エンジニアもマネージャーも含め、組織に所属する全ての人が価値提供のために自分ができることをできるだけする、というのはあまり変わらないと考えています。
この先も目標を見失わずに集団としてイケてる動きができるようになるためにはどうしたらよいか？という問いについて日々取り組んでいけたらと思います。
ありがとうございました。