現場コーチとしてScrumでサービス開発しているチームの支援をしていると、よくディスカッションする話題の1つが「プロダクトバックログアイテム(PBI)の価値や成果をどう考えて、どのように扱うか？」というものです。

このような話題の時、OutputとOutcomeの話をします。

• Outputとは、リリースした機能の数や質のことをここではいいます。
• Outcomeとは、利用者がどう変わったのか？利用者の課題が解決したのか？と利用者視点での効果のようなことをいいます。
  
  • ※Outcomeはビジネス視点からのOutcomeと、利用者視点からのOutcomeの2つに分類されます。上記は利用者視点からのOutcomeのことを書いています。
    
    

たくさんのPBIをつくって頻繁にリリースしてOutputが増えたとしても、自分達にとっての価値、もしくは利用者にとっての価値(利便さや嬉しさ)といったOutcomeが増えていないとそのプロダクトやサービスを続けていくことはできません。

1つずつのPBIの情報に"売上の増える額"や"ユーザー数の増加”を加えているチームもあります。
また別の現場ではストーリーポイントと同じようなやり方で、仮想の単位を決めて相対的な値をチームで話し合って、どれからやるか？の参考にしています。

このセッションでは、"プロダクトバックログアイテムにおける価値の取り扱いのやり方”のいくつかの現場の事例を紹介しつつ、Outcomeについて考えをお話します。
みなさんのPBIのOutcomeがよりわかりやすく、より高くなるヒントになればと思います。

スクラムチームにテックリード？

「スクラムのロールには定義されていないけど、こういうのは誰がやるのが良いんだろう？」「そもそも、そんな状況ってことは、まだスクラムをやるための準備が整ってないってことなのかな？」って悩むことありませんか？僕はありました。

スクラムに取り組んだ最初のころは「あれー？ここどうしようかな？とりあえず・・・自分でやっとくかな」と思うことが結構ありました。「これでいいのかなぁ？」と不安に思いながらやってましたが、それも5,6年たった今では「あー、うちの組織だと、こういう役割が必要なんだわ。こそこそやらずに、自分の中でテックリードって名前つけて堂々とやっとく方が良さそうだな」って納得してやってます。

スクラムガイドの中には、テックリードというロールは定義されていません。でも僕は、今の組織の中で、このロールがとても大切な役割を果たしているなぁと感じています。大変だけど、やりがいがあって、とても面白いロールです。

こんにちは。椎葉です。楽天株式会社の大阪支社で自社ECサービスのアプリケーションアーキテクトとして仕事をしています。僕が所属している組織では、多くのチームがスクラムを採用しています。その中で、この数年間、僕は改善エンジニアとして「色々なチームに入っていって現場のみんなと一緒に内側から組織の改善をする」という活動をしてきました。その活動の中で学んだのが、テックリードというロールの大切さです。

僕の中のテックリードは、スクラムチームと組織のあいだに立って、技術的な視点に軸足を置きながら、開発やチームや組織を支える。そういう役割です。何かと何かの間におちてしまいそうなものに手をのばして拾い上げたりします：プロダクトオーナーと開発チームのあいだ、開発チームとスクラムマスターのあいだ、スクラムチームと組織のあいだ、そしてマネージャーとスクラムチームのあいだ。など。　

このセッションで伝えたいこと

「僕の組織では、スクラムからは少し外れるかもしれないけど、こういうことをやる必要があって、僕はテックリードとしてこういうことをやってるよ」ということをお伝えしたいと思います。

それによって、これからスクラムに取り組もうとしていたり、既にスクラムを実践しているけど悩んでたりする方々に対して「あぁ、自分も同じようなことで、もやっとしていたけど、そういう風にやってる人もいるんだな」って何かしら参考になるようなセッションにしたいなと思っています。

また、その中で学んだ「テックリードとして考えておくと良いこと」もお伝えします。

今、テックリードとして悩んでいる方や、これからテックリードとしてチームをリードしていく方々に勇気を伝えられるようなセッションにしたいと思います。

突然ですが、スクラムマスターのキャリア設計って難しいと思いませんか？
アジャイル開発が普及するにつれてスクラムを導入するチームも増えている一方で、まだまだスクラムマスターというロールは一般的ではなく、多くのスクラムマスターは元々の役割と兼務しています。スクラムマスターとして価値を高め、今後キャリアを伸ばしていくためにはどうしたら良いでしょうか。

現在私は週3日サイボウズで正社員として働きながら、週2日は個人事業主として社外のチームをお手伝いするというちょっと変わった働き方（複業）をしています。
このセッションでは、エンジニアからスクラムマスターになり、アジャイルコーチとして複数チーム・組織を支援する立場になった事例を紹介したいと思います。スクラムマスターのキャリアの選択肢のひとつとして参考になれば嬉しいです。

3年間スクラム開発を実践するチームでデザイナーをやってきた経験をもとに、デザイナーがスクラム開発の中でどのようにチームに関わって、そして力を発揮するのかについてお話しします。

エンジニアやプロダクトオーナーと行ったロールと比較して、デザイナーというロールがどのようにスクラム開発に関わって行くべきかについてはあまり多くの知見がありません。
スクラム開発に関わるデザイナーは少なくない（はず）と思うのですが、各自手探りでやっているのが現状です。
自分も試行錯誤を続ける日々ですが、自身が学んだ知見を多少なりともオープンにすることで、デザイナーというロールにおいてもスクラム開発に対する知見が高まり、チームにより良い貢献ができるようになると嬉しいです。

そもそもの思い

RSGTの参加者が年々増えていることからわかるように、この間、スクラムに舵を切る開発現場が急増しています。

波に乗って私も、スクラム的プロダクト開発手法を学ぼうと、2019年3月に、認定プロダクトマネージャー研修を受講しましたが、POの役割が広すぎて、定義していないのと同じだと感じました。また、プロダクトオーナー向けのドキュメントが具体的ではなく、事業サイドの方が、赤いピルを飲むために、手がかりがほとんどないように感じました。

このギャップの前に、経営者はどんな手をとっているのか？というのが、このセッションを考えるきっかけでした。

日本の経営方針は「ヒト」「モノ」「カネ」、アジャイルは「文化」が第1義。

ナイスな開発チーム、プロダクトオーナーが自然と出てくる会社の文化をどう作っていったら良いのか、スクラムチームやアジャイル開発チームを抱える会社の経営方針は、どうきめるのかなど、本や研修には出てこない話を、デベロッパーから経営者になった方々に、この場でお話しいただき、彼らがヒリヒリした日常から何を気づき判断していったのか、お話を引き出せたらと思ってます。

45分1本勝負。ぜひ、チャンスをいただけるとうれしいです。

また、この場で聴いてみたいことなどあれば、コメントいただけるとうれしいです！

登壇者

市谷 聡啓

ギルドワークス株式会社 代表取締役／株式会社エナジャイル 代表取締役／DevLOVEコミュニティ ファウンダー

サービスや事業についてのアイデア段階の構想から、コンセプトを練り上げていく仮説検証とアジャイル開発の運営について経験が厚い。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、ギルドワークスを立ち上げる。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。訳書に『リーン開発の現場』（共訳、オーム社）、著書に「カイゼン・ジャーニー」「正しいものを正しくつくる」がある。

石井 智康

石井食品株式会社 代表取締役社長執行役員

ソフトウェアエンジニアとして、コンサルティング会社にて大企業の基幹システムの構築やデジタルマーケティング支援に従事。2014 年よりフリーランスとして、アジャイル型受託開発を実践し、ベンチャー企業を中心に新規事業のソフトウェア開発及びチームづくりを行う。2017 年から祖父の創立した石井食品株式会社に参画。地域と旬をテーマに農家と連携した食品づくりを進めている。現在のライフスタイルに合った「豊かな食」のあり方を模索中。認定スクラムプロフェッショナル。アジャイルひよこクラブ幹事。

もう１名調整中

進行役：岩切 晃子

株式会社翔泳社取締役 / コンピュータ出版販売研究機構会長

アジャイル札幌では大人気コンテンツ『紙粘土スクラム』のワークを複数回実施しています。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
紙粘土スクラムワークショップ
あるビジョンの動物園をスクラムに則ってチームで作っていきます。
プロダクトバックログを作り、スプリント計画、実装、
スプリントレビュー、スプリントレトロスペクティブを実施します。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

参加者は童心に返り、紙粘土をコネコネしながら軽い気持ちでワークを始めますが、実はこのワーク！現場の状況がスケスケ見えるんです！

このセッションでは紙粘土スクラムのワークを観察者として見たときに発見したアンチパターンとその解決策を時間の限り紹介します。

・顧客が近くにいるのに全く話を聞かず、自ら難しい仕様をドンドン考え出すエンジニア！
・プロダクトオーナーが品質にこだわり過ぎてチームにガミガミ。モチベーションも下がり、成果がでないチーム！
・概念は分かっているけど、オロオロして『チームの障害』を止められないスクラムマスター！

これはホンの一例ですが、ワークで出てきたアンチパターンは皆さんの現場でも間違いなく役に立ちます。

たかが紙粘土、されど紙粘土。
紙粘土から得た知見をあなたの現場に活かしてクレイ！

あなたはどんなプロダクトオーナーでいたいですか？

スクラムで定義されている役割の一つであるプロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持ちますが、組織・スクラムチーム・個人によって、その方法はさまざまです。

本セッションでは、これまでの数年間で出てきた日本企業での失敗事例から、企業でアジャイル開発に取り組む際の典型的なアンチパターンを紹介します。その上で、原因となる落とし穴と、本来のあるべき姿を明らかにし、チームやビジネスから見離されないためにどうしたらよいかを考えます。