「マネジメントに正解はない」。元CTOが語る”マネジメント嫌い”のエンジニアのための組織づくり実践ガイド

このタイトルには、マネジメントに対する私の率直な思いが込められています。エンジニアとして入社した企業でマネジメント職は希望していなかったのですが、何故かマネジメントに任命されやらないとならなくなりました。どうにかして自分なりのマネジメントを実践する為に、考えついたのが「管理」ではなく「技術」としてマネジメントをとらえ直すことでした。

最初は世の中で推奨されている一般的なマネジメント手法を勉強しました。しかし、実践しようとしても、自分が望むような結果を得れるとは思えなかったのです。

一般的なヒューマンマネジメントは「人で仕事をこなす」ことに焦点を当てていますが、特にエンジニアの仕事は「技術で仕事をこなす」ことになります。

技術を身につけそれを使って問題を解決していくには「失敗する」ことや「間違う」のは当たり前のことで、そこから仮説を立て、実験し、計測し、結果を分析してまた仮説に戻るというサイクルをまわしていきます。これを行いやすくするためのマネジメントを試行錯誤していました。

一番技術力の高い人間に仕事をフルに当てはめることを制限したり、時間がかかったりしても、一人ではなく必ず技術力の低い人間とそれを補佐する人間のペアで対応をさせたりしました。また、仕事を早く片付けることに一番の価値を持たせず、「持続的に組織の力が高くなることに価値がある」と目的意識をかえるように試みました。

仕事の成果を早く出すには技術力のある人間をフルに稼働させればいいのでしょうが、それには制限をかけましたし、そのうえで技術力の低い人間の底上げのほうへ稼働を振り分けるように仕向けました。一番大切な「仮説、実験、計測、仮説」のサイクルを実践することを教えるには、高い技術力を持つ人間とペアを組むのが一番良いからです。

そうですね。「マネジメント」を「管理」と訳したことに根本的な問題があると思います。マネジメントをする人を日本語では「管理者」や「経営者」というようなイメージでとらえがちです。私は管理者としてのマネジメントに魅力を感じられませんでした。

マネジメントに「正解がある」という思い込みが広がっている気がします。マネジメントを行っている上司が何か言うと「上司は正解を知っていて、部下はそれを当てなければならない」と考えがちですが、上司自身も正解を知っていないことは珍しくありません。

そうなると、自分の失敗を認めることが難しくなりますし、失敗を元にしてより良いやり方を探すこともできなくなります。せっかく、エンジニアというより良い技術を探す能力のある人たちと仕事をしていくのであれば、それはもったいないことだと思いました。

私はこれを「解決病」と呼んでいます。マネジメントを続けていると次第に消極的になり、解決しやすい小さな問題ばかりを処理するようになる現象です。

本質的な、難しい問題に取り組んで失敗した時に「よく挑戦した」と評価されることは少なく、「なぜできなかったのか」と責められることが多いからです。そのため「自分が解決できる問題」だけを問題として認識するようになり、本質的な問題ではなく解決できて結果を出せる問題にだけ対応するようになってしまいます。

そうですね。マネジメントで行うことを「『人を動かして』『交渉力で』問題を解決するものだ」とする固定観念の影響もあります。交渉力を強くするためには「自分が正しい」という前提が必要ですから、間違いを認めることがマネジメント能力を下げる方向に働いてしまうのです。

私がおすすめしたいのは「未来から逆算して考える」ことです。これは、現在の制約条件や前提をいったん忘れて、理想的な状態から考え始める「ゼロベース思考」と呼ばれるアプローチです。

例えば、24時間365日のシステム運用が必要な場合、「人間が疲れない方法」を探すのではなく、「人間が介在しないシステム」を構築するという発想の転換です。問題が根本的になくなった世界を想像し、そこから現在を見る視点で解決策を考えると、従来の「人を動かす」マネジメントでは得られない技術的な解決策が見えてきます。

「60・20・20」の配分はマネージャーに試してみてほしい、組織の持続的な成長と安定的なパフォーマンスを両立させるための試みです。外部からの要求に全てのリソースを使いきるのではなく、組織の成長に必要な個人の底上げと情報の共有の時間を確保するという考え方です。同じ60%でも、個々の力と共有の仕組みが向上すれば、提供できる絶対値は自ずと上がるという狙いです。

一般的には「最大限の力でアウトプットする」という考え方が主流ですが、それでは力を消耗するだけで成長できません。60%の力でアウトプットを安定して提供し続けることで、残りの時間を技術力向上と情報の共有に充てられるようにしました。

週40時間で考えると約8時間、つまり1日分の時間を学習に充てることになります。私がマネジメントを実践していた当時は、オラクルプラチナ認定資格（最上級の資格）などの高難度の資格取得も目標に掲げましたので、メンバーには負荷もあったと思います。しかし「この勉強は仕事の一部である」という位置づけを明確にしたことで、個々のエンジニアの技術力向上への取り組みが社内で正当化され、メンバーの意識も高まりました。

平常時は「情報共有」のために使いました。集団で60%の力でサービスを提供し、20%を学習に使うには、個人の情報やスキルを組織全体で再利用できる仕組みが必要です。資料作成、進捗管理、分析ツール開発などに時間を割きました。また緊急時には、この20%を緊急対応に割り当てる方針でした。

長期的に見ると大きな効果がありました。個人の能力の絶対値が上がることで、60%のアウトプットで提供できるサービスの質と量も向上しました。外部の技術者の方々から褒められることもありましたし、新しいキャリアを目指して転職していった者もクラウド企業などで活躍していると聞いています。

はい、個人的に既存の「線表」の進捗管理を補う為に行なっていました。一般的なガントチャートでは時間軸だけで進捗を管理しますが、それだけでは全体の作業の量や個々の難易度が見えません。

エンジニアのリーダーとして働いていたときに、プロジェクトの進捗について「あとどれくらい作業が残っているのか」という量的な把握が必要だったのですが、従来の線表では表現できませんでした。そこで考えたのが「全体の仕事量を面積として捉え、完了した部分を塗り絵のように埋めていく」という方法です。

まず、作業全体の量の把握ができるようになりました。また、特に難易度の高い部分は「深く穴が空いている」ように表現することで、単純な面積以上の作業量があることも視覚化できます。特に技術的なプロジェクトでは、物理的に解決できない問題がボトルネックとなることがよくあります。

そうなのです。例えば、ある機能の開発が「技術的に実現可能かどうか」不明な場合、ガントチャートでは単に期間を伸ばすしかありませんが、それでは問題の本質が見えません。「塗り絵方式」では、そのような技術的な未解決部分を「深い穴」として表現し、チーム全体でその課題に集中できるようにしました。

実際にあった例では、あるデータベース処理が理論上可能でも実際には処理能力の限界を超えていた状況がありました。ガントチャートでは単に「進捗が遅れている」と表現されるだけでリソースを追加すれば対応可能なようにみえてしまっていたですが、「塗り絵方式」で「技術的に未解決の深い穴」として可視化したことで、「技術的な解決策を」探し出すことにリソースをさいて根本的な解決策を見出すことができました。

進捗のマネジメントは納期だけではなく、「期日までの仕事の量」の管理を行うことにあります。納期は基本的に動かせないものですが、仕事の量と難易度を把握することで、「どの作業から着手すべきか」「どの作業は遅らせても良いか」「リスクの高い作業はどれか」といった判断ができるようになります。これにより「先に片付けても問題ない難易度もリスクも低い作業」を先にこなすことによって「時間の在庫」を作り出し、難しい課題に対応する余裕を作り出すことができます。

技術者の育成で最も効果的な第一歩は、優れた「教師」を見つけることです。業界特有ではない世界で認知されている技術に関しては、社内で中途半端に教師を探すのではなく、実績があり複数の業界で経験豊富な技術コンサルタントなどとと契約し、教育も含めた役割を担ってもらいました。

OJTは基本的に業界特有の技術や知識を身につけることが目的で生まれていると思います。現状の業務をトレースするだけでは広く世界で認知されるような技術の成長を望むことは難しいです。外部の優れた技術者を招き、実際の問題解決を通じて教育してもらう方法が、はるかに効果的でした。

技術コンサルタントと現場で問題解決に取り組む中で、報告書作成や分析作業を教わる側が担当する形式です。コンサルタントは全てを解決するのではなく、指導しながら一緒に作業します。これにより実践的な技術とアプローチ方法を学べました。

はい。経験を積んだメンバーには実際の事例をもとにした教材作成を依頼し、社内外への勉強会の開催、さらには擬似的な障害環境での訓練といった取り組みへと発展させました。特に興味深いのは「事故対応シミュレーション」です。実際の障害対応は最も学びが多いものの、事故が頻発しては困るため、コンサルタントに依頼して擬似的な障害環境を作ってもらいました。

「良い教師を探す」「学び合う環境を作る」「科学的思考を身につける」の3点です。特に重要なのは、優れた技術者の「人間像」を自分の中にイメージできることです。座学だけでなく、実際の問題解決を通じて技術的アプローチや思考プロセスを学ぶことで、より深い技術理解と実践力が身につきます。

エンジニアの適切な評価や組織での位置づけに関する問題を根本的に解決するには、エンジニアの価値観を理解できる人がCFO(最高財務責任者)やCHO（人事責任者）などの経営幹部になる必要があると思います。CTOやCEOだけでなく、予算や人事の意思決定にエンジニアの視点を反映できる人材が必要です。

スタートアップではエンジニア気質のCEOが全体を統括していることも多いですが、組織が大きくなり出資者などが大きな発言権をもつようになるにつれて利益を求める傾向が主流になり、エンジニアの価値観が組織の中から消えていくことが見受けられます。エンジニアの視点を持ちつつ経営の意思決定に関われる人材が増えれば、エンジニアにとっての働きやすさも向上するでしょう。

マネジメントの本質的な目的は「現実に変化を起こすこと」だと考えています。過去は変えられませんが、未来は変えられます。現在は過去と未来の狭間にある柔らかな粘土のようなもので、遠くの未来を見据えながら現在の形を少しずつ変えていくことで、望ましい未来を作り出すための技術です。

マネジメントは未来をより良くするための技術であり、それ自体も進化し続けるものだと考える人が増えてほしいと願っています。