スタートアップにおけるプロダクトの守備戦略

2021年12月1日 10:22

この記事はUMITRON Advent Calendar 2021 1日目の記事です。

こんにちは、UMITRONの宮山（@jkatagi）です。最近は新たに立ち上げたコリドラスパンダ用の水槽を眺めるのを楽しみに生きています。Advent Calendarの時期がやってきたということでアウトプットしたいな〜と思い、会社のAdvent Calendarを作成しました。UMITRONはまだ社員数が30人強なのでスカスカになるかなとも思いましたが、思ったより埋まって安心しました（何人かの方は複数記事を書いてくれるようです）。さて、UMITRON Advent Calendar 1日目はスタートアップにおけるプロダクトの守備戦略という内容をお届けします。

プロダクトの守備戦略とは

ここではプロダクトの守備戦略を「ユーザーに提供する価値に直結はしないが、プロダクト開発を安定して行うための戦略」と定義します。具体的には後述しますがCI/CDの整備やテストなどを取り入れることです。私が開発に携わっているプロダクトはリリースから約1年ほど経過しており、ソースコードも徐々に肥大化してきています。当時の状況としては

・React + JavaScript
・命名規則やコーディング規則は明文化されていない
・テストはほぼ手動テスト
・CDは導入されており、リリースは自動化されている
・lintは導入されていない

という状況でした。4ヶ月後に新しいデザインのリリースを予定しており、このままの状況で開発を進めるとちょっと危ないよねということになり、チームで守備戦略を固めることになりました。具体的にはチームの目線合わせを行い、やることをざっくり担当者に振り分けて調査から導入まで行うことになりました。いくつかあった中で、私は以下を担当しました：

・TypeScriptの導入
・CIの整備
・lintの導入
・テストの導入
・GItHub Actions + git-pr-releaseによるリリースPR作成の自動化

実際に採用したこと

TypeScriptの導入

チーム満足度：★★★★★

これは個人的に最優先課題と位置付けていました。もう素のJavaScriptは書きたくないという気持ちが強く（実行時エラーは嫌だ、エディターによる補完が効いて欲しい）、チームメンバーにもその旨を共有しました。ただ、一度に全てのコードを一気に書き換えるのは難しいので、以下のルールで運用しました：

・新規コードは必ずTypeScriptで書く
・既存のコードに手をいじる時にできたらTypeScriptに書き換える

このシンプルな二つのルールでも意外とTypeScript化が進んでいきました。チームメンバーからも「もうJavaScriptは書きたくない」という声も届きました。また書き換え中には定期的にTypeScriptの割合を調べてトラッキングしてみました。徐々に書き変わっていく様子は見ていて楽しいですね。

スクリーンショット 2021-11-26 15.39.20

CIの整備

チーム満足度：★★★★☆

TypeScriptを導入しながら並行してCIの整備も進めました。TypeScriptの利点としての型チェックをCIで行い、また次に述べるlintを組み合わせることによってデプロイ前のコードの品質向上を目指しました。CI自体はAWS CodeBuildを採用しました。理由としてはすでにチームでCodePipeline/CodeBuildを採用しているからです。GitHubにpushされるとCIが走り、型チェックやlint、テストにこけるとfailになるようにしました。

lintの導入

チーム満足度：★★★★☆

lintもTypeScript導入と同じくらい個人的にはやるぞ！という気持ちが強いものでした。ルールは基本的にはeslint-config-airbnbに従い、運用していく中で足りないルールがあれば都度検討するという形になりました。なお最初のlint適用時はかなりの（--fixで自動で直らない）
diffが出ましたが、そこは強い気持ちで一つずつルールを調べて直していきました。この作業は一見地味ですが、なぜlintで弾かれているのかの理由を調べる面白さがありました（ただやはり最初からlintは導入した方がいいよね、という気持ちは変わりありません）。

テストの導入

チーム満足度：★★★☆☆

テストの導入は実際には2回を経て行われることになりました。第一弾はテストがなぜ必要かの明文化・チームの目線合わせおよびテストの例を書くことでした。

（社内Confluenceより一部抜粋）
t_wadaさんの資料を参考にしつつ、チームに共有しました。これ自体はよかったのですが、その後私が書いたテストの例に続くテストはあまり書かれませんでした。そこで第二弾としてなぜテストが書かれなかったのかの（私自身の）反省を踏まえてテスト戦略の見直しを行いました。

このミーティングで課題が見えてきたので、Next Actionとしてさらに細かくタスクを分解して個別にそのタスクを振ることによって、徐々にテストを書く文化が根付いてきました。なおチーム満足度が星3つなのはスムーズな導入に至らなかった点を考慮したためです。

GItHub Actions + git-pr-releaseによるリリースPR作成の自動化

チーム満足度：★★★★☆

これはシュッとできるものだったのですぐにやりました。それまでは各自のローカルPCにリリース用のツール（git daily）をインストールしていたのですが、なるべくそういう作業は自動化したいという気持ちがあったのでシュッと導入しました。なおgit-pr-relase単体で導入するより、GitHub ActionsなどのCI/CDと併用した方がより効果があると思います。

採用しなかったこと

上記では採用したことを挙げてきましたが、採用しなかった（採用を現段階では見送った）ものもありました。例えば

・StoryBookの導入
・AutifyなどのUIテストツールの導入

が挙げられます。理由はそれぞれですが、主に次に述べる攻めと守りのバランス感によるものです。

スタートアップにおける攻めと守りのバランス感

今回何を採用するか・何を優先していくかを考えていく中で、常に攻めと守りのバランス感を意識していました。守りの戦略は開発が安定することにより、長期的に見れば顧客に提供する価値の最大化につながると思われます。一方でスタートアップでは開発人数が限られているため、誰か一人がつきっきりで守備戦略に専念してしまうと、その分短期的な顧客価値の提供が減少してしまいます。今回の内容はフロントエンドにかなり寄っていますが、実際にはチームメンバーは他の領域も担当しています（例えば私はバックエンド・ETLなども兼任しています）。そのことを意識し、例えば「このツールの調査には1日を設定し、それを超えたら見送る」「テストはクリティカルなところを重点的にカバーし、そうでないところは手動テストを活用する」といったことをしました。その一方で例え採用を見送ったとしても、どこまでやったかやなぜ見送ったかはなるべくWiki（Confluence）に明記しておくようにもしました（TODOコメントも活用）。こうすることによって、時間に余裕ができた時に再度チャレンジしたり、状況が変わって優先度が上がった時に振り返りができるようになります。またチーム内でも誰か一人がずっと守備に回るのではなく、攻め（UI/UXの向上や機能の実装）と守りを週や月によって変えるということも行いました。これはチーム全体へのナレッジの共有にも繋がったと思います。

おわりに

スタートアップにおけるプロダクトの守備戦略という内容を今回書きました。個々の導入事例（TypeScript化やCIの整備など）は巷にあふれていますが、UMITRONでも（バランス感に気をつけながら）やっているよ！ということを伝えたく書きました。この手の内容は採用の募集要項や社員のインタビュー記事にはなかなか出ことない内容なので今回取り上げてみました。他にも今回書ききれなかった改善を合間を見つけながら日々取り組んでいますが、それはまたの機会に。

次回はtakc923さんによる「 Docker for Macのファイルアクセス速くなるかも」です、お楽しみに！