プラットフォームはコラボレーションのための仕組みです。Marcy Paramonova氏とStéphane Cusin氏が、KubeCon & CloudNativeCon Europe での講演「Building Cloud Native Culture in a Bank」で説明したように、プラットフォームチームはアプリケーションチームに依存しており、両者には共通の標準が必要です。エンジニアがプラットフォームを信頼するのは、その機能の豊富さではなく、予測可能で一貫した振る舞いによるものだ。
Cusin氏は、オープンソースが我々が切実に必要としていたもの、すなわちチーム、ベンダー、ツール間の共有基準と共通言語をもたらしたと述べた。一方で、銀行業界においてオープンソースの採用は自明の選択ではありませんでした。サポート体制や責任の所在について、多くの懸念や疑問が存在している。
Cusin氏は、銀行業界ではまず信頼が求められると主張した。
信頼は意思決定によって得られるものではないです。信頼は、日々プラットフォームを運用し、一貫性を維持することで築かれるものであります。プラットフォームエンジニアとして私たちが学んだのは、開発者は機能の豊富さによってプラットフォームを信頼するのではなく、その振る舞いが予測可能であるからこそ信頼するのである。
Paramonova氏は、プラットフォームはコラボレーションのための仕組みであると述べた。開発者やプロダクトチームはプラットフォームチームに依存している。一方で、プラットフォームチームもアプリケーションチームに依存しており、双方が前進するためには共有された標準が必要である。
Paramonova氏は、オープンソースの利用者は単に技術を消費するだけではなく、その技術に貢献し、コミュニティを形成し、技術に関するアイデアを交換していると述べた。そのようなアイデア交換の取り組みの一つとして生まれたのが、私たちのGenius Barセッションである。
私たちは、普段のサポートチケット対応から一歩離れ、利用者に新しく斬新な支援を提供したいと考えました。そこで、利用者が自由に参加できるオープンサポートセッションを開催し、問題を一緒に解決する取り組みを始めました。こうした活動を続けるうちに多くの人々が関心を示すようになり、実際に多くのインフラストラクチャチームも参加するようになりました。
Paramonova氏は、エンジニアはソフトスキルを向上させることで恩恵を受け、それによって組織全体の協働がより円滑になると述べた。また、コミュニティ主導のアプローチを採用しており、人々が技術を中心としたクラブやコミュニティを立ち上げ、それを継続的に運営していると説明した。
Paramonova氏は、オーナーシップの明確化によって、エンジニア同士の関わり方が変化したと述べた。エンジニアは単にタスクを遂行するだけでなく、実質的な意思決定を行い、実際に大きな影響を与える存在として信頼されるようになったのです。
エンジニアであるということは、問題解決に取り組み、それに情熱を注ぐことだ。そして、エンジニアであるということは、問題解決への情熱を共有することでもあると、Paramonova氏は述べた。
Cusin氏は、オープンソースは単なるソフトウェアの選択ではなく、コミットメントであると述べた。ツールだけを変え、人々の考え方や協働の仕方、ものづくりの進め方を変えなければ、いずれ限界に突き当たると指摘した。
Cusin氏は、オープンソースは経営陣からの指示によるものではなかったと述べた。また、それは教義のような絶対的なものでもなかった。「オープンソースを使わなければならない」と誰かから命じられたことは一度もなかったのである。オープンソースは、私たちが進むべき方向を示し、この取り組みの指針となる羅針盤だったとCusin氏は締めくくった。
InfoQは、講演終了後にMarcy Paramonova氏とStéphane Cusin氏にインタビューを行った。
InfoQ：プラットフォームのユーザーとの信頼関係を築くために、どのような取り組みを行ったか。
Stéphane Cusin氏： 私たちは標準化、自動化、そして運用の高度化に重点的に取り組みました 。チームが開発環境、テスト環境、本番環境のいずれにデプロイする場合でも、同じ体験と同じ期待を持てるようにする必要があります。また、プラットフォームチームの責任範囲を明確化しました。どのサービスをプラットフォームチームが運用しているのか、どのサービスレベルを期待できるのか、そして各チーム自身の運用責任がどこから始まるのかを理解できるようにしました。
もう一つの重要な取り組みは、認知負荷の軽減であります。Kubernetesのあらゆる機能を利用者に公開するのではなく、妥当なデフォルト設定と明確な方針を持ったワークフローを提供するよう努めました。開発者は基盤インフラの複雑さを理解することに時間を費やすのではなく、アプリケーション開発そのものに集中できるべきです。
Marcy Paramonova氏：私たちは、新しいコンポーネントや機能を導入する際、それが完璧なものになるまで利用者への共有を待つことはしませんでした。自分たちが何をしているのか、そしてなぜそれを行っているのかを利用者に見える形で示しました。
その透明性は、完成度の高い製品そのものよりも価値があることが分かりました。利用者は単なる受け身の消費者ではなく、初期段階のテスターや協力者となりました。そして時間をかけて築かれたその関係は、リリース告知だけでは決して生み出せないものとなりました。
InfoQ：エンジニアリング文化は時間の経過とともにどのように変化したのか。
Paramonova氏：オープンソースコミュニティには独自の文化があります。そこでは意思決定の内容が文書化され、コミュニティへの還元が行われます。また、オーナーシップが明確にされているため、誰がコンポーネントを保守しているのか、誰が意思決定を行うのか、そして支援が必要な際に誰に相談すべきかが分かります。
私たちは、こうした実践を組織の中に取り入れようとした。Kubernetesを導入することは、単にコンテナオーケストレーション基盤を導入することではありません。それは、独自の規範や期待、協働の方法を持つコミュニティの一員になることです。その結果、私たちはより高い透明性、より広範なオーナーシップの共有、そして技術へのより強いこだわりへと導かれました。
カルチャーの変化は、誰かがカルチャー改革を宣言したから起きたわけではないです。ツールが特定の働き方を求め、その働き方が時間をかけて私たち自身のものになったことで、カルチャーが変化したのです。