Digital Hack Day 2022 大反省会
2022/09/21
Digital Hack Day 2022 (9 月 17 日 ~ 9 月 18 日) という「日本のデジタル化」がテーマの 24 時間のハッカソンに参加しました。 技術的なこととマネジメント的なことについての大反省と学んだことを書いていきます。
目次
やったこと
ハッカソンには 6 人のチームで出場し、僕はバックエンドを担当しました。 立場としては全体のリーダーがバックエンドとフロントエンドの進捗を確認しつつインフラ構築をしている中、僕はもう一人のバックエンドのメンバーにタスクを振りながら進めていくという感じでした。
作品としてはタイムカプセルのデジタル化をしました。 (本当はもっと奥深いコンセプトとか時間をかけて詰められたアイデアとかがある)
全体の技術構成はバックエンドに Go (Goa) 、フロントエンドに TypeScript (Next.js) を使用し AWS でインフラを構築するという Web アプリでした。
開発の概要
バックエンドの API サーバは Go とそのフレームワークの一つである Goa を用いて構成していました。
また sqlc というパッケージを使用してテーブル定義とクエリを SQL で書いていくという方針でした。
マイグレーションファイルをテーブル定義として sqlc に渡し、 golang-migrate でマイグレーションを実行します。
なぜこのような構成にしたかは詳しく 前の記事 に書いてあります。
簡潔に言うと Goa の機能で API スキーマの DSL から OpenAPI とプレゼンテーション層の Go コードが生成され、 sqlc を使うことで Go の DB のモデルとクエリを叩くコードが生成されるため、開発者は内部ロジックを実装するだけで良いということです。
ORM などを使わずにわざわざ SQL を地道に書くのは、最終的に実行されている SQL を開発者が把握していた方が意図しない動作やバグが減るだろうという予測と、 DB のテーブルと Go のコードのモデルが乖離すると実行時エラーにつながる可能性があるため怖いという気持ちからです。
今回考えた構成は個人的には開発スピード・開発のしやすさ・コードの安全性の点で個人的にはメリットがあるように感じていたのですが、実際の開発となると想像しなかった課題が大量に見つかりました。
技術的なことの反省
まず sqlc についてですが、このパッケージ自体は素晴しいものですが、そもそもの話として SQL を書く必要があります (そりゃそう) 。
しかし僕を含むバックエンドを担当したメンバーは SQL に慣れていなかったのです!
やってみれば何とかなるだろうと思っていましたが、そこまで上手くはいきませんでした。
SELECT や INSERT などは書いたことはあるが中間テーブルを使った操作などは ORM を使っていたり既にあるコードを呼んだりしていて、自前で書いたことがないという状況でした。
さらにそれだけで無く、書いた SQL が正しく動作するか継続的に検証する方法がありませんでした。
合っているか不安なものは適当なレコードを挿入して試してみるなどをしていたため sqlc が生成した関数を呼ぶと正しい動作をしないという本末転倒なことがありました。
これについては、シード値を用意しておいてすぐに SQL を実行できる環境を作るか、テスト DB を用意してそこに対して SQL を実行するテストのようなものを同時に作れば良かったです。
また、 dev 環境と production 環境の差異を考えておらず、環境変数を .env から取っていたり (本当は AWS のパラメータストアから取ってきたい) 、環境によって処理を分岐させていなかったりということがありました。デプロイされたら自動でマイグレートされる仕組みも必要でした。
マネジメント的なことの反省
バックエンドのメンバーは 2 人で、一応僕が考えたアーキテクチャを採用するということでリーダー的な立ち位置でタスクをもう一人のメンバーに振っていたのですが、この時間と人のマネジメントという視点でも多くの反省点がありました。
24 時間という短時間で完成させるためには 2 人のどちらにも空き時間や待ち時間が発生すると良くありません。
そのためには開発全体の順序と流れを把握して自分のタスクをやりながら、メンバーの能力や知識を考慮した上で適切なタスクを振る必要がありますが、これがとても難しかったです。
こちらのタスクやレビューが終わっていないためにメンバーに何もタスクが無い状態になったり、メンバーのスキルを把握しきれておらず重めのタスクを振ってしまったりということがありました。
また自分とメンバーで技術やアーキテクチャに対する認識のずれがあり、開発に入る前に解消しておくべき疑問や不明点を開発中に説明することになり、時間を消費し効率良く開発ができませんでした。
これらに関しては事前にメンバーの能力や知識、経験、キャパを知っておくことと、お互いに技術やアーキテクチャの議論を徹底的にして疑問や認識のずれを解消することで解決できそうと思いました。さらに今回は僕自身の技術に関する理解が浅かったために上手く説明できなかったり、事前に問題を想定できなかったりということがあったため、タスクを振る側が使う技術に関して熟知している必要がありそうです。
人に仕事を振るということは実際の仕事となると、テックリードなどの名前が付かなくとも、僕のようなアルバイトが入社してきて自分がやるべきだったタスクを他のメンバーに振り分けて作業を進めていく状況になることもありえるため、嫌でも必須の能力なのだと感じます。
まとめ
今回のハッカソンでは技術的な面とそうでないマネジメント的な面でたくさん反省と学びがあり、とても刺激的な 24 時間でした。
開発中はチームメンバーにたくさん助けられました、 (なによりめちゃ楽しかった) ありがとう。