アジャイル開発における見積りについては「アジャイルな見積りと計画づくり」という素晴らしい書籍でその有用性や有効な実践方法が示されています。ここで、あえて問わせていただきます。コンセプトと、見積りのコストについて言及しました。彼が述べたように、見積りには負の側面があることもまた認める必要があるのではないでしょうか。私達のチームでは、これら見積りの負の側面と見積りから得られるものを比較し、見積りすることをやめる判断をしました。以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。この私達のプロセスでは、モブプログラミングが鍵となっています。本セッションでは、私達がどのように見積りをせず開発をしているのか、見積りをやめたチームで何が起こるのか、という事例を紹介し、ソフトウェア開発、特にスクラムにおいての見積りのあり方の議論の一助となることを目的とします。見積りをやめたのか少し見積りの負の側面について触れておきます。私達が考える見積りの負の側面は、以下に集約されます。数値化したことによる、仕事量の最大化(パーキンソンの法則)見積りの難しさソフトウェア開発はそれ自体が複雑で不確実性を含む殆どの場合で経験したことがないことへの対応が必要になるこのため、正確な見積りを行うことが困難もちろん、見積りは負の側面ばかりではありません。見積りの「価値」については、見積り自体に価値があるのではなく、見積りから得られる副次的な情報に価値があると考えられます。見積りから副次的に得られる価値が見積りの労力とバーターしない場合、その価値を別の方法で得られるのであれば、見積り自体をやる必要はないと考えます。スクラムと見積りタイトルの通り、私達はスクラムを実践しています。見積りを行わないプロセスでもスクラムは成立するのか、あるいはこれはスクラムと呼べるのか、という疑問が当然湧いてきます。スクラムガイドには「見積り」という言葉が9回登場します。それぞれを分類すると、スクラムにおける見積りは以下の意思決定を行うための情報であると考えられます。算出に必要スプリントのキャパシティを測る追跡スプリントの進捗状況を把握する見積り自体を行うことなくこれらの意思決定をするための情報が得られるのであれば、見積りをしなくてもスクラムとして成立するのではないか、というのが今回のアイディアです。我々は、以下の方法でこの意思決定を行っています。Agile」において、アジャイルプラクティスは「補助輪」であると表現しました。見積りは今、ソフトウェア開発の「補助輪」といえる段階に差し掛かっているのではないでしょうか。私達のプロセスは完成されたものではなく、日々実験と失敗を繰り返して進化しているものです。AEPから10年、「見積りはソフトウェア開発において必須」という考え方もまた固定概念かもしれません。我々の実践しているソフトウェア開発の形について紹介し、議論できればと思います。「プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。「明確で詳細であれば、見積りも正確になる。「開発チームは見積りに対して責任を持つ。「スプリントのいずれかの時点で、スプリントバックログの残作業を合計する。MinsTalkIntermediate現場コーチとしてScrumでサービス開発しているチームの支援をしていると、よくディスカッションする話題の1つが「プロダクトバックログアイテム(PBI)の価値や成果をどう考えて、どのように扱うか?」というものです。このような話題の時、OutputとOutcomeの話をします。Outputとは、リリースした機能の数や質のことをここではいいます。Outcomeとは、利用者がどう変わったのか?利用者の課題が解決したのか?と利用者視点での効果のようなことをいいます。※Outcomeはビジネス視点からのOutcomeと、利用者視点からのOutcomeの2つに分類されます。上記は利用者視点からのOutcomeのことを書いています。たくさんのPBIをつくって頻繁にリリースしてOutputが増えたとしても、自分達にとっての価値、もしくは利用者にとっての価値(利便さや嬉しさ)といったOutcomeが増えていないとそのプロダクトやサービスを続けていくことはできません。1つずつのPBIの情報に"売上の増える額"や"ユーザー数の増加”を加えているチームもあります。別の現場ではストーリーポイントと同じようなやり方で、仮想の単位を決めて相対的な値をチームで話し合って、どれからやるか?の参考にしています。プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。(ScrumGuide2017より)このセッションでは、"プロダクトバックログアイテムにおける価値の取り扱いのやり方”のいくつかの現場の事例を紹介しつつ、Outcomeについて考えをお話します。みなさんのPBIのOutcomeがよりわかりやすく、より高くなるヒントになればと思います。MinsTalkBeginner世の中でアジャイル開発が一般的になるにつれて、アジャイル開発を支援する「アジャイルコーチ」という職種や肩書を見かけることが多くなってきました。アジャイルコーチとは組織がアジャイルなやり方で成果を出せるようにするために、組織的な観点、技術的な観点、プロダクトの観点などさまざまな観点から支援する役目です。アジャイル開発に慣れていないチームには、アジャイルコーチは必要な存在だと言ってよいでしょう。一方で、アジャイルコーチといえば、「めんどくさい」「マサカリ投げる」「上がった感」「単価が高い」「実際の効果がよくわからない」といったイメージがあります。これらはコンサルティングを始めとした支援系の仕事に対する共通のイメージでもありますが、銀の弾丸思考の表れでもあります(アジャイルコーチがあなたの問題をすべて指摘し、魔法のように解決してくれるわけではなく、あくまで主体はスクラムチームです)。Coach(CTC)で実際にアジャイルコーチングを有償サービスとして提供している現役アジャイルコーチが解説します。MinsTalkBeginnerアジャイル、XP、Scrumは10年くらい前からイベントに出たり、本を読んだり勉強しても、どうにも身につかず。2017年に会社を作って、2019年に自社サービスをリリースして、やっとアジャイルが腹落ちしてきた気がします。このセッションでは、なぜ今までアジャイルが実践できなくて、なぜ今になってアジャイルがわかりかけてきたのか、ということをお伝えできればと思います。MinsTalkIntermediateCI&Tではスクラムマスター(以下SM)のキャリアパスは通常テスター役から始まります。テスターは開発者達と日々タスクを実施するので、開発の流れ、プロダクトの使い方、技術などについて良く知ることができます。SMはプロジェクトマネージャーやプロジェクトオーナーと仕事をすることが多いのでどちらかというと「マネージメント」グループに含まれており、ビジネス要件にしか深く関わることができません。多数の案件を管理するようになると、チームが実際何に困っているか簡単に気づいてあげられない時もあります。お客様と開発チームとの関係性をより良くするためにはどうすればいいのか。どちらにも偏らないように、どうすればバランスを保つことができるか。テスターとして積み上げた知識はSMになった私にどう役立ってるのか。現在勤めてるプロジェクトの経験も通して、テスターからSMになって感じた変化についてお話したいと思います。-フラクタルスプリントとフラクタルチーム-1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。チームはできるだけ解散してはならない。本当にそうでしょうか?私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。これらを支える理論として進化心理学、ダーウィンの進化論などの学術的な視座からアジャイル開発を話します。人間はチームをつくるのか。MinsPanelAdvanced大企業で新規事業を始めるために必要なものはなんだと思いますか?予算ですか?社内政治ですか?そう!違う!そう!プロダクトオーナーやリーンスタートアップの本を読んでも、なかなか教えてもらえないのが「日本企業におけるカネと政治」。エンジニア出身の方も、マーケティング出身の方も、プロダクトデザインやUXの方も、等しく苦労するポイントであろうと思います。プロダクト開発はうまくできても、それ以外のところで泥沼にハマってしまいがちな大企業の皆様に、うまくサヴァイヴして人生をときめくためのヒントをお伝えできればと考えております。そのために、実際に大企業で新規ビジネス開発の仕組みづくりに携わるみなさんから、戦略やヒントやマサカリをいただきます。したらちょっと心に棘が刺さるかもしれませんので、しっかりと心のご準備をお願いいたします。発表者は、絹川達也さん(楽天)、太田敦士さん(NTT西日本)、そして楽天技術研究所や楽天テクノロジーカンファレンスを設立から育ててこられた森正弥さん。いずれもご本人が新規サービス/事業を手掛けるだけでなく、仕組みづくりや組織づくり、メンタリングなども携わられてきたみなさまです。MinsTalkIntermediateアジャイルでの大物でありScrumを考案して世界に広げた人物。卒業した元パイロットです。軍隊は一番入れ替わりが激しい組織です。今日入隊する人がいて、その反面退役する人もいます。退役の方が入隊より多く、総員の数がマイナスになることもあります。入れ替わる時の階級もバラバラで、一般兵士が入隊してきても、例えばベテラン士官が退役する場合もあります。いう状況の中でも、全てのメンバーを即戦力に作る極限のアジリティーを発揮し、最高のパフォーマンスを保つのが軍隊の最大課題であり、存在理由でもあります。私はそこで元陸軍将校として4年間勤め、300名の部下を纏めながら、毎日戦闘力の向上のために資源管理・訓練の計画・実施などに力を入れていました。チーム(ないしは会社)そしてアジャイルプロセスは、軍隊と特に違いはありません。入れ替わりは激しく、生産性のために中途はもちろん新卒に対しても即戦力になれる人材を求めています。チームなど組織に対しても、一定のパフォーマンスを出すことが求められています。制限された状況の中でも、どうしたら常に最大のパフォーマンスが発揮できるか。軍隊ではどういう風にしていて、それをどうやって今のチーム・組織に活かせるか。私の経験を持ってご提案させていただきます。Japanese.---アジャイルな開発においては、アナログなツールもデジタルなツールも大切な活動のための友達です。このセッションでは、アジャイルもテクノロジーも成熟してきたなかでうまれ、乱立されてきたデジタルなツールについて、基本に立ち返ってどんなツールが求められているか、どんなツールをあなたの現場で選べばいいのかを考察していきます。使うツールならば自分たちのための、自分たちの創り出す価値のためのものを選びましょう。ツールから学ぶバリューチェーンのような内容にするつもりです。本セッションでは特定のツールにフィーチャーすることはありません。MinsTalkAdvancedあなたのチームはいつ死にますか?スクラムはチームワークのためのフレームワークです。スクラムでは、安定したチームが成功するための前提条件として紹介されることが多いです。Patternsの1つになっています。安定したチームは本当によいチームなのでしょうか?私たちのチームは、スクラムやモブプログラミングを通して自己組織的なチームになりました。Unlearnを自分たちの活動に組み込んで、学習するチームになりました。スタートアップしたプロダクトも成長軌道に乗せることが出来ました。そのチームは、プロダクトの終焉を乗り越え、さらには会社をも越えました。TEAMだったのです。私たちのチームにとってはプロダクトの終焉も転職もチームの死にはつながりませんでした。TEAM(同じチーム)ではなく、生物のように変化し続けることができるチームです。私たちは会社を越えた後も、変化と向き合い生物的チームを目指して活動を続けています。あなたのチームはいつ死にますか?このタフクエスチョンの答えはどの教科書にも載っていません。チームの死を考えることで、どう生きるかが定まり、どうチーミングすればよいのかが見えてきます。一緒にチームのライフサイクルについて考えてみましょう。MinsTalkBeginnerふくおかフィナンシャルグループ(FFG)では、2018年4月、DevOps・アジャイル開発を実践していくための組織が立ち上がりました。昨今厳しいと言われる銀行業界でイノベーションを起こしていくための組織です。2018年5月にゲーム会社から銀行へと異色の転職で入社以降、このアジャイル開発チームに携わってきました。古くからある大きな企業でのアジャイル開発を進めていくには、技術的な面・組織的な面で非常に多くの問題が存在していました。そもそも外注開発しかしたことのない組織が内製開発に取り組むということで、その問題の大きさは想像に難くないでしょう。実際、前職とはかけ離れた環境やフローが存在し、多くのカルチャーショックにぶちあたってきました。このセッションでは、そんな組織の中で、ゼロからアジャイル開発を進めてきた1年半の歴史を余すことなく紹介していきたいと思います。取り組んできたこと、失敗したこと、成功したこと、たくさんあります。地銀という古い体制の組織・規制の厳しい金融業界、そんな世界で経験してきた内容が、少しでもみなさんの今後に役立つことができれば幸いです。MinsWorkshopBeginnerスクラムショーワークショップは、スクラムの説明をショー(寸劇)形式で行うワークショップです。このワークショップを通じて、参加者はスクラムの基本を体験・学習できます。スクラムショーワークショップは、yycr2019(アジャイルコーチとスクラムマスターの宴、通称:よなよなコーチングリトリート)で生み出されたワークショップです。「短い時間でアジャイルを知るようにしてほしい」というニーズに応えるために、最大2時間でアジャイル・スクラムの理解を高められるワークショップをみんなで作りました。会社の中で展開するために、できるだけ準備が少なく済ませたいという要望にも応えています。皆さんも、スクラムショーワークショップを実施してみましょう!紹介動画はこちらから!詳細はこちらの記事をご参照ください。MinsTalkIntermediate我々LINEのSETチームは、テスト自動化の実現・推進だけではなく、プロダクト開発チームのプロセス改善・DevOpsの推進・技術戦略の策定・実施といった活動を、全社的に行っています。一連の活動に際して我々は、様々な技術・ツールとアジャイルプラクティス・マインドセットとを組み合わせ、日々実験を繰り返しながら、ビジネス的成果へとつなげています。当セッションでは、特定の開発チームから組織横断活動までに活用できる、技術とアジャイルの組み合わせ方を、LINEでの実例をもとに、参加者の皆様が現場に持ち帰って試せる形でご紹介します。当セッションは、SETチームをこれから作ろうとされている会社・担当者の皆さま向けの具体的なアプローチ集とすることも想定しています。MinsTalkBeginnerUX屋さんは言います「ユーザーテスト(ユーザビリティテスト)は製品の利用品質を目覚ましく向上する」と。専門家に頼むと結構な金額の請求書が届くかもしれませんし、社内でやると結構な手間がかかるかもしれません。結局、まだ「やったことがない」「見たことがない」という人が多いのかもしれません。そこで、このセッションではスマホアプリを題材にしたユーザーテストを会場で実演します。「実演」と言っても大げさなものではありません。1その場にいる人で、2その場にある機材を使って、3約30分で完了する(ただしセッションは45分)ーーという「即席」スタイルです。「UXとは?ユーザーテストとは?」という小難しいプレゼンテーションを聞いたり、その分野の本を読んだりするのも悪くありませんが、まずは自分の目で見て、自分で価値を判断してみてはいかがでしょうか。意外と気に入るかもしれませんよ。そんな状況の中、チームがユーザーにより価値を届けやすくするために職能別部署は解体されチーム主体の新組織になりました。新組織の狙いは以下の4つです。主体的にキャリアを作れるように異動をカジュアルに組織変更の中で部長の役割は分割され再割当てされました。採用・予算などはチームに移り、異動は各メンバーに移り、給与評価はそれを受け持つ組織運営チームが新設されました。組織変更をして8ヶ月、様々な変化が起きました。やって意思決定するか議論するチーム。どんな人を採用したいか、そもそも人を増やすべきなのかを議論するチーム。上長がいなくなり色んな人と1on1し始めるメンバー。活発になる他職能/他チームへのお試し異動。チーム内でオープンに議論されるようになった問題。このセッションでは部長がいなくなった組織で起こったことを紹介します。MinsTalkIntermediateこんにちは。それぞれ仲間がいる開発組織で、25人くらいのグループのマネージャーをやっています。ベースは仙台ですが、月に2回くらいは東京に行っています。私達は、楽天市場の開発を行っています。2019年6月にリリースした新機能開発では、もともと縦割り組織だったビジネス・デザイン・開発のそれぞれのステークホルダをワンチームにまとめ、日々数万店舗様が使ってくれるような顧客満足度の高いものを作ることが出来ました。Team」の考え方でした。このおかげで、ともすると敵対関係みたいになってしまいがちな三者が、顧客に価値を届けるぞ!良いもの作るぞ!と同じ方向を向きつつそれぞれが強みを発揮するようになりました。最初からうまくいったわけではなく、色々な書籍や文献、先達の知恵に助けてもらいつつ、もがき苦しんだ結果たまたま発見したものです。セッションの内容は、うまくいったぜ!という過程ではなく、苦労話が多くなると思います。このセッションが、大企業の中で組織改善に悩むいろんな方々のヒントになったら良いなと思います。私自身もまだまだ悩み中なので、一緒に旨い酒が飲める仲間が出来たら嬉しいです。変化(変革)を「見える化」する全員で同じ方向に向かっていくために必要なことあなたが組織の変化・変革に関わり、チェンジ・プログラムを開発、実行するためのより効果的な方法を探しているのであれば、リーン・チェンジエージェントになりましょう!リーン・チェンジエージェントとして、あなた自身のチェンジ・フレームワークを構築する方法や、変化の影響を受けるステークホルダーからどう支持してもらえるかを様々な視点から考え学びます。Management(チェンジマネジメント・ゲーム)」を行う予定です。後半はグループでチェンジ・キャンバスを作成します。ディスカッションを通して変化(変革)への戦略を考えていきます。キャンバスから見えてくる変化(変革)への課題とどう向き合い実践していくかを学び、リーン・チェンジマネジメントを体験してください。ConfEngine。