トータルフットボールなチームの成り立ち 〜エンジニア視点〜
先日、SonicGardenの代表の倉貫が『兼業のススメ〜トータルフットボールなチームを目指して』というブログを公開していました。
これを読んで、SonicGardenがどのような背景でトータルフットボールなチームになり始めたかをエンジニア視点で考えてみました。
2008年頃
SonicGarden内にもアプリチームとインフラチームという括りがありました。
アプリチームは、アプリケーションの設計/開発を行い、インフラチームはアプリケーションのバージョンアップ、サーバのメンテナンスなどをメインに行なっていました。
この時はほぼ分業制でソースコードをいじるのはアプリチームの人にお願いし、ツールやミドルウェア、サーバに関することはインフラチームの人にお願いするという風習で、各チームがその分野のエキスパートとして仕事をしていました。
2010年頃
SonicGardenのメンバーは最大8名になっていましたが、諸事情等によりメンバーが5名になりました。
メンバーが減っても今までやっていた仕事をただ単に減らすというわけにはいきません。
とにかく無駄を省き効率化し、今いるメンバーで仕事を回せるようにする必要がありました。
こなしていた仕事の中で必要性の低いタスクをやらなくするというだけでなく、より効率的に作業ができるようにならないかを全員で考えました。
繰り返し作業については作業内容をなるべくシンプルにし、さらに自動化することで作業量を減らしました。
また、全員が作業範囲を広げ合うことで、アプリチームとインフラチームの垣根がなくなり互いにの領域の知識を学び始めました。
すなわち、「かけもち」をしはじめたのです。
2011年
エンジニアが「かけもち」の範囲を広げた結果、開発から運用までを一人のエンジニアできるようになるDevOpsを実践するようになりました。
常に100%の品質や成果を求めるのではなく、対効果などを考えて品質、成果を考えることもできるようになってきました。
「それをやって本当に意味はあるんですか？」ということを常に考えるようになり、それと同時に対効果もエンジニア自身が考えるようになってきました。
振り返ってみると…
2008年頃は、チームが分離していたため、各チームがその役割を全うし過ぎ、機能的にアプリケーションが高機能なものになりがちでした。
また、インフラについても高可用性を実現するための検証や新しいミドルウェア/ツールの検証などをやり過ぎていたのかもしれません。
これは、参考ブログ中の"専門部署の人たちが真面目であればあるほど、その役割を全うしようとし過ぎて起きてしまうのです。"に該当するところです。
しかし、この時に培ったノウハウは今でも生きているという事実もあります。
ちなに2010年頃が大きな転機でした。
「かけもち」をすることになり、一人ひとりがスキル範囲を広げることで、これまで意識できていなかったところの改善も考えることができるようになってきたのです。
例えば、アプリケーションのバックアップの仕組みです。
当時、バックアップ作業はインフラチームが行うというのが当たり前でしたが、アプリケーションデータのバックアップをするためには、アプリケーションの内部のことも知っておく必要がありました。他にもアプリケーションの仕様上、バックアップを実行する時間なども制約がありました。
このような状況を回避するために backup というgemを利用して、アプリケーションデータのバックアップの仕組みもアプリケーションに持たせるなどの工夫をしました。
この工夫も、アプリケーションとインフラの両方の観点が無いと思いつかなかったように思えます。
最後にこれまでを振り返って見て、「かけもち」やDevOpsを実践するようになり、以下のような効果が得られたのではないかと個人的には思っています。
- アプリケーション開発/運用がよりシンプルな仕組みに
- エンジニアも機能開発時に意見を言うように（本当に必要な機能かどうかを含めて）
- いろんな人と組みながら複数のアプリケーション開発に携われるので技術知識が向上
上記のような効果が得られ、各個人がこなすことのできる仕事量も年々増えています。
おそらくというか必ず今後もSonicGarden内のスタイルは変化していくことでしょう。
