頭数を足し算するだけはチームスキルを正確に反映しない
ちょっと長くなったので先にポイントだけ書きます
- １人が経験浅い人が含まれる2名１チームの場合のチームスキルを考える場合に1+1＝2ではなく、チームが生み出せるアウトプットｘ頭数として考えて、(1 x 0.5) x 2＝ 1という感じな気がする
- なぜ、２ではなく１になってしまうかは、経験浅い人に対して、技術的な側面に限らないフォローをもう1名がやらないといけないためチームが生み出せるアウトプットが少ない
- フォローをする側の人間が1名で全部抱えても結局はチームスキルは１のままなのでフォローするアプローチを変えて、ちょっとだけ改善の兆しがみえてきた。
以下それぞれ深堀りしていきます
実際の状況でチームスキルについて考察
エンジニア経験無い人にプログラミングを教えて、アルバイトとして職場を紹介したとこの前書いたのですが、そこで
しばらくは自分も出来る範囲でフォローするのでアルバイトで採用とかどうでしょうと打診し
と書いてるように、現在その人のフォローをしつつ自分の仕事もしています。
諸事情あってスポット的に作る必要のものが出たので、彼が基本作業して足りない所を私がフォローしてという感じで作業を開始しました。
まず仕事力というものを考えてみた
作業開始段階で、頭数として1+1＝２名なので、ほぼ２名分のチームスキルとおそらく私含めてみんなそう捉えていたのかなと思います。
ところが、エンジニア経験、正確に言うと社会人としの経験もそこまで多くないので、自分が勝手に名付ける仕事力がまだまだ不足してます。
仕事力は抽象的すぎるのですが、Web系のエンジニアとしての仕事に限ると
- 技術的な側面
- 自分が頼まれてるタスク（チケット）をどの程度で完了させることが出来るか作業を見積もれる
という所かなと思ってます。
後者の位置づけが、読み手によって違和感を感じそうなので補足をしておくと、会社規模的には数十名規模で、チームといっても2〜3名規模でニュアンスとしてはひげろぐさんという方が1年位まえに書いた久々にチーム開発したのでメモがすごく伝わるのかなと。
２名チームなのに１名分のチームスキルになってる
上記で書いたエンジニアとしての仕事力というのを、私の仕事力はを１人、フォローしてる人の仕事力を0.5人程度とした場合に単純な足し算だと、
1 + 0.5 = 1.5
というのがこの２名のチームのスキルになるのでしょうけど、この数字ほどにチームとしてのパフォーマンスが出ないなぁと感じてました。
まず２名の力を組み合わせた時のスキルというのを算出するためにそれぞれの仕事力を掛け算してみます。
1 x 0.5 = 0.5
上記の仕事力に対して頭数である２名を掛け算してみます
0.5 x 2 = 1
２人で仕事をしてるのになぜか１名分という数字になりました！数字遊びをしたいわけではないのですがでもこの数字は自分の肌感覚ではかなり正解に近いんですよね(^_^;)
まとめ的にチームスキルの定義を考えてみました
まず
- 技術的な側面
- 自分が頼まれてるタスク（チケット）をどの程度で完了させることが出来るか作業を見積もれる
という観点でそれぞれのエンジニアの能力を考えます。
技術的な側面については
みたいな感じで利用する技術領域ごとに以下のような感じで数値化するとより正確になっていくのかなとーこれ書きながらふと思いました。
- 0.5: 他の人のフォローがないと作業が進められない
- 1.0: 過去似たものを作ったことがあるので多少調べながら作業が進められる
- 1.5: この↑レベルよりも作業がすぐに終わるしより保守性とか意識した作業もできる
上記でそれぞれのエンジニアの能力が把握できると思うので、チームが生み出すであろうアウトプット力を算出するため、それぞれのエンジニアの能力を掛け算して、チームが生み出すであろうアウトプット力を得ます。
チームが生み出すであろうアウトプット力が得られたら、それに頭数を掛け算してチームスキルになるのかなと
チームスキル＝チームが生み出すであろうアウトプット力 でしょうかね。なんかこういうのは偉い人がまとめてるのかもしれないけどひとまず自分の頭で考えてみたことなのでまとめておきました
なぜ１名分になるのか？
これは当たり前なんでしょうけど、経験浅い人に対して、技術的な側面に限らないフォローを色々やらないといけないから。
Issueの機能を利用して、そこで当面やってほしいことの単位に落としこんで作業をしてもらうようにしていたのですが、こちらの意図が正確に伝わらないケースがあって、そのIssueで期待してること以上のことまで作業してて、そこで行き詰まってしまって思ったような成果が出ないということがありました。
当初はそこが気づけず、時間がかかる背景がわからなかったため、それ以外の未着手のIssue（しかも簡単そうなもの）が溜まっていくため、そこのフォローに時間をさいていたので、自分が本来着手しないといけないことは遅れ気味になるので、そんなことが積み重なると１名分のチームスキルというのもあながち間違ってない気がしてます。
現状課題に対してどうしたか？
フォローをする側の人間が1名で全部抱えても
- チームが生み出すであろうアウトプット力 →１のまま
- 頭数→本来2名チームだけど1名で抱えると１になる
なので、1 x 1 = 1となり、結局は１のままになってしまうため、それを続けていっても長期的にはプラスになりません。
なので、フォローするアプローチを変えることにしました。
問題が何かを明確にするための工夫
そこで当面やってほしいことの単位に落としこんで作業をしてもらってるはずが、そのIssueで期待してること以上のことまで作業してて、そこで行き詰まってしまって思ったような成果が出ないというのが自分達のチームにおける課題かなと思ってました。
少なくとも経験少ない人には大丈夫？とか何か困ってない？という質問は避けるようにしてました。
※スタートアップな会社で技術責任者してる知り合いがスタートアップの"カオス"を生き抜く開発術で生産性を阻害するたった1つのありふれた問題で何が問題なのかが分からない以降の話が参考にしてたりします。
これはエンジニアに限らず仕事の経験少ないうちは自分がやってることを人に説明出来ないのでどんなプロセスを経て現在仕事をしてるのかを意識させる仕組みを入れてみたほうがいいのかなと思って90分単位でWIPなプルリクエストを出させるようにしました。
ひとまず、一定の時間軸の中でできることを意識させたり、プルリクを出すという作業を通じて、xxを見てたけどわからないという形でもいいので、少なくとも何らかのアウトプットを出させる意識を持ってもらうようにしました。
劇的な改善っていうのはないのですが少なくとも以前よりもどういうプロセスを経て作業に着手しているのかが見えやすくなってきたので、フォローの質が変わってきたかなと思ってます。
改善策についてせっかくなのでネーミングを考えた
90分という単位に深い意味がないのですが、互いにサッカー好きなのと、現場のリーダーもサッカー好きということもあって何かサッカーにちなんだネーミングを付けてもいいのではと提案して、90分単位でプルリクだすのをゲーゲンプレスとしました。
ネーミング大事っていうのはインフラで実践したチームビルディングそれはサバ天を書いてるume3_と少し前に飲んだ時に教わったのでそこの学びを活かしてやってみました。
ゲーゲンプレスというネーミング通り、経験浅い人には大分ハードな戦術なのでネーミング通りの制度かなぁと思ってます
最後に
最近色々考えることが多くって、ブログにしっかりまとめたいけど、ポイント絞ってまとめるのが難しい。。。
