マネジメントナレッジ殴り書き
プレイヤーからリーダーをはじめてリーダーシップやマネジメントというものをやってみて、そろそろ2年になる。
せっかくだし、この経験知をアウトプットしたいと思う。
どこかのカンファレンスで一介のpythonのプログラマーだった自分がレコメンドチーム、データサイエンティストチーム、Railsチームと全く違う職能でチームを組成したリーダーシップノウハウを紹介したい
— いりす (@irisuinwl) 2024年10月31日
X (Twitter) にこんなことを書いたが、いざ自分の脳内を形式知にするのは中々難しいことに気付いた。
この記事では、自分の経験から見えてきた断片的な考えをまとめて、自分が認識している範囲でのマネジメントのあり方を書きたいと思う。
結局のところマネジメントは実践である。マネジメントの本質は「知ること」ではなくて「行うこと」 である。マネジメントの試金石は論理ではなくて成果である。マネジメントの唯一の権威は業績である。 P.F ドラッカー マネジメント―課題、責任、実践
言いたいことはドラッカーが全部書いてそうな感じあるので読んでくださいといいたいところだが、自分の言葉で語るのに一定意味はあるので書く。
マネジメントとは何か、何をするのか
マネジメントとは、組織の成果を最大化するための実行全てだと考えている。
組織をして高度の成果をあげさせることが、自由と尊厳を守る唯一の方策である。組織に成果を上げさせるものがマネジメントであり、マネジャーの力である。成果をあげる責任あるマネジメントこそが全体主義に代わるものであり、われわれを全体主義から守る唯一の手立てである。 マネジメントとは――ドラッカーの定義・考え方や経営管理論の解説と、役立つスキル・考え方の紹介 - 『日本の人事部』
そして、よく比較に出るリーダーシップとは、方針を定め推進することであると考えている。
リーダーシップとは、組織の使命を考え抜き、それを目に見える形で明確に確立することである。リーダーとは目標を定め、優先順位を決め、基準を定め、それを維持する者である TUNAG(ツナグ) | 組織を良くする組織改善クラウドサービス
これは、リーダーなった初期に記事にしたが、自分の思考の軸となっている。
自分の中では、マネジメントやリーダーシップとは、組織の成果を最大化するために人間の集団という複雑システムが持続的に効果を生む行動ができるための構造（組織の中で成果を生むために人間が行動する機序）を作っていく、働きかけていくことだと考えている。
プログラミングを時間積分したものがソフトウェアエンジニアリング*1 という言葉があるが、マネジメントやらリーダーシップの目的とは、成果を人間と時間で積分したものと言えるのではないだろうか。
そして、成果を高めるための具体行動として組織編制や目標設定や1on1やプロジェクトイベントなどがあるが、そういったツールを使うことが本質ではなく、どういう効果と構造寄与を期待して実行するのかが重要である。
自分の場合、エンジニアリング組織のマネジメントに介入することが多く、エンジニアリングマネジメントという領域になるだろう。 さらに、昨今新しい概念としてプロダクトマネジメントなどがあるが、これらの概念はマネジメントの基礎概念を継承し、重複は多く感じており、今回はマネジメントという言葉を選んだ。
まあ、変わらんだろというのが正直なところで、なんとかマネジメントをツール群だと思い、基礎となるマネジメントの考えを疎かにすることは片手落ちであるのでスコープは曖昧にしている。
マネジメントは何をすればいいのか
マネージャー、リーダーの仕事というと組織を編成して、メンバーと1on1をして、チームビルディングをして、メンバーの評価をして、プロジェクトを推進するためにスクラムイベントとかをやって……ということを想像する。
前節に書いた通り、それらの具体行動は本質的ではない
本に書いていることの真似だけしていればマネジメントをしているというのは、ソフトウェア開発でいうならば
- コードをいっぱい書いているのでソフトウェアエンジニアリングです（何が工学（エンジニアリング）なんですか？）
- 処理のレイテンシ閾値をとりあえず設定して監視していて SLI と呼んでいます！ ユーザーストーリーや便益は考えていません！（サービスのレベルって言えるんですか？）
- 4keys計ってますいっぱいリリースしてます生産性高いです！ 売上やKPIへの接続は見てません（何を生産しているんですか？ ）
といったことと同様の錯覚である（自分は全部の失敗を踏みました）。 守破離という言葉があるように、まずは真似してみるのは一歩として良いが、やってみて自分が直面した環境での気づきを得て調整なく真似するのみは上手くいかない。
もちろん、世に溢れる知識を参照すると、ある程度の行動の型、プロセスフレームワークというものは存在するし、マネジメントの書籍もその行動の分類と方法に関する言及が多い。そして、それらの行動がプラクティスとして現れているのは事実であろう。
じゃあ、どうすればマネジメントの目的である組織の成果最大化をできるのだろうか。つまり、必勝法あるんですか？
まあ、もうこれは「銀の弾丸はない」だ。
考えてみれば、様々なパーソナリティや思考を持つ人間が集まり、無限の幅をもった目的をもって行動するのだから、銀の弾丸と同じく本質的困難さを有し、マネジメントの定義は出来ないし、そこで絶対に上手くいく銀の弾丸はないのだ。 （全員の思想や行動を統一あるいは平均化して特定の状況に絞り込むということをすればあるかもしれないが汎用的ではない）
一方で「銀の弾丸はない」の考え方がヒントとなるのではないかなと考える。
我々が直面している困難さの解像度をあげる（何が難しさを生んでいるのか）、何が起きてどういった特性があるのか（複雑性、順応性、変更可能性、不可視性みたいなこと）といった分析を行い、そして、そこから打ち手を打っていくのが一つの指針ではないか。
より広くいってしまえば「見ろ」（組織はどういった状況で、どういう動きをするのか）、「考えろ」（何が変数となりどういう構造をもってして組織の動きを生んでいるのか）、「行動しろ」、「結果どうなったかを振り返れ」である訳で、ありきたりなのだが……（それこそG.PolyaのHow to Solve It*2 のプロセスである）
一方、この認知を持てば、この節の最初に書いたツール群は意味を成すと考えられる。
つまり、ツール群は「行動」であるわけだが、どういう状況を見て、今のあり方を考えて、効果を生み出す期待を設計した結果の行動であって、その繋がりを明らかにすべきでツールは輝く。
何のために目標を作るんですか？ 何のために会話をするんですか？ 何のためにチームビルディングするんですか？ 常に自分の中のもう一人の自分に「それ何のためにやってるんですか？」を問いかける人格を飼おう。
更にヒントとして考えているスコープ自体が間違っている、認知バイアスにまみれているということもあるので「今考えていることって本当なんですか？ 結果として意味あることにつながりますか？」と問いかける人格を持っても良い。
自分はこの見ること、考えることを重視しており、考え方のとっかかりを以前記事にした。
（この記事、数学、デザイン、ソフトウェア工学からつまみ食いしていて分かりづらいよなぁと反省している。こういったつまみ食いで独自の暗黙知を形成しているから形式知にするのがしんどいんだよな～）
ここで書いていて、マネジメントとソフトウェア工学って変わりないんじゃないの？ ということや、更に言えばナレッジワーカーの基本的な振る舞いじゃない？ というのを思った（日頃から頭に過ることなんだけど）。
これはソフトウェア工学がそもそもソフトウェアを作るのが人間というマネジメントの共通要素なのと、ナレッジワーカーの基本的な振る舞いはソフトスキルが重要な要素であることとマネジメント的振る舞いやリーダーシップは誰でも発揮して良いという考えが背景にあるんだろうなと考えている。
まあ、あとは経営学って境界の学問っていうし、エンジニアリングマネジメントってソフトウェア工学ディシプリンの側面を持ったマネジメント理論ってことじゃないですか、という捉え方をすればよいのではなかろうか
マネジメントの変数
マネジメント的働きかけをしてみると、非常に Kubernetes をはじめとしてコンテナオーケストレーションシステムの構築と運用している気持ちになる。（別にコンテナオーケストレーションでなくても複数のコンポーネントによるサービス作りであれば同様なんだが、自分はKubernetesが馴染み深い）
ソフトウェアの期待挙動を考え、サービスの通信を考え、役割やリソースを設定する構成ファイルを書き、サービスの挙動を定めるためにコーディングをし、どのように動いているかのモニタリングを運用していくことを人間に対して行っているような気持ちになる。
組織が効果を生むための構造を理解しつつ、作用するために、人間同士の情報の流れを設計しつつチーム組成や場を作ったり、人間の行動に働きかけるために目的設計やナッジしたり、人々と話ながら情報を知り組織の現状を理解する。
こういった人間と情報と行動におけるマネジメント構造を捉えたもので、自分が特に納得しているものとして ミンツバーグのマネジメントモデル がある。
これはマネジメントを行う対象として、情報の次元、人間の次元、行動の次元があることを示している。どれかに作用すればいいのではなく、全てをバランスよく作用しなければならないことをいっている。
- 情報だけマネジメントしているのは組織をころころ変えるだけで混乱を招くだけの人になってしまう
- 人間だけマネジメントしているのはただ1on1しているだけや、組織の外で良いことだけを宣伝する広報役になってしまう
- 行動だけマネジメントしているのはただのマイクロマネージャーや働きまくる現場のボスになってしまう
組織に対してこの全ての変数に作用してで初めてマネジメントとなる。
このモデルを考えるとマネジメントに関する様相がかなりクリアに見えてくる。
たとえば、プレイングマネージャーはアンチパターンなのか？ という問いは、成果を最大化するであれば行動の次元に作用すれば良く、全ての次元に作用してキャパシティを越えてしまう（次元をバランスできないマネジメント）のは悪い影響を及ぼすということであろう。
ミンツバーグは関連してマイクロマネージャーはよくないが（組織の方針や構造だけを決める仕事しかしない）マクロマネージャーは更によくないと言っている。結局これも組織の方針だけ決めて行動につなげないで丸投げしているだけでマネジメントモデルの一部の次元しか作用しないで全体のバランスを欠くということを言いたいのだと思っている。
モデルはモデルでしかない；「だからどうすんの？」
納得感の高い話ではあるが、モデルはモデルでしかないことを認識すべきである。
現象と実態が目の前にあり、働きかける人間や人間関係や組織や情報がそこにある。
現実が為している構造に目を向けて、自分が行動をすることで何に作用し、どういう変化を起こし（それこそ構造自体を変化させることもある）、結果として良くするのか。
そのヒントとしてモデルを使うべきで、更に言えば、世の中に数ある（それこそミンツバーグのものでなくてよい）モデルや理論というものを継承して、実態の現象に合わせてチューニングしてもよい。
行動し、結果を生んでこそのモデルや理論を使うということだ。
モデルに当てはめて「こうなるんですよね」って言うだけでは「本に書いていることの真似だけしていればマネジメントをしている」と錯覚することと何も変わりない。
我々が仕事をするモデル
情報、人間、実行というが、結局行動し成果を残すのは人間だ。人間が行動する指針を持っておき共通言語として目線を合わせるのは意味があると思っている。
自分が良く使う成果を生み出す行動モデルを示す。これはナレッジワーカーであれば共通するモデルだと考えている。
どんな職能・役割であろうが同じ目線で語り合えるものであるし、マネジメント的働きかけが作用するものだと考えている。
このモデルの基本的な考えは、ソフトウェア開発にも言えることだと考えている。
代表的なソフトウェア開発プロセスとして要求定義・要件定義 -> ソフトウェア設計 -> 実装・構築 -> テスト -> リリース -> 運用・監視・効果検証があるが
- 要求定義・要件定義: やりたいことを作る上で必要なこと何を満たすべきかをデザインする
- こういう状況だからこういう状態を目指してこういうことを作ってこういうのができると良いんですよね、という期待と目的をデザインしている
- 設計: やりたいことに対して、こういうソフトウェアを構築したい、こういう振る舞いを期待したいというデザイン
- 実装・構築: 期待と目的に対して生成物を作り上げる行動
- テスト: 生成物がデザインされた期待された振る舞いを満たしているのかという効果検証
- 運用・監視・効果検証: 成果物の全体が想定している期待・目的を達成しているのかを成果を得られているのか検証し、得られてなかったらどのように手を打つのかをフィードバックする
これもあくまでモデルなので成果を残すために実状に合わせる必要がある。ソフトウェアエンジニアリングでいえば機能要件・非機能要件に期待を分解したりイテレーションを細かくしてフィードバックをもらったりといった合ったやり方を模索するのがそれにあたるだろう。
易きに流れず困難に立ち向かう
人間に向き合うのは非常にしんどい。しかし、向き合うことを諦めたら成長限界を迎えてしまう。
これ言った方が良いけどやめとくかーみたいなことを繰り返して後で大変になったことは経験はよくあるだろう（まあ何でもかんでも困難に向き合えば上手くいくわけではないのでバランスもあるだろう）
そこに挑戦と成長が生まれる。易きに流れてしまい日々やることに追われて、やることをこなすだけになってしまうと停滞を迎える。
めんどくせえなって自分とやった方が良いよなって自分の両方を飼い、客観視して行動しよう。
向き合ってみた結果、大した話ではなかったかもしれないが、仮説検証と同様に検証したことに意味がある。
体調管理
メンタルや体調管理の話。
ここに書きました:
自分と向き合い、自分自身をアセスメントする。認知行動療法のテクニックを使い自己理解を深めることをした。
自分のバイアスを自覚することが効果的だと感じている。
本当に限界の時には仕事のテクニックとしては全てを止めるということが効果的だった。
全ての会議を消し、全てのチケットからアサインを外し、自分が真に価値を生む最小限の行動は何かを向き合うことをした。（これはかなりパワープレイなのでおすすめはしません）
自分は健康関連で限界を経験しましたが、リカバリーを模索したりと、学びはありました（人体実験するマッドサイエンティスト？） が、この経験を何回もやるべき話ではない。
成果の時間と空間の積分をマネジメントと捉えるのであれば、
自分が疲弊することで被積分関数を0に漸近するような関数を掛けたり、ある点までは1である点から0になるような関数を掛けたりする結果になるのは避けるよう意識するのは大切である。
ソフトウェアプロジェクトマネジメント
ここに事例を書きました:
大事なのは、何のために何を作るのかを明確にすることと、実現にあたってのトレードオフの解消、実現に必要十分なアーキテクチャ選定です。
あとは、よくあるプロジェクトマネジメントツール（例えばカンバンなど）やプロセスは添えるだけです。
*1:
One key insight we share in this book is that software engineering can be thought of as “programming integrated over time.” What practices can we introduce to our code to make it sustainable—able to react to necessary change—over its life cycle, from conception to introduction to maintenance to deprecation? from: Googleのソフトウェアエンジニアリング Software Engineering at Google
*2:G.ポリヤ 「いかにして問題を解くのか」
ヨビノリたくみの解説動画が分かりやすい
