アジャイル開発は海外から来た手法だと考えていませんか？実は、アジャイルの根底には、戦後にトヨタで開発された生産の流れ化、改善手法である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年に述べたことよりもさらに気づいたこと、強く意識するようになったことを、両方のロールの面からお伝えできればと思います。

レトロスペクティブのツールであるKPTは実に多様な進め方があります。徐々に短い期間のスプリントに挑戦してきた基盤チームではこの1年でKPTの付箋が5000枚になりました。

今回はそのKPTの具体例をチームメンバーであるbleis-tift, dico_lequeの二人それぞれ別の視座から紹介します。KPTの壁が狭くなるたびに引越しをかさねてきた基盤チームの実際のレトロスペクティブとはどんな会話がくりひろげられているのか。

よいチームになるためにKPT活用法の事例として、みなさんのレトロスペクティブにすこし違う視点を提供します。

こんにちは！
私達はLED-Camp(※) でスクラムを初心者向けに教えています。
ここでは、スクラムを教える上で感じたこと、特に

・うまく伝わっていたこと
・伝わっていなかったこと

に焦点を当てていきます。現在の実行委員の多くは、元々は参加者としてLED-Campに参加していましたが、参加者だけでは終わりたくない！と みんなやる気に満ち溢れてます。

参加者と実行委員、その両方を経験した私たちだからこそわかる、スクラムを教える際に生まれる教える側と学ぶ側の「ギャップ」を紹介していきます。

この話を通じて、教える際に気を付けないといけないポイントを感じてもらいたいです。

※ LED-Campは、組込みシステム開発の初学者や未経験者、また、興味のある方を対象とした合宿形式の勉強会です。若手の社会人や学生が一堂に会し、組込みソフトウェア開発の基礎を学びます。実習を通して、モデル駆動開発とスクラムを学び、チームで解決することを体験します。
詳しくはリンクを見てください！

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

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

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

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

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

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

皆さんは、メンバーが主プロダクトとは別に組織改善のような横軸のチームに関わっていたとき、その人の横軸のチームにおける貢献をどのように評価・賞賛しますか？
弊社では比較的若手に裁量があり、様々な形で若手が組織へ貢献しています。彼らの活動がより認知され、評価・賞賛されるような仕組みがあれば、きっと彼らのモチベーションは高まり、さらなる組織貢献をしてくれることでしょう。

本セッションでは、マネジメントをしたことがない新卒4年目の私たちが、メンターとして新卒の学生向けインターン企画・運営業務に関わり、可能な限り相応に評価されるべく、彼らの活動を彼らの上司、および組織へ向けて可視化した話をします。
加えて、ここに到るまでに私たちは何を考え、どのようにしてきたのかを順を追ってお話しします。

本セッションでは横軸業務における評価について扱いますが、おそらく通常業務における評価においても、私たちの取り組みを参考にできるのではないかと考えています。

評価者に限らず被評価者の皆様と、私たちの活動の妥当性や改善策について議論できれば幸いです。

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

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

SIerにあって「30台、取り柄無いプログラマー」だった自分が「このままでええんやろか…」でアジャイルに入門…

そうやって「やってみたいから足掻いてみる」ってスライドを書いてから数年。

「アジャイルってなんや？」から始まり、「スクラムとの出会い」を経て、「スクラムのプロジェクトに関われない…」というボーダーを超え「スクラム・プレイヤー」となり、今サービスを作ってる。

その間にあった「とまどい」「ジレンマ」「あるある」「踏み抜いた地雷 や 踏まなかった地雷(は、今から調べますが)」などなど。

そんな「生存戦略としてスクラムを選んだ壮年プログラマー」の経験を「チームを眺める側」ではなく「メンバー視点」「プログラマー視点」から話したいと思います。

こんにちは。

私たちは、大手電機メーカーの中で全社を横断したシステム/ソフトウェア開発のコンサルティング及び技術導入を推進するグループです。

今回の発表では、私たちが三年前にスクラム型開発方式を導入し、過去三年間に渡って開発を手掛ける傍ら、新しい文化の定着とプロセス・開発インフラの改良を実施してきた活動について紹介します。

活動の初期段階では、担当者間で情報を共有する文化がなく、個々の担当者が自分の職務を淡々とこなしていました。こうした状況下でスクラム型開発を導入する先導役になったのは、入社１～３年の若手メンバーです。

カンバンを使ったタスクの共有、基本的な開発インフラの構築、及び、開発プラクティスの導入と定着を経て、現在は、数多くのプロジェクトを並行して実行するスクラムチームとして活動しています。

一方で現在の組織・体制の枠組みでは、チームに閉じたプロセスと開発環境の改善に限界も見え始めています。今年度は、自チームを対象に匠メソッドによるチームデザインを実施しました。5年後の姿を見据えた上で、直近のスクラム開発にどのような活動を落とし込むか？の取り組みも簡単にご紹介したいと思います。

本発表を通して私たちのようなメーカー系企業とIT企業との間で活発な意見交換ができれば幸いです。

About Us

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

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

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

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

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

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

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

「ほかの企業が採用している方法やプラクティスをコピーしようとしたり、専門家がデザインしたモデルをそのまま実行してはならない。」アジャイル界隈では、このような考え方が定説となっていると感じてます。もちろん、ほかの企業とあなたの現場では状況や制約も違いますし、各プラクティスについてもその本質を理解しないまま闇雲に導入したところでうまくいく可能性は低いでしょう。そこで先述したような定説が述べられるのはもちろん理解できますが、一体どれほどの人達が最初の段階から本質を理解した上で、現場の状況や制約に合わせてアジャイルを導入できるでしょうか。

『禅とオートバイ修理技術』という書籍において、人間の理解は、本質に着目する"古典的な理解"と、表面的な現実しか見ることができない"ロマン的な理解"に分けられると記述されています。アジャイル開発を実践している"古典的な理解"の人からすると、本質も理解しないまま手段としてのアジャイルプラクティスを盲目的に実践する"ロマン的な理解"の人を理解することができず、そういった振る舞いのことを"プラクティス厨"、"スクラムの奴隷"と揶揄し、「状況に合わせて自分の頭で考えよう」と言いますが、"ロマン的な理解"の人はいくらそのように言われたからといって理解して実践することは難しいです。なぜならば、両者は全く異なる理解様式だからです。

当セッションでは、よりよい開発方法を見つけだそうと必死に頑張ってる"ロマン的な理解"の人ががいかにしてアジャイル開発、スクラムに取り組み、結果としてアジャイルになれるかをフェーズと理解様式の二軸から説明したいと思います。

こんにちは。椎葉です。

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

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

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

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

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

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

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

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

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