bon now

この記事はPharmaX Advent Calendar 2022 の12日目の記事でQiita、こっちでは余談を少し追記している。

プロダクトを作るうえでシステム開発のみではなく「ティール組織」や「ホラクラシー組織」「コンウェイの法則/逆コンウェイの法則」など、エンジニアリング組織やチームにフォーカスのあたる場面が増えてきた。そして組織におけるリーダーシップの在り方についても「サーヴァントリーダーシップ」とか「フォロワーシップ」とか「メンタリング」「コーチング」など、メンバーをリードしたり支援したりする仕組みについても認知度が上がってきている気がしている。 僕自身もマネージャーと言う役割を担うようになってからは、割と多くの組織論についてかいつまんで学んできた。論文を読んだわけではないので断片的な知識と実践経験しかないのではあるが、数年前金井 壽宏氏のリーダーシップ入門という本を近所の古本屋で見つけて買っていたのを思い出し改めて読み直した。数年の間リーダーシップについて実務を通して考えるようになったからか、中身が以前より理解できるようになっていたので、今回学んだことを書き残しておこうと思ったのがこの記事。

まとめ

サクッと書籍の内容と上述してきた内容をまとめると以下のとおり。

• リーダーシップ理論の多くは2つの軸「課題軸」と「人間軸」で語れる
• 課題軸は問題や課題、目標を解決するための行動指針や方針、方向性を示すなど
• 人間軸は人や集団をどう扱うか、やる気向上や信頼関係の構築など
• まずはPM理論をベースに考えてみるとよさそう
• 自分の持っているリーダーシップ像を言語化しよう
• 言語化できたリーダーシップを語れるようになろう
• 実践を通して再現性や判断軸を作りだし、リーダーシップを教育可能な状態にしていこう

基本のPM理論

書籍で述べられているように、すべてのリーダーシップ論の基本となる（であろう）「PM理論」について概要を記載する。

PM理論は日本の三隅二不二（みすみじゅうじ）氏が1966年に提唱した理論である。 PMのPは「Performance（目標達成機能）」、Mは「Maintenance（集団維持機能）」のこと。リーダーシップはこの2つで表すことができるというのが理論の根幹……である。

これを図にするとこんな感じになる。

PとMをそれぞれ大文字、小文字で表しその組み合わせが大きく4つ。
Pmとは目的達成力は高いが、集団での行動力が低いという一匹狼タイプ。個人的には強強エンジニアの一部はここにカテゴライズされる気がする。

PMとは目的達成力も集団を維持する力も高い人。最も理想と呼べそうなリーダーたちが巣食う場所。スラムダンクの仙道はここに位置するかもしれない。

pmとは目的達成力も集団を維持する力も低い人。低くなってしまった理由は色々あるだろうが、本来のパフォーマンスが出せていないという点では同じ。

pMとは目的達成力は低いが集団を維持する力が高い人。人に尊敬されるほど優しく仕事もある程度できるが、如何せんその人が様々なタスクを抱えてボトルネック化してしまい、全体の目標達成が遠のくという悲しい状況も多分ここ。

他のリーダーシップもPM理論で言い換え可能

先の著書については、基本的にPM理論で他のリーダーシップ論も説明できるということが総括だと思う。
例えば「サーバントリーダーシップ」や「フォロワーシップ」という言葉を聞いたことがある人もいるかもしれない。

サーバントリーダーシップはTYPE-MOON作品のFate（やその系列のゲーム）をやったり観たりしたことのある人ならかなり想像しやすいと思う。要は主たるものに仕える従者である。サーバントリーダーシップはリーダーシップの1つのあり方として、主（メンバー）のために献身的にサポートするのがサーバントの役目であり、その行為によって主の目的遂行が達成できたか否かがリーダーシップの結果となる。
ロバート・グリーンリーフ氏が1970年に提唱した理論だ。

一方フォロワーシップとは1992年にロバート・ケリー氏が論文で用いた言葉が理論になったものである。フォロワーシップもPM理論と同じように四象限に別れるのだが、PとMではなく「貢献力」と「批判力」である点がPM理論と異なる。貢献力は読んでそのままサーバントリーダーシップの行為に等しいと言えそうだ。批判力は自分のエゴにより、主体性を持って事を為しているかどうかを指す。

小難しい感じがするこの2つの理論も、それぞれの専門性ありそうな単語を身近な言葉に置き換えてみるとわかりやすい（書籍内でもそういうワーキングが存在する）
例えばサーバントリーダーシップの特性の1つである「献身的」を別の言葉に置き換えると、「優しさ」と言えそうだ。同じようにフォロワーシップの「貢献力」は「励まし上手」と言ってもよいかもしれない。 こんな感じでPM理論のPとMも置き換えると、Pは「やり遂げるパワー」とかMは「引きつけ力」とかでも良さそうだ。
ゲームの三国志みたいに「魅力」「知力」「武力」などをいい感じにPMに分配してもよさそう。ドラクエのようなRPGのパラメータ（ちから、かしこさ、すばやさなど）でもよいだろう。

こんな感じで言葉を置き換えていくとあら不思議、実はここまであげた3つの理論の特性や概念は、自分たちの普段使う言葉で置き換え可能であり、かつそれらを組みわせることで四象限ないしは構造化された評価軸を作り出すことができる……というわけである。

ちなみに書籍内ではPとMの2軸を基本軸とし、それぞれ「課題軸」「人間軸」と捉えている。

リーダーシップを形作ろう

多くのエンジニアリング組織ではおそらくアジャイルやウォーターフォールを取り入れたプロジェクトのプロセスだったり組織構成だったりを検討したうえで業務に従事しているだろう。その中にはアジャイルソフトウェア開発宣言を読んだり、PMBOKを読んだり、CSMの資格を取得したりしている人もいるだろう。
だが、僕の知ったところでは、リーダーシップについては資格や書籍を読んで実践しているという人はそんなにいないのではないかなと思っている。

書籍というよりは、人生の中で出会った「すごい人」を見習ったり、歴史上の偉人をリーダーシップの鑑として真似したりというパターンが多いような気もする。実際僕も強いリーダーシップを語るとき、漫画やゲーム、歴史を題材にする（先述のとおり）。
そういう意味では、リーダーシップとは自身が小さい頃から触れ合ってきた理論の1つであり、急に身につくというより自身の価値観や倫理観などから導かれる場合も多そうだ。そのためまずは自分の持っているリーダーシップ像を言語化しリーダーシップとは……を語れるようになれば実践可能な状態になる。
そして、自分の考えるリーダーシップ像を明確にできれば、他の人の考えるリーダーシップ像と比較したり議論したりすることができるだろう。（この、リーダーシップを語れる状態になることをTPOV（Teachable Point of View)と呼ぶらしい）

余談

型は所詮型でありそれ以上ではない

Twitterのタイムラインで、妄信的にスクラムを導入するのが正しいのかどうかとか、スクラムマスターみたいなのが往々にして斜めに構えてるせいで型ばっかり押し付けて理想論を並べた挙げ句現場にそぐわない意見や批評をするから結局上手くチームがワークしてないんじゃね？みたいなのを見かけた。
ちょうどこの話はここで述べてるリーダーシップにも関わるよなーと思っていて、スクラムもアジャイルも（言い方はあれだが）所詮「型」である。String型にbool型を入れようとするとエラーになるように、型定義したときに自分たちのチームで上手くいくこと・いかないこと周りを整理するための仕組み作りをしてくれるだけである。
大事なのは型からはみ出したことが「なぜ起きたのか」とか「どうすればよかったのか」とかの問題や課題・特徴みたいなのを、自分たちの組織・チームにフィットさせるにはどうすればよかったのかチームで考えることだと僕は思っている。

プログラミングでもString型が良いのか、そもそもオブジェクトモデル（エンティティ）を型定義したほうがよいのかなど色々と議論するであろう。1つのメソッド、クラスについても100％そのままの形でその後もメンテナンスされ続けるという場面は少ない。大体は誰かが「このレガシーコードをなんとかしなければ」と怒りと悲しみと楽しさの入り混じった感情で書き直すというのが通常だろう。いずれにせよ型以上に議論すべきことは大量にある。いわんや組織やプロダクト開発をやである。

つまり計画と実行と評価が大事

PDCA、あるいはOODAと言われるプロセス観点のフレームワークがあるが、スクラムやアジャイルにもこの概念が存在する。
スクラムの場合は「スプリントプランニング（計画）」や「スプリントレビュー（検証・レビュー）」「スプリントレトロスペクティブ（評価）」などだ。特に課題になりがちなのが、PoCやプロダクトのスケジュールなどで、いつ評価（振り返り）を実施するかだ。

個人的にはプロジェクトマネジメントしていると週次や月次での進捗会とか、PoCでも評価期間とか存在するので、それに合わせる形で評価をしたほうがいいんじゃないかなと思う。スクラムだとSprintという区切りで振り返りを実施するのでそれを真面目にやっていればよいはずだ。だが、まれに「振り返り全然やってない」というスクラム開発をやってるチームの話を聞くことがある。日々タスクをこなすだけなのであれば、それはスクラムではないような気がするので、まずは型を律儀にやってみるほうが良いと思われる。
そのうえで、自分たちのチーム開発にそぐわない部分は変えてみてまた評価→戻す・適用維持みたいにやっていけばよい。

ということで終わり。