マルチプロダクトでスケールするプロダクト開発組織をつくるために
いかにして GraphQL を組織に導入するか (新規開発編) / how we introduce GraphQL on scratch development
GraphQL Tokyo #18 Lightning Talks https://www.meetup.com/ja-JP/graphql-tokyo/events/286913987/ Links: [GraphQL を活用したスキーマ駆動開発の実践](https://speakerdeck.com/qsona/schema-driven-development-with-graphql) [GraphQL を利用したアーキテクチャの勘所 / Architecture practices with GraphQL - Speaker Deck](https://speakerdeck.com/qsona/architecture-practices-with-graphql) [Quramy/gql-study-workshop](https://github.com/Quramy/g
チームの目標が「とにかくたくさん開発する」はいけない “アウトプット”ではなく“アウトカム”を重視する体制作り
プロダクト開発チームが40人規模の組織となっていく過程で、どんな課題に直面し、どのような取り組みをしてきたのかをLT形式で届ける「食べチョク Tech Talk #1 『ユーザーに早く価値を届ける』組織と技術それぞれの取り組み」。ここで執行役員CTOの西尾氏が登壇。株式会社ビビッドガーデンが重視している「アウトカム」についてと、その思考に合わせた開発体制作りについて話します。 生産者の課題と、株式会社ビビッドガーテンの取り組み 西尾慎祐氏：「アウトカム思考なプロダクト開発を実現する組織作り」というテーマで、私たちの組織や開発チームがどういう体制でやっているかという話ができればと思っています。私は、株式会社ビビッドガーデンでCTOをしている西尾です。よろしくお願いします。 まずはその前に、私たちの会社がやっていることを紹介します。ビビッドガーテンは「食べチョク」というサービスを運用しています
エンジニアが LayerX へ人事として入社しました｜serima
昨日から LayerX に人事として入社した serima です！ いままで 10 年ほどサーバサイド・インフラを中心にソフトウェアエンジニアや Engineering Manager として活動してきたので、個人的には割と大きなジョブチェンジかなと思っています。 LayerX では、まずはソフトウェアエンジニアの採用活動に軸足を置きますが、事業成長に必要なことはなんでもやりたいと思っています！ 自己紹介と転職のきっかけかなりサマリですが、高専卒 → 大学編入＆中退 → 位置情報系サービスで学生起業 → ソーシャルゲーム開発・運用 → エンタメコンテンツ、メディアの開発・運用とキャリアを積んできました。 「積んできました」というと聞こえはいいかもしれませんが、改めて振り返ると「球拾いをしてきた人生だった」感があります。 小学生の頃にサッカーをやっていましたが、好んでディフェンダーになりたが
エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita
スクワッド体制における留意点として、「Spotifyは "Spotifyモデル "を使っていない [3]」で以下のように述べられているように、単に方法論を真似るのではく、自分の組織と向き合い、学習して、進化し続けることが大切であると思います。READYFORにおいても日々、組織体制について議論し、改善を進めています。 ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。 あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。 1-2. READYFORのスクワッド体制 READYFORの場合、どのようなスクワッド体制を敷いているか？ ひと
リモートでむしろ生産性が上がったエンジニア組織の作り方を一休 CTOの伊藤さんに聞いてみた
宿泊予約事業やレストラン予約事業などを手掛ける、株式会社一休。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Teams」を活用いただいています。 今回は、執行役員CTOを務める伊藤直也さんにインタビュー。実際に「Findy Teams」上のデータを参照しながら、エンジニア組織における生産性についての考え方などを伺っていきます。 ■プロフィール 伊藤 直也 株式会社 一休 執行役員 CTO コロナ禍における開発を、Findy Teamsで振り返る ──こちらが御社の2020年1月から直近までのデータになります。プルリク作成数はだいたい平均値を超えていて、件数としては2020年7月と2020年10月に大きな山があります。今年は5月頃から全体的に伸びている傾向にありますが、これらの要因として考えられる部分はありますか？ Findy Teamsのチ
Team Topologies(by Manuel Pais)のキーポイント
この記事について CaSEというPodcastを時々聴いているのだけど、その最新話がTeam Topologiesの著者であるManuel Pais氏のゲスト回だった。すごく学びが多く、同じ悩みをもつ人も多いと思ったので内容や思考を整理してみたものを記事化してみた。ちなみに書籍のTeam Topologiesは読んでいません。 “two pizza” チームの挑戦 話はAmazon CTOのVerner Vogelのインタビューから始まる。2006年頃にジェフベゾスがTwo pizzaチームの話をしたのは有名だが、面白いのはAWSはまさにプラットフォームチームをX as a Serviceモードにした結果になっていて、意図的ではないにしろトポロジーを体現していたのだと思った。これは後半のプラットフォームチームの話にも繋がってくる 本題に戻ると、Two pizzaサイズで自己組織化に向かった
組織開発の意思決定透明化のために ODDR を試すことにしました | DevelopersIO
こんにちわ。てぃーびーです。 最近システム開発界隈でたまに話題をみかける「ADR」。 ADR は Architectural Decision Records の略で、アーキテクチャーの意思決定を決まったフォーマットで記録し続ける手法です。アーキテクチャーの意思決定後、時間の経過とともに当時のアーキテクチャーを設計した人が異動や退職で不在になり、後任が現在の設計を検討する上で、なぜ現状のアーキテクチャーになっているか確認したい、といったときがこの記録が活用される典型的なケースです。それ以外にも人の記憶は不確かなため、意思決定をした本人にとっても記録は便利です。 そういった必要性に関して niku さんの以下の記事が参考になります。 2020-05-19 ADR(Architectural Decision Records)を書くと決めた理由を自分の言葉で書き出した｜ヽ（´・肉・｀）ノ｜no
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか？ という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応
モグラたたき開発になる理由 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? モグラたたき開発になる理由 モグラたたき開発を卒業しようの一部として書いていましたが、項目が増えてきたので 別記事に独立させました。 これらは、ほとんどが推測です。 某銀行の次期システムとか、受注したが開発できすに中断した官公庁の案件とか、携帯電話開発の事例 その他もろもろの不幸な事例を元に推測で書いています。まるで自分のプロジェクトとのようだと思われる方がいらしても、他人の空似です。 チームとしての共通の目標を成し遂げようという意識が低下している。 ユーザー視点の欠落 セクショナリズムの蔓延、「それは自分の知ったことじゃない」 「今ま
50人で評価額2,100億円を越えたNotionに聞く、少数精鋭のプロダクト組織のつくりかた：連載「クリエイティブ組織の要諦」第3回
50人で評価額2,100億円を越えたNotionに聞く、少数精鋭のプロダクト組織のつくりかた：連載「クリエイティブ組織の要諦」第3回 本記事は、デザインビジネスマガジン“designing”との共同企画で、双方の媒体に掲載されています。連載『クリエイティブ組織の要諦』では、デザイナーをはじめとしたクリエイティブ職の組織作りのヒントを得るため、注目企業にインタビューを重ねています。デザイン組織立ち上げを支援してきたMIMIGURI CO-CEO ミナベトモミを聞き手に、組織デザイン／組織開発の両面からヒントを探っていきます。 第3回に登場するのは、『Notion』を開発するNotion Labs（以下、Notion）です。2020年4月に企業評価額約2,100億円に達した際、従業員数は50〜60人だったという同社（2020年7月時点）。つい先日の2021年10月9日（日本時間）には、
【前編】開発内製化の5年の軌跡。「消耗戦の悪魔のループ」をどう乗り越えたのか - エス・エム・エス エンジニア テックブログ
大手企業を筆頭に、エンジニア組織の外注依存から内製化にシフトしようとする企業の報道を目にすることが増えてきました。 一方で、実際にエンジニア組織の内製化を進めようとするには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。 実際にケースとしても世の中に少ないことなどもあり、エンジニア組織の内製化に関する方法論について紹介されたコンテンツは少なく、各社が手探りの状態でこの内製化に取り組んでいると思われます。 そこで、まさにこれから内製化という難儀な仕事に向き合う技術組織の責任者の方の一助になればと思い、エス・エム・エスが2015年よりエンジニア組織の内製化に取り組んできたプロセスとそこで得られた反省と学びについてを共有したく、50人超のエンジニア組織で技術責任者を務める田辺に内製化の全貌を聞きました。 1. 簡
1年目で辞める未経験エンジニア／採用を後悔する企業の裏側｜久松剛／IT百物語の蒐集家
先立って未経験としてエンジニア入社し、4ヶ月でフリーランスになったというポストがTwitterを駆け巡っていました。私自身は未経験エンジニアが早期退職しフリーランスとして独立（そしてそのノウハウを売る）するムーブメントを問題視しており、下記のような投稿をしました。今は削除されていますがご本人も登場されました。 公務員を辞めてベンチャー内定後、4ヶ月で独立したという生存バイアスポストが回っていますが、こういう事例があちこちにあるので未経験採用を辞めている企業は多いです。後進の邪魔でしかありません。 あと時系列的に3ヶ月の試用期間でスパッと切られた可能性があるのが気になります。 — 久松剛 (@makaibito) September 13, 2021 4ヶ月というのはまた極端な例ではありますが、1年で辞めるパターンは数多く耳にします。今回は私も失敗も含めて経験してきた未経験エンジニア採用界隈
エンジニアリングマネージャーとしてどんなことをしているのか？ - tuneの日記
はじめに エンジニアリングマネージャーとは? メンバーのサポート・育成・評価 メンバーの状態観察 目標設定・人事評価 後進の育成 日常の労務管理 開発 プロダクトマネジメント エンジニアリングのリーダーシップ 採用・採用広報・アドバイザーの招聘 採用 採用広報 アドバイザーの招聘 他社との情報交換 終わりに はじめに 今流行りの Meetyを使って社外の方とお話しする機会を作っているのですが、「エンジニアリングマネージャーとしてどんなことをしているのですか?」という質問を何度かいただいたので、自分の整理のためにも日々の具体的な行動・活動をまとめてみます。 私はRetty株式会社でtoC Web開発/toB Web開発 両方をみているエンジニアリングマネージャーであり、この記事を書いた2021年9月時点では20名弱のマネジメントを務めています。エンジニアリングマネージャーとなってからは2年が
プロダクト開発組織のチームビジョンを作ったらすごいパワーが生まれた話 - Uzabase for Engineers
こんにちは。NewsPicks プロダクトチームの文字です。今日はプロダクト開発組織のチームビジョンを作ったら、すごいパワーが生まれた話をさせて頂きます。 「経済を、技術でもっとおもしろく。」 今年の春、NewsPicks のプロダクトチームでは、こんなチームビジョンを作りました。実は NewsPicks のタグラインは「経済を、もっとおもしろく。」なので、会社の掲げるタグラインをほぼ踏襲しているように見えます。しかし一見凡庸なこのビジョンが、実はとても大きなパワーを秘めていたのです。 1/ なぜビジョンをつくったのか 増大し続ける技術的負債と運用負荷 組織の急拡大 2/ みんなでビジョンをつくる 合宿の開催 腹落ちできるビジョンが完成 3/ ビジョンをつくったら、どうなったのか？ ビジョンはパワー 4/ これからのプロダクトチーム 1/ なぜビジョンをつくったのか そもそも、何故こんなチ
ソフトウェア開発における人的リソースの理想的な配分
背景SRE という概念が生まれてから数多くの開発チームで「ソフトウェアエンジニアリングの手法で運用を改善する営み」が行われてきた。 同時に、技術的負債が経営レベルで認知されるようになり、日常の会話の中でも長期・短期のトレードオフを念頭に置いたプロジェクト推進がやりやすくなったのは言うまでもない。 しかし、スタートアップでは Dev と Ops が別れていることは稀で、「全員が全てに対応する」ような状況になってしまうことがしばしばある。これは小さい組織だけの問題ではなく、例えば大企業の中の新しいプロダクト開発チームでも同じことが言える。 SRE を念頭に置き、技術的負債の主導権を握るために必要なチーム体制とはどういうものなのだろうか？ タスクの分解小さな組織のソフトウェアエンジニアは日々数多くのタスクを与えられている。場合によっては数名のメンバーで新規機能開発から日々の不具合修正、そして S
マイクロマネジメントは悪か？よりよい組織をつくるためのマネジメント形態についての考察 - クックパッド開発者ブログ
レシピ事業サービス基盤部で部長をやっています、新井(@SpicyCoffee66)です。引越しを機に MtG のカードをほとんど売ったはずなのに、そのときは存在しなかったポケモンカードのデッキが手元にあります。なぜ？ 私は 2017 卒のエンジニアとしてクックパッドに入社し、様々な業務を経験した後に 2020 年の 8 月から部長となりました*1。最近はコードを書いていないので Techlife の執筆内容に迷ったのですが、今自分の中にある「優れた組織づくりについての考え方」をまとめてみることとしました。部長になる前にも、グループ長として小規模なチームマネジメントの経験があるとはいえ、それを含めても２年弱のマネージャー経験しか持っていないので、これが絶対の正解というわけではなく一つの考えとして読んでいただけると幸いです。 組織の存在理由 優れた組織づくりについて考えるために、まずは組織の存
クラスメソッドのMAD事業部とは何か？ | DevelopersIO
2021年7月に発足したMAD事業部が、実際なにを価値提供するのか？理想の支援の形を赤裸々にお話します。 「クラスメソッドMADってなんなん？なんか狂った感じ？」 「うん、だいたいあってる」 というわけで、ハマコーこと濱田孝治は、2021年7月付で、クラスメソッド株式会社 CX事業本部 MAD事業部の部長を拝命致しました。 拝命とか書くと「そんな厳かな儀式があんの？」と思われる方もいるかも知れませんが、そこは弊社、のんびりしたもんです。自分も「ブチョー」と言われてもあまりぴんときません。 MAD事業部は、MADチームとしてちょうど一年前の2020年7月に発足しました。この一年はとにかく目の前の案件をこなしていくことに精一杯の一年だったのですが、改めてこれまでを振り返ってみることで、我々がどのように進化していきたいのか、何を社会に価値提供していきたいのかがおぼろげながら見えてきました。 MA
チーム内でも目標設定と振り返りをやってみよう！から1年が経ちました - STORES Product Blog
テクノロジー部門、STORES ECでフロントエンドエンジニアをしている @daitasuです。 私たちのチームでは、会社全体での人事制度で設定する目標とは別に、チーム内で独自にクオーターごとの目標設定と振り返りをしています。 チーム内での目標設定と振り返りを1年ほど続けてきたので、なぜこの取組を始めたのか、実際やってみてどうだったかを書いていこうと思います。 チームの位置づけ UI改善チームとは hey内では、全プロダクト横断的なテクノロジー部門という棲み分けがあり、その中にSTORES ECの開発を進めるECの部隊があります。 私たちフロントエンドチームは、ECのエンジニアチームの中の1つとなっています。 hey社のEC本部では、フロントエンドチームはUI改善チームと呼ばれています。 フロントエンドチームの構成 フロントエンドチームは、大きくプロダクト開発のチームと基盤改善のチームに分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自由と責任を開発チームにもたらしたら開発速度が上がった話
