アジャイル開発は海外から来た手法だと考えていませんか？実は、アジャイルの根底には、戦後にトヨタで開発された生産の流れ化、改善手法であるTPS、および、80年代製造業で行われていた暗黙知を利用した新製品開発手法の分析があります(XPにもScrumにも参照されています)。

現在広く採用されいてる「スクラム」の呼称は、野中郁次郎らが1986年に書いた論文「The New New Product Development Game」に由来しており、そこには、製品への要求を顧客との共体験を通して学び取り、それを仕様書ではなく体で開発に運ぶ、思いの伝達者としての実践知リーダーシップのありかたが生き生きと書かれています。

今回は、スクラムの本来の意味である、製品に関する知識獲得（顧客と要望に関するものと作り方に関するもの）、協調的マネジメント手法、デザイン思考との関連、知識創造モデル(SECI)、海兵隊の組織論、を中心に、 野中先生の「日本発のスクラム」のお話します。

そして、エンジニアの仕事の意味について考え、日本の現場でプロダクト開発、サービス開発、ソフトウェア開発に携わる人たちを応援したいと思います。

これまでアジャイルコーチとして様々な現場で、アジャイルやスクラムの導入のお手伝いや、実践の支援をしてきました。

もっとも頻繁に、そして恐々聞かれる質問が「うちってちゃんとスクラムやれてるんですかね…？」です。

教科書的なスクラムを否定しつつ、そもそも教科書さえちゃんと読めない人が多すぎます。

説教をします。

スクラムは軽量で理解が容易になフレームワークだと自分で名乗っています。でも、習得はちょっと難しい。ツンデレですね。

スクラムのルールをまとめたスクラムガイドは、表紙を入れても19ページしかありません。

でも、スクラムは、最初っからそんなにシンプルだったわけでもないし、ずっと同じ姿だったわけでもありません。最初はフレームワークと言ってませんでしたしね。

このセッションでは、ちょっとだけスクラムが出来上がってきた歴史をふりかえってみようと思います。

こんにちは。椎葉です。僕は2010年から楽天でWebアプリケーションエンジニアとして働いています。より良いものを届けたいという思いからスクラムの勉強を始め、2011年ごろから社内で導入を進めてきました。その影響もあってか、今は部署内のどのチームもスクラムを取り入れた開発を行っています。

スクラムを導入しようとした当初は「あれ？これ具体的にどうやったらいいんだろう？」と悩むことが沢山ありました。タスクってどれくらい細かくすればいいの？とか、見積もりって具体的にどうやったらいいんだろう？とか。

それに加えて難しいなと思ったのは環境です。組織がスクラムに適した形ではなかったり、メンバーもこれからみんなで成長していこうという状況だったり、開発チームの中の誰かがスクラムマスターをやらなきゃいけなかったり。

そんな中で色々と悩みながら一歩ずつ前進しながら取り組んできたのですが、試行錯誤を繰り返した結果「だいたいこうやると良さそうだなー」というやり方が自分の中でできてきたので、それを紹介したいなと思います。

それによって、同じような悩みを持った方が「そういうやり方もあるのか」と感じて一歩踏み出すチカラになれたらいいなと思います。

株式会社ラクス は中小企業向けのクラウドサービスを提供し、18期連続増収で事業拡大中の会社です。私が所属するチームは主力サービスである 楽楽精算 の開発を担当する大阪の開発チームです。これまでに社内初のモバイルアプリやAIによる入力補助機能など、サービスの成長を支える新機能の開発を行ってきました。その取り組みを活かしてチームをさらに加速させサービスのさらなる成長を支えるために、2018年からスクラムの実践にチャレンジしています。

本セッションでは、成長を続ける会社と主力サービスをとりまく不確実性の高いビジネス環境の中で、様々な変化に向き合いながらチームがアジャイルであり続けるために取り組んだこの1年間をスクラムの現場の視点で総括します。

このセッションテーマは RSG2019のCfP向けに考えた内容ですが、大阪の開発チームの取り組みとして、より身近な関西の皆様にお話しできればと考えています。

アジャイルやっていますか？スクラム組んでますか？「スクラム」のもっとも重要なポイントは、チームみずから課題を明らかにし、一つ一つ解決していくところにあります。簡単なゲームを通じて、スクラムのプロセスを通じたチームの課題解決を体験してみましょう。このワークショップはBall Point Gameといって、スクラムでは定番のワークショップの一つです。ぜひ持って帰って自社でやってみてください。

会社全体としてカイゼンマインドが広まっている組織の話

カイゼンしながら日々成長する総務の実践の話

私はプロジェクトマネージャーやプロダクトマネージャー経験が社会人生活18年の大半を占めており、エンジニアだったのは新卒入社の会社での1年程しかありません(もっと言うとホントにプログラム書いたのは半年で言語はPL/I…)。

そんな私がスクラムを全く知らない状態でプロダクトマネージャーをやるようになり、さらに4年程前にプロダクトマネージャーをやりながらエンジニアリングマネージャーをやることになりました。

当時はそんな言葉すら知らなかったので、本当に手探りの毎日でしたが、だんだん各ロールでやることというのがわかってきて、エンジニアリングマネージャーの仕事は「メンバーのお給料を上げるために尽力するのが仕事」だと2017年のRakuten Technology Conferenceでプレゼンさせていただきました。

そこからさらに1年経過し、未だに時折プロダクトマネージャーを兼任しながらエンジニアリングマネージャーをやることもあり、より強くこの2ロールの違いを意識しながら動くことが増えました。

ということで、2017年に述べたことよりもさらに気づいたこと、強く意識するようになったことを、両方のロールの面からお伝えできればと思います。

あなたのチームは楽しく過ごしていますか？常に学んで成長していますか？成果を出せていますか？

チームがポジティブに自分たちを見直せるふりかえり手法として、新たに作られたFun! Done! Learn!を本セッションのご参加者に体験をして頂きます。

・最強のチームをどう定義していますか？ ー Fun! Done! Learn!が生み出された経緯
・Fun! Done! Learn! を体験しましょう！ ー 参加者と一緒に実践
・この振り返りを現場で使うためのコツを共有
・Q&A

とあるECサイトを運営する企業に今年はじめから働いています。その後、上手くいったりいかなかったりしながら、みんなおおむね幸せに過ごしています。(response to: https://confengine.com/scrum-fest-osaka-2019/proposal/8722)

ところで、近ごろスクラム導入というキーワードが急激に増えているように見受けます。同時に、同じスクラムの取り組みでも、ええ感じになってるところと、ザンネンなところの差は大きく開いてきたようにも感じています。

なぜこのような格差が起こるのか。これまでに、スクラム道関西の活動や、アジャイルコーチとして経験したことから、"やり方"よりも組織文化やメンバーに根ざしている暗黙の行動規範といったものがあるような気がしています。そこにフォーカスし、自身の職場での実践をまじえて、マネジメント、リーダーシップのあり方について考察してみます。

かれこれ20年以上、鳥取県にある株式会社リコーの子会社（何度か名前は代わって今はリコーITソリューションズ株式会社の鳥取事業所です）で働いていて、21世紀に入ってからポツポツと、気がつくと10年以上アジャイルとかスクラムとかやってきました。長い。華々しい成果とかはないのですが、長いと色々経験できるので、その経験のお裾分けをさせてください。

特に、大きな組織や親会社子会社の関係性の中で、希望に燃えてスクラムを組もうとすると起きること、それを乗り越えるためにできること、に興味がある方にピッタリの内容です。最近始めた方、三年続けてみたぞという方、もう少し先の未来を覗けるかも？

デマルコの名著『ピープルウェア』では、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」と言っています。

アジャイルやスクラム界隈でも、心理的安全性をどう醸成するのかといった話題やレトロスペクティブでいかにアイデアを引き出していくか、といったテーマに関心が集まっているようです。

しかし、これは本当に今あなたのチームがフォーカスすべき問題なのでしょうか？

スクラムで成果を出すためには、以下の3つの要素が必要です。

• 適切な課題を設定する力（プロダクトビジョン、ミッション、ゴール）
• 課題を解決するソリューションを構築する力（言い換えれば技術力）
• これらを上手く進める力（プロセスやチームの関係性など）

心理的安全性だけでは成果は出ません。ダメなビジョンをいくら良いチームで実現しても何の価値もありません。良いビジョンでも技術力がなければ時間がかかってマーケットに出せないこともあるでしょう。

このセッションでは、あなたのスクラムチームが改善すべき問題にはどのようなものがあるのか、それらの問題の中から取り組むべきものをどのように選ぶべきか、説明します。

こんにちは。椎葉です。

僕は楽天でWebアプリケーションエンジニアとして働いています。数年前に「エンジニアとして色んなチームを内側からサポートしたい！」と考えて「改善グループ」というグループを立ち上げました。そして、様々なチームの中に入っていって、一緒にコードを書いたり、テストを書いたりして楽しんでいます。

そんな風にエンジニアとして動くことを中心にしてはいるのですが、実は毎回最初にやるのはチームの開発プロセスを一緒に改善することなんです。というのも、エンジニアとして動くための土台としての開発プロセスが、とても重要だからです。

僕の所属しているECインキュベーション開発部では、どのチームもスクラムで開発をしているのですが、この活動の中でよく聞いたのは「スクラムをやってはいるのだけど、何かうまくいかない」ということです。

このセッションでは「スクラムが何かうまくいかない」と感じているチームに実際にどのような課題があったのか、その原因は何だったのか、そしてそれをどのように改善したのか、を失敗談も交えながらお伝えしたいなと思います。

同じような課題を感じている方が一歩踏み出すきっかけになるといいなと思います。そして、セッションの後にはみなさんと「うちもこういうことがあるよー・あったよー」みたいな話をできたら嬉しいです！

カナダ、日本、マレーシア・・・自分の出自の説明はいつも難しい！出身カナダの大学ではボランティアクラブをリードしたり、日々ダンスに明け暮れたり。上智大学に留学やインターン仕事もしたのち、偶然にもブラジルがHQのCI&Tの日本オフィスに就職しました。顧客プロジェクトのQAアナリストとして2年が経過しました。

CI&Tはリーンを土台にエンタープライズ領域でのアジャイル開発で伸びたグローバル企業です。CMMi5も取得したプロセスを大切にする文化を基本に、日々スクラムを顧客やチームに合わせて運用しています。

本セッションでは、とあるリバース・エンジニアリング案件を例として、リーンに沿い顧客価値を第一にしたとき、スクラム・カンバンをいかに柔軟に活用できるかについて、新卒QAアナリストの経験と視点をもとにお話したいと思います！

みなさんは、ふりかえり（レトロスペクティブ）を楽しんでいますか？

スクラムでは「レトロスペクティブ」というイベントとして、チームの活動の一環として定義されている「ふりかえり」。色々なチームの話を聞いていくなかで、ふりかえりがなかなかうまくいかない、というチームが多いという現状が見えてきました。

ふりかえりは、皆で成長を祝いあい、前向きに未来のことを考える、とても楽しい活動です。
そんな楽しいふりかえりを、これからふりかえりをはじめようとしている方、
ふりかえりでモヤモヤしている方に体感いただきたいと考えています。

45分のワークショップのなかで、チームを作り、実際にふりかえりを行います。
そして、最後にワークショップをふりかえり、気づきを現場に持ち帰ることで、
現場で楽しくふりかえりをはじめるためのきっかけしていただければ幸いです。

赤鬼、青鬼リターンズ！！！

地獄のデイリースクラム＜また＞やります！

RSGT2018で実施した地獄のデイリースクラム。SFO2019でも出しちゃいます！！！

スクラムの中でも、比較的とっつきやすいイベント『デイリースクラム』
しかし、現場ではこんな光景をよく見かけますね・・・？

• 毎日できていない
• 時間通りに始まらない
• 特定の人しかしゃべらない
• デイリースクラムがお通夜みたい…
• そもそもやっていない…

このワークショップでは、そんな悩みを解決いたします！

　　『どうやったらデイリースクラムが良くなるの？』
　　『スクラムマスターは何をしたら良いの？』

皆さんと楽しく体を動かしながら、一緒に体験していきたいと思います。

(名前は怖いですが、内容は恐くないですヨ！)

イベント終了後、私たちが知らなかったデイリースクラムの一面を発見出来るかもしれません。

セッションに採択されましたら、職場で手軽に地獄を味わえる、自作『~地獄のデイリースクラム~ 地獄カード』の配布や『地獄カードデータ』のダウンロードサービスなどを検討いたします！！

あと！盛り上げるセッションになるようにがんばります！
しっかりがんばります！ちゃんとします！

～毎日のことだから ちょっとの工夫で大きな差！～

『地獄のデイリースクラム』とは？

地獄のデイリースクラムとは、2004年10月にデンバーのScrum GatheringでWilliam C. Wake氏によって行われたチームでデイリースクラムについて学ぶ ことができる「Daily Scrum From Hell」をもとにしたワークショップです。

3年前にCI&Tに加わり、国内企業案件の企画・開発支援にBusiness Analyst（要件定義スペシャリスト）という立場で、常に顧客企業のプロダクトオーナーに寄り添いながら関わってきました。

CI&Tはリーンを土台にエンタープライズ領域でのアジャイル開発で伸びたグローバル企業です。CMMi5も取得したプロセスを大切にする文化を土台に、日々スクラムを顧客やチームに合わせて運用しています。

本セッションではAOKI「suitsbox」の事例を交え、2週間単位のスクラム開発を行い期日前のロンチを可能にしたポイントを「国内企業のプロダクトオーナー」の視点で、ビジネス、プロセス、コミュニケーション、テクノロジー、メトリクスといった各種の観点について紹介してみたいと思います。

2年前にブラジルのCI&T HQから家族（妻・6歳/2歳/0歳児）で日本オフィスに転勤してきた日本が大好きなソフトウェア開発者です。.NETやPHPが得意です。テストなど各種の自動化も好きです。アニメや日本の歌謡曲も好きです。

CI&Tはリーンを土台にエンタープライズ領域でのアジャイル開発で伸びたグローバル企業です。CMMi5も取得したプロセスを大切にする文化を基本に、日々スクラムを顧客やチームに合わせて運用しています。

本セッションでは、非リーダー・非マネジメント職種であるソフトウェア開発者が、どのようにスクラム・アジャイル開発の成功に貢献できるか、について紹介します！

EN

This session will emphasize the contribution that the Software Developers as non-management role players, can contribute to making Agile a success.

なるべく日本語でお話しする予定です。

エンジニア採用を人事に任せすぎていませんか？ 今どんな学生がいてどんなことをやっているか知っていますか？ こんなに面白い現場がたくさんあるのに、知られていないとしたらもったいない！

文科省のプロジェクトenPiTで情報系の大学生や大学院生の教育に関わるようになって早5年、学生にアジャイル開発についてレクチャーしたり、学生のアジャイル開発プロジェクトを支援しながら得た知見をちょっぴりおすそ分けします。

• 企業のチームと学生のチームの違い
• 過去にどんなプロダクトの事例があったか
• どんな教え方が有効か
• どんな活動を見に行くと面白いか
• どういう関わり方をすると楽しいか

取り上げる事例は、あくまでも個人の経験であり主観です。

とかく教員に公平性を求める人も多いようですが（特に教育関係者）、独断と偏見で話します。

とはいえ、うるせー人（特に教育関係者）にうるせーことを言われたら面倒くさいかもしれませんので、資料の公開はしません。会場オンリーのとっておきのお話をお届けします。

え、え、え、ちょっと待ってちょっと待ってーや？

このセッション、めっちゃ明るくなーい！？？？