ホーム >

勉強会 >

「チーム全員をイノベーションを生み出す人に変える！」Agile Studio ウェビナーウェビナーレポート

公開日：2020/11/27 

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

• ESM橋本憲洋 様
• ESM橋本雄一 様
• ASY室木梨沙 様
• ASY熊谷成隆 様

• どのようにして使う人と対話しながら価値を作り、作り人のチームへと変化したかのコツを伝えます
• いろんな現場で、開発現場と発注側が遠い現場が多いが、今回事業開発と開発チームを双方向にチームを作って共同開発を行う形で実施した。

• 9月から6月までに開発したシステムで、9ヶ月の間にたくさん作ったので、3章にわけて説明
• 1章：PoCを同時並行で3つ作った
• 2章：6-9月につくったもの
• 3章：８月以降につくったもの

1章：Agile開発への挑戦

技術を通じたコミュニケーション

• 福井と東京に行ってお互いコミュニケーションとりながら関係性を築いた
• チームビルドにどれくらい時間がかかったのかという質問に対しては、元々わりとすぐできていて、その要因としてESMとASYの責任者の二人がメンバーに対して思いを伝えてくれたのがメンバーに伝わったのだと思う。
  • PoCでも話がずれることはなかった
• 教育イベントをしてもらうことで同じ方向に一緒に向いていけた（室木）
• お互い足を踏み入れて作っていったのが良かった。福井にも足を運んだり、モブプロしたり、ご飯したのがよかった（成田家）
• 東京でもごちそうになって、美味しいお酒をいただけたのも良かったのでは（橋本）

進め方の工夫

• 3案件を同時に二人で回すのに苦労したおり、どうやったらみんなに見えるのかの悩みがあって看板を工夫して作った
• プロダクトバックログがそれぞれの案件ごとに出てくるので、横にレーンを作って、そこにinboxとbacklogをいれて優先度順にやっていった（橋本）
  • プロダクトバックログも短かった
  • 全部混ぜるとわからなくなるのでプロダクトバックログの時点では明確に分けた
  • スプリントのTODOにいれるときに2つずつの案件で動く時に優先順位が高いものから並べて消化していくようにした
• 工夫としてエンジニア動詞みつにコミュニケーションとったり、ASYとチャットでやり取りしながら開発を進めていきました（橋本）
• 優先度を決めるのが難しいと思うがどうやったか？
  • 使う人がたくさんいるのでいろんな意見が聞ける。（橋本）
  • あのユーザがバンバンいってキーマンっぽいからその人の叶えたい機能を先に作ったらうまくまわりを巻き込んで進んでくれるんじゃないか？となった。
  • キーマンをみつけるのもうまかったし、心を掴んでうまく開発が進められたと思う（室木）

実際のUATをした時のお話

• 危険物として飛行機にもってけるものを判断しないといけないという所でどれをもってけるかと聞かれた時にすぐに判断するのが難しい業務がある。
  • 画像認識やバーコードの認識でできないかをPoCでやってみた
  • 判別する仕組みをつくるのも大変だった
  • システムができあがってUATやる中で、使う人にやってもらう中でFBをもらってすぐに対応を考えることができてよかった
• 3個中、2個の案件がPoCが気づいたら本番運用になっていた

2章：本格的なScrum開発の始まり

• PoCの世界が認められ、本格的なシステム開発が始まり、他にも業務改革の要望が入ってきたので体制を変えて開発を取り組んだお話。
• ESMもチームを作ってそれぞれ開発に入った
• ASYも代行ということで開発に関わって始めた

俺たちのScrum

• miroを使って情報共有しながら開発をしていった
• 当番表とニックネームを作ってニックネームで呼び合うようにした
• 一番困ってる人の写真は、ある案件でキックオフの時に誰が一番困ってるかを話しをききながら話していたらユーザ側の代表の方が一番困ってるというのがわかって、写真をとって常に見えるところに飾り、この人のために頑張るんだとおもいながら開発している
• 手作りのバーンダウンはgoogle drawを使ってメモリや線を自分たちでかいてやっている
  • めんどくさいことをすることでチームがどうなっているかの把握をすることができる

Scrumあるある

• 現行システム通りに作ってみてユーザに見せて使ったら違うということが起こったりする
• 一回ユーザさんも含めてインセプションデッキをみながら合意をするが、インセプションデッキでスコープを決めて開発しようとしたらインセプションデッキが変わってしまったりもあった
• 普通だったら金曜は楽しみのはずだが、金曜はユーザから変更要件が出てくる時期があった

葛藤したこと

• スコープが広がっていって、要望が出てくる中で大きい機能を作るのか、小さい喜びをたくさん上げるのかをみんなで考えてどちらをやるのかを葛藤しながら作っていった
• PO以外で間接部門がユーザと要件を決めてることがあった。
  • POが決断を下して、勝手に決めた要件は無視してもう一回話すようにした

工夫したこと

• 葛藤や苦悩からどうやっていいチームを作ったかのお話
• 過去の案件の振り返りをしていい点・課題・対策を洗い出して次の開発に活かした
  • 魔の金曜を繰り返さないために早く動くものをつくって生の声をきけるようにしていた
• 全体で一個のことをやっている感覚だった
• 最後に振り返りとして、Fun done learnを工夫してProblemを追加したものを使ってやった
• コミュニケーションのやり方として、情報共有の場をそれぞれの案件でやると大変なので一気に全部あつめて一つの会議体で情報を共有するようにした
• フルリモートで会話が難しいので常にzoomをつないでいつでも顔を出せるようにしていた
• 全案件の情報共有を行うのは、どの案件がどこまで進んで、どんな課題を抱えているのかを管理していくのが大変だったが整理しやすくなった（成隆）
  • 会議の価値として高かったと思う
• バーチャル会議室とか作ってたが、zoomに最初入りづらかったか？
  • もっと早くからやっておけばよかった（室木）
• 出来ないことを正しくユーザに伝えて腹をわって話すことで、ユーザも含めて一つのチームを目指したのは一番工夫した
  • 管理部門などで方針を出すのは必要だが、要件をどう作るか、ユーザが使うのはどういうものなのかは直接話すことで見えてくる価値がある（成隆）
  • ユーザが最も必要としてることはなにかと開発メンバーとユーザと話をして距離を縮めたのができたことにつながったのではないか。（室木）
  • リモートでユーザ調整が難しかった。今までは会議をして終わった後に補足の話ができたが、ユーザもリモートで会議なので補足はしづらかった。

3章：そして現在、Be a Builderに向かって共創

• ESMとASYとで新しい開発をしている
• 今までのところと何が違うかというとPO代行のASYとPOのメンバーと開発メンバーがチームを作って複数のユーザ部門からの案件の対応をしている

チームビルディング

• アジャイルサムライに書いてることを実践していった
• チーム名をつけて、偏愛マップを作って人となりを理解しながらみんなのことをわかるようにした
• ドラッカー風エクササイズでチームメンバーから期待すること、期待されてることを書いて紹介した。新しく来てもやってコミュニケーションを深めている
• ニックネームで呼び合っている

アジャイル経験格差

• チームのメンバーが経験も違ったり、アジャイルやってきたやってきてないの格差もある
  • 組織としてこうあるべきといった課題ももちながらも案件はたくさんくるので進めないといけない
  • 全員が技術を身に着けてすすめたいが、そこまで時間をさけると案件がすすめられなかったりの葛藤をもっている
• どうやって進めたいのかを話しながら変えて進めている
  • 究極の選択を決めて進めた暁になっている

スクスクレンジャー

• 開発メンバーが9人いるが、3人ずつにわけて3人で一人と仮定して動いている
  • 成長を重視したいためにこうしている
  • 今回8月からジョインしたASYのメンバーはアジャイルの開発を経験していないメンバーだった
  • 成長を重視しないとこの先ベロシティが上がらないということで試してみようとなった
  • 3人でレビューするのでレビュー効率も上がる
  • 9人もいると次なにしようかとなるメンバーもいた
  • 一人で知らないタスクをやるよりも3人でやったほうが圧倒的なチャレンジとして挑める
• チームどうやって決めているかというと、あみだくじで決めた
  • 毎回チーム名をかえながらやっている

最後に

• 一緒に勧めた中で変えたことと変えなかったことの紹介

変わる勇気・変えない勇気

• 最初から新しいことをやってみようという空気感はあった
• 苦しみ・楽しみをユーザと分かち合いながらやる
• 一緒に成長していくのが変わったこと
• 苦しいときも笑顔でユーザに価値を届けるというのはチーム全員が同じ思いをもっていたのがあるとおもう
• アジャイルでやっているが、時々昔のやり方に戻りそうなパワーが働くことがちらほらある。
  • 1チームで複数案件を同時でやると案件進めたいという思いが強くなって二人なら並行でやったほうがいいんじゃないかとなったりする
  • みんなで成長しながらやったほうがベロシティ上がってより良いものが作れると毎回説明しながらやっていた

QA

自己紹介で褒めあってるように見えたが意図してやったのか？

• 本当に思ってることを伝えました（室木）
• 自己紹介じゃつまらないので他己紹介にした（成隆）

そもそもなぜ３案件同時並行でやったのか？

• PoCをapp makerで使うことで早く開発できるということで評価を含めてやりきってみようということにtryした
• tryシた結果本運用に投げれたのでよかった（成隆）

バーンダウンは粒度をどれくらいにしているか？

• 長くて半日程度でおわる大きさ。ものによっては1hや30minでおわることもある（橋本）
• 半日超えない粒度でタスクを作ろうとしている
• ストーリーの中でみんなで合意しながら作っている

インセプションデッキ作ってうまく活用できたか？

• 最初に可視化して合意するというのはうまく活用できたと思う
• 見えるものをつかってユーザと話ができるのはいいスタートが切れたと思う
• 翌日変わったとしてもユーザから変わったというのを意識して話せる

全案件情報共有はどれくらいの時間かかったか？

• 1hとっていたが、30minくらいだった（室木）
• 1案件ずつ深い話をするのではなく、全体の1週間の確認と共有認識のQAを確認していた

同時並行の案件でどういう資料を共有していたのか？

• スプレッドシートを共有していて、スケジュールを確認するシートとQAを確認するシートで２点確認する会議をしていた

zoom常時接続は顔出しでしていたのか？

• 顔出し常時接続です。ストレスは感じない。顔出ししないほうがストレス。（橋本）
• 慣れだと思う（成隆）
• 顔出さない人がいない

リモートでユーザの意見を聞くのはzoomか？直接聞くのか？analyticsのデータも意見として使っているか？

• 全員リモートでやるときはzoom。（室木）
• 意見を聞くのは実際ものを見るのをやってなくて、ドキュメントをみながらはなしていた
• analyticsを使うような案件ではなかったので使ってない
• エクセルで今どのようにやっているかを見たりはした（成隆）

新しいメンバーが来た時は全員分のドラッカー風エクササイズをしているのか？

• 新しく来た人の分をみんなで書いている（成隆）
• 新しく来た人が他の人を書くのは難しいとおもうのでかけていない

朝回のスタンダートは15分ときくが、情報共有以外もやっているか？

• 朝会でスクラムの教科書どおりにすると昨日やったこと、今日やること、課題／問題点、共有事項となる
• メンバーが多くて15分でおわらない
• プロダクトバックログの状態の確認、ふりかえりのトライアクションの確認もしている
• 最初は15分で終わらなかった
• スクラムガイドが最近出たが、その内容をうけて朝回のやり方をかえてみたりして短くしたりもしている
• 朝会を15分で終わらそうとおもわないと終わらないので長くなる話はあとで話すようにしている。
• 朝会をブラッシュアップしていくのはいいこと（成隆）

ペア作業でセクハラ／パワハラなど発生しないか？気をつけてることはあるか？

• 気をつけてることはない。普段どおり接している。（橋本）
• 普段の関係性もあるし、パワハラ・セクハラする人がいない
• チームビルドがしっかりできてるのであまり気にしたことがない

個別作業が早いという対抗が逆らえず、どう説得すればいいか？

• モブプロをやるときもベロシティが低くなることもあると思うが、やってみたらベロシティが変わらなかったので、並行が早いというのが証明できてないのでとりあえずやってみるのがいい。（成隆）
• 個別にやると育たない（橋本）
• 議論しても何も結論でないのでやってみたほうがいい
• やってみて失敗したらやめればいいというチームなので説得するのはない

魔の金曜は客にも参加してもらうレトロスペクティブで解消できたか？工夫したことは？

• 顧客の参加したレトロはやってはいない
• いろいろ作戦をたてて落とし所を一緒に探った
• チームで起きる問題はチームで解決できるようになった

be a builderとしての背景や思いはあるか？

• 実際の造り手というところで単語を抽出した（成隆）

もぐめっとの所感