100名以上のメンターをやって見えた「めちゃくちゃ伸びる人」の共通点
どうも、株式会社プラハCEO兼エンジニアの松原です。 弊社では中級エンジニアを育成するプログラミングブートキャンプ「PrAha Challenge」を2年近く運営しています。累計100名近くの方々が参加して、日々実践的な技術課題に取り組みながら、メンターと技術的な質疑応答を繰り返しています。 実はプラハチャレンジの第1期から第5期までのメンターセッションは全て私が担当しているため、累計100名近くのエンジニアの成長を間近に見てきた経験から「めちゃくちゃ伸びるエンジニアの共通点」を見つけた気がしたので、何かの役に立てばと思い、Zennにも書き残そうと考えた次第です。 ちなみに弊社が運営しているpodcastでも同じテーマについて話しているので、耳で聞く方がお好みの方がいたらぜひ以下のpodcastへ！ TL;DR めっちゃ伸びる人は 分からないことを言葉にするのが上手 情報を鵜呑みにしない
ジュニアエンジニアに意識してほしいこと - 何でも屋エンジニアのブログ
あまり大きな成果が出せずに思い悩んでいるジュニアエンジニアの方に意識して欲しいことがある。ジュニアエンジニアとは、一人前の手前のエンジニアのことである。実績を残すこと以上に、成長するためのアクションを取れているかが求められている。成長途中なので、バーンとした実績を残すことは現実的に難しいかもしれない。だがそこでめげず成長のための種をまき続けて欲しい。 ミーティング中に分からないことがあれば躊躇せず聞く。もし都合が悪ければ「後でフォローするから後で話しましょう！」となるだけで誰も損しない。その都度質問することが当人に有益なのはもちろんだが、他の人が質問しやすい雰囲気を醸成することに繋がる。なんなら先輩もその環境に助けられるかもしれない。チームの良い文化を作ることに貢献するというのは誰にでもできることではない。 PRを作る時、分からないから既存の処理をコピペするという経験は誰にでもあると思う。
エンジニアが「暇な喫茶店」をやるべきである７つの理由｜Tsukishima
人の来ない喫茶店がやりたくて始めてみました。ツキシマでーす。 暇なコーヒー屋（ツキシマコーヒー）を始めて２年くらいになりました。 近所のワンちゃんちょっと前に世の中でこんなツイート（自分のツイートじゃないですけど）がバズってたので、人が来ない喫茶店をやりたいニーズっていうのは、世間に少しでもあるのかもしれないですね。 なぜ人の来ない喫茶店がしたかったのか。３年くらい前まで普通に外資系の企業勤めをしておりましたが、フリーランスエンジニアとしての働き方ができるかどうかを試したかったのと、その働く場所が欲しかったという簡単な理由ですね。 とりあえず仕事中にコーヒーは飲むからコーヒー屋でもしようかな、くらい。 エンジニアが暇な喫茶店をやることによるメリット。実際にやってみて分かったメリットが７つあります。 規則正しい生活が出来るフリーランスのエンジニアであれば、変な時間に寝たり起きたり深夜にプログ
未経験エンジニアを採用して失敗した
採用が困難な時期に妥協して未経験エンジニアを採用したけど、それが失敗だった。なぜ失敗なのかを話していきたい。 ただし未経験エンジニアといってもいろいろあって、子どものころからずっと学習してきたような人はただ実務が未経験なだけというように考えている。こういう人はあまり未経験と考えない。 自分への戒めもこめて。 失敗点 リターンがほぼ回収できないエンジニアの生産性の違いが10倍、100倍になることは別におかしいことではない。 そのため、未経験エンジニアに費やした時間がリターンを産むまでにとてつもない時間がかかる。 たとえば、生産性100/営業日の人が10営業日かけて教えるのなら、教えられた人は、1000の生産をしなければ当然マイナスになる。これは泣こうが喚こうが世界の理なのでここは変えられない。 1000の生産は、生産性1/営業日であれば4年2ヶ月かかる。つまり生産性100倍の人を用いる場合は
「リーダーの作法」マネジメントに限らず、エンジニアとして仕事の作法について書かれた良書
2022-08-08 リーダーの作法 ささいなことをていねいにを読み終えた。 著者は Netscape でマネージャー、Apple でディレクター、Slack でエグゼクティブを経験した Michael Lopp さんで、過去にBeing Geek や Managing Humans を書かれている。 翻訳の質も非常に高く、楽しく読めた。1 そんなにマネジメント関係を読んでいるわけではないが、HITH OUTPUT MANAGEMENT や、エンジニアのためのマネジメントキャリアパス ―テックリードから CTO までマネジメントスキル向上ガイド 同じくらい良い書籍で、学びや共感を多く感じた。 自分はマネジメントのポジションについたことはないが、仕事をしていくなかでマネジメント関係のソフトスキルや複数人でどうやってうまくリーダシップを発揮して、大きい問題を解決するかに興味があるので、良い書籍
2022年7月最近のスマイル制度活用事例 - コネヒト開発者ブログ
コネヒトには「スマイル制度」という制度があります。これは開発組織でのインプットとアウトプットの活性化を促進する制度です。とてもコネヒトらしい制度になっているので、詳しくはスマイル制度 - Connehito Tech Visionや、制度が生まれた当時の記事をご覧ください。 tech.connehito.com その後、カジュアル面談などで社外の方から「実際どういったものに使われているんですか？」と質問いただくケースがちらほらあるため、どういったインプット・アウトプットが行われたかを発信していければと思います！ インプット事例 iOSDC Japan 2022のチケット（別途協賛もしています） デプロイフロー改善における参考書籍の購入 ecspresso handbook 検索チームで輪読会をする書籍の購入 検索システム ― 実務者のための開発改善ガイドブック – 技術書出版と販売のラムダ
エンジニアのタイムトラッキング事始め - Qiita
あれ、今日何やったっけ...？ 仕事を終えて、忙しい日だったな...と思いながら日報を書き始めると あれ、今日何やったっけ...？ となることがよくありました。 頑張って思い出して書き出してみると、意外とやったことが少ない。 思い出すことにも時間がかかる。 どれにどれくらい時間をかけたか思い出せない。 ので、相対見積もりもうまくできない...。 等々、様々な問題を抱えていました。 タイムトラッキングを始めてみる 同僚のデザイナーが Clockify というタイムトラッキングツールを使っているのを知っていたので、私も真似をして導入してみることにしました。登録は簡単で、Google ログインするだけで簡単に使い始めることができました。 他に有名なタイムトラッキングアプリとして、Toggl が挙げられます。 Clockify とほとんど同じ UI でシェアも高いので、こちらもオススメです。 この
スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている｜s_semiya
はじめにこの記事の対象読者は「機能しているスクラム開発チームのメンバーないし関係者」をイメージしています。 また会社のフェーズや資本状況、フルタイムでないメンバーを雇いたいなどのコンテキストもあるので業務委託が一概に悪とは言いません。 単純に相性が悪いってだけです。 また相性が悪くてもチームが即崩壊するとかそう言う話でもないです。 僕は業務委託の人が嫌いなわけではありません。ただスクラム開発と相性悪いな（主に単価的な意味で）と思っています。 あとここで言うSES的に送り込まれる業務委託の人の単価は月100万~150万円くらいです。 実は「業務委託契約」とは限らないWeb界隈の一部の慣行として「協力会社(個人を指す)」とほぼ同義語として「業務委託」は使われています。「業務委託」と呼ばれる個人に対してリーダーが指揮命令権を持ちます。契約形態は関係ありません(パねぇな)。 実態の契約形態が業務委
初心者3人でペアプロ始めたら、想像以上にメリットだらけだった - Paytner Tech Blog
ペイトナーでエンジニアをやっている脇田慎平（@shimpeee_）です！ 僕が入社した2022年5月からチーム内でペアプロ導入を提案し、実際にこれまで何度か実施して得た経験や気づきを書きます！ 結論 めちゃくちゃにイイです！！！ これからも続けていきます！！！ 以降、始めたきっかけや良かった点、苦労したことなどを書きます。 きっかけ ペイトナーには、「同期作業」という文化があります（僕がとても素敵だと思う会社文化のひとつです）。 「オンラインで繋いで、仕事の会話するもよし、雑談するもよし、黙って作業するもよし」 というものです。 業務上でのもくもく会みたいなものです。 「biz側（PM） x エンジニア」の同期作業を週2回、各30分ずつやっているのですが、これがもうすごく良くてですね。。。 ペイトナー社では現在、フルコミットメンバーは週2の出社でオフィスの席数の関係で出社日を曜日で分散させ
フロントエンドからサーバーサイドへキャリアチェンジ 研修付き採用だからできたこと - Pepabo Tech Portal
はじめまして。SUZURI事業部エンジニアの kazuhi-ra (かずひら) です。 フロントエンド開発者としての経験しかなかった自分ですが、GMOペパボの第二新卒向け研修付き採用「ペパボカレッジ」を経て、 現在ではサーバーサイドを中心に開発をしています。 この記事では、入社の経緯、入社から2カ月半行われたペパボカレッジでの研修、その後開発チームに参加してからの様子についてご紹介します。 転職活動から入社まで 前職では航空券予約サイトを主にTypeScriptとReactを用いて開発していました。 エンジニアに与えてくれる裁量がとても大きい会社で、問題を解決するために局所的にWeb Componentsを導入するなど、 前例のないチャレンジングな取り組みも応援してくださる、とても心地よい環境でした。 一方で、社内にはメンターとなるような先輩エンジニアが存在せず、すべて自分一人で何とかする
技術を極める以外に何ができるのか？ カオスな環境へ飛び込んだITエンジニアのキャリアの分岐点 - Findy Engineer Lab
はじめまして。並河祐貴（@namikawa）と申します。Webテクノロジーが大好きなエンジニアなので、若い頃は技術系の書籍や雑誌記事を書く機会をたくさんいただきました。今回は自分のキャリアの話を書かせていただくということで、ずいぶんと歳を取ってきたのだなと感じています。 思い返せば、20代の頃はWebテクノロジーに強い興味を持ち、サービス開発の現場でエンジニアリングを極めたいと考えていました。そんな自分が15年ほどたった今では、まさか経営・マネジメントに近いポジションで働いているなど、1ミリも想像していませんでした。ことに最近では「自分の経験のホワイトスペース」を埋めるべく、いろいろなことに挑戦しようとしています。 これまで紆余曲折あり、決してきれいなキャリアを歩んできたわけではありません。何を考えて今のキャリアが形成されてきたのか、これからをどのように考えているのか、これまでを振り返りな
ITエンジニア採用の難しさを要素分解・図示してみた｜久松剛／IT百物語の蒐集家
「エンジニア採用がうまく行かない」というお話をお受けする度に、1から10まで通しでご説明するのもなかなかに長尺が必要なので、今回は要素分解をして図を書くことにしました。伝われば良いなと思う内容は下記です。 CxO、VPoEの方々： 今はこんな感じです できる若手エンジニアを採用したい経営層の方々： 人もお金も結構行きますが覚悟はお有りですか？ 人事・採用の方々： 何かヒントになれば幸いです エンジニアの方々： 裏ではこんな感じでやってます 採用を手伝ってくれと言われているエンジニアの方々： 助けてあげてください 皆様： エンジニア採用は真剣に狂気の域に突入していますので、担当者を承認してあげてください 今回はエンジニア採用シーンをおさらいしつつ、エンジニア採用に向けて企業は何をすべきかをまとめてみたいと思います。 エンジニア採用シーンのおさらい 若手エンジニアの需要が高まり始めた頃合いがア
コードを書いていてマネジメントもやるようになっちゃった人へ 背中で語っていた僕が、プロダクトとピープルに向き合うまで
「Day One - CTO/VPoE Conference 2022 Spring -」は、日本CTO協会が主催するイベントです。パネルディスカッションでは、政財界、テクノロジー分野の第一人者をパネリストにお迎えし、日本CTO協会理事のモデレートにより、“Day One”をテーマにご講演いただきます。ここで登壇したのは、株式会社Lighthouse Studio CTOの海老原昂輔氏。これまでの経験から導き出した、“ソフトウェアエンジニア的思考をマネジメントに活用するアプローチ”について発表しました。全2回。前半は、最初期のマネジメントとプログラマーとして犯してしまった禁忌について。 エンジニアにありがちなキャリアの変遷 海老原昂輔氏：「コードを書いていたいけど、マネジメントもやるようになっちゃった人のための生存戦略」というタイトルでトークをします。株式会社Lighthouse Stud
未経験からWebエンジニアを目指す人に伝えたいこと
最近、未経験からWebエンジニアを目指そうと思っているんだけどどうだろう？ という相談を受けることがあったので文章としてまとめておきます。 この文章はプログラミングを学んでWebエンジニアになろうとしている人に向けています 既にこの業界で働いている人にとっては常識的な内容しか書かれていません Webエンジニアになるには そもそもの読者の方達がどのような状況にいるのかによって方針が変わります。 新卒採用 新卒採用の場合は企業が未経験者を積極的に採用をして教育をしてくれるルートがあります。 この点は普通の就職活動をしてエンジニア職として採用されるようにがんばりましょう。 ただし、最近は新卒であっても小学生や中学生の頃からプログラミングの経験を積んできたスーパープログラマーがいます。また、そういった早熟な方達以外にも、大学や高専、専門学校などでプログラミングを専門的に学んできた人たちと就職活動で
エンジニアの技術土台となる知識を得るための本の紹介 - Qiita
はじめに の参加記事になります。 個別の技術ではなく、エンジニアの成長のステップで読むと良い本の紹介 エンジニアとして成長していくときに、個々の技術を深く理解し使いこなしていくことは必要ですが、個々の技術を選ぶときにもどんな成長ステップがあるかを理解することも重要です。 実装をするという範囲をエンジニアの中心なのはありますが、実装以外の部分を理解するとその技術が最大限に活きるのかを理解するには周辺についても理解していく必要があります。そこで、実装を始める前の構造のパターン、実装を進めるエンジニアの環境などを知ることで、もっと効率的な開発が出来るようになるのかを理解していきたいけると良いと考えています。 この記事では私が経験した中でより良いWebシステムを作るという観点に立ったときに、広く理解しておくと良いと感じた本を紹介します。 これからエンジニアリングでどのような勉強をすればよいかを考え
昇給によって年収1000万円を超えるエンジニアを産み出すという目標の達成報告 - Toyokumo Tech Blog
こんにちは。CTOの木下です。 「昇給によって年収1,000万円を超えるソフトウェアエンジニアを産み出す」という目標の達成報告をしたいと思います。 実は初めて達成してからかなり時間が経ってしまっているのですが、これまで、そしてこれからの取り組みによってさらに多くのメンバーが達成していく見込みであることを受け、区切りとして記事に残しておきたいなと考えてこの記事を書くことにしました。 遠い目標 賞与の導入と増額へ 昇給の推移 目標達成 なぜ昇給にこだわったのか？ これから 遠い目標 私が入社したのは2016年3月なのですが、当時CTOの落合は「昇給によって年収1,000万円を超えるエンジニアを産み出す」ということを口にしていました。 しかしながら2016年3月以前にいた社員数は3人程度で、売上規模も小さい会社でした。 そのため人件費にかけられる金額も絶対額として大きくなく、特段給与水準の高い会
コーディングチャレンジが必要ない理由
この記事は、著者の許可を得て配信しています。 https://css-irl.info/why-i-dont-have-time-for-your-coding-challenge/ 面接を受けに来る人に何らかのコーディングテストや課題を課すのは、テック業界では標準的な採用慣行となっている傾向があります。面接を受けに来た人は採用担当者の前で、ホワイトボードに書かれた問題に取り組むように言われます。持ち帰り課題やコーディングチャレンジなどがある場合もあります。多くの場合、最初の面接（時には2回の面接）の後、自分の時間内にタスクを与えられ完了させます。一般的には応募した仕事内容と同じようなタスクだったり、または同じスキルを多く必要とするタスクの課題であったりすることが多いようです。 この記事では、ホワイトボード面接（面接者のコードに関する知識や技術をテストする面接）については全く触れていません
簡単にできるDDDのモデリング - ドメイン駆動設計 - little hands' lab
DDDではよく「モデリングが重要だ！」と言われますが、どのようにモデリングすればいいのかがわからず、一歩を踏み出せないことは多いのではないでしょうか。 そんな方のために、本記事ではDDDにおいてシンプルで成果が出しやすいモデリング手法について紹介します。 (本記事は、YouTube動画「10分でわかるドメインモデリング」の内容をもとにした解説記事です。) DDDの目的 DDDの目的から確認しましょう。 DDDの目的は2つ。 ①機能性を高めること これは、役に立つものを作ること、言い換えると「作ったけど使えない」を避けることです。 そのために、ドメインモデリングを行い、ソフトウェアを適用して役立てようとしている現実世界の領域(これの領域をDDDでは「ドメイン」と呼びます)について理解を深め、解決策を検討することを目指します。 ②保守性を高めること これは、長期間開発しても機能拡張が容易であり
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
感謝され、人に好かれる指摘の仕方
この記事に書いてあること 指摘の仕方に気を付ける事の利点 オススメの指摘方法 ※何かを強要したり、コミュニケーションの仕方を責めるものでは無いです。Tip集みたいなものだと思って気楽に読んで下さい。 導入 社内外で関わる方（特にエンジニアの方）に対して、「（指摘の仕方で損をしているな〜）」と思う事が多くあります。 Twitterで呟いてみたところ、 「そうは言っても中々苦手…。」 「気を付けてるつもりだけど、キツい言い方になってないか不安」 といった反応をいただきました。 そこで下記について、私なりの考えをまとめました。 指摘の仕方に気を付ける事の利点 オススメの指摘方法 本論 指摘の仕方に気を付ける事の利点 指摘の仕方について、ちょっと気を使うと良い事がたくさんあります。 具体的には下記の良いことがあります。 感謝される 指摘内容を前向きに検討してもらえる 誤解されずに済む それぞれ解説
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
