🎯

小さなチームでのDevOps

2022/09/10に公開約3,700字

はじめに

これは"小さなチーム"でDevOpsを実践する際のアイデアのポストです。
DevOpsとは、運用の知識を開発に取り入れるマインドセットであり、またそのためのプロセスやアプローチを指します。"小さなチーム"というのは開発担当と運用担当とが分かれていないようなチームを指します。

DevOpsというとよく言及されるのは開発担当と運用担当のIntegrationの話だったり、DevOps専任チームの話や、DevOpsツールに言及するものが多いかと思うのですが、今回は開発担当と運用担当とが分かれていないような"小さなチームにおけるDevOps"についての話となります。表面的な事象の裏側にある構造上の特性を考えてみます。

"小さなチームでのDevOps"の場合には、DevとOpsの2つのミッションが1つのチームに集約統合(Consolidation)されています。全員が同じミッションを持ち、フィードバックループを短縮しやすくフロー効率を高めやすい一方、様々な意思決定の際に"Dev > Opsバイアス"やチーム内のコンテキストの複雑化、チーム内でのサイロ化、属人化などの問題に注意が必要かもしれません。

DevOpsとは

DevOpsとは運用の知識を開発に取り入れるマインドセットであり、そのためのプロセスやアプローチを指します。

DevOpsの根底には3つの原則があります。

1. フローの原則

特定のサイロ化した作業や部門のパフォーマンスよりも、システム全体のパフォーマンスを重視します。この部門は、開発部門やIT運用部門といった大きなものから、開発者、システム管理者といった個人の貢献者といった小さなものまでさまざまです。

2. フィードバックの原則

DevからOpsへの一方通行の矢印ではなく、OpsからDevへのフィードバックループを作成します。またそのフィードバックループを短縮および増幅させることを目指します。

3. 継続的な改善と実験の原則

先の2つを育む文化を作ることです。継続的な実験、リスクを冒すこと、失敗から学ぶことです。反復と練習が習得の前提条件であることを理解します。

小さなチームでのDevOpsとは

ここでの"小さなチーム"とは、開発担当と運用担当とが分かれていない編成のチームを指します。
"小さなチーム"と対照的なものとして"大きなチーム"とは、開発担当と運用担当とが分かれているチーム、もしくはDevOps専任チーム、SREチームが別に存在するチームを指します。

小さなチームでDevOpsを実践する場合、1つのチームにDevとOpsの2つのミッションが集約されています。
そのような"小さなチームでDevOps"を行うとなると、大きなチームの場合と比較し次のようなPros/Consがあると考えます。

Pros:

  • 「全員が同じミッションを持つ」 開発担当と運用担当の対立がない。
  • 「フィードバックループを短縮しやすい」 シンプルなチーム構造なのでコミュニケーションパスが物理的に短いです。直接的なコミュニケーション。
  • 「フロー効率」 基本的に1チームですべてのシステム開発ライフサイクルを回せます
  • 「情報と権限の集約」 チームにはDevとOpsに関わる全ての情報が集約され、蓄積されていきます。DevとOpsに関わるすべての権限を持っています。データを活用した意思決定のしやすさ

Cons:

  • 「開発者、チームには開発と運用の両方にわたる幅広いスキルセットが必要」
  • 「開発 > 運用のバイアスその1/市場からのプレッシャー」 運用が開発と並ぶ重要なミッションとされにくい。また開発者は元来、新しい事業価値の創出(Dev)に夢中です。
  • 「開発 > 運用のバイアスその2/開発者の知識はDevに寄っている」 知識の偏りによって、限定合理性な判断をしてしまいやすい問題。知識があるDevの課題にはすぐ気づけるが、知識の少ないOpsの課題にはなかなか気づけない、仮に課題と認識できたとしても改善のアイデアを持ち合わせていなければ現状がベストなんだと受け入れてしまいます。もちろん、その逆の"Ops > Dev"に知識が偏っていることによる認知バイアスもありえます。
  • 「複雑化するコンテキスト」 小さなチームはシステム開発ライフサイクルすべてを委任されており多種多様なタスクを抱えています。そのため同じチームの開発者と言っても専門性には違いがあり、各自が抱えているタスク、置かれている状況、知っていること知らないことに違いがあります。情報の非対称性があります。DevとOpsが1つのチームに集約したことで運用担当との対立はなくなりますが、今度は開発者間の対立が起こるかもしれません。コミュニケーションの際にはお互いのコンテキストを合わせることが重要です。
  • 「属人化、チーム内でサイロ化/孤立化」 小さなチームでは個人の責務、裁量が増えやすく、注意しないとあっという間に属人化されたタスクが生まれやすいです。

運用がわかると開発がしやすくなる

Consの一つに 「開発者、チームには開発と運用の両方にわたる幅広いスキルセットが必要」 と挙げましたが、そこを乗り越えると明るい話もあります。開発者は自身で開発したシステムを自ら保守運用することで運用の知識経験を積み重ねます。そうして運用がわかるようになると同時に開発もしやすくなります。ゴールまでの道筋を柔軟に描けるようになり、ゴールまでのプロセスやアプローチが変わり、よりスムーズにより確実に目標達成できるようになります。自然とアジャイル開発手法を取り入れ、気にいると思います。

「運用がわかると開発がしやすくなる」というのはその逆も然りで、「運用がわからないと開発が難しい」ということでもあります。
twadaさん「質とスピード」を引用すると、、、

コードの品質を高く保っていた「にも関わらず」早いのではない。コードの品質を高く保っていた「からこそ」早いのだ。
~ David Scott Bernstein

コードの品質には運用性も含まれています。運用面で課題のあるシステムを素早くリリースしても、それは近いうちに致命的に遅くなります。開発を急いでるときに削るべきはシステムの運用性ではなくタスクのスコープです。

まとめ

今回は開発担当と運用担当とが分かれていないような"小さなチームにおけるDevOps"について、表面的な事象の裏側にある構造上の特性を考えてみました。

繰り返しになりますが、"小さなチームでのDevOps"の場合には、DevとOpsの2つのミッションが1つのチームに集約統合されています。全員が同じミッションを持ち、フィードバックループを短縮しやすくフロー効率を高めやすい一方、様々な意思決定の際に"Dev > Opsバイアス"があり、チーム内のコンテキストの複雑化、チーム内でのサイロ化、属人化などの問題に注意が必要かもしれません。


https://b.hatena.ne.jp/entry/s/zenn.dev/karahiyo/articles/f2acc23e77a52c

参考:

https://circleci.com/ja/blog/devops-did-not-exist/
https://itrevolution.com/the-three-ways-principles-underpinning-devops/
https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition

Discussion

ログインするとコメントできます