社内政治をリーンにやろうぜという話をしました

概要

某社の社内勉強会にて「エスカレを支える技術 - アジャイルな報連相と情報流通」という発表をしました。 炎上現場を生き抜いた権謀術数（というか土下座テクニック）を共有しました。

スライド

ざっくり内容

「既存の業務フロー」と「ステークホルダーコミュニケーション」を無駄なく結びつけようぜ、という話です。

• 偉い人に働きかけることで、必要な資源をスムーズに得ることができるぞ！
• 報連相をより効果的にするには、リーン（トヨタ方式）が参考になるぞ！
• 今回は「チャット」「レトロスペクティブ」「人事評価シート」「ちょっとした雑談」を利用したぞ！

1営業日あたり2件の障害が発生した中で編み出した技法たちになります。

チャット

ノイズを減らす＆気軽に投稿する、を両立するために無駄を削減する。

• 上位レイヤの前にまずは現場チームで課題意識の共有・解決を試みる。
  • #dev_times チャンネル：技術・仕様面でのハマリどころ。
  • #kpt チャンネル：チーム運営でのちょっとしたご相談。
• 上位メンバとの1on1で話すことは事前に #times_{myname} チャンネルに投稿する。
  • 現場メンバから「これも忘れずに会話してくれ」リマインドが来たり。
  • 上位メンバが事前に目を通してスムーズに会話できる。

レトロスペクティブ（振り返り）

いろんな会議で同じ話をするのは無駄なので、情報流通フローを整理する。

• メンバーは思い立ったタイミングで#kptチャンネルに上げる。
• チームの振り返り会で#kptを見ながら大事なものをチョイス。
  • チーム内で解決できるならTryに繋げる。
  • チーム内で解決できないものは分ける。
• マネジメント会議で、KPTのサマリーを上位層に伝える。、
  • チーム内で解決できない課題を受け渡す。

人事評価シート

目先の課題とは別に、攻めるための目標・進捗を管理して、なおかつ担当者は取り替え可能な状態にする。

• 前提：人事評価シートの目標設定（xxxまでにxxxを達成するのだ！）をもとに、人事面談で攻めの目標についての認識合わせがなされる。
• 課題：マネージャーとメンバーたちの1対nの関係になりがち → 各メンバーが受け持っている目標が開示されない → チームで進捗確認できない → 報連相が個人に任されて漏れが生じる → 色々こじれがち。
• 打ち手：メンバー全員に同じ目標を設定する → 各目標の進捗管理を週次ミーティングで実施する → 進捗を妨げる問題があればチームとして検知 → ミーティング同席の上位陣にそのままご相談。

ちょっとした雑談

毎日の終業時刻に偉い人を10分弱ほど捕まえて、小さなバッチサイズで報連相を行う。

• 「もうダメっすねぇ」→「xxxに困っているんですよ」→「xxxがあれば助かるのになぁ（チラッ」
• 相談の中で課題が整理される。
• 必要であればサポートを受ける。

名付けてデイリーエスカレ。

言いたかったこと

エッセンスとしては、「開発・運用の現場」から自然と「経営層」に情報を流せるように仕組みを作りましょう、ということを伝えたいです。

でないと、ある日突然偉い人から「xxはどうなっているのか」と言われて、現場は「な、なんだってーーー！」と混乱したり、ある日突然現場が「xxで困っています」と伝えて、偉い人は「な、なんだってーーー！」と混乱したり、とにかく碌なことにならないです。

しかるべき情報共有をするだけで、あっという間に解決できるような問題は山ほどあります。 だったら、わざわざ未解決のまま放置する理由もないでしょう。

情報の「流し方」の話になるので、滝（ウォーターフォール）のように一気にドバーッと流すよりも、無駄なく（リーンに）流した方がよかろう、という話です。

当たり前だけど難しいこと

悪い言い方をすると、ただの社内政治（の第一歩）にすぎません。 お粗末な言い方をすると「報連相をしっかりやりましょう」という話です。 また、制度・文化・コンテキストに強く依存するので、プラクティスは組織によって変わるはずです。

ただ、このあたり、ビジネスとシステムを繋ぐ立場の人なら、似たような問題意識を持っているのではないかと思っています。CTO、技術マネージャー、開発リーダー、プロジェクトマネージャーなど、呼び方は多々あれど。

特に、組織がスケールして三階層を超えたら、確実にこの手の問題が浮上します。トップがメンバー全員ときめ細やかにコミュニケーションできなくなるので、情報流通をきちんと設計しないと阿鼻叫喚です。

各プラクティスの考案タイミング

上記の取り組みは、最初からスマートに仕組み化できていたわけではありません。 あとから俯瞰したらこうなっていた、というだけです。 仮に、最初からやろうとしても、関係者には必要性が伝わらず、浸透しないと思います。

実際には、目の前の課題をチームで1つ1つ取り除いていただけです。 チーム内では解決できない問題も山ほどあるので、必然的に上位レイヤーに働きかけて、間接的に解決することになりました。 その中で、プロセスに無駄があれば地道に取り除いていき、結果的にこれらのプラクティスに辿り着きました。

大事なのは、可視化（透明性）を担保した上で、課題発見（検査）と課題解決（適応）を繰り返すことだと思っています。 結局はDevOpsというかスクラムというかアジャイルというかリーン的な話に繋がるのかなと。

あえて言わなかったこと

あまりLT受けする話ではなかった（というか完全に社畜養成講座になりそうだった）ので、あえて言わなかったのが後工程の話です。

階層化された大規模組織だと、エスカレ後に「ポケットの内側」と「ポケットの外側」で、次の行動が変わると解釈しています。

追加予算の獲得や他部署の協力が必要な場合だと、ステークホルダーを説得する必要があるのです。 説得ストーリーを描き、エビデンスを集めて、軽くジャブを打って反応を見て、といった営業チックな活動になります。 ここは現場と偉い人が力を合わせると比較的スムーズに進むはずです。

ただ、最初から細かい数字やエビデンスまで抑える必要はないかなと思っています。 確保済みの予算など「ポケットの内側」で済む場合は、それこそ臨機応変に差配するためのポケットだと思うので、規模感だけ把握すれば問題ないはずです。

なお、組織の状況がどうなっているのか（特に予算と人員）を把握しておくと、何かとスムーズなのかなとは思います。 これも順番があって、こまめな報連相・サポート需給を通して上位レイヤーと信頼関係を構築することで、そのうち情報が開示される機会が巡ってくる、というのが妥当でしょうか。

まとめ

顧客への価値提供を主要な企業活動と捉えると、こうした社内の情報流通は本質的な部分ではありません。 だからこそ、無駄なく話を片付けるために、型化が大事なのかなと思っています。 過剰にこだわってしまうようだと本末転倒ですが、完全無視はもったいないです。

上手いことやっていきましょう。

リーン開発の本質