この記事はクラウドワークス Advent Calendar 2020 16日目の記事です。
はじめに
こんにちは、クラウドワークスの事業の1つである「ビズアシスタントオンライン」のPO（プロダクトオーナー）をしている竹ノ谷です。
この記事は約2年かけて開発してきた新規プロダクト開発の区切りがやっと見えてきたということで、長期開発においてPO目線でやって良かったことと反省点を書いたものです。
新規プロダクトをある程度の期間をかけて開発する際に、少しでも参考になれば幸いです。
何を開発しているの？
ビズアシスタントオンラインは事務領域に特化した在宅アシスタントと企業をマッチングするサービスです。
マッチングはクラウドワークスのような完全オンライン型ではなく、人材エージェントのように人が介在して行っています。
今回開発しているのは、在宅アシスタント向けのマイページのようなプロダクトで、内容としては
・会員情報登録
・タイムカードシステム（デスクトップアプリ）
・タイムシート
・契約管理
・支払い管理
などが含まれています。
もともとはクラウドワークス上の機能を使ってすべて管理していましたが、利用する在宅アシスタントが増えてきたというのもあり、独自のプロダクトとして開発を行うことになりました。
どんな道のりだったの？
プロダクト構想自体は2019年の4月頃から始まり、そこから開発チームを組成しました。
初期体制としては、エンジニア4名・デザイナー1名・コーダー1名・PO1名です。
私は途中でPOを引き継ぐ形でチームに入りました。
2020年4月からはエンジニア2名+PO1名という少ない人数で奮闘しつつ、2021年春を目途に当初予定していた第一弾としてのプロダクトをリリースできる見込みです。
大枠は↓のような流れで開発を進めてきました。
・技術選定、連携するツールの選定
・必要な画面、機能一覧の作成
・開発タスクを分割してチケット化
・画面デザイン、マークアップ作成
・チケットごとに開発タスクを進行
2年もかけて開発をしていると、ここには書ききれないくらいハプニングやらどんでん返しやら、てんやわんやのことがたくさんあったのですが、そんな中でもPOとしての私の目線でやって良かったことと反省点を書いていこうと思います。
やって良かったこと
1.とにかくドキュメントを残す
長期間に渡る開発だと、新しいメンバーが増えたり、途中でメンバーが入れ替わるケースが多くあり、今回の開発でも途中で体制変更が発生しました。
また最初からいるメンバーであっても、1-2年前に話したことや決めたことを正確に覚えておくことは難しいと思っています。
そのため今回の開発では最初からとにかくすべてドキュメントに残すということを意識していました。
仕様はもちろん、決定事項以外に議論の過程や、法務や経理側と調整した内容まで、あとから見返せるように細かく記録しました。
開発を進めていくと「この仕様ってどうしてこうしたんだっけ？」と後から気になるケースもよくありましたが、議論の過程までドキュメントで残っていると「あぁそうだった、だからこうしたんだった」というのを簡単に思い出せて、他の人に聞いたりする手間をなくすことができました。
また、今回の開発は最初からチームメンバー全員が週4リモート+週1出社というスタイルで進めてきたのですが、リモートメインでも円滑に進めることができたのはドキュメント文化があったからだと思っています。
すでにやっている方も多いと思いますが、長期での開発になればなるほど後からじわじわ恩恵が効いてくるのでオススメです。
2.見積もりの認識合わせと再見積もりの実施
今回の開発ではツールとしてJIRAを使っており、見積もりは各チケットにストーリーポイント（SP）を振る形にしていました。
そして開発タスクをチケット一覧にした当初に、全チケットに見積もりを行っていました。
ただ、開発を進めていく中で各チケットの難易度が変わってきたり、最初に見積もりを行ったエンジニア以外のエンジニアも増えたこともあって、当初の見積もりが上手く機能していないという問題が出てきました。
見積もりが正しく機能していないと、リリース時期も正しく予測できなかったり、ストーリーポイント消化数が理不尽に少なく見えてモチベーションの低下にも繋がります。
そこで改めてエンジニア全員でストーリーポイントの認識合わせを行ってもらい、そのうえで各チケットのストーリーポイントを全て見直してもらいました。
ストーリーポイントの定義の仕方は会社やチームごとに異なると思いますが、参考として今回の開発では以下のように定義しました。
この作業自体に多少工数はかかりますが、これによりリリース時期の見積もりの精度が上がったことと、共通認識ができて納得感も増したので、やって良かったと思っていることの1つです。
3.できるだけ分割してリリースする
今回の新規プロダクトは当初、開発できた機能から部分的にリリースという形ではなく、全機能が開発し終わってから一括でリリースする想定で動いていました。
しかし、開発の途中で「ビズアシスタントオンラインが扱っている仕事をシステム上で公開し、在宅アシスタントが応募できる機能を2ヵ月以内にリリースしてほしい」という事業部からの緊急度の高い要望があり、検討した結果開発中の新規プロダクトに仕事応募の機能を載せ、その部分だけを先行してリリースすることになりました。
これによって仕様やスケジュール感が変わってしまった部分もあるのですが、これを機に他の機能も切り出せる部分から分割してリリースする方針へと変更しました。
結果として分解リリースのメリットとして
（1）分割リリース日をマイルストーンにすることができる
（2）分割して少しずつつリリースしたほうが、開発チームも事業部側も”進んでいる感”を感じることができる
（3）リリース後に不具合があっても影響範囲が少ないのでリスクが小さい
などがあったと思っています。
特に長期開発ゆえにリリース日がなかなか定まらずに、果てしない道のりを歩んでいるような感覚が課題でもあったので、マイルストーンとしてのリリース日を決めることで「まずはその日を目標に頑張ろう！」という共通認識をもててモチベーションを上げられたのも良かったです。
今回のプロダクトでは、機能別のリリースを5回に分割することで、最終的なリリース日の予測も立てやすくなったと感じています。
反省点
1.デッドラインが決まっていないので、他タスクを差し込んでしまう
今回のプロダクトはもともと自社用のプロダクトかつ別プロダクトからの移行というのもあり「絶対にこの日までにリリースしないといけない！」というデッドラインが決まっていませんでした。
そのような状況下で、事業部からはすでに運用中の他プロダクトについて「こんな機能を追加してほしい」だったり、「新しくクライアント向けのLPを作りたい」といった、メインで進めている新規プロダクト開発以外の開発依頼がきます。
本来であればできるだけ差し込みは行いたくないものの、「この新規プロダクト開発が終わってからやります」となると着手できるのが半年以上先になってしまうことや、前述のように新規プロダクト自体の明確なデッドラインがなかったこと、（あとは私のマネジメント力の甘さもあり…）新規プロダクト以外の開発タスクを安易に差し込んでしまうということが続きました。
もちろん中には事業部として重要度や緊急度が高く、差し込むのが正解だったものもありますが、差し込みが多発した結果、新規プロダクト自体の開発スピードが上がらず、リリースが延び延びになってしまったというのは否めません。
1つ1つの差し込みの依頼に対してもう少し取捨選択や、タイミングの調整をするべきであったと反省しています。
また、新規プロダクトに関してもデザインや仕様を決める際に「少し開発工数はかかるけど、このほうが使いやすいはず」という観点で決めてしまっていた部分もあり、それもリリースのデッドラインを決めていたら、もう少し工数観点も重視した判断ができていただろうと思っています。
2.仕様がきちんと決まっておらず、実装後の修正が発生する
今回のプロダクトの開発が3分の1ほど進んだ頃に、ふと「この機能の仕様ってどうなってるんだっけ」と思い調べようとしたところ、実は細かい仕様が決まっていなかったというものがありました。
私がPOを引き継いだ時の確認不足でもあるのですが、そこで初めて他の機能に関しても細かい仕様が決まっていない部分が意外と多いということに気づきました。
これは規模の大きい開発だったことや、アジャイル的に進めてきたということもあり、最初にすべて決めていなかったというのが背景にありました。
そこで急いで全機能の仕様とテストケースを一覧化し、エンジニアと認識合わせをしました。
本来ならここで「ふぅ、助かった」となるのですが、中にはすでにエンジニア側で「おそらくこういう仕様であろう」と機転を利かせてすでに実装していたものもあり、改めて決めた仕様と差分があったものを修正することになってしまいました。
今回のような開発スタイルの場合、開発着手前にすべての仕様を決めきるというのは難しかったとも思いますが、もう少し早いタイミングで仕様をすべて決めることができていたら、修正の工数をなくすことができたなと反省しています。
3.リリース時期の予測が大幅にズレる
前述の反省点1、2も大きく影響しているのですが、今回のプロダクトにおいて最終的なリリース月がほぼこの月になるだろう、と言えるようになったのは今月に入ってからでした。
事業部側には開発を開始した当初はリリース時期が「2020年春ごろ」と伝えていたものが途中で「2020年秋ごろ」と変わり、最終的には「2021年春」と、当初の予測から1年オーバーする形になってしまいました。
もちろんその間に体制変更でリソースが減少したり、大きな差し込み開発が入ったりで、仕方ない部分はあったものの、最初から分割リリースの方針で進めていたり、デッドラインを決めて差し込みタスクや仕様決めの判断を行っていたら、ここまでリリース予測がズレることはなかったのではないかと反省しています。
さいごに
色々と反省点も書きましたが、紆余曲折ありながらもやっと2年かけて開発してきた新規プロダクトがもう少しでリリースできる予定です！
ですが、今回のリリースも全体像の中の第一弾という位置づけで、まだまだ今後も開発が続きます。
事務領域に働き方革命を起こすための新規プロダクト開発を担ってくださるエンジニアを大募集しています！
ご興味持っていただけたら、ぜひ気軽に話を聞きにきてください＾＾