感想 — ゲームから学ぶマネジメント

https://akisute.com/2020/11/blog-post.html

注：本文の段落構成は原文とおおむね同じだが、原文の全訳ではなく僕自身の主観的な見解も付け加えている。正確な原文を読みたい場合は、原文リンクを参照してほしい。

この記事の原文は日本語で書かれているが、仕事の上で僕自身とても共感でき、学ぶべき点も多かったため、ここで簡単に引用しつつ僕自身の感想をまとめることにした。

筆者は36歳で、もともとエンジニアだったがマネジメント職を引き受けた。理由は歳をとったこと、そして技術に対する情熱が次第に薄れてきたこと、さらに上司から「やってみなよ」と言われ給料も上がったため、流れでマネジメント職に就いたという。

筆者は「だが問題がある。僕は人間が一番嫌いだ。できることなら一人がいい。平穏にやっていたのに、なぜ人をマネジメントしなければならないのか？」と面白おかしく述べている。どうせ業績責任もないし、給料ももらえるのだから、ちゃんとやろうというわけだ。

ここで僕が感じたのは、すべてのエンジニアが技術に情熱を持っているとは限らないが、だからといって仕事をうまくこなせないわけではないということだ。技術への情熱と仕事をうまくやることは、別物だと言える。筆者のように、お金をもらっているからこそきちんと仕事をこなすという人間も確実に存在する。

マネジメント職の最も基本的な要素は、筆者が述べているように実はとてもシンプルで、能力面と思考面に分かれる。能力面は以下の通りだ：

• 理性的・論理的に思考できること（平均レベルに達していること）
• 人前でまともに話せること
• 照れたり、躊躇したり、慌てふためいたりしないこと

思考面は以下の通りだ：

• 目標の達成を楽しいと感じられること
• エンジニアの喜怒哀楽を心の底から実感・理解できること
• 自分を「ボス」ではなく「リーダー」だと捉えること
• 自分はチームの中で最も価値のない人間であると自覚すること。ここは筆者もかなりネガティブに語っているため割り引いて考える必要があるかもしれないが、筆者はマネジメント職の生産価値はゼロであり、他のメンバーを奴隷のようにこき使っているだけにすぎないと捉えている。したがって、チームの成功はメンバー全員のおかげであり、失敗した場合は自分自身の無能と怠慢によるものだということになる。

基本的にマネジメント職は、人を好きになることも嫌いになることも求めておらず、上記の条件さえ満たしていればいい。だから筆者は「誰がやってもいい仕事だ」と考えているが、僕の考えでは、ここまで徹底できる管理者は実際にはごく少数のはずだ。多くの管理者は部下が自分より優秀になるのを見たくないため、自分の立場を守るためにあらゆる手段で邪魔をしたり、手柄をすべて独り占めしたりする。正直なところ、まともな管理者を務めるのはエンジニアをやるよりも難しいのではないかと思う。

ゲームと定石

筆者は続けて、マネジメントはゲームのようなものであり、チームで協力して敵を倒すことと似たような理屈だと述べている。この後にも筆者が考えるさまざまな要素が登場するので、順を追って見ていく。

定石

囲碁を打つときには、通常参考になる「定石」が存在する。定石とは先人たちが発見し受け継いできた特定の手順のことで、例えば囲碁の定石は一連の手順を定義し、黒白双方が互角の展開になるようになっている。定石通りに打たなくても構わないが、相手に優位を取られやすくなる。

筆者も述べているが、『エイジ オブ エンパイア』ではショートカットキー「HCCC」を使うことで素早く町の人を生産できる。わずか数秒の差だが、相手より早く領主や城主の時代に進化できれば、それだけでアドバンテージを得られる。

つまりマネジメント職においても、熟知しておくべき定石がいくつか存在する。幸いなことに、ソフトウェア開発の領域では多くのアジャイル開発などの方法論や、参考になる名著（『人月の神話』『フェニックスプロジェクト』『エンジニアの知的生産術』『Joel on Software』など）が生み出されてきた。

経験も一部を占めるが、定石から学ぶことで無駄な遠回りを減らすことができる。

マネジメントにおける「パラメータ」

筆者は以下の3つを挙げている：

1. やる気（モラル）
2. 尊敬（リスペクト）
3. 発言力

やる気は非常に重要な指標の一つだ。なぜなら人間はやる気を失うと、死にはしないものの、何の生産性も発揮できなくなるからだ。僕としては、やる気を満たすことは極めて難しく、採用段階から手を打つ必要があるのではないかと思っている。エンジニアは誰もが自分がやりたいプロジェクトや触りたい技術を持っており、それらすべてを同時に満たすことはほぼ不可能だからだ。

尊敬も重要な指標の一つである。マネジメントはゲームの世界とは異なり、右クリックを押せばキャラクターがそこへ勝手に歩いていくわけではない。指示通りに動いてくれるかどうかは、依頼内容と、その人があなたにどれだけの尊敬を抱いているかによって決まる。

つまり、ある日メンバーBに対して納期が非常に厳しいプロジェクトのために残業を依頼した場合、彼がどれだけ応じてくれるかは、あなたへの尊敬度合いによるのだ。業務内容の難易度に応じて、必要とされる「尊敬値」も異なってくる。

開発者からの尊敬がなくなると、彼らが働く動機は「給料がもらえるから」「上司だから」「命令だから」というものになり、開発全体の行方は行き詰まってしまう。

「尊敬値」を高める方法として、筆者はいくつかのアプローチを提示している。1つ目は、相手のタイプに合わせて行動することだ。例えば相手が技術力を重んじるタイプなら、「尊敬値」を高めるために自分も相応の技術力を備えていなければならない。逆に相手が「人柄」や「パーソナリティ」を重視するなら、明るく魅力的な人間性を発揮できるよう工夫する必要がある。もちろん人それぞれやり方は異なるので、無理に自分を変える必要はない。

もう1つの手軽に「尊敬値」を高める方法は、相手の要求が何であれ、しっかりと相手の話を聞くことだ。なにしろ自分はすでに技術力を失いかけているアラフォーなのだから、雑用を引き受け、エンジニアのあらゆる面倒を取り除くことで尊敬値を稼ぐしかない。

発言と「尊敬値」は互いに連動している。会議で積極的に発言すれば「尊敬値」を得られるが、注意すべきは「おいおい、何言ってんだこいつ」と思われるような発言を繰り返すと、「尊敬値」は徐々に低下し、やがて発言権を失ってしまう点だ。

人間は必ずしも理屈だけで動く生き物ではない。理屈が通っていればそれで万事解決、というわけにはいかないことが多いのだ。ときには自分がどれほど正しくても、さまざまな要因によって納得してもらえないことがある。人間なのだから、理屈が通ったとしても最終的には人間性の問題に行き着く。

これについて僕自身も思うところがある。それなら皆が毎日優しさに溢れ、仲良しこよしでいればいいのだろうか？ なぜ技術を語り、プロフェッショナリズムを追求する必要があるのか？ 誰もが満足する意見など存在するはずがなく、CAP定理ですら最大2つしか選べないのに、全部取ろうとするのは欲張りすぎだ。プログラミング言語やフレームワークに何を採用するかだけでも散々揉めるというのに、プロダクトにおける数々の意思決定となればなおさらだ。

だからこそ、過剰なのも不足しているのも良くないと僕は思う。僕がより望むのは、プロフェッショナリズムが管理者のコントロール下で存分に発揮される状態だ。技術や専門性を備えた人間には開発を推進するための十分な権限と発言権が与えられ、まだ未熟なメンバーはしっかりと追従しつつ、適切なタイミングで意見を出せるような環境が理想的だ。

自主性について

筆者は、管理者はチームを完全にコントロールすることはできないと考えている。今『League of Legends（LoL）』をプレイしたとしても、味方がこちらの指示通りに動いてくれるとは限らないのと同じだ。管理者が目標を達成するにはチームの協力が不可欠であり、その際に「尊敬値」をいかに有効活用できるかが極めて重要になる。メンバーがやりたいと思うことは、管理者ができる限りサポートしてあげるべきだ。

しかし、メンバーの自主性はどこまで放任すべきなのだろうか？ これも管理者にとっての難題だ。メンバーが「今日は働きたくない」と言ったからといって、そのままダラダラさせるのを放置するわけにはいかないだろう。

筆者は再びLoLを例に挙げている。まずは味方の動きを観察してみる。例えばガンク（奇襲）を受けた際に対処できているか、ラストヒット（CS）やレーン戦は安定しているか、立ち回りは良いか、敵のスキルを避けられているか、などだ。もし地雷プレイをしている味方をそのまま放任していれば、ゲームはあっさり負けてしまう可能性が高い。その場合、他のプレイヤーはレーン移動を増やしたり、危険ピンを鳴らして注意を促したり、逃げ道を指示したり、代わりにスキルを受けてあげるなどの選択肢を取ることができる。

もちろん、すべての操作が完璧で、チームファイトやタワー折りでも見事に連携できるハイレベルなプレイヤーに出会うこともある。そうした人材は職場においても同様で、滅多に出会えるものではない。だがそんな仲間に恵まれたなら、最も重要なのは彼らに自主性を発揮させることだ。責任の移譲や権限の委譲がこれにあたる。最終的に失敗する可能性があったとしても、全責任をその人に押し付けるようなことは絶対にしてはならない。むしろ全力でサポートすべきなのだ。

ただし筆者も触れているが、明らかに仕事をせず、ただ足を引っ張るだけの仲間（原文では「クズ」と表現されている）も当然存在する。そうした人間と一緒に仕事をしていては目標達成など望めないし、反省もしないような人物に自主性を与える必要もないし、同じチームに置いておく必要もない。

このとき最も重要なのは、「この人ならできる」と信じたなら、最初から最後まで信じ抜き、できる限りの支援を提供することだ。この信頼関係こそが非常に重要になる。

やる気（モラル）

続いて筆者は、どのように士気を高めるかという話題に戻る。筆者は2つの計画が必要であり、その両方が不可欠だと考えている。1つ目は本能的なもの、もう1つは理性的なものだ。

本能的なものとは、大学のサークルのように「みんなで一緒に何かを成し遂げる」という親密さに近いだろうか。だが仕事は大学のサークルではなく、目標やプロジェクトを達成するためのものなので、理性的な計画も必要になる。

理性と目標を欠いてしまえば大学のサークルのようになり、何も達成できず、ただ仲が良いだけの集団になってしまう。逆に本能的な要素を欠いてしまうと、士気の低下を招きやすくなる。

筆者は以下のような具体例を挙げている：

• 無理に飲み会を開く必要はない：むしろ反感を抱く人もいる
• メンバーに「安心感」を提供する

安心感と自主性の矛盾

基本的に人間の脳は、思考せず、決断を下さない方向を好む。いわゆるコンフォートゾーン（ぬるま湯）だ。何でも他人が決めてやってくれるのが一番楽なのだ。しかし、そうした安心感を与えすぎると逆に反発を招くことがある。エンジニアは本来、解決策を考えることで飯を食っている存在であり、挑戦を好むのがエンジニアの本性だからだ。

この点において管理者ができることは、不要な意思決定をできる限り排除してあげることだ。例えばTrelloのラベルの色をどうするか、今日のミーティングは何時にするかといった、どうでもいい些細なことなどだ。

仕事に人間味を取り入れる

筆者はTrelloの背景画像を例に挙げている。例えば背景に旅行に行ったときの写真を設定することで、そこから話題を広げることができる。僕の現在のチームでは、毎日のスタンドアップミーティングで最近あった「ちょっとした小話」を短く共有している。この小話は何でもよく、新しく買ったゲームのこと、遊びに行った場所、作った料理、食べたものなど、何でもネタになる。2〜3分で終わるものだが、お互いの交流を促すことができ、なかなか良い試みだと感じている。

確かに、エンジニアの大半は理性的・論理的に思考する傾向があるが、エンジニアの背後には一人ひとりの生身の人間が存在しており、ロボットではない。人間である以上、感情もあれば情緒もある。これは管理者が必ず向き合わなければならない課題だ。

次に筆者はミーティングのコツについて触れている。彼が考えるミーティングの目的には、以下のような優先順位がある：

• ミーティングの目的は何か、どんな結論やアクションが必要か。これに失敗すると自身の「尊敬値」が徐々に低下していく
• やる気（モラル）を獲得する
• 「尊敬値」を獲得する。少なくとも減らさないようにする

できる限り同化する

端的に言えば「空気を読む」ということだ。そう、エンジニアは反感を覚えるかもしれないが、現実にはそうなのだ。どこの国の人であれ空気を読むものであり、その度合いが違うに過ぎない。

ここで筆者が考える管理者の立ち回りとは、発言したい人がいればできる限りその人に発言させ、自分一人で発言権を独占しないこと。逆に誰も発言しないようなら、自分が口火を切って議論の余地を作り出し、対話が生まれるように促すことだ。

対立が激しすぎると不要な敵意を生みやすいが、意見が全く出ないと士気の低下を招く。このバランスをどう取るかは、まさに職人技と言える。

ミーティングではできるだけ沈黙を作らないようにする。沈黙は場の雰囲気を悪くしやすいからだ。それでも沈黙に陥ってしまった場合は、あえて突拍子もない突飛なアイデアを出してみるという手法が使える。そうすると誰かがそれにツッコミを入れたり議論に参加したりして、次第に思考が動き出すかもしれない。

相手にボールを投げる（質問を振る）

相手が実はアイデアを持っているのにこちらが気づいていなかったり、相手自身も話すべきかどうか迷っていたりすることは多々ある。そんなときは、相手に質問を投げかけるのが非常に効果的だ。

正しいかどうかではなく、好きかどうかを聞く

ときには、案Aと案Bのどちらを選ぶべきか膠着状態に陥ることがある。そんなときは、メンバーに「どちらの案が好きか」（正しいかどうかではなく、好きかどうか）を聞いてみるのがいい。全員がすでに思考と取捨選択を済ませ、メリット・デメリットを理解している状態なら、たとえ最も正しい選択肢ではなかったとしても、チームが一番「好き」な案に向けて進めるべきだ。これにはいくつかメリットがある：

• メンバーに好きかどうかを尋ねると、相手も自ずと考えを巡らせる
• 自分の答えが今後の方向性を左右すると分かれば、当然より深く考えるようになる

そうであるならば、管理者がすべきことは十分な信頼を与えることだけだ。

大きな声で褒め、発言する

これは筆者の哲学とは少し異なるかもしれないが、人を褒めるときはその場で、大きな声で、心から褒めるべきだ。これはチームにとって士気とモチベーションを高める極めて優れた方法である。

逆に、指摘や注意を促したい場合は、後から、1対1で、改善点を明確に伝え、私情を交えずに話すことだ。

相手の表情を注視する

主導権を握る有効な方法の一つは、顔を出すことだ。また、自分の発言に対して相手がどんな反応を示しているかを観察することもできる。逆にカメラをずっとオフにしていると、「この人は何をしているんだろう？」と不信感を持たれ、「尊敬値」を落とすことになりかねない。

最も重要なこと

筆者にとって、管理者の最も重要な仕事は「自分自身を守ること」だ。つまり、給料の範囲を超えた仕事はしないということである。結局のところ、管理職は魔法使いではないのだから、無理なものは無理なのだ。責任感を持つことは素晴らしいが、できないことに対して「できる」と言ってしまうのは自分をすり減らすだけだ。だから逃げてもいいし、辞めてもいい。あなたが辞めたところで、誰かの幸福に影響が出るわけではないのだから。

この記事が実に貴重なのは、そのリアリティにある。理論ばかりを並べ立てるマネジメント本に比べ、職場の生々しいリアルな経験にずっと寄り添っている。僕もかつては技術に対して偏執的になりすぎた結果、良い結果も得られず自分をすり減らしてしまったタイプだった。技術へのこだわりは時に巡り合わせでもあり、職場で実現できないのなら職場の外でやればいい。

今の会社でも思い通りにならないことはあるが、概ね満足しているし、プロジェクトには一定の手応えや挑戦があり、学べることも多い。そして技術そのものだけでなく、いかに円滑に立ち回るかについても理解が深まった。円滑にやるとは自分の信条を捨てることではなく、お互いの間でバランスポイントを見つけ出すということだ。

仕事というものは、結局のところ「人間」がすべてなのだ。正直なところ、僕自身まだまだ学ぶべき点がたくさんある。僕は褒められるのが好きなわけでも、褒められて喜ぶタイプでもないし、急に褒められたからといって俄然やる気が湧いてくるわけでもない。仕事である以上、淡々としっかりこなすだけだ。

そのため、僕自身も他人を滅多に褒めない。給料をもらって仕事をきっちりこなすのは当然の義務であり、なぜ子どものように褒められないとちゃんとできないのかと思ってしまう。しかし、そうした承認が持つ重要性もよく理解できるようになったし、今後は練習し改善していくべき部分だと感じている。

そして最後に気づいたのだが、実は僕はこの筆者と同僚で、一時期一緒に仕事をしていたことすらあったのだ😂（会社を辞めた後に偶然知ったのだが）。

注：本文の段落構成は原文と同じだが、原文の全訳ではなく僕自身の見解も付け加えている。正確な原文を読みたい場合は、原文リンクを参照してほしい。