DevOps Topologiesから考える開発チームとスケールの注意点 # 小規模フェーズ（〜10人）
皆様、こんにちは！オプティマインドの深谷です！
今年の1月よりDevOpsチームの新たに立ち上げることとなり、SREやチームのコラボレーションなどについて学びの多い毎日を過ごしております。
今回はDevOps Topologiesの側面から、今までエンジニア組織の変遷を振り返ってみようと思います。
皆様の組織やチームの改善や学びにお役立ていただければ幸いです！
はじめに
対象読者
エンジニア組織の構築について興味がある方
TeamTopologiesやDevOps Topologiesに関する他者の解釈を知りたい方
まだまだ小規模なTech系のスタートアップで、今後の組織やチームをどうスケールしていくかについて悩んでいる方
この記事に書いてあること
小規模フェーズ（~10名）でのチームでの経験談
その経験に関連するDevOps TopologiesのAnti-Typeの紹介
1. この記事を書こうと思ったきっかけ
社内の勉強会の一環で、エンジニア組織に興味があるメンバーにてチームトポロジーを勉強するために『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』の輪読会をしております。
各メンバーの視点からの解釈や理解について話し合うことで、自分の視点からは気付けなかった事に気付くことができ、組織について理解を深める非常に良い場になっています。
すこし話が変わりますが、今期から設けられた成長支援予算の制度のおかげで、書籍やオンラインコースなどを気軽に購入でき、他のメンバーと共にスキルアップの機会を設けやすく非常に感謝しております。
そんな輪読会中に、DevOps Topologiesの話で盛り上がったので、せっかくなら今までの組織の変遷とともに、自分の考えをまとめてみようと思い、noteという形でアウトプットすることにしました。
本記事では、弊社の立ち上げ期（~10名）ぐらいのころについて振り返りながら、DevOps Topologiesで記載されているAnti-Typeなどについて触れていきたいと思います。
2. 小規模フェーズでのDevOps Topologies
小規模フェーズでのチームの特性と注意点
チームが数名程度である小規模なフェーズでは、ワンチームとなってユーザーの声を聞き、日々開発していくことになると思います。この規模ではチームとサービスが１対１の関係であるため、サービスに対して各自にオーナーシップが生まれやすいはずです。そのため、ユーザーのフィードバックをいち早くサービスに反映するために、自然とチームとしてどうしていくべきか日々ディスカッションが発生し、これ以降の規模と比較するとアジリティ高く開発が進めやすいと思います。
私達も同じ部屋、同じテーブルにみんなで集まり、自分の担当する技術の枠を超えてサービスについてのディスカッションをよく実施していました。
このフェーズの注意点として、チームの規模がまだまだ小さいが故に、開発環境や運用面を改善するようなDevOpsを意識したタスクにリソースを割き辛く、一時的に手動で実施する選択をしやすいことです。幸いなことに、サービスが小規模なうちは、それらの作業も大きな負荷に成り辛く、結果として『今の体制をベストエフォートで続けながら、早くそこを解決できる人材を獲得しよう！』となりがちです。
私達もまさにこのような状況になり、インフラエンジニアやSREの募集を出し、早くこれらの課題に取り組めるようにならないかと待ち望んでいました。
しかし、この状態は下記の2つのAnti-Typeになるリスクを有した状態であり、私達はまさにこのAnti-Typeを歩んでしまいました。
1. ユーザー重視によるOpsタスクの軽視（Anti-Type F ）
Anti-Type F: Ops Embedded in Dev Team
The organization does not want to keep a separate Ops team, so development teams take responsibility for infrastructure, managing environments, monitoring, etc. However, doing so in a project or product-driven way means those items are subject to resource constraints and re-prioritizations which lead to subpar approaches and half-baked solutions.
今振り返るとこの時期は『Anti-Type F: Ops Embedded in Dev Team』の状態でした。せっかくDevOpsを一貫して行えるチームでありながら、様々な意思決定を『ユーザーを第一に考える』と言うキーワードで判断してしまい、すぐに効果の見え辛いOps関連のタスクは後回しになりやすい雰囲気になっていたからです。
これらのタスクが将来的に自分たちの助けになり、最終的にはユーザへの価値につながるということがわかっていたとしても、そのタスクを今やるべきかを正しく評価するのは非常に難しいです。そんなときに、ユーザーが確実に喜んでくれるタスクが目の前にあれば、そちらを選択してしまう気持ちは痛いほどわかります。実際に、私もこのような意思決定を多く行ってきましたし、改めてこの時に戻っても、そうではない意思決定をできる自信はありません。
私達の反省点として、『リソースの数割程度は、DevOpsなどの機能開発以外のタスクをしても良い』というルールでこの状態を回避しようとしたことでした。
このルールの一番の失敗は”しても良い”としたことでした。当然、全員のタスクの考え方の観点がそこになく、DevOpsに関するノウハウや経験もない状態では、このルールはほとんど機能しませんでした。
今思えば、『リソースの数割程度は、機能開発以外のタスクやその勉強をしなければならない』のような強制的に全員が意識するルールにし、それについてディスカッションの場が生まれるような状態を目指していれば、自然とDevOpsを意識して行動する文化が根付いたかもしれません。
2. 無意識に生まれる独立したOpsチーム（Anti-Type E ）
Anti-Type E: Rebranded SysAdmin
This anti-type is typical in organizations with low engineering maturity. They want to improve their practices and reduce costs, yet they fail to see IT as a core driver of the business. Because industry successes with DevOps are now evident, they want to "do DevOps" as well. Unfortunately, instead of reflecting on the gaps in the current structure and relationships, they take the elusive path of hiring "DevOps engineers" for their Ops team(s).
この状態を回避するために、運用の経験のある人材を急いで獲得すると『Anti-Type E: Rebranded SysAdmin』のような運用周りのタスクを専任してこなすポジションになってしまう可能性があります。
このような人材が獲得できると、開発チームにとっては『今までできなかったタスクをこなしてくれる素晴らしい人材が増えた！』と歓喜し、チームとしていい方向に向かっているように感じます。実際私達もそのように感じ、これからの開発や運用がより良くなっていくと確信していました。
しかし、この感覚のままタスクをお願いしていると、その人がOpsのタスクをやることが当たり前となり、いつの間にかチームからOpsを考える習慣が欠落していきます。
私達の場合では、自分たちが運用するために監視ツールの導入をお願いしていたはずが、いつの間にかそれを活用した監視業務までその人のタスクになり、自分たちがそのツールをどう使って運用するのかわからない状態になっていたのです。
結果として、共にサービスを運用していくような一体感が希薄になり、ワンチームでDevOpsをしたかったはずのチームが、DevとOpsチームが独立した別のチームのようになりかけてしまいました。
このときの反省点として、『（物理的に）Opsできるようにすること』をゴールにしてタスクをお願するべきではなかったということです。
そうではなく、そのタスクのゴールを『チームがOps出来ている状態』とし、そのためのHowを全員でレビューした上でタスクにしていれば、自ずとそのタスクを終えた後の状況は変わっていたと思います。
3. 最後に
最後まで読んでくださった方ありがとうございました！
もし機会があれば、小規模から中規模になり、１チームが複数のチームに分割されていく場合についても記載したいと思います。
株式会社オプティマインドでは、一緒に働く仲間を大募集中です。
カジュアル面談も大歓迎ですので、気軽にお声がけください。
エンジニア領域の募集職種
●ソフトウェアエンジニア
●QAエンジニア
●Androidアプリエンジニア
●組合せ最適化アルゴリズムエンジニア
●経路探索アルゴリズムエンジニア
●バックエンドエンジニア
●インフラエンジニア
●UXUIデザイナー
ビジネス領域の募集職種
●セールスコンサルタント
●採用・人事
『オプティマインドってどんな会社？』については、こちらから
Wantedlyでもこちらで募集中