minne 開発プロセス

プロジェクトの最初に設計合宿@沖縄を開催してよかったこと

minne 開発プロセス

こんにちは!今年1月からminne事業部に配属されてエンジニアをしている@yumuです。

現在はとあるプロジェクトにアサインされていて、2月初旬には沖縄で2泊3日の設計合宿に参加しました!合宿中には機能に関連するテーブル等の設計や、開発タスクの詳細な分解などを行いました。

  1. 合宿をした背景
  2. 合宿前にやったこと
  3. 合宿中にやったこと
    1. テーブル設計
    2. バッチ処理の設計
    3. GraphQLのスキーマ設計
    4. タスクの分解
    5. 春秋さんと仲良くなる
  4. 合宿してよかったこと
  5. まとめ

合宿をした背景

今回のプロジェクトは業務委託でお世話になっている合同会社春秋さん(以下、春秋さん)と協力して進めています。春秋さんの拠点が沖縄にあるため、その近辺で合宿を行いました。

実は昨年も別のプロジェクトで同様の合宿を行っていて、今回は2回目の開催でした。前回、プロジェクトの初期にオフラインで合宿を行い、設計やタスクの分解を短期間で完成させることができたので、今回も同じアプローチを取りました。

合宿前にやったこと

前回と同じく、合宿前に要求の詳細化や合宿のゴール設定を行いました。設定したゴールは以下の通りです。

1. 見積もりが記入済みかつ担当が割り振り済みのタスク一覧が作成されていること
2. 見積もりを元にしたリリース目標日が設定されていること

また、今回は新たなチャレンジとして、合宿に臨む前に設計を仮fixさせました。前回の合宿では、合宿前に要求定義までしかやっていませんでしたが、今回はさらに一歩進んで、ER図、シーケンス図、GraphQLのスキーマ設計を事前に一通り完成させておきました。これらの設計に基づき、大まかなタスク分解まで事前に実施することができました。

合宿中にやったこと

テーブル設計

沖縄に到着した日の午後から作業を開始し、次の日の午前中まではテーブル設計に取り組みました。

minneのエンジニアで何度も設計レビュー会をしていたのでそれほど修正は入らないと予想していましたが、春秋さんから鋭い指摘が入り、それを取り込んだりディスカッションしたりしていたら丸一日かかりました。想定より時間はかかりましたが、時間が限られているからといって妥協せず、納得のいくまで議論をしたからこそ、素晴らしい設計を完成させることができたと考えています。

特に議論が盛り上がったのは、テーブルやカラムの命名や、あるカラムの変更履歴を持つ必要があるか否かといった内容でした。設計を変えるのか要求を調整するのかで迷う場面もあったので、プロダクトマネージャーの方が合宿に参加してくれていてありがたかったです。

結果、合宿前後でこんなにもテーブル設計が変わりました! モザイクがかかっていますが、各テーブルの大きさやリレーションが大きく変わったのがわかると思います。

テーブル設計

バッチ処理の設計

今回のプロジェクトでは定期的なバッチ処理が必要な機能があるため、その処理のシーケンス図を確認しました。

バッチ処理をRakeタスク+Kubernetes CronJobで行うか、Rakeタスク+Sidekiq Job+Kubernetes CronjobにしてRakeタスクの中の細かい処理をSidekiq Jobに任せるかが争点となりましたが、Sidekiq Jobを使用する場合1つ1つの処理のログを追うのが大変などといったデメリットがあるため、今回はRakeタスク内で処理を完結させることにしました。

また、冪等性をどう担保するかということも話題に上がりましたが、Redisに処理対象のレコードIDを保持し、Rakeタスク内で1つずつ要素をpopして処理していくという方法で落ち着きました。

バッチ処理について話し合う様子

GraphQLのスキーマ設計

minneではAPIのGraphQL化を進めており、今回のプロジェクトでも新しく追加する画面用のGraphQL周りの設計を行いました。

私はminneに配属されて初めてGraphQLに触れたのですが、事前にProduction Ready GraphQLという本を読んでいたおかげでしっかり議論に参加することができました。 特にtypeやfieldの命名ついて、ああでもないこうでもないと意見を出し合うのが楽しかったです。

タスクの分解

設計が出来上がったら、それを元にタスクの分解を行いました。 これも合宿前に大枠は作っていたので、その内容がfixした設計に即しているかの確認がメインとなりました。

タスクが分解できたら各タスクに人日単位の見積もりをつけ、担当を割り振っていきました。 見積もられた作業日数の合計からこのプロジェクトのリリース目標日が定められ、無事今回の合宿のゴールを達成することができました!

タスク一覧

春秋さんと仲良くなる

オフラインで会うのは初めてだったり、そもそも一緒に仕事をするのが初めてのメンバーもいましたが、合宿の3日間でランチを一緒に食べたりして仲良くなることができました! 建設的な議論をするための第一歩は忌憚なく意見を言い合える関係性を作ることだと思うので、プロジェクトの初期段階でそのような関係性を築けて良かったと思っています。

最終日の集合写真

合宿してよかったこと

やはり一番は短期間で設計をfixできたのが良かったです。 昨年同様合宿中は他のミーティングには極力参加しないようにしたので、設計だけに集中でき、かなり詳細に踏み込んだ議論をしたにも関わらず3日間という短い期間でタスクの分解まで持っていくことができました。

また、プロジェクトの最初にメンバー全員が要件や設計に関して認識を揃えられたことも良かったです。オンラインだと質問するタイミングが掴めないことがありますが、オフラインなので少しでも引っかかった点があれば逐一質問して解決することができました。認識を揃えておくとコードを書く人もレビューする人も仕様を確認したりするコストが減りますし、納得感を持って開発を進められると思います。

さらに、個人的には、先輩エンジニアに意見を言うハードルが下がったのが大きな成果でした。配属直後であることやエンジニアとしての経験が短いことから先輩エンジニアに対して遠慮してしまっていましたが、合宿中に必要に迫られて自分の意見を言っていたらいつの間にか堂々と意見を言えるようになりました。レベルが高いエンジニアの方々との議論を経て、私も普段からこのレベルの議論ができるようになりたいと思い、勉強にも力が入っています。

まとめ

オフラインで集中して行ったことで、十分な成果を出すことができた素晴らしい合宿になりました!プロジェクトメンバーにも「一緒にやっていくぞ!」という一体感が生まれたと思います。来年も機会があればぜひ合宿をしたいです。

沖縄は少し遠いですが、普段のオフィスと違う場所で、オフラインで集まって合宿を行うのは特に設計段階だとかなりタイムパフォーマンスがいいと思うのでぜひ試してみてください!