20260912_スクラムにジェネラリストは必要か

Scrum Fest Mikawa 2026の登壇資料
https://confengine.com/conferences/scrum-fest-mikawa-2026/proposal/50493

Transcript

1. スクラムに ジェネラリスト は必要か 2026-09-12 Scrum Fest Mikawa @ryugen
2. whoami 経歴: 株式会社ヘンリーに2025年11月join 医療・ヘルスケア領域のWebエンジニ ア,PO(ロールはEpic Owner)やっています。 山本竜玄 Yamamoto Tatsunori (@ryugen04) 趣味・領域 : Neovim好きです/スクラム好きです アクアリウム/カポエイラ/薬剤師 その他: ビールが好きです！
3. チームにいるジェネラリスト 以下のような人、周りにいませんか？ • プロダクトの仕様もある程度わかっている ◦ でもすべてや背景まで熟知はしていない • 実装もある程度はできる ◦ でも圧倒的なICではない • Product Ownerや、QA担当、Domain Expert、Managerとの間に入れ る ◦ でもロールは別にある。Developerとか とにかくチームに居ると、なんとなく助かる人
4. GeneralistとSpecialist Generalist • 複数の領域にわたる知識・Skillを持つ • 特定の一領域だけに専門化しない Specialist • 特定の領域に深い経験・知識・Skillを持つ • その領域を専門として扱う
5. ジェネラリストって200色あんねん
6. 近い考え方 Generalizing Specialist • 一つ以上の専門領域を持ちながら、周辺領域にもスキルを広げる • Software Development全体と、扱うBusiness Domainについても知 識を広げる • Generalistとは異なり、「master of a few」であることを前提とす • 専門職間のhandoffや専門家待ちを減らし、Whole Teamで動きやすく する • (https://agilemodeling.com/essays/generalizingspecialists.html)
7. 境界をつなぐ人という見方 Boundary Spanner • • • • • 組織やUnitの境界をまたいで活動する 境界の外側から情報を取得し、内側へ持ち込む 異なる集団の間で情報やKnowledgeの移転を担う 個人のSkill Breadthではなく、「境界をどう接続するか」を見る概念 (https://journals.aom.org/doi/10.5465/amr.1977.4409044)
8. そんなカッコイイ英語だけでなく、 日本語でこういう言い方 もありますよね？
9. 私は 潤滑油のような人間です！
10. 潤滑油でいいのか？ あなたの専門性はなんですか？
11. プロフェッショナルへの憧憬と劣等感 ジェネラリスト的な立ち回りは評価されてきた、 それでも、自分は何かのプロフェッショナル になりたかった • DeveloperとしてはReact, Kotlinなどを書いているがどれも一流とは言い 難い • 医療ドメインの知識はあるが、現場の医療従事者などの専門性・経験には 及ばない • Scrum Masterとしてのロールではなく、ただスクラムに少し詳しい人
12. スクラムにジェネラリスト は必要か？
13. Scrum Guide(2020)から考えるジェネラリスト • (※スクラムチームについて)一度にひとつの目的(プロダクトゴール)に 集中している専門家が集まった 単位である • スクラムを構成するには、作業に必要なすべてのスキルや専門知識を 「グループ全体として 」備える人たちである • Scrum Teamは機能横断型で、各Sprintで価値を生み出すために必 要なすべてのスキルを備える • Scrum Teamは自己管理型 で、誰が何を、いつ、どのように行うかを Team内で決定する 個人としてのジェネラリストは必須ではない と読める
14. なぜ自分は 「ジェネラリストでいいのか 」 という問いにそこまで引っかかるのか？
15. 専門性への不足感と、境界にある仕事を拾うクセ • • • • • 「何か一つのプロフェッショナル になりたい」という不足感 専門領域の境界にある仕事に気づく 自分にも拾えそうなら入っていく 仕事が前に進む また境界にある仕事を拾う この動きを色んな場所で繰り返していた
16. Developerとしてプロジェクトで担当したこと • • • • • • • Developerとして参加 社内で約2年間検討されていた機能追加のEpic ドメイン概念の追加、会計計算・帳票出力までを扱う デザイン案はあったが、スコープは未確定 PBIは「やりたいこと」の一覧に近い状態 Domain上の計算条件や帳票仕様も未整理 技術調査・検証はほぼ未着手 実装を始めるのは、まだ整理が必要な状態だった
17. Developerとして実装周辺で未整理だった仕事 • 技術調査 ◦ マスタデータの取得元、取り込み方法、バッチ • PBI ◦ 仕様や判断材料が十分に整理されていない • 調査事項 ◦ 実装するものと、先に調査・検討するものが混在 • Domain ◦ 計算条件や帳票仕様が未整理 ◦ Domain Expertと開発との接続の弱さ
18. 境界にある仕事を拾うことで起きたこと Good • PBIや仕様の整理が進んだ • Domain Expertとの連携が増えた • 実装を進められるPBIが増えた Bad • 仕様の背景や判断経緯を自分が多く持つようになった • 専門家への相談経路を自分が管理するようになった • 自分への相談が増えた
19. 今回の動きを考え直してみる
20. Generalizing Specialist • Scott Amblerがアジャイル開発の文脈で提唱した実践上の概念 • 一つ以上の専門領域を持ちながら、周辺領域にもスキルを広げていく 人 • Software Development全体と、扱うBusiness Domainについても一 般的な知識を持つ • SpecialistとGeneralistの中間でなく、「master of a few」でありながら 複数領域を扱える存在 • 専門職間のhandoffや専門家待ちを減らし、Whole Teamとして動きや すくする • (https://agilemodeling.com/essays/generalizingspecialists.html) 個人が、どれくらい深さを持ちながら周辺へ広がれるか
21. Expertise Coordination Faraj & Sproullが69のSoftware Development Teamを対象に調査 • Teamに専門知識を持つ人が存在するだけでは十分ではない • Expertise Coordinationを次の3つの行動として捉える ◦ 誰が専門知識を持つか ◦ どこで専門知識が必要か ◦ 必要な専門知識を実際に投入できるか Generalizing Specialistが「個人」を見るのに対し、 こちらは「Teamが必要な専門性を必要な場面で使えているか」を見る (https://doi.org/10.1287/mnsc.46.12.1554.12072)
22. Boundary Spanner / Knowledge Transfer Aldrich & Herker(1977)/Zhao & Anand (2013)に整理した、組織や集団の 境界をまたぐ役割 • Boundary Roleを、組織と環境をつなぐ役割として整理 • discrete knowledgeの移転では、 一人のBoundary Spannerを介し た構造が効率的になり得る • collectively held complex knowledgeでは、 一人を介した構造だけ では不十分 • 異複数人が直接つながる「collective bridge」を提案 専門領域の境界を、誰がどうつないでいるか
23. 今回の動きを考え直す 観点 何を評価したか 今回の経験から見えたこと Generalizing Specialist 個人の越境・Skill Breadth 隣接領域へ越境し、 handoffや専門家待ちを減らした Expertise Coordination Teamによる専門性の活用 必要な専門家は把握・参加させたが、接続先や Contextが自分に 偏った Boundary Spanner 専門領域間の接続方法 単純な確認では有効だったが、複雑な判断でも自分が接続点に なった ここから考えたこと • 境界を越えて動くことは、今回の Deliveryには有効だった • ただし、接続経路や Contextが自分に集まる状態を Teamとして再現可能な状態とは呼べない
24. 自分の成功を再現することと、 チームの成功は違う
25. なにを自分が拾い なにをチームへ返し なにを専門家に委ねるのか
26. 拾う・返す・委ねる • 拾う ◦ 境界にある仕事へ一時的に入る ◦ 必要な人や情報をつなぎ、仕事を前へ進める • 返す ◦ 同じ相談が繰り返し自分に来るなら、Teamへ返す ◦ Contextや判断経緯をTeamに残す ◦ 専門家への接続先を自分だけが持たない • 委ねる ◦ 専門的な判断は、その専門性を持つ人に参加してもらう ◦ 自分は論点整理や接続まで担っても、専門家そのものを代替しない
27. 潤滑油でいいのか？ あなたの専門性はなんですか？
28. 大事なのは、 これから自分がなにを成し遂げたいのか？
29. 私は、 医療業界に革新的な価値を出すプロダクトを作 りたい
30. 自分はそれをどう成し遂げたいのか？
31. 私が目指したい姿/価値を出せる姿 Generalizing Specialist • 一つ以上の専門領域を持ちながら、周辺領域にもスキルを広げる • Software Development全体と、扱うBusiness Domainについても知 識を広げる • Generalistとは異なり、「master of a few」であることを前提とす • 専門職間のhandoffや専門家待ちを減らし、Whole Teamで動きやすく する • (https://agilemodeling.com/essays/generalizingspecialists.html)
32. スクラムにジェネラリストは必要か？ スクラムにジェネラリストは必須ではない 複雑な課題・組織に向き合うためにはジェネラリストが必要 • スクラムガイドからは、ジェネラリストが必須ではないと読める • ジェネラリストにも色々なジャンルがある。個人として、チームとして、境界 としてなど • 複雑な問題になるほど、ジェネラリストの価値が高まると
33. あなたは ジェネラリストですか？ あなたのチームに ジェネラリストは必要ですか？ あなたのゴールに ジェネラリストは必要ですか？ そのゴールには、どんな広さと深さ が必要ですか？
34. We're hiring!
35. 告知: Health Tech Meetup 医療系のテック企業が集まる Meetupがあるよ。 お時間ある方はぜひどう ぞ！！
36. ご静聴ありがとうございました