エンジニアの成長と「快適な職場」について : 小野和俊のブログ
「時間あれば軽く飲んでいきます？」 一年前のちょうど今くらいの季節に、Diablo3のオフ会の後に伊藤直也さんと2人で新宿三丁目のバーに向かった。 伊藤さん曰く、 「グリーにいたとき、すごく優秀な人がいて。お願いしたいことを短い言葉で伝えるだけで、行間を読んでこちらがやりたいことを全部理解して、必要な指示を出して自分も動いてあっという間に成果を出しちゃう。」 一般に、エンジニアの楽園のような職場 - 快適で自由闊達に意見が言えて、技術力があり、それぞれが自主性を持ってのびのびと仕事をしている職場の方が、エンジニアは良いアウトプットを出せるし、類は友を呼んで優秀なエンジニアが集まってきやすい。これは確かなことだろう。ただ、エンジニアの成長を考える時、そういう職場は本当に理想的なのか、という点については、少し立ち止まって考える必要がある。 人の成長には、明るく楽しく周囲も優秀でコミュニケーショ
小野和俊のブログ:徹夜をしてはいけない理由
どうしても昨日までに仕上げなければならない仕事があったので、一昨日は徹夜で開発をした。一人で飲んだり、人と飲んだり、布団の中で考え事をしたり、徹夜をすること自体は悪いことではない。しかし、徹夜で仕事をするのは可能な限り避けた方が良い。 ベンチャーを始めてからの最初の2年は、年末年始を含めて365日1日も休まず仕事をした。徹夜なんて当たり前である。そんな私だったが、会社が3年目に入る頃に休息の重要性を痛感し、以来、できるだけ徹夜はしないようにしている。それは、徹夜がもたらす作業時間よりも、悪影響の方がずっと大きいということに気づいたからだ。 私の経験では、徹夜が常習化するにつれ、個人/組織には次のような症状が出てくることがある。特に、影響力のある人がこのような状態になると、組織全体が影響されて深刻な症状にかかりやすい。
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
if-then-else文の順番 : 小野和俊のブログ
ペアプロで if-then-else 文が出てきた際、「これ、else if の順序、こっちの方が良くない？」というような会話をすることが時折ある。 どれも当たり前のものかもしれないが、「ああ、確かに」という反応があることもあるので、今日はそんな会話の際に出てくる視点についてまとめてみた。 if (よくあるケース/正常なケース) { // 処理 } else if (比較的特殊なケース) { // 処理 } else if (さらに特殊なケース) { // 処理 } else { // 処理 } 条件式の結果がtrueになる確率が高く、「ノーマル」に近いものを上に書く。可読性が上がる他、特に2.で触れる条件式の判定に時間のかかる場合や、ループの最奥にある処理などのif-then-else文の実行される回数が極めて多い場合には体感レベルで実行速度にも大きな差が出ることもある。 Code Co
SIerでのキャリアパスを考える勉強会に参加してきた : 小野和俊のブログ
このところ「SIerの今後について」というテーマについて、意見を求められたりディスカッションしたりすることが多く、またエンタープライズ業界に身を置く立場として、売り上げ比・人口比とも業界の大半を占めるSIerが今何に取り組んでいて、今後どのようになっていくのか、というのは私自身関心のあるテーマなので、昨日は「SIerでのキャリアパスを考える」勉強会に参加してきた。 というわけで勉強会の中で印象的だったことや考えたことを書く。 勉強会の前半パートではゆもとさんによるSIerの現状分析、ひがさんによるSIerの中でのキャリア戦略が話題に上り、その中でも特に「上流と下流が工程分断されている」ことが現状のSIerを取り巻く諸問題の元凶、という指摘があった。 この「分断」については、中島聡さんの「ソフトウェアの仕様書は料理のレシピに似ている」というエントリが有名だが、今回の勉強会でのゆもとさんの資料
ソフトウェア開発の「自由の悲劇」 : 小野和俊のブログ
クリエイティブな仕事というのはある意味で残酷だと思う。 なぜなら、 つくりあげたものが評価に値しないものだった場合に、 自由にできる環境があったのに、 この程度のものしかできなかったのかという批判が 本人に対して直接的に向けられやすいからだ。 というような話を耳にすることがあるのだが、 「誰でもいいからお金を出すので好きにつくってよい」 という状況はほとんど考えられないわけで、 もし本人の希望がかなった結果、 大したものを生み出すことができなければ、 自分には新しいものを生み出す才能がないのではないかという 悩みに直面することになる。 もちろん、中には自分自身でソフトウェアを次々と開発して、 ダウンロード数やアクセス数、メディアで取り上げられた記事などを印刷し、 この企画を会社の事業として採用しないか、 と持ちかけてくるような強者もいる。 だがそういう人でさえ、注目を浴びたソフトウェアの影
型と自分のスタイルとそれに要する経験と時間について : 小野和俊のブログ
「まず型をきちんと覚えろ。はじめは自分のやり方も何もないだろ」 高校時代、陸上部の先輩は私にそう言ったのだった。 私は当時、反抗心だけで、 型なんて覚えずにあんたなんて追い抜いてやるさ、と思ったものだが、 だからと言って一人だけ部活とは別に練習をするわけにもいかず、 動き作り、走り込みなど、先輩から言われたとおりに、 望ましいとされる同じ動きを自分自身の体が自然に動くようになるまで、 毎日、夜遅くまで何度も練習した。 例えば、陸上の短距離走では初速をつけるために スタート後しばらくは前傾姿勢を取るのだが、 私の場合には前傾姿勢をその後しばらく取り続けると タイムが良くなることがわかってきた。 最終的には、400m走で250m付近まで前傾に近い姿勢を取り続ける スタイルが定着して、高校2年の頃にはちょうど50秒*1で 400mを走りきることができるようになった。 これとまったく反対の事例とし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
