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」も役割のひとつに過ぎず、「マネージャー」や「リーダー」、あるいは「新入社員」のように、誰もが担うなにかしらの責任と本質は何も変わらないでしょう。 さて、私がここに至るまでにはオミカレを辞めたり戻ったり、といった紆余曲折があったのですが、今の役割を担ったのには「これは、自分“しか”できない仕事だ」という予感があったからです。誰にも定義することなどできな

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? @rana_kualuさんの2018年の最先端バックエンドエンジニアになろうという翻訳記事がとても興味深かったのですが、記事内で提示されているロードマップに関して微妙に違和感を感じる部分もありましたので、 記事に記載されているスキルは現場でどの程度必要なのか 記事に記載されていないが現場において重要なスキルは何か といった辺りを、自分なりの意見を交えてちょっと書き出してみました。 自分をエンジニアとして最先端だとは全く思っていないのですが、最近のバックエンドのトレンドに一応多少なりともきちんとキャッチアップしてるかなとは思うので、若い方

ロールプレイングゲーム著者: 関 将俊 ここでは私が実践している、ちょっと良いプログラマになるためのコツを紹介します。まるで「理想のプログラマ」のように仕事をするための簡単なアイデアです。チームでプログラミングするお仕事に就かれているみなさんが、このアイデアで昨日よりも気分よく過ごせるようになれば幸いです。 多くの達人が「理想のプログラマ」とはどういうものか、よいプログラマのあるべき姿、立ち振る舞いを説いてきました。おそらく、みなさんも達人たちが理想のプログラマについて書いた文章を読まれたのではないでしょうか。そして達人たちの示す理想のプログラマ像を想像してそんな人物になろうとしましたよね。みなさんは実際にそうなれたでしょうか。その振る舞いを実践するのはちょっと難しかったりしませんでしたか。 「理想のプログラマ」といった「理想の何か」になるために、本来の自分を変えて別な自分になる必要があり