インターンシップの企画から運営までスクラムで回してみた!

「急にインターン来るとか言われたけど、何すりゃいいんだ?」
「今忙しいから作業手伝ってもらおうかな。。。」
「部門紹介とか、座談会、あとワークとかやればいいかな」
、、、こんなインターンシップしてませんか?

「どんな学生?」「どんな目的?」「何が成功?」分からないことが多いインターンシップは、漸進的に進めるスクラムと非常に相性が良さそうです。
ならばインターンシップもスクラム的にやったらうまくいきそうじゃないですか?

このセッションでは、開発以外の全てがスクラムに見えてしまう「スクラムの奴隷」がインターンシップをスクラムで成功に導いた体験談と、開発以外にスクラムを適用するためにどのように取り組めば良いかをお話しいたします。

 
 

Outline/Structure of the Talk

  1. インターンシップを突然任されて困惑
  2. インターンシップもスクラムでやればいいんじゃない!?
  3. インターンシップ開始!
  4. インターンシップが終わって

Learning Outcome

  • インターンシップをスクラム的に進める方法を知ることができる
  • 困ったときにスクラム的に考える視点を知ることができる

Target Audience

突然インターンシップの担当になった人/開発以外でのスクラム事例に興味がある人

schedule Submitted 1 year ago

  • 中村 薫(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年に自社サービスをリリースして、やっとアジャイルが腹落ちしてきた気がします。

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

  • kyon _mm
    keyboard_arrow_down

    kyon _mm - チームの再定義 -進化論とアジャイル-

    kyon _mm
    kyon _mm
    Test Architect
    オンザロード
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    チームの再定義 -フラクタルスプリントとフラクタルチーム-

    1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。だから、チームはできるだけ解散してはならない。果たして本当にそうでしょうか?

    私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。

    異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。

    そしてこれらを支える理論として進化心理学、ダーウィンの進化論などの学術的な視座からアジャイル開発を話します。なぜ人間はチームをつくるのか。

  • Woohyeok Aaron Kim
    keyboard_arrow_down

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

    45 Mins
    Talk
    Intermediate

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

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

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

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

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

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

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

  • 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が開催される頃までには何とかなってると思うので、私達がこれからどのようにして再び練度の高いチームを作り上げていったかについてお話しできればと考えています。

  • 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であるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
    この本に共感しぼくらもこんな会社に成りたい!と決意。それを実行してきました。
    会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

  • Tatsuya Sato
    keyboard_arrow_down

    Tatsuya Sato - RSGT 100分ハッキング - 出張短縮版OSS Gate ワークショップ -

    Tatsuya Sato
    Tatsuya Sato
    Software Developer
    DENSO
    schedule 1 year ago
    Sold Out!
    100 Mins
    Workshop
    Beginner

    開発チームのスキルによって、開発の時に重要な要素である実行可能性(Feasibility)は大きく左右されます。価値のあるバックログアイテムが用意されても、それを実現でき、お客さんに届けることができなければ意味がありません。実現することこそが開発チームの本懐であると思います。

    現在のソフトウェア開発において、オープンソースソフトウェア(OSS)を活用することは当たり前となってきています。もちろんOSSも人が作ったソフトウェアですのでバグはありますし、期待した機能を持っていなかったりもします。では、そういった不具合や期待した機能を持っていないことに気づいた時に、どうしたらいいでしょうか?居酒屋で見つけたバグをネタにビールを飲むことでしょうか?「こんなバグがあるなんて、酷い!」「このOSSは、○○が無いのでダメだ!」などとSNSなどで投稿することでしょうか?

    残念に感じたり、時には怒りを覚えるかもしれません。ですが、それはとても素晴らしいチャンスです。そう、OSSに貢献するチャンスです。しかし、残念なことにOSSへの貢献がとても高いハードルと感じている方もいらっしゃるようです。

    ようこそ、OSS Gate ワークショップへ!
    このワークショップでは、OSSに貢献したいけど最初の一歩を踏み出せずにいる方の背中を後押しするワークを行っていただきます。終わった時には、小さいかもしれませんが、OSSへの貢献に確実な一歩を踏み出せたと思えっていただけるでしょう。そして、普段の開発で、それまでよりもOSSに対して身近に感じていただけると思います。

  • 藤原大
    keyboard_arrow_down

    藤原大 / Takao Oyobe - 輝く未来を抱きしめて。アジャイルコーチ、スクラムマスター10年戦記

    45 Mins
    Talk
    Intermediate

    このセッションのプレゼンテーターの二人は、過去に同じ開発プロジェクトにおいて、アジャイル開発を経験しました。ひとりはアジャイルコーチ、スクラムマスターとして参加し、ひとりはエンジニアとして参加しました。

    そのプロジェクトは1000人を超える開発組織の中で初の「アジャイル開発を導入する」とうたったプロジェクトでした。もちろん途中、困難はありましたが、無事にプロダクトはリリースされました。

    プロジェクトが終わり、ふたりは異なる環境でスクラムマスターやアジャイルコーチの経験を積んでいきます。

    共に歩んだアジャイルプロジェクトから10年。それぞれの経験をふりかえりながら学びを確認し、今後の10年を考えるセッションです。

  • 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)を採用した大規模スクラム体制に移行できたのか、具体的な課題とその対処を交えて紹介します。

  • Masamichi Otsuka
    keyboard_arrow_down

    Masamichi Otsuka - 継続的レトロスペクティブ

    20 Mins
    Talk
    Beginner
    伝えたいこと

    プロダクトやチーム、そしてスクラムの継続性を維持するうえで、「ふりかえり」は最も重要なイベントです。

    スクラムに取り組み始めると、多くのチームが失敗と学習を繰り返して自分たちなりのスクラムを定着させていくことになると思いますが、その中でポイントとなる重要なイベントがふりかえりではないでしょうか。様々な事情からいきなりスクラムに変えることができないチームも、まずはふりかえりから導入している事例をよく耳にします。

    私自身もスクラム開発に取り組み始めてから、スクラムマスターとしてふりかえりをファシリテートしていく中で、「あの時のふりかえりでチームが前進した」「あの時のふりかえりでチームが新たな学びを得た」と感じたことが多々あり、ふりかえりはスクラムチームの継続性にとって重要なイベントであると実感しています。

    この経験から、私が最初にスクラムに取り組んだ現場での1年間をふりかえりの切り口で改めて整理し、その後の別のチームではふりかえりを軸にチームをアジャイルにしていくことに取り組んでいます。それらの実例をご紹介するとともに、この経験を踏まえて私が考える継続性を意識したふりかえりについてお伝えします。

    継続的なふりかえりとは、チームの過去・現在・未来をつなぐ支援をすることです。

    • 過去
      • チームは以前と比べて何がどのくらい変わったか
      • 以前のふりかえりでの課題がどう解決したか
    • 現在
      • チームが今一番困っていることは何か
      • このスプリントでどんなことが起きたか
    • 未来
      • プロダクトはどうなるのか
      • チームはどうしたいのか

    そして、継続的なふりかえりで特に私が意識しているのは以下の3つです。

    • タイムボックス
      • 時間オーバーしたり忙しいからと言って中止したりしない
      • 継続的な状態をつくる基礎として定期的に同じリズムで実施することが大切です
    • ふりかえり以外でのふるまい
      • ふりかえりを意識してチームを観察し、支援する
      • スプリント中のいつでも、ふりかえりの価値を高める機会があります
    • 楽しむ
      • ふりかえりを楽しむ
      • 楽しくないふりかえりは継続が困難です
    スクラムと私

    株式会社ラクス は中小企業向けのクラウドサービスを提供し、19期連続増収で事業拡大中の会社です。私は2011年に入社し、BtoCサービスや北米向けサービスなどの新規事業の開発を経験した後、主力サービスである楽楽精算の大阪開発チームをリーダーとして立ち上げ、2018年からスクラム開発に取り組みました。スクラム開発に取り組んだことで、過去の開発経験も含めてチームが不確実性と向き合い敏捷性を高めていくことの重要性を改めて実感しました。2019年4月からは10年以上続くメール配信サービスの開発チームに異動し、マネージャとして従来型の開発プロセスを少しずつ改善してチームのアジリティを高めていくことにチャレンジしています。

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori / えすさん - ふりかえり実践ワークショップ RSGT出張版

    100 Mins
    Workshop
    Intermediate

    あなたのチームのふりかえり(レトロスペクティブ)はうまく機能していますか?マンネリ化していませんか?

    このワークショップは「ふりかえり実践ワークショップ」のRSGT特別版です。
    以下のような悩みを持つ方に、ふりかえりの楽しさを知ってもらいたいと思い、このワークを実施いたします。

    • チームでふりかえりをやっているが、どこかうまくいかないというモヤモヤを抱いている人
      • ふりかえりのやり方が毎回同じでマンネリ化している
      • ふりかえりで毎週同じ意見しかでない
      • ふりかえりが楽しくない、辛い
      • 反省会みたいな場になってしまっている
    • チームのふりかえりをこれから始めたい人
      • スクラムをこれからやってみよう、と思っている
      • ふりかえり(レトロスペクティブ)をどう始めたらいいか悩んでいる
    • ふりかえりをもっと楽しみたい人
      • 自分たちでふりかえりは楽しくやっているけれど、他のやり方にも手を出してみたい
      • 他の人のファシリテーションを見てみたい

    スクラムにおけるふりかえり(レトロスペクティブ)とはなにか、という基本から、ふりかえりの型や様々なアクティビティの体験を含む、ふりかえりを実践するすべての人に楽しんでいただけるワークショップです。

    みんなで楽しいふりかえりを実践しましょう。

  • Junki Kosaka
    keyboard_arrow_down

    Junki Kosaka / Ikuo Suyama - 立ち上がれ、デベロッパー!私たちにとって大切な3つの勇気

    20 Mins
    Talk
    Intermediate
    • 「ビジネスになったアジャイルをエンジニアに取り戻せ!」

    師匠:David氏からDevOpsDays Tokyo 2019で強いメッセージを受け取った直後に臨んだ認定スクラムデベロッパー研修。エンジニアがオーナーシップを持ってプロダクトと向き合うこと、スクラムをやるためにはXPが必要であるなど、私たちは師匠から熱い想いやメッセージを受け取りました。

    これを経て、改めて『エクストリームプログラミング』(2015/6/26 Kent Beck (原著), Cynthia Andres (原著), 角 征典 (翻訳))に目を通すと、

    “XPが価値、原則、プラクティスを用意しているのは、ガイダンス、チャレンジ、説明責任を提供するためだ”

    とあり、XPは単なるプラクティス集ではなく、エンジニアは自分たちが取り組んでいることに対してちゃんと価値を理解すべきであり、それを周りの人たちに責任を持って説明していく必要性があることを強く訴えている、非常に刺激的なものであることに気づきました。

    「お客様に継続して最も高い価値を届けられるのは自分たちだ!」と自負をしながら、より高いスキルやデザインを追求出来る。

    クラムとXPを最高のチームで体現していく勇気を、今こそ分かち合いましょう!

    • 「社内なのに請負開発みたいだ・・・」

    ”ビジネス側” から言われたものを言われた納期でつくる。私達は内製のプロダクトのはずなのに、まるで請負契約のような開発をしていました。

    そこから、開発チームが少しずつ変化し、プラクティスを実践し、”ビジネス側” を巻き込み、プロダクトの価値をともに考えるチームに成長してきました。

    その変化の中で、プロダクトが価値を届けることにフォーカスし、チームの中心に据えることができたのは、師匠から学んだ価値、原則、プラクティスと、その実践の影響が多分にありました。


    もっとより良いチームになりたい。もっとより良いプロダクトを開発出来るようになりたい。そんな想いで立ち上がり、一歩ずつビジネスと向き合えるようになったチームの今をお話します。

  • 20 Mins
    Talk
    Beginner

    クライアントからアジャイルな開発体制を作って欲しいと要望される。
    アジャイルな開発体制を求めている理由を聞いていくと、「ビジネスインパクト」だという。
    今までにない新しいプロダクトが素早く創れることを期待している。

    本当にそれだけで「ビジネスインパクト」が得られるのか?
    開発部門だけでなく、新たなビジネスモデルやオペレーティングモデルを実現するためにも他部門を横断して価値を生み出さないといけないのではないか。

    そのような本質的な問いを抱いていたアジャイルコーチのGupta。
    アジャイル開発の外側で、組織変革に携わっているreborn founderのハブチン。
    呑みながら二人が対話したとき、仕組みや体制だけでなく、社員のモチベーションも重要で、ある仮説を立てた。

    仕組み×モチベーション=組織変革

    仕組みだけだと形骸化するし、
    モチベーションだけに頼ると不安定な状態になる。

    両方の要素をバランスよく組み合わせることによって、
    組織が変革し、「ビジネスインパクト」が得られるのではないか。

    それではモチベーションの正体は何なのか。
    鍵は個人のミッションの見える化にあった。
    個人のミッションとチームのミッションが重なり合ったとき、
    真のアジャイルが生まれていく。

    ハブちんとGuptaの会話で生まれた様々な気付きをこの場でシェアしたいと思っています。

  • Mitsuyuki Shiiba
    keyboard_arrow_down

    Mitsuyuki Shiiba / 伊藤 泰斗 / Shungo Ito - 新卒2年目の2人の伊藤さんがもたらしてくれたスクラムとモブプロといい笑顔

    45 Mins
    Talk
    Beginner

    椎葉です。新卒として入社したての初々しい2人が、戸惑いながらも頑張っていたのを、僕がチョコを食べながら遠くから見守っていたのは、去年の春のことです。

    それから1年もたたないうちに、2人ともがそれぞれのチームの中心になって活躍しはじめ、組織に新しい変化を与え続けてくれています。

    びっくりする!すごい!嬉しい!

     

    このセッションは新卒2年目の2人の伊藤さんが

    • 悩みながらスクラムやモブプログラミングを導入し
    • 先輩たちを巻き込んで挑戦し、学習し、それを何度も繰り返して
    • 組織に新しい変化を与えて続けてくれている

    そんな勇気の出るお話です。2人のいい笑顔にはいつも癒やされます。

     

    拡大していく組織の中で取り組んでいる、強い思いを持った強いチームづくり

    by しゅんごさん

    拡大していくサービス・組織の中で任された難しいプロジェクト。

    チームの全員がスクラムやモブプロ未経験。

    それでも、この難しい状況を乗り越えてユーザーにプロダクトを届けるたんだという強い思いから

    試行錯誤をしながらスクラムやモブプロに取り組んできました。

    その中で、どんな問題にぶつかって、何を考え、どんな風にそれを乗り越えてきたのかをお話します。

     

    テックリードの卒業を見送ることができるチームづくり

    by たいとさん

    テックリードしか対応できない。テックリードしか知らない。テックリードがいなくなったら回らない。

    僕らは少し前までそういう状況にいました。

    このままでは良くない!属人化をなんとかしたい!と考え、モブプログラミングを導入しました。

    その結果、最終的には、ほとんど引き継ぎなしでリーダーの卒業を見送ることができました。

    モブプログラミングに取り組む中で、若手として何を悩み、何を学び、そこでどんな風に向き合ってきたかをお話します。

     

    ということで、2人がどんなことを考えて、何に取り組み、どんな風に成長してきたのか、その話をご紹介したいと思います。

    ぜひ、2人の成長のストーリーといい笑顔を見に来てください。

  • Kazuhiro Niwaya
    keyboard_arrow_down

    Kazuhiro Niwaya / Yusuke Amano - 残業まみれで属人的だったサイボウズ人事部をスクラムで改善した話  ~抜けたエースの穴をチームで乗り越えるまで~

    20 Mins
    Talk
    Beginner

    サイボウズの人事部採用チームは、
    採用計画の立案から面接の実施、合否連絡、内定者のフォロー、イベントの出展、説明会の実施といった業務を日々行っています。
    採用チームに異動してきて2年目の始めに、リーダーを引き継ぐことになりました。
    これまで経験豊富なリーダー中心に業務を進めてきた状態だったので、経験の浅い自分がリーダーになることに不安を感じていました。
    自分個人がエースの抜けた穴を埋めるのではなく、チームの皆でカバーできるような進め方をしたいと悩んでいたところ、
    開発チームで導入が進んでいたスクラムが目に止まりました。
    スクラムが人事の業務改善にも役立つと感じ、導入を決意し、2年ほどスクラムをベースにした業務改善を進めてきました。
    プランニングやふりかえりで地道な改善を重ねた結果、モブ作業やカンバンを活用が進み、メンバーの残業が減り、チームのベロシティも向上しました。
    現在はチームでタスクがコントロールでき、理想のチームに向かう良い状態が作れています。

    改善の過程で起きた問題やそこから学んだこと、チームに起きた変化を紹介したいと思います。

  • Kazumichi Sakata
    keyboard_arrow_down

    Kazumichi Sakata - 価値のない CD はアジャイルではない!(仮)

    Kazumichi Sakata
    Kazumichi Sakata
    Product Manager
    Pivotal Labs
    schedule 1 year ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    CD(継続的デプロイ)は開発からデプロイまでの時間を縮めることで、デリバリーのスピードを向上させ、プロダクトの問題を早期に検知することができます。一方で、デプロイの回数とスピードを優先させるだけではITビジネスにとって価値のあるプロダクトができるとは限りません。今回のセッションでは、CD の良さを活かしながら価値のあるプロダクトを提供し続けることができるチームの取り組みを弊社の事例を交えながらご紹介したいと思います。

  • Akihiro Wada
    keyboard_arrow_down

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

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

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

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

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

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

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

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

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

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

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

  • Yoshitaka Hirano
    keyboard_arrow_down

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

    20 Mins
    Talk
    Beginner

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

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

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

  • yusuke kato
    keyboard_arrow_down

    yusuke kato - スタートアップの事業成長とともに、プロダクトチームがスケールしていくために取り組んだ挑戦やその成長痛

    yusuke kato
    yusuke kato
    product engineer
    atama plus
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    atama plusは創業期から「プロダクトファースト」の文化を大切にし、アジャイルにプロダクトづくりをしています。
    プロダクトチームだけではなく、カスタマーサクセスチームやコーポレートチームもアジャイルな考えが浸透しており、全員で良いプロダクトを作ろうという文化が根づいています。

    現在では社員数も50人を超え、当初は1チームだったプロダクトチームも今は3チーム(+α)となりました。

    しかし、決して順風満帆に3チームにスケールしたわけではありませんでした。
    初めてのチーム分割を行った際は、うまく機能せず、再度1チームに戻す決断しました。また、一度チームを戻す決断をした後も、組織の成長の中では、チームを分割していく価値があると考え、再度チーム分割にチャレンジしました。

    本セッションでは、特にプロダクトチームにフォーカスをあて、毎月のように人が増えていくスタートアップの中でプロダクトチームを1チーム→3チーム(+α!)にスケールさせていくために行った取り組みや実際におきた課題や痛みなどを実例を交えてお話できればと思っています。