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

http://www.amazon.co.jp/exec/obidos/ASIN/4822281906/aprsnp27-22

ソフト開発者やプロジェクトマネジャーにとって身近なテーマを中心に、ソフト開発の実情をクールな視点で浮き彫りにした辛口の読み物。長年信じ込まれてきた「ウソ=誤解」を解き明かした読みごたえ十分の1冊。

日経BPのサイトで邦訳の目次を見たら、managementを「管理」と訳している模様。デマルコの本でも「管理」とやっていた。最低だ。managementを「管理」にしたということは、controlは「制御」と訳しているのだろうか。それとも「コントロール」? ちなみに、マネジメント関連本では、controlを「管理」(場合によっては「コントロール」)にすることが多い。
【参考】原書目次

原書の一部を以下で参照できる。
Fallacies of Software Engineering Management:Sample Chapter(s)


原書の第1章冒頭(Facts of Software Engineering Management)は、以下のような感じ。

●マネジメントについて

正直言って、マネジメントは退屈な分野だと思っていた。これまでにマネジメントに関する本はいろいろ読んでみたが、そのほとんどは常識的なことばかり書いてあり、あとは二番煎じのアドバイスでしかなかった。では、なぜ本書の出だしがマネジメントになっているのだろうか。
その理由は、マネジメントはソフトウェアの開発で一番影響が大きく、最も目につきやすいからだ。これは筆者の偏見ではない。実際、大半の失敗はマネジメントが悪かったせいにされる。その理由は、マネジメントに関する知識も役に立つことがあるからだ。ソフトウェア分野で起きる問題を解決する糸口や筋道を与えてくれるのは、たいていマネジメント分野の知識だ。実際、これまで失敗したプロジェクトの多くはマネジメントに失敗している。また、成功したプロジェクトの多くは、マネジメントがうまくいっていた。Alan Davisの魅力あふれる書籍、『ソフトウェア開発201の鉄則』(1995)では、127番目の法則のところで次のように述べている。「優れたマネジメントは優れた技術よりずっと重要だ」。そう認めたくはないが、Alanの言うとおりだ。
なぜそう認めたくないのかと疑問に思うだろう。筆者は、これまでのキャリアの中で人生の岐路に立たされたことがある。テクノロジスト(技能労働者)としての道を歩み続けて、大好きなソフトウェアの開発を続けていくか、それともマネジャーとしての道を選ぶかという選択に直面したのである。これには相当悩んだ。アメリカではトップを目指すのが当たり前であり、このような考え方を無視することはできなかった。しかし最終的に、次の2つの理由から、筆者は開発現場から離れたくないということに気がついた。

1. 自ら作業するの好きなのであり、人を動かすのは好きではない。
2. 自由に意思決定できる環境に身を置きたい。「中間管理職」になって上司の判断を仰ぐようなことはしたくない。

2つ目の理由に驚いた人もいるかもしれない。どうしてマネジャーよりもテクノロジストのほうが自由に意思決定をすることができるのか? 筆者の過去の経験からすれば、これは真実である。しかし、これを人に説明するのは至難の業だ。このことに関して、筆者は過去に『The Power of Peonage』(1979)という本を執筆し、詳しく述べた。この本で言いたかったのはこういうことだ。「高いスキルを持ちながらも、マネジメント階層の最下層にいる人は、より上位の階層にいる人にはないパワーを持っている」。これは、筆者がテクノロジストとしてとどまることを決意させた最大の理由(my belief)でもある。彼らは降格させられることはない。たいていの場合、最下層の人には、それ以上下がるところはない。有能なテクノロジストには降格という手段は脅威になるかもしれないが、最下層の人には脅威にすらならない。そして私は、これまでに何度もそのパワーを使うことにより、自分が進むべき道を確信したのである。
少し話はそれるが、マネジャータイプでない筆者が、なぜ本書の冒頭でマネジメントについて触れているのかという疑問が出てくる。ここで言いたいのは、マネジャーよりもテクノロジストでいるほうが "楽しかった" ということだ。"重要だ" と言っているのではないという点に注意してほしい。マネジメントに関する事柄はソフトウェアの分野では忘れられがちだが、きわめて重要なのは言うまでもない。残念なことにマネジャーたちは、常識やら二番煎じの忠告やらに巻き込まれて混乱し、まさにいまそこに存在している、注目すべき重要な事実が見えなくなってしまうのである。
人(people):人の重要性は改めて述べるまでもないだろう。誰しもほかの人にはない長所があるものだ。いかにしてプロジェクトが成功あるいは失敗するかは、どのように遂行されたかということよりも、誰がその作業を行うのかによることのほうが圧倒的に多い。
次に、ツールや技法についてはどうだろうか(これらは通常、マネジメント層によって選ばれてしまうのだが…)。宣伝文句にのせられてしまうのは愚の骨頂だ。新しいアプローチを採用した場合、やり方によっては、マイナスの効果しか得られないかもしれない。実際のところ、新しいツールと技法が現場で使われることはほとんどない。
見積もり:見積もりの精度が非常に低いのは、日常茶飯事である。見積もりを作成するまでのプロセスは、何ともひどい。精度の低い見積もりは失敗につながり、これがプロジェクトの決定的な失敗要因となる。マネジャーとテクノロジストの見積もりが一致することは「まったくない」。
再利用:実に長いこと、我々はコードを再利用しようとしてきた。だが近年では、再利用することはほとんどない。再利用について、いったいどの程度の効果を期待(おそらく誤って)しているのだろうか。
複雑さ:ソフトウェア開発の複雑さは、ソフトウェア分野に数多く存在する問題を説明する理由となるのだろうか。一般に、複雑さは急速に高まる。どんなに優秀な人間でも、この複雑さに打ち勝つことなどはできない。

これが後続の章の概観である。“マネジメント”に関して、普段は忘れているけれども覚えておかなければならない重要なことについて見ていくこととする。

【参考文献】
Davis, Alan M. 1995. 201 Principles of Software Development. McGraw-Hill(『ソフトウェア開発201の鉄則』(アラン・M・デービス著、松原友夫 訳、日経BP社、1996)
Glass, Robert L. 1979. The Power of Peonage. Computer Trends.