【保存版】半年以内にエンジニアになりたい人が読んだ方がいい新卒研修資料まとめ - プログラミングとデザイン、スタートアップの話
エンジニアを目指して今プログラミングを勉強している人向けに、開発に関してより知識を深められる新人研修スライドをまとめました。 Progateやプログラミングスクールだけでは学べない内容ばかりなので、新人エンジニアの人は目を通しておくといいです。 各企業で新人研修で実際に使われた資料なので、どんなことが開発の現場では求められるのかということが掴めます。 ここにある内容を100%理解することは難しいですが、少なからずインターンや就職をする時に役立つはずです(わからない箇所は本などを読んで補足しましょう)。 ▶プログラミングを効率良く勉強したい人はこちらの記事 もオススメ 全員共通で読むべきスライド Cookpad★ この資料で学べること リクルートテクノロジーズ★ この資料で学べること Git/コードレビュー GMOペパボ この資料で学べること GMOペパボ この資料で学べること GMOペパボ
社員はほとんどエンジニア！ 東京・仙台・北九州・鯖江の4拠点で「エンジニアの幸せな働き方」を追求するメンバーズエッジの開発スタイル - はてなニュース
「約40人いる社員のほとんどがエンジニア」「東京、仙台、北九州、鯖江に拠点を持つ」「その中で一番人数が多いのは仙台オフィス」……という、ちょっと不思議な、アジャイル開発の専門集団を抱えるメンバーズエッジという会社があります。地方に複数の拠点を置き、場所にとらわれることなく、最先端の技術を使う開発案件を扱い、“生涯エンジニア”として活躍できるように仕組みを整える──そんなメンバーズエッジの仙台オフィスで働くエンジニアお二人と、エンジニア出身ではないけれどエンジニア組織を率いている社長の塚本洋さんに、「エンジニアの幸せな働き方」について伺いました。 この記事の取材は、東京オフィス（東京都中央区晴海）と仙台オフィス（宮城県仙台市青葉区）をテレビ会議システムでつないで行いました。上の写真左から、塚本洋さん、鹿野徹也さん、平野高広さん。 （※この記事は、株式会社メンバーズエッジ提供によるPR記事です
良いテックリード、悪いテックリード - 小さなごちそう
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
データサイエンティストもしくは機械学習エンジニアになるためのスキル要件とは（2017年夏版） - 渋谷駅前で働くデータサイエンティストのブログ
この記事は2年前の以下の記事のアップデートです。 前回はとりあえずデータサイエンティストというかデータ分析職一般としてのスキル要件として、「みどりぼん程度の統計学の知識」「はじパタ程度の機械学習の知識」「RかPythonでコードが組める」「SQLが書ける」という4点を挙げたのでした。 で、2年経ったらいよいよ統計分析メインのデータサイエンティスト（本物：及びその他の統計分析職）vs. 機械学習システム実装メインの機械学習エンジニアというキャリアの分岐が如実になってきた上に、各方面で技術革新・普及が進んで来たので、上記の過去記事のスキル要件のままでは対応できない状況になってきたように見受けられます。 そこで、今回の記事では「データサイエンティスト」*1「機械学習エンジニア」のそれぞれについて、現段階で僕が個人的に考える「最低限のスキル要件」をさっくり書いてみようかと思います。最初にそれらを書
フィボナッチ工数見積は「完成させます！（徹夜で）」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます！」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには＊＊日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな？誰だっけ、それ言ったの？オレじゃねーよ。お前だよ。おめーの
今はコードがお偉いさんなんだからMOBは雁首揃えろって話 - アンカテ
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ Mob Programmingって初めて聞いたけど、とてもいい方法に思える。 コードを書く時に、今現在の仕様はわかっていたとしても、今後どうなるか、どういう方向に発展するのか気になって、ビジネス的にその分野に詳しい人の所に聞きに行ってから書きはじめることがあるし、性能的に大丈夫かDBに詳しい人の意見を聞いたり、何か迷った時に過去のプロジェクトで似たようなケースをどっちの方法で解決したか調べたりすることもある。 書き出すとすぐ終わる短いコードでも、書き出す前に、聞きにいったり議論したりする時間が随分かかっていることもある。この時間をかけないと、結局、後で変更になるので、先に聞きにいくのがベターなんだが、チーム全員集まってひとつのコードを書けば、そういう時間を省略できるような気はする。 だから、これが生産性が高いということは感覚的に
企業に移って5年が経ちました - 渋谷駅前で働くデータサイエンティストのブログ
月日が経つのは早いもので、かつてボンクラ研究者だった僕が企業（そしてインダストリー*1）に移ってからちょうど今日で5年が経ちました。インダストリーに移ってからのこの5年間で様々なことを体験し、あるいは見聞し、あるいは決断したりしてきたわけですが、良い区切りなので自分にとってのマイルストーンとするためにも、ここでこれまでの5年間を振り返ってみようと思います。 Disclaimer 以下に体験談もしくは見聞談として記載されている内容は、特に断りがなければ自分自身の複数の体験や見聞及び同業の友人知人からの見聞をマージして一般化したものであり、過去現在の個々の特定の所属先における特定のエピソードや職務内容及び特定の個々人のエピソードなどを意味するものではありません。またここで述べられている意見はあくまでも個人の主観的な意見であり、いかなる特定の企業・組織・機関も代表するものではありません。 この5
リーダー(管理者)ではなくエンジニア(実務者)でありたいと願う人々へ - おうさまのみみはロバのみみ
「お前は向いていないんじゃない、やってないだけだ」 この一文を読んでほんの少しでもなにかを感じた人は是非とも↓の本を今すぐに読むべきだ。 エラスティックリーダーシップ ―自己組織化チームの育て方 作者: Roy Osherove,島田浩二出版社/メーカー: オライリージャパン発売日: 2017/05/13メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 本著はみんなが考え、感じているリーダーシップという曖昧模糊な概念に対して具体性をもたらせてくれる。 それは「チームリーダーの役割は優れた人材が育つのを助けること」と定義付けていることだ。 このシンプルである意味で本質をついている定義付けが本著を名書たらしめているとぼくは思う。 この本の構成は1部〜4部(おおよそ本書の半分ほどを占めている)までが著者によるリーダーシップとはなにか？3つのフェーズの分類とそのときに期待さ
いま学ぶべき第二のプログラミング言語はコレだ！ 未来のために挑戦したい9つの言語とその理由 - エンジニアHub｜Webエンジニアのキャリアを考える！
いま学ぶべき第二のプログラミング言語はコレだ！ 未来のために挑戦したい9つの言語とその理由 業務に必要なだけではなく、コンピュータによって問題解決できていない分野を切り開き、エンジニアとして戦っていくため、刺激的な第二プログラミング言語に挑戦しましょう。Rust、Go、Erlang、Elixir、Clojure、Scheme、OCaml、Haskell、Scalaを紹介します。 みなさんが使えるプログラミング言語はいくつあるでしょうか？ ひとくちに「使える」といっても、ひととおりのチュートリアルは終えたという段階もあれば、言語仕様（あれば）やライブラリを知り尽くしていて、思いついた処理を即座にコード化できるという段階もあります。リファレンスとか参考書を見ながらであれば使える、ということも多いでしょう。 ベテランエンジニアなら、いろいろな仕事に携わっているうちに、さまざまな環境でそれぞれ必要
AWS事業部の採用方針について | DevelopersIO
主にクラスメソッドメンバーズにおけるサポートサービスとフートシリーズ（運用保守オプション）を担当するグループです。運用保守、システム監視、セキュリティ監視、継続的コンサルティングと、システム稼動後のお客様インフラを24時間365日体制で安定した状態に保つために日々お客様とやりとりしています。 このように、一つの部の中に担当業務が違う複数のグループがありますが、部全体のビジョンはただ一つ、「AWSに関する圧倒的な量のノウハウを用いて、AWSインフラを安く早く構築し、AWSのことをまるっとお任せしてもらうことで、お客様のビジネスに貢献する」です。そして同じビジョンを掲げたチームとして、採用方針もグループ毎に分けず、部として統一しています。 今回はAWS事業部の採用方針をご紹介します。 AWS事業部の採用方針 AWS事業部の採用方針は以下の3つです。 技術が好きな人を採る クラスメソッドはエンジ
出る杭を打つ技術
若者の成長曲線は半端なく、おじさんエンジニアは日々恐怖を覚えます。 出る杭はちゃんと打っておきましょう。 環境の弄りがいのあるツールを教えるEmacs, VIM, zsh, tmuxなど…設定のいじりがいのあるツールは理想の環境を追い求めても終わりはなく、コンフィグはどんどん膨れ上がるばかりです。 それらを「一流のプログラマは、一つの道具にこだわりとことん使い尽くすもんだぜ」とでも言って、ずっとDotfilesのリポジトリばかりいじるようになってくれれば、彼らがプログラミングに費やす時間は減るはずです。 バイナリアンにさせるいくらアプリケーションが作れても、低レイヤのことが分からないとダメだと刷り込みます。 「プログラムがどうやって起動するか分かってる? えっ、mainを書けばそれが呼ばれる? あのなぁ、_startというのがあってだな…」 無駄に低レイヤに詳しいおじさん力を活かして、あた
【雑記】メンター業務をがんばってたら最強の後輩が産まれてしまった - 歩いたら休め
今年、いわゆるデータサイエンティスト的なスキルの後輩が入ってきて、私がメンターの役割を任されました（正確にはメンターになるはずのメンバーが抜けてしまい、早いタイミングで私が引き継ぎました）。 彼は、今時珍しく(?)、数学的な能力と、その手法を実世界に結びつけるセンスを兼ね備えて持っています。 ただし、プログラミングやエンジニアとしてのスキルは、入社時にはあまり持っていませんでした。 せっかくメンターになったので、ナントカっていう分析手法の話を「わかんねえなあ」って思いながら聞いてたり、「こういうこと勉強したらいいんじゃない？」とか唆したり、自分や同期がつらいと思っていたところを取り除いてたりしてました。その甲斐あったのかは分かりませんが、割と楽しんで仕事しているようだし、エンジニアとしてのスキルも順調につけていっています。 そこで、メンターの立場で心がけたことや、スムーズに業務できている要
ベンチャー系行ったらレベルが高すぎて辛い。 - 負け犬プログラマーの歩み
今の職場で働きだして少し経つが、既にエンジニアとしての自信を割と失っている。 俺は自分のことを少なくとも「そこそこのエンジニア」と思っていた。でも今の職場では、俺は下から数えた方が早い。「技術は有るが人間的にはクソ」と自負していた俺は今「技術者としても人間としてもクソ」となりかねない事態に陥っている。 言い訳の材料はある。周囲のレベルが高いのだ。 自分で言うのもなんだか経歴は豪華な人が集まっている。コアメンバーは最高学府(あえて誤用)卒はザラだし、某世界時価総額トップとか某金融会社とか某大手ゲーム会社に居たとか、某ソシャゲーの幹部とか、あのフリマサービスを作ったとか、別会社の元CTOでしたとかはたまた現役CTOやってますとか集えば、下流エンジニアも皇帝、四天王、１０傑（俺含まない）などの超一流だ。 文系で有名企業どころか正社員歴すらなく、名のしれた商品やサービスに協力会社の人間としても一度
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NOOK