短い期間で成果を出すための失敗と学び

はじめに

こんにちは。Product Team の竹原です。SPEEDA の「セグメント比較」機能に関する開発を担当しています。

私が所属している開発チームでは、2022年1月〜3月の期間で新しい機能「セグメント比較編集」をリリースしました。この機能の開発のため、フロントエンド・バックエンドともに新規実装をすることになりました。しかし開発に着手した直後から2ヶ月間ほどは開発遅延が目立ち、チーム内に暗雲が立ち込めていましたが、それを私たちがどのような解決策とともに乗り越えてきたのかをご紹介します。

はじめに
遅延の原因は何だったのか
1. 複雑なドメインに対する理解が浅かった
- 解決策: ペアプログラミングをする際、ドライバー・ナビゲーターの時間配分を工夫する
2. ユーザーストーリー1つ1つの粒度が大きすぎた
- 解決策: ユーザーストーリーを分割する基準についてチーム内で合意する
3. コミュニケーションロスが多かった
- 解決策: 夕会の導入 + 夕会で会話する内容の認識合わせ
4. 開発作業に対して意志を込められていなかった
- 解決策: Fellow をチームに呼び指摘をしてもらう、指摘内容から少しずつ学ぶ
おわりに

遅延の原因は何だったのか

私たちは毎週、その週のふりかえりを1時間ほど実施しています。その場で毎週のように遅延の原因について会話をしてきた中では、以下のような原因が多く挙げられました。

複雑なドメインに対する理解が浅かった
ユーザーストーリー1つ1つに関心事を詰め込みすぎた
コミュニケーションロスが多かった
開発作業に対して意志を込められていなかった

1. 複雑なドメインに対する理解が浅かった

セグメント比較機能は、様々な会社が公開しているセグメントのデータを1つのページでまとめて見ることができる、という一見シンプルな機能ですが、裏側には実は様々な複雑さがあります。たとえば...

国内企業と海外企業では、データの取得方法が違う
「単一セグメント」「複数セグメント」という概念がある
複数個のマイクロサービスに適切な責務を割り当てて実装・使用する必要がある

また、当時は開発チームのメンバー入れ替えがあったり、ユーザベースに入社して間もないメンバーが居たりと、セグメント比較機能を確実に理解できている開発メンバーが少なく、知識の伝達に時間を要しました。

もちろんそのような自体は定期的に発生することですので、私たちは当然のこととしてコストをかけて解決していきます。

解決策: ペアプログラミングをする際、ドライバー・ナビゲーターの時間配分を工夫する

私たちは開発作業に取り組むときは必ずペアプログラミングをします。コーディングはもちろん、日次ジョブのエラー調査などのタスクも常にペア作業です。

ペアプログラミングをする際、ドメインの理解が浅いメンバーをドライバー、ドメインの理解が深いメンバーをナビゲーターとして、慣れるまでそれを固定することとしました。 (普通は一定時間でドライバーとナビゲーターを交代します) これにより、ドライバーは手を動かすことではじめて気づけることに気づけたり、ドライバーの理解が追いついていない場合は自然と手が止まるのでナビゲーター側もスピードを調整できたりと、良い点が多くありました。

一定のリターンが得られたので、現在はすでに元の方法 (ドライバー・ナビゲーターを頻繁に交代する方法) に戻しています。

2. ユーザーストーリー1つ1つの粒度が大きすぎた

ユーザーストーリーについては過去記事もぜひご覧ください。

前述のとおり、セグメント比較のドメインはなかなか複雑で、かつそれを踏まえて新フロントエンド・新バックエンドの実装をする必要がありました。複雑なドメインについて常に「これで大丈夫か」と考えながらコーディングも同時に行うのは困難です。考える事柄が多い場合は尚更です。

今回の私たちの失敗事例を1つご紹介します。

ある日の私たちは、『ユーザーはセグメント比較編集画面で、セグメントの売上高を閲覧できる』といったユーザーストーリーの開発に着手しました。セグメント比較編集画面は現在は以下のようなページになっていますが、当時は「売上高」の列とそれより右側 (営業利益、営業利益率、など) が表示できていませんでした。

セグメント情報の表を更に列単位に分解してユーザーストーリーを作った結果が『ユーザーはセグメント比較編集画面で、セグメントの売上高を閲覧できる』であったため、私たちは「これ以上細かいユーザーストーリーは無いだろう」と思っていました。

しかし実際のところ、このユーザーストーリーは4つのユーザーストーリーが1つにまとまっている粒度の大きいものでした。

「売上高」と一概に言っても、

国内企業である場合、または海外企業である場合
単一セグメント企業である場合、または複数セグメント企業である場合

以上の組み合わせによって考慮すべきことが変わってくるため、組み合わせの数 (4) ほど更にユーザーストーリーを分割することができました。

解決策: ユーザーストーリーを分割する基準についてチーム内で合意する

まずは「どういった点でユーザーストーリーを分割するべきか？」という点についてチーム内で合意を取りました。その結果、「国内・海外」「単一セグメント・複数セグメント」という分割基準がチーム内に生まれ、例えば前述の例に示したようなユーザーストーリー『ユーザーはセグメント比較編集画面で、セグメントの売上高を閲覧できる』は、以下4つに分割されるようになりました。

『ユーザーはセグメント比較編集画面で、国内・単一セグメント企業のセグメントの売上高を閲覧できる』
『ユーザーはセグメント比較編集画面で、国内・複数セグメント企業のセグメントの売上高を閲覧できる』
『ユーザーはセグメント比較編集画面で、海外・単一セグメント企業のセグメントの売上高を閲覧できる』
『ユーザーはセグメント比較編集画面で、海外・複数セグメント企業のセグメントの売上高を閲覧できる』

もちろんこれだけが分割の基準ではありませんし、その基準は今後ドメインが複雑になるにつれてどんどん更新していく必要があります。重要なのは、常にどうなっているべきか考え続け、チームで合意を取っていくことだと思います。

3. コミュニケーションロスが多かった

私たちはペアプログラミングを常に実施している...とはいえ、100% の情報を共有しきれているかというとそうでもありません。ペアが1組しかない場合は問題ないのですが、もちろん開発チーム1つあたり4人程度、多くて7人程度の開発者が居ますので、普通はペアが2組〜3組作られます。そんな中で、ペア A とペア B の間でコミュニケーションが取れておらず、設計思想や今日の Todo を共有できていなかったり、作業内容がコンフリクトしたり、といった問題が発生しました。

解決策: 夕会の導入 + 夕会で会話する内容の認識合わせ

それまでも毎朝5〜10分で朝会をしていたのですが、「情報共有するにしても、翌朝の朝会での情報共有だと伝えるべき内容を忘れてしまう」といった課題感が挙げられましたので、朝会に加えて夕会を導入しました。夕会では以下のような事柄について、チーム全員で会話をすることにしました。

今日どこまで作業が進んだのか
作業に対する障壁はないか
今週のゴールに対する進捗はどうか

また、「わざわざ夕会を待ってコミュニケーションするのでは遅いこともある。コミュニケーションは迅速に行う意識を持とう」とチーム内で話をしまして、よりコミュニケーションに対する意識を強く持つものとしました。

4. 開発作業に対して意志を込められていなかった

「意志を込める」とはなんとも抽象的な課題ですが、たとえば

今週の開発作業予定について、なぜそれだけの量をやりきれるのか (あるいはやりきれないのか) を自分の言葉で説明できるようにする
今、最も効率的だと考えられる方法で開発作業に取り組めているか？無駄な時間を使っていないか？を考える
個人の動き方だけでなくチームとしての動き方は最適化されているか？を考える

などなど、つまり「説明できるようになること」「自信を持って開発に取り組むこと」だと思います。「いつもこうやってるから」「在籍歴が長いあの人がそう言ってたから」という理由で行動をするのは「意志を込められている」とは言えないかもしれません。私たちのチームで失敗した例としては以下のようなものがありました。

プランニングの際に「いつもだいたいこのくらいの量の開発作業を積んでいるから」という理由で適当に今週の作業予定を決めた
金曜日までに100%終わらせておきたい開発内容が、水曜日時点で30%程度しか終わっていない。かつその事実に対してチーム内で会話をしていない

解決策: Fellow をチームに呼び指摘をしてもらう、指摘内容から少しずつ学ぶ

ユーザベースには Fellow というポジションの方が居ます。詳細は以下記事をぜひご覧ください。

コーディング・設計・アジャイルな開発に関する考え方...などなどすべてについて詳しい Fellow の方にチームに入っていただき、細かく指摘をいただきました。現在では、Fellow の方がチームに居ないときでも、開発メンバーが自発的に「今週のゴールは満たせそうでしょうか？」「今やってる作業はもしかしたら不要なのでは？」といった発言ができるようになってきました。