ソフトウェアエンジニアは、どのように事業に貢献すべきか？ 宿泊施設やレストランの予約サービスを提供する株式会社一休で執行役員CTOを務める伊藤直也さんは、2016年に入社しておよそ2年間、心の奥に抱えた悩みを解消できないまま仕事をしてきました。 伊藤さんは、2000年代から複数のWeb系テックカンパニーで技術部門のリーダーとして活躍し、現在でも利用される個人向けWebサービスのローンチをいくつか手掛けています。一休には入社以前からフリーランスで技術顧問を務めており、会社がヤフーグループ（当時）に入って経営陣が一新されるタイミングで、代表取締役CEOとなった榊淳さんの要請を受けて入社しました。 当時は全て.NETだったというサービス基盤の刷新や技術的負債の解消、開発組織の整備といったエンジニアリングにおいて重要な改善を進めてきましたが、あるとき自身が「事業に貢献していない」ことを明確に意識す

2024年5月より株式会社はてなに転職し、エンジニアリングマネージャーを務める粕谷大輔（通称：だいくしー）さん。これまで複数の開発組織でソフトウェア開発に携わってきた粕谷さんは、2014年11月から2021年4月まではてなで働き、2021年5月にChatwork株式会社に転職。そして2024年5月より再びはてなで働き始めるというキャリアを歩んでいます。 いわゆる「アルムナイ採用」ではてなに戻った粕谷さんですが、なぜこのような働き方を選んだのでしょうか。そして、はてなで実現したいことやキャリアについての考え方とは？ 旧・はてな時代の経験は、マネージャーとしての原点 ── 粕谷さんが過去にはてなに所属されていた頃、「Findy Engineer Lab」に「マネジメントも『技術』のひとつ。技術志向だったエンジニアが、開発チームのディレクターに挑戦するわけ」というコラムを寄稿されました。この頃か

渡米 メールでやってきた唐突な仕事のオファーに応えて、渡米を決意した。どうしてそう決めたのかと言われれば、口うるさい母親が昔からアメリカに行けアメリカに行けと煩かった事だとか、給料がよかったからとか、ソフトウェア技術者にとっていかにシリコンバレーが特別であるかとか、それらしい理由もないではない。でも、実際には入念な検討は何もなかった。面白そうだからやってみようと思っただけだ。それで良かったと思っている。若さというのは、無知で無謀なものだ。でも、そのおかげで人生が思わず開けたりするのが、面白いところだ。 その決断の結果、僕の人生は一変した。これを機に、付き合っていた女性と結婚する事に決めた。2001.1.1という日付も縁起が良さそうではないか。誰もいない区役所に婚姻届を出し、近所のコンビニで肉まんを買って食べて結婚を祝い、数日後の飛行機に乗って、冬とは思えぬまばゆい陽光につつまれたサンフラン

Rubyをはじめとする「動的型付け」のプログラミング言語は、ソースコード中に型に関する記述が陽に出てこないことが特徴で、プログラムの実行前に（静的に）型検査をすることはありません。しかし、このようなプログラミング言語においても、大規模な開発における品質の向上や開発体験の改善、実行の高速化のために、静的な解析を活用しようという試みは多くなされてきました。この記事では、動的型付けの言語のための型検査の歴史を簡単に振り返って、現在私が開発しているRuby向けの型検査器Steepとその基盤となっている型記述言語RBSについて説明し、今後の展望を議論します。 著者：松本宗太郎さん（@soutaro） Rubyコミッター。大学院でRubyプログラムの型検査の研究に取り組み、修了後はスタートアップでWebアプリケーションの開発に従事。2017年から型検査ツールSteepの開発を始め、2019年からはRu

ハイクラスエンジニア向け転職・求人サイト。自社開発のWeb企業の求人多数！GitHub登録をすると、IT/Web企業とマッチングします。ユーザーサクセス (キャリア)面談も実施。

ソフトウェア開発に携わるエンジニアがキャリアを積むとマネージャーへの転身を余儀なくされた時代もありましたが、今ではIC（Individual Contributor）やスタッフエンジニアという働き方も周知となり、開発組織そのものをマネジメント対象とするEM（エンジニアリングマネージャー）を置く企業も増えてきました。 そんな状況を反映してか、株式会社カケハシの椎葉光行（@bufferings）さん、小田中育生（@dora_e_m）さん、荻野淳也（@ogijun）さんの3人は、それぞれチームをリードできるシニアなエンジニアでありながら、現在は同じチームのメンバーとしてともに開発に取り組んでいます。 新たに採用するハイキャリアなエンジニアを既存の開発組織にどうフィットさせるかに課題感を持つ企業もありますが、このように複数のシニアを集めたスーパーチームで開発にあたることにどういった意義があるのでし

YAPCは「Yet Another Perl Conference」の略称であり、Perlを軸としたITに関わる全ての人のためのカンファレンスです。このカンファレンスは、Perlのみならず参加者たちが好きな技術の話をして交流することを目的としており、毎年数多くの方々が参加する一大イベントとなっています。 2024年2月9日・10日に広島県で開催されたYAPC::Hiroshima 2024は「what you like」がテーマ。職種やロール、プログラミング言語、技術要素など、各々のさまざまな「お好み」を語る場となりました。YAPC::Hiroshima 2024の運営に携わったメンバーたちは、どのような思いで活動をしたのでしょうか。 運営チームのリーダーを務めたkobakenさんと、長きにわたり運営に参加し今回は主に広報業務を担当したpapixさん、そして開催地である広島県在住でコアスタ

皆様こんにちは。QAエンジニアのブロッコリーこと風間裕也（@nihonbuson）と申します。私は本業で株式会社10XのQAエンジニアとして勤務する一方、副業としてB-Testingを開業し、さまざまな会社でQAに関する相談に乗ったり、登壇や執筆活動を行っています。 また社外活動として、WACATE（ソフトウェアテストの合宿型ワークショップ形式勉強会）の実行委員長や、ソフトウェアテスト技術振興協会（ASTER）の主催するJaSST Review（ソフトウェアレビューのシンポジウム）の実行委員長を務めています。 本記事では、私がどうしてQAエンジニアというキャリアを歩んでいるのか、そして品質保証（QA、Quality Assurance）という分野でどのように開発チームと協調しながら開発してきたのかをお話しします。 筆者近影 学術と企業のギャップに驚いてテストの浸透に動く テスト技術に磨きを

インフラ・SRE領域の人材不足が叫ばれるなか、技術情報の発信、登壇、教育活動、OSS活動に奮闘しているadachinさん。大規模なオンプレミスからクラウドまでを網羅するインフラ担当からキャリアをスタートし、現在はSREとして本業に限らず、個人事業主としても活動している。 「10年前と比べると、インフラに関連した技術ブログや技術書も分かりやすいものが増えてきました」 「僕自身、インフラエンジニアになった当時は情報が少なくて困りました。技術的な問題でつまづいたとき、すぐさま解決してくれるようなブログもなかった」 だからこそ、現場レベルでの経験をもとに技術の検証をしながら、一目で問題解決の糸口を見つけられるブログを発信し続けてきた。これまでに個人ブログで500記事以上、備忘録サイトも含めると1,000記事を超えており、月間数万PVにもなるという。イベントで「インフラ周りで困ったときに参考にしてい

2014年5月から書き始めた連載「LXCで学ぶコンテナ入門」は55回（2024年1月時点）を数え、もうすぐ10周年。近年は、コツコツと書き溜めた、Linuxコンテナに関する記事を同人誌として刊行する活動も。 今の仕事はセキュリティエンジニア。なので、ご本人は「コンテナ趣味人って感じです」と笑う。 いろいろ興味があったことの1つとして、Linuxコンテナを調べ始めたのが始まり。 「当時は、調べてもなかなか情報がないんですよ。日本語ではまったくゼロですし、海外でもまとまったやつは見つけられなくて。だから、いろんなメーリングリストのちょっとした発言とか、マニュアルの記述とかをいろいろかき集めて、試してみたことをメモ代わりにブログに残してたんです」 「その後、勉強会とかで会う人に『ブログ、見てました』と結構、言ってもらったりして。何でもないメモでも、意外に見てくれる人がいるんやなって思いました」

「家の近くにあった工業団地で、工場の内部を見学させてもらったときに衝撃を受けました」 「製品を効率良く生産するための、計算し尽くされた工場の設計に大きな魅力を感じたんです」 あの日、工場で目を輝かせていた少年は、今はコードと向き合って、この日本でモノづくりを支えている。 現在、物流業界のDXに挑むベンチャー企業で、ソフトウェアエンジニアとして「2024年問題」を始めとした物流業界の課題解決に正面から向き合っている。子どもの頃の原体験からモノづくりの世界に憧れ、高専で機械工学を学んでいた。 「たとえば、作業員が歩くルートを１秒でも短くするような工夫。時間をわずかに短縮するだけで、その積み重ねがどれほど大きな効果につながるか。そんな工場の設計に魅了されたんです」 ではなぜ、機械工学の道からソフトウェアエンジニアへと転向を決めたのか。 「エンジニアだった父親が小学校の頃にパソコンを買い与えてくれ

製造業サプライチェーンの変革に挑むキャディ株式会社。2024年1月より、同社の図面データ活用クラウド「CADDi DRAWER」の開発・運用を担う​​DRAWER事業本部のVP of Engineering（VPoE）として、元Sansan株式会社 CTOの藤倉成太さんが就任しました。 藤倉さんは前職において、営業DXサービス「Sansan」の開発に携わった後、開発部長やプロダクトマネージャー、CTO、海外拠点であるSansan Global Development Center, Inc.の立ち上げなど、要職を務めてきました。 「CTO経験者」という経歴を見ると、読者のみなさんは「藤倉さんはなんでもそつなくこなせるタイプで、マネジメントも最初から上手にできたのではないか」と思われるかもしれません。しかし、藤倉さんは「自分は決して器用なタイプではありません。たくさんの失敗を重ねながら、キャ

ソフトウェアエンジニアがキャリアについて考えるときに、自分の好きな技術や得意なスキル、あるいは興味ある事業ドメインをもとに次を選択することがあります。とはいえ専念したい技術領域がすぐに見つかるというものでもないでしょう。得意分野が見つかるまで自分を成長させることも大切です。 柴﨑優季（@shibayu36）さんは開発者として12年間を、toCのコンテンツプラットフォームに始まり、toBのSaaS事業、現職のメタバースプラットフォームと、転職ごとに異なる事業ドメインを選択しています。担当する技術領域や職能も幅広く、選り好みすることなく経験を積んできました。 ただ次々とチームを移り変わるだけでは、次につながる知識を得ることも難しいでしょう。技術や職能にはこだわらない代わりに、一貫した軸をもって開発にあたってきた柴﨑さんに、新しい環境での仕事で意識することや、どのように技術を磨いてきたか、そして

ソリューションアーキテクト（SA）とは、クライアントとともに企業の事業やシステムの課題と向き合い、システムのアーキテクチャの改善案を提案して課題解決をする職業。クライアント企業のCTOやテックリードとディスカッションする機会も多いため、システムについての豊富な知識だけではなく、ビジネスや開発組織の今後を考慮した設計能力や論理的な説明能力なども求められます。 こう書くと、「学生時代からコンピューターサイエンスを専門的に学んでいた人でなければ、ソリューションアーキテクトとして活躍できないのでは」と思われるかもしれません。しかし、アマゾン ウェブ サービス ジャパン合同会社（以下、AWS）のソリューションアーキテクトとしてスタートアップを支援する塚田朗弘さん*は、大学時代には文学部国文学科に所属していました。そして、エンジニアリングの勉強を本格的に始めたのも、20代半ばになってからだったのです。

▲ YAPC::Asia Tokyo 2013でベストトーク賞1位を獲得し表彰される和田裕介さん（写真提供：Japan Perl Association） エッジコンピューティング環境に適したWebフレームワークとして注目を集める「Hono」の開発者として知られる和田裕介（@yusukebe）さん。大学院卒業後に就職の道を選ばず起業し、その後は17年にわたりフリーランスのエンジニアとして活躍してきましたが、2023年4月に初めて就職しました。 世界最大級のCDN（Contents Delivery Network）プラットフォームを提供するCloudflareが「Hono」に注目し、和田さんをスカウトしたことがきっかけです。Cloudflareに入社した和田さんはサーバレス環境「Cloudflare Workers」上での開発者体験（Developer Experience）の向上を職務と

こんにちは。澤田雅彦（@masahiko_sawada）と申します。オープンソースのデータベース PostgreSQLのコミッタをしています。2022年からは、Amazon Web Services Japan（以下、AWSジャパン）でソフトウェアエンジニアとしてPostgreSQLの開発をしています。 2013年に業務の一部として始めたPostgreSQLの開発はかれこれ10年以上続き、今ではフルタイムの業務となっています。「わたしの選択」というテーマで寄稿の機会をいただいたので、本記事では、私がどのようにPostgreSQL開発者のキャリアを選択したのか、なぜ10年以上もの長い間PostgreSQLの開発を続けているのか、などを紹介したいと思います。 データベースを始めるきっかけ 大学生の時は元々教員志望だったのですが、講義で初めてプログラミングを学び、その面白さからエンジニアを目指す

ハイクラスエンジニア向け転職・求人サイト。自社開発のWeb企業の求人多数！GitHub登録をすると、IT/Web企業とマッチングします。ユーザーサクセス (キャリア)面談も実施。

エンジニアや開発組織は積極的に情報発信をするほうがいい――。 そうした言説がよく語られているように、“情報発信”には数多くの利点があります。自分たちの解決した事業課題や書いたソースコード、プロジェクトのなかで得た学びなどをアウトプットすると、その情報を受け取った人たちの業務改善に役立ちます。複数のエンジニアが知見を共有することで、コミュニティ全体のスキルの底上げになります。ひいては、その情報発信がエンジニアのセルフブランディングや企業の技術ブランディング・エンジニア採用の成功につながるのです。 では、どうすれば効果的な情報発信を実現できるのでしょうか。その知見について、LINEヤフー株式会社でDeveloper Relationsの業務に携わる佐藤 祥子さんにインタビュー。佐藤さんがDeveloper Relationsの仕事を始めた経緯や情報発信のノウハウなどについて伺いました。 人には

みなさん、こんにちは！あらたま（@ar_tama）です。 ソフトウェアエンジニアとしてキャリアをスタートさせ、事業会社のテックリードや、レイターステージのベンチャー企業でのCTOを経て、現在は株式会社LayerXのバクラク事業部でEM（エンジニアリングマネージャー）をしています。 自分の軸足はソフトウェアエンジニアリングにあると思っていますが、エンジニアリングスキルをいったん脇に置き、事業そのものの価値を押し上げる目的で、違う領域に注力していた時期も少なからずあります。裏を返せば「エンジニアリングで突き抜けることを選ばなかった」ことの負い目と独り相撲的に戦ってきました。何なら今もその葛藤の只中にいる自覚があります。 葛藤は一般にはさらけ出すのも躊躇するような感情ではありますが、いかに研鑽を積もうともそういった感情はなくならず、隣の芝はずっと青くあり続けるのではないでしょうか。ならば葛藤によ