感想 — ゲームから管理を学ぶ
# 雑談https://akisute.com/2020/11/blog-post.html
備註：本文段落順序與原文相似，但並非原文翻譯並且有附上自己主觀見解，若要參考正確原文，請到原文連結閱讀。
この記事の原文は日本語で書かれているが、その中には仕事の上で共感できる点や、むしろ学べる点が多くあったので、ここでは簡単な引用と自分の感想をまとめることにした。
この著者は36歳で、もともとはエンジニアだったが、年を重ねるにつれて技術への熱意も少しずつ薄れ、ちょうど上司から「じゃあ、やってみれば」と言われ、給料も上がったので、その流れで管理職を引き受けた。
著者は面白いことに「でも問題がある。僕は人間が大嫌いだ。できるなら一人でいたいし、そもそも何でわざわざ人を管理しなきゃいけないんだ？」と言っている。どうせ業績管理も不要で、給料ももらえるのだから、まあ気楽にやろう、というわけだ。
ここで僕が感じたのは、エンジニアが全員技術に情熱を持っているとは限らないが、それは別に仕事をきちんとこなせないという意味ではない、ということだ。言い換えれば、技術への情熱と仕事をちゃんとやることは別物だ。著者のように、報酬を得るために働く人も当然いる。
管理職の最低限の要素は、実はかなりシンプルで、著者の言う通り能力面と思考面に分けられる。能力の部分は次の通りだ。
- 理性的かつ論理的に考えられ、一般的な水準には達していること
- 人前でちゃんと話せること
- 恥ずかしがったり、ためらったり、慌てたりしている様子を見せないこと
思考の部分は次の通りだ。
- 目標を達成することを楽しいと感じられること
- エンジニアの喜怒哀楽を心の底から感じ取れること
- 自分をボスではなくリーダーだと考えること
- 自分はチームで最も価値のない人間であること。ここは著者の言い方がかなりネガティブなので、そこは割り引いて見たほうがいい。著者は管理職が生み出す価値はゼロで、他のメンバーを奴隷のように使っているだけだと考えている。だからチームの成功は全員の功績であり、失敗は自分の無能さや怠慢だというわけだ。
要するに管理職においては、人を好きか嫌いかは必須条件ではない。上の条件を満たしていればいいだけだ。だから著者は、こういう役割は誰がやっても大差ないと考えている。だが僕は、実際にそこまでできる管理者はかなり少ないはずだと思う。多くの管理者は、自分より優秀な人間を見たくないし、自分の立場を守るためにあらゆる手を尽くして妨害したり、功績を全部自分のものにしたりする。正直なところ、まともな管理職になるのはエンジニア以上に難しいのではないかと思う。
ゲームと定石
著者は次に、管理はゲームのようなものだと語る。チームで協力して敵を倒すという考え方に似ていて、ここから先も著者が重要だと考える要素がいくつも出てくるので、順番に見ていく。
定石
囲碁では、通常いくつかの定石を参照できる。定石とは先人が見つけ、受け継いできた一定の手順のことだ。たとえば囲碁の定石は、黒と白が互角になるように一連の手順を定義している。定石どおりに打たなくても構わないが、相手に有利を取られやすい。
著者はまた、『Age of Empires』ではショートカット HCCC を使って村人を素早く生産できると言っている。数秒の差にすぎないが、相手より早く封建・城主の時代に進めれば、その時点で優位を取っていることになる。
つまり管理職にも、必ず覚えておくべき定石があるということだ。幸い、ソフトウェア開発には方法論（たとえばアジャイル開発）や参考になる古典（『人月神話』『The Phoenix Project』『ジョエル・オン・ソフトウェア』）が数多くある。
経験ももちろん大切だが、定石から学べば遠回りを少し減らせる。
管理における「パラメータ」
著者は3つあると考えている。
- 士気
- 尊重
- 発言
士気はかなり重要な指標だ。人は士気を失っても死にはしないが、何の生産性も発揮できなくなる。僕は、士気を満たすのはかなり難しいと思う。採用の段階から考えないといけないかもしれない。というのも、エンジニアにはそれぞれやりたいプロジェクトや触りたい技術があるので、同時に満たすのは難しいからだ。
尊重も重要な指標のひとつだ。管理の現場はゲームの世界のように、マウスを右クリックすればキャラがその場所へ勝手に移動してくれるわけではない。人がどの程度あなたの指示に従うかは、依頼内容と、相手があなたをどれだけ尊重しているかに左右される。
つまり、今日Bに残業して納期の厳しい案件を開発してほしいと頼むなら、どの程度従ってくれるかは、Bがあなたをどれだけ尊重しているか次第だ。仕事の難易度によって必要な「尊重値」も変わってくる。
開発者があなたを尊重していないとき、その人の動機は「給料がもらえるから」「上司だから」「命令だから」になってしまう。そうなると、開発全体の流れは苦しくなる。
「尊重値」を上げる方法として、著者はいくつか挙げている。ひとつは相手のタイプに合わせて行動することだ。たとえば相手が技術力を重視するタイプなら、自分にも相応の技術力が必要だ。逆に相手が「人」や「個性」を重視するタイプなら、自分も明るく魅力的な個性を持つよう努力しなければならない。もちろん、人によってやり方は違うので、自分を無理に変える必要はない。
もうひとつ簡単に「尊重値」を上げる方法は、とにかく相手の話をちゃんと聞くことだ。相手の要望が何であれ、まずは耳を傾ける。結局、もう技術力が落ちてきているアラフォーの僕にできるのは、こういう雑務や、エンジニアのさまざまな面倒を引き受けて尊重値を稼ぐことくらいだ。
発言と「尊重値」は相互に関係している。会議で積極的に発言すれば「尊重値」は上がるが、もし「え、何言ってるの？」みたいな状況が頻繁に起きるなら、「尊重値」は徐々に下がり、発言権も失われていく。
人間は理屈だけで動く生き物ではない。多くの場合、筋が通っているだけでは足りない。たとえ自分が正しくても、いろいろな要因で受け入れてもらえないことはよくある。人間なんて、理屈が通っているかどうかより、最後は人間性だ。
この点について僕にも少し考えがある。みんな毎日ぬくぬくして、ピンク色の泡みたいな温情だけでやっていければいいじゃないか、と。でも、何のために技術や専門性を求めるのか。全員が満足する意見なんてありえないし、CAP定理だってせいぜい2つしか選べないのに、どうして全部欲しがるんだ。プログラミング言語やフレームワークを何にするかだけで延々と言い争えるのだから、ましてやプロダクトの意思決定ならなおさらだ。
だから僕は、行き過ぎも足りなさすぎもよくないと思う。むしろ、専門性というものが管理者のもとで十分に発揮され、技術と専門性を持つ人には、開発を前に進めるだけの権限と発言権があり、まだ技術が成熟していない人は十分に追随し、必要に応じて意見を出す、そういう形が望ましい。
自律性について
著者は、管理者はチームを完全に命令で動かすことはできないと言う。今からLOLをやるとしても、味方が完全にこちらの指示通りに動くとは限らない。管理者が目標を達成するにはチームの協力が必要であり、そのとき「尊重値」をどう効果的に使うかが非常に重要になる。メンバーがやりたいことがあるなら、管理者はできるだけそれを支援すべきだ。
では、メンバーの自主性はどこまで放任してよいのか。ここも管理者の難しいところだ。さすがに「今日は働きたくない」と言われて、そのままサボらせるわけにはいかない。
著者はここでもLOLを例に挙げる。まずは味方の動きを観察する。たとえばガンクを受けたときに対応できるか、CS取りやレーン戦が安定しているか、立ち位置はいいか、スキルを避けられるか、といった点だ。こういう味方を放置して雷を落とし続けるなら、試合はそのまま負ける可能性が高い。その場合は、ローミングを増やしたり、警告ピンで注意を促したり、どう動くべきか示したり、スキルを肩代わりして受けたりするべきだ。
もちろん、すべての操作が完璧で、味方とうまく連携して集団戦を仕掛けたり、タワーを折ったりできる上級者に出会うこともある。職場に置き換えても同じで、そういう人は滅多にいないが、もし出会えたなら、その自主性を発揮させることが最優先だ。責任の移譲や権限委譲かもしれない。たとえ最終的に失敗する可能性があっても、責任を全部その人に押しつけてはならない。できる限り助けるべきだ。
ただし著者は、あからさまに何もしない、つまり明確に地雷を踏みに行くような味方もいると言う（原文ではクズ、つまりクズ人間として表現している）。こういう人と一緒に働いても、そもそも目標は達成できない。自分を省みない人に自主性を与える必要はないし、同じチームに置く必要もない。
このとき最も大事なのは、その人を信じてやれると思ったなら、最初から最後まで信じ抜き、できる限り支援することだ。この信頼は非常に重要だ。
士気
次に著者は、どうやって士気を上げるかという話に戻る。著者によれば、2つの計画があり、どちらも必要だ。ひとつは本能的なもの、もうひとつは理性的なものだ。
本能的なものは、大学のサークルのように、一緒に何かをして、同じ目標を達成する一体感に近い。だが、仕事は大学のサークルではなく、目標とプロジェクトを達成するためのものなので、理性的な計画も必要になる。
理性と目標が欠けると、大学のサークルのように、何も達成できず、ただ仲のいい人たちが集まっているだけになる。逆に本能的なものが欠けると、士気が下がりやすい。
著者はいくつか例を挙げている。
- わざわざ飲み会を開く必要はない。むしろ嫌がる人もいる
- メンバーに「安心感」を与える
安心感と自主性の矛盾
基本的に人間の脳は、考えず、決断せずに済む方向に傾きがちだ。いわゆるコンフォートゾーンだ。何もかも他人がやってくれるのが理想だ。ただし、こういう安心感を与えすぎると、逆に反発を招く。エンジニアはそもそも解決策を考えることで生きているし、挑戦したがることもエンジニアの本質だからだ。
この点で管理者ができることは、不要な決定をできるだけ取り除くことだ。たとえば、Trelloを何色にするかとか、今日は何時に会議を始めるかとか、そんな大したことのない小さな決定だ。
仕事に人間味を持たせる
著者はTrelloの背景画像を例に挙げる。たとえば背景に遊びに行ったときの写真を置けば、そこから会話が広がる。現在のチームでは、毎日のスタンドアップで最近の「ストーリー」を短く共有しているそうだ。このストーリーは自由で、新しく買ったゲーム、行った場所、作った料理、食べたもの、何でもいい。だいたい2〜3分で終わるが、お互いの交流を促進できるので、かなり良い試みだと思う。
確かに、エンジニアは多くの場合、理性的に考える。しかし、その背後には機械ではなく、生身の人間がいる。人間である以上、感情も気分もある。それは管理者が向き合わなければならない課題だ。
続いて著者は会議のコツについて述べている。会議の目的には優先順位があると考えているようだ。
- 会議の目的は何か、どんな結論やアクションが必要か。失敗すると自分の「尊重値」が徐々に下がる
- 士気を得る
- 「尊重値」を得る。少なくとも減らさない
できるだけ同化する
簡単に言えば「空気を読む」ことだ。そう、エンジニアは反発したくなるかもしれないが、実際はそういうことだ。各国の人はみな空気を読む。ただ、その度合いが違うだけだ。
ここで著者が管理者にできることだと考えているのは、誰かが発言したいなら、できるだけその人に発言させることだ。自分が発言権を独占してはいけない。逆にあまり誰も話していないなら、自分から発言して、議論の場をつくり、皆が対話できるようにする。
対立が激しすぎると不要な敵意を生みやすいが、意見がなさすぎると士気が下がりやすい。どうバランスを取るかもまた、ひとつの芸術だ。
会議ではできるだけ沈黙を避けるべきだ。沈黙はかなり雰囲気に影響するからだ。ただ、もし沈黙が起きたら、たとえば一見するとかなり突飛なアイデアを投げてみるといい。すると誰かがそれに乗って議論を始め、徐々に思考が動き出すかもしれない。
問題を他人に投げる
多くの場合、相手には考えがあるのに、それをこちらが知らないだけだ。相手も言っていいのか分からない。そういうときは、相手に問題を投げかけるのが非常に有効だ。
正しいかどうかより、好きかどうかを聞く
A案とB案で行き詰まり、どちらを選ぶべきか分からないことがある。そのときは、メンバーにどちらの案が好きかを聞くといい。正しいかどうかではなく、好きかどうかだ。もし皆がすでに思考と取捨選択を済ませ、長所と短所も理解しているなら、たとえ最適解でなくても、チームが最も好む案へ進むべきだ。こうする利点はいくつかある。
- たいてい、メンバーに好きかどうかを聞けば、相手も考える
- メンバーが自分の答えが方向性に影響すると分かれば、当然もっと深く考える
だから管理者に必要なのは、十分な信頼を与えることだ。
大きな声で褒めることと発言
これは著者の哲学そのものではないが、人を褒めるなら、その場で、大きな声で、心から言うべきだ。これはチームの士気と動機を上げるうえで非常に有効だ。
逆に、注意や指摘をするなら、あとで、個別に、問題点をはっきり伝え、私情を交えずに行うべきだ。
相手の表情を見る
主導権を握る有効な方法のひとつは、顔を見せることだ。また、自分の発言に対する相手の反応を観察できる。逆に、ずっとカメラをオフにしていると、「この人、何をしているんだろう？」と思われやすくなり、「尊重値」を失いやすい。
最も重要なこと
著者にとって、管理者に最も重要なことは「自分を守ること」だ。つまり、給料分以上のことをしないことだ。管理職は魔法使いではないのだから、できないことはできない。責任感を持つのは良いことだが、できないことをできると言うのは、自分を疲弊させるだけだ。だから逃げろ、辞めろ、あなたが辞めても誰の幸福も損なわれない。
この記事の貴重なところは、そのリアルさにある。理論ばかりが並ぶ管理書よりも、ずっと職場の実体験に近い。僕自身も、かつては技術にこだわりすぎた結果、いい結果を得られず、自分を疲れさせてしまうタイプだった。技術への執着は時に機運にも左右される。職場でうまくいかないなら、職場の外でやればいい。
今の会社では、不満がまったくないわけではないが、全体としてはかなり満足している。案件にもある程度の難しさがあり、学べることも多い。しかも技術そのものだけでなく、物事をうまく運ぶ方法もより理解できるようになった。いわゆる円滑さとは、原則を捨てることではなく、双方の間でバランスを見つけることだ。
仕事で最も大事なのは、結局のところ人だ。ここには、正直かなり僕が学ぶべきことが多い。僕は褒められるのが好きなタイプでもないし、褒められたから急にうれしくなるタイプでもない。突然褒められて急にやる気が満ちる、なんてこともない。仕事であるなら、僕はきちんとやるだけだ。
だから僕は、他人を褒めるのもあまり得意ではない。給料をもらって仕事をきちんとやるのは当然のことなのに、どうして子どもみたいに褒めないとやらないんだ、と思ってしまう。でも、こういうことの重要性はよく分かるし、これから練習したり改善したりできる部分だとも思っている。
最後に、実は僕とこの著者は同僚で、しかも一緒に仕事をしていた時期があったと分かった😂。ただ、それを知ったのは僕が退職した後の偶然だった。
備註：本文段落順序與原文相同，但並非原文翻譯並且有附上自己的見解，若要參考正確原文，請到原文連結閱讀。…