DevOps変革をリードする時、チームをチャンスに引き込む上で有用なのは透明性と可視性だ。ひとたび参加すれば、開発者は知識のマルチプライヤ(増幅器)として機能し、変革活動に貢献してくれる。頻繁に発生する問題の解決、複雑な問題への対処、変革の進捗状況の提示を組み合わせることで、ステークホルダの関与を維持することが可能になる。
Prasath Kumar Ramachandran氏はDevOps Summit Canada 2021で、自身がSAP labs IndiaにおいてDevOps変革を主導した時の経験について講演した。
変革の初期フェーズには、さまざまな課題だけでなく、変革に対する抵抗にも直面した、とRamachandran氏は言う。
問題の本質が見えていなかったのです。隠れた問題や、システムが深い場所で複雑につながっていることによる意図しない影響に気がつきませんでした。
そこで氏らは、ビジネスの継続性を確保するために、変革活動を一時的に停止して元に戻すことにした。その上でパターンやクラスタや根本原因を特定し、混乱を最小限に抑えるために対象とするグループを絞った上で、変革活動を再開したのだ。その一例を氏が挙げている。
私たちは、古いモデルのハンドヘルドプリンタで動作する既存ライブラリとの互換性を意識していませんでした。このプリンタは、世界のごく一部の地域でまだ使用されていたのです。そのために印刷機能が動作しなくなりました。そこで私たちは、活動を一時中断して、影響を最小限にするため、地域別に、段階的にロールアウトする方法に変更したのです。
さまざまな変革活動の進捗状況を透過的かつ可視的に示すことで、変革に対するチームの集合的参加意識を高揚するようにした、とRamachandran氏は説明している。
MTTRやコードカバレッジなど、さまざまなメトリクスをキャプチャするダッシュボードを作成しました。また、チームに対する自動アラートを、デグレードや障害が発生した場合の責任に基づいてカスタマイズしました。デグレードを自動検知して適切なアクションを実施するためのツールも開発しました。
私たちは"非難のないレトロスペクティブ(blameless retrospective)"を文化として取り入れていたのですが、チームが前進し、建設的なフィードバックで問題を解決する上で、これが役に立ちました。これらすべてが、私たちチームの進展を振り返り、総体としての変革へと進む上での支援となったのです。
初期段階を終えた後は、クラウドエンジニアリングやDevOpsに情熱を持った開発者を選び出して、彼らに変革活動への貢献を促した。これらの開発者が組織において、知識のマルチプライヤとして行動してくれた、とRamachandran氏は説明してくれた。
開発者たちは変革の進展を早め、さまざまなクラスタに関する正しいシグナルを得るための協調的環境を創造し、多くの活動を軌道に乗せてくれたのです。
知識の差を埋めるため、ハウツーガイドと、内部知識に基いて質問に答えるDevOps FAQボットを用意し、複数のセッションをロールアウトして自信を持ちました。
DevOps変革について、Prasath Kumar Ramachandran氏に聞いた。
InfoQ: SAP Labs IndiaでDevOps変革を始めたのには、どのような理由があったのでしょう？
Prasath Kumar Ramachandran: 最初は頓挫した(brownfield)変革活動から始まりました。私が"その日の問題"を聞き、チームと協力して解決にあたる、というのが当時の典型的な日課でした。
次の問題とそれを解決するために残された時間を知りたかったのです。その上で、現場(Gemba)と管理側の利害関係者から問題を収集して、カテゴリ、優先度、発生確率で整理する、という作業に着手していました。曖昧な部分の明確化という視点を持って、問題と解決策を評価しました。手近な成果を見つけ出して、進捗状況を示すことで勢いを持続させたのです。
並行して、複雑な問題の解決にも焦点を当てていました。例えば、"大規模な開発チームの運用において、複数のCI/CDサーバで失敗したすべてのジョブに固有の問題を見つける"というようなものです。これによって手作業の時間を節約すると同時に、チームの生産性を毎日xパーセント向上することができる、という考えからでした。セルフサービスのダッシュボードに単純なexcel出力を作成することで、ソリューションを段階的に進化させました。こうすることによって、CI/CDのステージ全体で共通する問題と解決策をチームやマネージャの目に見えるようにしたのです。チーム内の適切な専門家にも関与してもらって、ソリューションアプローチの特定と共有を行いました。これにより、チームの生産性とMTTRが大きく向上しました。
進むべき方向性が明確になったところで、クラウドエンジニアリングとDevOpsプラクティスのイニシアティブについて関係者に伝えました。アーキテクトとプロダクトオーナに対しては、サポートの意思、改善提案、組織としてのメリット、という点についてフィードバックを求めました。エンジニアリング発想のアプローチを問題解決に取り入れたことは、進むべき方向性を確立する上で有効でした。
InfoQ: チームメンバが目標と戦略的判断を共有するために、どのようなことをしましたか？
Ramachandran: 共通の目標とビジョンに関しては、管理側の関係者、開発者チーム、エンドユーザが定期的な連携を行いました。変革に抵抗する視点と理由、対処する方法は理解していました。例えば、コンピテンシのギャップには、ハンズオン・チームセッションの提供と変革イニシアティブの時期の選択によって対処しました。
私たちが作り上げた文化は、継続的学習、改善、オーナシップの主体的取得、他チーム支援、透明性といった、複数の属性を備えています。信頼を核とする帰属意識と一体感が、グループのオーナシップ意識を育んだのです。
InfoQ: リーダとして学んだことは何ですか？
Ramachandran: 私たちが従事した組織、製品、チームにはすべて独自の要素があり、変革への対応も違います。私が学んだのは、適応指数(adaptability quotient、AQ)が重要である、ということです。AQは、シグナルを読み取って行動し、外部の影響によってリアルタイムでコースを変更する能力、と定義されています。AQを向上するための専門的な計画を作ることが重要でした。"一度成功したことが次も成功するとは限らない(what got you here won't get you there)"という現実があります。実践者の心を持つことで、チームを指導することが可能になるのです。
ソリューションの戦略的実践には、進化的アーキテクチャの原則、Conwayの法則、Murphyの法則、といったものを念頭に置く必要があります。その達成のために私は、アーキテクチャや設計、スピード、スキル、コスト分析に関する意思決定活動において、チームの宣伝役(sounding board)として行動しました。
InfoQ: スキルセットという観点から、明日のリーダはどのようなものを備えるべきだと思いますか？
Ramachandran: リーダとしては、フィールドを越えてアイデアを結び付け、進捗を提示し、機会を成功につなげる能力が、価値のある、かつ緊急を要するものでしょう。次の提案は、それらを実現するために有用なものです。
"自分自身への投資" — 素早く学び、知識を行動に転換することが競争的優位性となります。自分自身の管理、イノベーションへの実験的アプローチ、テクノロジスキルに焦点を置いた学習プランを用意しましょう。
"強みに取り組む" — 他者の強みを認識する能力を養い、彼らと組織に対してよりよい結果をもたらすトピックに自身のエネルギを集中してください。
"自分のメンタリングチームを見つける" — あなたのアイデアを支持してくれる人を識別しましょう。あなたのリーダシップ獲得をガイドできるメンタを見つけ出して、さまざまな分野のリーダをフォローしてください。
"好奇心指数を改善する" — 自身の快適空間外にある新たなことを学ぶための能力とオープンさを向上させます。これによって、曖昧さから明確さへの変革を、プラクティスとして理解し、処理することが可能になるのです。