はじめてのSREリーダー
初めてエンジニアのチームリーダーになってから1年が経とうとしている中、あんどぅさんやじょーしさんの振り返りを見て良いなと思ったので、自分の中での棚卸しを兼ねて初めて筆を取ることにしました。
せっかく駄文を読んでくださる方には何か得るものがあってほしいので、まずは1章で前提条件として私が置かれている状況をある程度具体的に述べます。その後、2章でリーダーとしてどのようにSREを実現していくかを、3章ではリーダーとしての日々の取り組みを述べます。4章では1年間を通して気づいたことを評価し、5章でまとめます。
0. 筆者の略歴
2017年に新卒入社。複数のシステムについて保守運用および新規開発やリアーキを経験。
2020年に組織横断でのディレクションを担当。他組織や経営層に近い人々を含む場での調整・合意や各種施策の提案および実行を推進。
2021年にSREの新規立ち上げメンバーとして指名される。スケーラビリティの改善およびパフォーマンス・チューニングを通して、まずは組織の課題を解決する集団であるという形でSREの存在価値を組織に示す。
2022年に組織が拡大し、それに伴ってSREリーダーに昇進。
1. どのような状況で働いているのか
1-1. 組織的な立ち位置
まずは以下の図1の組織構成概要図を通して私の立ち位置を述べます。一色だけ異なるピクトグラムが私であり、ハイライトされた範囲は私から影響を与えることが可能であることを表します。ハイライトされた範囲は組織内のエンジニア全体であり、エンジニアリングに従事する人についてはVPoEも含め何かしらの手段で接触可能だと考えています。
この影響可能な範囲の広さは、SREが横断的な活動を求められていることに加え、これまでの仕事を通して上位の役職者から私が十分に認知されているという2点によって実現されています。
1-2. ボスとの関係
ボスからは何も管理されておらず、完全に放置されています。SREとして活動するようになってから人を率いて何かする場合に何度かある程度形式張った進捗報告をやんわりと求められましたが、あまりにも面倒なので口頭報告でお茶を濁し続け、今のところ無事に逃げ切ることができています。今期も最後に進捗報告をしたのは4月下旬でした。最早口頭報告すらしていない。
1on1ではメンバーの変化やSREが組織により大きな影響を与えるためにどういったアプローチが考えられるかといった話をすることが多いです。
1-3. チームメンバーと担当業務
私のチームメンバーとして以下の特徴を持つ人がアサインされています。
プロフェッショナル・オブ・プロフェッショナル。課題設定、意思決定、解決方法の提案および実行、教育といった全方向120点のオールラウンダー。ただし致命的に朝に弱い、というかいない。
卓越した責任感を持っており、いつアラートが鳴ろうとも即座に取る。たぶん寝てない。非常に安定した貢献を行うが、裏を返すと大胆さに欠ける。
非常に高い技術力を有しており、技術的なhowの実装においてはほぼほぼ指摘する必要がない。若手への指導を始め何をやらせてもできるものの、組織における管理職には全く関心がない。社会性フィルターを通した表現でリーダーはやりたくないですと言われる（n敗）。
極めて高いレベルのリーダーシップを持っているが、リーダーシップとスキルのバランスが悪すぎてやりたいことに対してhowが貧相になりがち。やたらとデキる人たちに囲まれてしまったせいで比較基準が異様に高くなってなんだか大変そう。
課題に対するソリューションが真に意味があるものかを徹底的に考え抜く。が、全体像の見通しは悪め。仕事においてはゆっくりと言葉を紡ぐが、アイドルの話になると早口すぎて感情がギリギリ追いついていない。
妙にクセが強いメンバーと共にECサイトにおける商品入稿ツールおよび商品管理システムの2つのシステムに対してSREを行っています。リソース配分としては、商品入稿ツールは凄まじいレガシーで10年ものの怪しいコードが熟成された魔界であるため、商品管理システムは1人、残りのメンバーで商品入稿ツールを担当しています。
魔界こと商品入稿ツールについて実務をせずに一定以上の質の意思決定をするのは不可能であると早々に判断し、検討・計画・実行についてはほぼ完全に委譲しています。その代わりに商品管理システムについてはプレイヤーとしても仕事しています。
2. リーダーとして考えていること
SREの至上命題は信頼性と新たな価値のデリバリー速度のバランスを最適化することであり、これが組織のために実現するべきバリューだと捉えています。個々のリーダーのミッションとしては、SREのバリュー実現に向けた過程を通して組織の文化に変化を起こすことだと考えています。
2-1. どのような状態を目指すのか？
これから記す内容は私見であり、組織としての意向を示すものではありません。個人としてはこの内容を元に提案や指摘を行いますが、組織としては議論の末に異なる方向性に進む可能性は大いにあります。
極論ではありますが、SREという組織が存在しなくても信頼性とデリバリー速度の最適なバランスが実現されていることが最も望ましいと考えます。この状態では各システム担当チーム自身がSREを行う必要があります。ブレイクダウンすると各担当チームおよび組織に以下の要素が必要だと考えます。
信頼性を表すSLOの継続的なモニタリング環境
現状の信頼性を評価し、以下の2軸いずれかの方向での意思決定
デリバリー速度を向上するための、変更箇所の検討及び実装
信頼性を回復するための、信頼性を毀損している原因の特定および修正
2を実行するための、1をベースに議論できる組織的な意思決定フロー
モニタリング環境についてはマンパワーで一度導入しきってしまえばそれがスタンダードとなり、SREという組織的なアプローチを通して強く介入しなくてもある程度機能すると考えています。もちろんSLOは各システムに紐づくものではありますが、その設計およびモニタリングシステムの構築は既存の前例が参考になるという意味でその実現は他と比べてそこまで困難ではないと仮定すると、残りは信頼性に基づいたソフトウェアの改善と信頼性に基づく意思決定フローについて考える必要があります。後者についてはモニタリング環境と同様の理由で、SREの実践を通して一度合意してしまえば持続可能だと考えています。なぜならばこのとき合意を取る相手はサービスのオーナーであり、信頼性と新たな価値のデリバリー速度に最も関心のある立場であるからです。したがって議論がなされていないのは信頼性に基づいた改修のみになります。これはモニタリング環境構築や意思決定フローの構築と比べて個別のシステムおよび担当チームへの依存が強いと考えています。
ここで所属している組織の現状を見ると、現場は最低限の運用と迫られた機能開発でほぼほぼ全てのリソースを使い切っており、自主的な改善を実施する余裕はないようです。もちろん著しく毀損された場合はその難易度を加味して組織的な命令としてある程度の期間の目安とともに信頼性を毀損している原因の特定および修正が指示されますが、当然機能開発がトレードオフとなるためあまり好まれず、十分に大きな問題となってから取り扱われます。もちろん機能開発がトレードオフとなる期間はビジネスにおいて重大なインパクトを与えるため、改修コストが高い場合は時間をかけて応急処置をして一旦対応完了というような意思決定にも繋がっていきます。
そういった状況下において半年単位で余白がほぼないサイクルを評価という金銭的なフィードバックと紐づけて回し続けると、現場レベルでも根本的な原因の解消や現状を大きく改善するといったアプローチに対する勘所がどんどん鈍っていくと考えています。今期各リーダーに対してヒアリングを実施しましたが、とにかく余裕がないという意見が多く、目の前の業務以外に思考を回せていない様子が感じられました。
さて、残った信頼性に基づいたソフトウェアの改善について考えます。これまで述べたモニタリング環境や信頼性に基づいた意思決定フローの構築はSREという組織的なアプローチによる機能を期待できる一方で、信頼性に基づくソフトウェアの改善については個別のシステムに紐づくアプローチが必要です。しかし、上述した通り現場はそういった視点を持って実践する余裕がない。よって、現場がそれを実践するには以下のステップが必要だと考えます。
トイル削減や業務フロー見直しによる物理的な時間の捻出
担当チーム自身での改善箇所の発見および実装
物理的なまとまった時間の捻出はSREによる組織的なアプローチによって実現可能だと考えますが、これと比べると担当チーム自身での改善箇所の発見及び実装は各チームの担当者に依存する部分が大きいという特性の違いが有ると考えています。
ここまでの話を整理します。現状はビジネス上実施しなければならないタスクに忙殺されている状況ですが、我々が新たに (1) 信頼性を表すSLOの継続的なモニタリング環境、(2) SLOをベースとした意思決定フロー といった仕組みを整えた上で、各システムで (3) 信頼性もしくはデリバリー速度の改善 を実施することで、各システムでの継続的な改善作業の時間を捻出可能にしたい。これを示したのが以下の図2になります。図2においてsystemは現場でコントロールしづらい組織的なものを表し、userは現場でコントロール可能なものを表しています。
この節の冒頭で述べた文化の変化と絡めて再度整理すると、SREという組織的なアプローチを通じて物理的な時間を捻出しつつ、その過程でTODOリストの消化を繰り返し続けた担当チームが自身で改善活動を行うことができるような文化を作る必要があると考えています。では、自身で改善活動を行うためには何が必要なのか？私はシステムに対するオーナーシップを養うことが重要だと考えています。壊れている箇所の原因特定やさらなる効率化を可能にする箇所の発見には一般的な技術的な知識と担当しているシステムへの理解の両方が必要だからです。
そこで、チームがシステムに対してオーナーシップを獲得した状態を定義します。現状はTODOリストの消化がメインとなっており、以下の図3内の図表13に近しい状態になっています。これを図表14のように一人ひとりがシステムに対して積極的に意思決定できる状態をシステムに対してオーナーシップを獲得したチームとします。これらの図表は伊賀泰代氏の「採用基準」というリーダーシップに関する書籍から引用したものですが、観測範囲内においてはエンジニアはなぜか「リーダー」という言葉に対して抵抗を示す傾向があるため、システムに対するオーナーシップと表現します。
システムに対して自律的な改善を継続するために管理職としての「リーダー」というロールに就く必要はないですが、全てのメンバーについて「リーダーシップ」は必須のスキルだと考えています。先程挙げた「採用基準」はリーダーにフォーカスした書籍ですが、メンバー個人の活躍にフォーカスした書籍としてStanley McChrystalが書いた「TEAM OF TEAMS」があります。これは米軍がアルカイダとの戦闘においてトップダウンの構造を取っていたことで意思決定に時間がかかり成果を出せなかったため、管理をやめ、現場には達成すべきことのメッセージングを行いつつ意思決定権限および実行能力を与える形に変更したという内容です。以下の図4は「TEAM OF TEAMS」から引用したものですが、「採用基準」と全く同じ図となっており、現場の活動にフォーカスした書籍についても全く同じ主張が為されている点が面白いです。Jonathan Rasmusson「アジャイルサムライ」, 2011 においても2-4節でアジャイルチームに適した資質を挙げていますが、図3, 4における右の状況下で活動できる人として捉えられると考えています。
オーナーシップが発揮された場面をソフトウェアエンジニアリングに当てはめて考えます。例えば致命的な不具合が発生したとして、意思決定者が捕まらないとユーザへの影響が継続してしまいますが、担当者自身に意思決定権限および実行能力が付与されている場合は前述した状況と比べて大幅な速度での緩和もしくは解消の実現が期待できるでしょう。
この例のように、現場がシステムに対するオーナーシップを取れるようになると、担当システムの改善や担当範囲内におけるMTTRの短縮といった、技術的な観点での意思決定のスピードの向上が期待できると考えています。これを支えるのがSLOをベースにした意思決定フローという名の現場に対する実行能力の付与であり、これらを構築できれば、現場のオーナーシップを高めることで自律的な改善を継続しながら機能開発を行うことができると考えています。
ここまで組織的な観点で組織を支える仕組みおよび組織の構成要素の状態について述べましたが、最後に1人のチームリーダーとして理想的だと考える状態を述べます。オーナーシップが発揮されるということは、置かれた状況に対してその人自身が感じたことに対してその人のやり方でアクションを提案し、変化させていくということです。ここにその人のオリジナリティがあり、それは非常に良い意味での属人性だと考えています。そのオリジナリティを数多く実現させていくために、仕事の進め方といった道具の使い方をある程度仕込むことで、その人のオリジナリティを発揮する上での些末な障壁を可能な限り取り除くことに価値があるのではないかと考えています。ただし、これはプラクティスの押しつけとも解釈できるので実施する際は必要性を慎重に判断する必要があります。このように考えているため、songmuさんの以下の記事の「異能を活かすマネジメント」には共感しかありません。
この節の内容をまとめます。SREとして我々がSLOの継続的なモニタリング環境を構築し、実施するタスク選定は既存の判断基準にSLOをベースにした意思決定フローを組織に提案し根付かせます。その過程と並走しながら各チームがシステムに対するオーナーシップを養うことで、SLOをベースに自主的な改善活動を業務に組み込めるようになると考えています。ここまでの内容はSREという組織が完全にいない状態を念頭に話していましたが、もちろん完全になくすことは不可能です。しかしながら上記の状態が達成された場合においては、SREという組織は縮小した状態を維持できるのではないかと考えています。また、オーナーシップを養うことは良い意味での属人化を推進することであり、一人のリーダーとしてメンバーが自身のオリジナリティを発揮できるような支援をしたいと考えています。
2-2. それを実現するために何を実践するべきか？
2-1節でSLOのモニタリング環境、そしてSLOベースでの意思決定フローを構築するという組織的なアプローチと、システムに対するオーナーシップを養うという各現場に対するアプローチが必要だと述べました。
SLOのモニタリング環境構築については、理想的にはSREが主体的に動き全てのシステムに対してSLI/SLOの設計およびモニタリング環境の構築まで実施できるのが最短です。しかし全てに対して実行するには我々のリソースが圧倒的に不足しています。したがって各チームの協力を得る必要がありますが、2-1節で述べた通り、現場は目前のタスク以外を受け入れる余裕はありません。したがって、まずは我々のリソースを使って各チームのトイルを削減し、物理的な時間を捻出する方向性が良いと考えています。具体的に削減するトイルやその方法はこれから詰めていかなければなりませんが、以下の対応が候補となっています。ただし後者については、直感的に悪くない選択肢だと感じていますが、組織的に断行するコストに見合うトイル削減なのかは慎重に評価しなければならないと考えています。
バージョンアップの自動化と自動テストの拡充による四半期に一度対応が必要な脆弱性対応の著しいコスト削減
社内にもdependabotのようなサービスが存在するが、gradleには未対応
multi-projectを利用し、複数のマイクロサービスを1つのリポジトリへ統合
全社でリアーキを推進した際に多くのシステムがマイクロサービスに移行したが、少なくないシステムがマイクロサービスとリポジトリを1:1で構築
SLOベースでの意思決定フローについては、既存の意思決定層の価値基準に照らし合わせてSLOという数値的な指標から解釈できる内容がリンクしていることやSLOだけでは説明しきれない部分を説明し、合意を得なければなりません。この点はボスがグレートボスと地道に会話を続けていますが、概念レベルでの認識合わせは進んでおり、いずれはラスボスに提案に行けるだろうという見通しが立てられるくらいのステータスになっています。
最後にシステムに対するオーナーシップについて。オーナーシップを獲得させるような組織設計は現状なされていないため、草の根活動に留まっています。弊組織においてオーナーシップを獲得させるにはフィードバックと前例のない施策の実施を通した著しい成果の創出、現場自身での目標策定が必要だと考えています。
まず、フィードバックの重要性については身近なリーダーおよびボスにはリーダー用のprivateチャンネルで頻繁にインストールしています。特にポジティブフィードバックについては日本人の特性なのかわかりませんが少ない傾向にあり、対象への実際の評価に関わらず観測回数だけで比較した場合にネガティブフィードバックが多くの割合を占めていると思います。以下の図5は三村真宗氏の「みんなのフィードバック大全」からの引用になりますが、ポジティブフィードバックを浸透させるためのhowを身近なリーダーやボスにインプットする他、そもそも「みんなのフィードバック大全」は必読書であると伝え、観測した限りでは所属組織においてボスを含む半分以上の管理職がこの本を購入していました。
次に、前例のない施策を実施することについて述べます。少なくとも数年間は現場は与えられたTODOリストを消化するだけの状態が続いており、何かしらの施策をやるにしても常に時間的な制約によって応急処置のようなものが多く、もちろん観測範囲が狭い可能性もありますが、完全に解消するといった事例はほぼ見たことがないです。そういった状況下において、組織の意思決定ロジック上採用できていないが価値があるであろうことをメンバーと共に達成し大きな成果を得るという事例を通して、システムに対して高いオーナーシップを持った人を増やしていくしかないと考えています。直近ではあまりにもヤバすぎて手に負えず二度のリアーキを生き延びてしまった10年以上熟成された魔界の見通しをよくすれば不具合が減るのではないか、といったことを考えています。
最後に、現場自身での目標策定についてです。弊組織においては上位の組織目標を管理職レイヤで各担当領域における実行計画として策定しなおし、メンバーはそれを達成することで評価を獲得するという仕組みになっています。末端なので実行計画に対する責任を負う事自体に問題はないと考えていますが、組織目標と実行計画の関連付けが管理職レイヤでなされているために、与えられたタスクを消化するだけが組織における現場の役割として暗黙的に根付いていくのではないかと考えています。これを解消するためには組織目標を元に自分たちの担当範囲内では何ができるのかを考え、実行計画と共に管理職レイヤに提案しに行くフローに変更することでオーナーシップを養うことができるのではないかと考え、ボスにも提案済みです。来期からトライします。
3. リーダーとしての仕事
3-1. 課題設定
2-1節で述べた通り、現場は担当範囲において強力な意思決定能力とそれを支える実行権限を持つべきであると考えています。この状態において統率された管理は困難でありメンバーの進捗を妨げるだけなので、基本的に管理はせず、好き勝手に遊ばせています。1on1では課題を解決するために何をするべきか？根本的に良くするためには何をすれば良さそうか？といった話をすることが多いです。
これは私のチームメンバーがプレイヤーとして高いレベルにあり、私が管理しなくてもほぼほぼ一定品質以上のものを生み出せるために実現できています。仮に未熟なメンバーがチームのほとんどを占めている場合は、おそらく、共に仕事をする過程を通してある程度安心できる基準まではタスク遂行のためのhowを仕込むことに集中すると思います。
3-2. フィードバック
これが管理職にとって最も重要な仕事だと認識しています。
普段の業務遂行プロセスを見て、改善の必要性がある箇所を発見します。このとき可能な限りリアルタイムにフィードバックを伝えるのが望ましいですが、特にスキルについてはそれが自身にとって重要な課題であると認識する必要があります。まずは課題感を提示し、それを本人がある程度大きな問題として捉えている様子が見られたときに、それを解消するためにブレイクダウンした要素を並べ、1つずつその要素は既に満たされたか？といった確認やその人にとっての過去の事例を取り上げて関連付けることを定期的に行って課題を解決することを意識しています。特に課題解決のために緻密に1要素ずつ積み重ねていく点はフィードバック時にシグナルとして発することを意識しています。ここで述べた内容はUlrich Boser「Learn Better」, 2018に記されています。困難な課題をそのまま取り扱うのは万人に出来る芸当ではないと考えており、安定した改善を実現する手段として体得してほしいと考えています。
このフィードバックはチームメンバーに対してだけではなく、業務委託や他の部署のリーダーに対しても必要性を感じれば実施しています。
3-3. 評価
メンバーが生み出した成果の定量的な根拠を集めます。ただこれもオーナーシップを養う上で重要かつ上位の役職者と議論する上では必須のスキルなので、担当領域の分についてはメンバーにやってもらった方が良いのではないかと考えています。
3-4. プレイヤー
マネジメントだけが全てではなく、手を動かすように心がけています。これは2章で述べたオーナーシップを養う上で、自分自身がメンバーの先頭を走ることに価値があると考えているからです。というキレイな理由にかこつけて開発は楽しいから私も遊びたいという個人的な感情もそこそこ大きいです。でも楽しいんだよなあ・・・困った困った。
課題解決をする上では、howありきではなく解くべき重要な課題であるのかを確かめ、課題を分解した上で原因となる要素を取り除いてからhowを構築することを意識しています。前期で言えばリアーキの過程で必要になってしまった歪なブランチ運用がリアーキ後も継続していたため、現時点での運用を元に達成しているオペレーションを確認し、ブランチ運用フローを改善するといったことをしました。また、HTTPステータスエラーが一定割合継続しているという事象に対してtcpdumpでパケット分析を行うことで詳細に事象を確認した上で止血するための変更を加えたり、コストカットの文脈に従って性能試験をするためのシナリオのモデリング、試験及び評価、チューニングを行ったりしました。
ただ、ほぼほぼ手のかからないメンバーを抱えていてもコンテキストスイッチのコストが気になるので、どこまで行っても昔のように目の前のタスクに100%のエネルギーを使い切ることは不可能だなとは思います。エネルギーをほぼ全て割くことも可能ではありますが、チームメンバーの活動状況を捉えづらくなるので、長い目で見たときに組織にとっては著しい損失になると考えます。
3-5. 組織横断での活動
弊組織は優秀になればなるほどなぜかMTGがてんこ盛りになって身動きがとれなくなります。ボスも例に漏れず毎日毎日MTGで1日が終わっており、組織横断の活動は意図的に活動しない限りは生み出しづらいと感じています。よって、マネージャーまたはプレイヤーとしての業務を行う過程で、こういったことをすれば横の組織に影響を与えられるのではないか？これはXXXの観点で良くないので改善の余地があるといったことについて勝手に思索を巡らせたり、提案したり、実践したりします。
例えば、組織全体として不具合が多い状態が継続しているため、不具合が発生した場合は担当者が後日役職者に報告会を行うようになっているのですがその報告内容から学びが少ない傾向にあるために、ポストモーテムを実施しその内容を報告したりしました。これはだいぶ評判が良かったようで、実施したチームの部門長から好感触のフィードバックを頂いたり、報告会における報告フォーマットがポストモーテムとして利用しているものに変更されたりしました。
また必要だと感じたチームについては個人的に関係を構築し、状況のヒアリング及び改善策の提案を行ったりしています。今期は不具合の報告会で役職者からタコ殴りにされただけのチームが不憫過ぎたのでフォローアップとしてポストモーテムを実施することで、事象だけでなく対応過程からの学びを抽出しました。またそれをきっかけにアラート疲れが発生しているという相談を個別に頂き、ソリューションを提案したところ、false positiveなアラートの発砲が相当抑えられたというフィードバックをいただきました。
4. 評価
4-1. うまくいったこと
① ボスに様々な影響を与えることができました。具体的にはフィードバックの重要性だったり、現場から上がってこない課題を吸い上げる上で非公式なチャンネルの構築の有効性について共感してもらうことができました。
② チームメンバーに対する権限委譲が成功しました。リーダーになったばかりのときは優秀すぎるメンバーをどのように扱うべきか悩んでいましたが、管理を諦めたことでメンバーが好き勝手に遊べるようになり、メンバーレベルでも組織として何をすべきかの思索に時間を使うことができていました。また、目に見えてる範囲において何をどのくらいの期間で成すべきかといった判断はメンバーから提案してもらえるようになりました。少し前に以下の記事が話題になっていましたが、私のチームでは知識は十分にある状態でメンバーに紐づく責任と実行能力が弱い状態でした。「TEAM OF TEAMS」にも意思決定能力と実行権限はセットと書かれており、強力な実行権限をセットで渡すと明確に繰り返し伝えたのが有効だったと考えています。
③ チームのslackチャンネルで思考を開示することで、どういった視点でものを見ているかをメンバーに共有できました。転職で新しくジョインしてくださった方がいらっしゃり、スムーズにオンボーディングできるように組織の見解とそれに対する私の見解の公開およびその人の価値観の把握に努めていましたが、それによってその方から思っていることを話しやすいというフィードバックをいただきました。
④ 組織横断での活動を数多くできました。前述したポストモーテムの実施や個別での相談を実施した他、意思決定者と客観的な指標を元にソフトウェアについて議論できる状況を目指して、組織内の全てのシステムにsonarqubeを導入することができました。以下の記事のようにソフトウェアの品質がビジネスに対して影響を与えるという主張には直感的に同意できるものの、具体的なビジネスへの影響と関連づけて説明された事例を見たことはありません。まだ導入が完了したばかりでインサイトを見出すのはこれからですが、多くの方の工数を頂いてしまったので、各チームがsonarqubeの指標を元に意思決定層とビジネスとのトレードオフを議論できるような環境を作りたいと考えています。
⑤ フィードバックがうまくいきました。1-3節で書いたhowが貧相なメンバーがいると書きましたが、その人に対して3-2節で書いた手段が特に有効に機能しました。思考回路の整理から始めましたが、今では自身で改善を回すために自身で課題を見つけてそこに対してアプローチするといった行動が習慣化しています。この成長はSRE Next 2023での採択という客観的な形でも現れました。
⑥ メンバーの意思決定を支援するツールを作ることができました。元々は取り扱おうとしている課題の評価や成果測定のために開発したCLIでしたが、実際の対応方法を検討する際にも使ってくれていることがわかりました。メンバーの意思決定を支援するという観点では貴重な成功事例だと考えています。
⑦ ボスから管理されずに済んでいます。前述した通りボスは何故か死ぬほど忙しく、たかが1チームの事情に振り回されている場合ではありません。そんな中で成果の方向性さえ認識を合わせれば、私のチームの詳細を意識せずとも出来上がった成果が報告される状況を実現できているのはボスにとって非常に楽なのではないかと考えます。
4-2. うまくいかなかったこと
① チーム内やチーム横断での横展開ができていないです。毎週展開しないと追いつかないほど進捗出とるんか？もしくは腕力が足りてないのでは？といった方向で考える余地はありそうですが、週次でやるようなものではないとは思っています。
② なんでもできる人をうまく活躍させられていないです。エンジニアとしては十分なレベルなのでシニアエンジニアとして意思決定層と交渉したりしながら技術的なソリューションを実装する経験が必要だと考えていますが、それをうまく用意できていないです。たぶん下に人をつけて計画実行させるような仕事があれば良さそうだと思いますが、それができる環境にないです。
③ 直近はプレイヤーとしてのタスクが多くなってしまい、メンバーの状態をキャッチアップするコストが高くなってしまいました。代わりに組織にアピールできる大きな成果を生み出せはしましたが、メンバーのことを考える時間は非常に取りづらく、この状態が続くと組織として長期的な損失になるという危機感を覚えています。
④ 個別のシステムの改善をベースにしたアプローチではSREという組織のリソースがボトルネックとなってスケールしませんでした。実施した改善自体に意味があるとは組織から評価されているものの、他のシステムに対して実践するには膨大な時間が必要になってしまうことに気づきました。
4-3. 幸運だったこと
① チームメンバーがとてつもなく優秀でした。組織内で一番いいと思えるレベルでリッチ。メンバーのお陰で管理はメンバーの制約になると気づくことができましたし、管理をしないことで浮いた時間を何に使うべきか思索できたことで、組織横断の活動に価値があると気づくことができました。
② ボスや身近なリーダーが脳筋でした。あまり表には出さないように心がけているものの根が脳筋なのでどうしても自身の腕力で解決するといったパワー系のソリューションに至りがちなのですが、そこに共感してもらえるのでとっても楽な環境で働くことができています。
4-4. 周囲からの評価
ボス、部下、同僚の360度評価がありますが、個人のパフォーマンスとしてはボスからが100点、部下からが98点、同僚からが92点といずれの方向からも高い評価を頂くことができました。特に部下からなされる管理職としてのフィードバックについては全社平均が83点であるのに対し、92点と大幅に上回ることができました。
2章で述べた通り、現場が自身の意志を発揮できることを最も重視しながら日々仕事をしているので、そういった取り組みに対して優秀なチームメンバーから高い評価を得られたことは素直に嬉しく思います。
幸運にも単なる管理職ではなく組織横断の視点を持つことができ、この視点で活動すること自体はとても面白いので継続し、組織横断で大きな成果を出したいと思っています。
5. まとめ
SREリーダーを始めてそろそろ1年が経ちますが、優秀なチームメンバーへの権限委譲を進めたおかげでどのような組織を目指すべきか、それを実現するために何をすべきかといった思索に多くの時間を使うことができました。その結果、SREが実現すべきバリューのうち我々の組織としての実践だけで解決できそうな要素と、それ以外の要素としてオーナーシップが必要そうなことに気づくことができました。特に後者についてはまず私自身のチームからオーナーシップの獲得を目指した運営を行い、周囲から高い評価を得られた他、自発的に組織横断での活動を行うことができました。
SREのバリュー実現に向けては進捗ダメですと感じていましたが、棚卸しをしてみると色々な気づきがあったので、1年目としてはそこまで悪くないなと思い始めました。
ここまで駄文を読んでくださった方、ありがとうございました。何か得るものがあれば幸いです。
この記事が気に入ったらサポートをしてみませんか？