「いい感じに成長する」エンジニアのキャリアと学び方 - 2023年オススメPython本を添えて - Lean Baseball
このブログおよび, 登壇・アウトプットはゴリッゴリのエンジニア, 本職はコンサル企業のマネージャーとしてクラウドエンジニアリングのコンサルをやっている者です*1. この記事は, 当ブログの名物である, Pythonのオススメ書籍（と関連する技術書）の紹介エントリーです！ ※去年の記事はこちら. 本年のエントリーでは「今最もいい感じなPython本」の紹介に加えて, キャリアごとに読むべき技術書（と学び方）の選び方 この年末に読んで欲しい技術書（Python本とそれ以外） 「エンジニアのキャリア形成的に期待値の考え方大事だよ」という話 この三本立てでご紹介できればと思います. というわけで, 本年のラインナップは以下の通りです. 要約すると キャリアレベルを考える オススメ技術書籍2023 ジュニア🔰 メンバー マネジメント ボード 結び - キャリアごとの期待値 【番外編】私の推し書籍2
自分でシュッとデータ分析をできる人になろう - 「データ分析人材になる。」から学んだこと - Lean Baseball
新年あけましておめでとうございます🎍 年末年始は色々と手を動かしつつ*1, 積ん読を消化していたのですが, 昨年最後の読書🍺 特にこの本にオッってなりまして読み終わる寸前には, これもうすぐ読み終わるのですが、なぜ積ん読にしてたワイは🤔 ってぐらい名著でした📖 https://t.co/RgTILDGc7r— Shinichi Nakagawa (@shinyorke) 2021年1月3日 ...という感想が出る程度にこちらの書籍に興奮しました. データ分析人材になる。 目指すは「ビジネストランスレーター」 作者:木田 浩理,伊藤 豪,高階 勇人,山田 紘史発売日: 2020/10/15メディア: Kindle版 データを使って仕事をする人は（データサイエンティストに限らず）サラッと読んだほうがええやぞ！ というぐらい良い本だったという話を2021年最初のブログとして書きたいと思い
エンジニアの辛い仕事をいい感じにする技術 - コンサルの仕事術・思想から学べること - Lean Baseball
エンジニアの辛い仕事を消す本かも（多分） 2014年の秋にリクルートに転職してから何社か経て今も自社サービスのエンジニアとして働いてるマンです. リクルートに入ったとき, そしてその後の転職先*1などなどで, 社内外問わずのコミュニケーションの辛さ. 社内調整, 顧客折衝etc... コードじゃなくて, ドキュメントを書く仕事の辛さ. プレゼンテーション・説明そのもの. 技術わかんない上司に説明(ry*2 みたいな経験をたくさんしました&これはエンジニアをやってたら誰でも直面する事態かなと思います, 自社サービス企業だろうがSIer/受託開発の企業だろうが. そもそも, 昔の調査にもそんな雰囲気ありますし, おそらく今もさほど変わらないでしょう. ...ということを, 前回のブログの執筆中および反響で改めて思い*3, そういえば自分はこの辺, 元々ITコンサルタント*4だった時に学んだこと
シニアエンジニアの懺悔とこれから - 2019年の個人ふりかえり - Lean Baseball
理想の休日です（察し） 年末年始休暇でようやっと一息つけました. ビール片手に趣味コードの読み書きができる日々が戻ってきて最＆高です.*1 今年もあと少しとなりました, ふりかえろう！っていう気持ちが残ってる間に書いときます. 2019年の懺悔, 2020年どうする 2019年の懺悔, 2020年どうする 出来事からふりかえる 40歳になった 転職（⚾→報道） アウトプット（主に登壇） 他職種のコミュニティでLTして盛り上げた by #PRLT 地方PyConツアー（札幌→沖縄そして広島） ブログについて アウトプットの総括 抱負からふりかえる 仕事・スキル関連 プライベートなど 2020年というこれから 仕事について 近々では...デブサミ2020 出来事からふりかえる 出来事ベースでのふりかえり. 仕事とかアウトプットなど. 40歳になった さようなら30代, ようこそ40代 shin
無能な同僚と働くということ。 - WETな備忘録
君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、
平成の終わり - 2019前半ふりかえりと令和に向けて - Lean Baseball
写真は今月最初に花見したときの井の頭公園です. ぼんやりと空を眺めまわしてみる桜は最高でしたが、本題とは関係ありません.*1 それはさておいて、今日（2019年4月30日）は平成最後の日、なんやかんやでちょっとした大晦日感ある（それも、次はあと数十年先だろうという）ので流れにのってふりかえりたいと思います. おしながき おしながき 今年（2019）前半のふりかえり 仕事 対外活動 プライベート 平成（過去5年）のふりかえり 野球とPython 仕事とかプライベート このブログについて 令和の時代にむけて（これからチャレンジ・やってくこと） 仕事 PyCon JPと #rettypy （他,Python系の何か） DevLOVE X登壇 プライベート 今年（2019）前半のふりかえり 備忘録程度にふわっと. 仕事 今の会社...というより、ずっと宣言していた野球界の仕事に就いてから1年と3ヶ
ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
「タダ」は許されぬ！がそれでも 「信頼取引」をしちゃう理由と意志｜中川 伸一 / Engineer Manager
まずはじめに断っておくと、私自身は、 自分がプロとして仕事で価値を出している・稼いでいるノウハウを「タダ」で提供したり、やってあげたりすることはしちゃいけない！！！（断言） というかなり強いこだわりを持っている。 （対象が若い人であったとしても）他のヒトにもこれは強く言ってる（はず）。たとえ相手が目上だろうが、昔お世話になったヒトだろうが、両親家族血縁だろうが。 なぜなら、過去に所属していてかつ好きなサービスで、 「知見・経験・ノウハウはタダじゃない」 「知見は然るべき所でしかるべき報酬をもらってお互い幸せになろう」 と経験の面で実感しているのと、もうちょっと一般的な話題だと最近ちょっと話題になってた「タダでやってよ問題」と背景・理由は同じだったりする。 ちなみに、これはエンジニアじゃなくても同じ（断言）。 安易にタダでやっちゃうと、色んな意味でサムネイルの通り「辛いです...」ってなっち
組織に流れるフォースを間接的にコントロールする仕事 - @i2key のBlog
Recruit Engineers Advent Calendar 2018 - Adventar ということで、エンジニアリングマネージャー的なことを書いてみます。1on1とか採用とか評価制度とかではなく、組織力学のような話を。 フォースを感じる 自分は普段からエンジニア組織をマネジメントする際に「構造によって発生する力学」をすごく意識しています。いま、大体100人弱の社員エンジニア組織をマネジメントしているなかで、役割上、判断する仕事がかなりの割合をしめます。その判断でどんな力学が発生して最終的に現場で何が起こるかまで可能な限り想像力を張り巡らさないとならないです。そして、この想像力において、どれだけ解像度を高くできるかこそが現場感だと思います。経験がないと何がおこるか想像すら出来ないと思うので。 ビジネスにおける意思決定で発生したフォースは徐々に伝搬し、最終的にエンジニアの現場に流れ
エンジニアリングマネージャーという仕事について - kobakei's blog
今自分が働いている会社ではエンジニアリングマネージャーという肩書で仕事をしています。「ああ、エンジニアのマネジメントをする人ね」ってことなんですが、具体的にどういうことを考えてどういう仕事をやってるかを実際にやってみて分かったこともあるのでまとめておこうと思います。 一応注意としては、「自分はこう考えて仕事してるよ」っていうだけの話で、会社や組織によっては全然違うことを考えたり実行してる人も一杯いると思います。自分の仕事はピープルマネジメントがメインです。 ミッションは「エンジニアチームの生産性を最大化すること」 そもそもエンジニアリングマネージャーって何のために存在してるかというと、エンジニアチームの生産性を最大化するために存在してると思ってます。生産性を上げるためには、各メンバーのモチベーションを高く維持しないといけないし、メンバーのキャリアアップをサポートしないといけないし、メンバー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
