早く行きたければ、ひとりで行け。
遠くまで行きたければ、みんなで行け。

プロダクトをちゃんと作り、育てていくために必要なものは何でしょうか？
ビジョンや現実的なロードマップ、MVPや顧客仮設の検証はもちろんとして、プロダクトチームを育てていく必要があるんじゃないかと思います。
近くに行きたいなら一人で行け、遠くまで行きたいなら、みんなで行け。

チームを維持するためには、政治も必要、カネも必要、ユーザーはもっと必要。
プロダクトオーナーやリーンスタートアップの本を読んでも、なかなか教えてもらえないのが「日本企業におけるカネと政治」。
エンジニア出身の方も、マーケティング出身の方も、プロダクトデザインやUXの方も、等しく苦労するポイントであろうと思います。

プロダクト開発はうまくできても、それ以外のところで泥沼にハマってしまいがちな皆様に、うまくサヴァイヴして人生をときめくためのヒントをお伝えできればと考えております。そのために、実際に大企業で新規ビジネス開発の仕組みづくりに携わるみなさんから、戦略やヒントやマサカリをいただきます。もしかしたらちょっと心に棘が刺さるかもしれませんので、しっかりと心のご準備をお願いいたします。

発表者は、黒田樹さん(リクルートテクノロジーズ)、絹川達也さん(楽天)、横道稔さん(LINE)。いずれもご本人が新規サービス/事業を手掛けるだけでなく、仕組みづくりや組織づくり、メンタリングなども携わられてきたみなさまです。

The presentation will be given in Japanese. I've uploaded the (partially) translated version of my slides at https://www2.slideshare.net/makotoiguchi/how-to-balance-between-security-and-agile-development for your reference.

2018年12月頃に掲載された「アジャイル手法でのセキュリティは困難」というタイトルの記事において、某セキュリティ会社のCTOは「高速のCI/CD（継続的なインテグレーション／デリバリー）においてセキュリティ上の問題が浮上しても、その解決に当たる余裕や時間がないままに事態が進行してしまうようなことが往々にしてあり、現場が混乱する」とした上で、結果として「DevSecOps、NetSecOpsが、現実にはうまく機能しない」という見解を示しました。

これは本当なのでしょうか？
もし本当だとしたら、それは悲しいことなのではないでしょうか？

一方、2019年8月に掲載された "Your security team is probably an infuriating obstacle - but it doesn't have to be this way" という記事においても触れられているように、開発者側より「セキュリティは、DevOpsやアジャイルな開発スタイルにブレーキをかける存在である」といった声を聞くことがよくあります。

これは正しい姿なのでしょか？
セキュリティとアジャイル開発は、水と油の関係なのでしょうか？

このセッションでは、ISMS内部監査責任者とスクラムマスターを兼任している立場の人間から見た、セキュリティとアジャイル開発の「あるべき姿」についてお話します。また、現在行っているセキュアなアジャイル開発の実現へ向けた実験（The Elevation of Privilege: Threat Modeling Card Deck を活用したセキュリティ問題の洗い出しとプラニング）をご紹介します。

参考）The Elevation of Privilege: Threat Modeling Card Deck を日本語化＆いらすとや化したもの。こちらの Github レポジトリで公開中です。

私たちLINEのSETチームは、プロダクト開発チームのプロセス改善と生産性向上を実現・推進するため、多くの社内ツール・サービス・プラットフォームを提案・開発・運用しています。

その経験で私たちは、技術的に優れた最先端のモノを提供し続けるだけでは不足で、ユーザの真のニーズの発見とその実装、施策を続けるための意思決定者からの支持の取り付け、社内でのプロモーション活動といった、プロダクトマネジメントの要素が必要不可欠であるとの認識に至りました。

一方で、ThoughtWorks社の"Technology Radar"などによると、プロダクトマネジメントの知見・方法論を社内ツール・サービス・プラットフォームへ適用する傾向が世界的に広まりつつある一方で、そのための知見がまだまだ不足していることも分かりました。

そこで当セッションでは、特に社内ツール・サービス・プラットフォームにおける、プロダクトマネジメントの適用の勘所・Tips・パターン・アンチパターンについて、私たちの現場での実践例を元に、参加者の皆さまが活用できる知見として紹介します。

10年前から5年前まで、アジャイルコーチとして2,000人以上の開発組織を抱える企業のアジャイルトランスフォーメーションに挑戦していました。
現在はその立場を離れ、事業会社のVPoEとして開発組織の運営をしています。

アジャイルコーチとVPoE、両方の経験からチームを見る視点にどのような違いがあるのか、アジャイルコーチの先にどのようなキャリアがあるのか、個人的な経験を交えながらお話します。

RSGT2020 Closing Keynote「NEXT→ACTION」の後日談でもあります。

ふりかえり／スプリントレトロスペクティブで、みなさんはどんな手法を使っていますか？

「KPT・YWT・Fun/Done/Learn あたりは試してみたものの、他の手法は知らない」という人も多いはず。

色々な手法を試してみると、「あぁ、ふりかえりってこういうものなのね」とあらためて見えてくるものがあるんです。

だから、色んな手法を試してみてほしい！楽しんでほしい！

そんな想いで、このセッションを実施します。

このセッションでは、トコトンHowを追求します。

目的の話は一切しません（目的の話は関連リンクをご参照ください）。

とにかく色んな手法を、手法の進め方、実施イメージ、ポイントなどに絞ってお話します。

1手法1分～2分くらいで、とにかくたくさん、面白い手法を話します。

メジャーなものからマイナーなものまで、色々話したいと思います。

きっと、「あ！これ楽しそう！私もやってみよう！」という手法が見つかるはずです。

話せるとよいなと考えている手法

• DPA
• 3Dots
• 連想ゲーム
• Timeline
• Story of a Story
• 象、死んだ魚、嘔吐
• 斜に構える／構えないを切り替える
• Starfish / Small Starfish
• Following up on Action Items
• Celebration Grid
• 質問の輪
• Sailboat / 熱気球 / スピードカー / ロケット
• ORID
• 4Ls
• Repeat / Avoid
• Effort & Pain
• SMART Goals
• 360度感謝
• Hapiness Door

このセッションは、参加者との双方向で作り上げていきます。

KANEが参加者からのコメントを拾い、森が解説する。

気になる手法を、この場で明らかにし、楽しいふりかえりを作り上げていきましょう！

• コーチやSMは特に横の繋がりをうまく作らないと知識の幅や、学習の幅が狭まりませんか？また悩み事やこんな時にどうしたらいいの？みたいな具体的な話も、オープンな相談会ではしにくいことがあると思います。
• 一方で、勉強会などのイベントだと自分の興味範囲を必ずしも話題にできるとは限らず、その時々の状況に応じたトピックを話す場合が多いのではないでしょうか？
• そんな人たちに、このゆるい1on1を提案し、ゆるい紐帯(つながり)だからこその新しい気付きやアイディアの源泉となっている事例をご紹介します。
• この考え方はふりかえりやチーム内での対話にも有効です。

「ボトムアップでのアジャイルチームづくりは、どうしたらよいか？」
「アジャイルチームを作ったものの、なかなかその先に進まない」
「顧客要望やトップダウン指示で、アジャイルチームを早急に作り成果を求められているが何から始めたらよいか、わからない」
こうしたご質問を数多くいただくようになりました。日本企業の経営層から開発エンジニアまで、みんな悩んでいるみたいです。

みなさんご存じの通り、アジャイルにおけるマネジメントの基礎は、チームにあります。チームがなければ、ベロシティも測れないし、見積もりもできないし、デリバリーできません。しかし、いまだに、作るものが決まって、予算が取れてから人をかき集めるプロジェクトが後を絶ちません。どうやって調達・開発するのかが決まっていないのに、なぜか金額や期間は決まってしまう。

まあ日本人、子供のころからチームチーム刷り込まれてますし、集まれば仲良くやることには長けてます。なんとかしますよ。大人ですし。

「うちの会社にいる人間はまじめな奴が多いから、
　チームというのは勝手に集まればできるもので、
　まあ、よいチームを作るためにワークショップでもして、親睦を深めたらいい」
....などと、簡単に思っているマネージャーも結構多いのではないかと思います。

ち・がーーーーーーう。

そんな風にしたって、簡単にはうまくいかないこと、みんな体験してますよね？
小学校の掃除の班でケンカが絶えない。遠足のグループ活動が楽しくない。
あいつの言うことが納得できない。一人でやった方が仕事が早い。
特定の人が仕事のほとんどを背負って周りは動けてない。
うまくできない人がいるけど十分に教える余裕がない。

私たちのチーム作りは失敗の連続。
でも仕方ない。人間関係って難しいから。
私一人が我慢すればよいのだ。
...いつもそうやって、うまくいかないことに蓋をして、めんどくさいことを先送りしようとします。

じゃあ、どうやってチームを作るのか？
本セッションでは、ここに答えていこうと思います。

大企業から中小企業まで経験を持つ、アジャイルコーチ三人衆が、それぞれの経験から話をしていきます。
チーム作りの各段階で、どんなことを考えながら作っていくのか、参考になる話もならない話もあると思いますが、
参考になるところだけ持って帰っていただければと思います。

チーム作りのプロセス

1. 一人目の仲間を作る
2. 話し合いながらアウトプットする
3. ものの置き場を確保する
4. 成果をアピールする
5. やったことをふりかえる
6. 技術的負債を解消する

「チームが生き生きしつづける予感はどこからきますか？」

予告編動画 => https://www.youtube.com/watch?v=5Ro5_c5kFaY

アジャイルをUnlearnし、生き生きとした開発を見つけたチームがいました。そこにはアジャイルマニフェストもスクラムガイドもなく、自分達のパタンランゲージがありました。開発するシステム、立ち居振る舞い、プロセス、価値観、イベント、成果物などありとあらゆるものが記述されていました。パタンランゲージの語彙は200を超え日々編纂されていました。

私達チームが新しい形に変化していくこと自体が漸進的で、自然で、納得しやすい必要がありました。Unlearnしていくこと、アレグザンダー理論を導入していくこと、実践していくことは一見難しくおもえました。ですが、私達は徐々にできてきました。この漸進的な変化こそが私達が見つけたかったものです。これこそがチームにおける決定の遅延であり、漸進的変化でした。これらの具体例そして考察をおとどけします。

時を超えた開発の道とは何かを考えるきっかけにどうぞ。

DXという言葉がいろいろなところで見かけるようになり、それに伴ってスクラムをスケールする手法も色々と出てくるようになっています。

たくさん見かけるからといっても、うまく行っている例は多くありません。むしろ、例ばかりが増えすぎて混乱しているようにも見えます。過去にも用語だけ先行する例はたくさんありましたね。

このセッションでは、特定のスケーリング手法を説明するのではなく、スクラムがスケールできた状態とはどういうものか、スケーリングを妨げる障害について議論したいと思っています。

ScrumやXPなどを用いて、みなさんのチームがアジャイルになっていっているとします。

そのチームの活動がプロダクトを構築することが主なら、次はプロダクトをより使い続けてもらえるプロダクトづくりができるチームを目指してもいいかもしれません。

その時には開発をする役割以外にも、ユーザーのことを知る活動、ユーザーに買ってもらう活動、ユーザーのサポートをする活動など様々な活動が必要になります。そしてその活動を担う人達やチームと連携して動く(少し大きな)チームになる必要があります。

このようなチームがうまく機能する要素の1つに「組織がアジャイルな価値観や考え方、それに根ざした活動ができているか？」というのがあります。
もし1つ、2つのチームしかアジャイルな価値観や考え方を持っていなければ、このようなチームはうまく機能しないかもしれません。

このセッションでは、組織がアジャイルな価値観や考え方、それに根ざした活動をうまくできるようになるために取り組んできた事例をお話します。
組織の中の一員としてやっていた(昔の)事例、ギルドワークスの現場コーチとして様々な現場を外から支援していた事例をお話できればと思います。

みなさんの組織がアジャイルになっていくヒントになればと考えています。

Scrum での開発に興味のある Project Manager はいらっしゃいませんか？ 
ScrumMaster を始めてはみたものの、何となくプロジェクトマネジメントの延長になってしまっている Project Manager はいらっしゃいませんか？

以前の私がまさにそんな人物でした。

Technical Project Manager として LINE アプリ内スタンプショップ開発に参加したものの、開発規模も大きく苦労の連続。 
Scrum に魅力を感じ、それならばと CSM を取りに行くも、秋葉原では心を削られ、現場に戻ってもやはり壁は高い。
そして、なかなか一歩が踏み出せない、、、

と、そんな私ですが、昨年の Global Scrum Gathering に参加し、そこで学んだ経験を糧に、ScrumMaster 稼業を始めました！

実際に ScrumMaster を始めてみると、プロジェクトマネジメントとは考え方が全く違うこと、たくさんありました。
分かったつもりでいたのに、実際にやってみたら勘違いだったこと、たくさんありました。

Project Manager だった私が、知りたかったことを実例と共にお伝えし、ScrumMaster に挑戦してみようと思えるようなセッションをお贈りします。

「アジャイルコーチってどうやったらなれるんですか？」
「自分でそう名乗っちゃっていいのかな？」
「”明日からアジャイコーチやってよ”と上司に任命されたんですが、何をすればいいんでしょう？」

時々、このような声を聞くことがあります。モヤモヤがモヤモヤを呼ぶモヤモヤ感、ありませんか？(汗)
これからアジャイルコーチを目指してみようと思う方にむけて、このセッションでは

• コーチになる経緯って実際のところどんな流れがあるんだろう？
• コーチになるために意識しておくと良さそうなことって何だろう？
• コーチが大切にしてることって何だろう？

といったことをそれぞれのコーチが自身の経験や考えを示し、そこからコーチングにおいて大切にしている事、価値観、コーチになるまでの経緯から生まれる多様性や共通点などを整理することでコーチを目指す人、あるいはコーチをお願いしたい人にとってのヒントを持ち帰っていただける場にできればと思います。

私たちコーチも、うまくやれる方法を毎日探し続けている身です。このセッションは、決してアジャイルコーチになるためのHowToを示したいわけではなく、ましてコーチを代表して語ろうというものでもありません。ただ、サンプルとして自身の情報を共有することによって、これから目指そうとする人の気づきのひとつにでもなれれば幸いです。

※ みなさんサブタイトルの「今夜くらべてみました」はご存知ですよね？え、まだ？であればこちらをご覧ください

スクラムガイドには「完成」という単語が36回、「完成の定義」が12回登場します（弊社調べ）。ほかの代表的な単語を調べてみると、スプリントバックログは16回、スプリントレトロスペクティブは12回です。
つまり、スクラムにおいて「完成」は非常に重要な意味を持つことは明らかです。

しかし、「完成」に対する認識がスクラムチームのなかで違ったり、組織での品質の基準をまったく考慮せずに開発を進めていった結果、リリース直前に品質上の大きな問題が起こったといった話もよく聞きます。

ネット上の記事を調べても、「完成」が重要な意味を持つ割に「完成」とは何なのか、どのように「完成」を定義し、どうやって「それを守っていくのか」というノウハウはあまり出回っていません（と認識しています。プロダクトバックログの話なんかは山のように見かけるんですが）。

そこで、本セッションでは、「完成の定義」をできる限り深堀りし、今後みなさまが「完成」を守っていく上でのヒントを共有します。

• 特に知り合いもいなくて、他の参加者と話すことなくセッションを聞くだけで帰ってしまうなあ。
• ネットワーキングパーティで楽しそうに話している輪に入りたいけど、浮いてしまいそうで怖くて近寄れない。
• これまで話したことのない人と話してみたいけど、なかなか話しかける機会を見つけられない。

過去の自分がRSGTで感じていたことです。
その当時は、せっかくの機会を無駄にしているような残念な気持ちになることもありました。

それから、少しずつ色んな方と知り合う機会に恵まれた結果、
RSGT2020は、自分史上、一番色々な方と話すことができました。

そうしたらRSGT2020は、これまでと比較にならないぐらい最高の時間になりました。びっくりしました。
RSGTが終わった後も、何かと交流する機会があったりして、コミュニティが最高に楽しくなりました。

こういう場に来たとき、話せる相手がいることのありがたさを痛感したので、
話せる相手を見つけることを目的とした時間があっても良いのではと思い、このプロポーザルを作りました。

ネットワーキングパーティ以上に真面目にネットワーキングしていきたいです。

まずはお知り合いになりましょう！！

私が最初に本格的にアジャイルと出会ったのは 2012年の Developer Summit でした。その後、書籍や記事、アジャイルコミュニティにいる実践者、研修トレーナー、同僚などから様々なことを学びました。

その本質が理解できていた（る）かはさておいても、その中には、次の日から意識や行動が変容するような、私の中でそれまでの考え方が大きくかわった考え方もたくさんありました。

ここ数年、「アジャイル」という言葉にはこだわることなく、これらのアジャイルから学んだことを、部分的であったとしても、様々なロールの人と働く中で実践しその考え方をおすそ分けしてきました。それがアジャイルから学んだことであることを明かすことで、結果としてアジャイルに興味を持って頂くシーンもとても増えてきました。

このセッションでは、私自身が初学者だった頃にさかのぼって、今でも印象深いことを広く浅くごった煮駆け足でお伝えできればとおもいます。（なるべくその後その知識を深められるように、参照元を紹介する予定です）

さまざまなロールの方が、その中から一つでもひっかかり、つまみ食いでも良いのでアジャイルに興味を持つきっかけになればと思います。
または、アジャイル実践者の方は、まわりでアジャイルのファンを増やす活動のヒントや材料にしていただければと思います。

Just what exactly does an Agile Coach do? Coaches may vary in their response to this question. I would like to think that most Agile Coaches, with some variation, would be fairly consistent in how we perceive our role. However, some companies or orgs or people probably interpret the role of the Agile Coach in ways that coaches never intended.

Let’s explore some of the things that Agile Coaches have been asked to do! Are these antipatterns? Doing what needs to be done? This session will delve into the topic of the role of the Agile Coach and highlight potential challenges and possible solutions.

スクラムのセレモニー（イベント）が長い、退屈だ、誰か一人だけ話している、お通夜・・・
なんてことありませんか？

学習熱心なスクラムマスターに相談しましょう！
・・・でもスクラムマスターも困っています。

スクラムのセレモニーを効率的に効果的に楽しく、みんなの学習効果を最大化できる方法なんてどこにも載ってないんです！

そこで、Six trumpsをご紹介します。

この原則を元にスクラムのセレモニーのみならず、ワークショップ、カンファレンス、エグゼクティブミーティング、全社会議、株主総会、国会審議をアレンジしてみてください！！
ものすごい良いミーティングになると思います！
人が集まるところにおいて、人と人との関係性、学習効果を高めるために、すべてに応用できます！

このワークショップは、
Six trumpsの概要をお伝えし、スクラムのセレモニーにどのように応用するかを参加者同士深くディスカッションする形式
となります。

加えて、清水自身がScrumにSix Trumpsをどのように適応しているかお伝えします！

アジャイル開発を始めたいと思ってるけどどうやったら良いか分からない…

新しいやり方がうまくいくか不安だ…

そんな現場ではアジャイルコーチを呼んでスクラムチーム立ち上げを一緒に行うことがあります。

アジャイルコーチ支援の多くは個人による支援なので、個人毎に違った得意技があります。

また、学習・経験を経て個人のスタイルは変化し続けます。

またまた、知識・スキル以外にも個別のキャラもあります。

私はアジャイルコーチとして２年ほどスクラムチームの支援をしてきました。

その中で車業界のHさんや半導体業界のTさんといった大企業で仕事もさせていただきました。

さらに、コロナの影響もあり完全オンラインでの支援に移行するといった変化もありました。

色んなチームと関わり、色んな失敗や学びを経て、徐々に自分に合ったアジャイルコーチスタイルが見えてきました。

というわけで！

とても個人的な内容になりますが「笹のアジャイルコーチスタイル」について話させてもらいます。

スタイルは日々変化して現時点のスタイルになっていますが、その過程でどんな経験を経てどんな変化があったのかについてもふりかえってみます。

その中でチームを成長させていく上で重要だと考えていることをまとめていこうと思います。

アジャイルコーチを始める方や始めたばかりで悩んでいる方が、自分自身をアップデートするための刺激になれば幸いです！

ビジネスの急速な変化に適応すべく、多くの企業でデザイン思考やスクラムの導入が進んでいます。しかし、新たな体制や進め方を導入してもなかなか効果が出ないのが実際ではないでしょうか？例えば、能力も経験も何の支援も無く「明日から君がスクラムマスターだ」というような無茶ぶり。チームに権限委譲されているはずなのに、いつも細かく口出しする上司。このような経験をお持ちの方は少なくないのでは？この原因の１つとして、組織マネージメントの方法やマインドセットが従来から変わっていない事があげられます。デザイン思考やアジャイルを導入しても従来通りの組織マネージメントとマインドセットでは、効果は薄れてしまいます。このような問題の1つの解としてManagement3.0というマインドセットがあります。本ワークショップではManagement3.0の基本的な考え方と、具体的なプラクティスを用いたワークショップを実践形式でお伝えします。参加されるみなさんに「今日から」使える考え方とプラクティスを持ち帰って頂こうと思います。

追記：2020/09/22 エンタープライズアジャイル勉強会で中原が開催したワークショップに加えてTeamへの権限委譲と育成の観点を加えて100分で実施する予定です(10/12 追記)     参照：https://easg.smartcore.jp/C22/notice_details/V2p0V1lRTTQ=