「地球高温化」というがっかりな例とは対照的な成功例を思い出したのでメモ代わりに書いておきます。同じように環境問題で、かつ命名に成功した例で言うと「環境ホルモン」が思いつきます。環境ホルモンは正式には内分泌攪乱物質(Endocrine disruptor)と言うそうです。「環境ホルモン」という問題が認識されたアメリカでは当初、Endocrine disruptorという言葉を使っていたそうですが、なじみのない言葉だったために認知度が上がらず、環境問題として認識されにくかったとのこと。一方、日本では「環境ホルモン」の呼称について[Wikipedia]にもあるとおり、NHKと井口氏によってよりイメージしやすい言葉を使って、環境問題として広く知らしめたという例があります。

「環境ホルモン」という言葉は、内分泌攪乱物質を正確に言い表す表現ではないものの、認知度を向上させたという観点では大変優れたキャッチコピーだと思います。ここで地球高温化の例に戻って考えてみます。環境ホルモンの認知度を上げたのが「危機感」によるものではなく、「より実感がもてるかどうか」によってもたらされた結果と考えると、「地球高温化」という単なる煽りは無意味であるだけでなく、そもそも地球温暖化の現象を適切に言い表してもいません。技術者畑で育った僕としては、正確な意味に従った名称をつけようという考えが働きますので、名称をつけるなら内分泌攪乱物質のような難しい言葉を使うでしょう。そこに営業畑で育ったインパクト重視の横やりが入ると、いつのまにか今回のような地球高温化のようなヘンテコ名称に陥りそうな気がします。気をつけないと。
「地球温暖化」では表現が手ぬるいとして地球高温化と呼ぼうという試みを川口市が始めたそうです。けど、個人的には的外れにもほどがあるという印象。実感として高温なほど気温は上昇しているように感じないから現実感がなくなる。温暖化という、ゆっくり進行する事象が多大な影響をもたらすという静かな恐怖感の方が、イメージにしっくりくる。安易に強い表現の言葉を使いたがるのは稚拙な印象しか持てない。
高温化って言われたら日照りで砂漠化していくことしかイメージできない。温暖化では地球の平均気温が現状よりたった2度あがるだけでも、人類の生活に深刻な影響を与えるという境界線「Point of No Return」が存在する。たった「2度」は高温化という言葉で認識している人にとってはかえって危機感がもてなくなってしまうのではないかと少し心配。稚拙な表現で小さな揺動を起こすより、しっかりと教育によって認識を高めてほしい。
社名の表記に含まれる形態を示す単語は結構いろんなバリエーションがあります。たとえば「株式会社」とか「合名会社」とか。日本でのバリエーションはずいぶん前に(たしか何かの会社マスタデータベースを設計するときに)調べたので良かったのですが、最近なんとなく英語表記も気になってきたので調べてみました。まず、前職のSun Microsystemsの場合、Sun Microsystems, Inc.で、現職のACCESSの場合、ACCESS CO., LTD.です。他にもいろいろパターンがあって、McKinsey&Companyのようなパターンもありますし、LLCとか、イギリスならPLCとか。他各国のパターンはTypes of business entity [Wikipedia]から参照することができます。今回知りたい英語表記のCo. Ltd.とか、Inc.あたりの違いを詳しく説明しているサイトがありました。Co LtdとIncの意味の違い (日向清人のビジネス英語雑記帳)。

日向清人さんの説明によれば、ACCESS CO., LTD.や、Sun Microsystems, Inc.のような表記中のカンマ (,)は不要で、ACCESS CO. LTD.やSun Microsystems Inc.のように表記するのが本来だ、とのことです。他のサイトでこの、カンマについて少し調べましたがだいたい同じ結論でした。一番納得したのは、おそらく日向清人さんの記事を元ネタとしてフォーラムに質問されたポスト [Co.,Ltd. and Co Ltd. - englishforums.com]へのKathrinさんのコメント。
I think the problem is linked to companies in Asia. There are to many abbreviations and this is pointless. Co is a common abbreviation for company and Ltd for a private limited company in the UK. There is no need for a comma. But I can imagine that the very first use was a kind of mistake by chance and after that they are in the situation of no escape. They would rather stick to the mistake then correct it. I have seen ABC Co., Ltd. a lot but this doen’t make it right:-) Though meanwhile it is already custom:-)
最後の、「Though meanwhile it is already custom (とはいえ一方で、それはすでに風習になっている)」は何とも説得力があります。「重複」の読みが「ちょうふく」なのか、「じゅうふく」なのかを議論しても読みが普及してしまった今、どちらが正しいかを議論しても意味がないのに似ていますね。

ブログのデザインを微調整しました。どうも記事本文の文字が小さくて読みづらかったので、12ptから14ptにしました。あと、行間が詰まっていて読みづらかったのでline-heightも16pt(行間4pt)から24pt(行間10pt)にしました。ブログのデザインテーマは、見栄え重視で小さい文字・狭い行間であることが多いのですが、個人的にはそれでは目が疲れて読みづらいので文字は14ptぐらいが好きです。行間を空けると、今使っているテーマのように白ベースのテーマでは、全体的に寂しい感じがしてしまいますが、これも読みやすさを重視しました。だいぶ前に変えてたつもりでしたが、テーマのバージョンアップの際に消えてしまっていたみたいです。
昨日と今日で2冊読み終わりました。全部読んだと言うよりは、読んだことにしたというニュアンスの方が近いかも。1冊目は、ワインバーグのコンサルタントの秘密という本。コンサルタントとして働いていたワインバーグの経験則や、教訓がまとめられた本。元著者のワインバーグが理系的知識をくすぐるように書いたように思えるのに、訳ではあまりそのあたりをうまく表現できていなかったのが残念。たとえば、「奇妙コーク」という単語。なんのことやらさっぱりわからなかったけど、途中でこれがストレンジクオークのことだと気づいた。他にもいくつか訳語の意味が分からなくて、あれ?って思ったところはあるけどまあ本質的な問題ではないのでおいておきましょう。全部を読むのをやめて、「読んだことにした」理由はあまりにも「〜〜の法則」とか「〜〜の秘密」というようにもったいぶっている箇所が多すぎたからでした。彼の法則に従うなら、これこそラズベリージャムの法則です。何を主張したいのか分からないし、まじめに読んでも記憶に残らなさそうだったので読むのをやめました。でも、最後にたくさんある法則がインデックスでまとまっていて、その7ページには簡単な法則ごとの説明も書いてありました。正直なところ僕にはこの7ページだけで十分でした。本を買った価値としても、この7ページで十分でした。

2冊目は、図説 実例でわかる!コトラーに学ぶマーケティング?ぜんぶ日本の実例で解説!いますぐ「使える」発想術! という本。ドラッガーの本で手元にあるやつがだいたい読み終わったので次はコトラーかなと思って、ブックオフで探して買ってきた本です。この本は今日読み始めて、今日読み終わりました。図解ということで、文字が少なかったこともありますが、何より内容がチープな感じでした。執筆当時、新聞・雑誌などのメディアで華々しく紹介されていた製品・サービスを取り上げて、それが以下にすばらしいかを、報道の通りに説明しているようにしか読み取れませんでした。少なくとも、どのへんが「コトラーに学ぶ」のポイントだったのかは全く分からないままでした。ただ、興味深かったのは本書で紹介されていた、ほとんどの注目すべき製品やサービス、ビジネスモデルが出版から4年経った今、当時の思惑通りに事業が展開できなかった点です。100年に一度と言われる、この不景気が広く認識される前に、すでにそれらの多くは衰退していました。4〜5年前の空気感をリマインドするという意味ではとても良い本でした。
蛇足ながら、前エントリ「Re: プログラミングに誇りを持ちたいなら単価を上げること」に少し補足しておきます。前エントリではプログラマの単価が、プログラマの能力や成果にほとんど関係せず、組織の力によって決定されると書きました。この顕著な要因として、与信とバックアップ体制があります。どちらも仕事がうまくいかなかった場合にはじめて実質的な効力が発揮されますが、商談前から検討項目としてあげられる重要な要素でもあります。単価に、ある程度のリスクに対する対応料金が含まれると考えることができるかもしれません。ある程度、大規模な開発案件になれば個々のスキル差による生産性の違いよりも、よりわかりやすくリスク回避できる方法が好まれるように感じるので、プログラマの単価とスキルの関係性はますます薄れるはずです。

この問題の難しいところは、生産性の高いプログラマ、アーキテクト、テスターに対して実際の生産実績と報酬を結びつける恒常的で有効な方法が発見されていないことにあると思っています。たとえばEarned Value Management System (EVMS)によって生産を管理しても、バグ発生による手戻りの影響は統計的な推測ぐらいしかできず、生産時やバグ修正時における各個人の働きがどの程度生産に影響をもたらしたかを管理することはできそうに思えません。生産活動を管理するという視点ではEVMSは強力なツールでえすが、知的財産の生産管理や評価に対して最適なツールであるとは思えません。数年前にPMBOKの講習を受けたままで、あまりプロジェクトマネジメントの知識はアップデートしていませんが、知的財産の生産に対して有効な管理手法が発見されたとは聞かないので、まだ発見までには時間がかかるのでしょう。
ひがさんの記事が盛り上がっているようなので話題に参加しておきます(^^;
個人的な感覚として、単価を上げる原動力は組織の力であって、プログラマーの能力とは直接関係しないと思っています。ひがさんはコミュニケーションオーバーヘッドから品質と単価の関連性を指摘されていますが、それは直接的にプログラマーの単価に影響を及ぼすことはほぼないというのが個人的な感覚です。なぜならば、一人のプログラマーがいかにすばらしい成果を出すとしても、それが単価、つまり通常発注する平均価格を吊り上げるためにはあまりにも影響力が少ないと感じるからです。今日のシステム構築は大規模かつ複雑なものが多く、一人二人ですべてを作り上げることはほとんど無理です。このため、仕事は社内であっても、社外であっても組織に対して発注されます。単価とは、この組織が働くときの評価額であって、個人の評価や、成果物の評価とはあまり関係しません。

ある組織のAさんが、常によい成果をもたらすとしても、Bさんが足手まといとなるなら単価をあげる交渉をすることは難しくなるでしょう。このとき、Aさんをシニアプログラマ、Bさんをアシスタントプログラマというようにジョブタイトルを分けて単価評価を分けることもできますが、それは組織をジョブタイトルによって分割しただけで、プログラマー個人のAさんとしての評価ではありません。あるスタープログラマーの知名度を利用して、ジョブタイトルや組織のブランド力を高めることができるかもしれませんが、実際にそこまで一個人のプログラマーが組織に対して影響力が与えられるケースはあまり多く見かけません。

あるプログラマがご指名で、単価を提示されることがあるかもしれません。これは、確実にそのプログラマ個人の評価です。ただ、組織としてご指名でプログラマを切り売りするのは、ビジネスとして難しいかもしれません。組織には、ベースラインとなる能力レベルはあっても、個々に見れば能力の高い人もいれば低い人もいて、安定的に仕事をすることを考えれば、相対的に能力の低い人がしばしば仕事がない状態では組織としてうれしくありません。能力の低い人にも、現場で活躍し、売り上げをあげ、また能力を伸ばしてもらいたいと考えます。このため、営業やプログラマのマネージャはまんべんなく仕事が割り振られるように、ご指名での差別化された単価で仕事を受注することに躊躇すると思います。単価が決まる過程は組織、業種、業態によってさまざまかと思いますが売る側、売られる側という最低二つの側面から考えても、個人の能力や成果によって単価を向上させるのはかなり難しいだろうというのが個人的な感覚です。プログラマがいかにがんばろうとも、ビジネス上うまく行かなかったシステムに対して多くの単価を支払うことは、心理的に抵抗感が生まれて不思議はありません。プログラマがいかに成功しようとも、ビジネスコンサルに失敗していたら十分な対価を気持ちよく支払ってもらうことは難しいはずです。お客様からみれば、ビジネスコンサルもプログラマも、自分のビジネスを支える「組織」です。

ところで、今回のもともとの話はプログラマの地位についての話だったと思います。地位とは、いろんな解釈があります。給与や単価もそうでしょう。しかしながら、プログラマ個人として単価の向上が難しいため、方向性としては別の価値観を模索すべきではないかと思っています。単価はあくまで組織として向上を目指すべきですし、組織を管理する者の責任でもあるはずです。小規模な、売り切りのソリューションを構築する以外の場合、個人の努力によって単価を向上させるのはかなり難しいはずです。このため、プログラミングに対する誇りは間接的な「お客様の評価」を向上させたこと以外に難しく、直接的な対価として数値化することは不可能とは言わないまでも、ほとんどの場合無意味でしょう。地位とは、単価だけでなく、尊敬されることによっても確保されると思います。個人的に、いちプログラマとしては単価が向上するよりも、より尊敬される存在になるほうを重視したいと思っています。より尊敬されるためには、より美しいコードを書くよりも、よりビジネスに役に立つコードが必要なことを理解していなければならない点に注意しなければならないのですが、報酬を向上させるためだけに働くのならば、いずれ売る側と買う側の対立という基本的なビジネス構造の壁にぶつかり「プログラマの地位を向上させる」という基本的な目標を忘れ、場当たり的な行動に出るか、単に仕事を投げ出してしまうことになりかねません。抽象的な結論ですが、プログラマは尊敬によって評価されるべきであり、単価向上を目標とすべきではないと考えます。
Firefox日本語版を入れて、右上の検索ボックスを使うとGoogle側の個人設定の如何に関わらず、日本語が検索対象として選ばれます。技術系のネタは英語も対象にしたいので、できれば「すべての言語」を対象として検索してほしいので、そのように変更します。/Applications/Firefox.app/Contents/MacOS/searchplugins/google-jp.xmlというファイルを編集します(Windowsの場合は C:\Program Files\Mozilla Firefox\searchplugins\google-jp.xmlだと思います)。例によって編集前にバックアップをとっておくことをお忘れ無く。

このファイルの Paramエレメントの lrというパラメータを渡しているところのvalueを空欄にしましょう。そうすればすべての言語になります。一方、読めない言語(僕ならドイツ語とか中国語とか)を省きたいなら lang_ja|lang_en のように読める言語だけを | でつなげれば複数言語を指定することもできます。


