ITサプライヤは、プロダクト開発に実験的アプローチを採用して、小さなプロダクト増分を運用環境で検証するという、小規模バッチで作業することにより、"you build it, you run it"というマントラに従うことができる。サプライヤはクライアントの目標が何であるかを見つけなければならない、とKonstantin Diener氏は言う。コラボレーション開発を行うためには、それをサプライヤ自身の目標にしなくてはならないのだ。
coseeのCTOであるKonstantin Diener氏はDevOpsCon Berlin 2021で、外部ITプロバイダがDevOpsプラクティスを採用する方法について講演した。
企業が社外のITサプライヤと開発を行う場合、最も大きな課題となるのはゲームの参加者が2人ではなく3人であることだ、とDiener氏は例を挙げて説明する。
エンジン開発で成功しているある企業が、新たなディジタル製品を開発したいと考えています。この製品は、同社のユーザが自身のマシンを監視するためのものです。機械が停止すると多大な損害を被るので、マシンが故障した時には可能な限り早く通知が欲しいと思っています。故障する前に警告ができれば(いわゆる予知保全)、さらに好都合です。
そのエンジン開発会社がソフトウェアエンジニアを雇用していないものと仮定しましょう。そうなれば、ゲームの参加者はサプライヤ、クライアント、ユーザの3人です。監視プロダクトを開発するのはサプライヤですが、将来のある時点でクライアントのチームに引き渡され、以降はそのチームが運用することになります。
プロダクトを開発するのがサプライヤであっても、将来的にはクライアントによって運用されることが多い、とDiener氏は言う。すぐに引き渡してほしいというクライアントもいれば、プロダクトの運用と拡張を担当する自社チームを雇用するまで、何年も待つクライアントもいる。
Diener氏によれば、ITサプライヤでも"you build it, you run it"というマントラに従うことは可能だ。
大切なのはウォーターフォール的思考の克服です。現在のサプライヤは小さなバッチで作業し、プロダクト開発に実験的アプローチを使用しています。サプライヤのプロダクト開発チームは仮説を立て、理想的には運用環境で、小さなプロダクト増分によってそれを評価します。
私自身の経験から言えば、今日では、ITサプライヤの多くがアジャイルソフトウェア開発と継続的インテグレーション(CI)を使用しているのですが、運用開始を境に、その反復的アプローチをやめてしまうのです。
開発と運用が分離していることによる問題のひとつは、多くの場合において、この2つのサイロが違う目標(開発 = スループット、運用 = 安定性)を持っていることだ、とDiener氏は指摘する。DevOpsチームに共通のビジネス目標があるのとは対照的だ。
ITサプライヤでもDevOpsプラクティスを採用できる、とDiener氏は説明する。
サプライヤがDevOpsプラクティスを採用するためには、クライアントの目標を見付けなければなりません。それが同時に、サプライヤの目標にもなるのです。coseeではプロダクトビジョン・ワークショップを使って、クライアントの目標(影響)とそのユーザのニーズ(成果)を形成し、資料化しています。反復的かつ実験的なアプローチにおいては、これが前提条件なのです。
DevOpsのムーブメントはサイロを崩し、旧態依然とした引き継ぎ("フェンス越しの投げ込み"とも言われる)を回避するためのムーブメントである。クライアントは、協調的な開発を行う意思と十分なスキルを備えた、適切なサプライヤを選択しなければならない。
ITサプライヤからのDevOpsプラクティスの採用について、Konstantin Diener氏にインタビューした。
InfoQ: サプライヤは、クライアントとの依存関係をどう扱えばよいのでしょうか？
Konstantin Diener: とてもよい質問ですね。完全な新規開発プロダクトであっても、外部に何らかの依存関係を持っているのが普通です。ユーザインターフェースを外部のエージェンシがデザインするかも知れませんし、クライアントの法務部門が情報保護に関するトピックを扱うかも知れません。こうした状況は、サイロの再現につながることも少なくありません。
このようなサイロを回避するには、DevOpsコラボレーションモデルを使うとよいでしょう。まず最初に、これらの専門家(デザイナや法律家)を、自分たちのクロスファンクショナルなチームに取り込むことを考えてください。これはクラシックなアジャイル手法です。価値のあるプロダクト増分を提供する上で不足する部分があるのならば、欠けている専門知識をチームに付け加えましょう。
ジョブローテーションや日々のスタンドアップへの参加、ペアリングなどの方法で、専門家たちと協業するという方法もあります。Matthew Skelton氏とManuel Paris氏の共著である"Team Topologies"には、他にもたくさんのパターンが紹介されています。プロダクトないしその増分を定期的にクライアントの運用チームに提供しているのならば、"Production Readiness Reviews"(PRR)などのSRE本に説明されている、Googleのパターンをいくつか試してみてもよいでしょう。この場合、クライアントの運用チームはSREチームのようにふるまって、事前に定義されていたPRRチェックリストに基づいて、プロダクトの運用可能性をチェックすることになります。
InfoQ: ITサプライヤがDevOpsプラクティスを採用することは可能なのでしょうか？
Diener: もちろん可能です。前提条件のひとつは、現代的なソフトウェア開発プラクティスです。このトピックに関しては、Nicole Forsgren、Jez Humble、Gene Kim各氏の"Accelerate"がお勧めの書籍です。小さなバッチで開発するためには、トランクベースの開発、極めて頻繁なブランチ、テストのための強固な基盤といった、本物の継続的インテグレーションを実践しなければなりません。
さらにサプライヤとして、アプリケーションを常にリリース可能な状態に維持する必要もあります。すぐに使用可能なプロダクトのインスタンスを新たにセットアップしたい、とクライアントが言えば、所定のリポジトリからチェックアウトして、ビルドとデプロイメントのパイプラインを実行するだけで可能でなければなりません。アプリケーションを運用環境か、あるいは少なくともそれに近い環境で実行することで、独自のメトリクスに基いたプロダクトの機能やインフラストラクチャの成長が実現します。
InfoQ: サプライヤからクライアントへの引き渡しに対して、DevOpsをどのように適用することができるのでしょうか？
Diener: サプライヤの立場からは、3日間のワークショップでプロダクトをクライアントに引き渡すようなことはしないでください。それでは撃ちっ放し(fire and forget)です。私たちcoseeは、上述した2つのコラボレーションモデルを使って、クライアントの従業員にプロダクトを引き渡しています。これらの人々を私たちのクロスファンクショナルなチームに迎え入れて"プロダクト開発の最後の一歩を共に進む"か、別のチームに留まったままでペアリングやジョブローテーションといった方法でコラボレーションするか、いずれかの方法を採用しているのですが、どちらのアプローチも数週間ないし数か月が必要で、3日で終わるようなものではありません。
InfoQ: 非難のない事後分析(blameless postmortems)には、どのようなメリットがあるのでしょう？サプライヤとクライアントが一緒に開発を行うには、何が必要なのでしょうか？
Diener: DevOpsのムーブメントには、"共有は思いやり(haring is caring)"という重要なマントラがあります。第1に、クライアントと非難のない事後分析を行い、その結果を共有することで、信頼を構築することが可能です。第2に、将来的にクライアントのチームがプロダクトを運用するのであれば、そのプロダクトの歴史、特に過去における失敗について詳しく知っておくことが重要です。