AIクリエーターの道 ニュース：プロジェクト管理のジレンマ！完璧を求めすぎると…？チームを率いることの難しさを学ぶ。 #プロジェクト管理 #ソフトウェア開発 #マネジメント
動画で解説
皆さん、こんにちは！AI技術解説でおなじみのジョンです。いつもはAIの最新技術や難しい仕組みを、できるだけ分かりやすくお伝えしているんですが、今日はちょっとだけテーマを変えてみたいと思います。
というのも、先日ちょっと考えさせられるソフトウェア開発現場の体験談を読んだんです。AI開発も広ーい意味ではソフトウェア開発の一種ですから、きっと皆さんの役にも立つんじゃないかなって。今回は、あるマネージャーが経験した、ちょっぴり苦いけれど、とってもためになるお話を紹介しますね。
プロジェクト管理は「両刃の剣」？あるマネージャーの告白
今日お話しするのは、僕、ジョンが昔シリコンバレーのとある会社で開発チームのマネージャーをしていた頃の、ちょっぴり昔の体験談（元記事の筆者の体験談を、僕が語る形でお届けしますね！）。
当時、僕がいたチームは、本当に優秀なエンジニアばかりでした。まさにエリート集団！でも、僕らが作っていた製品は、かつてはすごく人気だったんだけど、少しずつ時代遅れになりつつあるソフトウェア開発ツールだったんです。
巨大で複雑なソフトウェア製品との格闘
この製品、とにかく大きくて複雑だったんですよ。例えるなら、全部の機能が一つにぎゅっと詰まった「特大幕の内弁当」みたいな感じ。専門的には「モノリシックな製品」なんて言ったりします。
年に一回、新しい機能を追加したり、見つかった不具合（バグ）を修正したりして、大きなバージョンアップ版をリリースするのが恒例行事でした。製品の中には、人間が書いたプログラムをコンピューターが分かる言葉に翻訳する仕組み（コンパイラって言います）とか、プログラムがスムーズに動くための土台となる部品（ランタイムライブラリ）、ユーザーが見る画面や操作する部分を作るための道具（ビジュアルフレームワーク）、そして開発作業全体を助けてくれる統合開発環境（IDE）…とにかく、いろんなものがごちゃっと詰まっていたんです。これらを全部まとめて、一つの製品として完成させるのは、本当に骨の折れる作業でした。
特に大変だったのが、「プラットフォームシフト」と呼ばれる作業。これは、製品が動くOS（オペレーティングシステム…WindowsとかmacOSとか、コンピューターを動かすための基本ソフトのことですね）を新しいものに対応させたり、別のOSでも動くようにしたりすること。製品自体が大きくて複雑なので、このOS対応の変更は、毎回チーム総出の大仕事だったんです。
すれ違いが生んだ悲劇の始まり
そんなある日、僕らの会社は、データベース関連のツールを作っている別の会社に買収されることになりました。新しい経営陣がやってきて、僕たち中間管理職は「これからどうなるんだろう？」と、期待と不安が入り混じった気持ちで新しい体制に慣れようと努力していました。
ここから、少しずつ歯車が狂い始めるんです。
新しい親会社が作っていたのは、データベースを扱うためのツール。一方、僕らの製品は、もっと幅広い種類のソフトウェアを作るための汎用的な開発ツールでした。表面上は「開発ツール」という点で似ているように見えるかもしれませんが、中身の複雑さは桁違いだったんです。例えるなら、見た目は同じ「自転車」でも、片方はシンプルなママチャリ、もう片方はF1マシンくらいの違いがあった、と言ったら分かりやすいでしょうか。この「中身の複雑さの違い」を、新しい経営陣はなかなか理解してくれませんでした。
「半年で2つのOSに対応しろ！」無謀な命令
そして、運命の日がやってきます。新しい経営陣から、とんでもない指示が下されました。
「君たちの製品を、LinuxとMac OSの両方に対応させてくれ。期限は半年だ！」
僕たち現場のチームは、耳を疑いました。「ええっ！？本気ですか…？」と。だって、私たちの見積もりでは、一つのOSに対応するだけでも、当時の人員では最低でも1年半はかかる計算だったんです。それを、2つのOSに同時に、しかもたった半年でやれと言うのですから…。
ソフトウェア開発の世界には、「ブルックスの法則」という有名な法則があります。これは、「遅れているソフトウェアプロジェクトに人員を追加すると、プロジェクトはさらに遅れる」というもの。つまり、単純に人を増やせば早く終わる、というわけではないんですね。僕たちは、この法則を避けつつ、なんとか短縮できるプランも提案したのですが…
経営陣は、僕たちの「1つのOS対応に1年半、2つなら3年」という見積もりを聞いて、ショックを受けたようでした。そして、信じられないことに、こう言ったんです。「そんなにかかるはずがない！君たちは、本当はやりたくないから、わざと大げさに見積もっているんだろう？」と。まるで、僕たちがサボろうとしているかのように聞こえました。そして、非情にも「半年で両方やれ」という期限が設定されたのです。
マネージャーの葛藤と、取り返しのつかない過ち
半年で2つの新しいOSに対応するなんて、どう考えても不可能でした。それは挑戦というより、無謀そのもの。僕のチームのエンジニアは本当に優秀でしたが、魔法使いではありません。夜も週末も返上して働いたとしても、絶対に間に合わない。そんな「デスマーチ（成功する見込みのない、無謀なプロジェクトのこと）」に、大切なチームメンバーを送り出すわけにはいきませんでした。
しかも、「君たちは嘘をついているんじゃないか？」と疑われているような状況は、本当に悔しくて、腹立たしいものでした。
僕は、かつて海軍にいた経験から、「部下を守ることがマネージャーの一番大切な仕事だ」と固く信じていました。だから、経営陣に対してはっきりと「この計画は無謀です！馬鹿げています！」と、かなり強い口調で反論し続けました。きっと、僕のイライラや不満が、態度にも表れてしまっていたと思います。
僕の直属の上司は、もともと同じ会社にいたので、この計画が無茶なことは百も承知のはずでした。しかし、彼は僕にこう言ったんです。「まあ、難しいのは分かる。でも、とにかく“やってみよう”じゃないか」と。
この「やってみよう」という言葉が、僕の運命を決定づけることになるとは、その時は思いもしませんでした。だって、絶対に失敗すると分かっていることを「やってみる」なんて、チームのメンバーにどう伝えればいいんでしょうか？
僕がしてしまったこと、そして本当にすべきだったこと
僕が取った行動は、今思えば完全に間違っていました。
「チームを守るんだ！」という正義感に燃えていた僕は、経営陣の計画に対して、協力するフリさえしませんでした。それどころか、チームのエンジニアたちに「こんな計画は狂ってるから、本気でやらなくていい」とまで言ってしまったんです。そして、上層部には相変わらず「無理だと言っているでしょう！」と噛みつき続けました。
では、どうすればよかったのでしょうか？ これが本当に難しいところです。
僕が本当にすべきだったのは、この最悪の状況の中で、なんとか最善を尽くすことだったんです。無理な計画だと分かっていても、経営陣の顔をある程度立てつつ、チームが疲弊しきってしまわないように守る。そんな「中間の道」を見つける努力をすべきでした。それは確かに非常に難しいことですが、少なくとも「試みる」べきだったんです。
結局、僕の未熟で感情的な対応が原因で、僕は会社をクビになってしまいました。計画が期限内に終わらなかったかって？ もちろんです、終わるはずがありませんでした。でも、だからといって、クビになるほど頑なに反発し続けた僕のやり方は、正しかったのでしょうか？ いいえ、それは間違いでした。
この苦い経験から学んだ大切な教訓
この体験談から、私たちは何を学ぶことができるでしょうか？ 元記事の筆者は、いくつかの大切な教訓を挙げています。
- マネージャーという仕事は、時として本当に難しく、不可能に思えるような板挟みにあうことがある。
- 時には、「自分が正しい」という主張を通すことよりも、組織全体にとって何が最善かを優先しなければならない場面がある。
- 部下を守ることと、経営チームの一員として会社の方針に従うことのバランス感覚が非常に重要になる。
- 部下をマネジメントするのと同じくらい、上司をうまくマネジメントすること（これを「マネージング・アップ」と呼んだりします）も大切である。
結局のところ、「自分が正しいかどうか」だけでは不十分で、「いかに効果的に事態を収拾し、前に進められるか」の方がずっと重要だということ。筆者は、それを痛い思いをして学んだ、と締めくくっています。
ジョンからのひとこと
いやはや、なんだか読んでいて胸が苦しくなるようなお話でしたね。でも、こういう「失敗談」って、後から振り返ると本当に多くのことを教えてくれるんですよね。特に、人と人とのコミュニケーションの難しさや、それぞれの立場や視点の違いからくる誤解やすれ違いって、AI開発の現場に限らず、どんな仕事にもつきものだと思います。
もし皆さんが、将来マネージャーになったり、あるいは今まさに似たような難しい状況に直面していたりするなら、このお話を少しでも思い出して、一度立ち止まって「どうすればもっと賢明に進められるだろう？」と考えてみるきっかけになったら嬉しいです。
この記事は、以下の元記事をもとに筆者の視点でまとめたものです：
Managing software projects is a double-edged sword