🎯

小さなチームでのDevOps

2022/09/10に公開

はじめに

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

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

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

DevOpsとは

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

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

1. フローの原則

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

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

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

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

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

小さなチームでのDevOpsとは

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

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

Pros:

「全員が同じミッションを持つ」 開発担当と運用担当の対立がない。
「フィードバックループを短縮しやすい」 シンプルなチーム構造なのでコミュニケーションパスが物理的に短いです。直接的なコミュニケーションがしやすい
「フロー効率」 基本的に１チームですべてのシステム開発ライフサイクルを回せます。タスクマネジメントの際に考慮が必要な外部要因は少ないです。いわゆる「待ち状態、相手ボール」のようなもの
「情報と権限の集約」 チームにはDevとOpsに関わる全ての情報が集約され、蓄積されていきます。DevとOpsに必要なすべての権限を持っています。

Cons:

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

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

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

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

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

コードの品質には運用性も含まれています。運用面で課題のあるシステムを素早くリリースしても、それは近いうちに致命的に遅くなります。テストや監視を始め運用観点の仕組みや知見はスケール性の良いガードレールとなり、開発者はより安心して開発に集中できるようになります、それが継続できるようになります。
開発を急いでるときに削るべきはシステムの運用性ではなくタスクのスコープです。

まとめ

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

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