英国の番組制作/放送局であるITVで共通プラットフォームの責任者を務めるTom Clark氏が，ロンドンのDevOps Enterprise Summit 2016において行なった，組織全体にDevOpsプラクティスを広めるメディアとして同局のクラウドプラットフォームが果たした役割と，それに関わる”スマートで親切な”技術者のチームを育て上げた方法についての講演が好評を博した。
InfoQは氏にコンタクトを取り，ITVがDevOpsに取り組み始めたきっかけと現在の状況，これまでのおもな課題などを聞いた。
InfoQ: あなたの現在の役割について詳しく教えてください。
Tom Clark: プラットフォームエンジニアのチームの管理責任者として“共通プラットフォーム(Common Platform)”の開発と運用を行っています。このプラットフォームは，当社の近代化プログラムを通じて開発された，すべてのアプリケーションをホストします。
InfoQ: DevOpsをいつ，どのように知りましたか？
Clark: 2010年に最初のLondon DevOpsメーリングリストに参加した時，始めてそのことばを聞きました。ですが，そのメリットについて始めて知ったのは，2007年にTrutapというスタートアップで開発者として働いた時です。開発者とシステム管理者が席を並べることで，互いの領域について自然に知識を深めることができるという， 本当に生産性の高い方法でした。
InfoQ: 組織内でどのようにDevOpsを始めたのでしょう？最初のステップは何で，それはなぜでしたか？
Clark: 2012年に私たちは，Samsung TV用のITV Player (当社のVODプラットフォームで，現在はHubと呼ばれています)を開発していました。それがMVP(Minimum Viable Product)であったため，私の同僚のRobert Taylorが，この開発はこれまでに使用してきた機能的サイロではなく，DevOps/製品チープアプローチを試す上で絶好の機会ではないか，と考えたのです。
InfoQ: 草の根運動が中心だったのですか？あるいはDevOpsの必要性に対して，トップダウンの理解があったのでしょうか？
Clark: 間違いなく“草の根”です。RobertはWardley氏の言う“開拓者(pioneer)”なのです — 彼は確信を持って，オンライン部門の技術管理者にDevOpsを試行するように説得しました。それが大きな成功を収めたことにより，他の部署でも採用するための自信を持つことができたのです。このことが確かな証拠となって，他の技術部門にとっても適切なアプローチであることをCTOに納得させる上で役立ちました。
InfoQ: 社内では現在，どのようなDevOpsのイニシアティブを行なっているのでしょう？組織変更は実施されたのでしょうか？
Clark: ITVは現在，既存のビジネスシステムを根底から作り直すような，大規模な近代化プログラムの真っ最中です(既存(legacy)には，仮想メインフレームでCOBOLを実行するようなシステムも含まれます！)。プログラムではウォーターフォールからアジャイルへのスイッチに加えて，短命なプロジェクトよりも息の長い“製品”を通じた開発への切り替えも実現します。
ITVは大別するとスタジオ，コマーシャル，放送，オンライン，共有サービスという５つの部署に分かれていて，それぞれに専用の技術チームが付属しています。近代化プログラムは，これまではウォーターフォールデリバリを使用していた，これらすべての部署を対象としています。このために私たちは，彼らすべてがアジャイルの“旅”に参加することで，リリース時点ですべての機能が揃っていなかったり，あるいは変更が月や年といったペースではなく，数日ないし数週間で提供されることで，彼らが驚かないようにしました。
InfoQ: リスク管理やセキュリティ，あるいはコンプライアンスチームなどから，何らかのカルチャーショックを受けた経験はありますか？
Clark: 意外でしたが，そのようなことはありませんでした。移行チームは自動化/CI/CDといったものを，リスクを削減してSN比を改善することで，“真の”リスクに注目するための手段として捉えています。セキュリティチームと同じような話なのです。私たちの行なっている自動化や監査，追跡といったものはすべて，プラットフォームに対する信頼を実現するためのものです。それによって彼らは，本当に必要なことに努力を集中できるのです。継続的デプロイを100%活用できていないビジネス領域もまだありますが，私たちとしては，彼らのリリースインターバルを段階的に短くすることで，それが安全であることをデータで示そうと考えています。
InfoQ: あなたの会社の中で，その他の文化的あるいは技術的な課題としてDevOps推進チームが直面した問題には，どのようなものがありましたか？
Clark: 当社では各チームにプラットフォームエンジニアを配置しているのですが，非常に有益である反面，集中型チームを用意するよりも明らかにコストが必要です。説得も必要でしたが，結果が事実を明らかにしています。
InfoQ: これまでのDevOpsに対する取り組みの中で，最大の成果と失敗は何でしたか？
Clark: 最近の成功例として思い付くのは，新製品の開発チームが“ゼロからベータ”に進んだ — ８週間で製品の事業化に成功したことです。以前ならば１年はかかったでしょう。
今のところ，幸運なことに，大きな失敗は発生していません ...
InfoQ: その両方のケースで，もっとも重要な要素は何だと思いますか？
Clark: 成功の要因はたくさんありますが，鍵になったのはコラボレーションです — ビジネス的にMVPとして必要なのものは非常に明確でしたし，私たちもそれを過不足なく提供しました。プラットフォームの観点からは，共通プラットフォーム“ツールキット”に大きなメリットがありました。これはコアチームが開発したもので，各チームのプラットフォームエンジニアが日々の作業に使用しています。標準的な“プリミティブ”を再利用してプラットフォームを構築することにより，全体として高い一貫性と品質を実現することができました。
これまで大きな失敗が起きていないのは，私たちがビッグバンではなく，反復的な変更を行なっているためだと思います。“始めは小さく，目標は大きく(start small, think big)”という考え方が好きなのです。また，私たち自身についても，最先端を追い続けるよりも“速いフォロワ”でありたいと思っています。
InfoQ: “2016 State of DevOps Report”には，DevOpsと継続的デリバリのプラクティスへの投資がより早く，より信頼性の高いビジネス価値の提供につながることが示唆されています。これは事実だと思いますか？そうであれば，これまでにあなたの組織の中で，その主張を裏付けるような具体的な例がありましたか？
Clark: 認めざるを得ないでしょうね！先程の“ゼロからベータ”の例でメリットの存在は明らかですが，人手による運用ではスケールアップができません — 自動化/CI/CDを通じることで始めて，近代化プログラムを実現するために必要な変更量を安全に実行できるのです。
InfoQ: DevOps転換によって得られた価値(あるいは無駄の削減)を検証するために，どのようなメトリックやフィードバックを集めているのでしょうか？
Clark: ホストしているプロダクトオーナ(私の考える顧客)に定期的に会って，彼らが効果的なデリバリを実現するためにできることを，私たちがすべて実行できているか確認しています。彼らはみな非常に満足していると言ってくれますが，DevOpsの導入による変化を定量化するという，難しいデータの収集にも着手したいと思っています。
InfoQ: ITVのDevOpsに対する今後の取り組みには，どのような課題や障害がありますか？
Clark: 優秀な人材を見つけることが常に課題です。私はいつも，２つの資質で採用を決めています — 変化に適用できる“賢明さ”と，チームに溶け込める“優しさ”です。どちらも簡単に見つかりますが，両立している人はなかなかいません。お金だけでは十分ではありません — すべてのボックスをチェックした上で，それを維持する必要があります。
この記事を評価
- 編集者評
- 編集長アクション