1. ゆるテク
  2. #14 職能横断チームって大切な..

職能横断チームって本当に大切なんだっけ?について話しました。最後の方に少しだけペアプロの話してます。

ゆるテクは @junichi_m_ と @hacktk がゆるーく技術の話をするポッドキャストです。 感想は #yurutech をつけてツイートしてください。

Twitter:

・ゆるテク: https://twitter.com/yuru_tech

・@junichi_m_: https://twitter.com/junichi_m_

・@hacktk: https://twitter.com/hacktk

職能横断チームの重要性
ゆるテクは三長と博多家が緩く技術の話をするポッドキャストです よろしくお願いします
よろしくお願いします
はいというわけで今日のお話をしていきましょうか
はい今日はいったいどんなトピックが
はいえっとですねちょっと最近実は久々に組織というかチームについて
インプットし直してですね
でその中でまあよくアジャイルの文脈とかに出てくると思うんですけども
あの職能横断チームを作ってチーム一つでバリューを届けられるようにしようみたいな話ってあるじゃないですか
はいまあその理由ってすごく私自身も理解はしてるんですけれども
ただ実際その職能横断なチームが作りたいと思いつつも現場現実ってそうじゃないよねっていうケースもあると思ってて
じゃあその職能横断チームってどれぐらい大切なものなんだろうっていうのを
答えはないんですけれども博多家さんとちょっと話せればいいかなと思ってます
はい大切か難しい
はいどれぐらい優先していきたいかなっていうところですかね
でなんかそのチーム系のインプットをしている時に一番最初に読み直したのがチームトポロジー
通称チートポってやつですよね
の本を読んでてその結局というか職能横断チームってチームトポロジーでいうとこのストリームアラインドチームのことを
主に指しているかなと思ってますと
でちょこちょこそこの章とかを読んでるとそのストリームアラインドチームって割とこうジェネラリストと
スペシャリストっぽい人たちの組み合わせ
チームで組み合わせて作られてますみたいな話があったりするんですけど
それでまず読んでて一つ思ったのは
なんだろうなこうそういうチームだとしてもスペシャリストが例えば一人しかいないとか
チームトポロジーによる考察
ってなった時にそのチームで仕事をするとき
下手すると特定の領域がすごく一人に負担がかかっちゃうんじゃないかなって
思ったんですよ
いわゆるSPOF、SPOF、シングルポイントオブフェーラーみたいなことですよね
ですですであったりとか多分VSMとかで言うとヒーローヒロイン問題的なものにも近いのかなと思ってて
そうですね
でなんかそうなった場合ってよくあるのはじゃあペアプログラミングしてみんなで知識をこう
共有していきましょうであったりとかあとMOVプログラミングをして
チームの暗黙地を育てていきましょう形式地を作っていきましょうみたいなアプローチがあったりすると思うんですけど
それ以外のこういう考え方もあるんじゃないかとか
逆にそれをやったとしても実際スペシャリスト一人だったら
大変なんじゃないかみたいなことをちょっと考えてみたいなって思ってて
なるほど
はい
あのなんていうかなその
まあスペシャリストというか例えば特定の分野にここで言うスペシャリストっておそらくあれですよね
特定の分野に強いぐらいの意味で言ってると思うんですけど
はい
まあよく言われるのはT字型というか
うんうん
一つ強いところがありつつも他のところもなだらかにちゃんとスキルがあるような人たちの集まりが良いっていう感じですよねやっぱり
そうですねそうですね
でその場合でも例えばスペシャリストが2人みたいな時ってどこからがスペシャリストなのっていうことになると思うんですよ
ほうほうほう
なんか例えば何があるかな
例えばJavaのアプリケーション作ることができますみたいなざっくり能力があるとしてどの程度以上ならその人はそのスペシャリストと言えるのみたいな話があると思うんですよね
スペシャリストの偏りとバランス
そうですね確かに
まあつまりどのぐらいのスキルになればその一人に負担がかかっていないよねっていう状態になるのかを考えるといいかもしれないですね
ああなるほど今のその博多家さんの話を聞いてパッと思いついたのはなんかよくスキルマップとかあったりするじゃないですか
星のよくできるとかで表すあれですよね
ですです意外とその細かく厳密にスペシャリストの定義をするっていうよりはチーム内でっていう組織内でそういったなんだろうな
スキルマップでこれをつけてたら我々ではスペシャリストっていう扱いだよねみたいな感覚でもいいのかもしれないってことですかね
そうですね今そしてそれを聞いてさらに思ったんですけどなんか偏りがあるとダメなのかもしれないともちょっと思ったりしたんですよね今
偏り
はい例えば数字の方がわかりやすいかな5 4 3 2 1とするじゃないですか
はい
なんかチームが4人だとして4 4 2 1みたいな感じだったら自分は2人強い人がいていいなぁみたいな思うんですよね
うんうんうん
でもこれが5 2 2 2みたいな感じだとなんかちょっと辛くないですか偏ってないですかね
偏ってますねというよりはもう 一人で引っ張っていくぐらいの感じの
レベルですよねそうですねなのでなんかこれはもしかしてスキルの高い人がいればいいという話ではないのかもしれないなぁってちょっと
ああ 確かに
バランスというかなんだろうその なんだんだその
偏ってるかどうかはそのスペシャリストの人がどのぐらいスペシャリストなのかにもちょっと依存するなぁと思ったんですよね
確かに
だからさっきの例で言うと5 2 2 2だったらすごい偏ってる感じしますけど
はい
3 2 2 2なら偏ってない感じません
スペシャリストってよりはあのこの中では僕が一番できますかねぐらいの感じですよね
そうそうでもなんかその健全さみたいなとこだけで言うならそっちのがまだ健全じゃないですか 多分
そう思いますあの少し 見て
見ててとか読んでて思ったこととして例えば今博多家さんおっしゃってくれた522のパターン とか
が仮にあったとした場合にえっと 多分えっと
この人がやる作業と2の人がやる作業ってめちゃめちゃ多分品質で抽象的ですけど 品質に差があると思うんですよね
例えばコーディングで言えばよりその 保守性とか情緒性を考慮した行動がかけているパターンと
ちょっとそうでもないパターンに分かれるみたいな でそれを例えば522だからじゃあ最初のうちはそういう行動があるんだけど
この2の人たちがこれから3とか4に上がっていくための 授業料だよねっていう捉え方をして
プロダクトを作っていくのか それともでもそういう行動が入っちゃうと割れ窓の法則になってどんどん
職能横断チームの重要性
プロダクト行動が廃れていくよね だからそれはちょっと許せなくないっていう
戦略をするのかで 結構そのチーム構成を許すかどうかって変わってきそうですよね
変わってきそうですね 確かにならしい
でもあの もう1個さっき出した3222のパターンだと
そもそもそのなんだっけ 品質を上げていくパターンの戦略取れなさそうな気がしたんですよ
やっぱチームの中で一番できる人の能力にキャップされませんかね そのいわゆる品質というもの
されますね 3位以上に上がらない気がするんですよねやっぱりみんなが頑張っても
チーム内だけだと難しいのかもしれないですねそうなった場合って そこで出てくるわけですかね
イネイブリングチームとか そういうことか 誘導したわけじゃないけど
あれって でもそういう目的もあるんですよね 基本的にあれでしたよね認知負荷を下げるための
そうですそうです 今のあれイネイブリングチームであってますよね
はいそうですね イネイブリングチームっていう考え方もありだと思うし
あとはなんかちょっと違うかもしれないんですけどあの spotify モデルあるじゃないですか
あれでよくチームのやつですね そうですそうです
同じ専門性を持つメンバーのグループを作ってそこで要は交流するっていうか
情報交換するっていうチャプターっていう概念があったりするんですけど
あれなんかちょっと違うのに思いつつ 今の自分の頭の中にスクワットとかいう単語が出てきたんですけど
スクワットが言ってしまえばストリームアラインドチーム的なやつですね
ああそういう感じなのか なんでスクワット自体が職務職能横断的になってて
スクワットが複数個あった時にそれぞれのスクワットの中にまあそれぞれのスペシャリストがいるわけですよね
はいはい まあジェネラリストもいますけど
でそれだけだと今多分博太家さんが言ったような問題って起こるかなって私も思ってて 3人2位だったらあの3以上にはならないんじゃないかって話
ただそれがじゃあ 同じ専門性を持った人たちで集まった時にじゃあそれが実は3
3、5、5とかだったらその人たちの中では底上げができると思うんですよ
でその3の人が5の人から吸収したものを自分のスクワットに持って帰ってなんか3.5、4、4.5っていう風に上がっていくみたいなことを
やるパターンもあるんだろうなって思ってて なんでイネーブリングチームとして持ってるのか
そういうのはあまりなくてその横の繋がり、横っていうかチャプターとして持って
各々それぞれの専門性はそれぞれで高めていきましょうみたいなスタイルを取るのかっていうなんだろうな
そのプロジェクトの状態、現実によってそこらへんって実は組み合わせでやっていかないと
難しいんだろうなっていう話で思いましたね
チャプターを通したコミュニケーション
確かにな
そのチャプターっていうの知らなかったですね、それはなんかチーム外の繋がりみたいな意味でしたか
少し全体をいくと確かSpotifyモデルの一番外だったかな、トライブがまずありますと
同じ類似しているとか関連しているミッションを持つスクワットの集まりっていうのがありますと
なので無理やりチートポの表現で当てはめるなら多分トライブの中に何個かストリームアラインドチームがいるみたいな
そのトライブの中の同じ専門性を持つ人たちの集まりというか、まあ集まりでいいのかな、構成されるのがチャプター
本当だこれか、スクワットでチャプターが横
それがおそらくさらにトライブをまたいでいくレベルになってくると
キルドになってみたいな話だったかなって
この図見たことあるな、忘れてる完全に
何度か私も最近見直してて
そうかそうか、だからイネーブリングチームだとファシリテーションのコラボレーションみたいにして外からチームに教えにくる感じですもんね
そうですそうです
確かにな、分けないといけないか
イネーブリングチームのような構成にして外から徐々に調整させていくパターンもあるでしょうし
そうじゃないんだっていうパターンで今のチャプターのような形式をとって
横で専門性を高めていきましょうっていうのも多分ありだと思ってて
意外とそういうとこってハイブリッドに使ってるところとかがあったりするのかなと
食の横断チームの存在意義
そうですね、それも一番最初の話に戻ると
食の横断チームがみんな大事だと思ってるからですよね
そうですよね
食の横断にしたいから
そう
これちなみに、なんで食の横断チーム大事だと思うかっていう疑問が出てきたんですか
えっと、疑問ってわけではないんですけども
思考停止したくないなって思ってこれをちょっと考えてたっていうところなんですけど
よくアジャイルの文脈だと冒頭に話したように食の横断チームって大事だよねとか
スポティファイモデルの話でも食の横断チーム大事だよねって話はありますと
で、ただ、食の横断にできないとか食の横断が難しいっていうケースもやっぱり事実としてあって
ただ、食の横断じゃないからこれダメじゃんっていうところで思考を止めちゃうと
その先の発見って多分ないなって最近思うようにしてるんですよ
何て言うんでしょうね、例えばじゃあ
ウォーターフォールやってるなんてイケてないよねって止まっちゃうってもったいないじゃないですか
もったいない
本当にイケてないのかな、なんでなのかなって考えないと
他のものの良さとか、他のものと比較するときに
どこが大事なのかって本質を見極められないかなって思って
なるべくこうすぐ答えが出てもしっかり考えようって考えるようにしてるんで
この話を持ってきたって感じです
なるほど、すごい良い話の匂いがする
本質で言うとだから食の横断チームがなぜ大事かっていうと
つまり独立してデリバリーできるからでしたかね
そう、独立してデリバリーができるし
もちろんそれが大事なんですけど
あとはやっぱりそのチーム間、食の横断じゃないパターンの
チーム間のコミュニケーションコストとか手戻りの無駄があるからだと
個人的には考えてて
その手戻りのところに対してコミュニケーション設計がめちゃめちゃうまくできて
大丈夫なんですってなった場合って
食の横断チームを作るか外部に力を求めるか
本当に食の横断じゃなきゃダメなのかな
とか、あるいはそのコミュニケーション設計がめちゃめちゃうまくできちゃったら
それってもう食の横断チームになってんじゃねって解釈なのか
なるほど、なるほど
をちょっと考えてましたね
確かにそうですね、さっき言った通り
食の横断チームを作りたいのは他チームとのコミュニケーションコストがもったいないから
それを限りなく減らすためのものだとしたら
まあそれは他チームにスペシャリストがいて
そのスペシャリストとのコミュニケーションコストが限りなくゼロに近ければ
それはもう別に食の横断チームである必要はないですよね、そこが
そう、ただ限りなくゼロになってるってことはもう同じチームなんじゃないのって
捉え方もできますよね
他チームだったらどうしてもコンテキスト違うから
コミュニケーションコストゼロにならないですもんね
もっと言うと気になるとすれば
ストリームアラインドチームがどういった開発フローというかデリバリーフローを取っていくかにもよってくると思うんですよ
例えば、型やスクラム開発を適用してスプリント単位で動いてます
もう型や別にスクラムとかスプリント単位ではなくて
違う型を使って進めてますってなってきた場合に
型の特性によって優先順位の調整とかがめちゃめちゃ変わるじゃないですか
それってどう考え、現実の私はどう考えても無駄は発生するなっていう答えしか今出てこなくて
そうなるとさっきのコミュニケーション設計をうまくやって
そういうところのロスを限りなくゼロにしようっていうのって
現実的なのかな、できるのかなって
まあ難しいですよね
だからそうなるとコミュニケーションコストを払って
外部にスペシャリストを持つ、自分たちで職能横断にできていない分野に対しては
外部に対して力を求める、そのコミュニケーションコストを払うのか
自分たちを職能横断チームとして、誰かをチームに入れるなり自分たちが学習するなり
で、職能横断チームになるかの二択なわけですよね
そう見えますよねやっぱり
他にもあるかな
他に、他に
何かあるのかな
あの、区切り方、チート本読んだっていうかガッツリ読んでるわけじゃないですけど
思ったのが、コンプリケーテッドサブシステムチームあるじゃないですか
これめっちゃ定義曖昧だなと思って
例として機械学習とかそういうのあげられてるじゃないですか
専門性が高いといえば専門性が高いって表現できそうですよね
なんかすごい分かんないですけど、全然やったことない人から見たら
CI/CDとかの仕組みを作ったりとか運用したりすることだって
それに当たるんじゃないかとかと思っちゃうんですよね
わかりますわかります、確かに
なので、ストリームアラインドチームの認知負荷を下げるっていう意味であれば
ストリームアラインドチームが職能横断チームとして
今持っていない能力の部分は全部外に移情してしまうっていう方法ももしかしたらあるのかもと思いましたね
そうなると逆を定義してもいいかなと思ったのが
ストリームアラインドチームはどこまで認知しようかを決めちゃえば
どこからがコンプリケティッド、何でしたっけ、忘れちゃった
サブシステム?
サブシステムチームなのかとかになったりするのかもしれないですよね
確かにそうですね
確かにだいぶ曖昧は曖昧ですよね
そうですね、それでだいぶあれかな、職能横断にできるかできないかがちょっと調節できそうな気もしないでもない
職能横断って言ってる内容って、なんとなく技術の進歩によってどんどん中身は変わってきそうですよね
そうですね、それはありそう
今おっしゃってくれた機械学習もそうだし、もしかするとインフラ系の話もそうですけれども
逆にそれが1エンジニアとして習得するというか、使いこなすのにあまりコストがかかんないってなってくると
むしろ職能横断に入ってきちゃうかもしれないし
確かに、そうですね
専門としてやっぱりディグンないと無理ですみたいな分野になってくると
それをストリームアラインドチームでやるとストリームの滞りが起こっちゃうから
外に出した方がいいですねとかになるかもしれないですもんね
確かにそうですね、インフラ系は多分このここ近年で
チーム構成と戦略
今はきっとストリームアラインドチームに必要な能力の一つになってると思うんですけど
昔、それこそオンプレでサーバーを調達してきて、セットアップしてみたいなところからやってた時代だと
ネットワークの知識とかもがっつりいるし、ハードウェアの知識とかそこだと厳しかったかもしれないですもんね
そう、その変化もちろんあるんだろうなって思いますよね
それも例えば世の中の変化もそうですし、今の各々の現場の技術スタックの分布を見た時も同じなんですよねきっと
そうですね、そうですね
なるほどな、どれくらい大切だと思います?
結論で言うと大切なんですよね、間違いなく
そうですね、どのくらい犠牲を払うかってことですよねつまり
だからこれを大切とした上で、これを作っていく戦略もあるし
一部は技術的不採としてまずは払って、走ってその次のターンで返済しますっていう戦略を取って
チーム構成を考えるっていうパターンもあるんだろうなと思って
そうですね
一番辛いのはおそらく技術的不採を払ったんだけど返済せずに
もうとにかく次を作らなきゃいけないんだっていうビルドトラップ的なものにはまって
突っ込むのが一番辛そうですよね
そうですね、そうですね
この不採のメタファーでちゃんと認識が合ってるかどうかわかんないですけど
多分経営的な認知でいくと
借り入れできる不採はどんどん借り入れるべきだみたいな結論になるんですよねきっと
なるほど
なので返せるかどうかわからんけど借りれるならいくらでも借りるみたいなのが多分正しいんですよね
不採の解釈とコードベース
この不採というそのメタファーのままでいくとですよ
実際はそんなことないから、あのコード
我々が話してる不採は多分コードベースの話でしょうから
そのコードベースの不採は実際のお金の不採と違ってすぐに返せないので
そうですね
借りすぎは良くないっていうのはもう完全にその通りですね
その場合は借りすぎるとバンアウトとか離職につながる未来しかなさそうな気がするので
確かに
どんどん辛くなっていくことしかなさそうですよね
でも一定やっぱりそのさっきの成長の話もありますからね
うんそうなんですよね
個々人のスキルというか
そうですそうです
だからそういう意味でいうと知らず知らずのうちに借り入れしちゃってるんですよね
おっしゃる通りだと思います
初めてやることなんて多分ほぼほぼ借りてる気がしますよね
間違いないです、借りなかったことがないぐらいだと思ってます
なんか返そうとした時に
昔の自分こんなの書いてたのかーってなりますよねきっと
なります、それでも気づけてる分まだ良いというか
気づけないこともあるからな
うんそうなんですよね
チームにおけるファシリテーションの役割
はい、というなんでしょうね
食の横断はいいって思ってるんだけれども
そこに固執しすぎて辛くならないかな
大丈夫かなをちょっと考えてみた回って感じですね
そうっすね、ちなみに
ちょっとだけリアルな話を三沢さんに聞いてみたいんですけど
はい 食の横断、どのぐらい食の横断にできてますか?
多分完璧にはできてないと思うんで
どういうことをしてますか?するために、食の横断にするために
どの立場で表現するといいですかね
例えば自分がチームの中に入っている時なのか
あるいはなんだろうな
そうだった、EMだった三沢さん
うまく言えないですけど、マネージャーとして
人をどこにアサインした方がいいのかとかを考えている時なのか
チームの中に入っている時の話を聞きたかったんですけど
最近入ってますか?
そろそろ入る機会が出てきそうっていうぐらいですね
なので入ってた時の話をした方がいいんですかね
過去の話で
過去の話で言うと
基本私が意識してたのはファシリテーションの部分だったかなと思ってて
自分が例えば、私は基本インフラ側をよく触る人間なので
そういうチームに入ってた時って大体
フィールマップで言うとインフラ周りの数値が高い人だったんですけれども
なるべく自分が全部引き受けることはやらないようにしていて
何名かというか
興味のある人を集めてファシリテーションして
一緒にインフラを構築していくみたいな経験をなるべくつくるようにしてましたね
やっぱりそんな感じか
じゃないとずっとそこが自分の依存になるっていうところと
ある程度スペシャリストだろうが、ジェネラリストだろうが
一定の共通言語を持って会話ができないと
うまくコミュニケーションが取れないなっていうのを過去に実感したことがあったので
ここの共通言語まではみんな持とうっていうようなやり方をやってた感じですかね
なるほど、共通言語を意識するのか
ペアプロやモブプロの有用性
そのあれなんですよ、今三坂さんが言った状態
自分がインフラ方面では一番強い状態
完全に今の自分なんで
そうなんですね
どうしたもんかなみたいなのを考えてたんですけど
ここまでは知っておきましょうを定めるといいのか
これは後になって気づいたことなんですけども
エンジニアリングマネージャーの仕事の書籍の中で
人を学習させる時の最近説領域でしたっけ
話してましたね
はい、でその学習をさせていくのが
効率がいいというかその人が成長しやすいみたいな話を読んだ時に
ちょっと自分の過去を振り返ってこういう時のやり方って微妙だったんだろうな
改善が元できたんだろうなって思ったのが
最近説じゃないタイミングでペアプログラミングとかモブプログラミングをして
その最近説のように振る舞っちゃうとほぼほぼ定着しないなっていうのを実感してですね
なるほど
要は問いかけても何が分からないか分からない状態ってやっぱあるじゃないですか
なので全然その共通言語の暗黙地も育ってない状態で
まるで共通言語があるかのように振る舞ってるとめちゃめちゃ時間がかかる
なるほど確かにな
なんか分かったようにして進んじゃいますしね
そうなんですよ
なるほどな
よしすごい参考になりました
参考になったなら良かったです
ありがとうございます
そうですねただどうなんでしょうね
悲しいのはやっぱ自分が知らない領域になった時に教えてもらったとして
結構やっぱ土地観掴むのがすごい大変だったのを覚えてますね
確かに
今話してくれてるのがどの立ち位置のどこに立っての話なのかなっていうのがよく分からなくて
教えていただいている時でも結構点になっていることが多かったですね
うんうんうん
全体から説明されて今から話すところはここみたいな感じがやっぱり分かりやすいですよね
はいなのでなるべく人とそういう目的でペアプロとかモブプロをする時はその構成でやることが増えました
なるほどなるほどペアプロな
ペアプロとか今やってるんです?
全然やってない気がする
全然やってないなペアプロ
でも一人の時は一人の時で結構がっつり集中もできるからいいはいいですよね
そうですねでもペアプロやってないですけどモブであれですねいわゆる不採と言われる行動を見たりはしてますね複数人で
じゃあ皆さんでこうでもないこうでもない言いながら
そうですねいやーこれは辛いねみたいな話をしてますね
いいですね
そうですねでその時今最初はもういきなりリファクトリングとか始めず
単にコード理解のために読んでるんでコメントだけつけて言ってるんですよ情報を増やして言ってるだけ
なるほど
壊れないので流石にコメントを入れたぐらいじゃん
予報のことをやってない限り大丈夫ですよね
この方法は確か三長さんとペアプロした時にやってたのを覚えてるんですけど
やってましたね
確かそんなことやってませんでしたかね
職能横断チームとは
多分なんていうんですかね釘を打ってるようなイメージですね
この辺なんかこうじゃないっていうのをとりあえず先に入れてってことやってましたよね
やってましたやってましたであれが多分わかりやすかったから
よかったよかった
やってる感じですね
そういうエピソードを聞くとちょっと博多家さんと一緒に仕事をしてよかったなってなりますね
いやこちらのセリフですねよかったです
はいちょっとそんななんでしょうねきっと職能団がいいってわかりきってるけど
あえて疑ってみた後半ちょっとだけペアプロがどうこうっていう話をした回になっちゃいましたね
はいいやいい話だった
よかった
はいであれですね結構そのこういうチーム構成とか
うちはこうやってますよって本当に現場に寄り切りというかプロジェクトに寄り切りなところがあると思うので
ぜひ何かもしこれを聞いてくださった方で自分たちはこんな悩みがあったなとか
こうやってやってますとかあれば教えてほしいですよね
いやもうめちゃめちゃ聞きたいですね
なのでぜひよろしくお願いします
フィードバックをよろしくお願いします
フィードバックの依頼
はいでそのフィードバックなんですが
主にツイッターでハッシュタグアルファベットのゆるテクをつけてツイートしていただけるとありがたいですお願いします
お願いします
はいそれでは今日はありがとうございました
ありがとうございました
34:09

コメント

スクロール