インプットのすゝめ | 外道父の匠
絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。 当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。 はじめに これは私が二十数年間、プログラマー・インフラ・SRE といったエンジニアとして通ってきた中で、どのようにインプットをしてきたかを整理してみるチラ裏です。 自分は一般(?)と比べれば少々特殊な経歴で、情報学を学んだことも、新卒研修を受けたことも、IT系資格も、転職したこともない…… ほぼ独学による野良エンジニアとして生息してきましたので、あまり参考にはならないかもしれません。 それでも一応長く生き抜いてきたエンジニアの経験として、インターネットに数多くある参考例の
エンジニアリングマネージャとして入社した最初の取り組みとして、エンジニア全員(およそ100人)と1on1をしました - だいくしー(@daiksy)のはてなブログ
はてなにエンジニアリングマネージャとして入社して2ヶ月と少し経ちました。 マネージャとしての「最初の100日」もいよいよ終盤です。 note.com 入社して最初の取り組みとして、およそ100人のエンジニア全員との1on1を実施しました。 なぜ全員とやろうと思ったか イギリスの人類学者であるロビン・ダンバーによって提唱された「ダンバー数」というものがあります。 これは、人間が安定的な社会関係を維持することができる人数の認知的な上限について提案された数字です。大雑把に説明すると、人間が相互に認識しあって社会関係を築ける人数はおよそ150人程度、というものです。 要するに1つの組織でお互いに顔見知りの状態で活動ができる集団の人数上限が150人前後であるということです。 このエントリを書いている時点で、はてなのエンジニアはおよそ100人ほどいます。つまり、はてなのエンジニア組織は、まだダンバー数
育児中でもエンジニアとして技術キャッチアップするために編み出した西谷流・勉強法
西谷圭介 国内SIerで金融系基幹システムの開発等に従事した後、クラウドサービスの開発ならびに新規事業立ち上げを経て2014年にアマゾンウェブサービスジャパン株式会社（現アマゾンウェブサービスジャパン合同会社）へ。国内企業のクラウドシステム設計支援を実施しつつ、日本におけるサーバーレス市場の創出と普及に尽力。プロトタイプ開発を行う部門の立ち上げに従事した後、2021年6月より現職。CTOとしてプロダクトを国内外に提供すべくすべてのレイヤで開発に従事している。フロントエンドが好きでインフラもそこそこわかるバックエンドエンジニア。 X（@Keisuke69）・ブログ 第1回「西谷圭介が振り返る、育休なしで乗り切った娘2人の誕生と仕事の両立」では、子どもができる前後の生活の変化や仕事への影響などについてお話しました。子どもが生まれたことで時間の使い方や過ごし方を変える必要があり、その中で「エンジ
開発と保守・運用の分業は個別ミッションの遂行手段にコンフリクトを生じさせやすい - mtx2s’s blog
ソフトウェアエンジニアリング組織の主たる業務機能は、開発、保守、そして運用の3つだろう。これらをどう組織化するか。それが、生産性にもビジネスにも影響する。私は多くのケースにおいて、この3つの機能をすべて持つ、少人数のプロダクトチームをいくつか組織化する。その理由は、過去の記事で何度か書いたように、開発でのアウトプットに対するフィードバックサイクルをまわせるようになるからだ。それが、技術・サービスの両面を向上させる。 しかし本稿のケースは違う。ここで取り上げるのは、保守・運用が、開発とは分離された構造を持つ組織だ。この体制における課題を明らかにし、そのうえで解決策を探ってみたい。 事象は開発と保守・運用の分離が上手く機能していないこと 問題は開発が保守・運用を阻害すること 課題は個別ミッション遂行におけるコンフリクトを解消すること 対策は共通ミッションに立ち戻ること 結論は両チームをあえて密
キャリアと給料 - たにしきんぐダム
(自分の気持ちを整理するために考えをダンプしただけの雑文です) 日本のエンジニア達は海外に出なければいけない｜Kei というブログを見た。日本より海外の方がソフトウェアエンジニアの給料が一般に高いので海外に行こうという話 僕は今ポーランドの会社にコンパイラエンジニアとして(日本からリモートで)働いていて、コンパイラバックエンドやIDEなどの開発をフルタイムでしている。"海外" に関する話だけど上記ブログに載せられているスクショにはポーランドが見当たらないですね。 上記のブログのソースとなった Average Software Engineering Salaries by Country [2022] を見てみると、 Japan $36,024 に対して Poland $22,740 で日本のほうが200万円くらい平均が高い。実際、日本でフリーランスとしてWebアプリケーションとか書いてた
キャリアハックの奇行 - Software Transactional Memo
エンジニアの奇行 嚢中の錐という言葉がある。有能な人物は自ずと傑出していくという意味だが、有能さとは例えば学歴の高さとは一致しない。 たとえMIT卒であろうとも大成するとは限らないし、ましてや入試の点数などで見れる人間の側面は限定的である。 企業などで採用する側からしてみたら当然ながら採用後の活躍を期待して雇用するのであり、入社をゴールとしてそれ以降働かなくなる人は望ましくないし、学歴や入試の点数によってそういう人かどうか判定する事はできない。 活躍という観点で言うと長いキャリアにおいてより重要となるのはキャリア開始時での能力の高さよりも、険しく長い道のりを自己メンテナンスしながら歩み続けられる根気の強さが重要とされている。その根気の源泉は執着だったり崇拝だったり妄信だったりトラウマだったり原体験だったり人によって様々だが、ここではひっくるめて「やる気」と簡略化して呼ぶことにする。 さて「
成長に近道はない。責任から逃げない。私が職業エンジニアとしてキャリアを築いた10年で意識したこと - Findy Engineer Lab
ソフトウェアエンジニアとして成長するために続けてきた活動と、学習を支えるモチベーションは何だったのか。Repro株式会社の橋立友宏（joker1007）さんに10年以上のキャリアを振り返っていただき、それぞれのステージで意識してきたことについて寄稿いただきました。 Repro株式会社でチーフアーキテクトをしている橋立です。ネット上ではjokerの名前（@joker1007）で活動しています。 私は神戸大学法学部を卒業し、野村総合研究所でテクニカルエンジニアとして勤務、株式会社ウサギィでの受託開発を経て、フリーランスエンジニアになりました。その中で縁があったRepro株式会社に正式にジョインすることになり、CTOとして6年ほど勤務。会社のステージの変化で、立ち位置がCTOという肩書と噛み合わなくなってきたため肩書を変更し、今はチーフアーキテクトとして勤務しています。 以前、自分のブログで「ソ
「見積もれ」には「わかりません」で答えた Hacobuがフルリプレイスを成功させるまでの道のり
今動いているサービスを止めて、フルリプレイスすることはできるのかーー。そんな、一見無謀とも思える挑戦をやり遂げた企業がありました。株式会社HacobuのCTOである戸井田裕貴氏は、なぜクラウド型物流ソリューションである「MOVO」のフルリプレイスを決断したのでしょうか。その秘密に、レクターの代表取締役であり、日本CTO協会の理事でもある広木大地氏とともに迫ります。 HacobuのCTO ーーまずは戸井田さんに、自己紹介をお願いしてもよろしいでしょうか。 戸井田裕貴氏（以下、戸井田）：僕は、そもそものキャリアでいうとソーシャルゲームの開発が長くて。2011年から丸6年ぐらいなので、まさにソーシャルゲームバブル、スマホバブルがあったあの超加熱していた状態で、その時トップランナーだったgloopsという会社で、ソーシャルゲームをバンバン作っていました。そこの新規プロダクトのリードばかりをやってい
ダブルメンテ状態は、Hacobuにとっては“死” 「フルリプレイス」をやり遂げるためにCTOが決断したこと
ダブルメンテ状態は、なんとしても避けたかった ーーフルリプレイスに対して、社内で反対はなかったんですか？ 戸井田裕貴氏（以下、戸井田）：土日の48時間を使ってバシッと移行しきるのは、けっこうリスクがあるという雰囲気は出ていましたね。僕は絶対にやりたかったので、そこは話し合いました。 ーーそれをどう説得したのですか。 戸井田：新・旧システムのダブルメンテ状態は、なんとしても避けたかったんですよね。なんでかというと、営業はまずプロダクトを売っているから、両方を理解しなきゃいけないじゃないですか。新・旧で思想や使い勝手がぜんぜん違うし、しかも開発のスピードとかも変わってくるんですよね。こちらは速いけどこちらは遅いみたいな。 そんなことをしたら、営業もCSも辛いと思うんですよ。両方使うお客さんとかが出たら、さらに辛いと思うんです。どちらにしても、両方理解して売っていく状態になる。もう大変だし、開発
テックリードを再生産可能にする - テックリード養成講座をやっている話 - 貳佰伍拾陸夜日記
この記事はEngineering Management Advent Calendar 2022の7日目です. 今はエンジニアリングマネージャ(EM)としてエンジニアリングマネジメントの4領域(プロダクト・プロジェクト・テクノロジ・ピープル)すべてを見ていますが, それ以前は長い間テックリードをやっていました. その経験を活かして, 最近は後進を育ててテックリードあるいは「弱いEM」*1をできる人材を増やそうとしています(これ自体がピープルマネジメントの一環ですね). テックリードを育てるためにやっていることの全容を詳細に書くと本が1冊書けるくらいになってしまうと思うので, その中でも再利用可能そうな(と言うより再利用可能にしたいと目論んでいる)「テックリード養成講座」について紹介したいと思います. Memeplex.appで生成した, テックなリードが養成されるイメージ 経緯 僕自身は,
エンジニアのための自分経営戦略 - 西尾泰和のScrapbox
各農家からの出荷を約50の市場へ配送する際の、各トラックにどの品目を何ケース積載するかの配車プランを自動作成するアルゴリズムを開発。
試したいから、作る。ghq、goreの作者motemenの開発は「自分本位」で駆動する - エンジニアHub｜Webエンジニアのキャリアを考える！
試したいから、作る。ghq、goreの作者motemenの開発は「自分本位」で駆動する 次々とOSSを送り出す株式会社はてなのCTO、大坪弘尚さん。連続開発を支える、発想の源、そしてモチベーションをご本人に伺いました。 エンジニアにとっての強みとは何でしょうか。その答えはさまざまですが、「プロダクトを完成させるスピード」という要素は、“強み”の一つの指標と考えていいでしょう。 「エンジニアの会社」として見られることの多い株式会社はてなの中でも特に「作るスピードが早い」と一目置かれる人物がいます。CTOの大坪弘尚（おおつぼ・ひろなお／ @motemen ）さんです。 大坪さんはghqというツールを20代で公開し、コミュニティから高い評価を受けました。それにとどまらず、GoにおけるREPLを実現するツール、goreも続けてリリースし、GitHubで2000以上のスターを獲得しています。常にオー
内田 誠悟のプロフィール - Wantedly
GitHub トレーニングチームから学ぶ Git の内部構造GitHub トレーニングチームが日本で初のトレーニングイベントを行うのをイベント運営面からサポート。200 名以上が参加したイベントとなった。ヤフージャパンの正式な仕事ではないが、ヤフージャパン在籍時の最後の仕事となった。 Git, GitHub 導入社内に GItHub Enterprise が導入されたのをキッカケに、当時在籍していたヤフースポーツ開発チームをリードして SVN から Git, GitHub に移行した。ソースコードの移行に留まらず Git と GitHub の使い方に関するドキュメントの整備やメンバーの教育も行った。社内における GitHub 導入の先行事例だったため、そこでの知見を元に他部署に展開。他部署のメンバーと共に Git/GitHub 社内勉強会を開催。(昔のことで正確な期間が思い出せない) 使用
ITエンジニアの海外転職を成功させるちょっとしたテクニック集 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
ITエンジニアが英語圏の会社へ海外転職する際、それを成功に導くちょっとしたテクニック集。これは<成功への王道！>とかではない。あくまでもちょっとしたテクニックになる。 こういうのが意外と重要。シンガポールからヨーロッパのIT企業に転職することになった。オファーをもらうまでの過程ではっきりしたのはシンガポール在住日本人の私と比較すると「EU圏内に住むヨーロッパ人」の方がかなり有利であることだった。 それは当然だ。シンガポールのITスタートアップで働いている時も人材募集をすれば世界各国から履歴書が送られてきたが、基本的に応募者がシンガポール在住者の方がなにかと話が早いしオファーも速攻で出しやすかった。応募者が国内在住者だと「じゃあ＊＊月＊＊日にオフィスに来て技術面談をしましょう」「それでは＊月＊日から一緒に働いてもらえますか？」と、こうした会話がカンタンにできた。 もしこれが国外在住者だとこう
知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ - assertInstanceOf('Engineer', $a_suenami)
週末の午前中、カフェでアイスコーヒーを飲みながらふとポエムでも書いてみようかと思い立ってしまったので、ちょっと前からよく考えていることを書く。本当に思いつきで書くので乱文になる可能性が高いけどご容赦いただきたい。そもそもブログを書くこと自体が相当久しぶりだ。 僕ももう 30 をすぎて、プログラマの世界ではさすがにもう若手とは呼べなくなり、教育っていうのはおこがましいけど、まあ自分より若い人たちの指導みたいなことをやらないといけない立場になってきたからこそ、「いいプログラマとはどういう人なんだろう。この人たちはどういうことを学べたら幸せだろう。」ということをよく考えるようになった。そういう話をする。 プログラマは手段のスペシャリストである 世の中には目的・手段論みたいな論調が存在する。 「それは手段だよね。目的をはき違えたらダメだよ。」という話はいたるところでよく耳にするんだけど、僕はこれを
新技術導入の遅さの一端はラーニングモデルの違いかもしれない - メソッド屋のブログ
以前から不思議に思っていたことがある。それは、少なくとも米英の人は、ソフトウェア技術やプロセスに対して誤解が圧倒的に少ないということである。 別の回でも書いたが、イギリスの会社とお話しした時も、「アジャイル」に対するとらえ方、考え方は、100%といっていいほど正確だった。 バリューストリームマッピングで困っている人の話 今回の出張で、Sam Guckenheimerに依頼されたことがある。ある人が「バリューストリームマッピングをやっているのだが効果が出なくて困っている」だから原因を一緒に探ってほしいとのことだった。 Samと一緒に彼の話を聞いていると、バリューストリームマッピング、DevOps に関する考え方とらえ方は極めて正確だった。彼の問題は、「コンセプトの理解」は何の問題も無く、その先の「実際にやってみて工夫してみないと到達できない部分」の問題だった。 なぜか米英では、ソフトウェアの
【雑記】メンター業務をがんばってたら最強の後輩が産まれてしまった - 歩いたら休め
今年、いわゆるデータサイエンティスト的なスキルの後輩が入ってきて、私がメンターの役割を任されました（正確にはメンターになるはずのメンバーが抜けてしまい、早いタイミングで私が引き継ぎました）。 彼は、今時珍しく(?)、数学的な能力と、その手法を実世界に結びつけるセンスを兼ね備えて持っています。 ただし、プログラミングやエンジニアとしてのスキルは、入社時にはあまり持っていませんでした。 せっかくメンターになったので、ナントカっていう分析手法の話を「わかんねえなあ」って思いながら聞いてたり、「こういうこと勉強したらいいんじゃない？」とか唆したり、自分や同期がつらいと思っていたところを取り除いてたりしてました。その甲斐あったのかは分かりませんが、割と楽しんで仕事しているようだし、エンジニアとしてのスキルも順調につけていっています。 そこで、メンターの立場で心がけたことや、スムーズに業務できている要
ドナルド・トランプ氏をイメージしたプログラミング言語「TrumpScript」が滅茶苦茶すぎる - BppLOG
アメリカ大統領選挙候補者であるドナルド・トランプ氏をイメージした Pythonベースのプログラミング言語「TrumpScript」が公開されています。 特徴が滅茶苦茶だったのでご紹介します。 GitHub - samshadwell/TrumpScript: Make Python great again どうやら米ライス大学の24時間ハッカソンで作られたようです。 ハッカソンでの優勝は逃したものの、日々issueにバグ報告が上がっており、 よりトランプ氏らしくなるように改善がされているようです。 特徴 浮動小数点型は使えず整数のみ。アメリカは中途半端なことはしない。 数値は100万より大きくなくてはいけない。それより小さい数字は取るに足らない。 importは使えない。全てのコードはアメリカ製でなければならない。 True,Falseの代わりにfact,lieを使う。 変数名に使えるのは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience
http://jisakutech.com/archives/2018/04/43687
