Scrum Fest Osaka 2021 Day 2

2021/06/26に開催されたScrum Fest Osaka 2021 Day 2のイベントレポートです。
金沢トラックの鈴木さんのセッション「商用車メーカーの内製DXスクラムチーム奮闘記　～スクラムブルーからの脱却と成長～」の内容を・感想を記事化しています。

チーム参加してきました

aslead Agile のチーム「オキザリス」にて参加してきました。
チーム4人で参加して、その場で実況しつつ、記事も作っています。
私は一人で金沢トラックに一日いました。
この記事では、お話をきいたうえで私が感じたことをまとめていきたいと思います。

大まかな時系列

2019年、内製開発のプロダクトチームが発足。
2020年にもっとよいやり方を目指して、スクラムに出会った。

イントロダクション

DXが叫ばれる中、DX推進部が立ち上がった。
物流・人流業界でのDX。
日野自動車独自のソリューションだけでなく、信頼できるパートナーと連携をしている。
物流スタートアップのHacobuとタイアップする、など。

最初のチャレンジ

大きなモデルチェンジを行った4年前から、トラックがコネクティッド化され、
運行管理、緊急通知、安定/省燃費、運転支援など、様々なお客様に役立つ施策の実施。
そしてデータ分析をして、パートナー企業に渡していく。

最初はDX推進部から集まった3人で、エンジニア経験があるのは1名だけ。
安易に外注してしまうと問題があるのを身に染みていたのもあり、社内の開発メンバー3名でスモールスタートして、スピーディに新しいことを始めていこう、という取り組みは、社内でもなかなかないことだった。
経営層にも背中を押してもらえた。

PoCを経て、想定したユースケースは確認できたので、商用化を進めていくことになった。
そのタイミングで追加メンバーを入れて、追加開発を進めていくことになった。

このタイミングで新型コロナがはやり始め、いきなりのリモートワーク。
このころのキャッチアップには相当苦労したなと思う。

よかったこと

密なコミュニケーションができたことや、相互理解ができたこと。
自発的なメンバーも多かった。
わきあいあいとしている。

改善すべきこと

コーディングの大半が「できる人」頼み。
「真の意味で内製化ではないよね」という風に言われるほど偏っていた。

成行き的ではない、画期的な人材育成が必要だと思った。
裏では第２第３の矢が来るため、それらに使える基盤の開発を進めていくこととなった。

そして、反復的・漸進的な開発手法の習得が必要だと感じた。

時は進み…

本格基盤の構成に入り始めた。
「拡張性こそが大事、どのパートナーでも使える機能を。」
そんな疎結合なアーキテクチャを目指した。

連携先が入った時にも、PoCが進めていけるようにしたいと思っていた。

スクラムとの出会い～アジャイル志向の必要性～

漸進的に増加・変遷する要素への柔軟な対応が必要だと考えた。
中長期的には思いがけない企業とデータをオープンに使っていく、ということもあり得る。
また、PoC→商用化という流れも一般的になると思ったとき、データの3V（Variety, Velocity, Volume）が増えたときに、アーキテクチャの抜本的な見直しも必要になる。
だからこそ、アジャイルな開発が必要になった。

共同開発を検討する

独力でブレイクスルーは難しい。
一緒に開発をしてくれる協力会社を探した。

NECはスクラム開発手法や、アジャイルコーチによる実践を提案してくれて、ひときわ目を引くものであった。

スクラムへの第一印象

メジャーなアジャイル手法論
メジャーで、学習コストも少なく済みそう

PDCAの実践フレーム
分かり易くスクラムのフレームワークの中でPDCAが定義されている。
製造業の文化的にも、PDCAが必然的に回ることで、チームが成長する好循環が見えるのでは、と思った。

抵抗感
長らく計画主義、大日程があってゴールをばらして、というのを叩き込まれてきたので、
ゴールがぼやっとしていることに不満を覚えずにはいられなかった。

これらの不安はあったが、プロと一緒に学びのプロセスを踏んでいける、というところで、NECとの共同開発をすることに決めた。

スプリントゼロ

プロダクトバックログやアーキテクチャ設計などを最初にやって、イテレーティブな開発に進めていく、といった流れの中で、

導入教育
インセプションデッキ作成ワーク
開発ハンズオン

といった開発者がステップアップできる仕組みを導入した。

体験型のアジャイル集中講座

ワークを通じて、楽しんで、体験を通じた学びのプランをアジャイルコーチが提案してくれた。
誰も落ちこぼれることなく、学びを得られた。

この研修はシンプルであり、楽しかった。

「なんだ、スクラムって意外と簡単じゃん」という感覚が、我々に自信を与えてくれた。
これが錯覚なのは今は分かるが、一番最初にこうした成功経験をしたのはよかった。

インセプションデッキの作成

メンバー全員が参加。
ディスカッションしながら進めていった。
1つ1つの問いは単純で難しくないが、脳内を言語化するというのは集中力がいると感じた。

トレードオフスライダー、やらないこと、などで「やらなくていいこと」を明言化することに驚きを感じた。
いままでそういうことはやってこなかったが、全員の共通意識を得るのに役立った。

開発ハンズオン

開発ツールや環境といった前提条件も整理していった。

クラウド・サーバレスアーキテクチャを採用。
IaC、IDE、CI/CDなど、いくら説明してもらっても「？」になるものもあった。

こうしたアーキテクチャ設計ができてから開発をするまでに時間があったので、
これを学ぶためのハンズオンをNECさんにやってもらった。

とても開発に入ってからでは間に合わなかったので、スタートラインに立つということでいい経験を得られた

開発スプリント

4か月の中で2週間スプリントを8回回す。
1つのスプリントではスクラムの5つのイベントを実施。
スプリント期間が短いほうが柔軟に軌道修正できる、というコーチの声もあり、2週間区切りにした。

スプリントの中にタスクをパンパンに詰め込んでしまった、という想いはあるが、
これ以上の長さだと、タスクが見えなかっただろうと思う。

共同開発体制

適材適所な体制を検討した。
要となるSMはNECのメンバーに（経験値のあるメンバーに）お願いした。

日野に足りない部分をNECに強化してもらう布陣。
ビジネスロジックの開発は日野が主体、インフラ・アプリなどがNEC。

プロダクトオーナーは日野のメンバーが担当。能力的にも付加的にも一人だと沈没するので、エリアPOと一緒に分担して進めていくことにした。

スプリントを始める

「データを連結する」という価値を生み出す部分を優先的に進めていった。

問題①コロナが発生

コロナによって、フルリモートでのコミュニケーションが必然となった。
アジャイルソフトウェア開発宣言からも、face-to-faceが大事なのはわかっていたし、一緒にやりたかった。
ただ、リモートの波に押され断念。

Zoom, Muralなど、声だけで繋がっているチームとは思えないスピードでチーミングができた。
ただ、やりにくさは否めなかった。

現在も、NECのメンバーと一緒に対面したことはない。
会社のセキュリティで顔は見えないが、今は打ち解けられるようになっている。

問題②新メンバーのキャッチアップ問題

議論のすべてがドキュメント化されて引き継げるわけではないので、モヤモヤした部分はやりながら引き継いでいくことになる。
やり方が明確に決められていればよかったが、スプリント初期では特にこれからすべき内容の認識合わせで認識齟齬（三遊間と呼んでいる）が発生。

問題③環境整備も難しい

IDE, 設計ツール、テストツールなど、事前に設定が終わらず時間切れ。
日野・NECの両者の環境差によって、問題もいろんなところで健在化。
問題が出ては一つずつ潰す、という手間が想像以上に大きく、開発者の手間をボディーブローのように奪っていく。
この対応で2スプリント（4週間）かかってしまった。

こうしたものもスプリント0でつぶせておければ…と後悔している。

問題④全体設計の未整合

バックログの不確定部分・共通認識の齟齬部分を放置したまま取り掛かったため、レビュー時に前提条件の違いによって指摘が多くなってしまった。
誰も答えを持っていないので空中戦になってしまい時間が浪費される、といったこともあった。

ウォーターフォール時代には必然的にこうした問題はない（前提を決めたうえで進める）が、今回のやり方だからこそ生まれた問題。
ＰＯも口を出してしまい、開発者にもフラストレーションがたまってしまったと思う。

スクラムブルーへ

設計レビューを何度してもＯＫが出ない
コミュニケーションコストばかりかさんで前に進めない
打ち合わせなど、開発以外に工数を持っていかれる

こういったことで、スプリント２ごろには「スクラムは過酷、疲れる、つらい」といったネガティブな考え方しかできなくなってきた。

リモートで顔が見えなくてもわかるくらい、疲弊していったのが分かった。

ロール間の対立構造

POと開発者の対立構造。
どちらの言い分も理解はできるが、開発者とPOが利害関係が対立する、とは知っていたものの…。
ここから成り行きで進めてもうまくはいかない、と思った。

発注者としては心苦しい判断だったが、２スプリント目でスプリントを中断し、改善に充てることにした。

改善スプリント2.5

デイリーで腹を割って話し、「業務不可」「工程設計」「コミュニケーション」の観点で改善施策を立案・実行。

業務負荷の改善：長期的な目線でペアワークによる相互フォローなどを実施。
工程管理の改善：機能に直結しないものもバックログ化して、2スプリント先まで見通せるように。
コミュニケーションの改善：チャットツールの導入や、週１でのface-to-faceデーの実施。

よいものをつくりたい、という根っこの部分は変わらない。
チームのレジリエンスが徐々に復活し、わきあいあいとした雰囲気が戻ってきた。

現在の状況

リリーススプリントへ移行。
改善の貯金で開発スプリントを走りきれた。

なかなか血の巡りがよくなかったプロダクト全体のプロセスも、互いをおもんばかったコミュニケーションが取れるよいチームになっていった。

メンバーの感謝にフォーカスしたり、よいところに目が行くようになったのも、チームの信頼関係構築にもつながった。

一度大きな苦難を一緒に乗り越えているので、またスクラムブルーに陥ることはないだろう。

スクラムのふりかえり

メジャーなアジャイル手法
書籍が役に立った。
メジャー故にスクラムフェスにも巡り合えた。

PDCAの実践
試行錯誤やモブを通じて、全員が立派な戦力に成長。

経験主義への抵抗感
計画の重要性には変わりはない、と思う。
スプリント０からなる工程設計の甘さが問題につながったし、
段取り８割、というのはスクラムでも変わらない真理だと思う。

短いスパンで計画・改善を繰り返す。それが良い点だと感じた。

これからの方向性と課題

拡大期～安定期へと移行していく。開発スピードを加速させていく必要もある。

日野側メンバーでの開発主体化。SMを日野で担当する。
運用と開発の両立。DevOpsを導入していく。
複数チーム制への移行。スクラムノウハウを横展開していく。
スクラムプロセスの標準化、日野ナイズ。日野の文化にあったスクラムガイドを作成する。

おわりに

はじめの一歩を始めたばかり。
でも、1年で多くのことを学べた。
やっているだけでPDCAを回せたり、チームの成長を実感できるのがスクラムのよいところ。

感想

1年間でやったことをギュギュギュッと濃縮したセッションでした。
少しずつ、新しいことを繰り返して、着実にカイゼンして前に進んでいく。
そうしたプロセス、姿を一例として見せていただいて、とても感動しました。