私が人生でずっと悩んで追い求めていたものがついに解決した。それは、なんでも良いから何かが「出来るようになる」ことだ。 昔からいくらその対象に時間をかけても、努力しても、人並みにすらならない。人にやってもらうとか自分がやらないことに関してはうまくいくのだが、自分が何かが出来るようになるということに関しては人生５０年目だが、絶望的で、それが自分の自己肯定感や、人並みに生きることへの罪悪感を生んでいた。人生で解決したかった問題 No.1 だ。だからそれをずっと解決しようと頑張ってきた。 ギター演奏での解決方法私はクソ不器用で、なにやってもできないので、人生で出来たらいいことを２つだけ定めた。ギター演奏と、プログラミング。ギター演奏に関しては少し前に解決した。根本的な問題を一つ上げるとすると、「ゆっくりから、メトロノームで練習する」これだけだ。 ギターはもう何十年も演奏しているのに弾ける感がなかっ

最近、エンジニアは事業を理解すべきか？という話題をよく目にします。様々な経験や背景がある中での議論なため、多くの意見があり難しい話題だと思います。 エンジニアの主戦場は技術私は技術も事業も好きです。でもエンジニアです。 能力を表すのも求められるのも技術です。 まずは頭の中にあるアイデアを実現できる技術力は大前提で、その上で「エンジニアは事業を理解すべきか？」を考えるべきだと思っています。 事業への理解があることは、技術力がないことの免罪符ではありません。 むしろ事業への理解は技術力の一部です。 そもそも良いエンジニアに事業の理解は必要技術の意思決定において、前提や課題や目的の理解は大切です。仕事においては、事業や市場や顧客のドメインの理解がないと意思決定はできません。 エンジニアが事業をできる必要はありませんが、知識として事業を理解する必要はあります。 ちょっと不思議ですが、良いエンジニア

‌ という完全に仮説というか思考実験みたいなものを書いてみます。 ざっくりまとめ ベテランの何気ない情報は世に出にくいという仮設 ベテランは、独自見解など良い感じのもの以外の簡単な技術記事が書けなくなる、書きにくくなる 簡単な記事は経験浅めの人に偏りベテランは簡単な記事を書かない。簡単なものでも書いてくれるベテランは、アウトプット好きに限られる 簡単なものであったとしても世に出してくれれば嬉しいな 前提 経験の浅い人 = 初級者 ベテラン = 中級者以上 とおきかえてもらっても良いかもしれません。 経験の浅い人は簡単なことでも感動できるのでブログを抵抗なく書きやすい 例えば 「Javaのセットアップが出来た！」 「Rubyのセットアップが出来た！」 「このライブラリで良い感じに出来た！」 はじめのうちは一つ一つが嬉しいし一つ一つにハマりがちだったりするので、 感動もありハマりどころもありブ

2024年10月19日開催の「PHP勉強会 in 広島 vol.1」の登壇発表資料です。 https://hiroshimaphp.connpass.com/event/321216/

ゆめみ/虎の穴ラボさんの「勉強法の勉強会」というのが好きで、そちらをベースに社内の強い人たちへのインタビュー（10名程度）をミックスして、みんながどうやって調査とか勉強とかしているのか、まとめてみました。 インタビュの結果、あまり共通項みたいなものがなく、結局勉強に関しても銀の弾丸はなさそうな雰囲気でした。ので、どちらかというといろんな人のいろんな方法を並べる、みたいになっています。いろいろ詰め込もうとしすぎたのでゴチャった感ありますが、誰かの参考になれば幸いです。 前提など

株式会社カケハシは「日本の医療体験を、しなやかに。」というミッションを掲げた、医療系のスタートアップです。現在は薬局向けのSaaSを主軸としたビジネスを行っており、多くのエンジニアがチームを組んで開発に取り組んでいます。その開発チームのひとつ「yabusame」は、特徴的なチーム編成もあって社内外で注目を集めています。 メンバーの椎葉光行（@bufferings）さん、小田中育生（@dora_e_m）さん、荻野淳也（@ogijun）さん、種岡篤志さん、平松拓（@hirataq__）さんは、それぞれが開発チームをリードできる高い技術力やマネジメント能力だけでなく、細やかな対人スキルや広い視座でメンバーの関係性を捉える能力を備えたシニアエンジニアでありながら、同じチームのメンバーとして開発に取り組んでいます。 日本の古式弓馬術である流鏑馬(やぶさめ)から「変化が速い中を駆け抜けて、的確にゴール

月イチでお話させていただいているシリーズ、今月は「年配者と若い人」というテーマでした。タイトルは「My Generation - 年配者がこの先生きのこるには」。先方からは「刺激的なタイトルですね！」とリアクションをいただきました。 スライドはこちら。 またしてもきのこネタなのですが、内容は新作です。アウトプットしたい気持ちと需要がリンクしたので、ほかの機会でも話せたらいいな、と思っています。 サポート記事スライドで内容はけっこう伝わるかとは思うのですが、細かいネタなどのフォローを書いていきます。 タイトル最初は「Don’t trust anyone over XXXty」でした。アメリカのヒッピー文化から出てきた言葉で、若い頃に映画でボブ・ディランが言ったことで広まったとか。書いてるうちにそぐわなくなってきちゃったので変更しました。 「My Generation」はThe Whoの名曲で

はじめに こんにちは。食べログ開発本部 ウェブ開発1部の羽澤です。 マネージャーという立場で働いておりまして、案件をリードしたり、一歩引いてメンバーや案件をサポートしたり、その時々で役割を変えながら日々過ごしております。 その中でいつも頭を悩ませているのが、いかに早く開発を進めるかということです。これは食べログだけでなくどんな組織でも常に考えている、永遠の課題だと思います。 今回は食べログの開発体制を紹介しながら、自分として爆速で進められたと感じている案件を紹介します。「なぜうまく行ったのか」を掘り下げることで見えてきた重要な視点を、「爆速で進める1つのポイント」としてまとめてみました。 プロジェクト体制の紹介 開発の話の前に、前提となる組織の形を紹介します。 私の所属するウェブ開発1部では、マトリクス型の組織を採用しております。 ウェブ開発1部の事例ではありませんが、以下の記事が参考にな

ソフトウェアエンジニアリング界隈の言葉はとても曖昧な言葉に満ち溢れています。「自走」という言葉もそうです。でも、そういう曖昧な言葉の方が使い勝手が良いため、たとえば、ツイッターランドにはそういう曖昧な言葉がバズりまくったり、日々流れてきたりします。そうじゃなくても、「うちの職場のエンジニアには自走力が求められるんだよね」とか「転職するためには自走できる力が大切だ」みたいな言い方、度々聞いたり、むしろ話したりしていませんか？ この記事では「自走できるエンジニア」について自分なりの考えをまとめてみたいと思います。もちろんこれはあまたある解釈の中でも、僕が解釈したものに過ぎません。そういう意味ではさらに「自走」という単語を持ち出して世に混乱を投げつけるだけかもしれません。僕のただのポジショントークかもしれません。 それでよければ、「自分は自走できているのだろうか？」「自分は、うまく部下や同僚を自

CTOが訊く#2 Rails Committer と DeNA 「CTOが訊く」は、DeNA CTO の @nekokak（ねこかく）こと小林 篤が、社内のメンバーに、その人となりや仕事っぷり、そして野望を訊く、というコーナーです。 第2回の対談ゲストは、@kamipo（かみぽ）こと上薗 竜太。 Full-Time Rails Committer としての入社 ▲左から、@kamipo：上薗 竜太、@nekokak：小林 篤 @nekokak 今日は「CTOが訊く」へ、Rails Committer である kamipo さんに来ていただきました。よろしくお願いします。 @kamipo お願いします。 @nekokak この「CTOが訊く」は、DeNA で活躍しているスペシャリティの高いエンジニアの人から色々と話を訊きながら、DeNA でどういう活躍をしているか伺って深堀りをしていく、とい

こんにちは。倉内です。 依然としてコロナウイルス感染症の影響があるとはいえ、ITエンジニアの採用市場、特に経験者の採用においては一部の有名企業などを除き、企業側が人材確保に苦労しているのが現状です。 リモートワークの導入で場所を問わず働けるようになり、柔軟な対応をしている企業とそうでない企業、つまり「選ばれる企業」と「選ばれない企業」がハッキリしてきたと言ってもよいでしょう。 そのため企業としては、エンジニアの経験者採用が難しい以上、今いるエンジニアにできるだけ辞めないでもらいたいという気持ちが強いと思います。 もちろんエンジニアは転職してキャリアアップや年収アップを目指す人が多い職業であり、本人の将来のキャリアビジョンもあるので絶対に辞めさせないというのは無理な話です。ただし、スキルやポジションのミスマッチ、組織や事業のやり方に失望などの理由で辞めてしまうのは防ぐ必要があります。 そこで

2020 年は一般的なソフトウェアエンジニア。というよりは少し経路が違う仕事を主にやっていたので、良い機会なのでまとめようと思います。 やったこととしては多岐に渡って価値を発揮できたかなと思う一方、心情的にはしっくりこない一年でした。 要約 業務内容だけ見たい人は実際の業務についてへ 採用ブランディング/DX改善/コミュニティ活動などを行うチームを設立し、回していた それと並行して、採用活動や選考フローの改善、LINE DEV DAY 2020 Frontend の管理を行った 来年はまた事業側の仕事をやっていくつもりである 出来事 先に今年は大きな出来事が2つあったので、その変遷を紹介します。 Front-End Advocates TF を立ち上げた 今年の 3 月に Front-End Advocates TF という Task Force(以下 TF) を社内で設立しており、それの

17歳にして世界で初めてiPhoneのSIMロックを解除し、その後も脱獄(ジェイルブレイク)界隈で名を上げ、プレイステーション3を誰よりも早くハッキングしてソニーに訴えられるなど、天才プログラマーにして伝説的なハッカーとして知られるジョージ・ホッツ氏が、なんと1カ月で市販車を改造し、自動運転車に仕立て上げました。世界中の自動車メーカーやIT企業がこぞって参戦している自動運転車の開発競争に天才がたった一人で殴り込みをかけるとこうなるようです。 George Hotz Is Taking on Tesla by Himself http://www.bloomberg.com/features/2015-george-hotz-self-driving-car/ ホッツ氏が開発した自動運転車が実際に自動運転する様子は以下のムービーで確認できます。 Meet the 26-Year-Old Ha

2018年4月から務めた Quipper Limited の Vice President of Engineering を、2020年3月末日付で退任*1した。 なぜやめるのか 一言でいうと、 VPoE として担っていたミッションを完遂したため。 二年前に VPoE 就任を打診されたとき、自分が所属していた開発組織の課題は明白だった。人が辞める。定着しない。人が増えない（むしろ減る）ので現場の負荷が上がる。ムードも悪くなる。お世辞にもおすすめできる職場とはいえなかった。 そこで、「二年で開発組織を立て直す」をミッションに掲げ、上司と約束した。 結果、二年間でエンジニア組織は 25 名から 54 名へと倍増。かつ、ミスマッチを防ぐ採用方針を徹底したことで離職者を低く抑えることに成功。開発組織を安定化させた。 2017年3月 2018年3月 2019年3月 2020年3月 エンジニアの人数

（この記事はVPoE handbookの目次＆サマリパートです） 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 （この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。） VPoE handbookを書こうと思った理由まずはなぜ書こうと思った？の問題意識から。 この記事にあるように、三

こんにちは。今年の梅雨は雨が少ないといいますが、実はあれだいたい僕のせいです。ホスティング事業部チーフテクニカルリード(CTL)の pyama86 です。 今日はペパボのエンジニア評価制度のアップデート後、初の職位立候補期間が終了したので、改めてペパボのエンジニア評価制度がどういったもので、いかにして我々のエンジニア文化を醸成する根源となっているかを紹介したいと思います。 まずペパボのエンジニア評価制度は下記の図のように、CTOを頂点に、チーフエンジニア、シニア・プリンシパル、プリンシパル、シニアエンジニアの職位から成っており、CTO、チーフエンジニアを除く職位はすべてエンジニア自身の 立候補 をもとに、上位職種の面談を経た一次評価の後、経営会議を持って決定されます。 現在の構成としてはCTO1名、チーフ1名、シニア・プリンシパル1名、プリンシパル5名、シニアエンジニア13名という構成です

僕はよく手が早いと言われるのだけど、そんな中で気をつけてることを整理してみた。大きくは下記の３点につきる。 複数タスクは抱えるが、並列で進めないイベント駆動で動くことを原則として、探索行動をしない暫定対応ではなく、最初から必殺する複数タスクは抱えるが並列で進めない僕はだいたい平時2〜4くらいのタスクを抱えている。しかし、だいたい1個〜2個に集中して片付けて、次に手を付けるっていう感じで進めている。 この2つをさばくときは、例えば1つ目のタスクのコードを書ききってしまって、レビュー待ちとかの問に、2つ目のタスクの設計を考えたり、あれこれ進めて、レビューコメントが付いたらまた1つ目に戻ってぐわーってやる感じ。もう少し小さいスキマ時間、例えばchefのapplyとかコンパイルだとSlackで適当に人に絡んでわけのわからないことを言って去るという感じのことをしている。 ともあれ、これの利点は基本的

はじめに この記事は、エンジニアがどのように技術を学べば良いのかということについて、おもに西尾泰和氏の書籍・記事で主張されている内容を元に、特定の問題を対象として自分の考えを加えて考察したものです。特定の問題としては、以下の3つを設定しています。 何を学べば良いのか分からない 技術書を読んでもすぐ忘れる 学習する時間がない もちろん、学ぶ上で考えるべきことは上記の問題にとどまりませんが、ここでは、比較的身近で耳にすることが多いと感じるものを問題として設定します。 定義 この記事ではスコープを特定の範囲に限定しているため、一般的な用語について、一部を以下のようにローカル定義しています。そのため、一般的な用語そのままの意味においては、この記事の内容はコンテキストを維持できないことがある点に注意してください。 エンジニア Web 系企業に勤めており、主にプログラミングをはじめとしたコンピュータサ

エンジニアとして技術ブログをしたためるそーだいさんは、現在の仕事を「自分しかできないこと」と感じているそうです。誰もが追い求める、でもどこにあるのかわからない「自分しかできないこと」の見つけ方を綴ってもらいました。 はじめまして。株式会社オミカレという会社で副社長 / CTO（Chief Technical Officer）を務めるそーだいと申します。 と、肩書だけ並べるとなんかすごそうですが、実はそんなことはありません。「副社長」も「CTO」も役割のひとつに過ぎず、「マネージャー」や「リーダー」、あるいは「新入社員」のように、誰もが担うなにかしらの責任と本質は何も変わらないでしょう。 さて、私がここに至るまでにはオミカレを辞めたり戻ったり、といった紆余曲折があったのですが、今の役割を担ったのには「これは、自分“しか”できない仕事だ」という予感があったからです。誰にも定義することなどできな