淡々と価値を届けられるようになるための話「研究発表会vol.05〜aoki編〜」

はじめに

発表するまで

淡々と価値を届けられるようになるために

全体をどう捉えるか

• プロジェクト 📊
• 目的、計画、メトリクス、体制

• プロダクト 🚀
• 要件、価値提供の手段

• プロセス 🔄
• 要件をプロダクトに変換するための方法

• チーム 🧑‍🤝‍🧑
• プロジェクトの目的を達成するための集団、人

観察する

• まずは全体をざっくり俯瞰して見るターンを作る

• 気づいたことはメモして課題分析だけしておく

• 観察フェーズは観察のみする

作戦を練る

• 開発チームの自己管理化を優先

• 開発チームが自走しだしたらその周辺の課題に手を入れる

• 作戦を顧客に共有する
• アジャイルやスクラム関する勉強会を開催

変化のスピードと量に配慮する

• 人間は変化にストレスを感じる

• 安定したいので現状維持をしようとする力が働く

• 実際にチームの課題感が高まって自分事になってから対応する
• 結果的にチェンジマネジメントになる

余裕を持つ

• 最優先で取り組んだほうがよさそう

• 余裕がないと改善が回らない

ドキュメントに働いてもらう

• 人員の入れ替わりがあってもURLを共有するだけで説明が終わる

• 関わる人が多いほど効果的

• 他の人が勝手に参照してくれる

開発チームが小さく失敗し、成功体験を積める環境にする

• 失敗しそうだなーと気づいてもその場ですぐに指摘しない
• 大丈夫？くらいの確認はする時もある
• クリティカルかどうかだけは気にしておく

• 越えられそうな目標設定をする
• スプリントゴールの適切な設定

• 成功体験を積むとそれを再現しようとする力が働く

全体最適を目指す

• 開発チームだけで無理矢理解決しようとしない

• エンジニアとPMでは見ている景色が異なる

• PMは全体を見渡せる視野を持っておき、認知のメガネを貸し出す

過去・現在・未来にバランスよくアプローチする

メトリクスを取れるだけ取っておく

• PMの基本装備

• 対外的に説明する時に事実として出せるようにしておく

• うまく測定できてなさそうだったら運用をアップデートする
• 副作用でカンバンが綺麗になったりする

リードタイムに着目する

• 全員が120％の力で稼働していてもリードタイムが長いと意味ない

• どうやったら実際に動くプロダクトを早くレビューできる？
• チケットの分割どうする？

• LeanとDevOpsの科学のFour Keysは指標として良さそう
• リードタイム
• デプロイ頻度
• 平均修復時間
• 変更失敗率

さいごに