私はソフトウェアエンジニア、執筆家、ジャーナリストであり、マネージャーも務めている。今ままで一番複雑な仕事は、開発者のマネージャーを務めることだった。（最も困難なのではなく、最も複雑な仕事だ。）私はその専門家ではないし、素晴らしいマネージャーを装うつもりもない。しかし、より良いマネージャーになろうとする中で数多くの失敗を繰り返してきたことは事実だ。それらの失敗から学んだことを共有したいと思う。
責任者だからといって、支配するのが仕事ではない
マネジメントにおける最大の矛盾は、役職の階段を上るほど、実際の支配力は失われていくことだ。謙虚なコーダーである分には、コンピューターに対して、どうこうするよう明確な指示を出すことができる。しかしマネージャーになると、他の人が自分の要望を理解し、彼らがそれを時間通り、正確に仕事をこなすことを祈って信じるしかないのだ。
開発者からマネージャーになった人、特に私のような「フルスタック」（あるいは「プログラム愛好者」）の開発者は、ここで問題に直面することが多い。100%コーディングの仕事と100%マネジメントの仕事を行ったり来たりしている人、あるいはどちらも少しずつ行う人は特に顕著に体験するだろう。自分で全てが正確にできているか確認したいという衝動から離れるのが難しいという問題にだ。
更に難しいのは、誰かの仕事を確認する中で「私ならこういう風にはしない」ということと「これは間違っていて、リファクタリングしたり、書き直したり、アサインし直さければならない」ことを区別することだ。経験の浅い開発者には翼を広げるスペースを与えなければならないし、経験豊富な開発者にはその翼で自由に飛べるスペースが必要だ。マネージャーは意図的に一歩下がり、支配を弱めることで、大きな影響力を持つことができると理解しなければならない。
開発マネージャーで、エンジニアのバックグラウンドを持たない人は、更に支配力を持たない。開発における、プロセスや落とし穴への理解も少ない。そのような人に開発マネージャーが務まるのか私は疑問に思っているが、共に働いたあるいは、雇われていた先にそのようなタイプの優秀な人もいた。彼らがもたらす、あるいはもたらすと期待されているのは、クライアント、役員そしてエンドユーザー目線での考えを持ち込み、開発するプロダクトの質を高めることだろう。他人を支配できるという幻想からマネージャーを引き離す効果もあるのかもしれない。開発者からマネージャーに転身した人は、自身を軍隊の司令官であるように考えるが、実際は嵐の中を進む船をなんとか導こうとする航海士なのだ。船員の仕事が実際には重要なのだ。
アジャイルは良い。しかしそもそもアジャイルとは？
皆はプロセスの話をしたがる。私に言わせれば、話しすぎているほどだ。「アジャイル開発」と呼ばれるものの多くは、「スタンドアップ（立って参加する短い会議）」、「スクラム」、「スプリント」といった形式が細部まで定められた特定のプロセスに組み込まれている。これは、アジャイル開発のマニフェストの基本理念である「プロセスやツール以上に個人と互いの交流に重きを置く」と「計画を遂行すること以上に変化に対応することに重きを置く」という項目に対立し、とても皮肉な状況だ。結果的に企業が作成し、熱心に従っているものを見てみると、それはアジャイル開発のプロセス、ツールと計画なのだ。これはとても残念なことだ。スクラムマスターの認定を取得するのは、正しい道ではない。
人が作った特定のプロセスはそれほど重要ではないということだ。私が共に働いた最も優秀なチームは毎日スタンドアップ会議をしていたが、機能不全に陥っていた、今まで出会った中で最悪のチームもそれを行っていた。多くの人は、リーン・スタートアップの実用最小限のプロダクトを作るというアイディアに心を躍らせるが、同時に今は「デザインの時代」であると話し、スタートアップが成功するためには、世に送り出すプロダクトのデザインを最初から美しく、完璧に仕上げなければならないと言う。対面でのミーティングや「カジュアルな交流」は劇的な効果をもたらすこともあるだろうが、何十のタイムゾーンに散らばる100%リモートのチームでも同じことができるだろう。何が正しいのか？いつも答えは決まっている。その状況によるのだ。
早まらないでほしい。整えられたプロセスが全くない方が良いと言っているのではない。重要なのは、プロジェクトを行う手段として選んだシステムやプロセスは流動的で柔軟であるべきで、チームの状況や置かれている文脈によって選ぶべきものが変わってくるということだ。
幸いなことに私は本当に重要なことに気を配る、アジャイル開発の会社に勤めている。アジャイル開発にとって最も重要なことは、その名称が表している。アジャイルでいることだ。つまり、素早く動くということだ。（また、実践的なテストコードを書くことも重要だ。これは名称には含まれていないが、相当重要だと考えている。）コードを頻繁に定期的に世に送り出すことに意味がある。そうしなければ、私の経験上、ソフトウェア開発における停滞は、Lindy効果の対象となる。つまり、停滞している時間が長いほど、停滞から抜け出すのにより多くの時間がかかるということだ。サメのように、動き続けていなければ直に死ぬのだ。
つまらない仕事がマネージャーの職務
マネージャーの仕事とは基本的に、チームのプロダクティビティを高めることだ。そうするのに良い方法は？開発者の邪魔になっている仕事を代わりに行うことだ。つまり、開発者が最も嫌う重要な仕事を見つけ出し、代わりにそれを行うということだ。
ドキュメント作成を好む開発者は少ないだろう。それがマネージャーの仕事になる。テストコードを書くのもとても重要なことだが、開発者の多くは好まないだろう。それもマネージャーの仕事だ。全てのテストコードを書く必要はないが、一例として基準を設定し、物事を動き出させるのに必要な分を書くと良いだろう。コードが書けない場合でも、テストが作成できるくらいは身につけた方が良いだろう。自分でコードが書ける場合は、テストハーネスを全て作り、そこに何かを加える作業が限りなく簡単になるようにすると良いだろう。品質管理は他の誰かの仕事、あるいは職務内容に含まれていないと考えるのは、とても悪いマネージャーだ。
対人間で発生する摩擦にも向き合わなければならない。もし開発者がマネージャーの元を訪れ「重大な問題があり、苦渋の選択ですが、リファクタリングして正さなくてはなりません。期限には間に合わないと思います」と言ってきたのなら、それは称賛すべきことだろう。短期的に見ると痛みを伴うことだとしても、長期的に見ればそれは報われる。そのような技術的な負債を受け入れるのは、長期的にそれがそこには存在しないことが保証されている場合に限るべきだ。
まとめの更に要点だけを言うと：人が問題を起こす
きっと既に知っていることだろうが、残念ながら人は完璧ではない。人は疲れるものだし、間違えるし、マネージャーを無視することもあれば、嫌ったり、いなくなったり、仕事を辞めたり、マネージャーに対して失望するものだ。それは真っ当な理由もなく頻繁に起きる。そして事実は、マネージャーになったのなら、彼らの失敗はマネージャーの失敗であり、彼らの問題はマネージャーの問題であるということだ。早めに慣れよう。人の問題に早く気がつけるように気を配り、不測の事態に対応する方法を準備しておこう。
もう一つ：一人一人、違う方法で違うペースで働くということを覚えておくべきだ。つまり、採用活動がとても重要であるとことを丁寧に言い換えている。何故なら、やはり、人が問題を起こすからだ。
しかし、意外にも、人の問題を減らす方法もある。彼らがマネージャーを軽視したりすることが少なくなり、これが私の今までのキャリアの中で学んだ一番意外なことだった。彼らがマネージャーを信頼できる人だと分かれば、マネージャーも彼らに信頼を置くことができるようになるということだ。これは、本当だ。誓って言う。
絶対に誰にも嘘をつかないことだ。（今までのキャリアの中での最大の賛辞は、退職時の面談で当時の上司に言われた言葉だった。「どうやっているのか分からないが、君が話す時、聞いている人は皆、不誠実の仮面を外すようだ」と言った。）見たままの真実を外交的に伝えることだ。意味を取り違えないでほしい。信頼されるように努るべきということだ。そうした分だけ、他人を信頼することができるようになる。
マネージャーとは根本的には、少し注目を浴びることになった技術開発における翻訳者のようだ
マネージャーの仕事は、プロジェクトの壮大な計画を細部に至る内容と動作に落とし込み、開発者がそれぞれ遂行できるタスクに翻訳することだ。そして、開発者が仕上げたプロダクトをクライアント、役員、ユーザーが理解できるように翻訳することである。更に最も重要なのは、エラー、障壁となる物、そしてチャンスや可能性についてクライアントに対してその詳細を分かりやすく伝えるために翻訳することだ。そうするには、どんなプロの翻訳者でも言うように、創作物について執筆者よりも深く理解しなければならない。執筆者にとっては直感的に理解できるものだが、それを誰もが理解できるように落としこむのがマネージャーの仕事だ。
しかし翻訳者は翻訳した本に対する、栄光や賞賛を受けることはあまりない。（執筆者としての私の考えだ。）彼らの全ての良い判断は、執筆者に帰属するからだ。同様に、ファウンダー（ 私たちの場合は、クライアント）が創作物への賛美を受ける。開発者はコードに対して称賛される。誰も美しい子供を見て、助産師の仕事を称えることはないのだ。
なら何故やるのか？上述したように、個々の開発者にはより多くの支配力があるが、影響力はとても少ない。いかに賛美も称賛を受けなかったとしてもマネージャーの判断が、最終的に構築されるプロダクトの良し悪しを決めるのだ。それに価値を感じられないと言うのなら、その人は悪いマネージャーなだけでなく、仕事をするフィールドを間違えていると言えるだろう。
[原文へ]
