私家版 ITプロフェッショナルの仕事術

本書は、文字コードに関わるITエンジニア必読の書である。と言うことは、全てのITエンジニアが対象ということになる。「プログラマのための」と銘打っているが、サポートエンジニアでも運用エンジニアでもプリセールスSEでも、メールやブラウザなどで文字化けを見た経験があるはずだ。ブラウザのエンコーディングの設定を変えれば治ることがある。日本語ファイル名が文字化けする可能性があるからASCII文字でファイル名を付けて交換するという対処はよく行われる。本書を読めば、文字化けの根本原因が理解できるようになる。

Webの断片的な情報で文字コードを理解しようとすると、どこから手をつけていいのか、この情報とあの情報の関係はどうなっているのかなど、路頭に迷ってしまう。根本原因を知るには、文字コードの規格だけでなく、歴史や規格の背景まで知る必要がある。そして文字の背景には文化も存在し、それを避けて通ることがことができない。本書はこれらのテーマをとても分かりやすく体系立てて解説してくれる。Shift_JIS、EUC-JP、Unicodeなどの文字コードをていねいに解説したあと、文字コード変換やインターネットでの文字コードの実装、JavaやRubyでの文字コードの実装、そして代表的なトラブルの対処方法として「全角・半角問題」「円記号問題」「波ダッシュ問題」を取り上げている。これは、これまでの知識の応用例でもある。

著者の次の言葉が非常に印象に残った。

本書では上記の各種トラブルについて、文字コードの原理原則に立ち返ったうえで現象の意味を考察しました。こうしたやり方は一見迂遠で理屈っぽいように映るかもしれません。しかし、小手先の対症療法でない本質的な解決のためには、原理に立脚した議論が必要であるはずです。

本書で述べていない別のトラブルに遭遇したときにも、文字コードの原則に基づいた考察方法は確かな視野を与えてくれるはずです。

（「第8章 はまりやすい落とし穴とその対処」より）

これもまた、原理・原則アプローチのひとつである。表面上の現象やテクニックだけでなく、その背後に潜む原理・原則や、物事に対応するときの原理・原則を身につけておけば、さまざまな場面で応用が利く。

文字コードというテーマは、書籍でなければきちんと論じることができない部分がある。例えばひとつの文字コードに包摂されている複数の字体を例示するとき。あるいは、JIS規格の版によって字形が変わってしまったもの。そしてJIS X0213で追加された第3水準・第4水準漢字を扱うとき。これらの文字コードの字体は、OSやブラウザ、インストールされているフォントに依存する。書き手の意図と異なる字体が自体が表示されてしまう可能性がある（注）。読み手全てが同じ字体を見ることができるというのは、書籍の大きなメリットである。

（注）字形が変わってしまいそうな箇所を画像にするという手はあるが。

「日経コンピュータ」（2008年12月15日号 ）が、インドソフトウェアサービス協会会長ガネッシュ・ナタラジャン氏のインタビュー記事を掲載している。インドや日本、中国の国民性について興味深いことが書いてあった。

日本人はシステマティックにプロセスの順番を踏まえて考えるが、インド人はショートカットして結論を求めがち。インドはインフラが整備されていなくて渋滞が多い。常に新しいルートを考える必要に迫られる。このため「なぜだろう」と常に考える国民性が醸成された。この点は、社会インフラが整備されている中国に比べて優位点である。

こういった文化論は、ともすればステレオタイプに陥りがちで危険ではある。日本人、インド人とひとくくりにできるほど人間は単純ではない。とはいえ、インドのエンジニアと一緒に仕事をしていて物事の進め方に違和感を感じたとき、それも一理あると受け入れられるような視点を持っておくことも必要である。幸いにして、私がふだん接しているインド人ソフトウェアエンジニアたちには、それほど違和感を感じない。

大西とマクベイの「ハートで感じる」シリーズを先に読んだほうがいいだろう。この本は解説がちょっと高度でわかりにくいかもしれない。しかし、「ハートで感じる」シリーズで取り上げないような高度で微妙なニュアンスの表現も出てくる。仕事の内容によっては、こういった表現が必要になってくるだろう。特に政治的交渉を行うマネージャ以上のクラスは、意識して身につけておくべきであろう。

前書きでミントンが書いているのが、「言語感覚」に基づく直感力は文法知識に勝るということ。言語感覚を身につけるには、長期間にわたって大量の英語に晒される必要がある。全くその通りで、1日30分の勉強で英語が身につくという広告をよく新聞や雑誌の広告で見かけるが、そんなことはありえない。

24ページ
現在形はいつでも成り立つ状況に使う。出来事や動作には使えない。現在進行形は一時的に成り立つ状況に使う。

33ページ
一般論を展開するときは名詞の複数形を使う。不定冠詞を使うか複数形を使うか悩むことがあるが、定冠詞aには「1つの」という意味が含まれる。一般論は複数の集合に対して言及するのだから「an elephant is big」ではなく「elephants are big」とする。

40ページ
定冠詞theはとにかく唯一のものを表す。関係代名詞で修飾されているからという理由でtheを付けたくなることがあるが、関係代名詞での修飾の有無とtheを使うかaを使うかは無関係。それぞれ別の意味になる。the man you can rely onは、信頼できる人が世の中にその人ただひとりと言うこと。a man you can rely onは、何人かいる信頼できる人のうちのあるひとりという意味。

44ページ
過去形 + already。ネイティブも使う表現だが、いい加減な物言いに聞こえる。通常は現在完了形とともにalreadyを使い、もっと長くかかると思っていたのに、もう完了してしまったと言うことを表す。

46ページ
現在完了形は現在とのつながりを感じさせる。過去形は既に終わってしまったこと。大西とマクベイは現在完了形を「「迫ってくる」,過去形を「離れている」と表現した。

54ページ
「最近」を表すのはlatelyよりrecentlyの方が安全。実際、recentlyのほうが多く使われる。latelyは、近い過去から現在まで延びているような期間を表す用法しかなく、現在完了形でのみ使われる。さらにたいていの場合否定文と疑問文で使われる。muchやa lotと一緒であれば肯定文でも使われる。

57ページ
justはexactlyよりonlyの意味で使われることが多い。

61ページ
現在完了形は行為が終わっていることに焦点があり、現在完了進行形は行為そのものや、その行為がどのくらい長く続いているかに焦点がある。

68ページ
過去の出来事を順番に並べて述べるときは、すべて過去形を使う。大過去を表す過去完了形は使わない。

86ページ
命令形は所詮命令形。pleaseをつけようがwouldなどを付けようが、本質的に丁寧な表現ではない。

87ページ
日本語の否定疑問文は丁寧さを増す表現であるが、英語ではそうならない。日本語の「～ではないでしょうか」「～してくれませんか」を英語の否定疑問文で書くのはやめたほうがいい。失礼なニュアンスになり得るので要注意。使わない方が無難である。

たとえば「Will you～」はもともと丁寧な依頼ではないし、その否定疑問文「Won't you～」も同じ（16ページ）。「Can you～」は友人に何かを頼む場合に使われる表現である。目上の人やビジネスシーンで使ってはいけない。たとえ友人であっても「Can't you～」は、やってもらえるはずと思っていることをまだやってくれていないのでイライラを表現するときや、一度断られた依頼を別の形に変えて依頼するときに使うものなので、普通の依頼のときに使ってはいけない（87ページ）。

92ページ
許可を求めるときは「May I～」がもっとも安全。友人なら「Can I～」でもよい。possiblyを付け加えると丁寧度が上がる。

98ページ
「Don't you mind～」に対して許可を与える場合はNoで答える。しかしネイティブもNoと言うことに居心地の悪さを感じている。そこで何かを付け加える。Not at allやAll rightなど。

110ページ
mustは、それが必要だと個人に感じていること。have toは客観的事実。迷ったらhave toを使う。

138ページ
「know 人／場所」は、その人を実際に知っていたり、その場所を実際に訪れたことがある場合のみに使える。そうでない場合は、know the nameやhave heard ofを使う。know ofは古めかしく響く。

141ページ
使役表現
let。相手はやりたいと思っているが、自分はやって欲しくないと思っていること。
make。相手はやりたくないと思っているが、自分はやって欲しいと思っていること。
have。相手がやってくれると期待できる権利がある場合。
got <ものごと> done。やり遂げるのに時間がかかること。gotには動作のニュアンスがある。

146ページ
keep ～ing。必ずしもcontinue ～ing／to doとイコールではない。短い動作、そしてどちらかというとイライラさせることをを繰り返し行うこと。keep laughingは、ずっと笑っているわけではない。断続的に笑っていること。

調べたことや考えついたことのメモをどうやって保存するか。誰もが悩んでいるはずだ。だから、「情報は1冊のノートにまとめなさい
のようなハウツーものはよく売れる。最寄りの駅前の書店でビジネス書売り上げナンバーワンだそうだ。

この本が提唱している方法は実にシンプルで気軽に始められる。だから、ぱらぱらと立ち読みで眺めて、よしこれをやってみようという気になって買っていく人が多くても不思議ではない。私もつい買ってしまった。

・1冊のA6ノートに書いたり貼ったりして、すべての情報を一元管理する。
・時系列に書いたり貼ったりする。カテゴリ分けをしない。
・日付・タグ・見出しだけの索引をテキストファイルで作る。

カテゴリ分けはすぐに破綻する。だから私はメールをプロジェクトや顧客ごとに振り分けるのをやめた。情報発生時点のカテゴリ分けは、パソコンでの検索という手段が使えなかった時代のものである。

シンプルだからといっても、この本に書いてあることをそのまま実行しても長続きしない。奥野氏が書いているように、「自分の開発した方法は（その人にとって）必ず最高」なのである。ハウツーものを参考にして「自分流にアレンジする方がいい」。

現在の自分のやり方を振り返ると、情報が分散しすぎている点が課題だ。

ロディアNo.12
一時的なメモ。そのうちほかの場所に転記。転記が滞って長期間居座っているページもある。

メール
自分宛のメールでメモを残すことがある。

はてなダイアリ
非公開のはてなダイアリに、ロディアなどからメモを転記している。デジタル化して検索可能とするため、読んだ本の一節を書き写すこともある。

ほぼ日手帳
日記として使い、仕事に限らずプライベートの記録を書き綴っている。展示会のチケットや新聞記事をスクラップすることもある。

このブログ
これはアウトプットである。様々な場所の情報をまとめて、記事として完成させる。

Outlook予定表
行動予定と行動記録。過去の出来事を振り返るときのインデックスになっている。検索にGoogleデスクトップを使う。

Outlook仕事
アクションを起こすべきものはロディアやメールから転記してアラームを設定している。予定表と役割が重複していて、だんだん使わなくなってきた。

紙Copi
メモ管理ソフトとして使っていたが、新しい情報を書き込むことはなくなった。過去の情報だけが残っている。どこかに移し替えなければいけない。

奥野氏は索引をテキストファイルで作り、会社のPCやスマートフォン（ソフトバンクX02HT）に保存していつでも検索できるようにしている。私なら、これをWebの「あちら側」に置き、バックアップをPCに保存する。Webの「あちら側」にあれば、スマートフォンは必要なく、携帯電話でも他の人のPCでも検索できる。

Webの「あちら側」に索引を置き、複数箇所に分散している情報を一元化する。はてなダイアリかGmailがその解決策になりそうである。もう少し考えて自分のオリジナルな方法を見つけるつもりだ。

ポッドキャスト「@ITナナメ読みウィークリー」3月4日号の中から、＠IT発行人編集長の新野淳一氏とIBMエバンジェリスト米持氏の対談の要約。
http://www.itmedia.co.jp/enterprise/podcast/naname.html

IT エンジニアの人気が日本の若い人たちの間で低下している。「3K（きつい、給料安い、彼女できない）」がその原因と言われる。実際にきつい仕事なのは確かだが、自由度が少ないことも問題である。

建築業界と同じような考え方で、一箇所に人を集めて拘束し、なるべく安くたくさんのものを作ろうとする考えが強い。会社の生産性は評価されるが、個人の生産性を評価しない。創造性をプログラマに求めていない。結果として、ゲームやアニメ業界に人材が流れる。

アメリカのプログラマは自由度が高い（日本と似た現場もあるが）。科されたノルマを達成すれば、いつどこで仕事をしようが関係ない。基本的な「モノの考え方」が違う。

自由度もそうだが、日本でプログラマとSEを比べると、どうしてもプログラマの地位が低い。要件定義ができて仕様書を書けるSEが上で、仕様書に従ってプログラムを書くプログラマの方が下に位置づけられる。実際、平均給料もプログラマのほうが低い。私が日本のITベンダーでシステム開発業務に携わっていたとき、原価を計算する単価は三段階に分かれていて、一番下がPG（プログラマ）だった。

IT 業界の人気を回復し、IT産業を支えるプログラマの地位を向上するために、まず「SE」「プログラマ」という区別を止めるべきではないだろうか。少なくとも、プログラマはSEの下に位置するという序列を止めたほうがよい。よしんば「SE」としてシステム設計を行うとしても、プログラミングのスキルが基本である。いいシステムを設計するには、プログラムがどう動くかという理解が欠かせないはずだ。プログラマのチームを適切に導くにも、彼らの仕事内容をきちんと理解できる素養が必要である。

ジャーナリストの佐々木俊尚氏が、アーキテクチャとしてのジャーナリズムが台頭してきていると語っている（参考記事1）。従来のメディアは、記者や編集者、ジャーナリストたちが作っていた。彼ら・彼女らが自分の意志を持って世の中で起きていることを報道するのが従来のジャーナリズムだった。そこには人間の恣意的な意志が入る。これに対してブログやSNSに代表されるメディアは、自動化されていて人間の判断が入らない。それこそが公平であり、メディアとしてあるべき姿と考える。そこでの情報のやりとり自体がジャーナリズムとなる。これはジャーナリストのいないジャーナリズムであり、アーキテクチャとしてのジャーナリズムであるというのが佐々木氏の主張である。

新聞やテレビ放送などを指す「メディア」という言葉は、実は2つの役割を総称している。ひとつはメディアという言葉通りの役割、つまりなにかを伝える「媒体」である。もうひとつは、媒体の上を流れる「コンテンツ」やその「制作者」である。メディアという言葉は、媒体を指したりそのアウトプットのコンテンツを指したりしていたが、これからは二つを使い分けなければいけなくなっている。それは、これまで新聞やテレビ局の独占的所有物であった「媒体」を、インターネットによって個人が持てるようになり、個人が新聞やテレビなどと同列の「メディア」となる機会が得られたからだ。

佐々木氏の言うアーキテクチャとしてのジャーナリズムは、コンテンツを恣意的に加工しない媒体の上で、各自がそれぞれの意見を交換することで成り立つ。これに対して旧来のメディアは、媒体自体が恣意的にコンテンツを制作し加工することができた。新聞の社説がその典型だ。報道記事にも記者の考えや視点が含まれていて、決して事実そのものを伝えてはいない。

そもそも、人がなにかを取り上げてものを書くという行為自体に、その人のものの見方が反映されている。従って客観的報道というものは決して存在しない。全ての報道は記者の主観で成り立っている。統計値などのデータは客観的事物だが、どのデータを記事に取り上げるか、どんな文脈でそのデータを使うかで、記者の数だけ結論も異なる。

中田英寿が引退するとき、記者会見を全く開かず、自分のホームページに例の文章を載せて、その後どこで何をしているのか全くわからなくなった。このことについて日経ビジネスの井上編集長（当時）が憤慨していた（参考記事2）。ひとつは中田に対する憤慨で、要人であり公人と言ってもいい中田は、引退のような重要なことについては記者会見を開くべきであるということ。もうひとつは、中田を全く捕まえられず、ほぞを噛むだったメディアに対する憤慨で、中田に質問するなどしてその真意を確かめ報道するべきだったという批判だ。

なぜ中田はこういう方法を採ったのだろうか。彼のマスコミ嫌いは有名だった。テニスの伊達公子や以前のイチローマスコミ嫌いと言われていた。おそらく、自分の発言の真意が伝えられず、曲解されたり、おもしろおかしく伝えられたりすることに嫌気がさしたのだろう。記者の主観が過度に付け加えられたコンテンツによって、媒体としての信用をマスコミは失ったのだ。記者会見を開いてもらえなかったメディアは、自業自得といえる。

ブログやSNSは、コンテンツ制作者の意図をそのまま伝えることができるから、媒体として理想的と思われる。あとはその上に載せるコンテンツの質が勝負だ。そして忘れてならないのは、それを読む側にもある一定のスキルが求められるということだ。

先ほど書いたように、全てのコンテンツには制作者の主観が反映されている。社説などは明らかに主観的文章であるとわかるが、客観報道に見える記事は要注意だ。例えば、記事に使われた写真やそのキャプションだ。ある人を非難する記事に、その人の不機嫌そうな表情の写真が載っていることが多い（例えば最近の朝青龍報道）。人間はいつも笑っていられるわけではない。実際には不機嫌でないのに、不機嫌に見える表情をすることがある。その一瞬を偶然とらえた写真を批判的内容の記事に使って、記者の主張を補強している可能性はないか。そういったことを見抜く力が必要だ。例として、読売新聞2008年1月29日付朝刊に載った写真を引用しておこう。この男性は、本当に相場の急落で頭を抱えているのだろうか、それとも頭が痒かっただけなのだろうか。

参考記事1
アイティメディアキーマン対談
ネット時代のITとメディアの関係について──ジャーナリスト 佐々木俊尚氏に聞く
http://www.itmedia.co.jp/enterprise/podcast/keyman.html
http://stream.itmedia.co.jp/podcast/keyman/20071221.mp3

参考記事2
日経ビジネスPodcast「編集長の終わらない話2.0」
http://business.nikkeibp.co.jp/article/podcast/20060730/107142/
2006年7月10日号「格差の世紀 Global Gapitalismを誰が止めるか」（バックナンバーなし）

アルクの広告パンフレット「学びカタログ春号2007」に載っている関橋英作氏のインタビュー記事。関橋氏は外資系広告会社JWTのクリエイティブコンサルタントで、「ある日、ボスがガイジンになったら!?」の著者。

「英語で何より大切なのはコミュニケーションスタイルを理解すること」。このコミュニケーションスタイルとして関橋氏が例示しているのが、（1）物事を曖昧にしておきたがる日本人に外国人がフラストレーションを感じるケース、（2）日本人がよく使い外国人に評判の悪いフレーズ「日本は違う」、そして（3）欧米人の超ポジティブな考え方"Can-do"精神の3つ。

（1）は、「島国で何千年もいっしょに暮らしてきた日本人」と、「国の形がしょっちゅう変わってきた歴史を持つ欧米人」の文化的背景の違い。「イエス・ノーをはっきりさせ、自分が言いたいことを主張して闘う」欧米人とコミュニケーションするためには、日本人が好む曖昧さを意識的に排除するべき。

（2）は、私もつい使いたくなる。もちろん文化の違いを理解しなければならないが、違いを強調するだけでは物事は先に進まないと関橋氏は主張。

まず、ゴールを共有していることを確認し、その上で、ゴール到達のための、別のアプローチを提案する。日本人は細かい差異にこだわりがちですが、それは不信感を高めるだけ。ゴールを共有していることがはっきりすれば、こちらの話に耳を傾けてくれますよ。

もっとも、その細かい差異へのこだわりが、日本の工業製品の過剰とも言える品質を支えてきたというプラスの側面を忘れるわけにはいかない。「小異を捨てて大同につく」と「微に入り細をうがつ」。この2つのバランスを取る意識が欠かせない。

できそうもないことをやろうというのが（3）の"Can-do"精神。「"Can-do"とは"できる"というより、"やろうと思わなければ何もごともできない"という考え方」。「日本だとできなければ"失敗"だからできるかできないかにこだわり、"不可能だ"と言う」。これが「ガイジンにはネガティブに映る」。単純化しすぎるかもしれないが、減点方式の学校教育やテストがその背景にあるのは、当たらずといえども遠からずだろう。

「失敗は成功の元」「雨降って地固まる」。日本の学校教育でもこういう言葉は言い習わされているから、失敗が取り戻せないものでないことはわかってはいるはず。それを社会で実践できないのは、学校教育だけでなく、大人全員の責任だろう。多少の失敗を大目に見て、褒めて伸ばすことが必要だ。

関橋氏が薦めるコミュニケーション力向上策が、外国人との英語コミュニケーション。ハードルの高い外国人とのコミュニケーションで訓練すれば、日本人同士でのコミュニケーションも向上するはず。そして究極の策が外資系企業への転職。

実力主義の外資系企業で頑張れば、コミュニケーション力はつくし、英語も習得でき、おまけに出世もついてきて、一石三鳥になるかもしれませんよ。

出世できるかどうかは英語以外の実力も必要だから、一石三鳥のくだりは少々大げさだ。しかし、それを割り引いても、外資系企業で外国人とのコミュニケーションを日常的に行えば、日本人とのコミュニケーション力向上に役立つという意見には賛成だ。外資系企業でも、日本人としか相手にしない職種やポジションだと、日本企業で働いているのと変わらない。海外の人間と頻繁に関われる部門を目指す必要がある。