『ソフトウエア開発 55の真実と10のウソ』を読む

※ 以下ではいくつか翻訳の不備を指摘しているが、本書の価値を損なうものではない。また、訳しづらい原著者の英文を読み解き、無事刊行されたことに関しては敬意を表したい。

『ソフトウエア開発 55の真実と10のウソ 』
ロバート・L・グラス著、日経BP社　ISBN:4822281906

【内容】
IEEE Software誌の気鋭コラムニストが「名著」をめぐる旅で確信した真実
ソフトウエアの世界には、法則集は多くありますが、本書はソフトウエア開発における「真実」と「ウソ」をクールな視点でまとめた読み物です。プロジェクト管理、品質管理、ライフ・サイクル、再利用、見積もり、教育など幅広いジャンルから引き出したの“55”の真実と“10”のウソ。... （日経BP社の書籍紹介 より一部引用）

【目次】
邦訳書：http://bpstore.nikkeibp.co.jp/item/contents/m_4822281906.html
原書：http://www.informit.com/title/0321117425#

【原書立ち読み】
原書の一部を以下で参照できる（いずれも「About Management」と題された章）。ページ数としては、約３割公開されている。
第１部 第１章（Fact 1〜22）：
Facts of Software Engineering Management
第２部 第５章（Fallacy 1〜6）：
Fallacies of Software Engineering Management

※ その他参考図書：『悲しいとき』いつもここから著

---

『ソフトウエア開発 55の真実と10のウソ』の悲しいとき

悲しいとき

management が「管理」と訳されているのを発見したとき

悲しいとき

「プロジェクト管理」の「管理」に「マネジメント」とルビがついているのを発見したとき

（『ソフトウエア開発 55の真実と10のウソ』、10ページ１行目）

悲しいとき

manager が「管理者」と訳されているのを発見したとき

悲しいとき

よく見たら、manager / management の訳語に「マネジャー／マネジメント」も使っているのを発見したとき

【注解】
米国には遅れをとっているが、近年、PMP（Project Management Professional）に代表されるプロジェクトマネジメント分野の普及・発展は著しい。management という用語は以前は「管理」と訳すのが普通だったが、少なくともプロジェクトマネジメント分野では「マネジメント」と訳すのが了解事項となっている。同様に、manager は「マネジャー」だ。もちろん、プロジェクトマネジメントでも「管理」という用語は登場する。では、プロジェクトマネジメントにおける「管理」とは何なのか？　それは、「変更管理（change control）」に代表されるように control のことである。マネジメントと管理（コントロール）の違いは、以下のようになる。

● マネジメント＝プロジェクトをうまく成し遂げるために行う作業
● 管理（コントロール）＝プロジェクトに影響を与えるなんらかの事象（厳密には「変更（change）」と呼ぶ）が生じた場合に、適切に対処すること、それに伴う作業。

厳密さを欠く言い方になるが、マネジメントは「プロジェクトを計画どおりに円滑に遂行すること」が目的であり、管理（コントロール）は「障害を検出し、取り除き、正しい方向に導くこと」が目的となる。

※ 参考資料１：『PMP教科書 Project Management Professional』（翔泳社）
※ 参考資料２：日経IT Pro 情識・常識 「マネジメントとコントロールは違う」（日経コンピュータ2003年2月24日号，32ページ再録） より引用
　「マネジメントとは、正しいことをするという意味である。これに対し、コントロールとは、ことを正しくするという意味であり、マネジメントとは違う。日本企業は一般に、コントロールについては卓越しているが、マネジメントの仕組みを真に確立しているとは言い難い。仕組みを確立するにあたっては、包括的なマネジメント体系を取り入れる必要がある。それがプロジェクトマネジメントである」（峯本展夫氏、合資会社プロジェクトプロ CEO） ［20040420追加］

管理とマネジメント
では、実際に本書でどのように訳されているか見てみよう。本書の第１章の冒頭（10ページ）から引用する（原文も併記する）。

正直になところ、ソフトウエアのプロジェクト管理は、死ぬほど退屈なものと思っている。これまで、管理の本をいろいろ読んだが、管理とは、95％は常識で、残りの5％は大昔から引き継いできた教訓だ。この本の最初の章で、わざわざ管理を取り上げたのには理由がある。公平に見ると、ソフトウエアの開発で、一番影響が大きく、目につきやすいのが管理だ。例えば、開発の失敗は、マネジメントが悪かったせいにされる。

To tell you the truth, I've always thought management was kind of a boring subject. Judging by the books I've read on the subject, it's 95 percent common sense and 5 percent warmed-over advice from yester-decade. So why am I leading off this book with the topic of management?

Because, to give the devil its due, most of the high-leverage, high-visibility things that happen in the software field are about management. Most of our failures, for example, are blamed on management.

すでに指摘したように、management が「管理」と訳されており、さらに「マネジメント」も使われている。どのような使い分けなのかは私にはわからない。しかし、これでは読みにくいので「管理」を「マネジメント」に直し、不要な読点も取ったものを以下に示す（本書は不要な読点が多いのも気になる）。

正直になところ、ソフトウエアのプロジェクトマネジメントは死ぬほど退屈なものと思っている。これまでマネジメントの本をいろいろ読んだが、マネジメント※とは95％は常識で、残りの5％は大昔から引き継いできた※教訓だ。この本の最初の章でわざわざマネジメントを取り上げたのには理由がある。公平に見ると※、ソフトウエアの開発で一番影響が大きく目につきやすいのがマネジメントだ。例えば、開発の失敗はマネジメントが悪かったせいにされる。

では、内容を吟味してみよう。どのように読解するするかにもよるが、最初の※印の箇所「マネジメント※とは95％は常識で…」というのはおそらく違うだろう。この文の主語 It は 前文の the books（マネジメントに関する本）を指しているのではないか。２つ目の※印の箇所「大昔から引き継いできた※教訓」は単純な誤訳。warmed-over は、「（議論・意見などが）蒸し返しの」という意味だ。３番目の※印の箇所「公平に見ると※」は文章がつながらない。「to give the devil its due」は、「いやなやつでも評価すべきところは評価してやる」の意。「公平に見ると」でもよい場合はあるが、著者は「マネジメントなんて気に入らない」という態度なのだから、ここでは不適切だ。

また、最後の「ソフトウエアの開発で一番影響が大きく目につきやすいのがマネジメントだ。例えば、開発の失敗はマネジメントが悪かったせいにされる」は、「例」になっていない。もしこの訳ならば「このため、開発の失敗はマネジメントが悪かったせいにされる」とならないと意味が通じない。

以下に、修正訳を示す。

正直言って、マネジメントは退屈な分野だと思っていた。これまでにマネジメントに関する本はいろいろ読んでみたが、そのほとんどは常識的なことばかり書いてあり、あとは二番煎じのアドバイスでしかなかった。では、なぜ本書の出だしがマネジメントになっているのだろうか。

その理由は、マネジメントはソフトウェアの開発で一番影響が大きく、最も目につきやすいからだ。これは筆者の偏見ではない。実際、大半の失敗はマネジメントが悪かったせいにされる。 ［20040419修正］

管理（コントロール）と制御
本書では management を「管理」としているため、PMPなどのプロジェクトマネジメント技法を学んだ者にとっては、とまどう表現が登場する。前述のように、一般的な理解では「管理」とは control の訳語だということを頭に入れて、以下の引用をお読み頂きたい（原文を併記する）。

「測定できないものは管理できない」 "you can't manage what you can't measure" 「測定できないものは、制御できない」 'you can't control what you can't measure.'" （邦訳書、第２部 第５章「ウソ１」、249-250ページ）

この言葉はデマルコが『Controlling Software Projects』の冒頭で述べた言葉である。デマルコは、誤って "you can't manage what you can't measure" と書いてしまったとグラスに告白している（正しくは、'you can't control what you can't measure.'" ）。プロジェクトマネジメント分野での通常の理解では、「管理」も「制御」も control のことだと思ってしまうため、この２つの文は同義になってしまう。デマルコが誤って書いた前者のほうの「管理」は「manage」のことだと、いちいち頭を切り換えないといけない。

デマルコの名前が出てきたので、本年度の Jolt Award（Software Development Online: Jolt Product Excellence and Productivity Awards）を受賞した『熊とワルツを』（邦訳）を見てみたところ、こちらも risk management を「リスク管理」としている。

しかし、これは版元（日経BP社）の統一方針ではないらしい。たとえば、日経IT Proの「トム・デマルコ氏インタビュー（完全版）（日経コンピュータ2004年3月8日号掲載分の再録）」を見ると以下のようになっていた（「質問者：」「デマルコ：」は補足した）。

質問者： リスク・マネジメントは古くからあるトピックだと思います。この時期に『熊とワルツを』というリスク・マネジメントに関する本を出した意図は何だったのでしょうか。 デマルコ： ソフトウエア分野におけるリスク・マネジメントは、決して古いトピックではありません。

やはり、日経コンピュータのように management は「マネジメント」と訳すべきだろう。

また、control は基本的に「コントロール」と訳し、日本語として座りが悪い場合のみ「管理」と訳せばいいのではないだろうか。たとえば、「変更コントロール」のような漢字とカタカナを混ぜた表記はどうも座りが悪いと思える場合は、「変更管理」とすればよい。［20040420追加］

（追記）日経ITプロフェッショナル 2004年4月号のブックレビュー（140-141ページ）の特集は「リスク・マネジメント」だ。リスク・マネジメントに関する本を７冊取り上げ、峯本展夫氏（前出）がレビューしている。『熊とワルツを』も取り上げられている。ここで峯本氏は、『熊とワルツを』の翻訳を以下のように批判している。

残念なのは、「マネジメント」が「管理」と訳されていたり、「アーンド・バリュー」が「稼得価値」に、「コンティンジェンシー計画」が「危機対応計画」に訳されるなど、日本語にすることでかえって分かりにくくなっている用語があることだ。

（追記）コンティンジェンシー・プラン（contingency plan）：「不測事態対応計画」と訳される場合もある。不測の事態（リスク事象）をあらかじめ想定した代替案（計画）のこと。上記のように「危機対応」としてしまうと、軍事計画の「crisis response」が連想されてしまう。「ビジネスは戦争だ」という意見もあるが、ここでは関係ない。 ［20040429追加］

---

ドラッカーが悲しいとき

technologist の訳語が「テクノロジスト（技能労働者）」ではなく「エンジニア」あるいは「プログラマ」となっているのを発見したとき

【注解】
テクノロジスト（technologist）は、ドラッカー的世界観におけるキーワードである。これについては、日経BP社の谷島宣之記者の記事が詳しい（「谷島の情識」）。たとえば、以下のページを参照してほしい。

● 「ネクスト・ソサエティを読む２：テクノロジスト（技能技術者）が主役」（谷島宣之記者）

谷島宣之記者のページでは、テクノロジストを以下のように説明している。

知識労働者とは、今までは医師、弁護士、教師、会計士、化学エンジニアなど一部の人たちを指していた。これに対し、テクノロジストとは、コンピュータ技術者、ソフト設計者、臨床検査技師、製造技能技術者などを指す。テクノロジストは、「知識労働者であるとともに肉体労働者でもある。むしろ頭よりも手を使う時間のほうが長い。だがその手作業は、徒弟制度ではなく、学校教育でしか手に入れない知識を基盤とする。とびぬけて収入が多いわけではないかもしれない。しかし、彼らは、プロフェッショナルである」と書かれている。 ※『ネクスト・ソサエティ』P. F. ドラッカー著、ダイヤモンド社

日経ビジネスのインタビューでドラッカーは、テクノロジストに関して以下のように述べている。

現代の大きな社会変化は、人口の減少と単純労働が中国に移るなど働き手の質の変化である。この2つの変化に連動して、新しい働き手「テクノロジスト」と呼ばれる人達が増加している。テクノロジストとは、高度な専門技術や技能を持ったナレッジワーカー（知的労働者）のことで、米国を始め欧州や日本でも活躍の場を広げている。テクノロジストの特徴は出世を望まず、経営幹部になって報酬を3倍に高めるより、専門家として思い切り働きたいと願うこと。組織に対する忠誠心よりも自分の専門領域への情熱を優先する。今起きようとしている第4の情報革命の中で主役に躍り出るのはテクノロジストである。

※「ドラッカー　未来企業を語る」、日経ビジネス 2003年4月 特別編集版「情報力を鍛え直す」。特別編集版が見つからなかったため、以下のWebページを参考にした。
　・「本当に役に立つ」ビジネス書をご紹介します！
　・建設お助け隊・建設レーダー

原著者のグラスが「technologist」と記述した場合、おそらくドラッカーの言うテクノロジストを意識して書いていると思われる。であれば、テクノロジストを単純に「エンジニア」とか「プログラマ」としてしまうのは良くないだろう。深い意味がない場合もあるかもしれないが、わざわざ「テクノロジスト」という言葉を使うことによって、我々に言外の意味を伝えようとしているのかもしれない。

「テクノロジスト」が最初に出てくる箇所は10ページだ。引用する（原文も併記する）。

筆者が、管理の重要性を認めたくないのには、理由がある。筆者がソフトウエア技術者として、まだ駆け出しのころ、人生の岐路に立たされた。これまで通り、エンジニアとして自分の好きなプログラムを作るか、マネジャーになるかだ。 Why do I hate to admit it? Early in my career, I faced the inevitable fork in the road. I could remain a technologist, continuing to do what I loved to do—building software, or I could take the other fork and become a manager.

これは「テクノロジスト」のほうがふさわしいのではないだろうか。グラスの複雑な気持ちが「a technologist,」という言葉に込められている気がする。

続いて62ページ（訳文は、「何か」を「どれだったか、と」に修正）。

管理者は当該プロジェクトのプログラマに、これまでで最も成功したプロジェクトはどれだったか、と聞いた。 He asked the technologists on the project to talk about the most successful project they had ever worked on.

続いて63ページ。

このプログラムを開発することは、技術的に大きなチャレンジだった（データによると、エンジニア連中は、技術的に困難な問題を解決することに、大きな喜びを覚えたらしい）。 Developing the product had been a technical challenge. (Lots of data show that, most of all, technologists really like overcoming a tough problem.)

62ページと63ページで「プログラマ」と「エンジニア連中」と別の訳語をあてている理由は不明だ。しかし、どちらも「テクノロジスト」にしなければならないというほどではない気がする。

続いて251ページ。

マネジャーは、片方の手でモチベーション教育や品質確保の方法論を進めながら、もう一方で、厳しい工程を押しつけ、品質を下げている。管理者は、両方を同時には強制できないし、エンジニアも馬鹿ではないので、同時にできないことは承知している。 Management is motivating and methodologizing with one hand and applying antiquality schedule pressure with the other. It is simply not possible for those managers to have it both ways. And most technologists are smart enough to know that.

ここでは、Management＝マネジャー、managers＝管理者、 technologists＝エンジニア、と訳されている。managers をマネジャーと訳したり管理者と訳したりと一貫性がなく、非常に混乱する。原文を知らないと、違う職能だと思ってしまうはずだ。おそらく、Management は managers の上の階層のことを指しており、「経営層」あるいは「マネジメント層」のことだ。その下にマネジャーがいる。どうしても、Management＝マネジャー としないと話が合わないのであれば、（その箇所だけは）managers＝リーダー とすればいいだろう。

また、「テクノロジスト」が登場するときは、マネジャーとの対比で登場することが多いような気がする。「テクノロジストはマネジャーと違って、こうなんだ」というグラスの主張があるのではないだろうか。ただ、グラスはひねくれ者なので、意固地になって使っている場合もある点には注意したい。

最後になってしまったが、本書は含蓄があり面白い。ソフトウェア工学、あるいは通り一遍のシステム開発本には飽きている諸兄にお勧めしたい。

【おすすめ度】 ★★★★