弊チームのマネジメント・ビルディング取り組み

# はじめに

チームをいくつかもってマネジメントしてきた中で、自分が意識してやってきたことをトピック的にまとめます。
内容におかしな点を見つけたりアドバイス等ありましたらご指摘お願いします。

# 実践したこと

## カンバンボード

### 背景

タスクに対して、「誰が何をしているか」「どのタスクを優先してやるべきか」を可視化したい

### 取り組み

Trelloを使って作成しています。
基本的に、「ToDo」「Doing」「Done」の状態を用意していますが、頻出するタスクに応じて、以下のようなタスクの内部状態を定義して工程を可視化しています。

- 開発の場合
    - 要件定義・設計
    - 実装
    - テスト
    - etc.
- 分析の場合
    - 要件定義・設計
    - データ調査
    - 分析コーディング
    - 値検証
    - レポーティング
    - etc.

また、次の状態に遷移する際の条件として、第三者レビューや自動テストの通過など、それぞれ明確に定義しています。

### 効用

- チーム内で誰が何をしているのかが分かるようになった
- 作業が標準化されているため、どのように進めていけばいいのかが分かりやすくなった
- タスクの進捗の変動が分かり易くなり、サポートなどの対処がしやすくなった

### 課題・注意点

- (Trelloにおいて)視認性が若干悪い


## スクラムイベントの導入

### 背景

業務時の要件が流動的に変動するため、柔軟に対処できるようにしたい。
また、業務上の課題をカイゼンしたい。

### 取り組み

以下のスクラムイベントを組み込みました。
予定調整の手間を嫌っているため、実施時間は完全に固定でやっています。

- デイリースクラム(毎日)
    - メンバー1人1人が「昨日の実績」「今日の予定」「課題や共有事項」を話す
    - 業務状況に応じて、タスクの優先度の入れ替えを随時行う
- レトロスペクティブ(週1)
    - Timelinesdeで1週間を振り返った後、KPTで改善案を出す

業務上、スプリント単位で成果物を出していく進め方が難しいため、プランニングを導入できてないです。。。
前述にある通り、スクラムボードではなく、カンバンを導入しているのもこのためです。

### 効用

- デイリースクラムにより、毎日の進捗確認が定常化した
- レトロスペクティブにより、チーム内の課題を即座に組み上げることができるようになった

### 課題

- レトロスペクティブに、ファシリテーション能力が要求される
    - 気を付けないと一部の人しか発言しなくなってしまう

- プランニングができてないため、レトロスペクティブによるカイゼンを即座に実施できない場合がある
- ベロシティによるチームの改善が定量的に測定できていない

## 1on1ミーティング

### 背景

メンバー1人1人の理解を深め、本人の志向性を把握したい。

### 取り組み

- 週1で1on1を実施
    - 長すぎるとよくないので、週に1回30分で
- (話下手なのもあるが)実施する前に話したい内容をある程度決めておき、アジェンダにまとめておく
    - 自分の場合、基本的には「最近の状況」と「目標振り返りと次のアクション」
- とはいえ、メンバーが話したいことを聞くため、アジェンダを無理に消化しないようにする
- 話した内容に齟齬が起きないように、二人が見えるようにメモを共有する
    - 私の場合、ディスプレイに1on1のメモを残している

### 効用

- メンバーの志向性が把握できるようになった
    - 1on1で改めて話してみると、それまで認識していたことと結構ギャップがあったりする
- 本人の意図を把握したうえで、業務上の都合などを伝えて一時的に我慢してもらうなど、説得できる場として活用できるようになった

### 課題

- 1on1の目的を明確に設定しておくべき
    - 目的を設定しないと、「この時間無駄では・・・？」と思われる
- 1on1をうまく機能させるために、ある程度心理的安全性を高められているという前提があると思う
    - 1on1を実施していく中で、心理的安全性を高めていくという考え方もある

## ペアプロ・モブプロの導入

### 背景

データマートやコーディングやGitなどチーム特有のナレッジの教育コストが高いのを解消したい。
また、開発や分析などの効率が上がるTipsをチーム内で共有されるようにしたい。

### 取り組み

- オンボーディング直後の簡単な研修課題をやってもらった後、モブプロで実際の業務をしばらく行う
- 過去に辞令がないような新規の業務や1人でやるには大変な複雑な業務をやる場合にモブプロで業務を行う

### 効用

- エディタの便利機能やモジュールの便利メソッドなど、チーム内の暗黙知を共有できる
- チームで確認を行いながら作業を進められるので、レビューやそれに伴う手戻りが発生しない
- チーム内の横の繋がりが強くなった（気がする）

### 課題・注意点

- 効果を最大限得るために、ドライバーとモブの役割等、メンバーのモブプロへの理解が必要
    - ファシリテートできる存在がいればいいかも
- ティーチングやドキュメントなどで網羅すべき最低限必要な部分とモブプロで網羅できればいい部分の切り分けが重要
    - 常にモビングで進めていればいいが、そうでない場合何かしら俗人化は起きるという認識
- リソース効率が落ちるため、場合によっては理解を得るために対外的な説明が必要

## スキルマップの作成

### 背景

スキルの俗人化を防ぎ、メンバーが柔軟かつ横断的に作業できるようにしたい。
また、メンバーの入れ替えに伴うスキル喪失のリスク把握・対策をしたい。

### 取り組み

- 叩き台を作って、チーム内で意見をもらいながらスキルマップを完成
- 1on1でスキルマップを埋めて、メンバーの目標設定に活用
- オンボーディング時に、必須のスキルを習得してもらった後、状況に応じて優先的に習得してほしいスキルを判断

### 効用

- チーム内でのスキル状況の可視化ができ、優先的にスキトラすべき点がわかるように
- 1on1で利用して、目標設定に役立った

### 課題・注意点

- チーム内で共有することに合意をとる必要がある
- 場合によっては、どうしてもメンバー間の比較に繋がりそう
    - 前提としてチーム内の関係性がある程度成熟してないとだめかも
- 定期的に更新する必要があるが、タイミングが難しい
    - 頻繁すぎるとあまり更新することがないが、間隔が空きすぎると意識から抜けがち

- 運用する際のツールは、可視化を考えるとExcelとかがよさげ
    - 私はscrapboxで頑張ってますが、可視化が不得手なのでそのうち乗り換え予定。。。


# 参考

- [カンバンのキホン #カンバン仕事術](https://slide.meguro.ryuzee.com/slides/74)
- [カンバンの基本のキ](https://qiita.com/TAKAKING22/items/0a6412e5c3a95a90da50)
- [1on1を上達するために](https://speakerdeck.com/nitt_san/1on1woshang-da-surutameni)
- [小さなチーム、大きな仕事を実装するモブプログラミング](https://speakerdeck.com/takaking22/mobprogramming-as-change-the-way-your-work-forever)
- [「モブプログラミング・ベストプラクティス」読んだのでモブプロの魅力と始め方をまとめる](https://aloerina01.github.io/blog/2019-03-12-1)
- [異動のおともにスキルマップ](https://quipper.hatenablog.com/entry/2019/06/03/skill-map)