こんにちは、たくという名前でブログをやっています。
自走力という言葉を聞いたことがあるでしょうか？
与えられたタスクに関して、自分でゴールを決めて、わからない部分は他の詳しい人に聞きつつ、自力で目的を達成できる能力のことをいいます。メンバーの自走力でチームの生産性は大きく左右されます。
今日はその自走力に関して僕が大事だなと思った出来事をふまえて、自走力を発揮できるようなチームはどんなチームなのかを知見としてまとめたいと思います。
自走力が必要だと思った自分の体験談
僕は以前在籍していたチームでアウトゲーム部分のクライアントエンジニアリーダをやらせていただいておりました。
アウトゲームとは、キャラクタの編成だったり強化だったりミッションのクリアだったりと、バトル以外のすべての機能を指しています。そのため、UIの組み込みだったりサーバ側のAPIを実行したりと、エンジニア以外の職種と随時相談しつつ実装する力が必要になります。
そんなアウトゲーム部分の開発は基本的に以下のようなフローで動いています。
- 企画が仕様書を書く
- デザイナーがUIの画面設計と作成を行う
- サーバーエンジニアがAPIの設計と作成を行う
- クライアントエンジニアが組み込みを行う
クライアントエンジニアは最終工程になるため以下の作業が求められています。
- それぞれの工程に入り込み、企画とデザイナとサーバーエンジニアと実装内容をすり合わせつつ進める
- 基本的に並行開発になるため、スケジュールの調整も適宜行う
- 機能全体を意識してはじめに決めたスケジュールに間に合うかを意識する
実装内容のすり合わせやスケジュール調整など求めらることも多く、関係職種も多いため難易度の高い状態になっています。そのため、リーダーが適宜メンバーに調整のための段取りを指示したり、ミーティングを適宜開いたりなどしてなんとか進めている状態でした。
一度メンバーに調整を任せたこともあったのですが、調整の難易度が高いようでうまく行かないメンバーに関しては作業が遅延したり、現状の状態が不明確になってしまったりとあまりうまく行かなかった経験があります。しかし、理想的には個々のエンジニアが自走することでリーダーは本来の業務に集中できるためチームとしても生産性が向上することになります。
なぜ自走できないのか？
僕の職場の場合は以下のような原因があると思いました。
自分がどこまでやっていいのかが不明確
例えば、
- 企画に対してどの程度意見を言っていいのか？
- クライアントの実装設計などは相談がいるのか？それともある程度始めてもいいのか？
- サーバー側とのAPIのスキーマはどの程度自分で決めてもいいのか？
- デザインの基礎はエンジニア側で作成してもいいのか？
- レビューはいつ誰が行うのか？
- スケジュールの設定はいつ誰が行うのか？
などなどです。
これらが不明確の場合は、自分のできる範囲ですすめてしまい、気づいたときには大きな手戻りが発生することもあります。
ある程度ルール化できる部分もありますが、開発中はルール自体も変わっていったり、他の担当者によってやり方が違ったりするため難しいです。しかし、ルールがない状態では、段取りを立てようにも自分がどこまでしていいのかが不明確になってしまい動けないという状態になってしまいます。
不明確な状態では、自分の立ち位置をヒアリングをしつつ進めていく必要があるのですが、その過程で質問力や、段取り力、コミュニケーション能力が必要になります。その部分をリーダが随時フォローしていると、マイクロマネジメントになってしまい、更にメンバーの自走力が下がってしまいます。
自走するチームを作るためには
自走できな理由をまとめると
- 自分の仕事の範囲が不明確なため、自走しようにもどこまで手を出していいかがわからない
- ルール化やフロー化は、開発中では常に変わるため、信用できる情報が少なく動きづらい
つまりは仕事の範囲を明確にする必要があります。開発のルールやフローはすべてをカバーできないため、もっと抽象的な「権限」というレベルでメンバーとリーダーができることを明確にすることが大切です。
基本的な開発の流れに例えて分割してみると、メンバーの権限とリーダーの権限は以下のようになります
メンバーの権限
- 企画と相談して仕様をブラッシュアップできる
- 定まった仕様に沿って実装の設計ができる
- 実装の工数を算出してスケジュールを設定できる
- 実装ができる
リーダの権限
- ブラッシュアップした仕様のレビューし決定ができる
- 実装の設計のレビューし決定ができる
- 実装のスケジュールをもとに他職種との作業調整ができる
- 実装のレビューをしてフィードバックのタスクを作成することができる
これを決めることによって
- スケジュールはメンバーが決めるが、他職種と調整はリーダがおこなう
- 実装を始める前にリーダに設計をレビューして貰う必要がある
などといった動き方がわかるので、リーダーの許可が必要なものは適切に依頼が来たりなど自分でできる範囲が明確になります
自走できるチームを維持していくには
権限を明確にすることで自走力は上がりますが、メンバー自身のスケジュール管理をすべて任せるとリーダとして全体のスケジュールを見ることができなくなります。そのため、スケジュールに関する権限は詳細に決めておいたほうが良いです。
例えば
＊ここでは、タスクのまとまりが機能と考えてください
メンバーの権限
- タスクの遅延があった場合タスクのスケジュール調整ができる
リーダーの権限
- 機能の遅延があった場合はメンバーとのスケジュール調整ができる
- 機能の遅延があった場合は他職種に報告できる
この場合、タスクの遅延があったらメンバー内で調整てもいいが、機能の終わりに遅延が発生した場合はリーダーが調整するため、リーダに報告をする必要があります。
このように、スケジュール管理に関しても権限を明確にすることで自走力を落とさずに適切にスケジュール管理できるようになります。
おわりに
メンバーとリーダーの権限を明確にすることで、メンバーは自分の作業する範囲が明確になるので自然と動けるようになります。
メンバーが自走すると、リーダーは作業の効率化などもっと大きなチーム課題に取り組むことができます。そのためチームとしても大きく前進できると思います。
