悪癖がなおらないのは、「周りは困ってるけど、本人は全く困ってない」から。
前回、僕は何度も何度も注意しても全然改善しないタイプの社員が、なぜ何度注意しても改善しないのかについての記事を書いた。 簡単にいえば、あれは字が汚い人の字がある日突然キレイにならないのと同質の問題であり、彼らの中にある独自のルール（よくない習慣と言ってもいいかもしれない）を変換させないと一生そのままだという事だ。 前の記事で僕は字が汚い人の字を綺麗にするためにはペン字（というルール）を習得させるのが一番であり、それと同じように仕事ができない社員にはしっかりと処方箋を出してそれを履修させるべきだと書いた。 さてここまで書いておいてなんだが、筆者の字はいまだに汚い。解決方法を知ってる癖に、なぜ僕の字は未だに汚いのだろうか？ 実はここにできない社員を改善させる為のTIPSがつまっている。 今日は実践編として、実際にどうやってできない社員を教育していくべきかについて書いていこう。 困った社員の周り
Gitのスケーリング（と、その背景） | POSTD
数年前、Microsoftは、社内全体のエンジニアリングシステムを活性化させるため、数年間にわたる投資を行う決定をしました。私たちは山のような数のチームを抱える大企業です。チームはそれぞれ、担当のプロダクト、独自の優先順位、プロセス、ツールを持っています。”共通の”ツールもありますが、チームによって様々に異なる点も多く、内部で開発した単発のツールも数え切れないほどあります（「チーム」とは社の部門のようなもので、数千のエンジニアの集まりです）。 この状況にはたくさんのマイナス面があります。 似たようなツールを構築しているチームがいくつもあり、巨額の冗長な投資が生まれている 「クリティカルマス（損益分岐点を超える生産量、普及率）」に向けた設備投資ができない 皆がバラバラのツールやプロセスを用いているため、従業員が異動しにくい 組織の垣根を越えてのコード共有が難しい “MS限定”ツールの過多のた
「スキル伝授にはペアプロが最速」というのは何故か - 圧倒亭グランパのブログ
この問いに対して、自分なりの答えを言語化できたのでまとめます。 目次 目次 疑問 実践する機会 自分なりの答え 「コードを書く瞬間の思考」にアドバイスを貰える 他の方法で代替できない ペアプロの欠点 まとめ 疑問 きっかけは、下記の方々のやり取りをTwitterで見かけたからです。 「それをできる人とペアプロする」以上に短期間で新しい技術を身につける方法を知らない。— Jxck (@Jxck_) 2017年2月3日 ペアプロが最速だろうなあ https://t.co/SdbZZ2EypI— Takuto Wada (@t_wada) 2017年2月3日 サッと調べると「最速なのは同意」という意見が大半でした。自分もこれには同意するのですが、「なぜペアプロが最速なのか？」という疑問を持ったのです。 ペアプロ、最速だと思うんだけど、なぜ最速なのかがハッキリわからない。「わからないことがすぐに聞
YAPC::Kansai 2017 OSAKAで『はてなシステムの考古学』というトークをおこないました #yapcjapan - 詩と創作・思索のひろば
先日開催された YAPC::Kansai 2017 OSAKAで、『はてなシステムの考古学』というタイトルで発表しました。 スライド中のリンクが効かないのであまり意味がないのですが、一応 Speakerdeck にも上げてあります: はてなシステムの考古学 / History of development at Hatena // Speaker Deck はてなの開発の歴史を Perl エンジニア視点からふり返るというもので、どちらかというと『はてなの開発の歴史学』とでも読んだほうがしっくりくる内容になりました。 具体的な成果物を伴わない話をするのは苦手なほうだと思っていましたが、今回はあえてこんな内容でトークすることになりました。その背景には、いつの間にか自分が社内でも古参のエンジニアになっていたこと、また、事業や組織の拡大とともに開発のあり方が多様化してきて、それまで暗黙的に共有され
Introducing Cloud Functions for Firebase
Firebase started with the belief that apps could be built with mostly client code since it was, in many instances, easier and faster. However, there are still some cases where server code is needed, such as executing trusted code, authenticating to a third party API, or running battery intensive operations. In these instances, you had to stand up your own server — until now. Today we are excited
毎週新しい機能をリリースしている、はてな「Mackerel」の開発環境やツールを聞いてきた
毎週新しい機能をリリースしている、はてな「Mackerel」の開発環境やツールを聞いてきた 馬場 美由紀（HTML5 Experts.jp編集部） はてな「Mackerel」の開発チームに、HTML5 Experts.jp白石俊平編集長が直撃インタビュー！ チーフエンジニア兼「Mackerel」ディレクターの松木雅幸さん、アートディレクターの村田智さん、アプリケーションエンジニアの濱田健さんに、どのような開発環境やツール・体制などを構築しているのか、お話を聞いてきました。 社内のエンジニア向けツールをSaaS事業化 白石：まずは、皆さんの自己紹介からお願いします。 松木：はてなはIDで呼び合う文化なんです。僕は本名の松木を中国語読みにしたSongmu（ソンムー）と呼ばれています。3年前にはてなに入社して、Mackerelのディレクターと東京オフィスのチーフエンジニアを任せてもらってます。
「東電は許せない。しかし…」 震災・原発事故から6年 福島の浜で - Yahoo!ニュース
東京電力の副社長が泣いていた。2月3日、東京・内幸町の本社応接室。福島の、ある被災者に話が及んだ時だった。「すみません…。上野さんの話をすると、つい込み上げてしまって」。福島復興本社代表を務める石崎芳行副社長（63）は、鼻をすすって息を整えた。「上野さん」とは、上野敬幸さん（44）のことだ。南相馬市沿岸部の萱浜（かいばま）地区で農業を営んでいる。副社長はなぜ泣いたのか。東日本大震災と原発事故から間もなく6年。加害者と被害者という立場だけでは計りきれない事情を知ろうと、人々を訪ね、福島を歩いた。（Yahoo!ニュース編集部） 石崎副社長は、上野さんに初めて会った時のことを鮮明に覚えている。震災から2年後の2013年3月。復興本社の代表として、福島に居を移して2カ月が過ぎた頃だった。「知人からぜひ会って欲しいと言われまして」。萱浜を訪ねると、自宅前に上野さんが立っていた。1階は津波で破壊されて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
