こんにちは、キャリア・コンサルタント高橋です。 先日、あるITエンジニアの方にキャリア相談をさせてもらいました。そのとき、ITエンジニアにとって何が必要か？ という話が出てきましたので、今回はこれをネタにコラムを書いてみたいと思います。 ■ITエンジニアは技術力あってのモノでしょう！ その方をここでは仮に飯田さんとお呼びします。飯田さんは過去にも私のキャリア相談を受けられたことがあり、今回は約5年ぶりにキャリア相談でした。以前の飯田さんは職人気質のITエンジニアで技術力を高めることこそがこの世界で生き残っていく術だと考えていました。そのため、そのときのキャリア相談では、 どのようにして技術力を磨いていくか？ 身につけた技術力をどうやって仕事に生かしていくか？ といった内容でキャリアプランを考えました。でき上がったキャリアプランは技術の習得がてんこ盛りで、かなり難しい技術の習得も入っていまし

「生活イチバン、ITニバン」という視点で、自分なりのITを追及するフリーエンジニアです。ストレスを減らすIT、心身ともにラクチンにしてくれるITとはどんなものかを考えていきます。 「チョット待て！なんか様子がおかしい！」 エンジニアなら誰でも1度は声に出して叫んだり、あるいは心の中で叫んだりしたことがあるセリフだ。進行中のプロジェクトの随所で、心の中にフツフツと湧き上がる違和感。 この違和感を俊敏にキャッチする研ぎ澄まされた感覚。これはエンジニアにとってもっとも重要なスキルのひとつといえる。 ■違和感の正体は、意識や解釈のズレ 顧客やプロジェクトメンバーとのコミュニケーション。改訂され続けるさまざまなドキュメント。プロジェクトを進める中で、仕事やその仕事の成果としての情報が担当者間を流れるたびに、少しずつメンバー間の意識や解釈にズレが生じることがある。なぜそんなことが起こるのかは、伝言ゲー

いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■Windowsのエビデンス 一応私はサーバエンジニアだ。Windows系のサーバを触ることが多い。WindowsではサーバでもGUIから設定を行うのがいまだに主流だ。メンテナンスでエビデンス（作業記録）を取る場合、やはりスクリーンショットを画像で保存するのが多い。 ここでWindowsに愚痴りたい。標準のペイントがしょぼい。いや、ペイントがしょぼいというより、なんでPrint Screen押して直接画像を保存できないのだろうか。Metoroインターフェイス作ってる暇があったなら、そういう地味な改善をしてほしいものだ。 GUIで動く仕組みには、やはり画像でエビデンスを取ることになる。ウインドウの内容を機械的にテキストに出力してくれるような仕組みでもあれば楽なのだが、

ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 「いや、だからさ」守屋が言った。「引数を1個増やせばすむじゃんかよ。なんでそうしないんだよ」 「お前、よく考えてもの言ってるか？」木下が答えた。「この先、項目が1つ増えたら、また引数増やすのか？ そのたびに関連するとこ全部直すのか？ どう考えても手間だろ」 「じゃあどうしろって？」 「まとめてDTOにしよう。それが手っ取り早い」 「それだとわかりにくくなるじゃねえか」 「はあ？ 誰が？」 「後からメンテする奴に決まってるだろ」 「DTOのどこがわかりにくいんだ？」 「引数だったら"stockCode"とか"limitDate"とか、一目で分かるじゃねえか」 「DTOだってJavaDoc見ればわかるだろう」 「いちいちJavaDocなんて開いてられるかよ。コーディングのリズムっても

6月も終わろうとしている中、いよいよ Windows 8.1 のプレビュー版が一般向けにも提供され始めたので、実際に試されている人も多いのではないでしょうか。併せて Visual Studio 2013 や Windwos Server 2012 R2、SQL Server 2014 といった次期製品群もプレビュー版が一斉に登場し、新製品の登場を喜ぶ声の一方で検証する製品の多さから悲鳴も聞こえてきている所かと思います。特に Windows 8.1 については色々言われている方も多いので注目を浴びているのではないでしょうか。 このように新しい製品が出る際に必ず話題に上がることとして、「旧製品がよかった」という意見があります。Windows の世界で言えば Windows 2000 が登場したあたりから、このような声が見える機会が増えてきたように感じます。Office であればリボンUIを初め

ケニアの首都ナイロビを始めとする各地域において、同国の金融システムの中核を担っているのがモバイルマネーサービス「M-Pesa」である。2007年に誕生して以降、瞬く間に普及し、現在では国民の7割以上がこのサービスを利用しているとされる。

■勉強会で自社名を隠す人々 今年の2月に転職して以降、勉強会やカンファレンスでの発表資料に僕は会社名を書くようになった。 2010年9月にコミュニティで初めてのライトニングトークをして以降、今年の2月に転職するまで、僕は合計9回、ライトニングトークや、セッションで登壇している。そしてそのいずれも、会社名はあえて伏せていた。 そういった場面で名刺交換をする機会はあっても、僕は個人で作成した名刺を使い、会社の名刺を出すこともしていない。その当時、僕がなんという会社に勤務しているのか、おそらくほとんどの人は知らなかったはずだ。 転職以降も、こういった活動は続けているが、今は自己紹介で、どこの会社で、どういった仕事をしているか名乗るようになった。名刺交換でも、会社の名刺を出している。 勉強会やカンファレンスに行くと、様々な人と出会う。登壇者と仲良くなることもある。そういった人たちと話をしていると、

開発業務に携わる方たちだけではなく、多くの方々は、仕事でも仕事以外でも「ドキュメント」を書いていることと思います。業種によっては、ドキュメントを書くことが本業で、それ以外の業務の割合が少ない、という方もいるのではないでしょうか。 私が属する開発業務の世界でも、やはり多くのドキュメントを書くことがあります。それは設計書であったり、ユーザーや受注元とのやりとりであったり、いろいろな種類のドキュメントを書きます。 こと開発の世界に限ると、ドキュメントを書き記す理由は大きく分けて2つあります。 1つは、「今システムを作るために必要であるため」であり、もう1つは「後で何か不慮の事態が起きた際に利用するため」です。開発標準として多くのドキュメントが定義されていますが、このコラムを読んでいる皆さんは、標準をアレンジしていることが多いのではないでしょうか。 基本としてドキュメントは必要なもの、というのは疑

■大ソーシャルコーディング時代 GitHubの台頭により、ソースコードをオンライン上に共有するということが、たいへん簡単な時代になりました。 TwitterやFacebookなどを見ていると、毎日のようにエンジニアの書いたソースコードへのリンクを目にすることができます。 わたし自身、自分の書いたソースコードは、可能な限りたくさんの人に見せるべきだと考えています。 エンジニア同士、コードについてのノウハウを共有することはよりよいプロダクトを作る礎となりますし、なにより自分の成長を劇的に促進してくれるからです。 今回はこの、「コードを人に見せるということ」について考えてみたいと思います。 ■コードレビューが苦手だった 職業プログラマが、最初に自分の書いたコードを誰かに見せる機会というのは、おそらくコードレビューでしょう。 わたしが職業プログラマになって最初に書いたコードは、COBOLによるもの