はじめに

こんにちは、QA Leadのうへのです。

突然ですが、SHIFTはInfoQ Japanの運営をしていることをご存知でしょうか。 InfoQは技術者のための鮮度の高い情報を投稿できるプラットフォームです。私たちは世界中のエンジニアがInfoQに日々投稿している鮮度の高い記事を日本語に翻訳し、InfoQ Japanのサイトに掲載しています。

今日は、DevOpsの未来について考察されているInfoQの記事、"What’s Next in DevOps?"（リンク先：英語版・原文）をご紹介するとともに、私が考えたことを書いてみたいと思います。

※以下、英語版記事（原文）を日本語版の翻訳を手掛ける筆者（うへの）が和訳したものをベースに要点を解説していきます。

What's Next in DevOps?

この記事では、昨今のITの現場をDevOpsの文脈から読み解き、今後について示唆をしています。

※なお、ソフトウェア開発やDevOpsの経験者向けに書かれているため、専門用語も多くなっています。ご了承ください。

プロジェクトからプロダクトへ

DX（デジタルトランスフォーメーション）が広く知られるようになって久しいですが、これは一過性の活動と認識すべきでないと著者は指摘します。なぜなら、プロダクトを一回作って終わりにするプロジェクトではなく、プロダクト（社内システムも含まれると考えられます）に焦点を当てることの利点は非常に大きいからです。

プロダクトチームは、エンドユーザーからの継続的なフィードバックを得ることで、プロダクトを長期にわたり改善することができます。そのためのIT基盤を整えることは、継続的な改善をエンドユーザーが気付かないほど俊敏に行うためには必要性が増してくるでしょう。チームの在り方も当然異なってきます。プロジェクトチームのようにプロダクトがいったん完成を見たら解散するのではなく、プロダクトが死ぬまで進化をつづけられるように、チームも存続することになるのです。

また、そのためのIT投資はコストではなく投資と捉えるべきであり、予算の考え方も再考する必要があります。
これらはすでに多くの企業が気付いていることだと思いますが、この傾向は今後ますます加速するでしょう。

チームトポロジー

プロダクトチームを安定的に運営していく上では、コミュニケーション、信頼、チームワークを引き出す構造が重要であることは知られている通りです。マシュー・スケルトンとマニュエル・パイスの著書『チーム・トポロジー』のなかでも、アーキテクチャ構造は組織の構造に従うことを指摘したコンウェイの法則、そして逆もまた然りであるとする逆コンウェイの法則が紹介されています。これらは、経験的にもそうですが、DevOps Research and Assessmentのようなチームの研究によっても実証されています。

チームトポロジーの考え方を活用してチームの規模、構造、責任範囲や権限を決定し、長期にわたってベロシティを維持することができるでしょう。

ツール

DevOpsのプラクティスを促進する製品が次々に出てきていることもDevOpsを後押しする要因になっています。A/Bテストやカナリアデプロイメントのリスクを軽減し、気軽に実験をできるようにするツール群や、新しくはないが不可欠なインフラサービスは変わらず活用されつづけていくでしょう。

データサイエンス

データサイエンスはA/Bテストのような実験的なプラクティスの効果を定量化するために利用されています。

筆者は、現在こういったデータはマーケティング部門が主導していることが多いが、アプリケーションを作成したチームがプロダクトの効果を見るために活用されていくようになると予想しています。

リーンとアジャイル

DevOpsはアジャイルの現実化を目的としているため、技術力の確保、プロセスの簡略化、最適化、仕組化、改善の観点をDevOpsから欠かすことはできません。

プロセスを視覚化するツールは、無駄を省き、アジリティを高く保ちたいチームにとって、意思決定者からそのための予算を獲得したいときに有効な手段の一つになりうるでしょう。

システムインテグレーター

最後に筆者はシステムインテグレーターの未来についても言及しています。

今のDevOpsに対応できる人材の供給能力が需要を上回っているため、システムインテグレーターはチームの立ち上がりをテクノロジーとプロセスの実装で支援しつづけると予想しています。社内に人材がいない場合に、イネーブラー（※）としてコンサルタントに支援してもらうことも強力な手段の一つであると述べています。

とはいえ、テストやデプロイのような特定の機能、もしくは開発プロセス全体をアウトソーシングすることに対して警鐘を鳴らしています。なぜなら、すべての利害関係者を共通の情報と共有された目標でまとめることに重点を置くDevOpsの精神に反するからです。また、特定のアプリケーションの構築が終わった後、そのシステムインテグレーターがプロジェクトからいなくなってしまうのであれば、プロダクトの継続的な改善を行っていく上で大きなリスクになりえます。

上記を踏まえ、第三者が組織にどこまでかかわるかは注意深く設計する必要があるでしょう。

（※）ここでいうイネーブラーは、前出の『チームトポロジー』における「イネーブリングチーム」の一員であると私は解釈しました。イネーブリングチームとは、「特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける」と説明されています。

以上、記事の内容を簡単にご紹介しました。

DevOpsのチームに対する理想の支援とは？

ここからは、記事の内容を踏まえて考えたことを書いてみたいと思います。

SHIFTはこれまでDXに取り組む企業を数多く支援してきました。 プロダクトを継続的に改善するという考え方が普及してきている中で、従来の開発のようにプロダクト企業が要件定義を行い、システムインテグレーターに開発やテストを一括請負をするスタイルではなく、プロダクト企業とシステムインテグレーターが協働して開発を進めたり、プロダクト企業が内製化を進めたりすることがあります。

記事の中では、コンサルタントやシステムインテグレーターのような第三者がどこまで組織にかかわるのかは注意深く設計しなければならないとの主張がありました。どちらかというと筆者はプロダクトチームに第三者が介入することに否定的なように見えます。確かに、テストやデプロイメントの機能をごっそり誰かほかの人に任せてしまうことが危険なことはよくわかります。チームがコントロールできない変数が一つ増えることになるからです。あくまで主役はプロダクト企業のチームであり、支援の目標はチームが自走できるようになることです。支援期間が終わったあと、そのチームに運用可能なテスト資産なりCI/CDパイプラインなりナレッジなりを残すことができなければ、その支援は失敗なのです。

私が経験してきた案件では、支援の仕方は大きく分けて2つありました。一つ目は、プロダクト企業のアジャイルチームに参加させていただきながらQA活動を行うケース。もう一つは、開発の主体はプロダクト企業の内製チームが担い、私たちは第三者的にプロセスを支援したりガイドを提供したりするケースです。どちらの場合でも、最終目標はチームが自走できることなので、組織の壁を気にしたり、必要な情報を引き出せなかったり、課題をとらえられなかったり、スキルを移転する仕組みを作れなかったりすると、うまくいきません。

QAやテストの活動が完全に切り出され、それらをSHIFTが担っている場合、支援先のチームにナレッジを移管することは非常に難しくなります。最低限テストコードを残したとしても、メンテナンスできる人がおらず、結局運用されなくなることもあるでしょう。そうではなくて、チームメンバーの一員として（週1回1時間などではなく！）参画しながらも、専門家としての顔を持って、現場からテストの価値を広めたり、プロセスの課題を見つけたり、改善の提案をしたり、専門知識を伝えたりすることができるはずです。現場で一緒の時間を過ごしながら、なりたかったDevOpsのチームを目指して自走できるようになるところまで支援するのが、私が考える理想の姿の一つです。

チームに第三者が入るということは、作業をアウトソーシングするためだけではないと私は思います。チームはどうしてもデリバリーを優先しがちになるので、新しいことを学んだり、自分たちの作業をよくしたりすることに時間を割けなくなることが多いでしょう。こうした状況のときに、コンサルタントやシステムインテグレーターが専門的な知識を以てチームを技術的に導いたり、その組織にはなかった新しいアイデアを持ち込んだりすることができれば、チームの活動を加速させる可能性すら秘めていると思います。実際、チーム外の企業や組織とこういった関係性を築いている内製化チームは、必要なタイミングで自分たちの外に支援を求め、さらにパワーアップしていくように見受けられます。作業のアウトソーシングは最終的に必要なくなるとしても、相談相手としての需要はなくならないのでしょう。

まとめ

アジャイルやDevOpsが普及して内製化が進んだとしても、専門的な知識を提供する第三者としてのシステムインテグレーターやコンサルタントの役割は終わらないと考えています。 それどころか、理想のDevOpsチームの姿を一緒に探しながらチームが自走できるようにするための、よき相談相手であることが求められているのではないかと思います。

興味のある方はオリジナル記事もぜひ合わせて読んでみてください。

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら

PHOTO：UnsplashのAlexander Grey