November 20, 2020
マネージャーの成果物とは何か!? プロジェクトリーダー業務で考えたこと
30代を境に業務でコードを書く機会が減り、顧客折衝やチームマネジメントの割合が増えた。
ただマネジメント業務を深く考える時間はあまり無かったかもしれない。
そもそもマネージャーのアウトプットって何だろうか。
次の本にはその疑問を解消してくれるヒントが紹介されていた。
まず本書の冒頭では マネージャーのアウトプット を次のように定義している。
POINT自分の組織のアウトプット ＋ 自分の影響力が及ぶ隣接諸組織のアウトプット.
マネージャーはチームのパフォーマンス ＋ アウトプットで評価されるべきとあり、自身がチームマネジメントを行う上で一つの指標となったので、直近PJでも取り入れてみた。
チームのアウトプット最大化に向けた施策
本書に倣えば、マネジメントでやるべきは チームのアウトプットを最大化 させること!!
組織のアウトプットに良い影響を与えるため、何をすれば良いのか常に考える必要がある。
直近PJの課題やチーム状況を鑑みて、次の指標でアウトプットを判断することにしてみた。
1. 開発スピードが向上したか（リリース頻度・回数 / 売上に直結する機能追加の有無）
2. 品質の担保（本番障害や受入時のバグ・問い合わせの少なさ）
3. 持続可能な開発体制構築（将来の内製化に寄与する取組み）
まず1と2を実現するため、案件終了時に振返りの場を設け、チームの成熟化に取り組んでみた。
幸い、担当PJではタスク管理をRedmineで行っていたので、検収時に起票されるバグや問い合わせの内容を開発者と共に振り返り、次のような課題と対応策を洗い出せた。
1. ブラウザ毎の挙動が一致せず、検収時に多くの問い合わせを頂いた.
＝ デザイン変更の際は、クライアント先のデザインチームにモックを作成してもらう.
2. 開発担当者の試験項目書の作成が雑でチェック漏れが多い（操作手順の記載のみ）
＝ 試験観点を列挙したシートを作成し、RV担当者に配慮する.
3. 役割分担問題（出来るエンジニアに負荷が集中している）
＝ 出来るエンジニアの負担軽減のため、初級要員が軽微改修や問合せを対応する体制構築.
4. 実装漏れ ＋ 確認観点漏れ
＝ 実装前後でディレクターと認識合わせを行い、検収時の無駄な問合せを減らす.
5. 工数算出の甘さ（納期間際に間に合わないことが多発）
＝ 作業着手前にタスクを細かく分割し、ボトルネックを理解して計画を立てる.
＝ 定期的な進捗報告で、致命的な問題を早期に対処できる体制づくり.
6. 受入時の問合せ数を削減
＝ 基本的なホウレンソウで防げる問合せが多いので、密に連携が取れる体制構築.
マネジメント側の改善点も見えてくるので、定期的な振り返りの場は大切だと痛感させられる。
ちなみに本書の第2章でもインディケーターが大事だと述べており、今回は検収時のRedmineチケットを参考にしたが、良い指標（タスク消化率・コミット数）がないかを引き続き追求していきたい。
自発的な改善サイクルを回すためKPT
KPT導入前は、開発リーダーの自分がメンバーの進捗状況を把握し、日々感じた課題の改善策を考え、メンバーに実行してもらったが、自発的に改善サイクルが回せるチーム作りのために導入を試みた。
まず最初は書籍やネット記事をベースに次のような手順で着手。
またKPT運用にも色んなツールがあるが、まずスプレッドシートを使うことにした。コロナで在宅中心のため、リアルに付箋紙を書いて張り出すのは困難だし、なるべくお金もかけたくないので。
振り返りMTGでは、各自メンバーが良かったこと（Keep）と問題に感じたこと（Problem）を挙げ、Problemに対するTry、Keepに対するTryを話し合う。
Tryを実行したらKeepに移動。次回MTGではその成果を振り返り、効果があったものはナレッジとして別シートに移動し、メンバー主体で改善サイクルを回しながら、チームの成熟化を目指す。
マネージャーにとって大事な手段であるミーティング
本書ではミーティングに丸1章を割いており、いかに重要な手段であるかを述べている。
その理由は1マネージャーの仕事の大半が情報・ノウハウの提供であり、チームのアウトプット最大化には欠かせない。またその時間を最大限に有効活用するのも使命の一つ。
ミーティングの目的と役割には、プロセス中心（知識の共有化や情報交換）を主にするものと、使命中心（具体的な問題解決や意思決定を行う）の2種類がある。直近PJで前任者からマネジメント業務を引き継いだ際、前者に課題を感じたので、基本的な次のことを見直してみた。
1. 各要員の作業状況を把握できる状態になっていない（WBS未更新）
＝ WBSで最低限のタスク管理を行い、日次の夕会で確認（その場で更新）
＝ 進捗遅延のボトルネックを把握し、適切にフォロー（要員調整等）
2. 何をどこまでやるかの指示が明確になっていない（進捗が不明）
＝ なんとなくで依頼せず、完了までの具体的なゴール設定を行う.
3. 細かいタスク消化のための工数が考慮されていない（RV対応、etc）
＝ 事前にわかっているタスクはスケジュール作成時に考慮する.
プロセス中心のミーティングでは、チーム間のコミュニケーションを活発化させるため、日々の案件完了時、開発者自身がチーム全体に共有した方が良いと思うことを、定例の場で共有する運用とした。
ただ実際問題、共有事項をそれなりの資料に落とし込もうとすれば、タスクに追われる開発者の負担になるため、いかに開発者の隙間時間を作れるかが勝負な気がしている。
また日次の夕会で挙げられたボトルネックや相談事は、別途有識者が集まり、課題解決まで道筋を話し合う。これらを繰り返すことで、チーム間の風通しは幾分か良くなったことを実感した。
経験の浅いメンバーとの向き合い方
経験浅めのメンバーをメンターすることもあるが、第3章に参考となる考え方が紹介されていた。
POINT自分には ”わずかな” 時間でも、他人の業務遂行で ”長い” 期間に渡って影響を与えられる.
POINT部下への権限委譲について、委譲後にフォローしないのは職務放棄となる.
特定の経営管理活動により生じるアウトプットの尺度 ＝ テコ作用 としている。
そういえば、ある部下にタスクを振った後、日々進捗をモニタリングしていると、あるボトルネックが解決出来ず、相談されたことがある。私自身が直接的な解決策を持っていた訳では無かったが、問題解決までの道筋や今後の進め方を軽くアドバイスしたら、即解決でき、納期を守ることができた。
その件以降、メンバーは早期の相談を心掛け、進捗遅延が無くなった気がする。またメンバー毎にどの程度フォローするか、タスク習熟度別に効果的なマネジメント・スタイルの特徴も解説されていた。
タスク習熟度：低（明確な仕組み ＋ タスク志向）
”何を” ”いつまで” ”どうして” を示す.
タスク習熟度：中（個人志向）
双方向通行的コミュニケーション、支持、お互いの判断力を重視する.
タスク習熟度：高（マネジャーの関与を最小限に）
目標を設定し、モニターする
前任者からPJを引き継がれた際、3年目の若手社員が新人の面倒を見る体制になっていた。若手社員から新人（タスク習熟度：低）は全く仕事が出来ないと報告を受けていたが、タスクの完了条件と期限を伝えた後、認識齟齬が無いかをミーティングで確認、定期的なモニタリングを行うことで、ある程度戦力になってくれた。タスク習熟度別のマネジメントは常に心掛けたい。
ワン・オン・ワン・ミーティングの進め方
上記ミーティングに繋がるワン・オン・ワンにも詳しく言及されていた。
主な目的は、相互に教えたり、情報交換や、特定の問題や状況を話すことで、監督者は物事のアプローチ方法を提案でき、部下は自分が何をやっているのか、何に関心があり心配しているかを伝えられる。
私自身、直属の部下を持っていた訳ではないので、個別に実施していないが、もし実施する場合には、次のような点に配慮することが推奨されていた。
1. ワン・オン・ワン・ミーティングは、最低1時間は続けるべき.
2. 部下のミーティングであり、議題や各種調整は部下が決めるべき筋合いのもの.
3. 話す議題は実績数値、部下が使用している指標（トラブルの存在を知らせてくれるもの）
4. ミーティングのアウトラインを事前に作っておく.
ちなみに本書は、部下がある主題について言いたいことを全部話したと思ったら、もうひとつ念のために質問し、双方が問題の底にまで達したと、満足感を覚えるまで質問を繰り返すことを推奨している。
参考記事
■ 今年組織作りに貢献するためにやったこと@エニグモ開発者ブログ
■ 正しい「KPT」が仕事の成果を生み出す！進め方のコツ、現場の事例を紹介
■ フルリモートでのチーム開発となった2020年を振り返る
■ “ふりかえり会” の第一歩
■ スプリントの振り返りでKPTをやめた話
■ プロジェクトマネージャーいらなくね？と思って辞めた話
■ 振り返りで積み上げた開発プラクティス（2020年総まとめ）