開発生産性の現在地点～エンジニアリングが及ぼす多角的視点 / Current status of development productivity2024/2/15 Developers Summit 2024 登壇資料 https://event.shoeisha.jp/devsumi/20240215
クックパッドを退職しました - 昼メシ物語
2024年1月末まで在籍していますが昨年12月に業務は終えていて、いまは有休消化期間中です。2010年から約14年間勤めてきた、自分の生き様そのものとも言えるクックパッドを離れるのには、表現しきれないほど大きく、複雑な思いがあります。 僕がこの14年間でやってきたことを振り返ってみます。 入社 クックパッドに入社した時は新卒3年目相当で、26歳でした。もともと料理と Ruby が好きで、当時まだ珍しかった Ruby on Rails でサービス開発をしているらしいという点や、当時からネットウォッチしていた @ryo_katsuma さんが所属していること、直属の上司の井原さんが転職したことが決め手になり、体当たりで飛び込みました。当時の僕はほとんど実績もなく、入れてもらえるかギリギリのところだったと思いますが、おそらく井原さんが頑張って交渉してくれたのだと思います。本当に感謝しています。こ
第３回 最少人数のチームで | なにもできないからプロデューサーになった | ほぼ日刊イトイ新聞
『マリオ』や『ゼルダ』や『ピクミン』をつくり、 世界中で尊敬されているゲームクリエイター‥‥ と書くと、正しいんですけど、なんだかちょっと 宮本茂さんのことを言い切れてない気がします。 クリエイティブでアイディアにあふれているけど、 どこかでふつうの私たちと地続きな人、 任天堂の宮本茂さんが久々にほぼ日に登場です！ 糸井重里とはずいぶん古くからおつき合いがあり、 いまもときどき会って話す関係なんですが、 人前で話すことはほとんどないんです。 今回は「ほぼ日の學校」の収録も兼ねて、 ほぼ日の乗組員の前でたっぷり話してもらいました。 ゲームづくりから組織論、貴重な思い出話まで、 最後までずっとおもしろい対談でした。 え？ 宮本さんがつけた仮のタイトルが、 『なにもできないからプロデューサーになった』？ そんなわけないでしょう、宮本さん！ 糸井 宮本さんが入社したばかりのころは、 ある意味、任天
開発と保守・運用の分業は個別ミッションの遂行手段にコンフリクトを生じさせやすい - mtx2s’s blog
ソフトウェアエンジニアリング組織の主たる業務機能は、開発、保守、そして運用の3つだろう。これらをどう組織化するか。それが、生産性にもビジネスにも影響する。私は多くのケースにおいて、この3つの機能をすべて持つ、少人数のプロダクトチームをいくつか組織化する。その理由は、過去の記事で何度か書いたように、開発でのアウトプットに対するフィードバックサイクルをまわせるようになるからだ。それが、技術・サービスの両面を向上させる。 しかし本稿のケースは違う。ここで取り上げるのは、保守・運用が、開発とは分離された構造を持つ組織だ。この体制における課題を明らかにし、そのうえで解決策を探ってみたい。 事象は開発と保守・運用の分離が上手く機能していないこと 問題は開発が保守・運用を阻害すること 課題は個別ミッション遂行におけるコンフリクトを解消すること 対策は共通ミッションに立ち戻ること 結論は両チームをあえて密
なぜ雑談が重要か - stmn tech blog
これはなに？ こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 コミュニケーションには会議体やテキストベースなど様々な手段があります。 その中で雑談がなぜ重要であるかについて、私の考えを記したものです。 大事な前提 〜目的と手段の関係〜 人々の活動には目的があります。そして目的を満たすための手段を追い求めています（ここでいう手段とはシステムであったり情報であったり、「目的の役に立つもの」と考えてください）。 目的と手段の関係性を次の図で表現します。目的と手段それぞれの円の重なりが大きいほど、目的に対して相応しい手段である、ということをここでは表します。 この図を使った例を出します。 今の時期、だんだん暑くなってきましたね。「暑さを解消したい」という目的に対して、「扇風機を点ける」「エアコンを点ける」「かき氷を食べる」「南極に送り込む」
ソフトウェア開発上の問題や課題をビジネスリーダーや経営者らの関心事とするために - mtx2s’s blog
ビジネスリーダーをはじめ、ソフトウェアプロジェクトの関係者にとって、ソフトウェア開発上の関心事は、開発の進捗とシステムトラブルだ。ソフトウェアの内部品質や開発プロセス上の問題や課題なんて、開発者以外に興味を示す人などほとんどいない。だから、関係者ばかりか開発者自身も、開発の進捗とシステムトラブルにばかり注意を向ける。 そのような状況に、一部の優秀な開発者は我慢ならない。憂いている。「このままではまずい、積み上がった問題に取り組むために時間が欲しい」「まとまった時間でなくても、継続的に取り組むための少しの割り当てでも構わない」と。そんな願いも虚しく、使える時間はすべて、担当する開発を進捗させることにのみ費やすことを強いられる。 私たちエンジニアリングマネージャーやテックリードは、このような状況を見て見ぬふりをしていないだろうか。開発の進捗やシステムトラブル以外にも注意を向けるべき対象がある。
プロダクトマネージャーが意識したい8つのスキルとPM組織の編成｜ぶんた｜大枝史典
この記事は仕事の幅が広いPMにとって、よく分かりにくい大事なスキルをハードとソフトにカテゴライズし、個人としてまたは組織としての強みや弱みを分かりやすくするために書いてみました。 （こんな方におすすめの記事） ・PMとしてどういうスキルが必要か、また伸ばせばいいのかわからない ・プロダクト組織をどう編成していったらいいかわからない ・PMの採用基準が分からない どうも、ぶんたです。（@bunbuno0） 音声プラットフォームのプロダクトを作っているVoicyでPMチームのマネジメントとプロダクトマネージャーをやっています。 https://voicy.jp/Voicyでは毎週誰かがnoteを公開しているので、是非こちらもチェックしてみてください！ 今回は自分自身がPMであり、またPMメンバーのキャリアや組織について考えることも多く、PMがどうあるべきかというのは悩ましいなあと思っていたりす
半年でテック組織が10倍に成長、VPoEの役割とEMとの違い｜MIDAS Technology Review
背景コロナ禍を契機として、様々な企業でDX（Digital Transformation）の推進が求められています。そのため、エンジニアの需要がますます増加傾向にあり、それに伴って重要性が高まっているのが「エンジニア組織作り」です。近年では、多くの企業でこの課題を解決していくためにVPoE（Vice President of Engineering）を設置しています。 私は、これまでにスタートアップ企業における10名程度のチームのマネージャーや、大企業におけるテックリード兼チームリーダーとして5年ほどEM（Engineering Manager）を経験してきました。そして、現在はVPoEとしてエンジニア組織作りに取り組んでいます。本記事では、これまでの経験を元に、VPoEの役割についてEMやCTO（Chief Technology Officer）との違いをお話しします。 荒井 勇輔（@a
(新米)エンジニアリングマネージャーのしごと #RSGT2023
Regional Scrum Gathering Tokyo2023の登壇資料です。 エンジニアリングマネージャーのしごと https://www.amazon.co.jp/dp/4873119944 エラスティックリーダーシップ https://www.amazon.co.jp/dp/4873118026/ HIGH OUTPUT MANAGEMENT https://www.amazon.co.jp/dp/B01MU055XH/ 成人発達理論による能力の成長 ダイナミックスキル理論の実践的活用法 https://www.amazon.co.jp/dp/B0739Q42P5/ マネジメント3.0 https://www.amazon.co.jp/dp/B0B8GCPWP4/
プロダクト開発チームの分断に立ち向かう - yigarashiのブログ
先日のRSGT2023で以下の発表がありました。「自分がそれほどプロダクト開発に興味がないことに気づく」は自分自身にも心当たりがありますし、プロダクト開発チームのリアルを言語化した発表だと思いました。この発表では、そうした言語化を受けてどうするのかについては深く触れられておらず、回答は聴衆に委ねられていることから、さらに議論を広げてみようと思います。 実際問題、真に興味を持つのは大変 現代のプロダクトマネジメントは、ひとつの深遠な専門領域になっていると思います。「本が1冊書ける」なんてレベルではありません。何百冊、何千冊と書ける世界です。そうした専門知識を組み合わせ、市場とユーザーとプロダクトを徹底的に分析し、データに基づいて仮説検証を繰り返し、それを自分のプロダクトに接続する方法を捻り出して、ようやく少し尤もらしい方向に近づきます。とても過酷な領域です。 ここにエンジニアが越境して興味を
「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023
4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という状況から、おさらばしましょう。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/proposal/17655 発表者 https://twitter.com/_N_A_ https://note.com/mryy
今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間
株式会社FOLIO にてエンジニアリングマネージャーをやっています．FOLIO では この1年間，プロダクト開発を円滑に進めるための組織を目指し，様々な試行錯誤をしてきました．その中でも，適切なチーム・グループの境界設定やミッションに基づいた組織の構造化は現在進行系で大きなトピックの一つです． Engineering Manager は Engineer のマネジメントではなく Engineering のマネジメントだ，という指摘が今回の Advent Calendar でもありましたが，エンジニアリング組織の持てるポテンシャルを十二分に引き出せるかどうかを左右する変数のひとつが「組織のカタチ」だと思います。 本稿は，10月のあるタイミングで社内に向けた啓蒙活動の際に書き出した『組織づくりを考える上で知っておく必要のある概念たち』という wiki の内容を素にしています．私が今の仕事のコン
横断型テックリードという働き方 - 文字っぽいの。
みなさんこんにちは。FromAtomです。 自分は今『モバイルアプリ分野テックリード』という肩書で仕事をしています。世の中のテックリードの皆様におかれましては「"分野" テックリードって？」「横断型テックリードって？」という感じかと思います。そんなテックリード業を2019年末から2年ちょっとやってきたので、この記事では自分がやっていることの説明と、分野テックリードが置かれた経緯を紹介します。 なぜモバイルアプリ分野テックリードが必要になったのか 弊社では、全部で12つのiOS・Androidアプリを開発しています。これだけあると、各アプリのプロダクトオーナー毎に意思決定の精度にばらつきが出てきます。例えば、Appleのレビューリジェクトに対する姿勢が異なると「まぁ適当にごまかして通せば勝ちや！」というチームと「BANリスクもあるからちゃんとやるか。面倒だけど。」というチームが生まれる可能性
エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita
スクワッド体制における留意点として、「Spotifyは "Spotifyモデル "を使っていない [3]」で以下のように述べられているように、単に方法論を真似るのではく、自分の組織と向き合い、学習して、進化し続けることが大切であると思います。READYFORにおいても日々、組織体制について議論し、改善を進めています。 ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。 あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。 1-2. READYFORのスクワッド体制 READYFORの場合、どのようなスクワッド体制を敷いているか？ ひと
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
Engineering Managerの役割を無くしてみた - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2021 の22日目の記事です。 アカツキでは数年前よりEngineering Managerの役割をおいているのですが、この度、Engineering Manager(EM)の役割を公式に無くしました。私の個人的な活動で、EMによるEMのためのPodcastをやっているし*1、社内でもそういう活動を知っている人がいるし、世間からするとお前がそれを言うのか〜と言われそうなのでなかなか勇気のいる決断でした。ただ、今後の会社の方針を考えたときに、今見直すタイミングなんじゃないかと思い、思い切って無くしてみました。 本記事ではなぜ無くすことにしたのか、これからどうしていくのかを書いていきます。 EMのやることが消滅したわけではない アカツキのEMはエンジニアのマネジメントと、プロジ
1on1の効果を高める3つの技法 - NTT Communications Engineers' Blog
この記事は NTTコミュニケーションズ Advent Calendar 2021 の11日目の記事です。 はじめに ヒューマンリソース部の岩瀬(@iwashi86)です。普段は、全社の人材開発・組織開発を推進しており、業務の1つとして、"1on1" の全社展開をしております。 本記事では、その"1on1"の効果を高める具体的な技法を紹介いたします。アドベントカレンダーということで、ゆるめに書いてみます。*1 NTT Com における1on1の目的とは？ 技法を説明する前に、1on1の目的について説明します。技法はあくまで目的達成に向けたHowでしかないためです。 1on1の目的とは何でしょうか？1on1それ自体には、複数の目的が挙げられます。代表的なところで言えば次のようなものでしょうか。 信頼関係の構築 離職率の低下 メンバー育成 目標達成へ向けた支援 etc... どれが正解というもの
ペア制度を導入して、開発チーム内の相談しやすさ向上・知見展開・透明性向上を狙う - $shibayu36->blog;
最近プロジェクトマネジャーを担当していた仕事で、開発チーム内の相談しやすさ向上・知見展開・透明性向上・WIPタスク数減少を狙ってペア制度というのを導入した。今回は導入した背景、導入した仕組み、そしてその振り返りについてブログに書いておきたい。 導入した背景 ちょっとした相談のしづらさ 知見展開のしづらさ タスク状況の透明性の不足 WIPなタスクが多く、プロジェクトマネジメントが複雑 ペア制度を導入する ペア制度の振り返り ペア制度を振り返っての点数評価 導入して良かったこと 導入して困ったことや、改善すべきポイント 一人当たりの短期的な開発効率は下がったか？ まとめ 導入した背景 最近はエンジニア6~7人程度のフロントエンドフレームワーク置き換えプロジェクトのプロジェクトマネジャーをやっていた。ペア制度を導入する前は、大体1~6ヶ月程度かかる粒度のタスクを1人にアサインし、人数と同じだけの
評価の満足度を劇的にあげた秘訣。Continuous Feedbackのすすめ | メルカリエンジニアリング
誰向けの記事？ EM（Engineering Manager）の方に向けた記事です。 ただ、一般的な評価者全般にあてはまる内容を書いているので、評価を行う方なら誰でも参考にできると思います。 評価をする側ではないけど、どんな気持ちで自分のマネージャーが評価しているのか知りたい！といったエンジニアの方にも楽しんでいただけるかもしれません。 要約 メルカリエンジニア組織で、評価の負荷を削減しつつ、品質をあげるために、「Continuous Feedback」という仕組みを導入しました。 Continuous Feedbackは、通常よりも高い頻度でフィードバックを行うことで、負荷分散や、フィードバックサイクルの高速化などをはかる手法です。 導入した結果、評価に対する満足度や、評価を自身の成長に使えてると感じるようになったメンバーがとても増えました。現在では多くのEMの方が、評価に利用してくれて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
事業をスケールさせるエンジニアリング〜技術のコモディティ化にエンジニアは敗北する〜 - DMM inside
