こんにちは。プロダクトマネージャーの井口（いのくち）です。この記事は、UniFaアドベントカレンダー 4日目の記事になります。
今年もいよいよ残りわずかですね。今年といえば、新型コロナウイルスの影響でリモートワーク主体の勤務になった方も多いのではないでしょうか？
私も今年の3月からリモートワーク主体の勤務を始めています。弊社に入社したのが2月だったので、弊社のメンバーと少し親しくなったくらいの段階でリモートワークを開始しました。その影響もあってか、プロダクト開発の進め方に関する失敗をいくつかやらかしました。
このブログでは、私の失敗の中から3つの失敗を取り出し、そこからの学びをご紹介します。リモートワーク下でのプロダクト開発の参考になれば幸いです。
tl;dr
このブログでは、3つの学びを紹介しています。
関係者との前提のすり合わせが今まで以上に大事
開発チケットは自分たちが管理できるくらいまで細分化すべし
デイリースクラムでプチスプリントレビューを行うと問題発見に効果的
詳細が気になる方は下記もどうぞ。
失敗1：コミュニケーション編
発生した事象
リモートワークを開始してからしばらく経ったのち、このような事象がいくつか発生していました。
- 共有したと思っていたスケジュールが上手く伝わっていなかった
- 同じ事柄について話しているのに、話が上手く噛み合わない
- 仕事の完了条件についての認識がズレている
原因
これらの原因を深堀すると、ある1つの原因に辿り着きました。
それは「お互いの前提の共有が不十分である」というものでした。
私はこれまで、関係者のほとんどが出社して勤務する環境で働いてきました。そのため、お互いの仕事のスケジュールや置かれている状況、さらにはお互いの仕事観（例:正確性を求めるのか、スピードを求めるのか）、といったお互いの前提を自然と知りあえる状態でした。
一方で、リモートワークがスタートしたタイミングでは、あまりお互いを知らない状態でした。加えて、リモートワーク下で今までのコミュニケーションスタイルを取ってしまったことで、前提共有が不十分なコミュニケーションとなってしまい問題が発生していました。
学び
この失敗から、
リモートワーク下で協働するには、前提のすり合わせが特に大事
ということを学びました。
手法としては、プロジェクトの前提のすり合わせでは「インセプションデッキ」を作られることが多いと思います。
これに加えて「ドラッカー風エクササイズ」「ワーキングアグリーメント」や性格診断テスト（例:エニアグラム）など、個人の仕事観を共有する施策の実施も重要と感じました。
失敗2：プロジェクトの進め方編
発生した事象
続いては、開発とQAを並行で進める時に発生した事象の紹介です。リモートワークが直接の原因ではありませんが、問題に拍車をかけた要因の1つだったと感じています。
スケジュールがタイトだったこともあり、開発とQAを並行稼働させるチャレンジを行いました（下記の図のような想定です）
デイリースクラムでお互いの進捗を共有しており、上手く行くんじゃないかと思っていたのですが、実際は開発・QA間の手戻りが多く発生してしまいました。
原因
手戻りが発生した原因を深堀すると、
1つの開発チケットに大きくの内容を盛り込みすぎてしまい、チケット内に完了と未完了の部分が混在する状況になっていました。
そのため、チケットがいつまで経っても終わらず、チケット管理は上手くいかないし、チケット完了できないためベロシティの計測も上手くいかないという状況になりました。
学び
この失敗からは、
開発チケットは自分たちが管理できるくらいまで細分化すべし
ということを学びました。
ちなみにこの学びは抽象化でき、
相互に依存する物を並行稼働するときは、送り手(この事例では開発)と受け手(QA)で受け入れ条件を合わせるが大事
として汎用的に使える学びだと思います。
失敗3：問題発見編
発生した事象
最後にお伝えする事象は、デイリースクラム(朝会)のやり方に関する事象です。
私たちはスクラムで開発を行っており、毎日デイリースクラムを行っています。デイリースクラムでは、今自分が抱えている課題を他のメンバーと共有するプロセスが入っていますが、私たちのスクラムでは上手く機能していない状況がありました。
具体的には、毎日の報告では問題ないと共有されていたが、実は問題が解決されずに残っていました。それに周りも気づくことができず、問題の発覚が遅れ、対処や支援も遅れてしまいました。
原因
この事象を深堀すると以下の3つの可能性が見えてきました。
問題を話せるレベルまで、心理的安全性を高められていなかった
(周囲は問題だと感じるが)本人が問題と気づかなかった
本人が報告を忘れてしまった
主観的ではありますが、話に上がってくる問題もあったので、1の心理的安全性はそれなりに高かったのではと思います。そのため、2と3の原因の方が強いと考え、この問題を軽減する方法を検討しました。
学び
検討するにあたり、下記図の「周囲が気づいて支援できる箇所(盲点の窓)」をいかに明らかにするかが重要と考えました。
そこで私たちはデイリースクラムに「プチスプリントレビュー」というものを取り入れました。
やり方は凄く単純で、デイリースクラム内で、その日に各自が開発した内容を画面共有しながら話してもらうだけです。問題発見に気づくことを目的とし、スプリントレビューのようにデザインや仕様の議論は行いません。
プチスプリントレビューを実践したところ、口頭での問題共有では出てこなかった問題に気づくことができたり、忘れていた問題共有も行うことができるようになりました。
副次的には、毎日新しく開発された内容を確認できるので、チームとしてもゴールに近づいている感じを得ることができるようになりました。
まとめ
リモートワーク下での失敗から、以下の3つのことを学びました。
関係者との前提のすり合わせが今まで以上に大事
開発チケットは自分たちが管理できるくらいまで細分化すべし
デイリースクラムでプチスプリントレビューを行うと問題発見に効果的
1つでも皆さんのプロダクト開発の役に立てば幸いです。
最後に
もっと詳細を聞いてみたい、ユニファの開発ってどうなの？という疑問/質問がある方はぜひカジュアルにお話できると嬉しいです。
それではみなさま、良いアドベントカレンダーシーズンをお過ごしください！
