近況報告：無職になりました - IT戦記
みなさんお元気ですか？僕は少しだけ元気ではありません。じんわりとした夏の暑さを感じながらブログを書いています。 実は、数ヶ月前にスマートニュースという会社を退職しました。 しばらく無職 しばらくは就職せずに無職でいようかなと思っています。 すぐに再就職した方がいいんだろうな〜。とは思うのですが少し疲れたかも。 いい時代になったものだ 最近は AI の進化も素晴らしく、昔ソフトウェアで出来なかったことがどんどんできるようになってるなって感じます。 Rust とか、ちょうど欲しかった感じのプログラミング言語もあるし、 ChatGPT は完璧ではないけど何か新しいことを始めるときに素晴らしい洞察を与えてくれる。 時代は確実に良くなってる。そんな時代に「自分は働いていないくていいのか」と少し不安になるけれど、自由気ままにコードを書く、そんな時間が今あってのもいいのかなって思ってます。 オフトピック
得意なことを好きなことだと勘違いされる問題 - ミネムラ珈琲ブログ
仕事の話。例えばぼくはGoogleスプレッドシートが人並み以上ぐらいには得意だ。仕事でもよく使うし、ツールとしても好きだ。これは事実だ。 あるひとが得意としていることと好きなことが一致していることはそれなりに多いとは思う。 別の話。ぼくはアドテクが得意だ。専門の部署から動いて2年以上経つが、WEBサービスのプロダクトマネジメントの立場でぼくよりアドテクでの収益化に詳しいという人はそうそういないだろう。 だがアドテクや広告のことが好きかと言われたら全然そんなことはない。社内でそういうトピックについて一家言あるように喋っていたとしても、それは知識と経験があるものの義務としてアウトプットしているだけであって、本質的には興味がない。 ぼくにとって広告は、広告主にとっては売上拡大、メディアにとっては収益確保の手段でしかない。ぼくはコンテンツと情報流通の未来を作りたいと思って仕事をしているので、広告は
競技プログラミング、ソフトウェア・エンジニア、コミュニティ
なんか言及もされたのでアンサー的に書いてみたけど、アンサーには大してなってないな? ってやつです。一部で言及された、競技プログラミング (競プロ) 関係の話。 その前に、「プログラミングの競技」っていろいろあります。 短時間で問題に解答していく型 (ICPC / 情報オリンピック / AtCoder Regular / TopCoder とか)最適解が容易に求まらない問題のスコアを競う型 (SuperCon / AtCoder Heuristic / ISUCON / ゴルフ / ICFP Programming Contest の一部とか)対戦型 (ICFP Programming Contest の一部とか、最近のはあんまり知らないですが RoboCode / Imagine Cup とか)謎解き型 (ICFP Programming Contest で何回かありましたね。 UMIX
チーム開発で活躍するために、自分の庭を作れると良い - hitode909の日記
チームでどうやって活躍するか、まだイメージがついてない、振られた仕事をやっているだけで、仕事をしている間は忙しいけど、確認待ちになるとすぐ暇になってしまう、というメンバーの悩みを聞いていた。 巨大なチーム、巨大なプロダクトだと、すぐに全容を把握するのは難しい。その中で、この範囲なら触れています、任せてください、という庭を作るとよいのでは、という話をした。 思いつきで話したわりには意外といいことを言ってるなと思ったので掘り下げて書いてみます。 庭とは 現代では、庭のある家に住んでる人は少ないかもしれない。うちは実家が田舎だったので庭があって、ボールを蹴って回ったり、石をめくってアリを観察したり、隣の家の庭との境界もゆるくて、冒険と言って隣の家の庭で遊んだりしていた。 大人になってからの庭というと、池袋で遊んでた人が「池袋は俺の庭」と言ったり、JR新宿駅の東口を出たら椎名林檎の庭があることが知
Engineers Career Management and CTO role
Developers Summit 2019にて登壇した内容。 こちらはDevelopers Boostでの登壇の再演になります。
SIerってヤバいの？ ひろゆきがエンジニアに向けて語る、業界ごと沈まないためのキャリア戦略 - エンジニアtype | 転職type
2022.11.15 働き方 SIerプログラマーひろゆき駆け出し 日本のSI（システムインテグレーション）ビジネスの未来を危惧する声が聞かれるようになって久しい。にも関わらず、旧態依然としたビジネスモデルは回り続けており、そこでは多くのエンジニアが今も働いている。 日本最大の電子掲示板「２ちゃんねる（現５ちゃんねる）」の設立者であり、理路整然とした語り口と歯に衣着せぬ物言いで知られるひろゆき氏は、そうしたエンジニアに向けて「今すぐ逃げた方がいい」と呼びかける。 改めて、SIerはなぜ「ヤバい」のか。どうやって「それ以外の道」を模索すればいいのか。最新著『働き方完全無双』の売れ行きも好調なひろゆき氏に、今エンジニアが採るべきキャリア戦略を聞いた。 ※本記事は2018年8月7日に公開し、2022年11月15日に最新プロフィール情報に更新しています。 ひろゆき（@hirox246） 本名・西村
6 年間の起業を終えて - IT戦記
スマートニュースの社員になりました 皆様、お久しぶりです！約 7 年振りにこのブログを書いています。 元気にしてましたか？僕は元気です。 実はこの 6 年間 id:mizzusano とカクテル株式会社という会社をやっておりまして、先日のプレスリリースにもあったようにこの度会社ごとスマートニュースにジョインすることになりました。 UUUM に遊びに（？）行ってはしゃぐ僕と id:mizzusano そこで今日は振り返りも兼ねて、以下の 3 点について、この 6 年間考えていたことを書いて見たいと思います。 事業アイデアより大切なこと 起業家が健康的に働く方法 プログラマーが起業するということ 少しでもこれから起業したい人のお役に立てればと思っております。 事業アイデアより大切なこと 6 年間の事業を振り返えると失敗の連続でした。その中で、事業そのもののアイデアより共に起業するメンバーが大切
エンジニアの技術力評価は難しい? - 7年間運用してきた技術力評価制度の改善の歴史 ‒ / technology assessment 2018 04 25 - Speaker Deck
2018年4月25日にはてなさんのオフィスでプレゼンしたときの資料です。 ※このスライドは、2017年1月に公開した資料 ( https://speakerdeck.com/makoga/regional-scrum-gathering-tokyo-2017 ) に「社外評価者」の取り組みなどを追加した内容になってます。 ---- 2018/05/15追記 このスライドを公開後、下記2点を懸念する声がいくつかありました。 ・プレゼンスキルだけが高い人が過剰に評価されるのでは。 ・社内政治やコネを作るのがうまい人が過剰に評価されるのでは。 それを受けて、工夫していることを別ブログとして書きましたので、ぜひ読んでみてください。 適切な技術力評価をするために工夫していること https://note.mu/makoga/n/nfafc523957f3 ---- 2019年2月5日追記 スライドだ
HRzine
HRzine Day（エイチアールジン・デイ）は、人が活き会社が成長する人事のWebマガジン「HRzine」が主催するイベントです。毎回、人事の重要課題を1つテーマに設定し、識者やエキスパードが持つ知見・経験を、参加者のみなさんと共有しています。
リモートワークのストレス | POSTD
リモートワークのストレス ソフトウェアエンジニアリング業界では、リモートワークは大いに理にかなった働き方です。大抵はPCとインターネット接続さえあれば仕事ができるからです。よって、決まったオフィスに毎日通って働く理由は比較的少ないため、リモートワークはIT職の重要な要素になっています。最も先見的な求人市場とは決して言えないベルギーにおいてさえもです。とはいっても多くの場合、リモートワークが認められるのは週の一部のみ（おそらく週に1日か2日ぐらいが一般的）にすぎません。それにもかかわらず、リモートワークは大部分の企業で導入されるようになってきたのです。 リモートワークには多くの利点があると言われており、この働き方を過激なまでに擁護する声もよく耳にします。その多くには同意するものの、リモートワークを5年以上してきた経験から言えるのは、リモートワークにはストレスが付き物だということです。そう聞く
良いテックリード、悪いテックリード - 小さなごちそう
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
マネージャーが負うべき責任と役割とは？ 3人のリーダーが“強いエンジニアリング組織”の作り方を語る
各分野で活躍するプロフェッショナルを講師として招く、クライス＆カンパニー主催のセミナー＆交流会「汐留アカデミー」。今回は、Googleでエンジニアリングマネージャを担当した後、Incrementsにて「Qiita」などのプロダクトマネージメントを担当してきた及川卓也氏をモデレータに、情報共有ツール「Kibela」の開発をしながら複数企業の技術顧問も兼務する株式会社ビットジャーニーの井原正博氏、CTO、テックリード、プロダクトマネージャとして一人三役を兼ねる株式会社ニューズピックスの杉浦正明氏をゲストに迎えます。「強いエンジニアリング組織をつくる」というテーマで、エンジニアの組織作りやマネジメントについて考察します。 エンジニアのマネジメントと組織づくり 及川卓也氏（以下、及川）：今日のファシリテーターを務めさせていただきます、及川です。よろしくお願いいたします。 （会場拍手） 今日はこの「
100人のエンジニアを束ねるDeNAの現役部長が実践する、メンバーとの対話コミュニケーション術【及川卓也のマネジメントキャリア考】 - エンジニアtype | 転職type
ソフトウエアエンジニアからプロダクトマネジャー、エンジニアリングマネジャーを経験し、活躍の場を広げている及川卓也氏と共に、強い開発チームを持つ企業各社のエンジニア出身マネジャーたちのキャリア観や仕事術に迫る。多種多様なマネジメントスタイルから、自身のこれからのキャリア選択のヒントを見つけてほしい。 いちプログラマーからマネジャーになるとき、「現場を離れたくない」と思うエンジニアは少なくない。実際に手を動かしていないと不安だという声も多く聞かれる。 DeNAのシステム開発部部長を務める小林篤氏も、そうだった。しかし、実際にマネジャーとして仕事をするようになると、戦略的・長期的な視点でモノづくりを考えるマネジャー職の面白さが分かってきたという。 マイクロソフトやグーグル、Incrementsなどの開発現場で豊富な経験を持つ及川卓也氏が、100名を超えるエンジニアを束ねる小林氏の仕事ぶりと、De
管理職のためのエンジニア組織構築マニュアル | DevelopersIO
はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一
エンジニアのフリーランスの始め方/働き方/やめ方。あるいは業務委託の利点と正社員の利点 - みんからきりまで
この記事はフリーランスアドベントカレンダーの19日目です。 adventar.org タイトルはmizchi氏のこちらのエントリをパクりました。 mizchi.hatenablog.com 何故かというと、このエントリを読んで「ベンチャーからフリーランスになった人」との対比として「フリーランスからベンチャー社員になった人」という視点でエントリを書いてみたいなと思ったからです。 といっても、ぼくは別に廃業したわけではないので、正確にはフリーランスをやめてはいないし、副業としてコード設計のアドバイスしてほしいみたいな話は歓迎ですし、今後ずっと正社員として生きていくという気持ちがあるわけでも特にないです。 はじめましての方に説明すると、自分の経歴は 情報系専門学校卒業 => 新卒で零細SIer(Android) 1年 => 転職して零細ゲーム会社(Unity) 2ヶ月 => フリーランス(And
採用基準についてトレードオフスライダーを使って議論した - @kyanny's blog
開発者の中途採用をやっていくにあたり、「チームの誰もが採用担当」というポリシーでインタビューやコードテストのレビューなどをみんなでやってきたが、「どういう人を採用すべきか？」についての認識が合わなくなってきたと感じたので、認識を合わせるために議論の場を設けた。議論を進めるためのツールとしてトレードオフスライダーを使ってみた。うまくいくか確証はなかったが、事後にアンケートをとったら過半数からフィードバックをもらえ、全て好意的だった（五段階評価で4と5が半数ずつ）ので、まぁまぁうまくいったのだろうと受け止めて、もろもろ公開します。 使った資料はこちら。 以下、意図とか進め方とか学びとか。 最終的な目標は「採用基準についての認識が合うこと」なのだが、全員の認識・見解が一致することなどありえないと思っていて、むしろ各人の認識がどれくらいズレているのかを明らかにすることのほうが重要だと思っていた。そ
グーグルの｢最高の上司｣がチームの生産性を高めるために実践していること
世界で最も優秀な人材が集まると言われる企業の一つ、｢Google｣。そんなGoogleで｢最高の上司｣として部下から尊敬されるのは、どのような上司なのでしょうか。 Googleで人材育成やリーダーシップ開発に携わり、現在は独立しその手法を世に広めようとしているのが、モティファイ株式会社取締役で『0秒リーダーシップ』『世界一速く結果を出す人は、なぜ、メールを使わないのか グーグルの個人・チームで成果を上げる方法』の著者であるピョートル・フェリークス・グジバチさんです。 Googleにおける最高の上司の役割、部下とのコミュニケーション手法、そのレベルに近づくために必要なマインドセットについて、ピョートルさんにお話を伺いました。 データが導き出したGoogleの｢最高の上司｣ —Googleが考える｢最高の上司｣とはどのような人でしょうか。 前提として、私やGoogler（グーグラー、Googl
第15回 エンジニアとマネジメント | gihyo.jp
今回は「エンジニアとマネジメント」という話題について触れてみたいと思います。 「ラインに行ったら負け」なのか？ エンジニアもある程度成長してくると、30前後あたりでだいたいの人が「このままスペシャリストとしてやっていくのか、ラインとしてマネジメントにも携わっていくのか」という問題にぶちあたります。 わからなくもないですが、エンジニアには「ライン（マネジメント）に行ったら負け」というような風潮があります。職人と管理は相容れないような雰囲気ですね。 でも、エンジニアがみんなスペシャリストでやっていけるということは現実にはありません。もちろん会社によってもその比率は違いますが、某○ニーの子会社にいたころは、30歳（だったかな？）以降で選べる進路として、スペシャリスト1割に対してライン9割というような比率でした。 また、スペシャリストになれないからラインになるというネガティブな考え方をするのではな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rebuild: 240: Super Saiyan God Engineer (mayuko)
エンジニア採用
