コンテンツにスキップ

プロジェクト・マネジャーが知るべき97のこと/あなたは特別ではない

提供:Wikisource


母親があなたに言っていたことを覚えていますか?

「あなたは特別よ!かけがえのない子よ!」

母親のいる子どもは、みんなそう言われていましたよね。この愛情あふれるウソを信じることは、ソフトウェアプロジェクトでよく見られる問題の原因となります。

私はこれまでいろいろなチームをコーチしてきましたが、プロジェクトメトリクスをどれだけ満たしているかでチームを評価すると、必ず自分たちは「特別」だと信じているチームほど出来が悪いのです。どうやら自分たちは特別だと思っているため、何もかも再発明したくなるようです。「僕らほど使えるソフトウェアを開発してきたチームはないだろうね。少なくとも、僕らが作った方がいいものができるはずだ」彼らはほかの開発者の間違いから学ぶのでなく、自分自身で間違わないと気がすまないのです。何度も何度も何度も。それも会社の経費を使ってです。

彼らはすでに業界標準になっているソフトウェアやツール†があるのに、膨大な時間を費やして、それらを書き直し、デバッグして、独自のひねりを加えます。その結果、何が起こると思いますか。彼らは決して顧客のプロジェクトを完成できないのです。お金を得るために彼らが売るべきものは何なのでしょう。チームと同じくらい特別な、伝説的で魔法のような製品を書ければよいのですが……。

この特別な開発チームに話を聞いてみると、既存のビルドシステムでは彼らの「特別な」要件を扱えないと言います。だから、彼らは新しいプロジェクトごとに新しいビルドシステムを書かなければならないと言うのです。既存のオブジェクトデータベース・マッピングツールを再利用するのではなく、自分たちで書くのです。Webアプリケーションフレームワークだって?

僕らはそれも書けるよ。継続的インテグレーション?

調べておこう。テスティングハーネス?

書きますよ。そのなかでも最もムダでがっかりするのは、独自のプログラミング言語を書こうとすることです。

さて、こういうチームは1日をどのように過ごすのでしょう?

十分機能して、しかもフリーで利用できるソフトウェアツールの代わりに、自作のテストされていないコードを使います。そして、そこで発生した問題を、自ら解決するのです。自前のデータベース層を書くときには、よくわからないパフォーマンス上のバグを数日かけて追いかけて、ようやく問題を見つけます。エッジケース††まで対応しようと思うと、最終的には既存のツールを学習することはおろか、それを修正するよりもはるかに時間がかかってしまいます。

「特別」ではない(けれども成功している)チームが既存のツールを利用しているのは、彼らが解決しようとしている問題が難問だからです。彼らには信頼できるツールが必要なのです。それがあれば、自分たちのプロジェクトの問題解決に集中できます。ツールボックスがいっぱいなのに、さらにツールを補充しようとしてはいけません。

この話は効果的なプロジェクトマネジメントにどんな関係があるのでしょうか?

プログラマに車輪の再発明をさせてはいけない、ということです。開発者が自分たちのプログラムがどれくらい特別であるか説明しにきたときには、母親が「あなたは特別よ」と言ったのは過大評価だったのかもしれないよ、と指摘してあげましょう。あなたは何が使えるのか熟知しておき、高品質のオープンソースもしくは商用ツールを使うようチームを導きましょう。

NIH(NotInventedHere、ここで発明したものではない)症候群は、これまで数多くの優秀なチームを狂わせてきました。あなたのチームをそうさせてはいけません。

この作品はクリエイティブ・コモンズ 表示 3.0 アメリカ合衆国ライセンスのもとに利用を許諾されています。

あなたは以下の条件に従う場合に限り、自由に

  • 共有 – 本作品を複製、頒布、展示、実演できます。
  • 再構成 – 二次的著作物を作成できます。

あなたの従うべき条件は以下の通りです。

  • 表示 – あなたは適切なクレジットを表示し、ライセンスへのリンクを提供し、変更があったらその旨を示さなければなりません。これらは合理的であればどのような方法で行っても構いませんが、許諾者があなたやあなたの利用行為を支持していると示唆するような方法は除きます。