しかし本稿のケースは違う。ここで取り上げるのは、保守・運用が、開発とは分離された構造を持つ組織だ。この体制における課題を明らかにし、そのうえで解決策を探ってみたい。
- 事象は開発と保守・運用の分離が上手く機能していないこと
- 問題は開発が保守・運用を阻害すること
- 課題は個別ミッション遂行におけるコンフリクトを解消すること
- 対策は共通ミッションに立ち戻ること
- 結論は両チームをあえて密結合にすること
- 追記
- 関連記事
事象は開発と保守・運用の分離が上手く機能していないこと
実は、先日登壇させていただいたオンラインカンファレンスにて、保守・運用の分離に関して質問を受けたのだ。それを深掘りしようというのが、本稿の動機であり、趣旨である。
具体的にどういった質問を受けたのか、そのテキストが手元にないため記憶に頼ることになるが、概ね次のようなものであったと思う。
- 組織は、開発と保守に分かれている
- 開発が速くなっている
- どうすれば良い関係を築けるか
その場では、想定する前提に基づいて少々抽象度の高い回答になった。ZoomのQ&A機能を使った短いテキスト文での質問であったため、前提に不明な点が多かったことと、回答時間が1分ほどしかなかったからだ。その時は、「開発が速くなっている」という点を「良いこと」と受け止めて答えたのであるが、あとから考えると、それは、保守チームにとって「困りごと」だったのかもしれない。
色々と想像で補うしかないが、とりあえず検討を進めてみようと思う。
ここでは便宜上、保守チームの責務に運用も含まれている前提とする。誤解を招かないよう、保守・運用チームと呼ぶことにした方が良さそうだ。ただし、運用と言っても、ソフトウェアシステムをマネージドなインフラ/プラットフォーム上で本番稼働させている想定だ。また、扱うソフトウェアシステムも、自社プロダクトであるものとする。
問題は開発が保守・運用を阻害すること
まず、開発が速くなった理由であるが、これはちょっと分からない。様々な可能性があるからだ。
「開発が速い」という表現は、開発のリードタイムが短く、リリース頻度が高い状態を表しているのだと考えられる。その頻度が、保守・運用チームの負荷になっていたり、ソフトウェアシステムの信頼性に悪影響を与えているのではないか。そして、保守・運用上におけるこのような状況が続いていることについて、チーム間で建設的に話し合えておらず、問題を取り除くことができないままにあるのではないか。
リリース頻度が高まると、2つの面で、保守・運用業務の負荷が高まりやすくなる。
1つは、引き継ぎが困難になることだ。ソフトウェアシステムに加えられた変更点が何であるか、リリースの度に開発チームから保守・運用チームへの引き継ぎが発生する。この頻度が高いと、保守・運用チームにとってはつらい。
また、あまりにその頻度が高まると、開発チームにとっても引き継ぎ準備がオーバーヘッドとなる。高頻度なリリースの足かせだと感じ始めるのだ。すると、まともな引き継ぎなど行われなくなる。保守・運用チームは、引き継ぎのないまま保守を続けることになるだろう。そもそも、早期のリリースと引き換えに、ソフトウェアの内部品質を犠牲にしている可能性も高い。それが長く続くと、担当するソフトウェアシステムが、保守・運用チームにとって得体のしれないものになっていく。この状況で安定した保守を継続するというのは、なかなかにハードだ。
もう1つは、バグフィックスや緊急対応に追われるようになることだ。バグトラッカーには、リリースする度に、未対応のままの軽微なバグが積まれていく。その増加スピードがあまりに速いと、保守・運用チームの負荷は高まる。それに加え、リリース前に検出されなかったバグが本番環境でトラブルを引き起こし、その緊急対応や、その後の是正対応に追われることもある。リリース頻度が高まれば、こういった対応も増えるかもしれない。
開発チームと保守・運用チームが分離したままであっても、この状況を何とか改善する術はないか。それが、質問者の言いたいことだったのではないだろうか。
課題は個別ミッション遂行におけるコンフリクトを解消すること
この状況はコンフリクトだ。開発チームは、リリース頻度を高めたい。保守・運用チームは、リリース頻度が高すぎることを問題視している。典型的な、devとopsの対立である（保守をopsに含めて良いのかわからないが）。
開発チームは、優れた機能をユーザーに届けるために、開発のリードタイムを縮め、リリース頻度を高めようとする。リードタイムが短ければ、それだけビジネスにも好影響を及ぼす。たとえば1か月で100万円の利益が見込める機能を1か月早くリリースできたなら、利益を100万円多く得られる。もちろん、リリースしたからといって、新機能が思惑どおりの価値を生み出すとは限らない。しかし、リリース頻度が高まれば、それだけフィードバックサイクルが速くなり、新機能をより価値のあるものに近づけやすくなる。
一方の保守・運用チームは、信頼性の高いサービスを提供するために、プロダクト品質やサービスレベルを高めたり、安定させることに努める。品質やサービスレベルが下がると、ユーザーの不満足につながってしまう。だから、それらを日々、監視し、メンテナンスし、守り続けるのが彼らの責務だ。それだけに、プロダクトに変更を加えられるのは、品質やサービスレベルの安定性を崩す要因になりかねない。リリースに対して慎重にならざるを得ないのだ。
このように、チーム間での利害が相反するため、解決は難しいようにも思えるが、本当にそうだろうか。
開発チームであろうが、保守・運用チームであろうが、彼らには共通のミッションがある。それは、プロダクトのユーザー価値を高めて優れたユーザー体験を提供することと、その実現を通してビジネス面で大きな成果を得ることだ。そのミッションを支える戦術の1つが、開発チームの責務である「優れた機能をユーザーに届ける」というミッションであり、また、保守・運用チームの責務である「信頼性の高いサービスを提供する」というミッションだ。
分業によって生じやすい弊害として、各チームが互いに共通のミッションを見ずに、それぞれのチームに割り当てられた個別ミッションの範囲内で活動や思考が閉じてしまう点がある。いわゆる部分最適である。そうすると、チーム間でのコンフリクトが起き始める。この組織の開発チームと保守・運用チームは、この状態に陥っていると考えられる。
したがって、各チームが共通のミッションに立ち戻り、それを踏まえた上で個別のミッションを遂行できれば、コンフリクトを解消・軽減できるはずだ。
対策は共通ミッションに立ち戻ること
チーム間でコンフリクトしている対象が、実はそれぞれの個別ミッションの遂行手段である点に注目すべきだろう。1つしかない共通のミッションがコンフリクトするわけはないし、それぞれの個別ミッションもコンフリクトしない。あくまでも、それらを「どう遂行するか」がコンフリクトしているのだ。これは、自チームのミッションの範囲内だけで遂行手段を考えてしまうからだろう。したがって、それぞれのミッション遂行手段を両チームで話し合って決めれば良いのではないかという考えに行き着く。
たとえば、未解決のバグの数に上限を設けるというルールを設けてはどうだろうか。必ずしもすべてのバグを解決しなければならないわけではないが、解決するバグの数より、リリースの度に追加されるバグの数の方が多いようであれば問題である。それならば、バグの数が上限を超えたら、それらを収束させるまでリリースをストップするのだ。その間、開発チームと保守・運用チームが協力して、バグの解決に取り組む。バグの数でエラーバジェットを設けるようなイメージだ。
この方法の良いところは、バグ増加の抑止力にもなる点だ。リリースを止めたくなければ、開発チームは品質を担保しなければならなくなる。そのために開発速度が多少下がる可能性もあるが、優れた機能をユーザーに提供することも、信頼性の高いサービスを提供することも両立させることができる可能性が高まる。本番稼働後のトラブルの数にエラーバジェットを設けることだってできる。
他にもやり方は考えられる。
たとえば、コード内のコメントや、適切なドキュメントなどが未整備な状態が続いているなら、開発プロセスに、保守・運用チームが関わるのも手だろう。開発チームと協力し、開発を進める中で、並行して、保守・運用チームが必要最小限のドキュメントを整備していく。そのために、保守・運用チームが設計に関わるのも良いだろう。
また、保守・運用メンバーがコードレビューを担当し、変更されたコードを理解しつつ、コメントの不備などを指摘する。ここで、必要なログが出力されていない箇所があれば、それもあわせて指摘しても良いだろう。システム運用には重要なことだ。もっと踏み込んで、開発メンバーと保守・運用メンバーでペアプロをやってみるのも良いだろう。
さらに、開発チーム、保守・運用チームが、互いの課題について共有し合う場を定期的に設けるのも手だ。相互にフィードバックし合うわけだ。そうすることで、開発・保守・運用いずれに対しても改善が進む。
まあ、前提条件や制限事項がない状態での空想なので、これらの対策の実現性やその効果がどれだけであるかは定かではない……
いずれにしても、要は、全体最適になるよう各チームの行動を設計するということだ。チームの個別ミッションだけで思考を閉じてはいけないのだ。開発チームと保守・運用チームで、同じ目標を追いかけてみるのも良いだろう。
結論は両チームをあえて密結合にすること
はっきり言って、例として挙げた対策を実行すると、開発チームと保守・運用チームとの間で、コミュニケーションコストが増大するかもしれない。それが、かえって業務負荷につながる可能性もある。チームの境界を越えるコミュニケーションパスは、少なく、細い方が良いと私は考えている。それは、そういったパスが増えたり太くなるほど、チームの独立性を阻害する要因となるからだ。チーム単独で、業務を計画・遂行できなくなって、リードタイムに悪影響を及ぼすということだ。
ただ今回は、1つのプロダクトに対し、開発と保守・運用でチームを分けてしまっている。それ故、共通の担当プロダクトが結合点となり、両チームを縛る要因になる。チーム境界を越えるコミュニケーション量が増えるのはこのためであり、必然なのだ。
したがって、この組織構造においては、チーム間が疎結合である方がおかしいのだ。積極的にコミュニケーションを取り、協働するのが、開発と保守・運用が分離された組織でのあり方ではないだろうか。
追記
本稿を書き終えてから、質問文を入手できた。それが以下だ。
開発チームで開発したシステムを、開発するたびに保守、運用チームに保守・運用をすべて任せることで、次々と開発スピードが早くなります。早い開発をしたい場合、互いのチームの良い関係性はありますか？
あらためて読んでみて、質問者は開発チームメンバーなのかもしれないとも感じた。開発スピードを速くすることで、両チームの関係性が崩れる。そうならないようにする、あるいはそれを改善するにはどうすれば良いか。そういったところだろうか。
