ダイニーの開発ライフサイクル
こんにちは！ダイニーでソフトウェアエンジニアとして働く木村 (@1130_kimu)です。
前回のエンジニアリングブログ では、先月弊社で開催した HASURA CON'21 Recap について記事を書きました💪
この記事では Hasura をフル活用しているエンジニア組織が、どのようなライフサイクルを持って開発を進めているかについて紹介します！
ダイニーのプロダクト
弊社では飲食店のインフラとなるサービスを作るべく、飲食店オペレーションを支えるプロダクトを数多く開発しています。
現在ローンチ済みのプロダクトについては以下の記事をご覧ください (なおこの記事はすでに若干古くなっており、さらに新しくローンチ済みのプロダクトもあります)。
飲食店のインフラとなるサービスを作るにあたり、ダイニーが開発目標として掲げているのは以下の項目です。
1. オペレーションを支える上で重要な顧客要望への対応
2. 飲食店のインフラとなるに足る安定性向上へのコミット
3. お店のファンを増やし、飲食店の価値を高めるための新機能開発
これらを同時に開発する環境を実現するために、ダイニーが構想・実践している開発ライフサイクルについてご紹介します。
ダイニーの開発ライフサイクル
それぞれの開発目標がどのようにしてバックログに入るのか、目標ごとにご紹介します。
1. オペレーションを支える上で重要な顧客要望への対応
顧客要望への対応は以上のようなサイクルで行われます。
顧客要望分析定例
CS や Sales が顧客と対面のやりとりをする中で、顧客からの要望が顧客要望管理 DB に集まります。
顧客要望分析定例は、
Biz と Dev が要望・課題の背景を共有し
要望・課題が出てきた要員について考察し
バックログタスクや重要課題として分解する
ことを目的に行います。
2. 飲食店のインフラとなるに足る安定性向上へのコミット
3. お店のファンを増やし、飲食店の価値を高めるための新機能開発
これら二つの目標については、重要課題として管理されている課題の一覧からロードマップにブレイクダウンされるところから始まります。
PM によってプロジェクトされたプロジェクトは、Tech Lead によって一連のタスクに分解され、それはバックログに入る前に必ずキックオフによって Dev チーム全体に共有されるという流れです。
キックオフ
ダイニーでは、新たに始まるプロジェクトについては必ずキックオフを行うようにしています。これはプロダクトチーム全員がプロジェクトの背景を認識し、ここで懸念点や改善点を洗い出すことによって、タスク着手以降のフローを円滑に進める目的で行っています。
キックオフではブレイクダウンされたタスクについて確認し、PdM やデザイナーも含めてその内容についてディスカッションします。
バックログタスクのサイクル
バックログタスクがスプリントに入り、リリースされるまでのサイクルは上記画像のような流れになります。
タスク着手
ダイニーではアジリティを高く保つため、Hasura の採用や技術スタックの統一などによって、全員が幅広い領域のタスクをこなせるような形になっています。
ダイニーのエンジニアリングにおける戦略は以下の記事にまとまっています。ぜひご一読ください。
そのため、タスク着手の段階においてはどのようなタスクであっても全員が上から順にタスクを取っていけるような体制になっています。これがダイニーの高速な開発支える開発体制です。
QA
ダイニーではスピード感をもって新規開発や改善を進めるため、QA を外部リソースの QA エンジニアの方にお願いしています。
検証のプロによる徹底的な精査を経てリリースしているため、細かい不具合まで取り除きつつリリースサイクルを回すことができる体制となっています。
まとめ
今回はダイニーの開発ライフサイクルについて記事にしてみました。スタートアップの開発体制は流動的になりがちな中で、それに耐えうるようなライフサイクルを考えた結果、上記のようなライフサイクルに辿り着きました。
もちろん、上記のライフサイクルについては日々改善が続いています。開発ライフサイクルを考える上で参考にしていただけると嬉しいです！
dinii では Hasura を使い倒してみたいエンジニアを絶賛募集中です。
dinii の開発チームが少しでも気になった方は是非お声がけください！
興味がある方は採用ページから。
最後まで読んでくださりありがとうございます！ 公式Xでもダイニーの最新情報をキャッチいただけます！
