概要
新卒のエンジニアの研修で、3週間程度で新規の成果物をつくる試みがあった際に、主にバックエンドやインフラで踏み抜いた地雷とこうすればよかったというのを書いていこうと思います。
状況
- インフラに慣れている人（本職レベルで）がいない
- バックエンドのスキルがバラバラ（railsだったりlaravelだったり）
- バックエンドメンバーは3人
- 採用した主な技術はgo, echo, gorm(ORM), sql-migrate
地雷その1: 開発期間が短く、インフラにリソースを割くのに厳格なクリーンアーキテクチャで作ろうとする
これは、自分たちのチームがアジャイル開発をしており、1日1スプリントで機能を実装するという、割と短期決戦型の方針を採っていたのに、基盤作成に時間がかかりなおかつapiを生やすまでにhandler, usecase, service, repository, entity, etc...と実装する箇所が多いし、ファーストコミットまでが遠いアーキテクチャを採用したのが敗因。
さらに、バックエンドのメンバーでクリーンアーキテクチャに触れたことはあるが0から実装する程理解のあるメンバーがおらず、だいぶ苦戦することとなった。
結果として2週目半ばくらいまで各APIが生えず、クリーンアーキテクチャを無視して機能を実装して動作することを優先することとなった。
こうすると良かった
当初クリーンアーキテクチャを採用するか否かのときに、時間がかかることが予想されてはいたのでデメリットを上げてチームメンバーに説明してはいたものの、実装のデッドラインや転換するときの方針を明確に決めていなかった。
方針を決めておけばズルズル行くこともなかったように思える。
地雷その2: 全体を見通せるメンバーがアーキテクチャの基盤を作り切るところまでを終えなかった
バックエンド~インフラの構成やアーキテクチャをある程度見通せるメンバーが、コンテナを立ち上げたり、ヘルスチェックのための疎通確認のコードは書いてから、各バックエンドのメンバーにタスクを振り分けてはいたものの、そこから各apiを作るまでが少しタスクの粒度として大きかった気がする。
その結果、各メンバーが今の実装で何が必要で、どの技術を使うのかの認識ずれていたり、PRの粒度があまりに大きくレビューが大変だったりした。
こうすると良かった
大体こんな感じの構成になるとわかっているメンバーが、最低限イメージをメンバーに共有したり、欲をいうとDIやらmodelやらhandlerやらを生成しておいて、タスクの粒度が軽くなってから各メンバーに振り分けられるようにすればよかった。
そうすることで各メンバー間での認識の相違や、ビジョンがズレることが少なく、動き出しやすかったように思える。
地雷その3: 各チームメンバーが一人でタスクを抱え込む事態が多発した
バックログで誰が今何のタスクをやっているか、このタスクの優先順位はどうかなど、一定程度透明性があったので、そこまでメンバー間のコミュニケーションについてチームでは気にしていなかったが、切ったタスクの粒度が間違っていたり、環境構築等のみんなで見れば数分で解決することをずっと抱え込んでしまっているメンバーもいた気がする。
こうすると良かった
おそらく、バックログやスプリント等の仕組みである程度透明性が担保されていたので、積極的に相談しやすい雰囲気づくりをしなかったのが問題。
メンバー同士でslack等のチャットで定期的に詰まったり困っていることはないか確認したり、あとは各メンバーがもう少し積極的にここがわからないというのを言えばよかった。
そういったことができる心理的な安全性を作り出すために、メンバーそれぞれが最初に自分は何ができて何は自信がない分野だ、というスキルの認識を合わせておけば、「こんなこと聞いても大丈夫かな」とかって尻込みしないように思う。
地雷その4: タスクの依存性を考えて進めなかった
この機能ができないとこの実装ができないとか、このapiができないとインフラに乗せても疎通確認が取れないとか、開発においてのタスクの優先順位、依存性を考慮して進めることができていなかった。
こうすると良かった
必須機能の確認をして、タスクに洗い出したあと、メンバー全員で優先順位とやる順番、最優先事項などを確認しておくと、優先順位が低いタスクをやり続けてしまうことがなかったように思える。
最後に
今まで自分が開発者としてチームにジョインするときは、あくまでエンジニアとしてしか関わらなかったが、今回はエンジニアだけでなく、PMやテックリード的な役割を経験することとなりました。
デメリットとしては実装やアーキテクチャを考えることに集中できず、役割過多になってしまったこともありました。一方で、普段PMの人はこんな進め方をしていたなとか、テックリード的な人はこんなことを普段考えているんだなということがわかりました。
具体的には、期日から逆算して機能実装のトレードオフの意思決定を行ったり、現状のチームのスキルや方向性、プロダクトの方針からアーキテクチャを決定したり、場合によっては、実装が詰まっていたら自分が実装に入って実装を完成させきる、といったことを学べました。