プロダクト開発プロセスを考えるようになってから一年が経った

「Speee Advent Calendar 2016」の25日目です。

世間ではクリスマスですが、クリスマスに因んだ記事を書くことはできませんでした。

クリスマス気分を味わいたい方は、@pataiji氏が書いた超絶リア充記事を御覧になれば満足頂けるかと思います。

自己紹介

株式会社Speeeに2015年新卒エンジニアとして入社しました。

2015年10月末頃まではウェブマーケティング事業に関連する社内ツールの開発を主務とし、

2015年11月頃からはとある新規事業の立ち上げにリードエンジニアポジションとして携わることになり、以来その事業にてプロダクトの機能開発と運用を約1年間続けてきました。

初めてのプロダクト開発

とある新規事業にアサインされるまで、プロダクト開発（＝一つのプロダクトを長期的に開発/運用していくこと）というものをきちんと経験したことはありませんでした。

そんな中での開発チーム立ち上げとなったのですが、初期リリースの期限が早速迫っているという事情もあり、非常に大まかなフローのみを決めて開発を進めていくこととなります。

f:id:kohtaro24:20161225184644p:plain

一般的な開発プロセスといえばこうだよねみたいな、なんとなくの感覚で。

開発プロセスの大きな段階を一つずつ切り出して並べ、あとは見積もった工数に基いてざっくりとしたスケジュールに落とし込む、という感じでした。

結果どうなったか

リリース目標日にはなんとか間に合わせることができました。

ただ、計画通りに事が運んだというわけではなく、最後の最後に予実を合わせにいった形です。

f:id:kohtaro24:20161225213838p:plain

実装中に仕様や優先度の変更が行われたり、設計や見積もりのやり直しが発生していました。

仕様や優先度の前提が覆る

事業の立ち上げ初期の現場において、数日の間に仮説が変化する場面は珍しくなく、「初期リリースの時点でどんな機能がどんな状態で必要なんだっけ？」という前提が実装期間の中で右往左往し、リリースのスコープから外れる機能が出てきたり、逆もまた然りであったり。

工数見積もりも覆る

「この開発はリリース日までに間に合うのか？」を明確にする上で見積もりは重要です。しかし、長期的な機能開発に費やされる工数を正確に見積もるのは大変で、仕様や設計が変化すると見積もりに関してもやり直す必要が出てきます。見積もった結果がリリース日までに間に合わないと判断された場合は、仕様上簡素化できそうな部分を探したり、代替案を考えて調整したりします。そして再度見積り。

　上記のような要因が重なった結果、初期リリースに含まれた機能群は当初見込んでいた数の半分以下になり、テストや修正に費やされる期間が縮まったことで、リリースのタイミングを予定と合わせることができた、という形です。

開発プロセス検討

なんとか初期リリースを乗り切った後に、これからの開発プロセスをどうしていこうか、という話し合いをチームで実施しました。

アジャイルやスクラムといったキーワードがそこで登場するようになり、「アジャイルかぁ。。聞いたことはあるけどどういうものなんだろう」とか思いながら、アジャイルサムライや SCRUM BOOT CAMP のような書籍を読み漁りつつ、自分たちのリソースで運用していくことができそうな開発プロセスを思案しました。

大きく変えていったことを以下に列挙していきます。

開発のリリース頻度について

プロダクトの初期リリースというのは、開発計画における分かりやすい一つのマイルストーンでした。一方で、これから進めていく開発については二つの案が考えられました。

何月何日にどんな機能をリリースをするかを事前に決めてから開発する
優先度が高いとされる機能から開発し、開発完了次第即リリースする

自分たちのチームにおいて、1のような開発が求められるケースは例外的であり、基本的には目の前の価値を早く届けることに注力したいという観点から2の案を選択しました。

開発の周期について

先の項で書いたように、立ち上げフェーズの事業においては著しく状況が変わるため、開発チームが事業課題に追従しやすい動き方を取る必要があります。

優先度や計画を調整したり、振り返りを行い易くするために、開発プロセスに一定の周期を設けることが必要だと考えられました。

f:id:kohtaro24:20161226012607p:plain

ということで、一回あたりの開発周期(スクラムでいうところのスプリント)を1週間と置き、毎週の金曜日を締め日として、振り返り・新規開発要望及び優先度の確認・計画引き直しを毎週実施するようにしました。

工数見積もりについて

この件については、工数見積をどのくらいまで厳密にやるのか、ということが争点でした。「この機能を開発するのに〇〇時間かかります！」ということを伝えたとして、実際には開発する人によって結果が違ったり、コードレビューやリリース作業などが入ったりもするので、〇〇時間という数字を強く信用されると色々困ることもあり、これを伝えるには結構な勇気がいります。それ故に見積もり自体も非常に神経をすり減らす作業になります。

とはいえ、この機能開発は今週の計画内に組み込めそうかであったり、チームがどのくらいの開発を今週捌こうとしてるのかくらいは把握可能にしておきたいという事情はあります。

そこで自分たちのチームではストーリーポイント見積もりを採用しました。

時間ではなく作業の大きさを相対的に表したポイントを使うことで、時間を扱う際には密に考慮する必要のあった要素を、可能な限り見積もり作業から排除できます。

また、週ごとに消化できたポイントの数を計測していくことで、この機能開発は今週の計画内に組み込めそうかなどの判断もできるようになっていきます。

要件定義について

ぽっと出の開発要望の中には、「この要件、本当に適切？」って思うようなものも少なからず含まれます。

何を叶えるべきかが明確であれば、満たさなければならない要件はもっとシンプルにできるんじゃないか？ということで、開発要望において主要な項目をまとめたものをテンプレート化しました。

f:id:kohtaro24:20161226003513p:plain

githubからIssueを作ろうとすると、このようなテンプレートが表示されます。

各項目に関しては以下のような内容を記載します。

(Who) として
- 要望の出処を明らかにする。
- 要望の持ち主が誰なのかを把握することで、仕様に関するヒアリング等を誰に行うのが妥当なのかを判断できる。
(What) がしたい
- どのような要望なのかを明らかにする。
- 本質的なゴールは何なのかを把握することで、「どうなるのが理想なのか」を基準に仕様を検討できる。
なぜなら (Why) だからだ
- その要望が発生した背景、実現することの妥当性について明らかにする。
本Issueは (Acceptance Criteria) を以って完了とする
- その要望を実現する上で、何がなされている必要があるかを明らかにする。