経験ゼロからはじめる!10年以上続くプロダクトのアウトカム創出戦略

location_city Osaka schedule Jun 26th 10:50 - 11:35 AM place 仙台 people 3 Interested

アジャイルの浸透によってプロダクトがアウトカムに目を向けることの重要性が認識されるようになりました。では、従来型の開発プロセスで10年以上開発を続けてきたプロダクト開発チームは、どのように取り組めばアウトカムに目を向けたアジャイルな開発に転換できるのでしょうか?

今から2年前、10年以上の歴史を持つプロダクトが新たなビジネス領域に参入するためにチームを再結成して新機能を開発していくことになりました。正解がないレッドオーシャンのビジネス領域に飛び込んだ我々はまず開発プロセスをアジャイルに転換する必要性を感じてスクラム開発を取り入れようと試行錯誤していました。そんな中、関西でアジャイルコーチとして活動されている中村洋さんと秋元さんが開催していた相談会をたまたま見つけて相談しました。そこでホワイトボードの中央に書かれた言葉が「アウトカム」でした。

何のためにプロダクト開発をアジャイルにするのか?開発プロセスを変えてアウトプットを増やすだけではなく、ビジネスの成果=アウトカムにつなげなければ我々の課題は解決しないと気付かされました。「アウトカムは何か?」を問いかけ続けてプロダクトを成長させていくことがアジャイルの本質だと気付きました。

アウトカムを得るためにはプロダクトとその顧客をよく知る人の存在が重要だと考えました。そこで、チームで一番のベテランエンジニアが経験ゼロからプロダクトマネジメントを担当することになりました。そこから1年間、まずは開発チームにスクラムを取り入れて、新体制のアウトプットを安定させる事に取り組みました。その間にプロダクトマネージャーはスクラムのプロダクトオーナーとしての振る舞いを学びました。そして2年目、プロダクトのアウトカム創造をチーム目標に設定して本格的にプロダクトマネジメントに取り組みました。

2年前の再結成からチームのマネジメントを担当しているエンジニアリングマネージャーと、自身も新たなステージへ飛び込んでチャレンジしているプロダクトマネージャーが、アジャイルを取り入れてプロダクトのアウトカム創造に試行錯誤してきたチームの取り組みについてそれぞれの視点でお話しします。

 
 

Outline/Structure of the Talk

エンジニアリングマネージャー(EM)のパートとプロダクトマネージャー(PM)のパートに分けてお伝えします。

  1.  私たちがプロダクトアウトカム創造に取り組むきっかけ by EM
    • プロダクトと組織について
    • アジャイルコーチへの相談
    • チームへのスクラム導入
  2. ベテランエンジニアのプロタクトマネージャーとしての再出発 by PM
    • エンジニアからプロダクトマネージャーになるまで
    • プロダクトオーナーとしての取り組み
  3. プロダクトアウトカム創造の取り組み by PM
    • スプリントレビューの導入
    • 製品ターゲットと重要指標の設定
    • プロダクトの利用状況把握
    • 競合プロダクトの把握
    • ドッグフーディング
    • 製品ロードマップの策定
  4. 今後の展望 by EM & PM
    • チームとプロダクトのロードマップ
    • プロダクトマネージャーの育成計画
    • 新たに見えてきたプロダクトマネジメントの課題とチャレンジ

Learning Outcome

  • アウトカム視点でのプロダクトマネジメントの取り組み方
  • 従来型の開発プロセスからアウトカム創出の開発プロセスへの転換のさせかた

Target Audience

スクラムチームのプロダクトオーナー、プロダクトマネージャー、エンジニアリングマネージャー

Prerequisites for Attendees

  • アジャイルの原則やスクラムのルールを知っている
  • プロダクトマネジメントについての基本的な知識がある
  • 何年も継続しているプロダクトの開発現場のことを多少知っている

 

Slides


schedule Submitted 2 months ago

  • Michael Migliacio
    keyboard_arrow_down

    Michael Migliacio - 「モンダイ」が現れた!ゲームでアジャイルを練習しましょう!

    20 Mins
    Talk
    Beginner

    プロダクト開発は難しいですよね。コミュニケーションとスキルがとても必要です。よくストレスいっぱいあります。

    でも、もしプロダクト開発がゲームだったら・・・

    コーチとして、開発チームと仕事を面白くなるためにたくさん実験を作りました。

    そのプレゼンには、アジャイルか開発を楽しくなるコツとゲームを紹介します。

  • Shigeo Konno
    keyboard_arrow_down

    Shigeo Konno - なんちゃってアジャイルコーチが、コーチングを受けて気づいたことを共有します

    Shigeo Konno
    Shigeo Konno
    Agile coach
    NEC
    schedule 3 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    アジャイルでは、なぜ支援者がトレーナーではなくコーチなのか?
    どっかに引っかかりを感じながら、でも、なんとなく見ないふりをして、アジャイルコーチのマネごとをしてきました。
    アジャイル支援サービスを構築して、販売して、徐々にお客さんからも評価いただくうちに、
    自分がやっていることが本当にアジャイルコーチなのかに自信を持てなくなってきました。

    ある日、流石に見ないふりが苦しくなって、
    コーチを探し始めたら、わざわざ時間をとってたくさんのコミュニティの仲間が相談に乗ってくれて
    スーパーコーチのAkiさんにたどり着きました。

    現時点では導入となる6回のセッションが終わった段階、
    旅の途中ですが、同じもやもやを持っている方に何かの助けになればと思って、自身の体験を共有します

    ※発表内容は個人の主張・主観であり、所属している組織とは関係ないものになります

  • Kei Nakahara
    keyboard_arrow_down

    Kei Nakahara - 老舗メーカーにみんなでアジャイルを導入してみました ~「俺がやる!」から「みんなでやる!」に至るまで~

    Kei Nakahara
    Kei Nakahara
    Manager
    コニカミノルタ(株)
    schedule 3 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    既存の組織体系やマインドが色濃く残る老舗メーカーで、健全なソフトウェア開発を実現できるよう全社的にアジャイルや要求開発の導入を推進してきました。

    2016年に、ほぼ私一人で始めた活動ですが、今では20名を超えるコーチングチームを組織するに至りました。
    一部の活動は私の手を離れ、完全に社内コミュニティを主体に運営されています。
    さらに、毎年開催している社内のアジャイルカンファレンスは、17年時点は約450名ほどの参加者だったのが20年には倍の約900名にまで増えました。
    さらにさらに、私が支援した社内のサービス開発チームが、SFOにプロポーザルを出すに迄いたりました。

    ここに至るまで経緯や具体的な施策、現在直面している困難と課題についてお話しさせて頂きます。

    現在の途中経過ではありますが、少しでも皆さんの参考になれば幸いです。

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    Masanori Kawarada (Mark Ward) - 独立QAチーム1年戦記:スクラムの外からチームと組織の品質を創る道 / An Independent QA Team's 1 Year's War: Way to Create Quality of the Teams and the Organization from the Outside of Scrum

    45 Mins
    Talk
    Intermediate

    English follows:

    「Scrum@Scale(S@S)を取り入れた100名ほどの開発組織で、スクラムに入らない独立したQAチームが活躍している」と聞いたら、もしかしたら奇異な感じを受けるかもしれない。スクラムではチームであらゆることが完結することを理想とするため、当然テスター(QAエンジニア・テストエンジニア ・などなど)もスクラムチームに入るべき、と考える方がスクラム実践者にとっては自然だからである。あえて、その自然に逆らって、私たちQAチームは独自のビジョンを掲げた「ビジョナリー・QA(Visionary QA)」として、独立した立場から品質向上という成果を上げようと奮闘している。このトークではそんな私たちQAチームの1年戦記をありのままに扱いたい。

    開発プロセスの高速化が進み、多くの企業でアジャイル開発が取り入れられ、過去の当たり前が当たり前でなくなっている中で、QA界隈ではどうやって価値を提供するか頭を悩ませている。あくまでもテストにこだわる者もいれば、スクラムマスター・プロダクトオーナーの視野を得るべく資格を目指す者もいる。2009年に翻訳出版されたリサとジャネットによる『実践アジャイルテスト(Agile Testing)』(翔泳社)は国内のテスターに広く読まれているが、最近版元品切になっていることもあり、手に入りにくくなっている。

    さて、テスターは異質な存在のひとつとして見なされている。ご存知の通り、スクラムガイドにはテストやQA活動をどのように行うべきか、言及されていない。3つのロールに「テスター」の文字は無い。よって、テスターのあり方はそれぞれの組織で模索するしかなく、特にテスターをスクラムチームに含めるべきか否かという議論は継続的に行われている。先にもあげたように、スクラム実践者にとってはテスターがスクラムチームに入ることは自然であると感じられ、実際そのようにしている組織が多いが、それぞれにメリット・デメリットがあることから、あらゆる組織で通じる答えは今のところ無さそうだ(テスターとして仕事をしてきたメンバーがスクラムチームの開発者の一員としてどれだけクロスファンクショナルに動けるか、という点が特にネックなように思える)。

    このトークは、独立した立場で動くことを選んだQAチームの話だ。スクラムチームにテスターを迎え入れねばならないと思っている方にはそうでない可能性を示す一方で、やはりスクラムチームに開発者としてテスターを加えるべきだと結論づけるオーディエンスもいらっしゃるかもしれない。スクラムチームとテスターの一筋縄ではいかない関係を、1年間の実例をもとに、一緒に考えようではないか。

    "In a 100-strong software development organization which runs Scrum@Scale, an independent QA team works well." ––it may sound strange to you. Ideally, in Scrum, everything should be done in one scrum team, so it is natural for Scrum practitioners that testers (QA engineers, test engineers, etc.) should join a scrum team. Daring to go an unnatural way, our QA team struggles to achieve quality improvement results from an independent standpoint as "Visionary QA" with its vision. I want to treat our QA team's year-long battle story as it is in this talk.

    Development processes are getting faster and faster. Many companies are incorporating agile development. The commonplace of the past is no longer the norm. In this fast-changing age, the QA industry is struggling to figure out how to deliver value.  Some testers are more concerned with testing, while others aim for the certification to learn a Scrum Master/Product Owner's perspective. The excellent book, "Agile Testing" by Lisa Crispin and Janet Gregory (Addison-Wesley), which was translated in Japan in 2009 by the domestic publisher Shoeisha, has been widely read by testers in our country. Recently, however, it isn't easy to get due to out of print.

    Testers tend to be seen as one of the heterogeneous entities. As you know, there is no mention in the Scrum Guide on how testing and QA activities should be done. There is no "Tester" in the three roles of Scrum. Therefore, each organization has no choice but to explore the nature of testers. In particular, there is an ongoing debate on whether or not testers should be included in Scrum. As mentioned earlier, it seems natural for Scrum practitioners to have testers join Scrum, and indeed many organizations are doing so. Still, since each has its advantages and disadvantages, it seems that we don't have an answer that works for all organizations at the moment. One of the problematic points appears to be how well testers can work cross-functionally as a "Developer" in Scrum.

    With this session, which is about a QA team that chose to work independently, some attendees who feel testers should join a Scrum team may get a chance to notice the other possibility, and others may conclude that Scrum teams should still include testers. Let's take a look at the tricky relationship between Scrum and testers with the help of a year's worth of examples.

  • Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - すべての社会人に知ってほしい仕事の基礎としてのアジャイル/スクラムの話

    Yusuke Amano
    Yusuke Amano
    ScrumMaster
    Cybozu
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    アジャイルやスクラムについて学び始め、実際に取り組むと、その原則や考え方がソフトウェア開発の領域に閉じないことを日々実感します。原則を日々の仕事・生活に活かすことは重要ですが、「アジャイル」という言葉は抽象度が高く、開発のイメージも強いため、一般化してエッセンスを伝えるのに苦労している方も多いのではないでしょうか。

    スクラムマスターとして、開発に限らず組織の全員が、アジャイル/スクラムの原則を理解して、実践できるよう支援することは重要な活動です。サイボウズでは、数年前から新卒の全社員(+希望者は誰でも)向けの基礎研修としてアジャイル/スクラムの話をインプットしています。

    こちらのセッションでは、サイボウズ社内で実施している研修(講義)を社外向けに再編成したものをお届けします。アジャイルやスクラムの考え方をベースに、エンジニアに限らず、チームワークを高め、成果を届ける仕事の進め方の基礎となる考え方・プラクティスを紹介します。

  • Yuichi Tokutomi
    keyboard_arrow_down

    Yuichi Tokutomi - ゲームのように学ぶアジャイル開発

    Yuichi Tokutomi
    Yuichi Tokutomi
    CEO
    Degino Inc.
    schedule 5 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    アジャイル開発に興味のあるみなさん、どうやって学んでいますか?

    XP の白本から始まったアジャイル開発。その後、たくさんの本が出版されてます。本に書いてあることは良さそうなのですが、実際にやろうとすると分からないことだらけだったりしませんか? スクラム開発をやってるとつもりだった自分のプロジェクトが "ミルクボーイがアジャイルを説明したら" のネタになっててハッとしたりしませんでしたか?

    そんなアジャイル開発の入り口にいる人たちに向けて、私がどうやって学んできたのか? 学び続けているのか? XP 白本の発売から 20 年の道のりをお話したいと思います。入り口から一歩進むきっかけにしていただければ幸いです。

  • Kenta Sasa
    keyboard_arrow_down

    Kenta Sasa - チームや組織を良い感じにするためにやっていること紹介 〜社外アジャイルコーチと社内チェンジエージェントの両面から〜

    45 Mins
    Talk
    Beginner

    アジャイルコーチをやっていてよく聞く悩みとしてこんなのがあります。

    • もっと良いチームを作りたいのになかなかメンバーが変わってくれないんですよ…
    • うちのチームはアジャイルなんですが周りのチームが理解してくれなくて…
    • 弊社は古くて堅い文化なので新しいことを始めるのは難しいんです…

     

    では支援を提供している自社ではこのような問題はないのか?と問われると、程度こそ違えどチーム・チーム間・組織の単位で色々な問題はあります。もちろん、私が力になれそうな問題であれば良い感じになるように色々な動きをしています。

     

    社外のアジャイルコーチの場合、期限・頻度・役割といった観点で考えると、実際の現場のチームやメンバーと同等の動きは取りません。一緒に問題や解決案を考えたりはしますが、実際に解決のために動くのは現場のメンバーになります。

    逆に社内を良い感じにしようと思った場合、自分自身が当事者であり、実際にアクションを行うのは周りの誰かではなく私です。

     

    私は自身の勤務時間の半分を他社向け、もう半分を自社向けに使っています。アジャイルコーチとして現場の支援をすることもあれば、アジャイルコーチの皆さんに相談をして支援を受けることもあります。社外のメンバーの背中を押すときもあれば、社内のメンバーの背中を押すときもあれば、社外のメンバーから背中を押してもらうこともあります。支援や改善活動の単位も個人/チーム/複数チーム/組織全体と様々です。

     

    といった様々な立場や規模で動いている経験から、チームや組織を良い感じにするために実際にやっていること、結果としてどんなことが起きたのか、気をつけているポイントなどを紹介させていただこうと思います。あくまでもコンテキストありきの事例集ですが、事例ごとに参加者の皆さんとそれぞれのコンテキストで活用できることがあるかも議論しながら進めようと思っています。

    私の事例を肴にわいわいしましょー!

  • Takeshi Kakeda
    keyboard_arrow_down

    Takeshi Kakeda - 個人から始める変化 〜 IKIGAIマップ、マルチ・ポテンシャライト、ザ・メンタルモデルを入口にして〜

    Takeshi Kakeda
    Takeshi Kakeda
    Owner
    Zensow
    schedule 2 months ago
    Sold Out!
    90 Mins
    Workshop
    Intermediate

    a4310d2b6582d11a5058a7031d619a09.png

    チームを「アジャイルなチーム」にどう変容させるかという点に苦慮されている方は多いと思います。

    「チームの動きがなかなかうまくいかない」「あの人が変えられない」「自分のやり方が間違っている」などと悩んでいる方もいるのではないでしょうか。

    そんな時は、一呼吸おいて「チーム」や「他者」ではなく「自分の内面」に目を向けてみましょう。

    本セッションでは、チームではなく個人、他者ではなく自分に着目して「自分が変わることで、チームが変わる」という可能性を探ります。

    登壇者は、2000年から、XP、スクラムをはじめとする様々なソフトウェア開発、アジャイルの手法・思想・価値体系、パタン・ランゲージやネイチャーオブオーダーなどの周辺の思想も含めて探求してきました。そして現在着目しているのが「個人の変容」です。

    Kent Beckは以前、来日した時に「Social change starts with you.」と言う言葉を残しています。本セッションでは「自分が変わる」ということはどういうことなのかをワークを通じて探求していきます。

    まず最初に、IKIGAIマップによって自分の今を客観視してみます。IKIGAIマップは自分の今の人生の様子をざっくり俯瞰することができるツールです。

    その後、「マルチポ・テンシャライト」という「器用貧乏」を肯定的に捉える考え方をご紹介した後に、自分の内面に目を向けるワークをおこないます。

    最後に、「ザ・メンタルモデル」をヒントにして、自身の無意識の振る舞いがどのような現実を作っているのかを見つめます。

    自分を内観することで、どのように認知が変わるでしょうか?「そこにあるものを、ある」と認めることで何が変わるでしょうか?

    そして、結果として自分の周囲がどう変化するのでしょうか?

    様々な手法や考え方を紹介しながら、他者ではなく自分を見つめ、チームが変わるのではなく、自分が変わることで世界が変わるという意味とはどういうことかを一緒に探求しましょう。

     

     

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - コミュニティ活動で得られた知識と希望~オンライン勉強会に半年で200回参加して感じたこと~

    aki matsuno
    aki matsuno
    engineer
    -
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    完全未経験&文系でソフトウェア開発の道に飛び込んで3年半、仕事で少しずつ成果が出せるようになったものの、度重なる挫折と大きな無力感を抱いていた自分は、藁にも縋る想いでオンライン勉強会への参加を始めました。

    そこで出会ったのは、アジャイル開発をはじめとしたソフトウェア開発を豊かにする多種多様な知見と、常に変化を楽しんでお互いに刺激を与え続けているコミュニティの方々でした。

    素敵な出会いに囲まれた自分は、焦燥感から参加していた勉強会が楽しくなるばかりか、これまで嫌いだった"学ぶ"という行為が楽しく感じられるようになりました。
    気が付くと、物事を継続することが苦手だった自分は毎週勉強会に参加して毎日読書するようになり、200回の勉強会参加&100冊弱の読書をしていました。

    そして、コミュニティの方々と一緒に学びを深めるにつれ、知識が身につくのみならず"自分自身と向き合うこと"の重要性を意識するようになりました。

    今回は、自分がアジャイル開発や様々な学問から学んだ知識やもらった希望、そして自分に多数の知識と驚くほど大きなエネルギーをくれたコミュニティの方々の話をしてみようと思います。

  • Ryuku Hisasue
    keyboard_arrow_down

    Ryuku Hisasue - 良いチームを形成する方法 〜リーダーのいない組織を大学生が挑戦〜

    45 Mins
    Talk
    Beginner

    このセッションでは,大学のPBL(Project Based Learning)でリーダーのいない組織を形成し,その活動の中でどのようにチームが成長してきたかをお伝えします.

    いま,日本の大学ではPBLという学習方法が広く実施されています.PBLとは,実際にプロジェクトチームを形成してプロダクトを作る経験を得ることによって,チーム開発やチームマネジメントの手法について学ぶことができる学習手法です.私が所属する大学でもPBLのカリキュラムがあり,スクラムを用いてプロダクトを作るという経験を得ました.しかし,私たちのチームはほかのチームとことなりリーダーを決めずに活動してきました.そして,その結果として,とても良いチームを形成できたと感じています.

    リーダーもいなく,開発初心者が集まるプロジェクトで,どのようなことに苦労したか紹介・分析し,そのうえでチームをより良くするためにはどうすればいいかお話ししていきます.

  • Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe / kyon _mm / Mori Yuya / Toshiharu Akimoto - Deep Dive Experts - 達人が見ている世界を覗いてみよう -

    90 Mins
    Talk
    Beginner

    達人たちが見ている世界を覗いてみませんか

    「あの人はこの問題に対してなんて答えるんだろう?」
    「あの人はこの答えに辿り着くまでにどういう思考プロセスを経たのだろう?」
    「あの人の頭の中身が見てみたい!!」
    と思ったことはありませんか?

    同じようなプラクティスや手法を用いていても、人/チームによってまったく違う結果になります。
    つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

    このセッションでは達人たちが見ている世界を覗いてみる実験をします。
    ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
    ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - アジャイル環境における品質プロセス - Janet Gregory & Lisa Crispin(動画放映)

    Jumpei Ito
    Jumpei Ito
    QA Engineer
    WingArc1st Inc.
    schedule 3 months ago
    Sold Out!
    90 Mins
    Track Keynote
    Beginner

    テスターを含むチーム全体(Whole-Team)で、プロセスやプロダクトに品質を作り込む(Build quality in)にはどうしたらよいでしょうか。
    Janet Gregory とLisa Crispinによるこの動画では、W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」と、それをアジャイルな職場で実践する方法について詳しく学べます。

     

    W.エドワード・デミング氏が提唱する「ビジネス効率を向上させるためのマネジメントの原則」で以下の2つの原則はJanetのお気に入りです。

    • quality is everyone's responsibility(品質はすべての人の責任)
    • improve quality you automatically improve productivity(品質を向上させれば、自動的に生産性も向上する)

    また、Janetがオリジナルで提唱する原則が以下の2つです。

    • if you focus on quality the speed will come(品質にフォーカスすればスピードが出る)
    • if you focus on speed the quality gets lost(スピードにフォーカスすれば品質が失われる)

    アジャイル環境において品質を考えると、「プロダクト品質」と「プロセス品質」の関係が重要となります。
    JanetとLisaは以下のような内容で特にプロセス品質についてトークします。


    1.Question Askerであるべき
    2.例やテストを使って開発をガイドする
     ・magic bubble(魔法の泡) コード・テスト・自動化
     ・Acceptance Testのループ(受け入れテスト作成→テストの拡大→自動化担当者とペア→テストメソッドの作成→何をテストするのかを明確化→TDDサイクル→ハッピーパスが通るまでリピート→探索的テスト)
    3.エクササイズ(ユーザーストーリーからテストを考える)
    4.アジャイルテスティングの4象限を使ってテストを把握する
    5.探索的テスト、品質属性のテスト、スライディング・スケール
    6.コアプラクティスを使う
     ・継続的インテグレーション
     ・テスト自動化
     ・機能やストーリーの優先順位付け
     ・ビジネス価値を頻繁にデリバリー(いつでも出荷可能なリリース候補を用意する)
     ・品質をデリバリー(コアプラクティスを用いて、会社やチームのあらゆる部分で品質を構築)

     

  • Masayuki Nishida
    keyboard_arrow_down

    Masayuki Nishida / Kei Nakamura - スクラムチームが挑む!未熟プロダクト育成とビジネス成功への道

    45 Mins
    Track Keynote
    Beginner

    老舗大手製造業生まれの新規SaaSビジネスが1年目で直面した成長の壁、
    モダンアプリ開発会社が加わり組成した新スクラムチームが、ビジネス貢献に取り組み続けて成果を上げ始めています。

    「変化を目指す」老舗事業会社のPOと「変化を加速する」開発会社のScMが、体験や事実、その裏側にあった仲間の支援など、対談形式も交えてお伝えします。

    「スピード優先で事業化にこぎつけスタートしたSaaSプロダクト。その結果プロダクトが、早晩スケーラビリティや持続性を担保できず足踏み状態になる」…そんなビジネスあるある。

    今回題材となるSaaSプロダクトも、スピード優先でビジネスを始めた当初は数十社の顧客と密にやり取りを行い、フィードバックを製品に反映しながら良好な立ち上がりに見えました。
    しかし顧客数が増えるにつれ、事業会社が進めていた日曜大工的開発では開発スピードや品質が市場要求に追いつけなくなっている状態に、事業会社POは悩みます。
    (悩みの一例)
    ・PoCの延長で開発されたプロダクトのテスト、デプロイが人力依存で非効率な状態
    ・インフラやアーキテクチャが大規模顧客を考慮していない中でのエンタープライズシフト企画
    など。
    せっかくビジネスが拡大しそうなのに、さてどうしたものか。。。

    組織的な改善を水面下で続けていた老舗大手企業とモダンエンジニア集団が出会い協力しスクラムに取り組んだ軌跡

    登壇するPO、ScMが本プロジェクトで大切にしてるマインド

    [ PO ]

    対話を通してビジネスが目指していく姿、変化していく市場の生の声、背景を伝え続ける

    [ ScM ]

    POを含めたステークホルダへの状況の見える化と対話の機会を明示的に増やして活用してもらう工夫をしました

     

  • Mori Yuya
    keyboard_arrow_down

    Mori Yuya - シン・仮説検証 70,000枚の付箋で分かった仮説検証のエッセンス

    20 Mins
    Talk
    Beginner

    2012年に翻訳発売された『リーン・スタートアップ』を皮切りに仮説検証という考えが身近になりました。観察して仮説を立てて確かめるプロセスを通して、より効果的な手をうち、問題の解決やプロダクトの売上の成長につなげていく考えです。

    仮説検証は特別な行為ではなく、私たちは日常的に「いまこうなっているから、これをしたらこうなるだろう」と推論しています。これも仮説検証です。

    しかし一方でこんな声も聞きます。

    「仕事の中で仮説検証はやってみているけれど、本当にこれでいいのかいまいちピンとこない」

     

    私は『リーンスタートアップ』の登場以前から仮説検証の虜になり、この10年のあいだに書いた付箋だけで7万枚を超えました。そこで分かったことは、ちょっとしたポイントで善し悪しが大きく変わってしまうということです。

    このセッションでは仮説検証の質に悩んでいる方に向けて仮説検証のエッセンスを共有します。時間のかかる仮説検証のテクニックとは異なり、普段使いできるため日常で無理なく使えます。一言で、ここを押さえるだけですごくよくなるキモをお伝えします。

    特に、次のような仮説や問題定義を目にする方には抜群に役立つと思います。
    「時間がない」「スキルがない」「チームがうまく連携できていない」

  • Kenta Sasa
    keyboard_arrow_down

    Kenta Sasa - スクラムマスター的な振る舞いと効果を見てみよう -子供3人とプレイしたFortniteの現場から-

    45 Mins
    Talk
    Beginner

    スクラムを始めたばかりのチームで稀によく聞く質問に下記のようなものがあります。

    • スクラムマスターって具体的に何をすれば良いんですか?
    • スクラムマスターって必要なんですかね?
    • 開発してもらった方が効率いいよね?

     

    ではスクラムガイドにはどんなことが書いているか確認してみましょう。スクラムマスターの責任については下記のような記述があります。

    • スクラムチームと組織において、スクラムの理論とプラティクス を全員に理解してもらえるよう支援することで、その責任を果たす。
    • スクラム チームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任 を果たす。

     

    支援については、スクラムチーム・プロダクトオーナー・組織を対象に、さまざまな支援が記載されています。スクラムチームへの支援だけとってみてもこのような説明が書いています。

    • 自己管理型で機能横断型のチームメンバーをコーチする。
    • スクラムチームが完成の定義を満たす価値の高いインクリメントの作成に集中できる よう支援する。
    • スクラムチームの進捗を妨げる障害物を排除するように働きかける。
    • すべてのスクラムイベントが開催され、ポジティブで生産的であり、タイムボックス の制限が守られるようにする。

     

    このような説明を読んでみると、ふわっとしたイメージは掴めるものの「具体的に何をすれば良いんだろうか?」という疑問は残ります。そんな時に経験の長いスクラムマスターが近くにいれば振る舞いを見て学ぶようなこともできますが、初めてスクラムを始めるようなケースではモデルになる人がいないことも多いと思います。

     

    ということで!

    スクラムマスター的な振る舞いを実践している所を見て学ぶ場を用意したいと思います!

    題材はFortniteというゲームです。Fortniteとは、4人でチームを組み25組100人の中で1番を目指すサードパーソン・シューティングゲーム(TPS)です。

    今回は子供3人+笹の4人でプレイした時の動画を題材に、スクラムマスターとして必要な動き・考え方・観点を確認していきましょう!

    私が一方的に説明するだけではなく、参加者の皆さんの意見ももらいながらポイントをまとめていこうと思っているのでワイワイやりましょう!

  • Jean-Baptiste Vasseur
    keyboard_arrow_down

    Jean-Baptiste Vasseur - リーダーとは何か、その答えをずっと探していたがCAL2を受けてやっと理解し始めた話

    45 Mins
    Talk
    Intermediate

    昨年弊社のメンバーが徐々に増えてきて、自分としてよりリーダーらしい立場と振る舞いをとっていきたいと考え始めましたが、そもそもリーダーとは何か、そこからスタートする必要がありました。

    色んな書籍やネット記事を読めば大体のことが理解できますが、相反する考え方もあれば自分としてこういうリーダーになりたいというものがちゃんとフィットするものも見つかりませんでした。

    そこで2020年9月にScrum AllianceのCAL(Certified Agile Leadership)プログラムに出逢いました。

    よし!CAL1とCAL2を取得してヒント探しに行くぞ、と。

    そして2021年4月現在、無事終わりました。確かにヒントは得られました。

    しかし、経験したこと、学んだこと、得られたものは想像を遥かに超えていました。

    皆さんにもぜひアジャイルリーダーの旅に出て欲しいという気持ちを込めて私のアジャイル・リーダー・ジャーニーを語りたいと思います。

  • Yuki Misumi
    keyboard_arrow_down

    Yuki Misumi - チーム バーサーカーズ 〜狂戦士になれと言われた僕らの、がむしゃら1日スプリント

    Yuki Misumi
    Yuki Misumi
    Software Engineer
    Freelance
    schedule 3 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    人生初の開発現場は、6人のバックエンドチームがFAPI-CIBAという世界最先端の認証認可サーバー実装をしながら、モバイルアプリや銀行業務システムの開発まで担当する戦場でした———

    毎日変わる要求と仕様。政治の絡む技術選定。立ち塞がる大量のRFC文書。

    僕たちは、高速でアップデートするチームになる必要がありました。スプリント期間は、2週間から1日になり、モブプログラミングには、知識の新陳代謝が組み込まれました。肥大していく技術分野に追いつくために、勉強タスクを設けて学びを共有しました。

    具体的な使いどころに関して、1日スプリントはプロダクトの方向性が定まっていない時に大変効果的でした。プロダクトオーナー側から細かいフィードバックが生まれ、プロダクト像がかたどられていくためです。モブプロは、新しい技術分野の実装時に、開発メンバー間の理解のキャッチボールを促した点で有用でした。

    このセッションでは、そんな狂戦士の如く戦場を舞った、ぼくらの取り組みと考察を1日スプリント/モブプロ導入事例として共有します。

    プロジェクトが始まったが、漠然とした課題解決方針のみで具体的な仕様はだれも言えない。。
    誰も対象の技術分野の経験がない。。
    これらの状況にある方にとって、日々の働き方のヒントになるような内容にしたいと思います。

  • Mori Yuya
    keyboard_arrow_down

    Mori Yuya - プロダクトオーナーマニアックス! POとSMの原点の原点をさかのぼって学ぶ初代主査 中村健也の働き方

    45 Mins
    Talk
    Advanced

    ■チーフエンジニアというプロダクトオーナーとスクラムマスターの原点

    スクラムではプロダクトオーナーという役割が用意されています。この役割はどのように作られたのでしょう。ジェフ・サザーランドが書いた『スクラム 仕事が4倍速くなる“世界標準”のチーム戦術』では次のように解説しています。

     プロダクトオーナーという役割は、トヨタのチーフエンジニアから発想を得たものだ。

     

    続いて、スクラムマスターの着想もチーフエンジニアからだったことが解説されます。

     チーフエンジニアはただこうしろと指示を出せばいいのではない。メンバーを納得させ、うまくその気にさせて、自分が提案するやり方が正しくベストなやり方だということを示さなければならない。普通ならその道で三十年くらいの経験がなければ務まらない役割だ。そこでこの役割を二つに分け、仕事の進め方をスクラムマスターが、仕事の内容をプロダクトオーナーが管理する分担制にした。

    もちろんチーフエンジニア以外からも参考にされたものはたくさんあるでしょうが、POとSMというアイデアに大きな影響を与えたようです。

     

    ■機能しないチーフエンジニア

    しかし、チーフエンジニア制度と半世紀近く携わり、自らもセリカ、カリーナ、スープラのチーフエンジニアであった和田明広は次のように述べています。『和田明広オーラル・ヒストリー』 から引用してみましょう。

    トヨタのチーフエンジニア制度について様々な企業から相談が持ち込まれますが、うまく機能しないことを述べています。※文中の主査は、チーフエンジニアの前の名称。

     和田 チーフエンジニアという制度はあるのですが、トヨタみたいな機能はしないのです。マーケットを見ていますけれども、新しい車をクリエイトするというようなことがなかなかできないのです。
     尾高 日本の中ではどうですか。
     和田 同じです。


    また現在のトヨタにおいてもチーフエンジニア制度は、機能しているか疑わしいと述べています。

     和田 よそのチーフエンジニアですか。でも、いまはトヨタのチーフエンジニアもそうですからね。いまはそんなに能力のある人間はいません。そんな2年や3年ちょこちょこっとやったぐらいで十分な能力ができるわけないですよ。我々だってどのくらい失敗したかわからないわけです。10年から実質的には何十年やっていますけれども、どれくらい失敗したかわかりません。

     

    ■トヨタのチーフエンジニア制度が生まれる過程

    ジェフ・サザーランドがスクラムを構築する過程にチーフエンジニア制度があったように、トヨタのチーフエンジニア制度においても過程がありました。その中で和田明広は中村健也という人物に焦点を当てています。

     松島 トヨタの場合は、なぜ他社とは異なる主査制度が生まれてきたたのでしょうか。
     和田 それは前回申し上げたかもしれませんが、中村健也さんが素晴らしい実績を残されて、会社内全体が、主査のいうことは社長の言うことだ、そういうムードになったのだと思います。

     

     尾高 外国から主査の役割についていろいろ聞いてきたとおっしゃいましたね。その結果、外国で何か起きたのでしょうか。
     和田 起きないと思います。どうしてトヨタでは主査というのがうまく機能するのか、ということですから。それはどうしてかと私に聞かれれば、それは中村健也さんから始まって全社的な組織とは違ったパーセプションを得られて、それでうまく動いているのだと説明するしかないのですけれども(略)

    ※和田明広 日本初の乗用車である初代クラウンや、初代カローラのボディ設計を担当し、トヨタで大主査と呼ばれるようになった中村健也や長谷川龍雄と共に開発をした。その後、自身もセリカ、カリーナ、カリーナED、スープラの主査(チーフエンジニアの前の名称)、またプリウスのプロジェクト責任者を担当。トヨタ副社長、アイシン精機会長、日本機械学会会長を歴任。

     

    トヨタ自動車株式会社名誉会長である豊田章一郎は『未来を信じ一歩ずつ : 私の履歴書』の中で、節をまるまる用いて中村健也を取りあげています。

     その後、1962年(昭和37年)はにモデルチェンジした2代目クラウンには、より剛性の高い「Xフレーム」を採用した。
      このときも、私は、技術部で中村さんと一緒に仕事をした。フレームをできるだけ薄くし、車高を低くすることを目指したが、X型フレームに対しては社内の反対も多く、まさに冒険そのものたった。
      テストコースの悪路耐久試験ではフレームに亀裂が生じたが、中村さんは決して諦めなかった。私は、「これが失敗したら2人で一緒に会社を辞めましょう」と言って中村さんを励ました。いつも不退転の決意で臨む中村さんも同じ思いだった。

     

     中村さんの主査としてのやり方が骨格となり、今日のトヨタのCE制度がだんだんと築き上げられ、それがトヨタの特徴となり財産にもなった。
      初代クラウンとともに主査中村健也は、いつまでも私の心に残る技術者だ。いかに情熱を持って仕事に取り組むか。そのような精神の持ち方を訓練すれば、私のような若い技術者でも大いに活躍できると思った。

    ※CE制度とはチーフエンジニア制度のこと

    いったい中村健也とは何者なのでしょうか。どのような仕事や仕事の仕方をしてきたのでしょうか。

     

     

    ■このセッションでは何をするか、何が得られるか

    スクラムのPOとSMはジェフ・サザーランドによればトヨタのチーフエンジニア制度から着想を得ましたが、和田明広によればチーフエンジニア制度は他社では積極的に導入を試みるもうまく機能しておらず、まして現在のトヨタでも機能しているか疑わしいと厳しい評価をしています。

    このセッションでは、私たちがプロダクトオーナーという役割をより効果的に果たしていくために「そもそもチーフエンジニア(主査)とはなんだったのか」を「中村健也」という人物を中心に、POとSMの原点(チーフエンジニア制度)の原点(中村健也)を70年ほどさかのぼり、プロダクトオーナーが効果的に力を発揮するための知恵を探ります。

     

     

    参考文献

    『スクラム 仕事が4倍速くなる“世界標準”のチーム戦術』ジェフ・サザーランド, 早川書房, 2015
    『和田明広オーラル・ヒストリー』 松島茂, 尾高煌之助編 東京理科大学専門職大学院MOT研究センター, 2008.12(非売)
    『未来を信じ一歩ずつ : 私の履歴書』豊田章一郎, 日経BP, 2015
    『トヨタ自動車開発主査制度』塩沢茂, 講談社, 1987(絶版)
    『主査 中村健也』和田明広編, トヨタ自動車株式会社, 1999(非売)
    『トヨタの製品開発』安達瑛二, 白桃書房, 2014
    『初代クラウン開発物語』桂木洋二, グランプリ出版, 2015(底本1991)
    『トヨタ チーフエンジニアの仕事』 北川尚人, 講談社, 2020
    『プロジェクトX 挑戦者たち われら茨の道を行く ~国産乗用車 攻防戦~』NHK

  • Hiromi Morikawa
    keyboard_arrow_down

    Hiromi Morikawa - 創業145年の日系大企業でのアジャイルへの挑戦

    Hiromi Morikawa
    Hiromi Morikawa
    UX Designer
    Dai Nippon Printing
    schedule 2 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    145年の歴史を持つ大日本印刷株式会社。
    時代の変化に適応し、印刷という名前からは想像できないほど、ものからシステム、SI案件から自社事業まで幅広いものづくりを行っています。

    そんななかで新規事業のシステム開発を担う、たった5人のスクラムチームからはじまり、
    現在では会社全体になかまができ、外部コーチの力を借りながらアジャイル推進を行うまでになりました。
    新規事業の開発チームしかいなかった状況から、プラットフォーム開発や受託開発での検討の話題にもなっています。
    当初は1チームしかなかった開発チーム。チームと人材は徐々に増え、会社としての取り組みが加速しています。

    開発チーム内での実践から「アジャイル推進」へ役割を変え、
    どのようになかまを作りムーブメントを広げていったのか、大企業内で推進に向き合ってきたなかでの工夫や苦労をお伝えできればと思います。

    大きな組織のなかで試行錯誤している事例のひとつが、みなさんの参考になれば幸いです。

  • 90 Mins
    Track Keynote
    Advanced

    「ユニコーン企業のひみつ」。この本はとても読みやすいんだけど、でもそれって…自分と違う星の話を眺めてる気分だからじゃないのかな(仮説)。

    私たちのチームと本で紹介されているチームの様子は、まるで地続きみたいによく似ていてます。本講演では「ユニコーン企業のひみつ」を使って私たちのチームについて説明を試みます。この本を自分のことのように受け止めた人たちの助けになれば良いな、と思います。

help