#132 事業をエンジニアリングする技術者たち②
こんにちは。ITベンチャーエンジニアのこへいです。
前回に引き続き、最近チームメンバーと一緒に読んでいるこの本を紹介します。
前回の記事はこちら。
〇第2章 Zucks ― フルサイクル開発者の文化
第1章で紹介したfluct社とは全く別の広告配信基盤を運用すうるZucksのシステム構築から現在までの航跡を紐解起きながら、開発チームの在り方とフルサイクルでの開発をいかにスケールさせるかについての話です。
私の印象に残った部分をピックアップしていきます。
Zucksのエンジニア文化
など、フルサイクルエンジニアであることが求められる文化にはとても共感しました。
弊社でもエンジニアが要件を深堀りするのは当たり前のことであり、そういうエンジニア集団であることが強みでもあります。
フルスタックとフルサイクルが混同されがちですが、Zucksでは下記のように整理しています。
弊社もフルスタックエンジニア集団と自称していますが、最近私自身はフルサイクルエンジニアであると自覚しています。
フルスタックでもありますが、フルサイクルで価値提供出来ることにより強い面白味を感じているからです。
〇ドキュメントが全く存在しないシステム
長く稼働しているシステムを開発していると立ち上げ当初からずっと在籍している人がいなくなったり、メンバーの入れ替わりが発生します。
その中でもフルサイクルの開発が続けられるということは『人を超えて永続化していける秘密』があるのだと思います。
一般的にはドキュメントを整備することで、コンテキストを共有することを志向しますが、その逆を行くZucksは下記のように考えているとのことです。
あえてドキュメント整備しない開発体制をどのように構築しているかというと、GitHubのissueにすべての情報を残し全文検索するという意外と腕力に頼った運用をしているとのことです。
ドキュメントは更新されていないとう前提でソースコードを追い、関連しそうなキーワードでissueを全文検索する。
この運用が回るように『動いているものが読みやすいコードでないとダメ』という考えが浸透している。
また、全体のお俯瞰やアーキテクチャに関する情報の伝達や共有はつどつどホワイトボードに集まて説明を繰り返すことで文章に残さずに済んでていると。
各人がフルサイクルで仕事を回すことが出来るからこそ、超ハイコンテクストなこの手法がとれ、開発速度と品質を担保出来るのだと思います。
チームの文化はスケールできるのか
Zucksの『互いに補い合いつつすべてがうまく回る文化』はスケーラビリティに疑問を感じてしまいます。
Zucksもスタート時は3人で、少人数だからこそ可能なやり方であることは理解しつつも、少しずつ人数が増えるたびに「そろそろ限界かな・・・」とお感じながらも今動けている状態を大事にしていると。
「人を増やしたいとは思っているけど、増やし方は考えていきたい」と、個々のメンバーが出来ることを増やすことでチームを強くしていく考え方を大切にしています。
〇第2章での学び
フルサイクルのエンジニアの集団をどのように構築し維持しているかのヒントが散りばめられており非常に学びが深い章でした。
受託のシステム開発をしている私の場合、特定の開発プロジェクトにおいてはZucksと同様にハイコンテクストをハイコンテクストなままでチーム全体でフォローし合うことでハイアウトプットを出すことが出来ていました。
しかし、人数の増加や複数プロジェクトを並行して進める状況においてはハイコンテクストのまま立ち向かうことに限界を感じ、開発速度の低下を肌で感じながらもドキュメント化によるキャッチアップコストの軽減に力を入れています。
Zucksでは新しくジョインしたら初日に機能をリリース出来るようにしており、ドキュメント化だけでないハイコンテクストをキャッチアップするオンボーディングの仕組みを整えることに力を入れています。
私もオンボーディングには力を入れていますが、Zucksの仕組みも積極的に真似させていただきます。
ということで、『事業をエンジニアリングする技術者たち』の第2章の紹介でした。
最後までお読みいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか?