# Agile Japan 2019

いくつかのセッションに参加してきましたが、GROOVE X株式会社のアジャイル開発の話が印象に残ったので、当該開発に関連する３つの講演について内容をまとめました。

## 基調講演

## マネージャー不在の洞窟型組織[https://www.agilejapan.org/session.html#e-03]

GROOVE X 株式会社
代表取締役
林 要 氏

**＜概要＞**
GROOVE XのプロダクトであるLOVOT（ラボット）https://lovot.life/
はアジャイルで開発している。ロボット開発という先が見通せない領域は
アジャイル開発しか選択肢がなかったと断言していた。プロダクトオーナー
でもあった林氏から、実際にアジャイルでロボットを作ってみて、どのような
手ごたえを感じたのか率直な感想を聞くことができた。

**＜アジャイル開発の特徴＞**
- 未知の領域にはアジャイル（フラット型）が向いている
（未知の領域＝先が見通せない、朝令暮改が頻繁に起こる）
- 早く試して早く学ぶことができる
- アジャイルは試行錯誤できるがウォーターフォールは試行錯誤しづらい

- 先が見通せないので常に不安との戦いがある
- タスクかんばんで見える化することでその不安を解消していく

- 先が見通せない領域において遭難しない能力がアジャイルには必要
- 失敗しないギリギリのところを攻めるのが大事。片足を落としたときにそれに気づける能力が重要
- ピラミッド型の組織だと役割が固定しているが、フラット型だと役割が固定されていないので、タスクが漏れていても誰かがすぐに声をあげて拾ってくれる。（ピラミッド型だとそれがない）
- アジャイルは各人の責任感が芽生える。また、フラットなので横連携のコストが安い
- ピラミッド型だと2.6.2の法則になるが、フラット型だとこの法則が崩れる（さぼる人が少なくなる）
- フラット型はカオスになりがちだが、そのぶん活気がある
- 飽きるというのをポジティブに考える
- 積極的に飽きることを認めるとラーニングアジリティが上がる
- GROOVE Xでは飽きたらすぐに手をあげてもらい別の仕事をしてもらうようにしている（マイナス評価はしない）
- 出資者への説明は結構ウォーターフォールで説明している（いつまでに何をするか）

**＜所感＞**
林氏の講演の中で、「カオス」という表現がいくつか使われるところがあった。プロジェクトにおいて「カオス」ときくとマイナスイメージを持ってしまうが、林氏はプラスのイメージをもっていた。「カオス」だが活気が生まるからだそうだ。どれだけカオスな現場なのか一度みてみたいと思った。

## 別セッション

## あなたの組織のマネージャーは本当に必要ですか？
GROOVE X 株式会社
清水　麻由 氏
清水　弘毅 氏
山崎　一法 氏

**＜概要＞**
GROOVE XのプロダクトであるLOVOT（ラボット）の開発に携わった担当者の方々の登壇。実際にアジャイルでロボット開発をしてみての率直な感想を聞くことができた。

**＜開発のポイント＞**
- 120人20チームとなっているが組織ツリーがない１スクラムで実施している
- 正解がないからとにかくひらすら試すことが重要
- アイディアはたくさんほしい
- 局所最適ではなく全体最適を考える
- 管理者がいないので全員がフラットで当事者
- 最初はスクラムって何だろうってレベルだったが現在では開発以外でもスクラムを意識するようになっている
- アジャイル開発の最初は試行錯誤の連続だった。バックログやスプリント期間が各チームでバラバラだった
- その改善としてLeSS(Large-Scale Scrum)というフレームワークを使うことにした
- LeSSにより全チームでスプリント期間を統一した。１週間スプリント。バックログを同じボード上に統一した
- LeSSを使うことで定例会が減った。自分ごとに考えるようになった
- デイリースクラムは全員が同じ場所、同じ時間でやるのが大事
- バックログの作成はカスタマージャーニーの流れを意識する

**＜所感＞**
LeSSのルールにもあるが、どんなに大規模でも複数スクラムを作るのではなく、ワンスクラムにすることが重要というのが印象に残った。複数スクラムを作ると、スクラム間で壁ができてしまい、全体最適ではなく局所最適になってしまうとのこと。ロボットのようなプロダクトだとどれだけ局所的に優れていてもダメで、全体をみて購入したいと感じてもらえるかが勝負なので、ウォーターフォールのように最後に部品をガッチャンコでは全体最適の状態でリリースするのは難しいんだと感じた。

## 別セッション

## LeSSでつなぐビジネスとIT
合同会社カナタク 代表社員　アジャイルコーチ
木村 卓央 氏

グロース・アーキテクチャ＆チームス株式会社/有限会社StudioLJ
アジャイルコーチ/プログラマ
高江洲 睦 氏

株式会社オージス総研
アジャイルコーチ/コンサルタント
水野 正隆 氏

**＜概要＞**
LeSSのルールやガイドを紹介しながら、顧客視点を持つ自己管理型のチーム、
マネジメントスタイルを考えていく。

**＜所感＞**
講義内容だとLeSSがよくわからなかったので以下のサイトが参考になりました。
[https://less.works/jp/less/principles/overview.html]

※サイトより自分が気に入ったLeSSの原則を抜粋

- Large-Scale Scrumはスクラムである　
決して新しい物でも改善版でもない。LeSSはスクラムの目的、原理原則、要素を大規模開発で適応する為の物である。複数チームのスクラムであり、複数スクラムチームでは無い。

- 完璧を目指しての継続的改善　
プロダクトをバグが無い状態で常に提供し続ける事により顧客を満足させ、環境を改善し、生活をよりよくする。これに向かって、各スプリントを謙虚に、そして根本的な改善を行う為の試行錯誤を行う。

- システム思考
部分最適では無く、全体を俯瞰し、理解し、システム全体を最適化する。個人や１チームなどの部分的な効率化や生産性向上だけに集中することは避けなければならない。顧客は製品開発の過程を気にする事は無く、アイディアがお金を産むまでの期間を極力短くしたいのである。

以上