はじめに
こんにちはテックリードのかどたみです。 今回は仮説検証期あるある？、検討がうまくいかずスケジュールがおしちゃった話をしようと思います。 我々プロダクトチームはロードマップという形で年間を通した開発スケジュールを社内に公開しています。これによってビジネスサイドとの会話の円滑化を図っています。
もちろん、期初に決めたスケジュールのまま固定されるのではなくお客様の要望や、会社や市場の状況によって見直しはしますが、基本的に我々はロードマップの通りに開発することを念頭に置いています。
そんな中、タイトルの通り今年はいろいろな事情が重なり1つのチームが大幅な遅延に見舞われました。 大変でしたが、結果としては遅延を巻き返すことができ、学びも多かったので、そのときの進め方と課題を言語化しておこうと思います。
この記事はエモーションテック Advent Calendar 2024の4日目の記事です。
サボってたわけじゃないんだ！
さて、ではなんでこんな事になってしまったのか、反省も兼ねて背景を説明しましょう。 重ねてになりますが、サボってたわけではないですよ！
まず、このチームは昨年(2023年)の12月から新たに編成されたチームでした。最初のうちは順調に機能開発に取り組んでいましたが、既存プロダクトの課題を打ち取るための3つの機能の開発が連続する期間に突入し、雲行きが怪しくなりました。 その中でも1つ目の機能は社内はもちろん様々な顧客からの要望が多く、期待が寄せられていた機能でした。しかし、その分ユースケースも多く、仕様が複雑化していました。
なんとかリリースまでこぎつけましたが、社内レビューではあまり良い反応が得られず、厳しい意見を受けることとなりました。このときの反省としては、リリースするまでまともな社内レビューが行われておらず、方向性の修正ができなかったことが挙げられます。 社内レビューを踏まえてチームで話し合った結果、課題を分解し、別の機能として作り直すチャレンジをすることにしました。
この時点で、残り2つの機能を作る期間で3つの機能を作るということになります。さらに、そのタイミングでPdMを担当していたメンバーが育休により離脱し、他のチームのPdMが兼任することになりました。 その結果、残り2つの機能も1つ目の機能の反省を踏まえて検討からやり直すことになり、見事タイトルの通りの状況が出来上がりました！
取り組みを振り返る！
何を考え、どの様に進めてきたか紹介します。1つ目の作り直しをメインで実装していたメンバーに任せ、残りを他のメンバーで担当し、並行で開発することにしたので、あくまで私が担当した機能の進め方です。
ヒアリング
検討していた内容が正しいのかどうかをステークホルダーに確認させてもらう時間を設けました。 ただ、文字ベースやワイヤーフレームだと細かい要望をもらいづらいのでモックデータによるフロントエンドの実装は事前に準備し、社内ネットワークで公開しつつヒアリングを行いました。
実際に動くものがあると「ここってもっとこうならないですか？」とか「こういうツールがあるんだけどこのツールの動きって取り入れられない？」といった声が得られました。文字ベースだとイメージしづらく意見がもらえなかったり、「〜〜できる」にフォーカスがあたってしまいがちですが、動作を確認しながらのヒアリングは使いやすさや見やすさにも言及してもらえるのでかなりの価値を感じました。
開発中の機能だけでなく、その機能を踏まえた他の機能群とのストーリーにも話が及ぶとても有意義な時間を過ごすことができ、協力いただいた方には大変感謝です。
実装・リリースの意識
検討が終われば、次は実装です。ただ、間違った方向性で実装を続けて同じ轍を踏むわけには行きません。1つ目の機能の最大の失敗は社内のフィードバックを引き返せなくなるまでもらいにいかなかったことです。 しかし、ヒアリングをして思いましたが、ビジネスサイドの方々も忙しいので多くの人の時間をもらってフィードバックをもらうのは大変です。なので、すでにある仕組みを使うことにしました。
弊社ではスプリントを2週間として開発を行っています。各スプリントが終わるごとに社内全体に公開する形でスプリントレビューも行っており、そこではその二週間の成果や今後リリースされる予定の機能の紹介、質疑応答、要望の収集がなされます。 私はこのスプリントレビューを利用して全社からフィードバックを得ようと考えました。リリースされてしまえばお客様からも要望が入るかもしれないですし、紹介する社内の方からも意見がもらえる機会が増えるかもしれません。なので、実装時にはとにかく細かく早くリリースすることを考えました。
早くリリースすることだけを考えると、労働時間を増やしてコードを書いていればいいですが、今回の課題は方向性の確認不足なので「細かく」が主眼です。 そのため、開発対象機能を複数のユースケースに分解し、最低限ユーザーが利用して価値のある最小単位を整理しました。その最小単位ごとに開発をし、リリースすることを心がけました。
細かいことは考えない
細かく開発することは意識しましたが、細かいことを考えるのはやめました。
というのも、フィードバックを得ることを前提としている以上、開発している最中に出てくる疑問に対する答えはありませんし、ビジネスサイドの方が正解を持っているとも限りません。正解がわからないものについては考えることをやめて、とりあえずスプリントレビューに持っていって意見を募ることを優先しました。
これができた要因
機能的に細かく出すと言っても、コードとしては結構な量だったりします。新しい機能を素早く出すことができたのも我々のチームの良いところがあったからだと振り返って思うので紹介します。
設計をリードしてくれるメンバーが居る
私はバックエンドが主領域なのでフロントエンドの設計についてはあまり明るくありません。そんな私でもヒアリング時点からプロトタイプ開発を行うことができたのは設計をリードし、相談に乗ってくれるメンバーがいるからです。
各機能ごとの独立したコンポーネントの設計だけでなく共通コンポーネントやロジックがとても使いやすく整備されているのも大変ありがたかったです。
ありがとう、Angular Material！
弊社ではAngular Materialを導入しており、これによってHTML、CSSを書かずともある程度洗練されたデザインのアプリケーションを構築できます。普段からお世話になっていて便利さを感じていますが、スピードが求められる状況では改めて偉大さを痛感しました。
決めきらずに出すよ！を合意できた
我々はコードレビューをしっかりやる文化が根付いています。今回開発した機能でもコードレビューはしっかり行っていますが、前章の「細かいことは考えない」に基づき決めきらないこと、わからないことはフィードバックをもらってあとから修正することに合意を取れたのも良かったです。現場によっては仕様をしっかり決めないとリリースできなかったり、作ったものが無駄になることを嫌ってレビューが進まなくなることもありますが、しっかりレビューするところとそうでないところの線引ができているチームであることもとても良い状況だったと思います。
余談ですが、プルリクエストのコメントに🍠絵文字がつくことがあります。IMO(In My Opinion)を表す絵文字で、気になったけど特に直さなくてもいいよ、というニュアンスで使われます。今回の機能開発では一番コメントでみた絵文字かもしれませんw
まだ他にも要因があるかもしれないですが、私が感じているのはこのようなところです。 うまく開発が進んだことで自信にもなりましたし、チームとして機能リリースのスピードは上がっていると思うので維持していきたいと思います。
課題
開発はなんとかスケジュールに間に合わせることができましたが、万事OKとは行きません、課題もいくつかあるので紹介します。
デザイン
UIについてはAngularMaterialをベースにしているとはいえ、私はデザイナーではありません。プロダクトのテーマ以外の色味については生成AIに頼っていたり、UXについても他の機能との整合性などでどうしても違和感のある機能になる部分があります。また、要望を多く受けて改善していった結果、全体としては大きな機能となり複雑になっている部分もあります。このあたりは、機能のコンセプトから腰を据えて改善する余地があると思います。
フィードバックの対応
フィードバックはもらえるのですが、リリースされてからフィードバックをもらうと最短でその対応が入るのが2週間後になります。開発環境に上げた時点でフィードバックが貰えれば更に早く改善案がリリースできるので、もう少し社内のフィードバック環境を整えていきたいところです。
おわりに
いかがだったでしょうか？はじめからスケジュールどおりに事が運べば良いに越したことはないですが、遅れてしまってもやるべきことをやれば巻き返すこともできるかもしれません。この記事を書いていて割と当たり前のことなのでは？と不安になりましたが、その当たり前が自分たちはできていなかったので自戒を込めて残しておきます。諦めずに考え続けてより良いものを作り続けたいですね。
エモーションテックでは顧客体験、従業員体験の改善をサポートし、世の中の体験を変えるプロダクトを開発しています。プロダクトに興味のある方、ユーザーの欲しいものを突き詰めていく環境を求めている方、ぜひ採用ページからご応募をお願いいたします。
