やる気がストロングZERO

やる気のストロングスタイル

テックリード・アーキテクトやってみた感想

ここ数ヶ月、業務でテックリードとしてシステム構築の設計と実装のリードをやってきて、区切りができたので、

  • 良かったこと
  • 良くなかったこと

をまとめてみる。

自分の役割(全体設計・実装作業のリード)

職場ではテックリードって役割になっているけど、別に高度な技術を先導するとかはしてなくて、主に設計周りをやってるので「アーキテクト」のほうがしっくりくるかも。

システムの全体設計(言語選択・ミドルウェア選択・構造構築など)と、完成に向けての実装タスクの切り出しと、開発メンバーへのタスクの依頼とコードレビューを行った。

やって良かったこと

開発環境構築を自動化した

最初に開発環境の構築を一人で行った。
docker-compose upで必要な実行環境や開発用ミドルウェアがすべて立ち上がるようにした。

構築には地味に時間かけたけど、誰でも簡単にコマンド一発で開発環境が整うようにしたおかげで途中参加メンバーもスムーズに開発業務に入れたし、なんか環境がおかしくなっても基本的には作り直せば治るので、このあたりのコスト削減効果はあったなと感じた。
メンバーが多くなればなるほどここの部分は生きてくると思う。

また「外部サーバーとやり取りする部分」などの実装はテスト実行することが難しいが、外部サーバーを模したコンテナを用意してテスト実行しながら実装を進めることが出来るようにし、スムーズに実装してもらうことができた。

全体設計を自分一人に任せてもらえた

全体設計を自分一人に任せてもらえたのは良かった。

たぶん、複数人で検討すると意見が割れて落とし所を探す感じになり、一貫した設計ができなかったのではないかと思った。
また、一人でやることで責任の所在がハッキリし「設計が破綻したら自分の責任」と思うと死ぬ気で考えることができた。

細かめの粒度で実装タスクを切り出ししたことで品質管理が楽だった

全体設計を終えたあと、必要な処理をできるだけ単純な単体処理に切り出して実装タスクにし、テストコードも書いてもらうようにお願いした。

上がってきたコードをレビューする際

  • テストコードにより、期待通りの結果が得られているかが判断しやすい
  • 処理が単純なのでコードの理解がしやすくレビューもしやすい
  • 仮にコードがマズくてもその影響範囲は関数内に収まるので破綻はしない

のような感じで、ある程度ラフにレビューを進めることができた。

良くなかったこと

自分がボトルネックになった

「設計」「タスク切り出し」「レビュー」をやってると、実装メンバーの開発速度に追いつかれてしまう事がちょいちょいあった。
このプロジェクトに専任出来たらもう少し速度を挙げられた気がするけど難しかった。

つつかれて切り出し切れていないタスクをざっくりと依頼するようなことも増えてしまったが、実装メンバーの力量によってはざっくり渡したほうが速度が上がることがわかった。このあたり調整のしどころかも。

DB設計から関わりたいと思った

自分に話が回ったきた時にはある程度DB設計が済んだ状態だった。
たぶんそれは今回の目的に特化した構造になっていて、それ故テーブル構造はシンプルなんだけど、 その時想定されていた事情外の事が発生すると結構コード側で頑張る感じになってしまう。

僕個人はテーブル構造とか、システム構造はできるだけ汎用的にしたいと思っていて、 こうしておくと考慮外の事情(主に運用が始まってから)にも低コストで対応できるけど、 構築自体には工数がかかる。

特定の目的に特化させたテーブル構造、システム構造は構築は早いけど、考慮外の事が発生すると対応が難しくてここで工数がかかる。

僕は多分汎用性に寄りすぎた思想なので、もう少しバランスをとった考え方が出来るようになったほうがいいのかも。

まとめ

メンバーに恵まれたのもあり「システムを作る」事自体は問題なく行えると感じた。

ただし「プロジェクトが成功するかどうか」というのは、もう少し上のレイヤーの部分での立ち振舞による気がしてきた。