スクラム開発お悩み相談室
2020/07/26(Sun) CHARITY CONFERENCE OKINAWA × devPM Vol.2 MANAGEMENT
CHARITY CONFERENCE OKINAWA×devPMVol.2 MANAGEMENT2020/07/26 (Sun)YogAgile Engineer 岩村 琢スクラム開発お悩み相談室
View Slide
自己紹介@takusamar いわむー＠ヨガはいいぞ沖縄在住のフリーランスITエンジニアヨガ×アジャイルで健康なチームづくりをサポートしています2019年10月～ KDDI DIGITAL GATEフロントエンド開発（React/Flutter）スクラム、モブプログラミング拠点：東京、大阪、沖縄開発メンバーは在宅リモートワークアジャイルゆいまーるアジャイル開発のコミュニティ「アジャイルゆいまーる」を運営https://agile-yuimar.connpass.com/2Scrum Alliance認定スクラムマスターScrum Inc.認定資格プロダクトオーナー
「軽量、理解が容易、習得は困難」と言われるスクラム。本を読んで理解した気になっても、いざ実践となるとなかなか上手くいかないものです。本セッションではスクラム実践にあたっての悩みにお付き合いします。以下のJamboardに悩みを書き込んでください。https://bit.ly/38aNK8H3スクラム開発お悩み相談室セッション概要と、現場の悩みを募集したところ・・・
4
5受託開発でスクラムを導入するときにどう理解を得るかこれからアジャイルをはじめようという人向けの解説書特にエンジニア以外（PM、営業、役員、…）におすすめ• 目的を明確にする• スクラムの基礎知識を学ぶ• 他社事例から学ぶ• まずは小さく始めてみる最初は問題点が出てきても、スプリントを繰り返して徐々に改善していく様子を肌で感じる。なんのためにアジャイル開発をやるのか、スクラムをやるのか顧客や上司の共通認識を得る。このプロジェクトでスクラムをやるべきという確信を持つ。顧客や上司にもスクラム研修を受けてもらう。最低限スクラムガイドに書かれている内容は理解している。さまざまな会社の成功事例・失敗事例を見て、自分たちのスクラムはどうするかを顧客と一緒に考える。顧客や上司にスクラム導入を理解してもらうには・・・
6そもそも受託開発(請負型)でスクラムするのは向いているのかどうか要件が決まっている（何を作るか明確に決まっていて、交渉の余地がない）案件だとスクラムには向いていない。従来の開発アプローチ「要件は変わらないはず」スコープ予算 納期（固定）（可変）アジャイル開発アプローチ「要件は変化する」予算 納期スコープ予算や納期も固定されていてどうしようもないことも良くあるその場合は品質が犠牲になる品質品質予算・納期に合わせてスコープを調整することで品質を維持する【契約例】• 期間は4週間• Dev3名＋SM1名のチームを提供• POは顧客に担当していただく• 金額は固定（時間精算ではない）• 期間内の仕様変更はいつでも可能受託開発（請負型）でスクラムをやる場合は、期間とリソースを固定して、スコープは調整可能にしておくと良い。
7チームメンバーをスクラム脳にするためのポイントなど新たなマインドセットを身につける方法として最も効果的なのは、上手くいっているスクラムチームに入れること。アジャイルなマインドセットの中で仕事を共にすることで、少しずつ慣れていく。アジャイルはマインドセットである。マインドセット ＝ ものの見方、習慣 人生観、仕事観「こういう生き方をしたい」「こういう働き方をしたい」私はどう在りたいのか、という思いその人がこれまでの人生で積み上げてきたものなので、簡単に差し替えることはできない。（そういうスクラムチームがない場合は、外部からコーチを招いてスクラムチームを育てるところから始めよう）
8スクラムチームの３つのロール（役割）• プロダクトオーナー（PO）開発チームから生み出されるプロダクトの価値の最大化に責任を持つ• 開発チーム（Dev Team）リリース判断可能な「完成」したプロダクトインクリメントを届ける• スクラムマスター（SM）スクラムガイドで定義されたスクラムの促進と支援に責任を持つPOとDevチームのコミュニケーション
9よくあるプロジェクト体制PMの役割• 顧客との交渉、報告• 開発チームへの指示出し• チームメンバーのフォロー：責任が重すぎる。とにかく忙しい。ボトルネックになりがち。スクラムではPMの役割をみんなで分担しよう！開発チームメンバー顧客PM開発チームリーダー
10（顧客）PODev TeamSMこの図を見て、何に気づきますか？スクラムチームの３つのロール（役割）• プロダクトオーナー（PO）• スクラムマスター（SM）• 開発チーム（Dev Team）スクラムのロール（役割）
11（顧客）PODev TeamSMビジネスを知っている人が意思決定に責任を持つリーダーやメンバーといった固定された上下関係はないファシリテーターとしてPOを支援するDev Teamを支援する外部からの指示を受けずにインクリメントを作成する責任と権限を持つ• 顧客との交渉、進捗報告→顧客がPOとなる• 開発チームへの指示出し→Dev Teamが考えて実行する• チームメンバーのフォロー→SMがスクラムチームを支援するスクラムのロール（役割）
12開発チームメンバー顧客PM開発チームリーダー（顧客）PODev TeamSM顧客と開発チームメンバーは遠く離れた存在だったPOとDev Teamは直接対話する（しかもフラットな関係で！）顧客と開発チームの距離の変化
13PO代理がボトルネックになる。Dev Teamが顧客の真の課題に気づけない。SMがPOを支援できない。顧客は元々の仕事で忙しそうだし、あまりスクラムを分かってないのでPOをやるのは難しそう。（顧客）PODev TeamSMPO代理失敗事例（PO代理を立てたパターン）なので、こちらでPO代理を立ててPOとDev Teamとの仲介をしよう。
14（顧客）PODev TeamSMPOとDevチームのコミュニケーション（まとめ）POとDev Teamはいつでも気軽にコミュニケーションできる状態にする。それが仕事のスピードをあげ、無駄な作りすぎを防ぐことができ、良いものを素早くデリバリーできる。
15結局優秀になってくるとスクラムだろうがなかろうがデリバリーできるある経営幹部のつぶやきこれは完全に同意。すごく腕のいいエンジニアを揃えれば、良いものを素早くデリバリーできる。では、なぜスクラムというプロセスを採用するのか？
16これは完全に同意。すごく腕のいいエンジニアを揃えれば、良いものを素早くデリバリーできる。では、なぜスクラムというプロセスを採用するのか？結局優秀になってくるとスクラムだろうがなかろうがデリバリーできるスクラムを導入する私の理由結局、優秀でなければスクラムだろうがなかろうがデリバリーできない優秀なエンジニアを揃えるのは大変（希少価値、人件費が高い、…）→エンジニアを育てる仕組みとして、スクラムは優れている。優秀なエンジニアがいなくなるリスク（休暇、退職、…）→スクラムというプロセスでチームとしての生産性を担保する。
17プロダクトオーナーを目指す人へ【翻訳】プロダクトオーナーになりたい人が知っておくとよいことhttps://www.ryuzee.com/contents/blog/14509• 毎日たくさんの人と話すのは楽しいですか？• 頻繁に衝突が起こる覚悟ができていますか？• 会議をリードするのを楽しんでいますか？• 喋るよりも多く人の話を聞いていますか？• 交渉は得意ですか？• いつでも意思決定する準備ができていますか？プロダクトオーナーとして成功するための特性
ご清聴ありがとうございました今日お会いした皆様が身も心も健康で過ごせますように18
takusamar
t2auto
feosnowcharadecon
progmat
toyotasystems_career_pitch
mvrecruit
cr
recruitengineers
copilot
andreitit
socialmatch
mihofujita
erikaheidi
addyosmani
kneath
panda_program
scottboms
aarron
mongodb
ddemaree
samanthasiow
frogandcode
keavy
mojombo