Scrum for Enterprize お客様と一緒に前を向くスクラム開発

受発注という契約で結ばれるお客様とベンダー。
時に岩よりも固く、時にガラスのように脆いその関係性では、スクラム開発を進めることはできないのでしょうか?

いいえ。そんなことはありません。

いま私たちは、ベンダーの立場でお客様と一緒になってスクラム開発を進めています。
今では7人規模のチームで日々開発を行い、継続的にプロダクトをリリースしています。
日々開発をする中でメンバー自身の成長、そしてチームの成長も実感しています。

しかしそこに至るまでには、数多くの課題や悩みがありました。
なにせ、お客様はスクラム開発が初の体験、私たちのチームもスクラム開発を経験したメンバーは1人の状態からのスタートでしたから。

今回は、スクラム開発を検討しているベンダーの方へ参考になるように、私たちがお客様と今までどのようにスクラム開発を進めてきたのか、プロジェクトのスタートから今日までの流れをたどりながら、その手法や失敗例などをお話ししたいと考えています。

主にお話ししたいことは以下のような内容です。

・提案からスクラムを掲げる
・要件定義は大まかに決めていく
・悩めるプロダクトオーナーと共感する
・受動的なチームから自発的なチームにするためには
・日々のチームの活動をサポートしてくれるツールや手法
・私が考えるエンタープライズ向けのスクラムの実現条件

このお話でスクラムをやってみようと思う方が一人でも増えるような内容にしたいと考えています。

 
 

Outline/Structure of the Talk

  • 提案からスクラムを掲げる
    • スクラム開発に興味があるお客様と組む
    • スクラム開発のデメリットをはじめに説明する
  • 要件定義は大まかに決めていく
    • 要件定義のゴールはプロダクトバックログの作成
    • 要件定義に有効なユーザーストーリーマッピングとペーパープロト
  • スプリント0で開発の土台を作る
    • 開発の土台を作るための開発準備期間
    • スプリント1から開発スピードを上げるためにスプリント0で残すもの
  • 悩めるプロダクトオーナーと共感する
    • お客様の悩みを聞いて一緒に考える。
    • プロダクトバックログはみんなで更新する
    • 役割は明確にして時には厳しく接する
  • 受動的なチームから自発的なチームにするためには
    • チームを信頼する。メンバーを信頼する。
    • 話しかけ、問いかけ、背中をソッと押す。
  • 日々のチームの活動をサポートしてくれるツールや手法
    • プロダクトバックログの管理からCI/CDまでこなす強力ツール「Azure DevOps」
    • スプリントのPBIはマイルストーン表を使う。
  • 私が考えるエンタープライズ向けのスクラムの実現条件
    • お客様とベンダーが対等であること
    • 動きやすい契約を交わすこと
    • お客様と一緒に同じ目線で前を向くこと

Learning Outcome

・お客様とスクラム開発をするときの流れがイメージできるようになります。

・お客様とスクラム開発をするためのヒントが得られます。

Target Audience

スクラム開発を行いたいベンダーの方、ベンダーとスクラム開発を行いたい企業の方

schedule Submitted 1 year ago

  • Kazutaka Matsusaki
    keyboard_arrow_down

    Kazutaka Matsusaki / 河野 彰範 - アジャイルな組織を創っていくには?地銀で取り組むアジャイルな組織創り

    45 Mins
    Talk
    Beginner

    ふくおかフィナンシャルグループ(FFG)では、2018年4月、DevOps・アジャイル開発を実践していくための組織が立ち上がりました。
    昨今厳しいと言われる銀行業界でイノベーションを起こしていくための組織です。

    2018年5月にゲーム会社から銀行へと異色の転職で入社以降、このアジャイル開発チームに携わってきました。

    古くからある大きな企業でのアジャイル開発を進めていくには、技術的な面・組織的な面で非常に多くの問題が存在していました。
    そもそも外注開発しかしたことのない組織が内製開発に取り組むということで、その問題の大きさは想像に難くないでしょう。
    実際、前職とはかけ離れた環境やフローが存在し、多くのカルチャーショックにぶちあたってきました。

    このセッションでは、そんな組織の中で、ゼロからアジャイル開発を進めてきた1年半の歴史を余すことなく紹介していきたいと思います。
    取り組んできたこと、失敗したこと、成功したこと、たくさんあります。
    地銀という古い体制の組織・規制の厳しい金融業界、そんな世界で経験してきた内容が、少しでもみなさんの今後に役立つことができれば幸いです。

    • アジャイル組織の変遷
    • 現行ルールのしがらみとの闘い
    • アジャイル開発を少しずつ組織に浸透させていく方法
    • 組織を拡大していくための対内・対外的な取り組み
    • 拡大していく組織で発生した問題
    • 成果を出し続けていくための組織やチームの意識改革
  • Woohyeok Aaron Kim
    keyboard_arrow_down

    Woohyeok Aaron Kim - 【元士官が語る】軍隊組織からみる、これからのアジャイルのあり方

    45 Mins
    Talk
    Intermediate

     アジャイルでの大物でありScrumを考案して世界に広げた人物。ジェフ・サザーランド氏は実は、米国陸軍士官学校を卒業した元パイロットです。

    軍隊は一番入れ替わりが激しい組織です。今日入隊する人がいて、その反面退役する人もいます。退役の方が入隊より多く、総員の数がマイナスになることもあります。入れ替わる時の階級もバラバラで、一般兵士が入隊してきても、例えばベテラン士官が退役する場合もあります。

     しかし、こういう状況の中でも、全てのメンバーを即戦力に作る極限のアジリティーを発揮し、最高のパフォーマンスを保つのが軍隊の最大課題であり、存在理由でもあります。私はそこで元陸軍将校として4年間勤め、300名の部下を纏めながら、毎日戦闘力の向上のために資源管理・訓練の計画・実施などに力を入れていました。

     チーム(ないしは会社)そしてアジャイルプロセスは、軍隊と特に違いはありません。入れ替わりは激しく、生産性のために中途はもちろん新卒に対しても即戦力になれる人材を求めています。チームなど組織に対しても、一定のパフォーマンスを出すことが求められています。

    制限された状況の中でも、どうしたら常に最大のパフォーマンスが発揮できるか。

    軍隊ではどういう風にしていて、それをどうやって今のチーム・組織に活かせるか。私の経験を持ってご提案させていただきます。

  • Yukio Okajima
    keyboard_arrow_down

    Yukio Okajima - 【完結編】総売り上げ:35,400円 ~ 受託エンジニアが自社サービスのPOをやって学んだこと Total sales: 35,400 yen ~ What the contract engineer learned from the experience of Product Owner

    45 Mins
    Talk
    Beginner

    永和システムマネジメントはソフトウェアの受託開発を生業にしていて、私もその最前線で25年やってきました。 そんな私が企画し、プロダクトオーナーとして関わった自社Webサービスが、数ヶ月前にひっそりと終了しました。

    「ニーズがなかったね」の一言で済ますにはもったいなく、一体何が悪くてそこから何が学べるのか? オーナーシップって何なんだろう?組織との付き合い方は?これからのエンジニアに求められるマインドって何?といったことを、自分なりに徹底して追及した結果を共有させてください。

    The web service that I planned and worked as a product owner closed quietly a few months ago.

    What is wrong and what can you learn from it? What is ownership? How do you interact with your organization? What kind of mind is required of engineers in the future?

    Please let me share the results that I thoroughly pursued.

    ※ 「明日の開発カンファレンス2019」でお話させていただいたことを全面ブラッシュアップし、後日談も含めた【完結編】となります。

  • Masakazu Yoshikawa
    keyboard_arrow_down

    Masakazu Yoshikawa / Ryuichi Honda / Stefan Nüsperling - エンジニアの大量採用。退職届け取り下げ etc,,, Management3.0を実践投入して様々な成果を出している2人による、Management3.0ワークショップ

    100 Mins
    Workshop
    Beginner

    退職希望者の退職届け取り下げ。

    エンジニアの大量採用成功。

    やる気のない社員のマインドセットを変えた。

    変革する気がない組織にアジャイルコーチを投入できた。

    これがManagement3.0のプラクティスやツールを導入して僕らが半年で得た成果です。

    近年、アジャイル界隈を中心に広がりを見せている。Management3.0

    Management3.0には、仕事の改善、高性能のチーム作りや、やりがいのある仕事を作るといった能力を引き出すことに有効なツール、ゲーム、プラクティスが存在します。

    それらは、どれもライトウェイトで導入が簡単かつ、確実に成果が出ます。

    (具体的な成果は上記参照)

    が、日本では学ぶ人は増えているが、実践している人が少ないのが現実。

    そこで、自分の組織、家庭etc... 日本で2番目にManagement3.0実践投入している2人(株式会社クオリティアの吉川誠一、株式会社マリエッタの本田竜一)による、事例紹介のトーク実践者視点によるワークショップを行います。

    Management3.0を日本で展開する、NuWORKS の Stefan Nüsperling氏による、簡単なManagement 3.0の紹介やトークセッションも行います

  • Alex Sloley
    keyboard_arrow_down

    Alex Sloley - Liberating Structures... 36 tried and true facilitation techniques to amp up your org's collaboration

    Alex Sloley
    Alex Sloley
    Alex Sloley
    schedule 1 year ago
    Sold Out!
    100 Mins
    Workshop
    Beginner

    The communication tools of Liberating Structures will teach you how to facilitate the discussions your org needs. I am going to demonstrate how to use these techniques in the workshop. And all the attendees are going to be fully immersed and ready to wield their new knowledge the very next day at work.

    Come learn how to help your team(s), org(s), and company(ies)!!!

    For more information, watch my video at http://youtu.be/UNOjqMUv8h0

    A version of this workshop that was presented at Agile Tour Sydney 2016 is at http://bit.ly/2f4Bie8

  • Yuichi Tsunematsu
    keyboard_arrow_down

    Yuichi Tsunematsu - 「1プロダクトをみんなで作る」会社での大規模スクラム(LeSS)導入

    Yuichi Tsunematsu
    Yuichi Tsunematsu
    Manager
    Retty Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    Retty株式会社は「信頼出来る友人や好みの合う人から自分にぴったりなお店を探す」グルメサービスRettyの開発・運営を行なっております。内部システムはレストランを見つけるtoC向けのWeb、スマートフォンアプリ、レストラン側が利用するtoB向け管理システムに大別できますが、会社としてたった1つの多くのユーザに利用されるサービスを手がけています。

    サービスと会社が大きくなった結果、全社でスピード感とアジリティを追求していくには開発プロセスの見直し、そして組織構造の見直しが必要だと考えるようになりました。

    本講演では1チームから始まったスクラム開発をどう広げ、LeSS(Large Scale Scrum)を採用した大規模スクラム体制に移行できたのか、具体的な課題とその対処を交えて紹介します。

  • Yoshiki Iida
    keyboard_arrow_down

    Yoshiki Iida - 自己組織化あるいは組織の緩慢な衰退

    Yoshiki Iida
    Yoshiki Iida
    Engineer
    Loglass Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    スクラムマスターもリーダー、マネージャーも組織が自ら前に進んでいけるようにする支援を行います。

    しかし、現実に待ち受けているものは、異なる論理、異なる価値観、異なるスキル、異なる権限の間での苦悩です。

    多くの教科書で「自己組織化」というキーワードが出てきますが、私はこれを理想だと思いながらも到達することのできないアキレスと亀的な状態だと思っています。しかも、気を抜けば到達できないだけでなくどんどん遠ざかってしまいます。

    しかしながら、それに向き合うことこそがスクラムマスターやリーダー、マネージャーの存在意義なのではないかとも思っています。

    このセッションではそんな「自己組織化」について捉え直し、向き合い方を整理する場にできればと思います。

    具体的には、私が見てきた組織の変遷をベースに、勝手に自己組織化していた少人数開発チームから、組織として統率が必要になる30名規模になるまでの過程で起きたことやトライしていることをお話できればと思います。

  • Akiko Iwakiri
    keyboard_arrow_down

    Akiko Iwakiri / Toshihiro Ichitani / Tomoyasu Ishii - 経営者に聞く!-アジャイルと経営ー開発の現場は変わりつつある。事業サイド、経営陣はどうか?

    45 Mins
    Panel
    Beginner

    そもそもの思い

    RSGTの参加者が年々増えていることからわかるように、この間、スクラムに舵を切る開発現場が急増しています。

    波に乗って私も、スクラム的プロダクト開発手法を学ぼうと、2019年3月に、認定プロダクトマネージャー研修を受講しましたが、POの役割が広すぎて、定義していないのと同じだと感じました。また、プロダクトオーナー向けのドキュメントが具体的ではなく、事業サイドの方が、赤いピルを飲むために、手がかりがほとんどないように感じました。

    このギャップの前に、経営者はどんな手をとっているのか?というのが、このセッションを考えるきっかけでした。

    日本の経営方針は「ヒト」「モノ」「カネ」、アジャイルは「文化」が第1義。

    ナイスな開発チーム、プロダクトオーナーが自然と出てくる会社の文化をどう作っていったら良いのか、スクラムチームやアジャイル開発チームを抱える会社の経営方針は、どうきめるのかなど、本や研修には出てこない話を、デベロッパーから経営者になった方々に、この場でお話しいただき、彼らがヒリヒリした日常から何を気づき判断していったのか、お話を引き出せたらと思ってます。

    45分1本勝負。ぜひ、チャンスをいただけるとうれしいです。

    また、この場で聴いてみたいことなどあれば、コメントいただけるとうれしいです!

    登壇者

    市谷 聡啓

    ギルドワークス株式会社 代表取締役/株式会社エナジャイル 代表取締役/DevLOVEコミュニティ ファウンダー

    サービスや事業についてのアイデア段階の構想から、コンセプトを練り上げていく仮説検証とアジャイル開発の運営について経験が厚い。プログラマーからキャリアをスタートし、SIerでのプロジェクトマネジメント、大規模インターネットサービスのプロデューサー、アジャイル開発の実践を経て、ギルドワークスを立ち上げる。それぞれの局面から得られた実践知で、ソフトウェアの共創に辿り着くべく越境し続けている。訳書に『リーン開発の現場』(共訳、オーム社)、著書に「カイゼン・ジャーニー」「正しいものを正しくつくる」がある。

    石井 智康

    石井食品株式会社 代表取締役社長執行役員

    ソフトウェアエンジニアとして、コンサルティング会社にて大企業の基幹システムの構築やデジタルマーケティング支援に従事。2014 年よりフリーランスとして、アジャイル型受託開発を実践し、ベンチャー企業を中心に新規事業のソフトウェア開発及びチームづくりを行う。2017 年から祖父の創立した石井食品株式会社に参画。地域と旬をテーマに農家と連携した食品づくりを進めている。現在のライフスタイルに合った「豊かな食」のあり方を模索中。認定スクラムプロフェッショナル。アジャイルひよこクラブ幹事。

    もう1名調整中

    進行役:岩切 晃子

    株式会社翔泳社取締役 / コンピュータ出版販売研究機構会長

  • Daisuke Kuroda
    Daisuke Kuroda
    PO
    -
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    開発を思いっきり楽しもう!
    開発に熱狂できる「場」を作ってみました

    そこで開発チームと一緒に思いっきり「暴走モード」をやってみた実例です。

    ★注意事項★

    これはスクラム開発の事例ですが、「お手本」となるやり方ではありません。正しいスクラムを継続してきたチームで、一時的に「暴走モード」を試行したらどうなったかを、みなさんに共有する内容です。

    概要

    完成してきたスクラムチームに対して、スクラムの営みを一部取り外してでも開発速度を優先させてみた内容です。
    チームを強制的に「暴走モード」に突入させます。
    内容は非常に危険なので、普通はマネしないようお願いいたします☆彡
    開発速度を200%まで挑もうとした結果、大幅に上回るxxx%になっています。
    さらに、開発チームからは「もう少し余裕がありますけどw」と言ってくる事態に。
    暴走モード終了後の振り返りFun/Done/Learn。というチャレンジをした内容です。

    スクラムマスターの名言「バーンダウンが早すぎるから、みんなちょっと休憩しよ!」

    背景

    プロダクトオーナー(発表者)と開発チーム2チーム(スクラムマスター1人ずつ)で開発しています。
    1年程度スクラム開発している中で、POはふと気づきました。
    なんだか最近バーンダウンの調子悪そうだけど

    • チームの改善が足りない!という内容は、このセッション外です
    • チームの苦しみや嘆きの現れ!とPOが思って取り組んだ内容がこのセッションです

    スクラム開発はツラいのか?実は別の所にツラさがあるかもしれません。

    チャレンジした結果

    「みんな楽しすぎて、このチームから離れられないと思います」(開発チーム内の20代エンジニア談)

    開発速度を求めたら、チームが劇的に楽しく開発できるようになった。何が起こったんだ・・・

  • Nobuaki Miura
    keyboard_arrow_down

    Nobuaki Miura - プロダクト開発に足りなかったピースとしてのマネージャー

    Nobuaki Miura
    Nobuaki Miura
    VPoE
    Syoya, Inc.
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Intermediate
    僕らのチームはScrumでプロダクトを開発しています。

    Scrumには プロダクトオーナースクラムマスター開発チーム の3つのロールがあり、
    各ロールのメンバーが協働することでプロダクトを作り上げています。

    今までいくつかのチームでプロダクト開発を行ってきましたが、
    上記のロールがプロダクト開発に 必要な全て であったことは一度としてありませんでした。

    いつも何かあとちょっと足りないと感じていた僕が、
    マネージャーとしてチームに加わることで実現出来たことがいくつもありました。

    マネージャーというロールがすべきことはScrumガイドには書かれていません。
    エンジニアリングマネージャーという言葉が世の中に広く知られるようになった今も
    マネージャーが「何をマネジメントするべきなのか」は不透明さを感じます。

    ですが、求められていることは「チームを機能させる」という非常にシンプルな結果です。
    色々なトレードオフを検討して、最良だと思う手を打つことを求められます。

    また、これはマネージャーだけが知っていれば良いものではなく、
    チームメンバーからも求められるべきことだと思っています。
    • Scrumでプロダクト開発を進めるためにマネージャーができること
    • 開発チームを機能させるためにマネージャーができること
    • 物事を進めるためにマネージャーができること

    まだまだ色々な要素があると思いますが、
    10ヶ月間で最高のチームと最高のプロダクトを作るために
    マネージャーとして行ってきたことをお話します。
  • Shigeru Tatsuta
    keyboard_arrow_down

    Shigeru Tatsuta - マネージャーレスなスクラム開発を実現してみた気づき

    Shigeru Tatsuta
    Shigeru Tatsuta
    System Engineer
    SoftBank
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

     我々が所属するIT本部は、主にソフトバンクの通信事業を支えるITシステムの開発、保守、運用を担っています。通信事業は社会的なインフラですので、これまではキャリア品質のシステム構築のプロセスとしてウォーターフォールが中心でしたが、加速していくビジネス要件にスピーディに対応するために、2 年前からアジャイル開発に取り組んでいます。

     ソフトバンクの IT 本部も日本の伝統的な大企業のように、深いマネージャー階層となっていまが、比較的早期に成功体験を達成することができた一方で、それ以降は伸び悩みを感じていました。そして、いくつかの試行錯誤を経て、現在はマネージャーレスな組織で、スクラムマスターすら必要としない真に自己管理されたチームを目指してアジャイル開発を実践しています。

     このセッションでは主に LeSS や社外の有識者との交流からヒントを得て、日本の伝統的な大企業におけるマネージャーとアジャイル導入の課題と、アジャイル開発にとって好ましいマネージャーと好ましくないマネージャーについて、また現在の我々の取り組みについて、事例を踏まえつつ、我々の気づきを共有できればと思います。

  • Yoshitaka Hirano
    keyboard_arrow_down

    Yoshitaka Hirano - 1年半スクラムとモブプログラミングをやってみた話

    20 Mins
    Talk
    Beginner

    モブプログラミングを聞いたことはあるけどやってみたことがないという話や、やってみたけどあまりうまくいかなかったという話はよく聞きますが、少なくとも僕の周りではうまくいっている例があまり聞かれません。

    1年半前にスクラムとモブプロを同時に始めたのですが、実際の開発の現場において、部屋の構成、内容、人数、能力差など、うまくいったパターン、失敗したパターンなど気づいたところを共有できればと思います。

    また、その中で気づいたバックログの切り方などスクラムに関することもお話できればと思います。

  • Yuichiro Yamamoto
    keyboard_arrow_down

    Yuichiro Yamamoto - 共感がインクリメントの価値を高める

    20 Mins
    Talk
    Intermediate

    こんにちは。2年前に転職してEC通販/製造企業のIT部門長をしています。元アジャイルコーチだった私は早速スクラムを導入し、持ち前の鈍いマサカリと役職権限をふりかざして覇道系プロダクトオーナーとして切磋琢磨しています。

    “システムの価値は、その機能ではなく、どう使われるかで決まる”
    どこで読んだか聞いたかことか忘れましたが、私はずっと意識してきました。

    私が就いたIT部は、つぎはぎシステムの補修とそれが吐き出す壊れたデータを直すことで日々を追われていました。
    やらなければならないことが多すぎるので、できるだけ手間をかけずに要望を満たす必要があります。しかし機能を削るだけでは利用部署の不満は増します。
    私は、十分に機能するものを小さく作るために「どう使うか」に注目することにしました。そして、そのために利用部署との間に「これはいいものだ」と言える共通の認識を作りあげるよう努めてきました。

    インクリメントは何かできたかよりも、いつ・どういう形でデリバリーするのかを評価します。業務で使ってもらうのに「ちょうどよい」タイミングがあり、業務部署にそう認識してもらうための過程があります。事業部との間に共に解決するという関係性を築いて、プロダクトバックログがインクリメントに変わったときにもっとも効果的に使ってもらえるよう図るのです。

    また、成果に結びつけるにはチームメンバーの深いコミットメントも必要になります。指示をうけるだけでは「いいもの」にはなりません。
    メンバーのそれぞれの動機やスタイルを尊重したうえで、やみくもに個人の欲求を優先するのではなく、チームの目的とどう一致するかを見いだしてもらうよう工夫しています。場合によってはテストや設計の知識の甘さを問いただすこともありますが、できるだけ共同で解決して実体験から理解してもらえることを原則にしています。

    昨年のRSGT2019では、IT部が批難の的から信頼を獲得するストーリーを発表させてもらいました。いま私たちはとある次の大きなステップを目指しています。その過程として、共感をベースとした価値構築に奮闘しています。
    いま、共感に基づいたマネジメントが見直されていますが、人のためだけでなく価値を高めるために重要なファクターでもあるということ皆さんと共有できたらと思います