はじめに

本セッションはRSGT2020にてご好評いただきました「見積りしないスクラム」の続編となります。

見積りをせず、どうやってスクラムを実践するのか。RSGT2020では、我々の方法論とその背景にある理論を紹介させていただきました。
本セッションでは、それらHOWの部分に加え、時間の都合上ご紹介できなかった「見積りしない開発」にたどり着くまでの経緯や、
見積りをやめてから起こった問題やその対処についてもご紹介します。

また、現在我々のチームでは、書き入れ時である年度末に向けて、並列で走る納期駆動の小さなプロジェクトをこなしています。
以前は「見積りしない開発」は向いていないと考えていた「納期優先」な状況でも、見積りをすることなく納期を守っています。
この状況で考えたことや、納期駆動の状況でアップデートされた方法論についてもお伝えできればと思います。

Introduction

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

しかしながら、見積りには負の側面があることもまた事実であるように思われます。
RSGT 2019 Key Note において、 Chris Lucian(@christophlucian) 氏は見積りのコストについて言及し、 #NoEstimates のコンセプトを紹介しました。

そもそも、なぜ見積りが必要なのでしょうか?

そして、本当に必要なものは見積りなのでしょうか。

この問を繰り返すうち、私達は「ほんとうに必要なものは見積りではなく、意思決定ではないか?」という仮説にたどり着きました。
それから、見積りの負の側面と向き合い、「見積り」をせず「意思決定」をする方法を模索し始めます。
以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。

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

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

見積りの負の側面と価値

見積りの負の側面について、私達の考えをまとめます。
私達が考える見積りの負の側面は、以下の「3M」に集約されます。

  • 数値化による「コミット圧力」… 納期の「ムリ」
  • 数値化による「仕事量の最大化」 … 仕事の「ムダ」
  • 数値化による「正確であるという錯覚」 … 精度の「ムラ」

そしてこれらは、見積りを「数値化すること」により発生すると考えています。

もちろん、見積りは負の側面ばかりではありません。
見積りの価値について、見積りがなぜ必要なのか、という問いについて、AEPに完結に記されています。

見積りと計画づくりは、期日やスケジュールを決定するためだけのものではない。
計画づくりとは価値の探求なのだ。
– アジャイルな見積りと計画づくり

見積りだけでなく、価値の探求のための「計画づくり」をせよ、とあり、
見積もり自体ではなく、この「計画づくり」に必要な判断材料として見積もりが必要であると考えられます。

これらの考察から、私達は「#NoEstimates / 見積りしない」開発を

見積りの負の側面の根源である「数値化」を行わず、
見積りから取り出したい「価値」を抽出する手法

と定義づけています。

スクラムと見積り

私達はスクラムを実践しています。

見積りを行わなくても、スクラムは成立するのか。あるいはこれはスクラムと呼べるのか。
見積りをやめて以来、ずっと問い続けてきました。

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

  • リリース計画づくり … PBIの優先順位付け
  • スプリント計画づくり … スプリントのキャパシティを測り、コミットメントを高める
  • 進捗管理 … 残作業を確認し、計画を更新する

見積り自体を行うことなく、これらの意思決定をするための情報を抽出することでスクラムを行う。
これが私達のたどり着いた答えです。

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

  • 優先順位付け / バックログリファインメント
    • PBIのサイジング … 直近のPBIを 1スプリント以下のサイズ に調整
    • C3D(Cost of Delay Divided by Duration)
  • キャパシティ / スプリントプランニング
    • PBIのスループット
    • スプリントゴール
  • 進捗管理 / デイリースクラム
    • SBIのスループット
    • モンテカルロ法 … 過去データからの ‘予測’
  • スプリント(開発作業)
    • モブプロ
      • WIP制限 … 安定性・予測可能性の向上

「見積しない」 開発と現実

このプロセスは教科書上の理論だけの話ではなく、現実のプロダクト開発で行われています。
通常のソフトウェア開発と異なり、「見積りしない」ことが現実のソフトウェア開発にどのような影響を与えるのかについて、私達の事例をご紹介します。

  • 「見積りしない」の始め方
    • どのように上司を、ビジネスを巻き込むのか?
  • 「見積りしない」計画づくり
    • どのように先の見通しを立てるのか?
  • 「見積りしない」開発の課題
    • 見積りをやめてから、チームに降りかかる課題と対応
  • 「見積りしない」で納期を守る
    • 納期が設定された小さなプロジェクトが複数件並行で走る状況で、見積りせず納期を守るには?

まとめ

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

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

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

 
 

Outline/Structure of the Talk

0. イントロダクション - なぜ見積りをやめたのか

  • 見積りしていたときの開発
  • 見積りをやめてからの開発

1. 見積りの価値と負の側面

1-1. 見積りの負の側面

  • Hidden Cost of Estimates / Chris Lucian
  • 見積もりの3M(ムリ・ムダ・ムラ)

1-2. 見積りの価値

  • 計画づくり
  • 意思決定に必要な情報
    • コスト、期間、情報

2. スクラムと見積り

2-1. スクラムガイドにおける見積もりの役割

  • リリース計画 ... 優先順位
    • 「プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。」
    • 「プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをする」
  • スプリント計画 ... キャパシティ/コミットメント
    • 「プロダクトバックログから選択するアイテム数については、開発チームが責任を持つ。」
    • 「開発チームは見積りに対して責任を持つ。」
  • 進捗の追跡 ... 進捗
    • 「スプリントのいずれかの時点で、スプリントバックログの残作業を合計する。」

3. 「見積りしないスクラム」

3-1. バックログリファインメント

  • PBIのサイジング
  • C3D

3-2. スプリントプランニング

  • キャパシティ ... スループット
  • スプリントゴール
  • SBIのサイジング

3-3. デイリースクラム

  • タスクの残数と残日数
  • モンテカルロ法

3-4. 開発作業

  • モブプログラミング
  • リードタイム/スループット安定性
  • デルファイ法
  • 対パーキンソンの法則
  • スクラムの価値基準とモブプログラミング

4. 現実と #NoEstimates

4-1.「見積りしない」の始め方

  • どのように上司を、ビジネスを巻き込むのか?

4-2.「見積りしない」計画づくり

  • どのように先の見通しを立てるのか?

4-3. 「見積りしない」開発の課題

  • 見積りをやめてから、チームに降りかかる課題と対応

4-4. 「見積りしない」で納期を守る

  • 納期が設定された小さなプロジェクトが複数件並行で走る状況で、見積りせず納期を守るには?

Learning Outcome

  • なぜ見積もりが必要なのか
  • 見積りの負の側面をどう回避するのか
  • 見積りしないスクラム
    • うまくいく一つの実装
  • 見積りをやめたチームで何が起こるのか

Target Audience

見積りに対して懐疑的な考えをお持ちの方 / 見積りは必ず必要だと考えている方

schedule Submitted 6 months ago

Public Feedback

comment Suggest improvements to the Speaker

  • Liked Yuichi Tsunematsu
    keyboard_arrow_down

    Yuichi Tsunematsu - もりあがるスプリントレビューをしよう

    Yuichi Tsunematsu
    Yuichi Tsunematsu
    Manager
    Retty Inc.
    schedule 6 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    あなたのスプリントレビューは盛り上がっていますか?

    アジャイル開発を始めて4年になりますが、意義のある・活気のあるスプリントレビューができることもあれば、お通夜のような・審議のような・辛いスプリントレビューをしてしまうことが今でもあります。皆で褒め合うだけでなく、皆で責め合うだけでなく、「またやりたい」と誰もが感じられるスプリントレビューを開催する秘訣はないのでしょうか。

    Regional Scrum Gathering Tokyo 2020でこの悩みを共有したところ様々な方からアドバイスをいただけました。このセッションではその内容を整理し、実際に自分たちで実践した感想を加え、よりよいスプリントレビューをするための知見を共有したいと思っております。

  • Liked Kazutaka Matsusaki
    keyboard_arrow_down

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

    20 Mins
    Talk
    Beginner

    Reginal Scrum Gathering Tokyo 2020 にて講演させていただいた内容の再講になります。
    ぎゅっと圧縮してお話しさせていただきます。


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

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

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

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

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

    Kazuki Mori - さあ、楽しいふりかえりを始めよう

    50 Mins
    Talk
    Intermediate

    大事な活動である「ふりかえり」。だが、難しい活動でもある。

    スクラムの重要なイベントの一つである「スプリントレトロスペクティブ/ふりかえり」。
    チームを自己組織化へと導く大事なステップでもあり、スクラムの中でも一番「チームによるチームのための活動」だと言えると考えています。

    スクラムを始めたとき、多くの人が直面するのは、「ふりかえりがうまく機能しない」ということです。
    ふりかえりが反省会のようなムードになってしまう。
    チームのためのアクションが出ず、なかなかチームがまとまらない。
    アクションは出たものの、なかなかカイゼンされているように思えない。
    こういった悩みを持つ多くの現場を見てきました。

    ふりかえりは、難しい活動の一つとして考えられがちです。
    時間対費用効果が出ているのか、なかなか計測がしづらいですし、効果がすぐに現れない場合もあります。
    他のイベントと違い、ふりかえりがうまくいかなかったときに、「この活動は価値がないものだ」と感じ取られてしまいがちなのです。
    そのまま、ふりかえりが行われなくなってしまうのは、とても悲しいことです。

    ふりかえりとファシリテーション

    ですが、ふりかえりにはチームが成長するために大事な要素がたくさん詰まっています。
    そのうちの一つが「ファシリテーション」という考え方です。

    進行役としての「ファシリテーション」ではなく、促す者としてのファシリテーション。
    スクラムマスター一人がファシリテーターなのではなく、チーム全員がファシリテーター。
    チームが「ファシリテーション」を意識したとき、あなたたちのふりかえりはきっと良い方向へと変わります。

    ファシリテーションというものをあなたがどうとらえるか。
    そのとらえかたが変わると、きっと新しく見えてくるものがあるでしょう。

    このセッションについて

    このセッションでは、あなたがふりかえりの中で行うファシリテーションを考えるときの気付きを提供します。
    チームの形成、そしてチームの成長・混乱・成熟、そしてチームの解散。タックマンモデルのチームの推移に合わせて、どのようなファシリテーションを検討するとよいのか、といういくつかの事例を示します。

    また、私がふりかえりを突き詰めた結果見つけた「8つの型」についてお話します。
    ふりかえりの守破離」を通じて、ふりかえりを導入・成長・拡張していく流れについて、お話させていただきます。

    「自分のチームでは今どんなことを意識しながらファシリテーションしているだろうか」
    「自分のチームのふりかえりの現状はどんなものか」をイメージしながら、セッションに参加していただければ幸いです。

  • Liked kyon _mm
    keyboard_arrow_down

    kyon _mm / neno neno - 道産子が上京してからスクラムを2回はじめた話

    50 Mins
    Talk
    Beginner

    北海道でそだち上京、23歳で組織初のスクラム導入。転職してなんちゃってアジャイルだと数年たってから気付いてスクラムの再導入。どちらも期待と不安がいりまじった時間をすごしましたが、とても楽しい時間になりました。私が当時どのようにスクラムを導入したり、変化させていったのか。そしていまならどうやるのかという考察をお話します。

  • Liked Takao Oyobe
    keyboard_arrow_down

    Takao Oyobe - It dependsから脱却するスクラム

    50 Mins
    Talk
    Intermediate

    チーム、組織、会社、役割、契約、業種・・・
    私たちの仕事にはいろんな状況があるので、つい、
    「It depends(ケースバイケースだね)」
    と言いたくなってしまうときがあります。

    しかし、私たちがアジャイル開発やスクラムからヒントを得て成し遂げようとしているのは、そのいろんな状況の中で「It depends」ではない答えを出すことです。

    こんにちは!

    こんにちは、及部です。

    私は、2009年に楽天に新卒入社し、アプリケーションエンジニアとしてプロダクト開発の仕事に携わってきました。その中でもっとよいプロダクトをよいチームで作りたいと思い、スクラムやモブプログラミングを学んで、実践してきました。そして2019年には、チームFA宣言からのチーム転職をして現職であるデンソーでエンジニアとして働いています。

    組織上の役割やプロダクトのドメインや会社が変わっても、「よいプロダクトをよいチームで作りたい」という想いは変わりませんでした。コードを書くだけではなく、チームにもプロダクトにも言い訳をしない自分を、そしてチームを目指して試行錯誤してきました。

    伝えたいこと

    教科書にあるスクラムとは違うかもしれないけれど、プロダクト開発のいろんな状況において言い訳をしないために、どのように考えてどのようにチームを実装してきたのかお伝えしたいと思います。

    つい言い訳したくなってしまう人やスクラムをやっていても「これでいいんだっけ?」と悩んでいる人に、少しでも勇気と元気を与えて、行動のヒントを与えられるような時間にしたいです。

    それでは、スクラムフェス札幌大会でお会いしましょう。アディオス!

  • Liked Tadahiro Yasuda
    keyboard_arrow_down

    Tadahiro Yasuda - 日本にJoy,Incを創る!どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡

    Tadahiro Yasuda
    Tadahiro Yasuda
    CEO
    Creationline,Inc.
    schedule 6 months ago
    Sold Out!
    50 Mins
    Talk
    Beginner

    会社の文化(カルチャー)変革の7年間の軌跡。

    2013年ごろ、色々な問題が噴出し、会社としても個人(経営者)としてもどん底の状態でした。
    そこから、色々な取り組みを行い、少しづつ会社の状態がよくなり素晴らしいメンバーにも恵まれ、会社の良い文化(カルチャー)が形成されるようになりました。

    その過程のなかで2017年8月「Joy,Inc.」に出会いました。
    「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
    この本に共感しぼくらもこんな会社に成りたい!と決意。それまでの会社の文化を良くするための取り組みを更に推進していきました。

    会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

    今回は、Regional Scrum Gathering Tokyo 2020での講演(20分)のロングバージョンとしてもう少し詳しく、それぞれの取組みについてお話したいと思っています。

    https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11835/joyinc3

  • Liked Yusuke Amano
    keyboard_arrow_down

    Yusuke Amano - 本当に強いプロダクトを作るためのプロダクトオーナー支援のはじめかた

    Yusuke Amano
    Yusuke Amano
    Scrum Master
    Cybozu, Inc.
    schedule 5 months ago
    Sold Out!
    50 Mins
    Talk
    Beginner

    みなさんの現場ではすでにスクラムを導入済みでしょうか。

    最初は仕事が終わらない、品質が低い、改善が進まないといった問題が沢山出ていたチームも、スクラムを始めると少しずつ安定して開発ができるようになってきます。ある程度のベロシティが出て、不具合の数もそれほど多くなく、割り込みタスクも大きい問題にはならなくなるでしょう。しかし、チームは魅力的で顧客の問題を解決する本当に強いプロダクトを作ることができているでしょうか。

    本当に強いプロダクトを作るためには、プロダクトオーナーの支援が欠かせません。プロダクトオーナーが不確実性と向き合い、素早い仮説検証を繰り返して、価値の高いアイデアを見つけられるようになる必要があります。開発チームはプロダクトオーナーの活動に参加・協力し、スクラムマスターはその取り組みを様々な方法で支援することができます。

    このセッションでは、自分がスクラムマスター/アジャイルコーチとして複数の現場で取り組んできたプロダクトオーナー支援の活動と、そこから学んだことについて紹介したいと思います。

  • Liked Jun Yamamoto
    keyboard_arrow_down

    Jun Yamamoto - (自称)エバッキーの愛弟子!が札幌でエンタープライズシステム開発のスクラムマスターをしてみたお話

    20 Mins
    Talk
    Beginner

    基幹系システム開発は、ウォーターフォールで着実に品質を積み重ねて行うべきもの。

    そういった固定観念が社内外充満している中、
    SoEな領域だけでなくSoRにもスクラムが適用されたプロジェクトメンバー約200名のエンタープライズ・アジャイルSIプロジェクトに
    札幌からスクラムマスターとして参画してみた顛末をセッションで共有いたします。

    特段教訓めいた話に帰結するわけでもなく、発生したさまざまな出来事を通し、
    札幌のエンジニア達がLeSSに近しい姿をトライ&エラーしていく
    天竺への道程(現在進行形)を等身大で聞いていただければと思います。

    • アジャイルやスクラムも知らずに集められたメンバーの戸惑い。
    • 複数拠点横断スタッフとのリモートワークによるチーミング。
    • クライアントとのカルチャーギャップ。
    • 自分自身含めたメンバーのマインドセットの成長。
    • などなど・・・

  • Liked Yasushi Hagai
    keyboard_arrow_down

    Yasushi Hagai / Stefan Nüsperling - 未経験者中心のチームとベテラン中心チーム、Management 3.0のプラクティスはどう作用したのか?

    75 Mins
    Workshop
    Beginner

    まだ”色”がついていない若手未経験者中心のチーム。『いままでやってきたやり方』そもそもが無いのでなんでも受け入れるが、主体的に「こうしよう」と動けるだけの経験・知識はまだ無い。

    一方、『今までやってきたやり方』の蓄積はたっぷりのベテラン勢中心チーム。打っても響かない感があったが、果たして本当にそうなのか?
     
    使ってみたManagement 3.0のプラクティス
    • Kudo Wall
    • Celebration Grid
    • Moving Motivators
    • Delegation Poker
    • Competency Matrix
    はそれぞれのチームにどう作用したのか。
    役に立ったのか?、役に立たなかったのか?、チームはどう変わってきたのか?
    現場での事例、仕掛けた側とチームそれぞれにどのような学びがあったかを話します。
     
    そして、Management3.0を日本で展開する、NüWORKS のStefan Nüsperlingさんといっしょに、簡単なManagement 3.0の紹介、Management 3.0のプラクティスである
    • ムービングモチベーター
    • デリゲーションポーカー
    のワークショップを行います。
    ムービングもチベーターは、「10の本質的なモチベーション」のカードを用いて、モチベーションの源泉、価値観を表明し合うツールです。デリゲーションポーカーとは、7枚のカードを用いて、意思決定領域ごとの認識をマネージャーとメンバーとですり合わせながら権限委譲レベルを決めるというツールです。羽飼がやってみたところ、『意外』も『納得』もあり、とても興味深い結果が得られました。是非体験していただきたいです。
     
     
    Management 3.0 は、オランダ出身のヨーガン・アペロ(Jurgen Appelo)が作ったアジャイルリーダーシップ概念です。
    「人ではなく、システムをマネージするべき」というアイディアに基づいています。
  • Liked Tomonori Fukuta
    keyboard_arrow_down

    Tomonori Fukuta - Scrum for people who working remotely

    20 Mins
    Talk
    Intermediate

    (作成中)

    ひょんなことから委託元はおろか開発チームのメンバー全員別々の場所で働いているチームに関わることになりました。

    別拠点、別組織、別会社、SIer、ベンチャー、フリーランス、リモートワーカー...どうやってチームになっていくのか、その過程において、自らもその1ノードでしかない人間に何ができるものなのか。

    「場」の無いところに「場」をつくる、そんな仕事の様子をお伝えできればと思っております。

  • Liked Yoh Nakamura
    keyboard_arrow_down

    Yoh Nakamura - これまでと違うやり方に取り組む時にうまくいくかもしれない方法とその落とし穴

    20 Mins
    Talk
    Beginner

    これまでのやり方に比べて、よりよさそうなやり方に変えてみるには知識と勇気、そして作戦が必要です。
    またそのようなことを進める中で様々な壁にぶつかります。

    このセッションでは自分がこれまでの様々な状況(※)で自分がどのように考え、やってみたこと、その時には越えることができなかった壁のこと、そこから得たことなどをお話します。

    ※様々な状況

    • SIerの客先常駐の現場
    • SIerのチームリーダー
    • 事業会社のマネージャー
    • アジャイルコーチ
  • Liked Tsukasa Yokoyama
    keyboard_arrow_down

    Tsukasa Yokoyama - 突破力 - 大企業の札幌支社に中途入社して直面したこと

    Tsukasa Yokoyama
    Tsukasa Yokoyama
    Producer
    Rakuten
    schedule 5 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    まるで自分たち4人だけ隣のグランドでサッカーをやらされているようだ
    と私は思いました。2012年ごろのことです。

    約10年前に、まだ設立間もない楽天の札幌支社に中途入社し、
    しばらくは社内システムを担当していました。

    組織移動により、一般ユーザ向けサービスの担当になり、
    最初のBigプロジェクトが楽天のデータセンター移行でした。
    全サーバを、物理サーバからVMに変換しつつ旧DCから新DCに移行するというものです。

    担当サービスのこともまだ良くわかっていないのに
    関係者がどこの誰だかわからない、やらばければいけないことさえわからない。
    わかっているのは期限だけ。

    自分たちには相手の協力が必要なのに、相手からは必要とされていない。
    圧倒的格差。
    無理もありません、だって知られてないわけですから。
    相手も手一杯の仕事を抱えているなか、なんで自分たちをケアしてくれないんだ
    と憤ってみても始まりません。当時は気付けませんでしたが。


    本社や発注元企業がリモートになりがちな地方都市では、このような状況に陥りやすいのではないでしょうか?
    自分のやり方が正解なんて思っていませんが、札幌で働く皆様の気づきの一助になれば幸いと思い自分がどのようにこの状況を突破したかお伝えさせて頂きたいと思います。

  • Liked Noriyuki Nemoto
    keyboard_arrow_down

    Noriyuki Nemoto / Kohei Shoda - 紙粘土スクラムから得たアンチパターン

    20 Mins
    Talk
    Beginner

    アジャイル札幌で人気のコンテンツ「紙粘土スクラム」。
    紙粘土と侮るなかれ、毎回リアルな現場のようなドラマがあります。
    その中の失敗をアンチパターンとして紹介します。

    紙粘土スクラムに特化したアンチパターンではなく、例えば下記のような実際の現場でもあるあるのアンチパターンになっています。


    アンチパターン:チャラオーナー
    対象:PO
    プロダクトオーナーが開発者に対してイメージトークしかしない。例えば「もっとカッコよく」「いい感じで可愛く」「品質をあげよう」など。
    改善ポイント:開発者とPOで具体的な例を挙げて認識合わせをする。事前に画像でイメージを共有する。

    アンチパターン:妄想の暴走
    対象:DEV
    ステークホルダーが近くにいるのに、まったく聞かず仮定を積み上げて難しい仕様や不要なものまで作りすぎてしまう。POまで妄想に加わるとチームとして完全にアウト。
    改善ポイント:仮説という認識を持って、ステークホルダーと対話する。

  • Liked Tsutomu Yasui
    keyboard_arrow_down

    Tsutomu Yasui - Happy Lucky XP ― ケント・ベックに教わったこと

    Tsutomu Yasui
    Tsutomu Yasui
    Consultant
    self-employed
    schedule 5 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    “I do not love the bright sword for its sharpness, nor the arrow for its swiftness, nor the warrior for his glory. I love only that which they defend.”

    ― J.R.R. Tolkien, The Two Towers

    スクラムのイベントなので、エクストリームプログラミングの話をしたいなと思いました。

    私が最初にアジャイルに触れたのは、2000年頃、XPの記事や書籍、さらにXPを導入したプロジェクトにプログラマーとして参画したときでした。まだアジャイルという言葉はありませんでした。ペーペーのSIerプログラマーだった私はXPと遭遇して、プログラマーがさらに大好きになり、同時にただプログラミングが好きなプログラマーではいられなくなりました。プログラミングは趣味も含めて10年以上、フルタイムジョブとしては2年目くらいという、XPに触れたタイミングは幸運でした。

    XPはプログラマーの仕事を楽しくし、人生を幸せにします。プログラマーは指示通りに手を動かす歯車ではなく、創造性と専門知識を持った一個の人間です。同時に、プログラマーは安穏としてプログラムを書いてるだけでは済まず、顧客やその他すべての職種の人とコミュニケーションし、協力して、やるべきことをしなければなりません。プログラマーはプログラマーだから愛されるのではなく、生み出す価値が故に愛されます。XPは究極(エクストリーム)なので、プログラマーは究極的に最高の仕事をします。時間不足やスキル不足に追われる代わりに、ユーザーの期待と品質のバーを最高に設定して越えていく仕事が楽しくないわけがありません。プログラミング、ものづくりという仕事の意味をXPに塗り替えられた私は幸運でした。

    2000年に発行された『XP エクストリーム・プログラミング入門』(第1版)を見返すと、XPのユニークなプラクティスとして紹介されているものがいかに当たり前になっているかに驚かされます。テスト自動化、リファクタリング、コードの共同所有、継続的結合、シンプルな設計。当時の私にとっては、XP、Java、オブジェクト指向設計は不可分なものでした(時代背景的にも多くの人が似た状況だったのではないかと思います)。アジャイルなソフトウェア開発が発達するのと、並行して進歩する開発技術は表裏一体でした。将来当然となるプラクティスに早く触れられたのは幸運でした。

    XPは日本において(だいたい世界でも)現在に続くアジャイルのムーブメントを引き起こした先鋒であり第一の波でした。私はXPに心酔するのと同時にコミュニティに熱狂しました。アーリーアダプターの人たちがたくさん引き寄せられました(一過性ではなく、いまでもずっと活動されている方もたくさんいます)。そうした中で、コミュニティに参加したり、登壇の機会をもらったり、運営側を経験することにもなりました。人前で話をするなんてまっぴら御免と思っていた私にとって、幸運な機会がたくさんありました。

    XPはソフトウェアの作り手と使い手とを引き裂いた人工的な傷口を癒やし、全体性を取り戻す試みです。私は最初にXPに触れられて幸運でした。XPはプログラマーとして守るべき規律を示しながら、プログラマーの本来の役割は顧客やユーザーに歩み寄り、価値を生み出し続けるために一緒に働くことであるという、長く続く道にそうと知らずして進み始められたからです。オブジェクト指向設計やJavaといった技術だけを追求していたら、もしかしたら一生見つけられなかった道です。幸運だったとしか言えません。

    (上記はプロポーザル時点で考えている概要で、今後おおきく変化する可能性があります。4月になったら「XP: An East Asian smiley emoticon representing a happy face sticking out its tongue.」みたいな話になってる可能性もあります。悪しからずご了承ください)

  • Liked Atsushi Nagata
    keyboard_arrow_down

    Atsushi Nagata - ここがすごい!モブプログラミング

    Atsushi Nagata
    Atsushi Nagata
    Agile Coach
    Cybozu
    schedule 6 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    モブプログラミングは、いますごく話題になっています。モブはいいという話が多くされてはいますが、どういうことでいいのでしょうか。そして、モブプログラミングでは何が起こっているのでしょうか。モブで、チームメンバーはお互いにどんなやりとりをしているでしょうか。それがそれぞれにどのように働きかけているでしょうか、その結果、どんな効果が生まれているでしょうか。

    サイボウズでは、日本の開発は全てモブでやっています。そこから戻ることはありません。何が彼らをひきつけているのでしょうか

    私は、そのモブに接した時、衝撃を受けました。そしてその魅力に取り憑かれました。何が起こっているのか、もっと調べたくなりました。そこで、モブのやりとりを徹底的に取っていきました。そこからモブメトリクスというものができて来ました。そのメトリクスを改善していくうちに、虜にさせるモブのメカニズムが見えてきました。そこには、チームが不確実な問題に取り組む際のメンタリティーを高める効果ばかりでなく、高い品質をはじめから組み込んでいく仕組みを支える効果もありました。

    このセッションでは、その膨大な情報から見えて来たモブの活動の何がすごいかをご紹介したいと思います。

  • Liked Tomonori Abe
    keyboard_arrow_down

    Tomonori Abe - 札幌の地でスクラムを実践して得た失敗そして改善

    Tomonori Abe
    Tomonori Abe
    SE
    トラスティア株式会社
    schedule 5 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    数年前から札幌でスクラムを実プロジェクトにて実践してきました。

    まわりではスクラムの事例が少なく、なかなか相談できる環境も多くはない状況でした。

    その中での収穫は、自分たちで考え実践したことにより多くの失敗を経験することができたことです。

    このセッションでは、これまでの経験から得た[失敗]そしてどのように[改善]していったかを紹介します。

    スクラム視点での正解ではないかもしれないですが、これからスクラムに取り組む方や実践していてうまくいかない方の微力ながらヒントになればと思っています。

  • Liked YAMAKAWA, Hiroto
    keyboard_arrow_down

    YAMAKAWA, Hiroto - 学生に「チーム活動」を再認識させる!ある大学の情報系カリキュラムでの試み

    20 Mins
    Talk
    Beginner

    チームのあり方・チームでの成長の仕方が着目される昨今、IT業界を目指す若者たちも、いち早くそういったノウハウ・方法・ツールに触れ、体験的に学ぶことが肝要でしょう。

    アクティブラーニングの活用などで学生が主体的・対話的な活動を求められる近年の学生達は、けれどもチームを組むとなると、ゴールにむけて役割・立場・責任を当てはめる分担的チームワークを求めがちです。

    チームを形作り成長させるためのノウハウは、教育現場でも彼らに新たなチームのあり方・チームでの成長の仕方への気づきを促し、「チーム活動」を再認識させることは可能なのでしょうか?

    大学教育の情報系カリキュラムにおける個別の試行事例から検討してみます。

  • 20 Mins
    Talk
    Beginner

    小さなベンチャー企業にて、新規自社プロダクトを作ることになりました。

    会社として作りたいものはあり、期日もありますが、メンバーがアサインされるわけでもなく、だれかが号令をかけるわけでもありませんでした。

    その状況から、

    • いちエンジニアがチームを立ち上げてプロジェクトを始動させた話
    • 他拠点・多国籍チームが立ち上がり、みんなでスクラムの勉強から始めてスプリントを回し始めた話
    • リモートでもチームとしてワークするために試行錯誤している話

    をお伝えしたいです。

  • Liked きむら あゆみ
    keyboard_arrow_down

    きむら あゆみ / Junki Kosaka - Scrumですぐ使えるビジュアルコミニュケーション&『グラレコ』ワークショップ

    75 Mins
    Workshop
    Beginner

    初めまして、北のグラフィックレコーダー、木村あゆみと申します。
    北海道&札幌のトークイベントを中心に、話を絵と文字でリアルタイムに可視化する「グラフィックレコーディング(=グラレコ)」を描いています。

    北海道・札幌で講演を描くというスタイルでは、第一人者として活動しています。

    エンジニアさんの間でも、
    ・チーム内外の相互理解を深めるため
    ・より良い場をファシリテートするため
    などを目的として、ホワイトボードを活用したり、グラレコを活用したりする機会が増えていると感じています。

    「絵が描けないと難しそう・・・」

    と思われがちですが、ちょっとした道具や簡単なスキルを覚えるだけで、場をより良く可視化することができます!

    現場で実践しているコサカさんの経験からも、
    スクラムを通じて「現場をより良くしたい」と思っているみなさんにとって、グラレコのエッセンスは、即使える新しい武器になると考えています。

    私たちと一緒に簡単なワークをしながら、グラレコを体験してみませんか?

    楽しい時間を通じて仲間も増える、素敵な時間を過ごしましょう!

  • Liked Tsuyoshi Maehana
    keyboard_arrow_down

    Tsuyoshi Maehana - 遠くにいるチームメンバーと、空間を超えて会える場を作った話

    Tsuyoshi Maehana
    Tsuyoshi Maehana
    XR Evangelist
    Ricoh IT Solutions
    schedule 5 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    遠隔のチームメンバーとのミーティングやスクラムイベント、どうしていますか?

    チャット、TV会議、ホワイトボード共有ツールなどがありますが、うちのチームではどれも満足できませんでした。

    バーチャルでメンバーとあって、付箋やボードを無限に広げて使える場、チームで占有できるプロジェクトルーム、欲しくないですか。

    まだ、機材や制約もありますが「現実よりも便利に働ける場」を目指してバーチャルワークプレイスを作っています。

    わたしたちのチームメンバー5名は、スクラムイベントを毎週そこで行っています。

    少し未来の働き方を紹介させてください。

    紹介動画: https://www.facebook.com/ricoh.jp/videos/808565413001238/