おわび この記事ははてなアドベントカレンダー2022年の12月12日分記事の予定でした。<em>21日ではありません</em>。12日です。アドカレ登録していたものの、プライベートの用事がいろいろ重なった結果すっかり忘れていました。すみませんすみません。
どうもどうも。id:ma2saka です。ブラックフライデーでは昇降デスクの足を買いました。フレキシースポットってやつです。昔ダイニングテーブルの天板だったでかい板を支えさせたらちょうど良くて快適になりました。
さて。今回はタイトル通り、非常に限定的な人向けの記事を書きます。
自分はこの十年くらい、中小規模のWebサービス開発運用をやってるいくつかの会社で、事業やインフラ部門のマネージャーをしています。それぞれの会社で、べつべつの事情があり、ジョブタイトルは似たようなものでもやってることや関心ごとはけっこう違います。不思議なものです。
※ 本記事ではマネージャーという言葉をいわゆるラインマネージャーの意味で使っています。
別の会社で、状況とかやってることがかなり違うのに、似たようなポジションで仕事をできているということは、なんかしら共通して適用可能な仕事のかたちがあるということだと思います。そこで、自分の普段を振り返って、こういうことを気をつけているな、ということをいくつか挙げてみたいと思います。これから中小企業のインフラ部門マネージャーをやってみようかな、と思う方*1は参考になるかもしれません。
Points
- ステークホルダーの仕事と利害を自分なりにモデル化しよう
- 仕事の枠を設定して、それをボスや周りと共有する
Tips
- 責任感だけでも仕事はできるけど知識とスキルは身を助ける
- ダメージが入る前に失敗判定をできるとスムーズです。暗中模索なときは特に。
- いつも同じ対策が出てくるようなら問題分析の仕方が失敗してる。頻出パターンは把握しておくこと。
- 現場で「やればいいことがわかっているが時間が割けない」という課題があったら、それはたぶん難題
ポイント1. ステークホルダーの仕事と利害を自分なりにモデル化しよう
ステークホルダー（利害関係者）とはここではあなたの仕事で関わる、影響を受けるかもしれない人々です。
インフラ部門とかやってると、開発チーム、事業チームを相手にすることが一番多いですが、実際にはそれ以外にもいろいろいます。
大きな現金の出入りが必要であれば経理とは密に対話するでしょうし*2、一年を超える期間の大きなコミット契約を締結するなら債務と一緒なのできちんと経営層と会話する必要があるでしょう。計画や決算に無視できないボリュームでインフラ費用が現れてくるなら経営企画系のメンバーとは付き合いがあるでしょう。場合によっては会計上の扱いを一緒に詰めていくことになるかもしれません。夜間、休日対応がどうしても発生するなら労務関係で人事とやりとりが発生します*3。採用もするでしょうしね。ベンダーとのもろもろの契約やりとりをしていくなら法務にはお世話になるでしょう。契約書とか請求書の保管って法律でいろいろ決まっていて、だいたい総務的な人がオペレーションを持っています。もちろんベンダー側のサポートチームや営業担当も重要な関係者です。セキュリティの話題はいつだって身近ですから、場合によっては会社全体の情報セキュリティポリシーや運用ルールをメンテナンスすることもあって情シスとかリスク管理部門と連携していくことになります。彼ら全てがあなたやあなたのチームと利害関係があります。重要なことを忘れていましたが、もし上司がいるのであれば、その上司も対象です。もちろん部下もです。つまり仕事で関わる人全員です。
彼らはどういうポジションで、どういう役割で普段仕事をしているのでしょうか。どういう理由であなたやあなたのチームと関わるのでしょうか。歴史的に関係性はどうなっているのか。あなたには何を期待するのでしょうか。何に困っているのか。どこからどういう力を受けて意思決定をするのか。...
そういう、周囲の環境を自分なりにモデル化してみます。そうすると、自分の仕事の外形がなんとなくわかってきます。
これはめちゃくちゃ大事だと思うんですけれども、「どうせ不十分な理解しかできないでしょ〜半年はROMの精神で」とか思って最初はうっちゃってしまうんですよね。はじめは持ってる情報がとにかく少ないので、かなり実態から離れた理解になってしまうと思います。それでもやってみると「こういう理解に従って自分はこう判断している」というロジックが常に立っていることはとても有益です。自分の行動に（自分に対しても）説明がつけられますから。
最初は正しいことよりも、登場人物をなるべく全員とらえようとすることと、経験を元にサクッとアップデートするのが肝要だと思います。事業や採用、時間経過、技術の変化などによってモデルががらりと変わります。更新していきましょう。
ポイント2. 仕事の枠を設定して、それをボスや周りと共有する
自分を取り巻く環境を「自分はこのように捉えている」「自分の仕事のかたちはこういう感じかな」という解釈を組み立てるだけでは不足です。会社組織における裁量は基本的に上位階層から委譲されたものです。マネージャーは部下に対しては会社の出先機関として機能する必要があるので、どこかのタイミングで、なんらかの形で裁量を公式に獲得する必要があります。*4
もちろん、ボスからお前の仕事はこれだぞと言われることもあるでしょうが、基本的にはそれに従っている範囲であっても、いったん立ち戻って、自分の仕事のかたちを自己定義して、それに承認を得るプロセスを踏むのは、マネージャー業の入り口であるように思います。「あなたの要求は承りました。では、私はこのようにやろうと思うけど、それでいいですか」と、あくまでも自分のオールを手放さないようにするべきです。*5
幸い、コミュニケーションのフォーマットはだいたい決まってます。毎回考える必要はありません。
こんな感じ。
- あなた（上司）の関心範囲はこうなっていますね。私はこのように理解しています。 - 私（またはチーム）はこういうことができるので、この期間については、このような動きをします。その先についてはこう考えています。 - この範囲についてはXXのチームがカバーすると認識しています。あってますか。 - 余裕があったら計画を適当に前倒ししていきますが、なにかやってほしいことありますか。その都度相談でもいいですよ。
仕事の枠、ミッションとか役割という言い方をしてもいいですね。たとえば、はてなという会社はコーポレートサイトの真ん中にインターネットがある生活をより良いものにと書いていて、社長のメッセージにも インターネットを良くしたい と書かれています。これがフレームです。そこで「じゃあはてなでやる新規事業考えてよ」と言われたら、発想はやっぱりインターネットをよくする方向へつながるような制約を受けます。インバウンド需要の復活を狙って地方の温泉宿を買い取ろうとかそういうことにはならないわけです。いや、やってもいいですけど、そこはインターネットと繋げる工夫をすると思うんですよ。開発合宿専門の温泉宿をやろうぜ、とかね。高速インターネットが引かれているけど周りには何もない、雪に閉ざされたスカンクワークス御用達の秘境の宿ね。いいじゃん。
インフラ部門の仕事の枠というのは、「インフラってなんですか」というところから導かれてくると思います*6。情報システム部門と違うところはなんですか。基盤チームとの境界線はどこにありますか。CTO室や標準化チームとは期待値重なりませんか。なぜ有志のインフラエンジニア連絡会議ではなく部署になっているのですか。「我々以外には誰も期待されていないことはなんですか」
まー、だいたいボスの認識もけっこう曖昧だったりしますよね。納得いく答えが言語化されて出てくるまで質問攻めにする必要はありませんし、綺麗にロジックが通っていても本音通りとは限りません。*7問いかけることが重要です。私はあなたが与えようとしているミッションに関心がありますと伝える。
ボスやいろんな人と会話して認識を揃えていきます。歴史的にやってきた仕事内容、手放せないルーティンワークや運用、現時点でわかっている課題感、今後会社としてやっていきたい方向性、自分をマネージャーに配置することでどういう変化・効果があると期待しているのか。そういうことを聞き出しながら、自分やチームがどういう役割を果たすとものごとがうまくいくのか、そういうストーリーを一緒に考えていきましょう。
このストーリーが結局、チームメンバーと具体の仕事を組み立てていく時の土台になります。ここまできたら、あとはそれに沿って試行錯誤をしていくだけです。間違っていたら直せばいい。
...と、いう進め方は、今だと思いつくのですが、当初は「とりあえずやったるかー」という勢いで生きてました。なんとか死ななかったけれど、見当違いの認識で進んでしまったり、合意がとれているという思い込みがあとからひっくり返っていろんなひとに迷惑をかけたり、ハシゴを外されたーと勝手に不満を持ったり、部署に向けられた期待値をチームにうまく展開できずに歪みを自分が処理し続けたり、という失敗がいろいろありました。
Tips
1. 責任感だけでも仕事はできるけど知識とスキルは身を助ける。隣接領域の人と会話できるようにしよう。
責任感とか労働量でカバーすることができる範囲というのは確実にあります。知識やスキルを場合によっては上回る有効性があることもあります。でも、様々なリスクとダメージがあるので、知識とスキルは後からでもいいいので身につけていくといいと思います。
ここでいう知識とスキルというのは「マネージャーとして」みたいなやつだけではなくて、インフラ部門の代表者としてのドメイン知識的なものです。そして、システム開発や運用に関わる技術だけではなく、法務、経理、会計、経営、営業、人事、労務... といった隣接部門の業務の都合をある程度理解したり、担当者と会話できるようになると、できることがだいぶ広がります。「タバコ吸わなくてもタバコ部屋に出入りするようにする」にも話題としては近いかもしれない。Slackとか最初は関係ない部署のチャンネルとかに入りまくるといいと思います。
周りの人はあなたに成果や外形的な振る舞いを要求することはあっても、あなたが成果を出すために必要な行動や仕込みをストレートに要求してくれることはありません。必要と言われたときにはいつも着手が一手遅いのです。情報を集めることが重要です。そのためには会話できるチャンネルをなるべく多く作りましょう。
「俺、エンジニアだしぃ...」とか言わずとにかく隣接領域は少しでもかじってボキャブラリを獲得しておくと便利です。知ったかぶりと思われないように注意は必要ですし、それこそ生兵法で怪我をするのは避けないといけません。気をつけましょう。はい。
2. ダメージが入る前に失敗判定をできるとスムーズです。暗中模索なときは特に。
これ最近すごく思うんですが、目標高めに設定して、失敗判定を早めにするようにして、再試行サイクルを小さくすると、ダメージが入らないんですよ。すごい。
自分にダメージが入ると防衛本能が働いて、リカバリーしようとしてしまう気がする。でもそのリカバリーって、目的に向かう動きじゃなかったりするんですよね。無理やり辻褄を合わせるみたいになりやすい。「やろうとしたことは間違っていなかったが...」みたいな線を引きたい欲求が生まれる。これは人によると思います。たぶん、一定数の人はこういう自分の癖について早い時期に気がついてコントロールできるようになってそう。そうでない人もいる。ああ、なんか失敗したな、そうしたらこう言い訳しないとな、認められるかな、こういう理屈だとどうだろうか、などと考えてしまいがちな人は、「ダメージが入るより早く理性的に失敗判定をする」を試してみてください。
自分にとって未知な部分が多い仕事はどうせ失敗だらけになるので、失敗判定して方向修正をすることを体に慣らしてしまいましょう。失敗判定を素早くするには、事前に失敗判定基準をおく必要がでてきます。これも癖になっていると、便利なことが多いです。
3. いつも同じ対策が出てくるようなら問題分析の仕方が失敗してる。頻出パターンは把握しておくこと。
よくチームのメンバーへこういうことを話す機会があります。自分も自分の傾向に気がつくまでけっこう時間がかかった。うまくいかない対策が導かれるパターンというのがあるわけです。
例としてあげると、「他の人に自発的に変化してもらう」が導出されてしまうことがあります。そして、自発的な変化を強制することはできないので、なんかふわっとしたアクションプランが出てくる。
- 意識が低いので問題が起こっています。なので、意識を高めます。
- つまらないトイル*8がどうしても対応が遅れて溜まりがちである、当事者意識がないからだ、当事者意識をもってもらおう。
- 新入社員が失敗を恐れているので、失敗を恐れないようにアドバイスしました。
- ドキュメントは更新しているのに読まないで古い手順で失敗する人がいる。必ず最新のドキュメントを確認するように啓蒙するぞ。
- 必要になる前にスキルを身につけるのはエンジニアとして当然だと思う。そうでない人がいるので、CTOからメッセージを発信してもらおう。
文化作りみたいな場面では、自然な変化を起こすための仕掛けをやっていったりしますが、少人数のチームで他人が自発的に変化することが有効な対策となる実際的な課題はあまりないでしょう。行動に影響を与える小道具を駆使して状況を誘導して、その副産物として意識の変化を期待するのがせいぜいだと思います。
これは人によるんですよね。他人に対する影響力が高い人、意図的にそれを行使できる人というのはいて、そういう人にとっては他者に変化をもたらすというオプションがあったりします。でもできないことの方が多いんじゃないかな。そして、できないんだったら、他人の内面の変化を必要とするアクションプランを導いて、その実行に悩むのは時間の無駄です。下手すると、他人が変わってくれないという地点で足を止めるのが癖になってしまったりします。これは無駄を通り越して危険だと思う。
自分が「こうすればいいのはわかるんだけど」というところまで考えて、いつもそこで止まってしまう頻出パターンがあるなら、把握してリフレームする手順をあらかじめ考えておくと効果的だと思います。
4. 現場で「やればいいことがわかっているが時間が割けない」という課題があったら、それはたぶん難題
ありとあらゆる場所で「ドキュメントをきちんと残したいがリリース優先でどうしても時間がとれてない」とか「これを人間がやっているのは無駄すぎるので自動化したいのだけど、改善業務に使える時間がない」という話を見聞きしますが、これは経験的に、ドキュメントを書くことも重要であると宣言して時間を確保するようにしてみたり、改善業務に時間を使ってくれと依頼しても解決しません。時間がとれないなら時間を使えばいいじゃん! とはいかず、もうちょっと問題は複雑なことが多いです。
この種の課題は、ミクロに見るとちょっとの時間が取れない問題なんですが、実際にはもうすでにイケてない状態になっている全体があって、その膨大なタスクの残量の存在感とか負債の増える速度の圧が、少しでも手の届く範囲で片付けようとする意識にストップをかけていることが多いと思ってます。8割の不便は2割の場所で発生していると思うので、よく触るところを集中的に手直ししていくことは効果絶対あると感じるのですが、このあたりは楽観論だという自覚はあるし、ドキュメントやツールを思いつきで増やすのが負債の増殖に直結しているのもわかるという。
ともあれ、時間が取れないのではなく、時間があってもやらないのはなぜかって課題が現れてくる。で、各自の、ドキュメントが必要だという意識であるとか業務効率化をしていく意欲の問題として捉えてしまうと、おおこれは内面の変化を必要とする頻出パターンではないか...。3.へ戻る。
おかしい。時間がないのでドキュメントが書けないって言われたので時間とったのに誰もちゃんと書いてないじゃん。…となってしまうのはわかります。顧客が本当に必要だったものゲームでも買って落ち着いてください。この混乱はただ「ちょっとの時間をチームが割けないことが原因である」という仮説が間違っていたに過ぎません。単に修正すればいいだけです。解決策がわからない複雑な問題への対処策が必要です。マネージャーやろうという人なのだから、そういうフレームは持っているはず。
なんだかんだでみんな優秀な人間です。彼らが「わかっているんだができない」のだから、マネージャーがちょっと時間使っていいよと宣言するだけで解決するわけがないのです。簡単そうに見える、効果的そうな問題が転がっていたら警戒しましょう。それは宝箱のように見えてミミック*9かもしれませんよ。
おわりに
ということで、ジャパニーズ中小企業のインフラ部門マネージャーをやっていて、最近ようやく言語化されてきた、普段明に暗に意識していることを書いてみました。一般的なソフトウェアアーキテクトのスキル、組織マネジメント、エンジニアリングマネージャのキャリアや位置付けについて書かれているようなことは、だいたい書籍や公開スライドとかで読めるので、もうちょっと土臭い話です。
過去の自分や、または不安を感じながらマネージャ業やったるかーという誰かの助けになるといいのだけど。むしろ不安にならないことを祈って。
12月11日は d-haruさんのWeb Speed Hackathon 2022 の解説と振り返り - d-haru’s blogで、13日は SlashNephy さんのRust で書いた型定義を様々な言語に変換できる Typeshare を試してみた - Avoid a voidです。どちらも力作だった。わいわい。
*1:「これから中小企業のインフラ部門マネージャーをやってみようかな」と思う方はぜひ連絡ください
*2:外貨調達のタイミングなどで円建てだと1割とか2割変動しちゃいますね。最近の為替の動きは本当に怖い。
*3:オンコール体制は待機なのか問題とかいろいろありますよね
*4:なお、ここではティール組織的な状況は念頭にありませんが、もしそうであると、他のメンバーに対して強制力を働かせる権限や裁量を獲得するプロセスがケースバイケースになって大変そうだなという想像だけがあります
*5:経験的に、自分の仕事に対するセルフコントロールを失っている時のマネージャー業はストレスが大変です。メンバーや同僚に「実は納得いってない」などと愚痴るのは自分の発言の力を喪失させるリスクが相当高いです。
*6:ここではインフラ部門という言い方をしているのでインフラという用語からスタートしています
*7:仕事柄、他人に説明をするのが多い人はその場でうまくストーリーを組み立てるちからに長けていますが、そのストーリーが嘘ではないとしても十分に本気の論でないことはあると思います
*8:Toil: GoogleのSRE概念とセットで世に広まったと思われる用語で、発展性はないが必要でやらなければいけない小さなタスク
*9:Mimic: 宝箱に擬態し、近づいてくる冒険者に襲いかかってくるモンスター。Wikipediaには姿を変化して擬態できるモンスター群の特定の一派を示す言葉なんじゃないかという説が載っていた。
