STORES のバックエンドエンジニアとして働いている sgr です。
今回は機能開発時にプロトタイプを作ることで不確実性を減らしたよーという話をします。
この記事は STORES Advent Calendar の 12 日目です。

プロトタイプを作る

チームの背景

当時進行していたプロジェクトでは、開発途中に PdM が育休で不在になることが事前にチームへ共有されていました。
PdM が不在でもプロジェクトが進行できるようプロジェクト開始時から PdM の役割を開発メンバーでも担う動きを取ることにしていました。
具体的にはプロジェクトマネジメントや外部のステークホルダーとの連絡をエンジニアが主導で行い、アダプション周りのドキュメント更新対応もエンジニアが積極的に協力していくことを目指しました。
その中で機能実装にどれくらいの工数が必要なのか、不確実な部分を洗い出して見積もりするためにプロトタイプを作ることにしました。当該プロジェクトは技術的な面が強いものだったので PdM よりエンジニア主体で洗い出しを行うほうがよりスムーズに出来て、あとから考えるとよい動きだったなと思っています。

プロトタイプを作るうえで気をつけたこと

プロトタイプで確認したいことは大まかな設計方針を建てられることと、障害になりそうな箇所を早期に発見することです。未来に発生する可能性のある問題を事前に把握することで実装着手より前に対処出来ます。
その上で、プロトタイプを作りすぎないことを心がけました。前述のとおり将来の見通しを立てる目的で作っているため必ずしも動くものを作る必要はないと考えています。ベタ書きでいいし DRY の原則に従う必要もなくテストも書いていません。捨てることを前提にプロトタイプを作ることで、実際に issue ベースで実装するときもプロトタイプに引っ張られず作ることが出来るので目的を見誤ることがないと思います。
また、機能規模にもよりますがプロトタイプを作成、共有するということはコードを読むことになり口頭説明よりもエンジニアが理解するコストは低くなって便利です。

失敗したこと

プロトタイプを作って事前に問題を見つけて対処しながらプロジェクトを進めていくことが出来ましたが、失敗したこともあります。
機能実装のコアとなる部分や不確実性が高いと予測される領域のみをプロトタイプで作り、機能すべてをプロトタイプでカバーすることはしていませんでした。つまりプロトタイプで網羅していなかった部分で予想しない問題が発生しました。
問題の規模としてはそれほど大きくありませんでしたが、知識があるから大丈夫だろうとか難しい箇所ではないから問題ないだろうという甘い気持ちからプロトタイプの作成を怠った結果だと考えています。出来る限り端折らず機能実装に関わる部分はプロトタイプを作っておいたほうが安心出来るので今後はそうしていきたいです。

まとめ

プロトタイプを作ることでプロジェクト開始から本格実装までの時間が伸びる可能性がありますが長期的に見ると将来起きる可能性のある問題を事前に対処出来てプロジェクトを健康的に保つことが出来ます。問題が発生してから対処するよりも心理的な面でも余裕を持てました。
問題そのものを無いものとして進めることが出来るのでプロジェクトがスムーズに進行していると実感できます。
プロトタイプの作成はおすすめです。