いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■クリエイティブな時点で儲からない 例えば芸術活動や音楽活動。創造性を問われる割にあまり儲からない。特にエンターテインメントなど、形がないものほどお金になりにくい。もちろん、当たればでかい。しかし、それだけでは食べていけない人も多いようだ。 それを考えれば、ＩＴ技術者はまだマシかもしれない。しかし、クリエイティブにコードを書くより、マネジメントやコンサルティングをやった方が儲かる。結局、コードを書いたりインフラをいじってる内は大して儲からないだろう。 ■単純に稼ぐという観点から考える 「稼ぐ」という観点で考えてみる。少なくとも、働いて収入を得ている時点で、時給換算で考えれば負け組だ。俗にいう「働いたら負け」というヤツだ。真に稼ぐ者は、生まれつき持った資産を運用して少

ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 電話が鳴った。 あたしはワンコールで受話器を取り上げた。別に待ちかねていたわけではなく、朝から続くしつこい頭痛に干渉する電子音を一刻も早く断ち切りたかっただけだ。 「はい、日比野です」 『受付です。ホライゾンシステムサービス株式会社様がいらっしゃいました』 「すぐ行きます」 あたしは受話器を置いて時計を見た。14:12。約束の時間より約10分の遅刻だ。 ――まあ、遠いから仕方ないか 腰を上げたとたんに立ちくらみに襲われた。椅子にへたりこみそうになるのをぐっとこらえて、窓際の席でヒマそうにしている磯貝課長に呼びかけた。 「課長、ホライゾンシステムさん、いらっしゃいました」 「あいよ！」 磯貝課長の脳天気な返事を後頭部で受けておいて、あたしは頭を揺らさない程度に早足でフロアを出た。さ

■ はじめに どうもー。＠ITの捨てがまり担当、terukizmです。にしても、深夜アニメ楽しいですよねー。ほんとに。かるたとか、超やりたい。 嘘です。 で、題名の元になってる某アニメなんですが、「歴史上の偉人の英霊を召喚して戦わせる」ってコンセプト…… すごく、いいですよねー。 となると当然「プログラム言語」でやってみたくなるのがプログラマの「業」というもの……。当然各方面に喧嘩を売ることになりますが、書いてたらだんだん楽しくなってきてついやっちゃったんだ。しかたないね。 ■ コーディング戦争概要（元ネタを知らない人向け） 「エスイー」が「プログラマ」を使役してコーディングする 「プログラマ」は7つのクラスに分けられ、それぞれの用いる言語に関わりの深い「英霊」が割り当てられる 最後に勝ち残った「エスイー」の願い（定時で帰りたいとか）が叶う 確かこんな感じ。で、以下、本編です。 ■ プログ

エンジニアのためのWord再入門講座 美しくメンテナンス性の高い開発ドキュメントの作り方 佐藤竜一（著） 翔泳社 2008年5月 ISBN-10: 4798117137 ISBN-13: 978-4798117133 2310円（税込） Wordはワードプロセッサです。 Excelは表計算ソフトです。 残念ながら、Excel方眼紙にドキュメント作成ツールとしての地位を奪われた感があるWordですが、きちんと機能を理解して使えば、必ずエンジニアの役に立つはずです。「Wordは変な動作をするし、おせっかいな機能が多くて使いにくい！」とは、言わせません。 ■「より良いドキュメントを、効率よく作る」ための本 「より良いドキュメントを、より効率良く、低コストで作成する」――これが本書の目指すゴールです。この目的を達成するために必要なWordの初期設定、および理解しておくべき機能などが解説されており、

昨日、何気なくつぶやいた以下のTweetが72人にRTされて、個人的な記録となりました（http://favstar.fm/users/knsmr/most_retweetedを見ると、RT数による私の過去のツイートのランキングが見られます）。私のTwitterのフォロワー数は2400人程度と、それほど多くありませんので、これは結構な数です。共感する人が多かったのかなと思ったので、ここのブログでも共有してみます。 企業の情報部門は「サポート対象ブラウザ」というけど、ウェブってそんな世界じゃなかったのよ、もともと。そこに誤解があったんだし、そんなこと言うなら、ウェブ技術使うのやめてOSのAPIに戻ったら？ 10年同じもの使いたいんでしょ。外のウェブの世界に負担をかけるのいい加減にやめたら？less than a minute ago via web Favorite Retweet Repl

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 徳丸浩（著） ソフトバンククリエイティブ 2011年3月 ISBN-10: 4797361190 ISBN-13: 978-4797361193 3360円（税込） ■われわれの生活に根付く「安全神話」 インターネットが生活の基盤になってから久しい。皆さんは今日もどこかのWebサービスにログインし、ユーザー名やパスワードといった個人情報、あるいはクレジットカードの番号を入力したかもしれない。 「生活の基盤」である以上、安全で安心して使えるものである、という前提で考えがちだ。しかし、インターネットの先で運用されているWebサービスは、人が作ったプログラムである。人間の仕事である以上、完ぺきであるはずがない。 これは当たり前の事実であるはずだが、毎日インターネットを使っていると、つい忘れがちだ。そして、何か大

ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 彼らには本当に知能があるのだろうか？ つまり、彼ら自身の知能が？ ぼくにはわからない。どうすればそれがわかるのかも、わからない。 ぼくの名前は細川マモル。横浜市内にオフィスを構える小さなシステム開発会社に勤務しているエンジニアだ。当年とって29歳、独身。付き合い始めて2年になる彼女がいるが、結婚を意識していいのかどうか決めかねている状態。 うちの会社は7年前に某大手SIerからスピンアウトした6人が立ち上げた、いわゆるベンチャー企業だ。最近の世界的な景気後退の大波を何とかしのいで、ここまで黒字を――かろうじて――維持してきている。もちろん危機的状況に陥ったことも少なくなく、役員の2人が給料なしでしのいだ月も何回かあったらしいが。 社員数は20名前後。開発要員は15名で、うち半数以

1990年代後半のインターネットブームの火付け役といってもいいWebブラウザ「Netscape」の創業者で、現在シリコンバレーで投資家として活躍するMarc Andreessen氏が、あるインタビュー中で「優秀な5人のプログラマは、二流のプログラマ1000人を完全に凌駕する」（Five great programmers can completely outperform 1,000 mediocre programmers.）と発言したことで、ちょっとした話題となっているようです。インタビューはライターのBill Taylor氏（個人サイト）が、自著「Marvericks at Work – Why the Most Original Minds in Business Win」（アマゾンUSへのリンク）のためにインタビューした際の答えとして、Harvard Business Revie

いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■ほげほげに宣戦布告 ほげほげ（hogehoge）。 ほげほげ（hogehoge）は、ソフトウェア業界ではよく使われている単語です。サンプルのclassの名前に使われていたり、サーバ名がこの“hogehoge”だったりする。プログラムを書いている人なら一度は見たことがあるだろう。 これは、誰が最初に使い出したのだろうか？ かなり長い間使われているが、根拠を知らずに使っている人は多くないだろうか？ ちなみに、私も“ほげほげ（hogehoge）”の起源は知りません。 ここではっきり言っておきたい。“ほげほげ（hogehoge）”はレガシーコードだ！ ■これからの時代は、“ぽうぽう（poupou）”だ 決してマイケル・ジャクソンのファンというわけではない。私は“ほげほげ（

群れのルール――群衆の叡智を賢く活用する方法 ピーター・ミラー （著） 土方奈美（翻訳） 東洋経済新報社 2010年7月 ISBN-10: 4492532722 ISBN-13: 978-4492532720 1995円（税込） なぜ、人員を増やしたりスケジュールを引き直したりしても、プロジェクトは遅れるのか？ なぜ、高い技術を持つプログラマを集めてチームを作っても、チームとしての生産性が向上するとは限らないのか？ 知の巨人に聞いても、容易に回答が得られない難問である。知の巨人でも難しいなら、いっそのことアリに学んでみるのはどうだろうか？ ■個体の能力は低いが、チームになると賢い「組織のプロ」 本書は、「組織のプロフェッショナル」の豊富な事例をもとに、効率的な組織の回し方、生産性向上という難問の解決方法、火を噴いたプロジェクトの改善案を紹介している。 しかし、先生である「組織のプロフェッシ

こんにちは。草食系妙齢プログラマ　野口おおすけです。約2カ月ほどコラムをお休みしていました。今週からまた、更新頻度を以前のように戻していければと考えています。お付き合いのほど、お願いいたします。 さて、お休みしていた間に仕事の面で動きがあり、プロジェクトを引っ張る立場になりました。チームメンバーは少ないものの、メンバー管理やお客さまとの調整、ほかのプロジェクトとの調整などに走り回っています。落ち着いてコードを書きたいと思うこともありますが、残念ながらそういう時間は減ってしまいました。 わたし自身もそうですが多くの人は「打ち合わせ」や「ミーティング」という会議体に時間をかけたくありません（ごくまれに、会議時間は長い方がいいと考えられている方もおられますが）。そのため、短い時間で効率よく物事を伝え、議論を組み立てる必要があります。 「短い時間で効率的に物事を伝える」。これは、よくIT系イベント

近年、ハードウェアの性能向上などにより、IT業界をめぐるインフラは、ようやく市場の要求に耐えうるようになってきた。以前はプラットフォームの陳腐化によって5年と持たなかったソフトウェアの平均寿命は、ここへきて徐々に延びつつある。 このような状況の中でソフトウェアに求められるものは、繰り返し行われる機能追加に耐えうる「拡張性」と、長期に渡って品質を保てる「保守性」だ。これらの課題については、クラウドのような分散コンピューティング技術や、オブジェクト指向デザインのような設計思想といった大きな枠組みの中で数多く議論され、ソフトウェア技術の進歩を押し上げてきた。「実際の現場においてこれらの課題をインプリメントするのは、システム設計者やSEといった上流工程を任された人間の役目である」と一般に言われている。 彼らのアウトプットは、基本的に文書（Document）だ。文書は日本語や図から構成されており、読

本音が語れるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 ここでは、編集部がおすすめするコラムを紹介しよう。「言語萌え」、部下のモチベーションアップ、素敵なIT女子に関するコラムの3本を取り上げる。 言語擬人化妄想 第5話：“運用部門の若手メンバーの疲弊”の巻（下） ～モチベーションを上げるには IT業界の仕事は女子職になるのか？ 考察（その1） どの言語に萌えるか？ 言語擬人化妄想 キャリア20年長のベテランプログラマ ひでみ氏による『プログラマで、生きている』。萌える言語と萌えない言語について。 「久しぶりにC++を使ったら、すっかりC++がツンデレ化していた」と、ひでみ氏は語る。愛好している嫁言語なのに、すっかりご機嫌を損ねてしまったらしい。 プログラミング言語をいくつも使いこなしていると、「この言語の方が記述が

月刊「Windows Server World」の連載コラム「IT嫌いはまだ早い」の編集前原稿です。もし、このコラムを読んで面白いと思ったら、ぜひバックナンバー（2008年7月号）をお求めください。もっと面白いはずです。 なお、本文中の情報は原則として連載当時のものですのでご了承ください。 新入社員の方は、そろそろ基礎研修が終わり、職場に配属されたころだろうか。最新の情報はブログで発信されることが多い。ブログを読んで、元ネタは分からないが何かのパロディらしいと思ったことはないだろうか。今回のテーマは「IT業界人として知っておきたい作品群」である。 ●エンジニアの好きな作品 エンジニアの書いているブログや、オープンソース系のドキュメントを読んでいると、ときどきよく分からない表現に出くわすことがあると相談される。見てみると、何らかのパロディであることが多い。 完成されたドキュメントを読む場合、

わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他

●テレビっ子とデジタルネイティブわたしは1959年生まれで、生まれたときからテレビがあった世代に属します。ですからテレビがなかった時代の家庭の団欒が、いかに静謐（せいひつ）さに満ちていたかを知りません...

アプリケーションを作成する上で非常に重要な要素の1つにユーザーインターフェイスがあるかと思います。使い勝手に直結する部分のため、非常に頭を悩ませているところであり、全国のSEの方たちも、物凄く気を使って考えているところだと思います。 ユーザーインターフェイスは時代にあわせて進化を続けています。それは入力デバイスの進化とほぼ同じ時系列で進んできているように思えます。最初のころはキーボードがメインでしたので、「いかに入力しやすいか」という点に主眼をおいたデザインであったと思います。それがマウスが主流になり、「いかに選択しやすいか」という点へと変化していったのではないでしょうか。ただどちらにも共通しているのは、あるデバイスを利用して適切に楽に入力を行えるもの、というのが基本であったと思います。 今でいうGUIが全盛になる以前は、キャラクタベースのUIが主でした。そのため「選択する」という操作方法

わたしは4月で社会人10年目になりました。 エンジニアを10年もやっていると、それなりに経験が蓄積され、若いころであれば調べないと判断できないようなことも、培った経験で判断ができてしまうことが増えてきます。 しかし、そのような経験を過信してしまい、物事に対して先入観を持つことにより、間違った判断をしてしまうことがあります。 古いOracleの知識で「Oracleではそれはできない」 古いWindowsやLinuxの知識で「Windowsだからできない」「Linuxだからむずかしい」 と判断していませんか？ 「前にやったことがあるけどダメだった」 「アプリケーション側でエラーが起きるわけない、データベース側の問題だ！」 こんなセリフを吐いて思考停止していませんか？ 【思考停止エンジニア】 わたしは経験だけで話をするエンジニアの言うことは信用ができません。 エンジニアの技術力はITのアンテナを

刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ