ナンバリングしよう

久しぶりに大阪の地下鉄を利用したら、駅や車内に表示されている駅名に、アルファベットと数字からなる番号が併記してあった。「何を今更」と思われるだろうが、田舎に住んでいるとそんなものである。「駅ナンバリング」というらしい。大阪には 2004 年に導入されたのだそうだ（※１）。

その周辺の地理に詳しくない人や、日本の地名に馴染みがない外国人にとっては、駅の名前よりも番号を使う方が、識別や伝達が確実だ。どうして、もっと早くそうしなかったのだろう。

IT の世界では、データに番号（コード、ID、インデックス）を付けて管理するというのはよくあることだ。例えば、データベースの「商品テーブル」には「商品名」だけでなく、「商品コード」をつけて管理する。逆に「名称」の項目があって「コード」がないようなテーブルがあったとすれば、不自然さを感じてしまうのではないだろうか。IT 業界の人間にとって、「ナンバリング」はそのくらい馴染みがあるものだ。

しかしである。この業界でも、時々、ナンバリングされていないために不便を感じることがある。例えば、会議の場で「ページ番号」が付いていない資料が配布されることがあるのだ。しかも、そういう資料に限って、「行番号」が付いていない表が載っていたりする。すると、

「えーと、後ろから３枚目の、下から７行目の件ですが・・・」

などというテンポの悪い会議になってしまう。会議だけではない。電話でも同じような経験をすることがある。

少なくとも、それを見ながら会話をするような資料には、きちんと「ナンバリング」をしておきたいものである（※２）。

応援のクリックお願いします →

※１
日本では2002年のFIFAワールドカップにあわせて横浜市営地下鉄で採用されたのが最初のようだ。ちょうどその頃は横浜にいて毎日乗っていたはずなのだが、どういうわけか覚えていない・・・。

※２
番号を付けると後から変更しにくくなると考える人もいるかもしれない。確かに、後からページや行を挿入すると、古い資料と番号が合わなくなる。しかし、それも改訂ごとに資料にバージョン番号を明記するようにすれば、問題ないだろう。

これだけは知っておきたい「ビジネス文書」の基本と常識
―ビジネス文書の基本から作成まで、この1冊でOK!

posted with amazlet on 07.05.14

東京スクール・オブ・ビジネス
フォレスト出版(株 (2007/04)
売り上げランキング: 60750

おすすめ度の平均:

CDが使いやすい！

Amazon.co.jp で詳細を見る

鉄道検定
―路線、車両、駅、時刻表、切符、駅弁、歴史
-7科目からの出題で“鉄道力”を総合判定

posted with amazlet on 07.05.14

河出書房新社 (2007/03)
売り上げランキング: 108671

Amazon.co.jp で詳細を見る

ITエンジニアの年収

連休中、溜まっていたフィードの「未読」を片付けていると、ITエンジニアの年収に関する情報がいくつかあった。考えてみれば、このブログでは、収入に関する記事はあまり書いていなかった（筆者が惨めな気持ちになるからだろう）。しかし、「これからプログラマを目指す人たちへ」などと銘打っているからには、少しは触れておいたほうがいいかもしれない。

まず目を引いた情報は、「＠IT年収MAP 」というサービスだ。自分の年齢と年収（適当でも良い）を入力して検索すると、年齢×年収のグラフに、２万人のITエンジニアのデータがプロットされる。会員登録すれば、スキルなどの条件でより細かく絞り込むことができるようだ。あわせて、「ボクらの生きざまSHOW! ＠IT年収MAP　セルフレビュー」というブログ記事（カテゴリ）も見てみると面白い。「ITエンジニア35歳定年説は本当か？」とか、「何歳までにチームリーダーになればいいの？」といった、年齢に着目した利用例もある（※）。

また、＠IT自分戦略研究所には、「あなたはどの位置にいる？スキルと年収の関係を探る」、「IT系は本当に給料が安い？ 2万人の年収比較！」といった記事があった（前者は＠IT年収MAPと同じデータを分析したもの）。年収の「相場」といったものは、なかなか分からないものだ。このように多くのデータに基づいた情報は一見の価値がある。

あとは、検索で見つけたものだが、テクノブレイン（アデコ）の「エンジニア仕事マップ」も紹介しておこう。職種の説明と一緒に時給、年収の相場が分かるようになっている。派遣向けのサイトだが、この業界の仕事の内容と給与について知りたい人にはよい情報だろう。

最後に。こうしたページを見ると、ある程度、自分に近い条件の人の収入を知ることはできる。しかし、自分のスキルや仕事の内容が、他人と全く同じであることはありえない。あくまでも参考程度に考えるべきだろう。そして、仕事をして得られるものはお金だけではない、ということも忘れないようにしたい。

応援のクリックお願いします →

※このサービスに限らず、こうしたアンケートデータへのアクセスを Web API 等で公開すれば、面白い分析をしてくれる人が出てくるかもしれない。

■関連記事
・プログラマは誰でも同じ？
・続・プログラマは誰でも同じ？
・プログラマ35歳定年説に思う

ITアーキテクト x コンサルタント未来を築くキャリアパスの歩き方

posted with amazlet on 07.05.06

克元亮
ソフトバンククリエイティブ (2006/08/30)
売り上げランキング: 44257

おすすめ度の平均:

コンサルタントとITアーキテクトの違いが分かった。

事前知識"0"でも大丈夫

個々人のキャリアに特化した良書

Amazon.co.jp で詳細を見る

勝つDBエンジニアのキャリアパス

posted with amazlet on 07.05.06

斎藤直樹
翔泳社 (2006/07/19)
売り上げランキング: 170511

おすすめ度の平均:

悩めるＤＢエンジニアのバイブルです。

Amazon.co.jp で詳細を見る

ハンガリアン記法

変数などの名前を付ける時のコーディングルールに、ハンガリアン記法（ハンガリー記法）と呼ばれるものがある。簡単に言えば、名前の先頭に「型」などを表す文字列（プリフィックス）をつけるというものである。

かつて Microsoft が好んで採用しており、 Visual C/C++ (MFC) を使ったWindows プログラミングの仕事が多かった私の会社では、社内ルールとしても採用されている。

★

というわけで、私も、ハンガリアン記法で多くのコードを書いてきたのだが、あるとき、Joel Spolsky 氏の「間違ったコードは間違って見えるようにする」という記事を読んでショックを受けた。

それまで私が書いてきたハンガリアン記法というのは、MFC でやっているように、変数名に「型（type）」を表すプリフィックスを付けるものだった。しかし、それは「システムハンガリアン」と呼ばれ、本来のハンガリアン記法ではなかったのだ。

本来のハンガリアン記法とは、「アプリケーションハンガリアン」と呼ばれ、プログラミング言語の「型」とは無関係に、データの「種類（kind）」を変数名で表現する方法であった（※１）。

アプリケーションハンガリアンを使えば、変数間の互換性（端的に言えば、代入してもよいかどうかということ）が、コードの読者（コードを利用する人、改造する人、デバッグする人、レビューする人、そして、そのコードを書いた人自身）に明確に伝わる。ここでいう互換性とは、文法的なものではなく、意味的なものである。文法的な互換性はコンパイラがチェックしてくれるが、意味的な互換性は人間がチェックするしかない。

つまり、本当に有用なのは、文法的な「型」を明示するシステムハンガリアンではなく、意味的な「種類」を明示するアプリケーションハンガリアンなのである。

★

今では、Wikipedia にも「アプリケーションハンガリアン」と「システムハンガリアン」の違いが記述されている（※２）。しかし、古参のプログラマは、あらためてハンガリアン記法の意味など調べない人がほとんどだろう。一方で、Microsoft からシステムハンガリアンが消えようとしている時代にあって、新参のプログラマが、ハンガリアン記法について考える機会はどんどん少なくなるだろう。

しかし、そんな時だからこそ、アプリケーションハンガリアンの価値を再考すべきではないだろうか。特に、自前のコーディング規約の作成を考えている人には、是非とも先に紹介した記事は読んでもらいたい。プリフィックス方式を採用するかどうかは別にしても、少なくとも、意味的な種類（kind）を明確にする、という考え方は取り入れるべきだろう（※３）。

応援のクリックお願いします →

※１
もちろん、アプリケーションハンガリアンを使わない場合でも、変数名はデータの意味的な「種類（kind）」を表すようにすべきだ。しかし、それをプログラマ個人に任せてしまうと、不統一になってしまって意味がない。ルール化するということが大切なのだ。

※２
2007/4/22 現在。Wikipedia の項目名は「ハンガリー記法」となっているが、「ハンガリアン記法」への改名が提案されている。

※３
システムハンガリアンのルールを作るのが簡単だが、アプリケーションハンガリアンのルールを作るのは難しい。しかし、Joel Spolsky 氏の記事にある「本当の解決法」はそのまま使えるし、他のルールを作る上での参考にもなる。また、類似したデータを取り違えてバグになった経験を思い出せば、いくつか思いつくのではないだろうか（例えば、「YYYYMMDD」と「YYMMDD」、「ゼロ埋めしているデータ」と「ゼロ埋めしていないデータ」、「枝番つきコード」と「枝番なしコード」、「協定世界時」と「日本標準時」、文字コード違いの文字列・・・）。

Joel on Software

posted with amazlet on 07.04.22

Joel Spolsky 青木靖
オーム社 (2005/12)
売り上げランキング: 1815

おすすめ度の平均:

実際に現場で使わせてもらってます

優秀なソフトウェア開発者の日々の徒然

プログラミングチームを率いるときに

Amazon.co.jp で詳細を見る

C++ Coding Standards
―101のルール、ガイドライン、ベストプラクティス

posted with amazlet on 07.04.22

Herb Sutter Andrei Alexandrescu 浜田真理浜田光之
ピアソンエデュケーション (2005/10)
売り上げランキング: 37199

おすすめ度の平均:

上級者には心得集、中級者にはポインタとして

この二人以上にC++について語れますか？

文法だけでは分からない、C++の書き方

Amazon.co.jp で詳細を見る

どうして仕事を断らないのだろうか

仕事を頼まれたら断れない人がいる。傍から見ていて出来そうもないと思うような仕事でも引き受けてしまう。つい横から口を挟みたくなるが、本人が「出来る」と言っているのに、他人が「出来ないだろう」などと言うのも失礼だと思い、黙っている。しかし、案の定、期限が来ても仕事は終わっていない。

もちろん、何らかの理由で仕事が遅れるようなことはよくある。そういう場合は、可能な限り早く「出来そうにない」と言うのが誠実な対応である。しかし、期限が来るまで黙っていて、当日になってから「出来てません」などと言う人もいる。そういう人に限って、「明日までにやります」などと言うが、やはり出来ないのだ。

そういう人がいると、周囲は振り回される。その仕事の依頼者はもちろん、その人に次の仕事を頼もうとしている人にも影響が及ぶ。また、遅れた仕事がクリティカルパス（※）の一部であれば、より大きな仕事のスケジュールがまるごと遅れてしまう。

もちろん、本人も辛いだろう。

★

どうして出来ないことを引き受けてしまうのだろうか。

自分が「出来ない」と言ったら依頼者が困るだろう、と考えてしまい、ついつい引き受けてしまうのだろうか。実際には、「出来る」と言っておきながら出来なかった場合の方がもっと困るはずなのだが。

あるいは、「出来ません」と言うと怒られると思っているような場合もあるだろう。特に上司からの指示には、萎縮してしまって「出来ない」とは言えないのかもしれない。実際、「出来ない」と言うと怒るような上司もいるだろう。しかし、「出来る」と言っておきながら出来ない時の方がもっと怒られるはずだ。

もしかすると、「出来ません」と言うのが「格好悪い」と思っているような場合もあるかもしれない。

★

反対に、彼が本当にその仕事を期限内に出来ると思っているケースもある。

例えば、仕事に必要な時間の見積が小さすぎるのかもしれない。その仕事に関する経験が少ない場合はうまく見積もれない。作業が順調に進んだケースしか考えなければ「出来る」と思ってしまう。しかし、実際の仕事をしていると、何かトラブルが発生するものだ。作業時間はある程度のリスクを考えて、多めに見積もるべきである。

逆に、自分が使える時間の見積が大きすぎる場合もあるだろう。自分が他にも色々と仕事を抱えているということを忘れている。または、そうした仕事に対して自分はどれだけの時間を割けるのか、というスケジューリング（時間管理）をしていないような場合だ。

あるいは、自分の能力を過大評価していて、「出来る」と思い込んでしまうこともあるかも知れない。

★

誰かに仕事を頼むとき、「出来ない」と言われれば、他の人に頼むとか、スケジュールを見直すとか、何かしらの対応が出来る。しかし、「出来る」と言われれば、信頼して待つだけだ。それが、期限の日に「出来なかった」となると、取り返しがつかないこともある。もちろん、依頼者の信頼を裏切ることにもなる。

何か仕事を引き受けるというときには、本当にそれが出来るのか、ということを相当慎重に考えてもらいたいと思う。

応援のクリックお願いします →

※クリティカルパス
その仕事が終わらないと次の仕事が始められない、という関係にある一連の仕事。特にプロジェクト全体の長さを規定するものをいう。

■関連記事
・どのくらいでできる？
・簡単に見える時ほど注意せよ

エンジニアのための時間管理術

posted with amazlet on 07.04.11

Thomas A. Limoncelli 株式会社クイープ
オライリー・ジャパン (2006/10/19)
売り上げランキング: 3697

おすすめ度の平均:

「普通のエンジニア、プログラマ、SE」を脱皮し始めた人へ

システム管理者は一度は読んでおきましょう

Amazon.co.jp で詳細を見る

簡単に断れない。

posted with amazlet on 07.04.11

土屋賢二
文藝春秋 (2006/11)
売り上げランキング: 61109

おすすめ度の平均:

なんだかわからない

論理の綻びが面白い

一度、この方の講義を聴いてみたい

Amazon.co.jp で詳細を見る

愚痴のこぼし方

ITpro の「新入社員諸君への提言」という記事を読んだ。

新入社員を迎える「上司・先輩へのお願い（２ページ目）」として、

　ぜひ，いい話をたくさん聞かせてあげてほしい。しかし，現実は全く逆になっていないだろうか。特に，ビジネス環境が厳しい昨今ではともすれば愚痴っぽい話が多くなる。話題に出てくるのは，「会社の経営状況が厳しい」，「他社の製品に比べて当社の製品は劣っている」，「うちの上司はダメだ」など，新入社員の夢を砕いてしまうものばかりだ。彼らは入社前に聞いた勧誘の話とは相当異なることにあ然としてしまうだろう。

とある。

私が新入社員だった時も、職場では「いい話」よりも「悪い話」を聞く方が多かった。特に、ワンマン社長への不満、給与面での不満、長期の出向が多いことへの不満など。そんな雰囲気を受けて、新人同士の会話もネガティブな話が多かったように思う。

今でも、毎年のように入社後１ヶ月もしないうちに辞めてしまうような新人がいるが、先輩達の「悪い話」が、彼らの背中を押しているということは否めないだろう。

★

しかし、私は「悪い話」自体を全て否定する気にはなれない。

引用元の記事は、

　以前，営業担当の役員をしているときに，ベテランや中堅の社員が若手を相手にして，会社の愚痴を言っているのを聞くと，必ず「会社の良いと思う点と悪いと思う点を両方すべて挙げなさい」と指摘したものだ。良い点がたくさんあることが分かっていて悪い点（改善点）を指摘するのは認めた。

　だが，良い点を挙げられず，悪い点だけを強調する場合は，退社を勧めることにしている。悪いことだけしか思い浮かばない会社に勤めているのは当人にとって不幸だし，その愚痴を聞いて感化されるかもしれない若者はかわいそうだ。会社にとっても迷惑である。

と続くのだが、そこまで言うのは、いささか乱暴ではないだろうか。

社員が会社の良い点を見つけられない理由の何割かは、その個人の特性（批判的な性格など）によるものだろう。しかし、他の何割かは会社側にあるはずだ。彼が会社に何を求めているか、ということを聞く前にクビを切るのは、会社にとって、もったいない話である（引用中、自分が「認めた」人の指摘だけを「改善点」と書いているのは意図的なのだろうか）。

★

もうひとつ、愚痴や不満には、それを口にすること自体が、ストレス解消になるという側面もある。また、職場の中で「愚痴の言い合い」をすることによって、結束力が高まるようなことすらある。

要するに、「悪い話」をするなら、相手を選べということである。冒頭のような影響を考えると、新入社員に対して話すのはあまり好ましくないだろう。また、話の内容にもよるが、社外の人間に話すのもよろしくない。会社として非公開の情報は社外の人間に漏らさない、というのが、社会のルールだからだ（当ブログのように、匿名で悪態をつくようなことはあるかもしれないが）。

愚痴や不満は、同僚に向かって言うのが無難である。もし可能なら、上司に向かって言う方が理想的だ。まともな上司であれば、それを「相談」として受け止めるだろう。場合によっては、対策に取り組んでくれるかもしれない。そうなれば、ストレスの解消のみならず、悪い状況の改善にも繋がる可能性も出てくる。

★

では、新人に対して、悪いことは隠しておけというのか？　という人もいるかもしれない。確かに、後から知ったほうがショックが大きいということもある。

もし、新人に伝えておきたい「悪い話」があるのなら、なるべく最後はポジティブに締めくくるようにしたい。悪い状況があるのなら、そうした状況に対して、自分（あるいは会社）はどのように対処しているのか、といったことを付け加えて話すようにするのである。例えば、ただ「うちの上司はダメだ」と嘆くだけではなく、「そんな上司とはこう付き合え」と付け加えてやれば、新人のためになるだろう。

「対処なんてやってないよ」というのであれば、いい機会なので、考えてみるといいだろう。自分の力ではどうしようもないこともあるかもしれないが、それなら「自分が社長ならこうする」というような想像でもいい。

愚痴を言うのは誰でもできるが、それだけでは問題解決能力は育たないのだから。

応援のクリックお願いします →