Agile Japan 2020 参加レポート「チーム全員をイノベーションを生み出す人に変える！」

# Agile Japan 2020

この記事は、2020/11/17-18に開催された[Agile Japan 2020](https://2020.agilejapan.jp/)のレポートです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221788/678fd508-bde8-ec92-6c4f-3a36dbf26758.png)

# チーム全員をイノベーションを生み出す人に変える！

[セッションの概要はこちら](https://2020.agilejapan.jp/session.html#gold-10)

株式会社永和システムマネジメント Agile Studio・スクラムマスター 橋本 憲洋 氏
株式会社永和システムマネジメント Agile Studio 橋本 雄一 氏
ANAシステムズ株式会社 デジタル・イノベーション部 熊谷 成隆 氏
ANAシステムズ株式会社 デジタル・イノベーション部 室木 梨沙 氏

（森）お互いがお互いの他己紹介をしていて、雰囲気がいいなーと思いました

# 本日のテーマ

ANAシステムズが目指す**"Be a Builder"**に向かって、どのように変化していったのかを話す
内製化支援パートナーである永和システムマネジメントから、共創・共育アジャイル開発の意義とコツを伝える

# これまでの道のり

**2019/09からの活動**
これまでずっと開発をしてきた。最初の9-11月の3か月で、3案件同時で走っていた。
これを4名で対応している。

**2020/02からの活動**
6案件同時

**2020/08からの共創開発**

# アジャイル開発への挑戦

RSM1名、ASY3名の4人でスタート。
どうやってパートナーシップを築いてきたか？

## 関係性を築く

ESMの本社のある福井に来てもらったり、ASYの本社に行ったりして、イベントを実施。
当地のおいしいものを食べながら、両社の関係性を築いてきた。

- 福井は来ただけで面白かった
- 2日間でモブをしながら、アジャイルできる気になった

## 進め方の工夫

**どうやって開発を進めたか？**

3案件同時なので、いかに効率よく開発を進めていくか、きちんと管理して見える化しながら、この案件どのような状況なのかを話しながら進めていった。
チャットツールを活用して、すぐに情報共有しながら進めていた。

**カンバン**

3案件をどのように見える化すればいいのか、を相談して、可視化していった。
TODOレーンにはプロダクトごとに違う色の付箋が貼られている。
複数案件のプロダクトが走っていて、かつ2人で開発しないといけないとき、プロダクトごとに優先順位がある。
それぞれのタスクをごちゃまぜにすると何が何だかわからなくなる。
バックログはレーンを別にしながら、優先順位をユーザーと握りながら、行ってきた。

## 結果

3案件ともいけた。
ユーザーからの感謝の言葉
「昔ながらの手順からやっと抜け出せました。確実に・手間なく業務出来るシステムに感謝しています。」

**機内に持ち込む危険物を判別するシステム**

現場でアプリを使うユーザーがユーザーテストをし、フィードバックをその場でする。
フィードバックの生の声をその場で聞けるのがとてもよかった。

# 本格的なScrum開発の始まり

## 俺たちのScrum

PoCでの成果が認められ、本格的なシステム開発が始められるようになった。
体制として、ESMの開発チームが3-4個、ASYのメンバーはPO代行という形で、ユーザーを初めて巻き込みながら行った。
コロナの影響でフルリモート開発を行った。

## Miroでの可視化

大切にしていた部分は以下

- 時間割
- **当番表とニックネーム**
    - 本名では呼ばずに、ニックネームを付けて呼び合うようにした
- 朝会アジェンダ
- **一番困ってる人の写真**
    - 作っていたプロダクトで一番困っている人はだれか
- 手作りのバーンダウン
- みんなの写真
- PBI一覧

## Scrumあるある

**現行システムに踊らされる**

現行に合わせて作ったら「ダメだ！」と言われる

**翌日変わるインセプションデッキ**

決めた内容が次の日に代わる。

**魔の金曜日**

なぜかわからないけど、毎週金曜日の夕方になると、仕様が変わったり、ユーザーから言われたり、というのが3週間位続いた。

（森）あるある…？？魔の金曜日こわい

## 葛藤したこと

案件でも葛藤が。

**スコープが広がっていって全部やりきれない。**
どう解決しようとしたときに、大きな機能をやるのか、小さな機能をたくさんやるのか、どちらがユーザーの満足度を上げられるのかを話して、後者を合意した。

**ユーザー部門・間接部門で勝手に要件が決まる。**
ASYの二人が頑張って、ユーザー部門と間接部門で決まったことを「無視」してユーザーと直接話に行った。

## 工夫したこと

過去の案件ふりかえりを実施し、よいところ、わるかったところ、こうしよう、という話をして、開発が進むにつれていい感じに開発を進められるようになった。
魔の金曜日でもふりかえりが盛り上がり、結果的には笑い話に。

**「これまでの歴史をふりかえる」ふりかえり**

すごく楽しかった。ふりかえりというより雑談という感じ。
Fun/Done/Learnをやっていたが、主にProblemを書く部分は右上に配置。
予想以上に学びが多くて嬉しかった。

**コミュニケーションを密にする**

- 5案件全部をバラバラに状況確認するのが大変なので、全員集めてやる
    - 一気に集まったのを見たのは快感だった
    - 授業しているような感じ
- いつでも開発現場を見れるようにして、ASYと密になるようにした
    - あんまりバーチャルオフィスには来てもらえなかった
    - 緊張していた様子。入ってみると大丈夫だった。

**困っていることや悩んでいることをユーザーに伝えて、腹を割って話す**

ユーザーとの距離も近くなるし、いいものが出来上がる。
間接部門で決めたものをASYの2人が無視するという決断をしたのがよかった。

ユーザーと間接部門が決めた要件があったとしても、間接部門の人は直接システムを使うものではない。
作る人と使う人が実際に話し合って要件を決めるのがいいんだなと思った。

開発側でも苦しいときはあったが、「なんでできないのか」をユーザーに説明しないと分かってもらえない。
どれくらいのインパクトがあるのか、要求を呑むとどれくらいの影響があるのか、というのを赤裸々に語って、理解してもらった。
ユーザー側も「これをやると影響でかそうだね」と言ってくれるようになって、グッと距離が近づいた感じ。

色んな工夫をしながら、関係性をいい感じに進めていった。

# そして現在、Be a Builderに向かって／共創

## 共創開発の始まり

"Be a Builder"として自らの力で働き方改善を推し進めるため、ASY・ESMの混成メンバーで共創開発を加速していく。

**チームGTの体制**

- PO代行(ASY)
- 開発メンバー(ESM&ASY)

ESMが目指している開発の体制。

## チームビルディング

2020年8月から結構な時間を費やしてチームビルディングしている。
チームビルディングしながら開発を進めている。
「[アジャイルサムライ](https://www.amazon.co.jp/s/?ie=UTF8&keywords=%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB+%E3%82%B5%E3%83%A0%E3%83%A9%E3%82%A4&index=aps&jp-ad-ap=0&tag=googhydr-22&ref=pd_sl_1k49ihcq34_e&adgrpid=56053864951&hvpone=&hvptwo=&hvadid=338518511220&hvpos=&hvnetw=g&hvrand=14494585326827757363&hvqmt=e&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1009332&hvtargid=kwd-334760378145&hydadcr=27263_11561109&gclid=Cj0KCQiAhs79BRD0ARIsAC6XpaXsdvSH-jWOj0eBySTquOGWQJrIRpZIrL4iDFo7MXhS96Eisej-hDIaAnuqEALw_wcB)」をなぞりながら、行っている。

- チーム名
- 偏愛マップ
- スキルマップ
- ドラッカー風エクササイズ
- ニックネーム

これらのコミュニケーションをしたことで、チーム内部の距離は近づいたかなと思う。
新しいメンバーが追加になったら、上記のプラクティスをまた実施している。

## アジャイル経験格差

ESMの技術でプログラミングしてきたのと、ASYの開発経験のないメンバーが混じっている。
今の究極の選択として、**「案件を進めるか」or「自己組織化されたチームを強化するか」**がある。
この選択の先に、チームの未来があるはず。

## スクスクスクレンジャー

先週から取り組んでいること。
開発メンバーは9人いるので、3人ずつのユニットに分けて、3人が1人として動くようにしている。

- 成長を重視
- レビューの効率化
- 何をしたらいいのだろうと一人で悩まない
- 一人でやるより勇気をもって、新しいタスクに挑戦できる

今朝もスプリントのふりかえりをしたが、「この取り組みが楽しい」という話をもらっている

# 最後に

**変わる勇気**

- とにかくやってみる
    - 進んでやってみる、ということ。
- 苦しみ・楽しみをユーザーと分かち合う
- チームとして成長していく

**変えない勇気**

- 福井弁
    - たまに福井弁が移る。変えられない。変えない。
- 苦しいときほど笑顔で
    - みんなが楽しそうに笑顔で
- ユーザーに最高の体験を
    - ユーザーのことを考えて、ユーザーにいいものを届ける気持ちで
- アジャイルチームでやりきる
    - アジャイル自体がチャレンジだった。決めたことをやり続ける、という勇気。

# 質疑応答

## Q. 5案件をまとめた会議をどのようにしましたか

うまく2人がまとめてくれていた。モブプロをもじって、モブプロジェクト管理としていた。
5案件を通じた課題も書いたりしていた。

## Q. ESM, ASYは最初からこんな雰囲気だったのか？雇用関係の壁を超えるには？

最初は確かに敬語だったり。
イベントをしたときに、餃子を食べながらコミュニケーションをした。
リアルな場でのコミュニケーションが大事。
チャットで案件に関係ない話でも、どうでもいい話でもして、それで盛り上がる。
オフラインで顔を合わせる、というのが非常によかった。

## Q. 楽しそうな雰囲気がよいですね

ありがとうございます。たまたま全員集まっているので

## Q. どうやればそういういい関係を築くための一歩として、契約形態は？

準委任。成果物責任のない形態。
最初から壁を感じなかった。
**みんなで一緒にやっていこう**というのがよかった。
誰かが飛びぬけていたのではなく、みんなでやっていったのがよかった。

## Q. POがASYなのはなぜ？

実際POはユーザー部門が担うべきだと思うが、アジャイル開発を理解しているユーザー部門はなかなかいない。
ASYとしてはユーザー部門のPOと、開発側の立場を併せ持つPO代理を作って、その役割をやっていた。
実際のPOはいない。

## Q. ユーザーテストの苦労は？

危険物を預けられるかどうかをバーコードを使って判別できないか、と思っていたが、とてつもない種類がある。
また、同じ種類でも量によって持ち込めなかったりする。
一つの機能で解決するのは難しかったので、マニュアルを入れたり、国土交通省のサイトへのリンクを入れたり複数の機能で対応していった。

# 感想

- チームの成長譚として徐々に変わっていった様子が見えて興味深かったです。
- 2社が親密な関係性になっていることがセッションからも分かる。こうした雰囲気を作り上げていくことはとても大事だよなぁと思いました。