nishida どこまでが「チーム」？ デザイナーやテスターの存在をどう考える？
新井：
これは、「作る」ということにともに関わり、チームに貢献できることがあるならば、みんな「開発者」に含めるということでいいんじゃないかな。
中村：
貢献、いい言葉ですね。もう少し軽い言葉がいいと思われる方もいるかもしれませんが、「貢献」とか「コミットメント」という観点は大事だと思います。
新井：
「貢献」という言葉に対して重さを感じるというのは、そこに自己犠牲のような意味合いを読み取ってしまうということでしょうか？
中村：
「大それたこと」と感じるんじゃないでしょうか。「自分なんかにはできない」と、謙遜される方が時々いらっしゃいます。
デザインすることも品質を確認することも、ものを作る上で必要な活動ですから、それを担っているデザイナーやテスターはチームに必要な存在ですよね。
例えば、「フロントエンドが得意なエンジニア」とか「テストが得意なエンジニア」と考えてみてはどうでしょうか。
デザイナーやテスターという枠にとらわれず、他のことにもチャレンジしていってほしいと思います。
新井：
専門分野の軸があるのは武器になりますし、さらにその周辺スキルも備わればより強い武器になりますから、どんどん伸ばしていけるといいですね。
参加者コメント：
どんなことでもなんらか「貢献」できていれば「開発」してますよ、と言える文化を醸成することも必要ですかね？
中村：
コメントありがとうございます。その通りだと思います。
以前、自分ではコードは書けないというマネージャーさんがいたんですけど、トラブル対応でみんなが残業しているときにお弁当やお菓子を買いに行ってくれたり、定期的にやってくる上層部からの進捗確認への対応を一手に引き受けたりしてくれていたんです。
そういう関わり方であっても、ともに開発している仲間と捉えていいのではないでしょうか。
「自分は何もできないから」と言っていましたけど、十分に貢献してくれていますよね。
新井：
そういうことを引き受けてくれる人がいるから集中できるし、パフォーマンスを維持できるんですよね。大事です。
中村：
チームメイトにプレッシャーをかけるような「貢献」の使い方はNGですけどね。
新井：
そうですね。チームビルディングでドラッカー風エクササイズを使ったりして自己発信できるといいかな。
Message from coaches
- チームに何らかの形で貢献しているなら、ともに作る「開発者」。
- 専門分野の軸があるのは大きな強み。それ以外のことにもどんどんチャレンジして成長していこう。
- 貢献しているかどうか？ の問いがプレッシャーにならないように、ドラッカー風エクササイズなどを活用して自己発信していこう。
チームにスキルが足りないとき、チーム外に頼るときのポイントは？
参加者コメント：
必要だけど常に必要ではない役割、例えばインフラやセキュリティ担当者もスクラムチームに含めるべきでしょうか。その場合でも専任化すべきでしょうか。
外部の方をコーチとして招くのは良いと思いますが、外部の方に作業を依頼するようになってしまうと、そもそもチームの定義から違ってきてしまうような気がします。
中村：
コメントありがとうございます。いい質問ですね！
組織の形や度合いにもよると思いますが、「機能横断的」というスクラムチームの観点から言うと、やはりチームのなかでデリバリーできるように知識は持っておいてほしいですね。
でも、決してスペシャルである必要はなくて、チームに必要なレベルでいいんです。
インフラやセキュリティ担当として、チーム外の専門家に力を借りるのも良いでしょうけど、そのことで毎回大幅な待ち時間が発生するようなら、チーム内にスキルを持つ人を入れることを考えた方がいいんじゃないでしょうか。
新井：
組織ごとの体制や人材採用の方針にも関わるので完璧な正解はありませんが、短期で解決できることと中長期で解決しなきゃいけないことを見極める必要がありますし、それを踏まえてチーム外にエスカレーションしなきゃいけないこともあります。
そのためにも、「ふりかえり」で適応する機会を設けたいですね。
中村：
時間軸で区切る考え方もできると思います。
今はチーム内にスキルがないなら、例えば外部の専門家に1〜2週間くらい一緒に活動してもらって、ペアプログラミングやモブプログラミングで最低限の知識をスキルトランスファーしてもらう。
最低限のところは自分たちでできるようになったら、専門家には一旦離れてもらって、またレベルを上げたいときなどに手伝ってもらうようにする。
そうやって「スキルを持つ人」を徐々に作っていくことができます。
新井：
関わり方に濃淡をつけるのはいいかもしれませんね。
Message from coaches
- 機能横断的なチームであるために、一通りの知識は持っておこう。チームやプロジェクトごとに必要なレベル感は違う。まずは最低限のところだけ押さえられればOK。
- 外部の専門家に頼ることでリードタイムが大幅にかかる場合は、スキルを持つ人をチームに加える方が良い場合も。中長期的な解決が必要なときはチーム外にエスカレーションしよう。
- 外部の専門家に力を借りるときは、時間軸を区切って関わり方に濃淡をつける方法も。ペアプログラミングやモブプログラミングでチームと一緒に活動したり、スキルトランスファーしてもらったら一旦離れてもらったりして、少しずつスキルを取り込んでいこう。
開発効率を上げようと思うと、得意なことをずっとやることになりそう
中村：
マネージャーが先を急ぐあまり、できる人に任せっぱなしになってしまうとか、そういうチーム外からのプレッシャーもある気がしますね。
新井：
短期的には効率重視でも仕方ない部分もありますけど、マネージャーや上位職の人にはもっと違う視座から、中長期的な視点で見てもらいたいですね。
中村：
マネージャーだからこそ、チームが「効率化の罠」に落ちないように見ていけるといいと思います。
すぐに結果がでなくても、広くチャレンジできる文化を作れるといいですね。
新井：
立場上、成果は出さなくてはいけないでしょうし、メンバーの育成にも責任があり、難しいところですよね。
中村：
限られた層だけではうまくいかないと感じます。もっと組織全体として変わっていけると広く定着していくのでしょうね。
Message from coaches
- 短期的な開発効率を追求するよりも、中長期的な視点で見て広くチャレンジできる文化を作ろう。
- 特にマネージャーや管理職にいる人は、チームが「効率化の罠」に落ちないように働きかけよう。
- 一つのレイヤーやチームだけでなく、組織全体でもチャレンジしやすい文化ができるとベスト。
redjourney.jp