アイザック エンジニアの金井です。今回は2023年1年間で本番デプロイ数を815回をしたプロダクト開発現場の環境・状況などを紹介をしていきたいと思います。
といいますのも、DevOpsの文脈にて本番デプロイ数の頻度(4keys)がパフォーマンスが高いチームの指標として取り上げられるようになり時が経っておりますが、自分のエンジニア歴10年以上の経験の中では圧倒的に高い頻度の環境で1年を過ごしたので、その実態を紹介できればと思います。
慣らすと週に16回、1日2回などでしょうか。もちろん実際ムラはありますが、体感とは大きくずれていないかなと思います。
事業・システム環境
- 2年目グロースフェーズの新規事業
- CtoCサービス、24h365d利用ユーザがいる
- シンプルなモノレポ・モノリスサービス
- React Native, NestJS, Next.Js, Hasura, GCP
チーム構成
- PdM1名
- エンジニア フルタイム2名・パートタイム3名
- マーケター フルタイム2名・パートタイム3名
- デザイナー パートタイム1名
- CS フルタイム1名・パートタイム3名
事業に向き合える開発体験・環境
まず、自分の経験の中で最高に良い状態で開発に従事できていると思います。ここでの良いというのは事業成長・ユーザの価値に貢献できている、そのための時間に集中できるという意味です。
エンジニアチームの働き方・状態と事業成長の因果関係を示すのは難しいですが、1つの先行指標としてのデプロイ数が高かったこのチームでは、この1年事業成長もできていると感じています。
デプロイ頻度が高い = デプロイを日常的にやることにストレスとコストがかからない環境をもつエンジニアチームが事業成長に貢献できていると実体験から言える点は例えば以下になります。
1. 単純に機能をユーザに届けるまでのタイムの速さ
段階的に届けられるものは少しずつでもユーザにデリバリしていく方向性（Time to Marketの短さ）
2. 本番で発見した事実から改善をリリースするまでの短さ
実際のユーザデータ・動きからここ調整した方が良いなど気付いてから反映するまでの速さ。（実ユーザからの学習を活した改善の速さ。翌日には調整をリリースしたりなど。）
3. 作業自体には価値を生まない本番デプロイという時間の少なさ
時間・ストレスを取られないため、他の事業成長に繋がりやすい作業に時間を当てられる（ユーザデータ分析からの機能提案など）
こう書いてみると、どこかの本からとってつけたような内容ですが、この1年間の事実として感じております。
実現を可能にしている Key Factor
このチームにおいて、高いデプロイ頻度を実践できている要因は、開発フルサイクル全ての裁量・意思決定権を持つ独立したスモールチームでの業務を遂行できる環境。
これに尽きると思います。
デプロイ頻度の高さから視点を少し広げてアイザックのスモールチームの良さに触れていければと思います。
システム思考図でいくと、こんな関係性を感じます。繰り返しますが、これは正解、理想、理屈ではなく、この1年間、このチームで体験した事実です。独立したスモールチームを始点とした力学だろうと捉えております。
上記図の番号部分に触れてみます。
1. 技術プラクティスそのものの力はもちろんある、But.
DevOps, DORA, XP, Agileなどの文脈で言われるような技術的なプラクティスはもちろん支えになってくれると思いますし、本チームでも多くを実践しております。テスト自動化（仕様のコード化・テストデータのコード化）、デプロイ自動化、0ダウンタイムデプロイ、フィーチャーフラグ（デプロイとリリースの分離）、頻繁な統合（PUSH & マージ）、OTA update、最低限のCode Quality Gate、機能追加変更に伴う継続的なリファクタリングなど。
ですが、私の過去の経験・観測範囲では、個人の力で見れば技術プラクティスの知識・スキルをもっていても、実践ができない。実践ができていても、デプロイ頻度が上がらないという環境を多く経験してきました。
これは、独立したスモールチームの環境が生む力と感じておりますし、今回はそちらをフォーカスして触れたいと思います。
2 . 守備範囲の広いエンジニアの業務
スモールチームである = 全ての業務の裁量があること。
様々あるエンジニアの業務をその人数で全てを実行する必要があることになります
もちろん得意分野・役割分担はありつつも、学習のベクトルとしては各々がカバーできる範囲を増やす方向にになり、 結果としてフルサイクルなエンジニアにメンバが近づいていきます。
フルサイクル = フルスタック開発、システムモニタリング・CS・マーケ・デザイナーとの連携・対応、データ分析、施策効果測定、データドリブンの機能提案
3. フルサイクル視点での課題の発見
フルサイクルの体験・視点があると発見できる課題の内容の幅が変わってきます。 事業貢献するためにはどうするか、というテーマでの振り返りが現実に息をするようになってきます。（今のチームはそのテーマの方が多い状態になってきています）
4. 改善実行の裁量がある・全体視点での改善案議論に向かう
エンジニアの高い裁量 = 技術的プラクティスの実践・改善なども開発の優先順位を考慮しながら日々挑戦できる状態です。
この裁量が結果として技術的プラクティスの実践も高めていくことに繋がっていると感じます。
また、フルサイクルからくる視点によって事業成長にとって今重要か？という視点を持ちながらの時間の使い方と判断・会話に繋がっています。
これはエンジニアだけが嬉しいことに時間を使いすぎていないか？というバランス感覚を得る上で非常に重要なことに思います。
5. シームレスな工程からくる作業効率
必然的にエンジニア内で仕様を整理する人、設計する人、コードを書く人、テストする人、リリースする人、効果測定する人、データ分析する人は別れづらいです。
フルサイクルであることは、作業の引き渡し・引き継ぎ・待ち・中間生成物作成・コミュニケーションミスなどムダがないことに繋がっていくわけで、その分事業成長のために頭と手を使う時間が増やせる形です。
6 . 不要な開発をできるだけしない効率
開発の生産性を上げたい。というキーワードはよく耳にしますし、目指したいことですが、難しいです。（そもそも筋の良い計測も難しい。デプロイ頻度がある程度それを表してくれているとは感じております）。
エンジニアのスキルが効率の高い開発を導くことはもちろんありますが、成長は急にはできません、もちろん最大限の努力はしますが、事実を受け入れることも重要です。
なので、とにかくムダなことをしない。不要な開発はせずに重要なことに集中する。当たり前の話ですが本当に重要です。
やると決まった上でもエンジニア視点でコストが安い実現方法や、優先順位付の提案すること。これも努力できることです。
フルサイクルの視点を持っていること、事業の状況、データ感を知っていることがエンジニアの意見の幅につながっていることを感じます。
また、スモールチームであるとエンジニアの目標も事業の数字を伸ばすというPMと同じ視座の目標だけでも十分に活動ができ、中間指標のような位置付けの生産性を使わずとも、PMと信頼関係を持ったコミュニケーションができていると感じております。
7. 本質・コア作業以外の少なさからくる作業効率
例えば上述したようなチーム構成があった時に、そのメンバ以外との重いコミュニケーションや、プロセス、意思決定、承認、多い人数からくる打ち合わせ、待ち時間のようなものはほとんどありません。
”独立した”スモールチームといっているとても重要に感じる点は、全てのロールの人が裁量があるという点です。
エンジニアだけがそうでも、PM、デザイナ、マーケの人が複雑なプロセス・コミュニケーションパスを持っていると効率はまた変わってきてしまいます。
アイザックのチームは全てのロールの人が裁量高く行動しています。（業務委託のメンバも高い裁量で活動しております）
6,7はアイザックValueのLess is moreにも当たる部分になると思います
8 . シームレスな工程からくるデータドリブンの機能提案の効率
こちらは図上ではデプロイ頻度とは絡まない部分に位置しますが、ついでに触れておきたい部分として置いておきます。
事業特性・フェーズに大きく左右される部分もある項目であるとは思います。
機能改善の意思決定として以下のようなことを行うわけです。
- 機能レベルのユーザペインの仮説立て
- 仮説を確かめるデータ抽出
- データが足りなければ必要なデータ定義
- データの持ち方設計・実装・リリース
- また、仮説自体を手に入れるために探索的にデータを色々な角度で眺めたりする
これらの工程がエンジニアと別の人が分かれているとスピード感がでにくいことがあると思います。
例えば関わる人が増えると以下のようなことが起きます。
- データの定義認識ずれが起きる
- あとからこのデータも欲しい、この形にしてほしいなど往復が起きる、お互い心理負荷もでてきたりする
- 特に自由な発想で探索的にデータを見るような活動をエンジニア以外ができるようにするにはデータ基盤・ツールをしっかり整える必要があるわけですが、その構築・運用・メンテの時間を確保する必要がある
現時点でのフェーズでは、データの構造・定義に詳しく、クエリを書く速度も速い(Ghat GPTが）、データが足りなければ収集項目を追加して即リリースしたりなど、エンジニアが担っていることは効率的に感じております。
ムダ・ストレスがとにかく少ない開発体験がある。アイザックのカルチャーは何がそうさせるのか
色々それっぽいことを書きましたが、関係者が・人が少なければ（独立して動ければ）自然とそうなるよね。ということばかりな気もします。 ただ、ついそれを維持できなくってしまうことも多くあると思いますがkeepしようという考えをアイザックは持っております。
また、とにかくムダ・ストレスがない開発体験の環境だと強く感じておりますが、それがなぜ・何がそうさせているのか。私自身まだまだ興味があります。
今回はスモールチームの話を取り上げ、上述のように因果図みたいなものを書いておりますが、書かれていない要素がまだまだ複雑に作用した結果、今の開発体験が作られていると感じます。
重要なファクトだと捉えてみているものの、はい、スモールチームにしました。最高の開発体験になります。という単純な話でもないというところです。
実現のために裁量を与えられる環境づくり、実践できるスキルがある人、事業成長に関心がある人を集められる。など、この辺りもまた触れられたら良いなと思いますし、 上記の因果図に要素を足して拡張していくことも実験してみたいたと思っております。
そんなことを通してアイザックのカルチャーを伝えていくことができたらと考えております。
会社のカルチャーがわかるような記事はnoteにも色々ありますので、ここからでもぜひ見てみてくださいませ。 note.com
アイザックの文化・指針としてのスモールチーム
代表の田中はエンジニアでRubyのコミッター。
37signalsの会社運営にヒントを得ているとのこと。
代表田中のインタビュー記事 note.com
また、こちらのDHH著の本がバイブルでもあるそうです。（若干違う文脈でのスモールチームの話ではありますが）
いかがだったでしょうか
いかがだったでしょうか、アイザックの開発現場のイメージが伝わればと思います。
普段からこの記事のようなことを考えているわけではなく、振り返ってまとめてみました。
普段は事業・ユーザのことを考える毎日ですし、そこに集中できる環境、メンバと働けていることが本当に楽しく感じております。
記事に書いたことは美しく偉そうに見えてしまうかもしれませんが、実際は、さらに良く実践すべく奮闘しておりますし、チーム・システム・組織が大きくなるタイミングが来た時にどう変化させるべきかも考え続けることになると思います。
記事のような環境・考え方に共感いただける、興味がある方や一緒に作り・目指し続けていける方とぜひ一緒に働きたいと思っております！
アイザックでは、一緒に「世の中を実験する」仲間を募集しています！ご興味を持ってくださった方は、こちらのお問い合わせフォームからエントリーください。
採用に関する詳細は以下のページをご覧ください。
