目指した開発チーム

自律的な開発チーム

自分でやりたいことを宣言できる
自分で決めて自分でやり切れる
開発ではなく案件を任せられる
楽しく元気に働ける

自分のチームが置かれていた状況

リーダーがタスクを整理して、各メンバーに割り当てる。タスクの進捗をリーダーが取りまとめて必要なチームに共有する。

チーム構成

トップダウン型のメリット

チーム全体を把握しやすい
- ほとんどのことを自分が指示するので誰が何をやってるか見通しやすい
窓口が明確
- 他チームからみたときに誰に話をすればいいかわかりやすい

トップダウン型のデメリット

メンバーが指示を待つようになる or 指示を求めるようになる
メンバー同士の連携が希薄
- 自分以外の人が何をやっているか知る必要がない

筆者の立ち位置と役割

リーダーの移動に伴って、その席に座ることになった

提示したチームの方針

やりたいタスクは自分で決める
- やりたいタスクをタスク一覧から拾ってチーム内に宣言する
チームのためになるタスクを6ヶ月のうち1つやる

目指したチームの構成

相互コミュニケーションが取れる構成にして、自分が全て支持しなくてもみんなで問題解決できるようにしたい。

やってよかったこと

メンバー全員との定期的な1on1

社員・パートナー含め、何を目的として会社にいてどうなりたいのかを聞く。
明確な目標を持っているケースの方が少ないので、どんなことが楽しくてどんなことが辛いのか、そのメンバーの嗜好やスタンスを理解する。
それを元に、可能な限りメンバーの目標に近いタスクが選択できるよう調整する。
定期開催であることを明示すると、そこに合わせて話題を持ってきてくれるようになる、自分から話すのではなく相手が話したいことを、なんでも話せる雰囲気を普段から作ることが重要。

チーム方針を示す

自分のチームはどのようなものか全員に理解してもらう。
理解を得るまでには時間がかかるが、自分の描くチーム像を伝えることで、その方針に沿った判断ができるようになる。
また、メンバーの評価軸を明文化して、何をすれば評価されるのか伝える。

だるいが言えるような雰囲気作り

個人的には「やりたいことが言えること」と同じくらい「やりたくないことが言えること」は重要だと思う。
日々のミーティングでは可能な限り発言しやすい雰囲気作りに努め、なんとなくいや、なんとなくいい感じが気軽に表現できるようにする。
そうやって、自分らしくいれるチームこそがメンバーの居たい場所になって結果的には業務効率に繋がっていく。。。と思っている。

社内・社外に評価されやすい仕組み作り

パートナースタッフが多いという特徴から、自社に提出しやすく、かつ自分のチームにメリットのあるタスクを自分で選定してやってもらうようにしている。
支持されたタスクではなく、主体的に選択して達成したという事実を積み重ねて、メンバーのやりがいに繋がるようにしている。

やってダメだったこと

危機感を煽る

今のチームの問題点をあげて、改善しないとまずいことを説明する。
しかし、リーダーとメンバーでは持っている情報に差異があり、同じ結論にたどり着くことは難しい場合もある。
正確に自身の考えを伝えられればいいが、コミュニケーションは出し手と受け手の両者がいて成立するものなので100%伝わるとは思わない方がいい。
言われた側としては、そんなことは知らないし、この人は急に何を言ってるんだろうとなる。
これをやるくらいなら、「自分のチームの方針がいかに素晴らしいと思ってもらえるか」を考えた方がいい。

困ってたらすぐ助ける

これをやってるといつまで経っても育たない。
何かあっても助けてくれるだろうという甘えは安心感とは似て非なる物なので注意が必要。
致命的な事態にならないものであれば失敗してみた方が早いと思うが、そうでない場合は解決するためにどうやって動くべきか伝える方がいい。

今後チーム作りをする人へ

チームのことを考えるのは開発することとは違った気付きや苦しみがあると思います。
ただ、ソロで開発し続けるのはいつか限界が来ると私は考えています。自分で作るのが一番楽しいけど、もっと大きな物をみんなで作っても楽しいよねという気持ちでチャレンジしてみるといいかなと思います。

（そして、できればそういう人と情報交換したいなと思ってこの記事を書きました。）