Robert Scherrer氏に聞く - スイス金融センタのバックボーン上のDevOps

InfoQで以前に報告したように、Robert Scherrer氏は、DevOps Enterprise Summit Londonの参加者に、SIXでDevOpsを導入した方法を公開した。少人数のコアチームによる開始、スキル・組織・プロセス・インフラストラクチャ・アーキテクチャの５つに価値観と思想を加えた5+1次元を中心とするDevOpsアプローチ — SIXは、ITとビジネスの協業のあり方として、それまでのサイロを破壊し、バリューストリームを実現する転換を着実に進めている。InfoQはScherrer氏に、この件について話を聞く機会を得た。

InfoQ: あなたの現在の役割について詳しく教えてください。

Robert Scherrer: 現在はSIXのソフトウェア部門を預かっています。SIXはスイスの金融市場インフラを運営し、証券取引、清算決済、財務情報や支払取引といった領域において、包括的サービスを世界規模で提供する組織です。

InfoQ: SIXではDevOpsをどのように始めたのでしょう？最初のステップは何で，それを選んだのはなぜですか？

Scherrer: ITマネジメントの戦略ワークショップで私が提案して、DevOps活動の開始を決定しました。次に、開発と運用の思想的リーダ、最初のプロジェクトに相応しいパイオニア、変革の対象として最初に考えていた製品、ミドルマネジメントの中でこの考えをサポートしてくれる代表者などについて考慮しながら、コアチームを慎重に人選しました。このコアチームとともに、私たちはビジョンと原則の定義に着手したのです。

InfoQ: SIXでは現在、どのようなDevOps活動を行なっているのですか？

Scherrer: 私たちはDevOpsの活動を、Hakaプロジェクトというひとつ屋根の下にまとめています。これ以外では、インフラストラクチャとツールのセットアップを行なっています。OpenShiftプラットフォームの整備、バリューストリームマッピングのワークショップのようなリーン思想の推進、アジャイル手法やクロスファンクショナルなコラボレーションのコーチなどです。これらによって、DevOpsの原則に従ったビジネスおよびライフサイクルプロジェクトの実践が可能になります。

InfoQ: 昨年は、内部的な指示に対抗することの重要性について話されていましたね。その理由となった外部規制よりも厳格である場合が少なくないから、というのがその理由でしたが、このような会話を交わすことさえ憚られるような状況もあります。そのような場合はどう対処しましたか？

Scherrer: 監査やリスク管理、セキュリティ部門との個人的な関係を使って、プロセス改革の意図に関して、早い段階から彼らに関与してもらえるようにしました。その上で彼らに、企業にとって重要なものとして判断してほしいと依頼したのです。

InfoQ: ソリューションの中には技術的に高度なもの(コードレビューやリリース自動化など)も含まれていると思いますが、監査人との言語的なギャップを埋めてコンセンサスを確立し、コンプライアンスを確実にするためには、どのような方法を採用したのですか？

Scherrer: 私たちは幸運にも、両方の面で優れた専門知識を持つことができています。監査部門にはIT専門家チームがあります。彼らは元々、私たちソフトウェア部門の出身者なのです。

InfoQ: あなた方の組織におけるDevOps活動が直面した課題には、その他に何がありますか？

Scherrer: 開発者全員をオンコール担当ローテーションに含めるというのは、当初は大きなテーマでした。一部の開発者の説得には、長時間の議論が必要でした。運用チームとテストチームは現在もありますが、彼らは自分たちの将来が不安であったり、あるいは“左シフト”することを快くは思っていません。そしてもちろん、DevOpsチームをビジネスにより直結することによって、仲介者という役割はなくなり、組織内に敗者が生じることになります。

InfoQ: ある種の考え方や文化を育むというのは、時間のかかる仕事ですが、SIXにDevOpsとアジャイルプロセスの文化を根付かせるために、どのような取り組みをしているのですか？

Scherrer: Hakaプロジェクトの一環として、DevOpsコアチームとは週次のスタンドアップミーティングを行なっています。その他にも、コアチームに新メンバを参加させたり、数週間分の作業結果を観衆の前でデモンストレーションしたり、優秀なDevOpsの成果を表彰したりしています。このような方法で、従業員にDevOpsの進捗状況を伝えるようにしているのです。これと並行して毎年２回、各チームと進捗状況を議論して、その結果を成熟度メータという形式で透過的に公開しています。これにより、成熟度がどのように向上しているか、他チームと比較して自分たちがどの位置にいるのか、どのような点を改善できるのか、といったことを確認できます。私たちはアジャイル手法のコーチングの提供だけでなく、組織を前進させるための技術も提供しているのです。

InfoQ: 成熟度メータについて詳しく教えてください。どのようなディメンションを対象としているのですか？

Scherrer: 成熟度メータは自慢できると思っています。他の企業でも採用されていますし、カンファレンスでも２回講演したことがあります。残念ながら、今のところはすべてドイツ語です。
このメータでは、次のようなディメンションを使用しています。

• チーム
• 顧客
• プロセス
• 方法論
• ツール

まず最初に、すべてのディメンションに対してYes/Noの質問をします。
チーム: 個人の目標ではなく、チームの成果に取り組んでいるチームメンバが80名以上いるか？
顧客: 最低でも月1回、顧客と連絡を取っているか？
プロセス: ソフトウェアは自動的にビルド、テスト、デプロイ可能か？
方法論: アジャイル手法を適用しているか？
ツール: 一元的に提供されるCi/CD用のツールスタックが使用されているか？

答がNoのチームは、その理由が何なのか説明しなければなりません。Yesであれば、アンケートに基づいた成熟度の評価を行ないます。この内容を一晩で翻訳することは不可能ですが、大まかなアイデアならば説明できます。顧客のディメンションについては、顧客の関与、顧客をサポートするためのチーム内のビジネスノウハウ、客観的視点から見た場合の顧客は誰か、などを質問します。次に、該当する場合であれば、チームが指定した顧客の満足度を評価します。 これらすべての結果を基に、1から10までの値を与えます。すべてのディメンションがまとまれば、チーム毎のレーダーチャートを作成します。

このプロセスを実行するために、各チームに年2回、アジャイルコーチを派遣しています。これはかなり大変です。一方で私は、これはアジャイルコーチングの一部であって、管理業務とは見なしていません。それが可能なのは、結果の保存と表示の可能な自己開発型ソフトウェアがあるからです。