【資料公開】30分で分かった気になるチームトポロジー
みなさんこんにちは。@ryuzeeです。 2022年3月16日に「チームトポロジーを成功させる実践方法の探求」というイベントで登壇した際の資料を公開します。 セッション内容は、書籍の内容をかいつまんでまとめたものになっており、とりあえずチーム内や社内でチームトポロジーの概要をさくっと押さえるのに使える資料になっていると思います。 スライドを見て興味を持った場合は、是非書籍をご覧ください。紙とKindle版の双方が発売されています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社：日本能率協会マネジメントセンター発売日：2021-12-01単行本：280ページISBN-13：9784820729631ASIN：4820729632
小さなチームのままフルスタック問題を乗り越えたい
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は「プロダクト開発チームがプロダクトに集中できるように、専門性の高い技術課題を解決するチームを作りたい」という弊社の組織設計についてパブリックなところに公開してみたいと思います。 理想の組織とフルスタックの限界会社組織が大きくなっても、プロダクト開発チームはできる限り当事者のみで意思決定ができるように小さくしたいと考えています。 そうすることで開発スピードが上がり、その結果ユーザーへの価値提供がより高められるという信念からです。 ですが、プロダクト開発チームを小さく保つということは、各人のスタックを広げる必要があることを意味します。担当を分業するとその分専門性は高まりますが、同時に関係者が増えてしまいますよね。 そして専門性がないと乗り越えられない技術の壁も存在
GitLabで学んだ最高の働き方。気持ちよく働くための組織と個人のテクニック（後編）。デブサミ2022
GitLabで学んだ最高の働き方。気持ちよく働くための組織と個人のテクニック（後編）。デブサミ2022 2022年2月に行われたイベント「Developers Summit 2022」で、GitLab社で働く伊藤俊廷氏と佐々木直晴氏が実際の体験を基にした働き方についての講演「GitLab社で学んだ最高の働き方」を行っています。 実際にオールリモートで働く二人の講演内容は、多くの示唆に富むものになっています。ここではその内容をダイジェストとして記事化しました。 この記事は前編と後編の2部構成です。いまお読みの記事は後編です。 1on1のアジェンダ例 これが実際に、私とマネージャーの1on1（一対一のミーティング）のアジェンダ例です。1時間やっています。 私のマネージャーのアジェンダの特徴として1個目に雑談と書いてあるので、アイスブレイク的にも雑談を毎回議題としてやっています。お互いの趣味のこ
組織の壁みたいなもの
こんにちは、Reluxの篠塚です。35歳の最終日、超大作の1.4万字のNoteができあがりました。書いてみたは良いですが、長すぎてニーズあるのかが実は不安です。頑張ったので、Twitterをフォローしてくれたり、シェアしてくれたらすごく喜び… 経営者ではないけど、自分は5年以上、とあるプロダクト開発組織の初期のメンバーとして関わってきている。 その組織内のエンジニアリングマネージャーであるのと同時に、なんとなく、組織全体の空気感だったりとか慣習を作ってきたうちのひとりだと今振り返ると思う。多分、在籍期間が長いのと、組織のほぼ半分がエンジニアで、それをマネジメントする立場だから自然とそういう立場も引き受け続けてきたのかなーと思う。 そういう中で、やっぱり組織の壁は存在していたし、今もかなりソレと戦っている。5人くらいで開発を始めた当初はしばらくは、非常に良い意味で本当に好き勝手にプロダクト開
マネーフォワードCTOが考えていること（2022年3月） - Money Forward Developers Blog
こんにちは、マネーフォワード CTOの中出（なかで）です。 CTOの私が、普段「なにを感じて、どんなことを考えているか」について、四半期に一回社内へ共有している内容を一部編集し、エンジニアブログに公開したいと思います。 前回はこちら：マネーフォワードCTOが考えていること（2021年12月） マネーフォワードの開発組織の強み マネーフォワードのエンジニア組織が持つ強みはなんでしょうか？CTOとして感じている最大の強みは、サービスを生み出し続ける力、開発力です。 マネーフォワードは今年創業10年を迎えますが、毎年いくつものサービスがリリースされています。昨年度には、個人向け、法人向け、金融機関向けでそれぞれ複数の新規サービスがリリースされました。既存サービスも機能面でも使いやすさでも改良を重ね、より多くのユーザーを獲得しています。マネーフォワード全体では、リリース後も成長を続け、運用・改善を
テックリードとしてシステムの未来を示して品質の期待を合わせる - yigarashiのブログ
最近チームのテックリードを拝命して、テクノロジーマネジメント領域もリードすることになりました。興味の中心は開発プロセスやデリバリーで、エンジニアリングはまだまだひよっこなので苦労の日々が続いています。この記事では新米テックリードとしての取り組みをひとつ紹介します。 私のチームでは10個近いコンポーネントのオーナーシップを持っています。それらの品質の期待度は大きく異なり、変更頻度、採用技術、システムに占める重要度といったパラメータから決定されます。この期待を見誤ると、変更頻度が極めて低いコンポーネントを頑張ってリファクタリングしたり、モダンな技術が採用され寿命の長いシステムを雑に拡張したりと、成果の小さいアクションを取ってしまいます。逆にこの期待を適切に捉えられると、チームのリソースがコスパが高いアクションに向かっていくことが期待できます。変更頻度の高いコンポーネントのCI/CDを改善し、重
事業で勝つためのマネジメントとは。エンジニア組織づくりの裏側を一休伊藤氏とスタフェス柄沢氏に聞いてみた
青山学院大学大学院博士課程前期修了後、新卒でニフティ株式会社に入社し、ブログサービス「ココログ」を開発。その後、株式会社はてなの取締役CTOに就き、はてなブックマークの開発などを主導した。フリーランスでの活動などを経て、2016年4月、一休の執行役員CTOに就任。 スターフェスティバル株式会社 柄沢 聡太郎[@sotarok] 中央大学大学院卒業後、ソフトウェアエンジニアとしてグリー株式会社に入社。その後2011年株式会社クロコスを共同創業、2012年にヤフー株式会社へ売却。2015年より株式会社メルカリで執行役員CTO及びVP of Engineeringとして技術領域全般を統括し、エンジニア組織20人規模から数百人規模、そしてプロダクトの急成長に貢献。2020年2月よりスターフェスティバル株式会社に執行役員CTOとして参画、同年9月より取締役就任。 登壇者の自己紹介からスタート。3人の
挑戦する組織にするためにCTOになってからやったこと | PR TIMES 開発者ブログ
本件は実装に漏れがあった状態で放置してしまっていました。お客様に多大な迷惑をかける前に防ぐことができず、申し訳ございませんでした。 今回の事象が発覚してすぐに総点検・改修プロジェクトが開始され、調査と改修を行っていきました。 こういったことが起こった時にすぐに調査できるようにBigQueryの導入を進めていたり、リファクタリングデーの設定により古いソースコードにも目を触れる機会を作っていこうとしていたのですが、いずれも間に合わず、かなり悔しい思いをしました。 しかしそんな中でも各メンバーが頑張り、1つずつ問題を解消していき、何とか終わらせることができました。こんな大変な状況でも対応をし続けてくれた人には本当に感謝の気持ちでいっぱいです。 セキュリティ対策で唯一間に合ったと言えるのはKENROの導入でした。 KENROは新卒＋希望者の人に受けてもらいましたが、KENROで得た知識を今回のプロ
人月の神話
人月の神話 をひさしぶりに読んでみた。 人月の神話は、フレデリック・ブルックスの超有名古典的エッセイ集で、ソフトウェアエンジニアリングに関する多岐にわたるトピック取り扱っている。その中でもとくに有名で、よく世間で言及されるのは、表題にもなってる「人月の神話」と「銀の弾などない」、それから「セカンドシステム症候群」あたりだろうか。 はじめて読んだのは20年くらい前。社会人になったばかりのころ、満員電車にゆられながら、「へー人を増やしても開発ってうまくいかないのねー」などとわかったような顔をしながら読んでいたのを覚えている。当時は職業プログラマとしての経験を積む前で、本を読んでも鵜呑みにすることしかできなかった。でも、熟練のプログラマとして経験を積んだいま読んだら、またなにか違った洞察を得られたりするかもしれない。読み返してみた動機はそんな感じ。 目次 現代のプログラマにとって有益か やっぱり
Team Topologiesを読んだ
https://teamtopologies.com/ DevOps consultantとして技術と組織の両面からDevOpsの支援を行なってるMatthew SkeltonとManuel Paisによる本．Consultant本は大体中身が薄く感じることが多くなり手に取ることは少なくなってきたが，各所で見かけたり，2人によるDevOpsにおけるチームのあり方のパターンをまとめたWhat Team Structure is Right for DevOps to Flourish?が良かったので読んでみた． 本書はDevOpsの視点から高速なDeliveryを実現するためにどのようなチームや組織を作るべきかについてまとめている．個人ではなくチームをDeliveryの最も重要な単位と考え（Team first-thinking），チームが最大限にパフォーマンスを発揮するために，チームの人数
意思決定のROIという考え方｜樫田光 | Hikaru Kashida
こんにちは、樫田です。 ご存じの方もそうでない方もいると思いますが、この数年メルカリという会社でデータ分析という業務を通して意思決定に関わる仕事をしてきました。（知らない方は ⇨ 僕について） ビジネスはいわば意思決定の塊で出来ています。事業と組織、そのすべてのことが何らかの意思決定を通して動いていると言っても過言ではないでしょう。 僕自身、仕事で分析を行う中でも「意思決定」という領域に対するフォーカスは強かった方だと自負しています。今振り返ってみると、メルカリ在籍時に受けたインタビューもそのスタンスがタイトルとして切り取られていることが多かったようです。 さて、意思決定について話す時に「良い意思決定とはなんだろう？」と問うと、一般的には「良い意思決定とは正しい決定である」というような答えが返ってくることが多いような気がしています。また、昨今のスタートアップに聞けば、意思決定は早いほど優れ
自分のキャリアについて｜nishiba
今の仕事について考えをまとめたいと思います。 急にポエムを書いてみようと思いました。その理由は最後に書きます。 私はあるIT企業で機械学習エンジニアとして働いています。 採用チームやAI・機械学習チームのチームリーダー、エンジニアGのグループリーダーをしています。 しかし、もしこの内容に組織的な話が含まれていたとしても私個人の考え方で組織の考えではありません。 免罪符的に「組織の考えではありません」というわけではなく、私に与えられている裁量の範囲内であり本当に私個人の考えです。 現場の裁量が大きく、チームマネジメントの方法はそのチームのリーダーに委ねられています。 これまでのキャリア大学では、学部でマーケティングや組織論、修士・博士では数理ファイナンスを専攻していました。 (卒業後はメガバンクでクオンツとしてモデル開発・システム開発を行っていまいした。) 私は「数学・コンピュータを使う」&
一休における開発組織の変遷（目的型組織への移行） - 一休.com Developers Blog
メリークリスマスイブ！ 皆様クリスマスイブはいかがお過ごしですか。 データサイエンス部所属のエンジニア 笹島 id:sisijumi です。 年末ということもあり、今日は一休という会社のエンジニア組織の変遷を振り返るとともに、現状に関してもお話させていただきます。 （現状はデータサイエンス部ですが、今年の10月までは宿泊事業部のエンジニアのマネージャーをやっておりました。） 一休における収益の変遷 宿泊事業に関してですが、過去発表した資料を元に説明させていただきます。 （近年非上場になった為、直近の収益に関しては資料はありません。） 創業期、成長期を経て、一時停滞したものの、きちんと再度成長していることがわかりますね。 事業のステージに合わせて変化してきました 創業期、成長期を支えてきた組織構造 各部署内に宿泊・レストランチームが存在しています 各部署が都度エンジニアのマネージャーとコミュ
1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断
■イベント 【Sansan Tech Meetup マネジメント編 #1】 1年で6倍にメンバーが急増したエンジニアリング組織の変遷と判断 https://sansan.connpass.com/event/238006/ ㅤ ■登壇概要 登壇者：Bill One Unit プロダクト開発責任者 / 大西 真央 「請求書受領から、月次決算を加速する」をコンセプトに2020年 5月にローンチしたクラウド請求書受領サービス「Bill One」。その事業成長を支えるエンジニアリング組織は、直近の1年で5人から30人と急激にメンバーが増えました。 本発表では、組織拡大の過程を振り返るとともに、エンジニア部門のマネジャーがその渦中でどのような課題に向き合い、どのようなことを考え、どのような判断をしたのか。プロダクトグロースの中でのエンジニア組織の変遷と、具体的な取り組み例をご紹介します。 ㅤ ▼E
【前編】開発内製化の5年の軌跡。「消耗戦の悪魔のループ」をどう乗り越えたのか - エス・エム・エス エンジニア テックブログ
大手企業を筆頭に、エンジニア組織の外注依存から内製化にシフトしようとする企業の報道を目にすることが増えてきました。 一方で、実際にエンジニア組織の内製化を進めようとするには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。 実際にケースとしても世の中に少ないことなどもあり、エンジニア組織の内製化に関する方法論について紹介されたコンテンツは少なく、各社が手探りの状態でこの内製化に取り組んでいると思われます。 そこで、まさにこれから内製化という難儀な仕事に向き合う技術組織の責任者の方の一助になればと思い、エス・エム・エスが2015年よりエンジニア組織の内製化に取り組んできたプロセスとそこで得られた反省と学びについてを共有したく、50人超のエンジニア組織で技術責任者を務める田辺に内製化の全貌を聞きました。 1. 簡
【後編】開発内製化の5年の軌跡。「消耗戦の悪魔のループ」をどう乗り越えたのか - エス・エム・エス エンジニア テックブログ
エンジニア組織の内製化を進めるには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。エス・エム・エスは2015年よりエンジニア組織の内製化に取り組んできました。そのプロセスとそこで得られた反省や学びを技術責任者の田辺に聞いたインタビューの後編です。 tech.bm-sms.co.jp 前編では、2015年の入社から1年半くらいの間にやったことを話しました。リサーチから始めて会社の特性を理解しにいくということと、小さく始めて検証をするというスタートをきり、小さな新規サービスの立ち上げに上流からかかわって、アジャイルな開発がうまくいったということでした。 エス・エム・エスは当時40近い数のサービスを展開していたのですが、最初の1年半で内製化を進める主要なサービスと注力をせず終了するサービスや CMS 化で開発能力
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアの個人ブランディングと技術組織
Ubie Discoveryにおける基本的な選考フロー｜Ubie (ユビー)｜note
開発組織の持続可能性について
成果を出し続けるエンジニア組織を目指してやってること
