急カーブを描いていた成長曲線が、いったん踊り場を迎える。そんな感覚を持つのが、ソフトウエアエンジニアとしてちょうど10年ほど経験を積んだ頃ではないだろうか。 がむしゃらに技術スキル向上を目指していればよかった時代が終わり、さてこれからのキャリアの方向性は？とふと立ち止まる節目。そこで迷いなくクリアに次のステップを思い描ける人は意外と少ない。なぜならしっくり来る選択肢が目の前に存在するケースが稀だからだ。 マイクロソフト、グーグル、Incrementsで活躍してきた及川卓也氏は、そんな悩めるアラサーエンジニアに３つのキャリアパスを提示する。及川氏が語る、エンジニアの仕事人生を切り拓くヒントとは？ 及川卓也氏 早稲田大学理工学部を卒業後、1988年、日本DECに入社し、営業サポート、ソフトウエア開発、研究開発などに従事。97年、マイクロソフトに転職し、Windows製品の開発統括に携わる。20

加点主義と減点主義 ロッシェル・カップ：　日本人は言葉で相手を褒めたり、感謝を伝えることを苦手としています。褒めると相手が努力しなくなるという心配や、「努力することは当たり前。あえて褒める必要はない」という考え方などが、理由として挙げられると思います。そのため、非言語的な方法で間接的に感謝や満足を伝えるケースが多く見受けられます。たとえば、優秀な社員に対して、責任のあるポジションを与える、特別な場に出席させることなどを通じて、本人に期待をかけていることを伝えています。 しかし、日本以外の多くの国では、望ましい行動に対して直接感謝したり、褒める文化があります。この差は、加点主義と減点主義の違いから生じていると思われます。たとえば米国の場合は、ポジティブ・フィードバックは「心の報酬」と考えられており、学校教育段階から相手の良い部分を重視します。一方、日本は何事にも完璧を追求する傾向が強いため、

人はフィードバックを受けたい ロッシェル・カップ：　部下が望ましくない行動を続けているとき、日本人に多い傾向は「いつか自分で気づき、直してくれるだろう」と期待することです。しかし、直接的なコミュニケーションを好む人は、ネガティブ・フィードバックを行わなければ、自分から行動を変えることはありません。 たとえば、ある日本人上司が、外国人の部下の問題行動に対して不満をもっている。しかし、上司は直接指摘しない。部下はまったく気にしていないため、我慢比べのようになり、最終的に上司は「この人は改善する意思がない、辞めさせるべきだ」と考えてしまう。一度もフィードバックをせずに、ある日突然解雇を告げてしまうのです。 部下としては、フィードバックがないのは自分に悪い点はないからだ、と考えているため、突然の解雇通告に対して大きなショックを受けます。そのため、差別など仕事以外の問題により解雇されたと誤解し、訴訟

具体的に事実のみを伝える ロッシェル・カップ：　ネガティブ・フィードバックには、基本となる3つのステップがあります。フィードバックの目的は指導と改善を促すことですから、相手がイメージしやすいよう、事実や理由を明確に説明することが大切です。 1つ目のステップは、「問題行動を指摘する」です。指摘する内容は、客観的な事実だけに絞ります。重要な点は、形容詞を使わないことです。「くだらないミスをして」など人格を否定するような形容詞を使うと、相手が感情的になり、論点が別の方向に外れてしまいます。直接的な表現や憶測はできる限り避け、何が問題であったかについて、事実だけを分かりやすく指摘するのです。 2つ目のステップは、「望ましくない行動がもたらした結果を指摘する」です。このステップは、「なぜ、その行動が望ましくないのか」に関する理由の説明となります。日本的な感覚で指導を行う場合は、「皆まで言わなくても分

一度覚えたらずっと忘れないことを、“like riding a bike” (あるいは“bicycle”）と言います。それは良いことですよね。 しかし、“Like riding a bike”という表現が良いことだけでなく、一つのやり方、あるいは一つの見方しかできなくなるということにもぴったり当てはまるかも知れません。そう思わせる動画をご紹介します。 “The Backwards Brain Bicycle”（すなわち、脳を逆回転させる自転車）という動画ですが、ハンドルが正反対に動く自転車に乗ることがどんなに難しいか、面白く教えてくれます。そして、子供の脳の柔軟性を実証する実験でもあります。 ちなみに、この実験をしてみたデスティンさん（アメリカ人エンジニア）は、私と同じアメリカのアラバマ州出身ですので、動画を見ながら、彼のちょっとした南部訛りをエンジョイしてください。

【16-E-4】残業ゼロで開発スピードが10倍に！もう元の開発体制には戻れないデンソー流のアジャイル開発Developers Summit

本記事は、「編集とライティングにまつわるアレコレ」の24日目の記事です。 こんにちは、ITエンジニア向けのWeb編集者をしているid:kondoyukoといいます。業界は4年目でまったりと仕事をしてきたのですが、今年度からイベントの企画運営ががっつりと、新メディア（こちらはあんまりやってない）が乗ってきたので、体感的には2年前の2倍くらい仕事をしているような気がします。 インターネットで文章を書くことが好きだったはずなのに、編集者の仕事をすればするほどプライベートでも文章に触れたくないのか、スクラッチで文章を書くのが辛くなってしまい、投稿が遅くなってしまいました……。出版社で働いているのに本を読むことと文章を書くことにとてもコンプレックスを持っています。毎年、ブログを書くことを今年の目標を上げていますが、まあ来年こそは、ね。 今年作ったイベントたち さて、私は今年、公私共にたくさんイベント

2017年11月のリニューアルでモバイル版Webサイトの表示速度が“爆速”になったと話題の「日経電子版」。第2回「日経電子版はなぜ”爆速化”したのか、どれだけ速いのか」においては、スピード改善の背景と成果について、開発チームに話を聞いた。それに引き続いて今回は、改善ために採用した手法と効果指標について解説してもらった。 表示スピードはエンゲージメントにおいて大切な要素だから 表示スピードの改善を行う上で、日本経済新聞社ではどのような効果指標を持ってプロジェクトを進めたのだろうか。注目は、2016年に取り入れた独自の「エンゲージメント指標」だ（下図参照）。これはアクセス解析を基に独自の数式で指標を設定したもので、有料会員を増やし、離脱を防ぐためのパラメーターとなっている。この数値こそ、まさに日経電子版の要といえる。

中島聡氏（以下、中島氏）：普段はアメリカのシアトルに住んでいますが、年に数回は日本に来ています。今回の日本出張の目的のひとつが、母校でもある早稲田大学でのシンポジウムへの出席、講演でした。ここで「エンジニアのための経営学」といった話をするために招かれたんです。 ぼくの仕事の主軸はソフトウェア開発です。米国Microsoft社でWindowsの開発に携わったあと、2000年にUIEvolutionというソフトウェアの開発会社を起業しました。今はその後継となるXevo.Incという会社で、チーフアーキテクト兼会長という職に就いています。職務上、この会社で現場業務に携わることは少なくなりましたが、まったく別のところで、今もプログラミング、ソフトウェア開発を行っています。「少しずつ前進する未来」をこの目で見たくて、イチプログラマーとしてあれこれやっているんです。 「三度の飯より……」という言葉があ

What、Where、When、HowのISとIS NOTを押さえることで、初めてA君の状況が見えてきます。上司の直感で「A君はダメだ」と決めつける場合と比べて、状況認識に広がりと深さが出てくることがわかると思います。 情報の品質という観点からもこのようなシステマティックなアプローチは威力を発揮します。ヒトに関する良質な情報は収集が難しいので、怪しげな情報が横行する危険性が常にあります。ところが、目についた否定的なIS情報だけでなくて、IS NOTという対照情報も探すとなると、自ずと情報がスクリーニングされることになります。 比較に耐える情報を探さなければならないので、直接情報（自分が直接見た）なのか、間接情報（他人が直接見たことを確認した）なのか、噂（誰が見たかわからない）や臆見（根拠の薄弱な情報に基づいた主観的意見）なのか、ということが気になるからです。こうして、正しいものだけ受け入れ

こんにちは。 「はたらくていたらく」という名前ですが、現在働いておりません。ただの体たらくです。 それはさておき、はじめまして〜のエントリだけだと味気ないですね。 この間ツイートした件のことを残そうかと思います。 ◟(๑•́ ₃ •̀๑)◞ ◟(๑•́ ₃ •̀๑)◞ ◟(๑•́ ₃ •̀๑)◞ 突然のご連絡、大変失礼致します。株式会社○○○○の〜〜〜と申します。 こんなメッセージ、SNSで何かしらエンジニア的な活動をしているともらったことないですか？ いやいや、突然すぎるだろと。正直、怪しさしかないだろと。警戒しかないですよね。 大抵の人が無視するであろうものに乗ってみた私の心情や経緯などは興味ないと思うので省略しますが、 メッセージを受け取ったことがある方は大抵こんなこと考えるのかなと思います。 ワイと会って何するつもりなんや どこからワイの情報仕入れたんや こちらについて、実際に会っ