プロダクトやチーム、そしてスクラムの継続性を維持するうえで、「ふりかえり」は最も重要なイベントです。
スクラムに取り組み始めると、多くのチームが失敗と学習を繰り返して自分たちなりのスクラムを定着させていくことになると思いますが、その中でポイントとなる重要なイベントがふりかえりではないでしょうか。様々な事情からいきなりスクラムに変えることができないチームも、まずはふりかえりから導入している事例をよく耳にします。
私自身もスクラム開発に取り組み始めてから、スクラムマスターとしてふりかえりをファシリテートしていく中で、「あの時のふりかえりでチームが前進した」「あの時のふりかえりでチームが新たな学びを得た」と感じたことが多々あり、ふりかえりはスクラムチームの継続性にとって重要なイベントであると実感しています。
この経験から、私が最初にスクラムに取り組んだ現場での1年間をふりかえりの切り口で改めて整理し、その後の別のチームではふりかえりを軸にチームをアジャイルにしていくことに取り組んでいます。それらの実例をご紹介するとともに、この経験を踏まえて私が考える継続性を意識したふりかえりについてお伝えします。
継続的なふりかえりとは、チームの過去・現在・未来をつなぐ支援をすることです。
そして、継続的なふりかえりで特に私が意識しているのは以下の3つです。
株式会社ラクス は中小企業向けのクラウドサービスを提供し、19期連続増収で事業拡大中の会社です。私は2011年に入社し、BtoCサービスや北米向けサービスなどの新規事業の開発を経験した後、主力サービスである楽楽精算の大阪開発チームをリーダーとして立ち上げ、2018年からスクラム開発に取り組みました。スクラム開発に取り組んだことで、過去の開発経験も含めてチームが不確実性と向き合い敏捷性を高めていくことの重要性を改めて実感しました。2019年4月からは10年以上続くメール配信サービスの開発チームに異動し、マネージャとして従来型の開発プロセスを少しずつ改善してチームのアジリティを高めていくことにチャレンジしています。
以下の3本立てでお話しする予定です。
スクラムを始める/続けるためにふりかえりをファシリテートしているスクラムマスター、スクラムを浸透させたいマネージャー/リーダー/スクラムマスター
アジャイル、XP、Scrumは10年くらい前からイベントに出たり、本を読んだり勉強しても、どうにも身につかず。
2017年に会社を作って、2019年に自社サービスをリリースして、やっとアジャイルが腹落ちしてきた気がします。
このセッションでは、なぜ今までアジャイルが実践できなくて、なぜ今になってアジャイルがわかりかけてきたのか、ということをお伝えできればと思います。
アジャイルでの大物でありScrumを考案して世界に広げた人物。ジェフ・サザーランド氏は実は、米国陸軍士官学校を卒業した元パイロットです。
軍隊は一番入れ替わりが激しい組織です。今日入隊する人がいて、その反面退役する人もいます。退役の方が入隊より多く、総員の数がマイナスになることもあります。入れ替わる時の階級もバラバラで、一般兵士が入隊してきても、例えばベテラン士官が退役する場合もあります。
しかし、こういう状況の中でも、全てのメンバーを即戦力に作る極限のアジリティーを発揮し、最高のパフォーマンスを保つのが軍隊の最大課題であり、存在理由でもあります。私はそこで元陸軍将校として４年間勤め、300名の部下を纏めながら、毎日戦闘力の向上のために資源管理・訓練の計画・実施などに力を入れていました。
チーム（ないしは会社）そしてアジャイルプロセスは、軍隊と特に違いはありません。入れ替わりは激しく、生産性のために中途はもちろん新卒に対しても即戦力になれる人材を求めています。チームなど組織に対しても、一定のパフォーマンスを出すことが求められています。
制限された状況の中でも、どうしたら常に最大のパフォーマンスが発揮できるか。
軍隊ではどういう風にしていて、それをどうやって今のチーム・組織に活かせるか。私の経験を持ってご提案させていただきます。
本セッションは「見積りは不要なのでやめよう」と一律に提案するものでは ありません。
アジャイル開発における見積りについては「アジャイルな見積りと計画づくり」という素晴らしい書籍でその有用性や有効な実践方法が示されています。
ここで、あえて問わせていただきます。
「あなたのチームの見積りは、どれくらい正確ですか？」
前回の RSGT 2019 Key Note において、 Chris Lucian@christophlucian 氏は #NoEstimates のコンセプトと、見積りのコストについて言及しました。
彼が述べたように、見積りには負の側面があることもまた認める必要があるのではないでしょうか。
私達のチームでは、これら見積りの負の側面と見積りから得られるものを比較し、見積りすることをやめる判断をしました。
以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。
この私達のプロセスでは、モブプログラミングが鍵となっています。
本セッションでは、私達がどのように見積りをせず開発をしているのか、見積りをやめたチームで何が起こるのか、という事例を紹介し、ソフトウェア開発、特にスクラムにおいての見積りのあり方の議論の一助となることを目的とします。
少し見積りの負の側面について触れておきます。
私達が考える見積りの負の側面は、以下に集約されます。
もちろん、見積りは負の側面ばかりではありません。
しかしながら、見積りの「価値」については、見積り自体に価値があるのではなく、見積りから得られる副次的な情報に価値があると考えられます。
見積りから副次的に得られる価値が見積りの労力とバーターしない場合、その価値を別の方法で得られるのであれば、見積り自体をやる必要はないと考えます。
タイトルの通り、私達はスクラムを実践しています。
見積りを行わないプロセスでもスクラムは成立するのか、あるいはこれはスクラムと呼べるのか、という疑問が当然湧いてきます。
スクラムガイドには「見積り」という言葉が９回登場します。
それぞれを分類すると、スクラムにおける見積りは以下の意思決定を行うための情報であると考えられます。
見積り自体を行うことなくこれらの意思決定をするための情報が得られるのであれば、見積りをしなくてもスクラムとして成立するのではないか、というのが今回のアイディアです。
我々は、以下の方法でこの意思決定を行っています。
Joshua Kerievsky はAgile2016 の基調講演「Modern Agile」において、アジャイルプラクティスは「補助輪」であると表現しました。
見積りは今、ソフトウェア開発の「補助輪」といえる段階に差し掛かっているのではないでしょうか。
私達のプロセスは完成されたものではなく、日々実験と失敗を繰り返して進化しているものです。
AEPから１０年、「見積りはソフトウェア開発において必須」という考え方もまた固定概念かもしれません。
我々の実践しているソフトウェア開発の形について紹介し、議論できればと思います。
2018年の11月頃から始まり、開発手法としてScrumを採用したとあるプロジェクトは、2019年の6月に予定通りサービスのローンチを行うことができました。
このプロジェクトはお客さんとのユーザーストーリーマッピングでのMVP検討から始まり、まずはサービスの背骨にあたるMVPの実装を1ヶ月で完了。その後4ヶ月間はリリースできる状態をずっと維持し続けながら、毎スプリント着実に機能を追加していき、ローンチの1ヶ月以上前にはお客さんが希望する機能の追加を完了。ローンチ前にはいくつかのメディアに取り上げられたこともあり、多少注目されながらローンチ当日を迎えましたが、そこでも拍子抜けするほどなんのトラブルも起きず、お客さんからも開発チームからも、これほど安定したプロジェクトは今まで経験したことがないといったようなポジティブなフィードバックをもらうことができました。
その結果、お客さんからの期待値が想定以上に高まってしまい、同じやり方を他の複数プロジェクトにも早急に導入することが決定。開発者を含む関係者が一気に倍増したことで、チームは混乱状態に陥ってしまいました。
今現在も混乱中ですが、RSGT2020が開催される頃までには何とかなってると思うので、私達がこれからどのようにして再び練度の高いチームを作り上げていったかについてお話しできればと考えています。
Joy,Inc.に出会う前のぼくらは、チームとして機能していませんでした。2013年ごろ、色々な問題が噴出し、会社としてどん底の状態でした。
そこから、色々な取り組みを行い、少しづつ会社の状態がよくなっていきました。その過程のなかで2017年8月「Joy,Inc.」に出会いました。
「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
この本に共感しぼくらもこんな会社に成りたい！と決意。それを実行してきました。
会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。
開発チームのスキルによって、開発の時に重要な要素である実行可能性（Feasibility）は大きく左右されます。価値のあるバックログアイテムが用意されても、それを実現でき、お客さんに届けることができなければ意味がありません。実現することこそが開発チームの本懐であると思います。
現在のソフトウェア開発において、オープンソースソフトウェア（OSS）を活用することは当たり前となってきています。もちろんOSSも人が作ったソフトウェアですのでバグはありますし、期待した機能を持っていなかったりもします。では、そういった不具合や期待した機能を持っていないことに気づいた時に、どうしたらいいでしょうか？居酒屋で見つけたバグをネタにビールを飲むことでしょうか？「こんなバグがあるなんて、酷い！」「このOSSは、○○が無いのでダメだ！」などとSNSなどで投稿することでしょうか？
残念に感じたり、時には怒りを覚えるかもしれません。ですが、それはとても素晴らしいチャンスです。そう、OSSに貢献するチャンスです。しかし、残念なことにOSSへの貢献がとても高いハードルと感じている方もいらっしゃるようです。
ようこそ、OSS Gate ワークショップへ！
このワークショップでは、OSSに貢献したいけど最初の一歩を踏み出せずにいる方の背中を後押しするワークを行っていただきます。終わった時には、小さいかもしれませんが、OSSへの貢献に確実な一歩を踏み出せたと思えっていただけるでしょう。そして、普段の開発で、それまでよりもOSSに対して身近に感じていただけると思います。
このセッションのプレゼンテーターの二人は、過去に同じ開発プロジェクトにおいて、アジャイル開発を経験しました。ひとりはアジャイルコーチ、スクラムマスターとして参加し、ひとりはエンジニアとして参加しました。
そのプロジェクトは1000人を超える開発組織の中で初の「アジャイル開発を導入する」とうたったプロジェクトでした。もちろん途中、困難はありましたが、無事にプロダクトはリリースされました。
プロジェクトが終わり、ふたりは異なる環境でスクラムマスターやアジャイルコーチの経験を積んでいきます。
共に歩んだアジャイルプロジェクトから10年。それぞれの経験をふりかえりながら学びを確認し、今後の10年を考えるセッションです。
Retty株式会社は「信頼出来る友人や好みの合う人から自分にぴったりなお店を探す」グルメサービスRettyの開発・運営を行なっております。内部システムはレストランを見つけるtoC向けのWeb、スマートフォンアプリ、レストラン側が利用するtoB向け管理システムに大別できますが、会社としてたった1つの多くのユーザに利用されるサービスを手がけています。
サービスと会社が大きくなった結果、全社でスピード感とアジリティを追求していくには開発プロセスの見直し、そして組織構造の見直しが必要だと考えるようになりました。
本講演では1チームから始まったスクラム開発をどう広げ、LeSS(Large Scale Scrum)を採用した大規模スクラム体制に移行できたのか、具体的な課題とその対処を交えて紹介します。
師匠：David氏からDevOpsDays Tokyo 2019で強いメッセージを受け取った直後に臨んだ認定スクラムデベロッパー研修。エンジニアがオーナーシップを持ってプロダクトと向き合うこと、スクラムをやるためにはXPが必要であるなど、私たちは師匠から熱い想いやメッセージを受け取りました。
これを経て、改めて『エクストリームプログラミング』(2015/6/26 Kent Beck (原著), Cynthia Andres (原著), 角 征典 (翻訳))に目を通すと、
“XPが価値、原則、プラクティスを用意しているのは、ガイダンス、チャレンジ、説明責任を提供するためだ”
とあり、XPは単なるプラクティス集ではなく、エンジニアは自分たちが取り組んでいることに対してちゃんと価値を理解すべきであり、それを周りの人たちに責任を持って説明していく必要性があることを強く訴えている、非常に刺激的なものであることに気づきました。
「お客様に継続して最も高い価値を届けられるのは自分たちだ！」と自負をしながら、より高いスキルやデザインを追求出来る。
スクラムとXPを最高のチームで体現していく勇気を、今こそ分かち合いましょう！
”ビジネス側” から言われたものを言われた納期でつくる。私達は内製のプロダクトのはずなのに、まるで請負契約のような開発をしていました。
そこから、開発チームが少しずつ変化し、プラクティスを実践し、”ビジネス側” を巻き込み、プロダクトの価値をともに考えるチームに成長してきました。
その変化の中で、プロダクトが価値を届けることにフォーカスし、チームの中心に据えることができたのは、師匠から学んだ価値、原則、プラクティスと、その実践の影響が多分にありました。
もっとより良いチームになりたい。もっとより良いプロダクトを開発出来るようになりたい。そんな想いで立ち上がり、一歩ずつビジネスと向き合えるようになったチームの今をお話します。
クライアントからアジャイルな開発体制を作って欲しいと要望される。
アジャイルな開発体制を求めている理由を聞いていくと、「ビジネスインパクト」だという。
今までにない新しいプロダクトが素早く創れることを期待している。
本当にそれだけで「ビジネスインパクト」が得られるのか？
開発部門だけでなく、新たなビジネスモデルやオペレーティングモデルを実現するためにも他部門を横断して価値を生み出さないといけないのではないか。
そのような本質的な問いを抱いていたアジャイルコーチのGupta。
アジャイル開発の外側で、組織変革に携わっているreborn founderのハブチン。
呑みながら二人が対話したとき、仕組みや体制だけでなく、社員のモチベーションも重要で、ある仮説を立てた。
仕組み×モチベーション＝組織変革
仕組みだけだと形骸化するし、
モチベーションだけに頼ると不安定な状態になる。
両方の要素をバランスよく組み合わせることによって、
組織が変革し、「ビジネスインパクト」が得られるのではないか。
それではモチベーションの正体は何なのか。
鍵は個人のミッションの見える化にあった。
個人のミッションとチームのミッションが重なり合ったとき、
真のアジャイルが生まれていく。
ハブちんとGuptaの会話で生まれた様々な気付きをこの場でシェアしたいと思っています。
サイボウズの人事部採用チームは、
採用計画の立案から面接の実施、合否連絡、内定者のフォロー、イベントの出展、説明会の実施といった業務を日々行っています。
採用チームに異動してきて2年目の始めに、リーダーを引き継ぐことになりました。
これまで経験豊富なリーダー中心に業務を進めてきた状態だったので、経験の浅い自分がリーダーになることに不安を感じていました。
自分個人がエースの抜けた穴を埋めるのではなく、チームの皆でカバーできるような進め方をしたいと悩んでいたところ、
開発チームで導入が進んでいたスクラムが目に止まりました。
スクラムが人事の業務改善にも役立つと感じ、導入を決意し、2年ほどスクラムをベースにした業務改善を進めてきました。
プランニングやふりかえりで地道な改善を重ねた結果、モブ作業やカンバンを活用が進み、メンバーの残業が減り、チームのベロシティも向上しました。
現在はチームでタスクがコントロールでき、理想のチームに向かう良い状態が作れています。
改善の過程で起きた問題やそこから学んだこと、チームに起きた変化を紹介したいと思います。
日々スプリントを回している中で
「明確に課題があるわけじゃないんだけど、何か違和感を感じる」
「仲が悪いわけじゃないんだけど、本音で話し合えているのだろうか？」
上記のような健全ではないことを何となく感じ、そこから振り返って次の取り組みを考えたことはないでしょうか？
私はこのように感じることを"嗅覚"に例えています。
ではその嗅覚はどうやって身に付いたものなのでしょうか？
アジャイルソフトウェア開発宣言の「プロセスやツールよりも個人との対話を」の背景にその答えが隠れているのではないかと考えています。
ノンバーバルコミュニケーションにある多大な情報を紐解くことができるかどうかで"嗅覚"を感じることができるのではないでしょうか。
理屈はいい加減身につけてきたという方々に向けて、「考えるのではなく感じる」という力とは何なのか、それをこのセッションでお話できればと思います。
こんにちは。2年前に転職してEC通販/製造企業のIT部門長をしています。元アジャイルコーチだった私は早速スクラムを導入し、持ち前の鈍いマサカリと役職権限をふりかざして覇道系プロダクトオーナーとして切磋琢磨しています。
“システムの価値は、その機能ではなく、どう使われるかで決まる”
どこで読んだか聞いたかことか忘れましたが、私はずっと意識してきました。
私が就いたIT部は、つぎはぎシステムの補修とそれが吐き出す壊れたデータを直すことで日々を追われていました。
やらなければならないことが多すぎるので、できるだけ手間をかけずに要望を満たす必要があります。しかし機能を削るだけでは利用部署の不満は増します。
私は、十分に機能するものを小さく作るために「どう使うか」に注目することにしました。そして、そのために利用部署との間に「これはいいものだ」と言える共通の認識を作りあげるよう努めてきました。
インクリメントは何かできたかよりも、いつ・どういう形でデリバリーするのかを評価します。業務で使ってもらうのに「ちょうどよい」タイミングがあり、業務部署にそう認識してもらうための過程があります。事業部との間に共に解決するという関係性を築いて、プロダクトバックログがインクリメントに変わったときにもっとも効果的に使ってもらえるよう図るのです。
また、成果に結びつけるにはチームメンバーの深いコミットメントも必要になります。指示をうけるだけでは「いいもの」にはなりません。
メンバーのそれぞれの動機やスタイルを尊重したうえで、やみくもに個人の欲求を優先するのではなく、チームの目的とどう一致するかを見いだしてもらうよう工夫しています。場合によってはテストや設計の知識の甘さを問いただすこともありますが、できるだけ共同で解決して実体験から理解してもらえることを原則にしています。
昨年のRSGT2019では、IT部が批難の的から信頼を獲得するストーリーを発表させてもらいました。いま私たちはとある次の大きなステップを目指しています。その過程として、共感をベースとした価値構築に奮闘しています。
いま、共感に基づいたマネジメントが見直されていますが、人のためだけでなく価値を高めるために重要なファクターでもあるということ皆さんと共有できたらと思います
「急にインターン来るとか言われたけど、何すりゃいいんだ？」
「今忙しいから作業手伝ってもらおうかな。。。」
「部門紹介とか、座談会、あとワークとかやればいいかな」
、、、こんなインターンシップしてませんか？
「どんな学生？」「どんな目的？」「何が成功？」分からないことが多いインターンシップは、漸進的に進めるスクラムと非常に相性が良さそうです。
ならばインターンシップもスクラム的にやったらうまくいきそうじゃないですか？
このセッションでは、開発以外の全てがスクラムに見えてしまう「スクラムの奴隷」がインターンシップをスクラムで成功に導いた体験談と、開発以外にスクラムを適用するためにどのように取り組めば良いかをお話しいたします。
Yasunobu Kawaguchi
Teppei YAMAGUCHI
Miho Nagase
