組織の生産性を可視化しよう! 〜プロジェクトの導入課題とその効果〜

みなさんの会社では組織の生産性を客観的に判断しているでしょうか?

創業6年目を迎える弊社では、ここ1年で従業員数が2倍近くになり、サービスも組織も急成長しています。

その一方で開発プロセスが整っておらず、プロセスの整備、スクラムの導入など、組織としてより成長するための仕組み作りを始めています。その一環で、2019年3月から組織の生産性可視化も始めました。

プロジェクトは進行中であり、結果というよりは経過報告の形になりますが、今回の発表では、押さえるべきポイント、成功事例、失敗事例をご紹介できればと思います。

 
 

Outline/Structure of the Talk

変更の可能性はありますが、以下の予定です。

  • 生産性とは何か
  • 組織が抱えていた課題
  • 可視化プロジェクトのフェーズ
    • 合意形成期
    • 推進期
    • 改善期
  • 各フェーズで行ったアクション
  • 難易度が高かった課題
  • 今後のアプローチ

Learning Outcome

以下を持ち帰ってもらえるよう想定しています。

  • ケーススタディ
  • 生産性可視化がもたらすPros/Cons
  • 新規プロジェクトを進める際の成功アクション・失敗アクション

Target Audience

生産性可視化に興味がある方、新規プロジェクトを進める際の課題を聞きたい方

schedule Submitted 1 year ago

Public Feedback


    • Yoh Nakamura
      keyboard_arrow_down

      Yoh Nakamura - みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか?

      20 Mins
      Talk
      Intermediate

      現場コーチとしてScrumでサービス開発しているチームの支援をしていると、よくディスカッションする話題の1つが「プロダクトバックログアイテム(PBI)の価値や成果をどう考えて、どのように扱うか?」というものです。

      このような話題の時、OutputとOutcomeの話をします。

      • Outputとは、リリースした機能の数や質のことをここではいいます。
      • Outcomeとは、利用者がどう変わったのか?利用者の課題が解決したのか?と利用者視点での効果のようなことをいいます。
        • ※Outcomeはビジネス視点からのOutcomeと、利用者視点からのOutcomeの2つに分類されます。上記は利用者視点からのOutcomeのことを書いています。

      たくさんのPBIをつくって頻繁にリリースしてOutputが増えたとしても、自分達にとっての価値、もしくは利用者にとっての価値(利便さや嬉しさ)といったOutcomeが増えていないとそのプロダクトやサービスを続けていくことはできません。

      1つずつのPBIの情報に"売上の増える額"や"ユーザー数の増加”を加えているチームもあります。
      また別の現場ではストーリーポイントと同じようなやり方で、仮想の単位を決めて相対的な値をチームで話し合って、どれからやるか?の参考にしています。


      プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。(ScrumGuide2017より)



      このセッションでは、"プロダクトバックログアイテムにおける価値の取り扱いのやり方”のいくつかの現場の事例を紹介しつつ、Outcomeについて考えをお話します。
      みなさんのPBIのOutcomeがよりわかりやすく、より高くなるヒントになればと思います。

    • 中村 薫(Kaoru Nakamura)
      keyboard_arrow_down

      中村 薫(Kaoru Nakamura) - 10年たってやっとアジャイルがわかりかけてきた話

      中村 薫(Kaoru Nakamura)
      中村 薫(Kaoru Nakamura)
      CEO
      HoloLab Inc.
      schedule 1 year ago
      Sold Out!
      20 Mins
      Talk
      Beginner

      アジャイル、XP、Scrumは10年くらい前からイベントに出たり、本を読んだり勉強しても、どうにも身につかず。

      2017年に会社を作って、2019年に自社サービスをリリースして、やっとアジャイルが腹落ちしてきた気がします。

      このセッションでは、なぜ今までアジャイルが実践できなくて、なぜ今になってアジャイルがわかりかけてきたのか、ということをお伝えできればと思います。

    • Ryutaro YOSHIBA (Ryuzee)
      keyboard_arrow_down

      Ryutaro YOSHIBA (Ryuzee) - アジャイルコーチ活用術

      20 Mins
      Talk
      Beginner

      世の中でアジャイル開発が一般的になるにつれて、アジャイル開発を支援する「アジャイルコーチ」という職種や肩書を見かけることが多くなってきました。
      アジャイルコーチとは組織がアジャイルなやり方で成果を出せるようにするために、組織的な観点、技術的な観点、プロダクトの観点などさまざまな観点から支援する役目です。
      アジャイル開発に慣れていないチームには、アジャイルコーチは必要な存在だと言ってよいでしょう。

      一方で、アジャイルコーチといえば、「めんどくさい」「マサカリ投げる」「上がった感」「単価が高い」「実際の効果がよくわからない」といったイメージがあります。
      これらはコンサルティングを始めとした支援系の仕事に対する共通のイメージでもありますが、銀の弾丸思考の表れでもあります(アジャイルコーチがあなたの問題をすべて指摘し、魔法のように解決してくれるわけではなく、あくまで主体はスクラムチームです)。

      本セッションでは、アジャイルコーチとは何なのか、実際にアジャイルコーチをどう活用すれば良いのかを、日本で唯一のScrum Alliance Certified Team Coach(CTC)で実際にアジャイルコーチングを有償サービスとして提供している現役アジャイルコーチが解説します。

    • Takao Oyobe
      keyboard_arrow_down

      Takao Oyobe - Team-Based TEAM - 会社を越えるチーム -

      45 Mins
      Talk
      Advanced

      あなたのチームはいつ死にますか?

      スクラムはチームワークのためのフレームワークです。スクラムでは、安定したチームが成功するための前提条件として紹介されることが多いです。実際に「STABLE TEAM(安定したチーム)」はScrum Patternsの1つになっています。

      安定したチームは本当によいチームなのでしょうか?

      私たちのチームは、スクラムやモブプログラミングを通して自己組織的なチームになりました。Unlearnを自分たちの活動に組み込んで、学習するチームになりました。スタートアップしたプロダクトも成長軌道に乗せることが出来ました。そしてそのチームは、プロダクトの終焉を乗り越え、さらには会社をも越えました。

      私たちのチームは、Project-BasedでもProduct-Basedでもなく、Team-Based TEAMだったのです。私たちのチームにとってはプロダクトの終焉も転職もチームの死にはつながりませんでした。私たちの考える「STABLE TEAM(安定したチーム)」はSAME TEAM(同じチーム)ではなく、生物のように変化し続けることができるチームです。私たちは会社を越えた後も、変化と向き合い生物的チームを目指して活動を続けています。

      あなたのチームはいつ死にますか?

      このタフクエスチョンの答えはどの教科書にも載っていません。しかし、チームの死を考えることで、どう生きるかが定まり、どうチーミングすればよいのかが見えてきます。一緒にチームのライフサイクルについて考えてみましょう。

    • Raquel Silva
      keyboard_arrow_down

      Raquel Silva - Conflict Management - The dream behind the complaint

      Raquel Silva
      Raquel Silva
      Agile Coach
      JP Morgan Chase
      schedule 1 year ago
      Sold Out!
      45 Mins
      Talk
      Advanced

      A key question: What is the dream behind the complaint?
      Remember that a complaint denies our basic instinct to speak the truth. By reflecting on this question, you can create a shift in perspective and behaviour and move past the complaint, opening the door to share the need that was not met or the hidden dream.
      As coaches, we work and meet teams and individuals who live in constant frustration, constant complaining. Can you help them communicate their needs?

    • Ikuo Suyama
      keyboard_arrow_down

      Ikuo Suyama - 見積りしないスクラム / NoEstimates Scrum

      Ikuo Suyama
      Ikuo Suyama
      Engineer
      CyberAgent
      schedule 1 year ago
      Sold Out!
      20 Mins
      Talk
      Advanced

      はじめに

      本セッションは「見積りは不要なのでやめよう」と一律に提案するものでは ありません
      アジャイル開発における見積りについては「アジャイルな見積りと計画づくり」という素晴らしい書籍でその有用性や有効な実践方法が示されています。

      ここで、あえて問わせていただきます。

      「あなたのチームの見積りは、どれくらい正確ですか?」

      前回の RSGT 2019 Key Note において、 Chris Lucian@christophlucian 氏は #NoEstimates のコンセプトと、見積りのコストについて言及しました。
      彼が述べたように、見積りには負の側面があることもまた認める必要があるのではないでしょうか。

      私達のチームでは、これら見積りの負の側面と見積りから得られるものを比較し、見積りすることをやめる判断をしました。
      以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。

      この私達のプロセスでは、モブプログラミングが鍵となっています。

      本セッションでは、私達がどのように見積りをせず開発をしているのか、見積りをやめたチームで何が起こるのか、という事例を紹介し、ソフトウェア開発、特にスクラムにおいての見積りのあり方の議論の一助となることを目的とします。

      見積りの負の側面と価値 - なぜ見積りをやめたのか

      少し見積りの負の側面について触れておきます。
      私達が考える見積りの負の側面は、以下に集約されます。

      • 見積りのコスト
        • 見積りを行うためにかかる時間
        • 数値化したことによる、納期コミットの圧力
        • 数値化したことによる、仕事量の最大化(パーキンソンの法則)
      • 見積りの難しさ
        • ソフトウェア開発はそれ自体が複雑で不確実性を含む
        • 殆どの場合で経験したことがないことへの対応が必要になる
        • このため、正確な見積りを行うことが困難

      もちろん、見積りは負の側面ばかりではありません。
      しかしながら、見積りの「価値」については、見積り自体に価値があるのではなく、見積りから得られる副次的な情報に価値があると考えられます。

      • 見積りの価値
        • 見積りから得られる計画
        • 共通理解の促進
          • e.g. プランニングポーカー

      見積りから副次的に得られる価値が見積りの労力とバーターしない場合、その価値を別の方法で得られるのであれば、見積り自体をやる必要はないと考えます。

      スクラムと見積り

      タイトルの通り、私達はスクラムを実践しています。

      見積りを行わないプロセスでもスクラムは成立するのか、あるいはこれはスクラムと呼べるのか、という疑問が当然湧いてきます。

      スクラムガイドには「見積り」という言葉が9回登場します。
      それぞれを分類すると、スクラムにおける見積りは以下の意思決定を行うための情報であると考えられます。

      • 計画づくり
        • PBIの優先順位付け
          • ROIの ‘I’ の算出に必要
        • スプリントのキャパシティを測る
      • 追跡
        • スプリントの進捗状況を把握する

      見積り自体を行うことなくこれらの意思決定をするための情報が得られるのであれば、見積りをしなくてもスクラムとして成立するのではないか、というのが今回のアイディアです。

      我々は、以下の方法でこの意思決定を行っています。

      • PBIの優先順位付け(ROIの ‘I’)
        • PBIのサイジング
          • 直近2Sprint分のPBIはすべて1スプリント以下のサイズに調整
        • CD3(Cost of Delay Divided by Duration) による優先順位付け
      • スプリントキャパシティ&追跡
        • モブプロによるWIP制限
          • 安定性・予測可能性の向上
        • 過去データからの ‘予測’
          • タスクのサイクルタイムをヒストグラム化
          • タスクカウントとスループット

      まとめ

      Joshua Kerievsky はAgile2016 の基調講演「Modern Agile」において、アジャイルプラクティスは「補助輪」であると表現しました。
      見積りは今、ソフトウェア開発の「補助輪」といえる段階に差し掛かっているのではないでしょうか。

      私達のプロセスは完成されたものではなく、日々実験と失敗を繰り返して進化しているものです。

      AEPから10年、「見積りはソフトウェア開発において必須」という考え方もまた固定概念かもしれません。
      我々の実践しているソフトウェア開発の形について紹介し、議論できればと思います。

    • Takuo Doi
      keyboard_arrow_down

      Takuo Doi - モブプログラミング x 行動分析学 x 教育 / Mob Programing x Behavior Analysis x Education

      Takuo Doi
      Takuo Doi
      CTO
      Lifematics Inc.
      schedule 1 year ago
      Sold Out!
      20 Mins
      Talk
      Beginner

      現在,大学でプログラミング言語の授業を持っています.

      その授業では,文法としてのプログラミングだけでなく,プログラミングの面白さを知ってもらえるもらえるように,モブプログラミングを導入して授業を行なっています.

      ところが,企業でのモブプログラミングの導入とはまた違った課題がありました.そして,その解決策として,行動分析学を元にして,試行錯誤をしています.

      本セッションでは,その試行錯誤の課程を共有したいと思っています.

      ----

      I have a C programing course at university.

      I introduced Mob Programing technique to my class so that my student learn not only the grammar of the programing language but also the fun of programing.

      I have an experience to introduce Mob Programing to the work in our company. However I faced different problems. And Now I am trying to solve the problem using Behavior Analysis.

      I will share this experiences in my session.

    • Mitsuyuki Shiiba
      keyboard_arrow_down

      Mitsuyuki Shiiba - テックリードは未来の話をしよう (Tech Lead in Scrum)

      45 Mins
      Talk
      Intermediate

      スクラムチームにテックリード?

      「スクラムのロールには定義されていないけど、こういうのは誰がやるのが良いんだろう?」「そもそも、そんな状況ってことは、まだスクラムをやるための準備が整ってないってことなのかな?」って悩むことありませんか?僕はありました。

      スクラムに取り組んだ最初のころは「あれー?ここどうしようかな?とりあえず・・・自分でやっとくかな」と思うことが結構ありました。「これでいいのかなぁ?」と不安に思いながらやってましたが、それも5,6年たった今では「あー、うちの組織だと、こういう役割が必要なんだわ。こそこそやらずに、自分の中でテックリードって名前つけて堂々とやっとく方が良さそうだな」って納得してやってます。

      スクラムガイドの中には、テックリードというロールは定義されていません。でも僕は、今の組織の中で、このロールがとても大切な役割を果たしているなぁと感じています。大変だけど、やりがいがあって、とても面白いロールです。

      バックグラウンド

      こんにちは。椎葉です。楽天株式会社の大阪支社で自社ECサービスのアプリケーションアーキテクトとして仕事をしています。僕が所属している組織では、多くのチームがスクラムを採用しています。その中で、この数年間、僕は改善エンジニアとして「色々なチームに入っていって現場のみんなと一緒に内側から組織の改善をする」という活動をしてきました。その活動の中で学んだのが、テックリードというロールの大切さです。

      僕の中のテックリードは、スクラムチームと組織のあいだに立って、技術的な視点に軸足を置きながら、開発やチームや組織を支える。そういう役割です。何かと何かの間におちてしまいそうなものに手をのばして拾い上げたりします:プロダクトオーナーと開発チームのあいだ、開発チームとスクラムマスターのあいだ、スクラムチームと組織のあいだ、そしてマネージャーとスクラムチームのあいだ。など。 

      このセッションで伝えたいこと

      「僕の組織では、スクラムからは少し外れるかもしれないけど、こういうことをやる必要があって、僕はテックリードとしてこういうことをやってるよ」ということをお伝えしたいと思います。

      それによって、これからスクラムに取り組もうとしていたり、既にスクラムを実践しているけど悩んでたりする方々に対して「あぁ、自分も同じようなことで、もやっとしていたけど、そういう風にやってる人もいるんだな」って何かしら参考になるようなセッションにしたいなと思っています。

      また、その中で学んだ「テックリードとして考えておくと良いこと」もお伝えします。

      今、テックリードとして悩んでいる方や、これからテックリードとしてチームをリードしていく方々に勇気を伝えられるようなセッションにしたいと思います。

    • Arata Fujimura
      keyboard_arrow_down

      Arata Fujimura - 最高のScrumキメた後にスケールさせようとして混乱した(してる)話

      Arata Fujimura
      Arata Fujimura
      Manager
      Classmethod, Inc.
      schedule 1 year ago
      Sold Out!
      20 Mins
      Talk
      Intermediate

      2018年の11月頃から始まり、開発手法としてScrumを採用したとあるプロジェクトは、2019年の6月に予定通りサービスのローンチを行うことができました。

      このプロジェクトはお客さんとのユーザーストーリーマッピングでのMVP検討から始まり、まずはサービスの背骨にあたるMVPの実装を1ヶ月で完了。その後4ヶ月間はリリースできる状態をずっと維持し続けながら、毎スプリント着実に機能を追加していき、ローンチの1ヶ月以上前にはお客さんが希望する機能の追加を完了。ローンチ前にはいくつかのメディアに取り上げられたこともあり、多少注目されながらローンチ当日を迎えましたが、そこでも拍子抜けするほどなんのトラブルも起きず、お客さんからも開発チームからも、これほど安定したプロジェクトは今まで経験したことがないといったようなポジティブなフィードバックをもらうことができました。

      その結果、お客さんからの期待値が想定以上に高まってしまい、同じやり方を他の複数プロジェクトにも早急に導入することが決定。開発者を含む関係者が一気に倍増したことで、チームは混乱状態に陥ってしまいました。

      今現在も混乱中ですが、RSGT2020が開催される頃までには何とかなってると思うので、私達がこれからどのようにして再び練度の高いチームを作り上げていったかについてお話しできればと考えています。

    • Harada Kiro
      Harada Kiro
      CEO and Agile Coach
      Attractor Inc.
      schedule 1 year ago
      Sold Out!
      45 Mins
      Talk
      Beginner

      ScrumPLoPとして2010年から活動してきたスクラムをパターンランゲージとして記述する活動も、2019/8/5現在、最終校正が完了し印刷待ちです無事9/3発売されました。RSGT 2020 には、出版された本を持っていける予定ですいきます。

      540ページの大部になってしまったので、ちょっと気軽に手に取るには大きな本になってしまいました。

      このセッションでは、A Scrum Book の読み始める方法を、ちょっとした出版までのエピソードなどを含めてお話しできればと思っています。

      著者のJim Coplienを発表者に追加しました。

    • Tadahiro Yasuda
      keyboard_arrow_down

      Tadahiro Yasuda - 日本にJoy,Incを創る!ぼくらのジョイインクジャーニー3年間の軌跡

      Tadahiro Yasuda
      Tadahiro Yasuda
      CEO
      Creationline,Inc.
      schedule 1 year ago
      Sold Out!
      20 Mins
      Talk
      Beginner

      Joy,Inc.に出会う前のぼくらは、チームとして機能していませんでした。2013年ごろ、色々な問題が噴出し、会社としてどん底の状態でした。
      そこから、色々な取り組みを行い、少しづつ会社の状態がよくなっていきました。その過程のなかで2017年8月「Joy,Inc.」に出会いました。
      「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
      この本に共感しぼくらもこんな会社に成りたい!と決意。それを実行してきました。
      会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

    • Raquel Silva
      Raquel Silva
      Agile Coach
      JP Morgan Chase
      schedule 1 year ago
      Sold Out!
      100 Mins
      Workshop
      Intermediate

      Toxic behaviours in a Team cause damage to the Team. Affecting their performance, causing high levels of stress and demotivation. Conflict Navigation is one of the biggest challenges within the Teams. Can you help them to overcome this challenge? Are there any antidotes?

      When a Team member shows a toxic behaviour, how the Team reacts to it? Can we educate the team and help them as a System to overcome these challenges? As a Scrum Master or a Coach, our main mission is to help out teams to be their better selves. By the end of this workshop, you should be able to help your team to be better prepared to deal with conflict.

    • 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名規模になるまでの過程で起きたことやトライしていることをお話できればと思います。

    • Takeshi Arai
      keyboard_arrow_down

      Takeshi Arai - Scrum Master 2.0 〜僕が考えるスクラムマスターが目指すその先〜

      20 Mins
      Talk
      Intermediate

      僕が考えるスクラムマスターが目指すその先

      プロジェクトにおいて、プロダクトマネジメントにおいて、スクラムマスターとしての役割を実践してきました。
      この知識やマインドや実践知は、製品づくりだけに留まらせる必要はありません。
      チーム、部署へとスケールさせ、会社組織全体を対象にできるのです。

      また、自社だけに留まらず、複業にて他の会社を支援してきました。
      ソフトウェア開発の現場だけではなく、バックオフィス系、営業系、エグゼクティブチームなど、あらゆるところで活用できるのです。

      スクラムマスターのノウハウを活用して、会社という組織を活性化させることを目指してみませんか?
      僕が考えるスクラムマスター業の一つの解をご提供します。
      もしかしたらスクラムマスターとしての「あり方」や「生き方」なのかもしれません。

    • Koki Shimizu
      Koki Shimizu
      Scrum Master
      N/A
      schedule 1 year ago
      Sold Out!
      20 Mins
      Talk
      Beginner

      みなさん、スプリント期間ってどうやって決めてるんですか?なんとなく決めてませんか?

      なんとなくでも、きっと開発チームの頭のなかにある”これまでの経験”によってひねり出された期間がスプリント期間になっているんじゃないですか?

      スプリントが終わったら”潜在的に出荷可能なもの”ができるんですよね?すぐリリースしてください!

      え?リリースできない?あくまで”潜在的に”って言ったじゃない。あとこれとそれとこれとそれをやらなくちゃいけない、あと1ヶ月かかるんだって。

      うちの会社はしがらみが多いから・・・とか。

      プロダクトオーナーと開発チームがDefinition of Doneを共有していないとこんなことになります。

      Definition of Doneは、単なる、「タスクを終わらせるときのチーム内の合意事項」ではありません。

      プロダクトを「リリースして、顧客に届く」までのバリューストリームを示し、そこまでに必要な作業と基準をすべてを洗い出します。

      作業と基準をすべて洗い出して、はじめて、

      • 「潜在的に出荷可能なインクリメント」がどのくらいの期間で作れるのか
      • このプロダクトにスクラムは適用可能なのか
      • スプリント期間が終わってから顧客に届くまでに何をやらなくてはいけないのか、どれくらいの期間がかかるのか

      が明確になりますし、スクラムをはじめる前に明確にしておく必要があります。もちろんその後も継続的にリファインメントされる必要があります。

      これがDefinition of Doneです。

      このセッションでは、忘れられがち(と勝手に私が思い込んでるだけかも知れませんが)なDefinition of Doneの重要性と作り方、維持管理の方法を

      みなさんと考えていきたいと思います。

      とくに規制(FDA、ISO*****等)があるプロダクトや昔ながらのルールのある企業において、スクラムを適用する際には、Definition of Doneを決めることが非常に効果的だと確信しています。

    • KazuhideInano
      keyboard_arrow_down

      KazuhideInano - チームや組織が変革するためのポイント 〜アジャイルコーチの視点から〜

      KazuhideInano
      KazuhideInano
      Agile Coach
      JEI LLC
      schedule 1 year ago
      Sold Out!
      20 Mins
      Talk
      Intermediate

      最近のDXという風潮も追い風となり大企業でもベンチャーでも規模を問わずアジャイル、スクラムに取り組む現場が本当に多くなってきました。

      私は流しのアジャイルコーチをしているのでこういった現場の支援を行うことが主な仕事となりますが、実際のところチームにせよ組織にせよ一筋縄では行かないことがよくあります。時として、今まで培ってきた組織の文化や慣習などのような「今までのやり方」が障壁となってしまうことがしばしばあるからです。

      そこでこのセッションでは、コーチの視点で「うまくいくためのポイント」や「気をつけるべきポイント」などを事例を踏まえつつお話しし、チェンジエージェントを担うみなさんにヒントを持ち帰ってもらえる場としたいと思います。

      ※ここで挙げる事例は一部実例も含みますがあくまで架空のものとなります

    • 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名調整中

      進行役:岩切 晃子

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

    • Jean-Baptiste Vasseur
      keyboard_arrow_down

      Jean-Baptiste Vasseur / Hiroki Arai / KazuhideInano / Kenta Sasa - 「叱ってほしい!」・もし相手のスタンスが読めるならワークショップ

      100 Mins
      Workshop
      Beginner

      チームメンバー同士の会話や1to1でのコミュニケーションをより有効的でより安全にしたい方大集合!

      スタンスカードを使ってロールプレイをしながらコミュニケーションについて考えよう!

    • Akihiro Wada
      keyboard_arrow_down

      Akihiro Wada - チーム・組織の健全性に対する嗅覚

      Akihiro Wada
      Akihiro Wada
      PM
      CyberAgent
      schedule 1 year ago
      Sold Out!
      20 Mins
      Talk
      Intermediate

      日々スプリントを回している中で

      「明確に課題があるわけじゃないんだけど、何か違和感を感じる」

      「仲が悪いわけじゃないんだけど、本音で話し合えているのだろうか?」

      上記のような健全ではないことを何となく感じ、そこから振り返って次の取り組みを考えたことはないでしょうか?

      私はこのように感じることを"嗅覚"に例えています。

      ではその嗅覚はどうやって身に付いたものなのでしょうか?

      アジャイルソフトウェア開発宣言の「プロセスやツールよりも個人との対話を」の背景にその答えが隠れているのではないかと考えています。

      ノンバーバルコミュニケーションにある多大な情報を紐解くことができるかどうかで"嗅覚"を感じることができるのではないでしょうか。

      理屈はいい加減身につけてきたという方々に向けて、「考えるのではなく感じる」という力とは何なのか、それをこのセッションでお話できればと思います。

    • Kazunori Otani
      keyboard_arrow_down

      Kazunori Otani - アジャイルな見積もりと計画づくりと呪われた我々

      20 Mins
      Talk
      Intermediate

      みなさん、進捗どうでしょう?最高ですか?そんなことないよね!なぜならあなた達は呪われている。事前の計画よりも、常に、3倍の期間が必要になる。常にだ!!この呪いは強力であり、解放されるのは難しい。

      さて、我々はどうすればよいだろうか?