これはなに？
エンジニアリング組織を作る中で感じたことについてのポエムです。
内容について
- 規模感について
- 用語について
- エンジニアリング組織においての銀の弾丸が存在しない
- まずは小さく初めて改善をする
- 開発組織を作るエンジニアの意義と重要性
- その他
- まとめ
規模感について
プロダクトの中にある1チームの中のエンジニアリング組織について
- チームのメンバー構成
- ビジネス:8名
- PM：2名
- エンジニア：6名
- デザイナー：2名
- 自分のポジションはエンジニアリーダとしてエンジニアリング組織の最適化
- 目的とするKPI（ex. 100万PV増加）は明確に定められている
- 発足して4ヶ月が経過したところ
用語
「チーム」と「エンジニアリング組織」
チームの中にエンジニアリング組織があるイメージ。
エンジニアは、他の横断的な改善チームやプラットフォームのチームにも所属しているため、エンジニアの活動が特定のチームの中のエンジニアリング組織だけではないが、今回はシンプルに考えるために特定のチームのエンジニアリング組織について記載する。
エンジニアリング組織においての銀の弾丸が存在しない
エンジニアリング組織を作るとなったときに、はじめに本や記事を読んだり、他のチームのエンジニアリング組織についての調査を行いました。
社内の調査をしている中で目標とチーム状態にあっていると思ったのが「グロースエンジニアリング」でした。グロースエンジニアリングの詳細はこちら（note - シリコンバレーで流行りの、分析・仕様策定・実装まで行うグロースエンジニアとは？）。
選定基準したときの理由はざっくり下記になります。
- エンジニア主導で進められる状態を作って、エンジニアのやることがない状態を作りたくなかった。
- エンジニアの待ち時間を減らして、打ち手を増やしたかった。
- エンジニアやデザイナーが直接数字や事業に対してのコミットできる状態を作りたかった。
1ヶ月ほどで構想から実行までを行いましたが、グロースエンジニアリングは今回のエンジニアリング組織の中でうまくワークしませんでした。
なぜワークしなかったかというと、グロースエンジニアリングを目的ベースで入れたために、自分たちのエンジニアリング組織においての本当の課題を解決しているものではなかったからだと思っています。
エンジニアリング組織を作るということは、プロダクト開発と同じでメンバー（ユーザ）の課題を発見して、改善することを繰り返すことだと思います。
世の中には多くの「銀の弾丸」に見えるようなフレームワークや技法が存在していますが、同じ課題や目的があったとしてもそのまま適応できるものは存在しないと思います。
目的や目指す状態に合ったフレームワークや技法を取り入れるよりも、エンジニアリング組織の課題や問題を発見する方が近道になると思います。
(* グロースエンジニアリングの考え方が悪いわけではい。)
まずは小さく初めて改善をする
エンジニアリング組織の課題や問題を見つけたときに、まずは「小さく初めてみる」のがいいと思いました。
リーンな開発で用いられるMVPの概念と同じで、エンジニアリング組織でもMinimumで改善を行い、エンジニアリング組織からのフィードバックを元にさらに改善を行っていくのがいいと思います。改善を行うメンバーも疲弊しませんし、エンジニアリング組織のメンバーも振り回されなくなります。
上記の考え方は 「スクラム」 とほとんど同じだと後々気付きました。（スクラムという言葉とニュアンスは知っていましたが、根本を理解していませんでした。）
エンジニアリング組織における開発においては不確実性（開発物、開発状態）が高いため、実際の失敗などの経験から学びを得て、改善してくのを繰り返していくとが重要になります。以下スクラムガイドでのスクラムの定義になります。
スクラムとは、経験的プロセス制御理論（経験主義）を基本にしている。経験主義とは、実際経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスク管理を行う。
スクラムガイドより
自分の意見としては、スクラムガイドをまるまるエンジニアリング組織に取り入れる必要はないと思いますが、問題が起きたときや始める前には見ておくと大変参考になると思います。現時点で、もっとスクラムを理解する必要があり、4ヶ月前に知っていればと思っています。
参考
スクラムが銀の弾丸なのでは？
先ほどの「銀の弾丸はない」ということと、スクラムを参考にした方がいいということが矛盾するのでは？っということについて
これについてもスクラムガイドに書いてある定義が参考になります。
スクラムは、1990年代初頭から複雑なプロダクト開発の管理に使用されてきたプロセスフレームワークである。プロダクトを構築するプロセスや技法ではなく、さまざまなプロセスや技法を取り入れることができるフレームワークである。
スクラムガイドより
このようにスクラムは、改善を繰り返すためのフレームワークになります。
エンジニアリング組織を作るエンジニアの重要性
エンジニアリング組織の開発効率の最大化を行い、責任を持っている人がチームにいることが重要だと思います。PMが行ってもいいと思いますが、役割が肥大化して見切れなくなってしまうので、内部のエンジニアや開発ディレクターやCTOのような人が行うのがいいと思います。
チームによっては、Outcome(成果 ex. PVや収益などのKPI)が重要視されますが、Output（開発物 ex. 新機能・機能改善）はなかなか見られていないと思います。もちろん事業なので、Outcomeを継続的に上げる必要があります。しかし、Outcomeを生むのはOutputであり、Outputはエンジニアリング組織から生み出されます。このエンジニアリング組織からのOutputを最大化することに責任を持っている人が、チームにいることが大切だと思います。
エンジニアリング組織からのOutputに責任を持つ人がいればOutputの質や量は上がり、結果的にOutcomeの向上に繋がります。Outcomeしか見ていないと、Outputの質と量を適切に保てず、Outcomeを安定的に出すことは難しくなると思います。
その他 - コンウェーの法則の応用
まず「コンウェーの法則」について
「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」 (原文: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.")
Wikipedia - メルヴィン・コンウェイ
MicroService化の文脈でよく聞いたことがあると思います。（システムを疎結合にすることで、組織のコミュニケーションも疎結合になり、開発をグロースさせることができるようになる。）このように組織とシステムは密接に結びついています。
エンジニアリング組織を立てつけるときに、使用する多くのツールがあると思います。これらの使用するツールの構成も、組織によって分離することで余計なコンフリクトがなくなり、開発に集中できると思いました。
- Slackの場合だと、窓をチームによって分離する
- ドキュメント管理ツールだと、ディレクトリーをチームごとに切る
システム周りだけでなく、目標や開発体制もチームによって分離することで、意思決定が早くなったりコミュニケーションが円滑になり開発につながると思います。
最後に
駆け出しエンジニアが駆け出し状態でエンジニアリング組織を作る中で感じたことになります。
まだまだ最高の状態のエンジニアリング組織はできておらず、終わりはないと思っています。
今後もチームのエンジニアが少しでも開発しやすい状態を作って、Outputを増加させて、組織に貢献していきたいです。