世の中でアジャイル開発が一般的になるにつれて、アジャイル開発を支援する「アジャイルコーチ」という職種や肩書を見かけることが多くなってきました。
アジャイルコーチとは組織がアジャイルなやり方で成果を出せるようにするために、組織的な観点、技術的な観点、プロダクトの観点などさまざまな観点から支援する役目です。
アジャイル開発に慣れていないチームには、アジャイルコーチは必要な存在だと言ってよいでしょう。

一方で、アジャイルコーチといえば、「めんどくさい」「マサカリ投げる」「上がった感」「単価が高い」「実際の効果がよくわからない」といったイメージがあります。
これらはコンサルティングを始めとした支援系の仕事に対する共通のイメージでもありますが、銀の弾丸思考の表れでもあります（アジャイルコーチがあなたの問題をすべて指摘し、魔法のように解決してくれるわけではなく、あくまで主体はスクラムチームです）。

本セッションでは、アジャイルコーチとは何なのか、実際にアジャイルコーチをどう活用すれば良いのかを、日本で唯一のScrum Alliance Certified Team Coach(CTC)で実際にアジャイルコーチングを有償サービスとして提供している現役アジャイルコーチが解説します。

スクラムショーワークショップは、スクラムの説明をショー（寸劇）形式で行うワークショップです。
このワークショップを通じて、参加者はスクラムの基本を体験・学習できます。

スクラムショーワークショップは、yycr2019（アジャイルコーチとスクラムマスターの宴、通称：よなよなコーチングリトリート）で
生み出されたワークショップです。「短い時間でアジャイルを知るようにしてほしい」というニーズに応えるために、最大2時間でアジャイル・スクラムの理解を高められるワークショップをみんなで作りました。
会社の中で展開するために、できるだけ準備が少なく済ませたいという要望にも応えています。

皆さんも、スクラムショーワークショップを実施してみましょう！

紹介動画はこちらから！

詳細はこちらの記事をご参照ください。

サイボウズの事業がオンプレミスからクラウドに移行する中、開発スタイルはウォーターフォールでの指揮統制・分業型からスクラムでの自己組織化・機能横断型に変わりつつあります。そんな状況の中、チームがユーザーにより価値を届けやすくするために職能別部署は解体されチーム主体の新組織になりました。

新組織の狙いは以下の4つです。

• 職能単位での部分最適化ではなく、チーム全体で最適化しやすく
• 従来の職能の枠にとらわれず、個人の多様なスキル・個性を活かしてプロダクトやチームに貢献できるように
• チームに必要なことはチームで意思決定できるように、権限と責任をチームに委譲
• 主体的にキャリアを作れるように異動をカジュアルに

組織変更の中で部長の役割は分割され再割当てされました。採用・予算などはチームに移り、異動は各メンバーに移り、給与評価はそれを受け持つ組織運営チームが新設されました。

組織変更をして8ヶ月、様々な変化が起きました。
どうやって意思決定するか議論するチーム。
どんな人を採用したいか、そもそも人を増やすべきなのかを議論するチーム。
上長がいなくなり色んな人と1on1し始めるメンバー。
活発になる他職能/他チームへのお試し異動。
チーム内でオープンに議論されるようになった問題。

このセッションでは部長がいなくなった組織で起こったことを紹介します。

現在，大学でプログラミング言語の授業を持っています．

その授業では，文法としてのプログラミングだけでなく，プログラミングの面白さを知ってもらえるもらえるように，モブプログラミングを導入して授業を行なっています．

ところが，企業でのモブプログラミングの導入とはまた違った課題がありました．そして，その解決策として，行動分析学を元にして，試行錯誤をしています．

本セッションでは，その試行錯誤の課程を共有したいと思っています．

----

I have a C programing course at university.

I introduced Mob Programing technique to my class so that my student learn not only the grammar of the programing language but also the fun of programing.

I have an experience to introduce Mob Programing to the work in our company. However I faced different problems. And Now I am trying to solve the problem using Behavior Analysis.

I will share this experiences in my session.

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

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

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

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

僕が考えるスクラムマスターが目指すその先

プロジェクトにおいて、プロダクトマネジメントにおいて、スクラムマスターとしての役割を実践してきました。
この知識やマインドや実践知は、製品づくりだけに留まらせる必要はありません。
チーム、部署へとスケールさせ、会社組織全体を対象にできるのです。

また、自社だけに留まらず、複業にて他の会社を支援してきました。
ソフトウェア開発の現場だけではなく、バックオフィス系、営業系、エグゼクティブチームなど、あらゆるところで活用できるのです。

スクラムマスターのノウハウを活用して、会社という組織を活性化させることを目指してみませんか？
僕が考えるスクラムマスター業の一つの解をご提供します。
もしかしたらスクラムマスターとしての「あり方」や「生き方」なのかもしれません。

日本の典型的な製造業で、スクラムで社内向けアプリ開発を始めて約１年。
ソフトウェア開発をしたことのない部門が、失敗を繰り返しながら動くをソフトを作り、ユーザーに価値を提供出来るようになってきました。

スクラムによって生まれたのは品質の高いアプリだけではありません。セクショナリズムが強い大企業の中で、部門を越えた関係者が一つのチームとして動くことによって仲間が増え、コラボレーションが生まれ、想定していなかった所でも新たな価値が生まれつつあります。

組織風土の変化の話に加えて、開発チームの具体的改善事例やインフラ構築の取り組み、メトリクスの推移なども共有します。

参考に7月にDASAで発表した際の資料をシェアします：

https://speakerdeck.com/yasuhiro_funato/minnagashou-huo-wode-rareru-aziyairukai-fa

スクラムチームは、ホントのイノベーティブなプロダクトを作れますか？

近年、「デザイン思考」という言葉の使用が増加しており、ソフトウェア設計が戦略設計やサービス設計に取り入れられるようになるにつれ、良い設計の敵はスクラムか、という議論が多くなっています。スクラムと設計はどのようにシームレスに連携するのでしょうか?

６年でデザイン会社に働いて、スクラムとアジャイルの世界に入った時にデザインのリサーチャーから見ると、会話の中で何かが欠けているように感じられます。スクラムとアジャイル組織が単に「デザインに優しい」になるのではなく、エンジニアとデザイナが協力して構築した新しい世界を作るために、私たちはDAIKONというフレームワークを作成しました。DAIKONは、「ダイバージェンスとコンバージェンス」という「拡散・収束」のことから来ます。イノベーティブなプロダクトを作るために、デザインかスクラムだけではなくて、両方の力が必要と思います。

今回の講演ではスクラムとデザイン思考の歴史,最新の視点、そして現在クライアントとテスト中のDAIKONフレームワークについて議論します。私たちのチームが学んだことを話して、DAIKONフレームワークのテスト方法を教えます。

このトークは日本語になります。

AgileやScrumを問わず、組織やチームで仕事を進めていく上ためにはゴールの共通認識は重要な要素となります。
一方で、ビジネスの現場では企画部門や開発部門、営業部門、品質管理部門など様々な立場の人が関わるため共通のゴールを設定することは容易ではありません。
その結果、Scrumチームが目標を見失ってしまい、本来集中するべき価値に集中できていない場面を見かけることがあります。

このセッションでは立場の異なるステークホルダーが多数存在するプロジェクトにおいて、共通のゴールを合意するためのSuccessFactorsワークショップをご紹介します。

さらに、このワークショップの価値を最大限に高めるためのポイントを事例を交えてお伝えします。

yamoryってなに？

株式会社BizReachから8月27日にリリースされたサイバーセキュリティ事業とそのサービスで、開発中のプロジェクトで利用しているOSSの脆弱性検知やその管理を行うことでセキュリティリスクや対応コストを削減できます。

https://yamory.io/

開発フローの中にセキュリティを組み込んでいく、DevSecOpsを実現するための一つの選択肢として、開発中にOSS脆弱性に気づき、イテレーションの中でこれらを解消出来ることによって、

• 「安心してテクノロジーを活用出来る世界」
• 「すべてのエンジニアによってセキュリティを当たり前にする」

そんな世界観を目指しているプロダクトです。

セッションの概要

　そんなプロダクトを開発するために、2月頃に結成したスクラムチームについてです。結成は昨年はじめ頃でしたが、人数が増えるにつれて、作りたい機能が複雑化していくにつれて、どう管理していくかが課題でした。

　プロダクトの特性としては

• 「どのOSSにどんな脆弱性があるのか」というデータベース
• その脆弱性がどの程度危険なのか判断（トリアージ）するロジック
• お客様のプロダクトにどのようなOSSが含まれているのか解析するためのコアロジック
• これらを突合して「あなたのプロダクトにはこんな脆弱性があるよ」と通知するロジック

などなど、技術的に非常に複雑な構造をバックエンドに抱えています。

　新規事業結成直後なので所属するメンバーは各分野のスペシャリストばかりで、癖の強いエンジニアたちをなんとか纏めながら、上記のような複雑な機能を如何に安定して開発するか。事業のトップが選んだ手法がスクラムでした。

　それ以降、不定期に飛び込んでくる上記のような大型案件を上手く処理できずに大きな躓き（Velocityがでない！）を経験したり、短期間での異動・採用の成功によってエンジニアが激増し、規模の拡大によってLeSSを本気で考えざるを得ないほどになりました。

　チーム結成の経緯、フェーズごとにぶつかったいくつもの問題。それらにどう立ち向かったかをお話するとともに、チームがぶち当たっている現状の問題や、それらの解決に向けた取り組み、スクラムマスター見習いとしてチームを観察しながら感じたこと、マネージャーとしてチームメンバーの成長と向き合う中での葛藤など、ざっくばらんにお話します。

目を閉じて思い浮かべてみてください。

あなたには、「意見が合わない」「考え方が理解できない」「思い出すだけで腹が立つ！」「できることなら話したくない！」

そんな「あいつ」はいませんか？

プライベートであれば、その「あいつ」から、そっと離れればよいですが、取引先の担当や上司、隣の席の人がそうだったりすると簡単に離れる訳にはいかないでしょう。

そんな時、わたしたちは毎日、息苦しい思いをして仕事を続けないといけないのでしょうか。

居心地の悪いこの場所を離れる決意をし、転職したほうが良いのでしょうか。

「あいつ」はいつか、考え方を変えてくれるのでしょうか？

わたしたちが大事にしているスクラムやアジャイルの「価値観」は、世の中的にはまだ当たり前の「価値観」ではありません。
（みなさんはそれをもうすでに知っているか経験をしていると思います）

RSGTはとても居心地のいい場所です。でも一歩、RSGTから離れたらどうでしょうか。
越境しようとする境界にいる人ほど「価値観」との衝突は避けることができないのではないでしょうか。

このプロポーザルでは、そんな時に私たちはどういう選択肢があるのかを皆さんとともに考えてみたいと思います。
(RSGTにとっても皆さんにとっても有意義な時間となるよう努めます)

発表は、いつもつらい感じの発表をしている開原さんと、そんな人を支援するダイアログファシリテーターの高柳さんでお届けします。

■発表の流れ

1.「社内のあいつら」開原ライトニングトーク(5 min)

「ルール１：クソ野郎には近づくな」

昔読んだ、エンジニア向けの本の「ルール１」にはそう書かれていました。
私は教えを守りクソ野郎とはなるべく距離をとって生きてきたつもりでした。
そのおかげか、たくさんの良い出会いがあり、人にも恵まれてきたと思います。
それでも自分にとってしんどい出会いはあります。

「あいつら」です。

わたしが「あいつら」とは少し考え方が違うということは、「あいつら」は知っています。
そして私も、「あいつら」のことを少し知っています。

できることなら、同じ目標に向かって活動したい。
でも、私は「あいつら」とわかりえることができるのでしょうか。
「あいつら」が「わたしたち」にすることができるのでしょうか。

「クソ野郎に近づくな」は正しいことだったのでしょうか。

この数年間、考えてきたことをお話ししたいと思います。

2.「社外のあいつら」高柳ライトニングトーク(5 min)

　企業内の研修依頼の多くは、何かしらのスキルが不足していて、もしくは課題になっていて、それを補う、解決するための研修になります。その場合の受講者は「自分にそれがないから受けてこいということか？」とか「今までのやり方は間違っているから、新しいやり方に変えろということか？」という自身を否定されたような状態で参加しているので、研修を「学びの場」として受け取るのではなく「研修内容を批判する場」として挑んで…というか、お手並み拝見とばかりにわかり合おうとしない状況が発生します。

そんな分かり合えないことから始まる研修で、私がどのような向き合い方、選択をしてきたかをお話させてもらいます。

3.「あいつらとの選択肢」について対話 By 高柳のファシリテート(10min)

ホワイトボードではなく、iPadを使ってリアルタイムに書き取り、それをプロジェクターに投影しながら、2人の対話を、つなげたり、解いたり、遠ざかったりしながらお互いのライトニングトークから得た情報・状況で語り合います。

そもそもの思い

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

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

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

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

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

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

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

登壇者

市谷 聡啓

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

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

石井 智康

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

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

もう１名調整中

進行役：岩切 晃子

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

サイボウズの人事部採用チームは、
採用計画の立案から面接の実施、合否連絡、内定者のフォロー、イベントの出展、説明会の実施といった業務を日々行っています。
採用チームに異動してきて2年目の始めに、リーダーを引き継ぐことになりました。
これまで経験豊富なリーダー中心に業務を進めてきた状態だったので、経験の浅い自分がリーダーになることに不安を感じていました。
自分個人がエースの抜けた穴を埋めるのではなく、チームの皆でカバーできるような進め方をしたいと悩んでいたところ、
開発チームで導入が進んでいたスクラムが目に止まりました。
スクラムが人事の業務改善にも役立つと感じ、導入を決意し、2年ほどスクラムをベースにした業務改善を進めてきました。
プランニングやふりかえりで地道な改善を重ねた結果、モブ作業やカンバンを活用が進み、メンバーの残業が減り、チームのベロシティも向上しました。
現在はチームでタスクがコントロールでき、理想のチームに向かう良い状態が作れています。

改善の過程で起きた問題やそこから学んだこと、チームに起きた変化を紹介したいと思います。

チームメンバー同士の会話や1to1でのコミュニケーションをより有効的でより安全にしたい方大集合！

スタンスカードを使ってロールプレイをしながらコミュニケーションについて考えよう！

LAPRAS株式会社では全社的にHolacracy(ホラクラシー)というティール組織の1つである組織体系を導入しています。一方でホラクラシー導入前から開発チームではスクラムで開発を進めており、ホラクラシー導入の2018年4月から2つのフレームワークの共存にチャレンジしてきました。

ホラクラシーの思想は個々人が役割(ロール)を持って責任範囲を明確にし、各人が自身で優先順位を決めて主体的に動いていくものである一方、スクラムは属人化を排除してだれでもどの役割を担えるようになる状態を理想としており、開発の優先順位決定もプロダクトオーナーが役割を持っています。根本的に異なる思想を持っているように見える2つのフレームワークが同居できるのか、実際に運用してみてわかったことをお伝えします。

スクラムでプロジェクトを進めて行く時に「ファシリテーション」という言葉は割と普通に出てくると思います。そしてスクラムで実際に「ファシリテーションをする」時になると、スクラムマスターとして見ている視点とファシリテーターとして見ている視点は少し違うのかもしれないと思うことがあります。ファシリテーターとしての役割と、スクラムマスターの役割と「帽子を被り直す」という感じで使い分けるということを考えていらっしゃる方もいると思います。

今回のワークショップでは、スクラムイベントでのファシリテーションというポイントもありますが、その前にそもそもファシリテーションがスクラムの文脈では何をすることなのか、ファシリテーターとしての視点、捉え方が何を指すのか、改めて自分自身の引き出しに「ファシリテーション」のラベルのついた棚を明示的に増やしてみませんか？

みなさんは、新規事業に取り組んだ際、プロダクトに価値があることを感じつつも、そもそもリリースできなかったことはありませんか？

私は、過去いくつかの新規事業に取り組んできました。無事にリリースできたプロダクトもあれば、世に出ることなくお蔵入りしたプロダクトもあります。
また、関わった立場は、開発者、スクラムマスター、テクニカルサポートなど様々です。

新規事業は、プロダクトオーナーが、仮説検証をおこない、価値がありそうなことを感じたとしても、世の中にリリースすることすら難しい場合があると、今までの経験から感じています。

プロダクトオーナーが考えるべきことは、スクラムガイドに記載されているような「プロダクトがユーザーに価値があること」以外にも数多くあります。
プロダクトを会社からリリースするには、営業、サポート、製造、出荷、総務など、様々な部門との連携が必要です。
ユーザーがプロダクトを購入するには、営業部門がプロダクトの価値を理解し、販売網を作り上げる必要があります。また、プロダクト購入時の利用規約は法務部門が内容を精査する必要があります。
ユーザーがプロダクトを利用する際に困った場合、QA対応ができるサポートセンターを構築する必要があります。
ユーザーが利用するプロダクトが、ソフトウェアを通して販売される場合（ECサイトなど）は、プロダクトの製造や出荷が必要で、ソフトウェアを提供するより長いリードタイムや事前準備が必要です。

加えて、製造、販売ルートによっては、社外との関係性も非常に重要です。
製造が社外の工場の場合、アジリティを高めるために小ロット生産をしたいですが、万単位のロット数を最低発注する必要があったりします。
既存の販売網を代理店を通して活用する場合は、代理店の営業部門にプロダクトの価値を理解してもらう時間が必要ですし、仕切りといった価格調整が利益を残すために大事な要素になります。

上記はあくまで例ですが、プロダクトをリリースするためには、ソフトウェアを作り上げる以外にもやるべきことが数多くあります。

本セッションでは、様々な立場で、様々なプロダクトオーナーのもと新規事業に関わったエンジニアとして、私の過去の成功事例、失敗事例を踏まえながら、新規事業においてプロダクトオーナーが考える必要があることを紹介します。

2019年4月にDevLove関西で発表した「トラブルだらけの現場から仕事が「楽しい」現場に変わった、6か月間の話」（https://www.slideshare.net/cowappa/ss-141300729）のその後の話です。

業務改革を行ったチームがその後どうなったのか報告します！