業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ▪️業務時間外の勉強を新人にどう説明しているか IT業界は技術の流れに置いていかれるとしんどい思いをする。業務時間外の勉強は必須だ。しかし、おかしな話ではないだろうか。なんで時間外に仕事のための技術を勉強しなければならないのだろうか。 本来であれば、業務に必要なことは業務時間内で教えるべきだと思う。だが、今時そんな余裕のある会社なんて無い。やって当然という雰囲気はあるが、やるだけの理由を説明できる人は少ない。大半が「仕事に必要だからやるんだよ！」としか言わない。 IT系に勤めているからそれが当然だと思うかもしれない。だが、「仕事で必要だから」では理由が弱い。しんどい仕事をした後に、更に勉強というのはなかなかしんどい。相応の理由でも無い限り、モチベーションは保てない。
いつか新入社員がいなくなる？ 『新卒ゼロ社会』：晴読雨読＠エンジニアライフ：エンジニアライフ
新卒ゼロ社会―増殖する「擬態社員」 岩間夏樹（著） 角川書店 2005年12月 ISBN-10：4047100242 ISBN-13：978-4047100244 686円（税別） 「最近の若者は、仕事に全力で打ち込まない」「ワークライフバランスよりも先にやることがあるだろう」――いつの時代も人は「最近の若い者は」とぼやく。年上の人が「若者はなっとらん」というのは、自分たちのものさしで若者を判断しているからだ。だが、その判断は果たして適切だろうか？ 著者は、本書の冒頭でこう述べている。「時代は変わる。人も変わる」。 ■日本型「新入社員」がいなくなる？ 本書で、社会学者である著者は「日本型の新入社員制度」が歩んだ歴史、40年近くの間に「新入社員の意識がどう変化したか」を考察している。財団法人 社会経済生産性本部と社団法人 日本経済青年協議会は、1969年から毎年、新入社員に対して「働くことの
炎上したのでまとめ：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 炎上したので、論点を整理しておく。 1．業務系では効率がトレードオフできない必要条件 業務系の職務では、「効率を求めること」がトレードオフしてはいけない必要条件です（十分条件ではない）。医者でいうならば、「命・健康」と同じ、トレードオフしてはいけない必要条件です。 効率が必要条件にならない職業もあるけれど混同してはいけない。 2．SQLはオブジェクト指向言語の数十倍の効率 オブジェクト指向言語を使い切るのと、全部staticで宣言してしまうような使い方と比べても、効率は数十％も変わらない。 SQLとオブジェクト指向言語を比べたら、数百～数千％の差が付く。 言語や手法を考えるとき、慣れてない人はできないから無限大の工数が掛かる。ですから、できない人を対象に比べても
世界を目指せばエンジニアはもっとハッピーになる：「おれたち世界一になれますか？」：エンジニアライフ
■はじめに 楽天株式会社 開発部の安藤祐介です。アプリケーションエンジニアとしてPHPやRubyのフレームワークやオープンソースのツールの推進などの業務を行っています。また2008年末からは美谷さんからも紹介があったリンクシェアへ出張にいくことが多く、まもなく正式な赴任を控えています。 社外ではPHPなどのオープンソースコミュニティでよく活動しており、昨年は20回弱社内外の勉強会などで講演をしました。そのおかげか昨年は情報処理推進機構（IPA）が例年開催している日本OSS貢献者賞の奨励賞をいただくことができました。 社内での業務を直接オープンソース活動に繋げることは難しい時がありますが、アプリケーションフレームワーク、CakePHPのイベントに参加する為の旅費を会社負担で処理してくれたり社内のスペースを一般参加可能な勉強会の会場として利用するなどオープンソース活動に対して理解があり助かって
ググるな危険：プログラマで、生きている：エンジニアライフ
だいぶ前の話になりますけど、「新人にデータ移行ツールのコーディングを任せるので、面倒をみてやってくれ」と頼まれたことがありました。 その新人はやたらとGoogle検索に頼る人で、とにかくわからないことがあると、わたしに聞かずにGoogle先生に尋ねるんですね。 検索サイトにはわたしもかなりお世話になっていますし、昔に比べるととても使い勝手がよくなっていますけれど、その人の技術レベルに対応して検索結果を出してくれるほど高機能なわけではありません。 そのため新人の書いてくるコードは、つぎはぎというかちぐはぐというか、身についてない知識に振り回されてる感が満載でした。 そういう弊害を気にしつつも、自分で調べようとする気持ちは尊重するべきなのかなあ、と思ってとりあえず黙認していたんですが、あるとき「ちょっと考えが甘かった」と思い知らされるトラブルが発生しました。 その新人が「Windowsのレジス
テーブル設計は実装の後に！：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 「みんなが言ってる」は技術者が口にする言葉じゃないと書いてきました。 私が言ってることで、「みんな」とはおそらく真逆のことがあります。 それは「テーブル設計を（ユーザーインターフェイスの）実装の後に！」ということです。 「そんなことができるわけがない」とバカにされますが、そういう決め付けは思考停止ですよね？ ともかく、眉に唾塗っていただいてけっこうですので、続きを読んでください。 一般的なシステムにおいて、一番手戻りが大きい（波及する箇所が多い）仕様変更はテーブル変更を伴うものです。下手糞な設計で、他に悪影響を与えるのもテーブル設計です。 逆に、テーブル設計が美しく合理的にできていれば、他の工程は非常に楽になります。 では、仕様変更を防ぎ、美しく合理的なテーブル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
