機能横断型のスクラムチームって、どうすれば実現できる？ ─ ”とはいえ”シリーズ #7「開発者編」（前編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。

第7回のテーマは「開発者」です。前編では、「開発チーム」から「開発者」へと呼び名が変更された意図について考察しつつ、機能横断型のチームを実現するために必要な視点やアプローチ方法についてお話します。

「開発チーム」から「開発者」へ。変更された呼び名に込められた意図とは？

中村：
まずは、スクラムガイドの「開発者」の項目を一緒に読んでみましょう。
短い文章ですが、いろんなことが読み取れますね。

新井：
ポイントが詰まっていますよね。

中村：
元々の英語版スクラムガイドでは、「開発者」＝「Developers」となっています。
語尾に「s」が付いていて複数形になっているので、日本語で言うと「開発者たち」ということになりますね。
そんなところからも理解を深められるかもしれません。

新井：
英語版を読むことによって閃きがあったり、新たな解釈へと繋がったりするかもしれませんね。

中村：
以前のスクラムガイドでは「開発者」ではなく「開発チーム」という言葉が使われていました。
なぜ、呼び方が変わったのか？　疑問に思われる方も多いのではないでしょうか。

新井：
洋さんは、どんな意図があると思われますか？

中村：
開発者たちを「開発者チーム」とすることで、スクラムチームの中にもう一つチームができてしまいます。
分断を防ぐためにも、「チーム in チーム」は作らない方がいいですから、その辺に意図があるのかな。

新井：
個人や役割によってタスクや責任を振り分けるのではなく、「スクラムチーム」という一つのチームとしてすべてを握るということですよね。

チームと言えばスクラムチームのこととすぐ分かるように、「開発者チーム」ではなく「開発者たち」としたということかな。

中村：
そうじゃないかなと思います。

それと、「構造をシンプルに保つ」という意味合いもあると思います。
チームの中にチームがあると、構造として複雑になってしまいますよね。

新井：
日本語の「開発者」だとプログラマーやエンジニアがイメージされますけど、英語の「Developers」はもっと広いニュアンスで使われる言葉ですよね。

中村：
いわゆるプログラムを書く人というだけじゃなくて、「ものを作ることに関与する人」という風に、もう少し広い意味で使われる言葉みたいですね。

デザイナーまで含めるかは分かりませんが、要するに「良いプロダクトを作るために関わる人」といったニュアンスがあるようです。

新井：
そういう意味では「開発者たち」（Developers）という呼び名はより実態に合っているのかもしれませんね。

中村：
それと、プロダクトオーナーからするとメンバーに対する呼び名があるのは分かりやすくて助かりますね。

新井：
リモートワークが増えたことも関係しているかもしれませんね。
アイコンタクトに頼らないコミュニケーションでは、誰に向けて話しているのかが伝わりにくいですから、より分かりやすい呼び名が必要です。

Message from coaches

• 英語版では「開発者」＝Developers と複数形で、言葉の持つ意味合いも日本語の「開発」とは微妙に異なる。英語版から理解を深めるのもおすすめ。
• 「Developers」は広く「良いプロダクトを作るために関わる人」というニュアンスの言葉。エンジニアやプログラマー以外も「開発者たち」に含まれる。
• 個人や役割によってタスクや責任を振り分けるのではなく、ワンチームとして取り組むことが大事。分かりやすい言葉とシンプルなチーム構造を保つことで分断を防ごう。

開発リーダーのような人がいないと、まとまらないのでは？

中村：
これもよく耳にする質問ですが、どうでしょうか？

新井：
新入社員とベテランとでは経験、スキル、知識や場数が全然違いますから、「リーダー的な存在」が出てくることはあると思います。

ただ、特に「リーダー」という役割を用意する必要はないんじゃないでしょうか。
名は体を表すと言いますが、「リーダー」と呼称することでみんなが頼るようになってしまったり、責任感が生じたりしがちです。

「開発者同士」として、なるべくフラットに組めるといいですね。

また、チームとしての成長がすごく大事です。1ヶ月ないし半年間といった期間を設けて師弟関係を組むのもいいと思いますし、ペアプログラミングやモブプログラミングをしながら、徐々に役割を交代していくようなフォーメーションが取れるといいんじゃないかな。

中村：
たしかに、体制図の中に「リーダー」として名前を書き入れるような決め方は危うい気がします。
自分たちで役割の境界線を引くようなことは避けた方がいいのではないでしょうか。

例えば、テストに関してはAさんが詳しいからAさんがリードする、UIに関してはBさんがリードしていく、っていう感じで、ある局面を「リードする人」はいてもいいと思います。

新井：
「リーダー」ではなく「リードする人」というのがポイントですよね。
「誰でもできるんだよ」「一人でやるのが心細ければフォローし合えばいいよ」っていう風に、より「フェア」な状態が作れるといいですね。
そうすれば、「誰もリードしたがらない」なんていう事態は防げるはずです。

中村：
「ジュニアエンジニア」と「シニアエンジニア」みたいな組織の職制上の区分けがあったりすると、またちょっとややこしいかもしれませんね。

新井：
そうですね。明確な等級以外にも、暗黙の境界があるような状態はできるだけ避けたいですね。

参加者コメント：
局面によってイニシアチブを持つ人を変えていけるように促すのもスクラムマスターなんですかね？

中村：
コメントありがとうございます。そうですね。得意な人が継続してやる方が効率的でいい、となりがちなので、そこを壊すのはスクラムマスターの役割かな。

もちろんスクラムマスターだけがやる必要はないと思います。「誰かやってみたい人いない？」とチームに投げかけてみるとか、スキルマップや星取表を持っているなら、そこからのアプローチも可能です。

新井：
長期的な目線で見ていけるといいですね。
短期的な効率を追い求めるあまり個人に役割が集中してしまうと、結果としてその人が抜けたらどうにもならない状態になってしまいます。

Message from coaches

• 開発者同士はできるだけフラットな関係性でいよう。
• 「リーダー」ではなく、局面ごとに「リードする人」はいてもいい。誰かの負担が重くならないように、お互いにフォローし合って「フェア」な状態を作ろう。
• チームとして成長することが大事。技術や経験の差を利用して一時的な師弟関係を組んだり、ペアプログラミングやモブプログラミングを活用しながらチーム力を上げていこう。
• 短期的な効率を追い求めるのではなく、長期的な目線でチームの成長のためにより良い方法を考えよう。
• チームに変化を促すのはスクラムマスターの役割の一つ。でも、スクラムマスターだけがやる必要はない。