こんにちは、Findy CTO の @ma3tk です。

Findyで開発力を2倍にしていくぞ！と改善を繰り返した結果3倍の成果になったのですが、そこから得られた話を書いてみます。

2021年初頭に起きていたこと

2021年初頭、Findy、Findy Teamsの開発プロセスは全体的に課題が多く、無数の課題に悩まされていました。

• リリースが毎週1回
• CIが回るのに30分
• ビルドするのに1時間
• ユニットテストカバレッジ30%
• プルリクがコンフリクトしやすい
• ファーストレビューまで3〜5日かかる
• JavaScript + FlowType …

どれも課題は大きく、数年かけて直しながらプロダクトを作る必要ある…という状態でした。

2021年末の実績

2021年、ここで大きな決断をしました。新機能の開発をなるべく減らして、開発者体験を良くし、圧倒的に爆速で顧客価値提供をできるようにする。開発力2倍。

開発スピードを上げることで全てが解決するわけでもないですが、まずは単純に顧客価値提供が1週間で1回は少ないなというのを解消したい。小さな改善でもいいから秒で出していかないともったいない。初期は1人で作っていたのですぐに出せていた。あの感覚をチームでやりたい。

詳しくは過去の記事に書きましたが、

• リリースはフロントエンドで1日1〜2回、バックエンドも1日1回
• CIはフロントエンド最短30秒、バックエンドも最大10分
• リリースビルドは数分
• ユニットテストカバレッジ90%
• レビューは土日のバッファ入れても5時間
• TypeScript化

様々な課題を潰してきました。

プルリクエストが2021年初頭は1人1日平均0.8件のプルリク数でしたが、現在は1人あたり2.2件まで増えました。月間だと、1人あたり44件ほど作成し、99%が対処され放置されているプルリクがほぼない状態になりました。

よかったこと: ユーザからの反応が圧倒的に良くなった

この開発者体験の向上を行った結果、2021年前半は特に無風でしたが、後半からは「ツイッターで呟いてからバク対応完了まで5時間は早すぎます(笑)」といった声だとか、「カスタマーサクセスの方にフィードバックするとすぐに実装してくれるのでフィードバックしがいがある」とまで言っていただけるようになりました。圧倒的に反応がよくなったなぁと思うことができるようになり、会社内でも「早いｗ」という声が多数出てくるようになりました。ありがたい。

フィードバックしても変わらない体験があるとどうしてもフィードバックしなくていいなと思っちゃいますが、変わるとわかると少しでも声あげやすくなるのかなと思います。実際に僕も反応が早いサービスなどはよくメッセージ送ったりしています。

その他にも、Findy社の採用も進めている中で、「Findyの開発は爆速って仰ってましたが、実際にお問い合わせ連絡してから爆速で修正完了の連絡が来たので受けに来ました」と仰ってもらうこともありました。

一重に、開発に関わってもらっている全てのメンバーの頑張りに感謝です。改めてありがとうございます。

2021年はスピード感ある開発ができるようになり、当初考えていた開発基盤の改修はできてきた、というところではありましたが、最近起きた課題もあります。

課題: 圧倒的に企画の量が足りない

2021年は佐藤の企画と仕様作成で回っていた状況でしたが、

• 開発基盤に関する課題が徐々に減ってきた結果、新規で機能が作れるようになった
• 新規で機能が作れるようになった結果、イシューが消化できるようになってきた
• イシューが消化できるようになってきた結果、企画のサイクルがボトルネックになってきた

という状況になりました。1年前には想像もしていなかったような課題が課題になりました。

• PdMの採用よりもエンジニアメンバーの採用に力を入れていた
• 企画メンバーがそこまで増えていなかった(大きな反省)
• かつ僕や代表の山田が企画も兼務していたが、別課題で時間が取られていた

エンジニアの採用も非常に大変ですが、PdMの採用も困っている方多いんじゃないでしょうか。弊社もやはりここは大変なポジションではあります…！ｗ

2022年の前半は企画スピードを上げるために、

• メンバーを育成して企画力を上げる
• メンバーを採用して企画チームを増やす
• 企画が増えるとデザインできるメンバーも必要になるので採用する

というような動き方が必要になりそうです。

この経験でわかったこととして、エンジニアリングの課題が解決すると、プロダクト開発全体の課題のどこかがボトルネックになっていくのだな、ということを身にしみて感じました。開発スピードがいきなり早くなったという経験が初めてだったので、早期に予見できなかったなぁと改めて反省です。

創業メンバーと一緒に企画づくりしたい方、PdMやりませんか？

ここからは宣伝ですが、上記のようなプロダクト開発のスピードを挙げていくために、代表の山田や僕と企画をしたいPdMの方いませんか？

• Findyのビジネスドメイン(エンジニア組織づくり、エンジニアのキャリア)に興味のある方
• 事業全体を見ながら企画し、爆速で意思決定したい方
• ユーザの声を聞きながら数値を見てトライアンドエラーしたい方
• Findyのバリューを体現できる方

是非興味ある方はこちらから！

是非お待ちしてます！

「開発スピードを上げる」ことは「爆速で顧客価値提供する」ための必要条件

Findy Teamsなどで開発スピードを定期的に観測していくと、「数値を良くしないといけない！」となったりする方もいると思います。

開発スピードは早いに越したことはないですが、開発スピードを早くしようとして「ユーザに向けた機能提供や改善が0」「開発が遅くて開発の遅い人を咎める」などの本質からズレた状況になってしまうといくら開発スピードが早くてもユーザから見て価値はゼロです。何も変わってないサービスですよね。

エンジニアリングの範囲は企業によりますが、開発スピードを意識しながらいかにユーザの価値になっているかを考え続けられる組織が一番強いと思います。また、「開発をしない選択肢を取ることで開発スピードも考えなくて良くなる」のが費用的にもスピード的にも最強ですが…ｗ

エンジニアリングをやっているとユーザのことを棚に上げて自己投資を多くしてしまうこともあるかと思いますが、チームでサービスを提供する以上、様々な要素を考慮してユーザファーストのものを作れることがいいかと思います。それが前提での「開発スピードを上げるのももちろん大事で良いことである」というのが僕の答えです。

開発スピードは上がったことでトータルのユーザへの価値提供スピードも上がったのはとてもいいことではありますが、今の所Findyでは他の工程のスピードがボトルネックになっている状況です。つまりは改善が見込まれてくるなら先手を打って別な箇所の改善/全体最適を行うべき、というのが得られた結論でした。

とはいえ、今回の事象を通じて開発スピードを上げることは、全体最適とは必ずしも言えないが、よくボトルネックになりがちな開発スピードを上げることで価値提供スピードのインパクトを十分に上げることができるというのがわかりました。

開発スピードを上げるには、定量的に分析するのが最良だと思うので、是非Findy Teamsを使って現状の自社の開発スピードを可視化していくのがおすすめです！