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