XP祭り2024の登壇資料です
ここ数年、「会社を筋肉質に」というワードをIT業界で見るようになった。 元は市場の不況に応じて海外VCが言い始め、実際に言葉の波に乗るように外資企業ではレイオフが進んできた。1年遅れくらいで国内ベンチャーにもその波が来ており、右も左も筋肉質化と言っている。この波はすぐにIT全体に波及するだろう。 「筋肉質とは何か」とか「筋肉質化の功罪」はまたあるとして「会社の筋肉質化において重要なのはリーダーがどれだけ思考を透明化できるか」であると叫びたい。 思考は伝わらない私は、最近は転職にあたって引き継ぎ作業を行っている。 元々後続を探す、作るのがLeadと名前のついた人の役割だと思っているので、抱え込んでいるタスクこそ少ない。 少ないタスクの中でも「これはXのためにやります」と宣言してスタートする事が多く、何事も記録に残す事を徹底しているし、Qの終わりには1〜2万字の個人振り返り記事を社内に公開して
こんにちは、モノタロウのUIUXグループの澤井です。 主にサービス開発や商品開発のためのリサーチ・体験設計、これらのための仕組みづくり・運用に携わっています。 この記事では、チームにポジティブなコミュニケーションを増やすために、メンバー同士の自己開示のためのツールとしてスキルマップを利用したこと、利用にあたって工夫したことについてお話していきます。 目次 スキルマップってどんなツール? スキルマップを利用しようと思った背景 スキルマップの利用にあたって工夫したこと スキルマップを利用してどうだったか おわりに スキルマップってどんなツール? そもそもスキルマップはどんなものかといいますと、縦軸と横軸を中心で交差させて分けた4つのセグメントにスキルをマッピングして傾向や状態を可視化するものです。自己紹介や自己分析に使ったり、目的によって様々に利用できる便利なツールです。 詳しくは、宇野さんの
今日で仕事が納まった。それと同時にチームメンバーが一人チームを去ることになった。送別会もしたのでお別れはまあそれなりにしたんだけど、結構自分に影響を与えたのでなんとなくブログとして残しておくことにした。 うちの部署は複数のスクラムチームで構成されているスクラムオブスクラムという形を取っている。僕がこのチームに配属されたのは二ヶ月前くらいのことだ。部署内の別のチームからこのチームに異動したのがきっかけだ。チームメンバーの一人であり、今回お別れした人は認定スクラムマスターを持つエンジニアであり、このチームはちゃんとアジャイルなチームになろうとしているという話を事前に聞いていた。(以降、この人を彼と呼ぶ) 前職でもスクラム開発はやっていたつもりだったし、以前のチームでもスクラムを行なっていたのでなるほどなるほどという感じでチームのやり方に乗っかっていくことにした。見積もりをして、計画で洗い出し、
CTOアドベントカレンダー2021の12日目の記事です。 今の時代、様々な組織の情報透明性が上がっています。 有名スタートアップが自社のエンジニア組織についてメディアで発信している情報を見たり、流行りの本でGAFA・米国ユニコーン企業のエンジニア組織で採用されている最新の概念を勉強したりできます。 しかし成功している素晴らしい会社の話を聞いていると、どうしてもそれが唯一の正解だと思ってしまいがちなので、注意が必要です。 それらは成功して大きくなった後の組織の話であり、またブランディングとして良い側面だけをクローズアップして拡散しています。 そしてタイトルの通り、事業内容により必要なエンジニア組織は大きく異なります。 成長途上のスタートアップでは名もなき戦略を自分達でゼロベースで考えながら、それを泥臭く改善していく必要があります。 具体的に、事業内容によって必要なエンジニア組織が変わるとはど
チームメンバーや他社のエンジニアとの 1on1 の中で、「憧れている人とかいますか?」という話をすることがある。この質問はわりと継続して聞いているなと思ったので雑に書いておきたい。 チームメンバーとの 1on1 で聞くのは半年ごとくらい。目標設定など、たまにはちょっと中長期の話でもしますかってタイミングで話している。いわゆる"キャリア"の雑談である。 自分は「1年後/3年後どうなっていたいか?」みたいな質問がすごく苦手で、うまく答えられたことがない。どうなりたいかを明確にするのは大事なことだと思うけれど、正直3年後とか何もわからんという気持ちになる。自分ができないのでチームメンバーにも聞けない。 そこで、違う聞き方として「憧れている人はいるか?」という雑談をしている。この質問は人によって回答がぜんぜん違うのが面白い。 たとえばiOSエンジニアだと @k_katsumi さんとか。Go書いて
身の回りではチームのMTGとかは普段カメラオフでも、1on1のときくらいはオンにしている人が多い気がする。たぶん1年以上顔見てない人もいるけどとくに困ってないので、僕はどちらでもいいのだけどみなさんはどうだろう。 僕はある日、手荒れ対策でMacをクラムシェルモードにしたらカメラが畳まれてしまい使えなくなってしまった、という事情である日カメラオフにして過ごしていた。 さっき一念発起してMacのフタをあけてカメラオンにしてみたけど、ケーブル(高額なケーブルなので長さにゆとりのあるものは買えない)が短いので、ひきちぎれそう。 普段はカメラオフだけど、1on1のときくらいはカメラを— 趣味はマリンスポーツです (@hitode909) 2023年8月21日 この日記が、カメラオンにするのが当然、みたいな押し付けを推し進める記事にはならないようにしたい。 むしろ、1on1だからといってMacのフタ開
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),チームが最大限にパフォーマンスを発揮するために,チームの人数
はじめに 新チームを、自律自走するチームへ移行させるテーマで記事を書いていきますが、 一番の肝は 『もしかして、あなたのチームは、新チームなのでは!?』 という点です。 新チーム≒未成熟なチームだとすると、 歴の長いチームだからと言って成熟したチームであるとは限りません。 優秀なメンバーが揃っていても、今ひとつスピードが出ない 何かとアクシデントが多い マネージャーが説明ばかりしている これらはチームが成熟しておらず、統率が取れていない証拠です。 ・チームが統率されていないことに気がつく ・チームが自ら統率された状態をつくる環境構築 という流れを書いていきます。 「新チーム」はぬるっとやってくる 新チームを受け持ったマネージャーのために記事を書いていますが、 チーム・ピープルマネジメントにおいて問題が発生するケースの多くは 「新プロジェクトが発足した」ようなタイミングよりも いつのまにか新
尾藤さんと平田さん ニュースサマリ:顧客とのエンゲージメントに特化したマーケティングプラットフォームのReproは6月7日、開発組織の責任者(CTO)に、ウノウやUUUMなどで活躍した尾藤正人氏(BTO氏)が6月1日付けで就任したことを伝えている。 尾藤氏はメルカリ創業者の山田進太郎氏が創業したウノウの初期メンバーとしてCTOを務めた後、2015年からUUUMの執行役員CTOとして上場までを牽引した人物。2020年に同社を退任した後は技術顧問やエンジェル投資家として活動を続けてきた。今回のReproも顧問先のひとつとして関わり、2021年6月から執行役員CTOとして専任することとなった。 Reproはアプリを中心にユーザーのエンゲージメントを高めるためのコミュニケーションツールを提供する。現在世界66カ国にて利用実績があり、これまで累計で7,300件に導入されている。 話題のポイント:テク
業務上のやり取りで一番抜け漏れがあると困るのは、 金額や納期や業務の定義やその他の契約条件など業務の進行に必要な情報だと思うんだけど、 そういう要件のやり取りだけで、雑談が皆無だと、 「尊重されていない」と感じて自尊心を損ないパフォーマンスがガタ落ちする人いるよね。 ガタ落ちしない人とガタ落ちする人がいるんですよ。露骨に差が出るんですよ。 テレワークになって鬱病になった人と、元気なままの人いますよね。人によって本当に差があるんですよ。 雑談が無くてもパフォーマンスに変化がない人にはテンプレメール文で仕事をお願いできる。 でもパフォーマンスがガタ落ちする人には、その人に向けたメッセージ (その人の趣味・関心事項を意識した、思いやりが感じられる、オリジナルのもの)を添えなければいけなくて、 毎回それに結構な時間を要している。 正直、キツイなって思うことも多い。心の負担になっていて、すり減らしな
複数チームに分かれたプロダクト開発スタイルをかえって不自由に感じてはいないだろうか。チーム間に張り巡らされた無数のチェーンが自由を奪い、チームの活動を束縛する。そんな感覚だ。 組織を複数のプロダクト開発チームに分割する組織アーキテクチャは、マイクロサービスアーキテクチャに例えることができる。そこから見いだせる原則は、チームをコンポーネントとして捉え、凝集度を高く、結合度を低く設計することだ。この原則を軽視すると、チーム間の依存関係が互いをチェーンのように繋ぎ、絡み合い、組織全体を「分散されたモノリス」に変えてしまう。その結果として、チームは日々、多大な調整コストや遅延コストを支払い続ける羽目になる。 では、既存のソフトウェアプロダクト開発において、個々のチームが活動しやすい分散型組織の設計とはどういうものだろうか。あくまでも私の経験や考えに基づくものではあるが、本稿はこれをテーマに書いてみ
MLOpsチームは4名程度の規模だったのですが、PF-SREチームは当初から8名という大所帯(現在は10名)で、適切なチーム人数と言われる Two Pizza Rule の8人を超えてしまい、チーム運営のやり方を変えていく必要がありました。 また、2020年2月頃からCOVID-19によって週5リモートワークに代わり、その中で如何に効率を落とさずにチームとして働くかを模索していく必要がありました。 本記事では、小さなチームから、大きなチームのリーダーに移り変わるにあたってどのような変化を進めていったのか、またCOVID-19におけるリモートワークにどのように適合していったのかを記載していきたいと思います。 チームリーディングで気をつけていること私がチームをリードするときに気をつけていることは、約一年前に発表したZOZO MLOps のチームリーディングとSRE (Engineering)と
日本のNode.jsコミュニティの中心で活動してきた古川陽介(@yosuke_furukawa)さんは、仕事でもシニアソフトウェアエンジニアとグループマネジャーの二足のわらじを履きこなしています。アプリ開発の最前線における複数の役割にコミュニティの運営と、これだけわらじを履いていては足がもつれてしまうのではないかというのは勝手な印象で、古川さんにとってみればどれも地続きのことだと言います。 スペシャリストとしてキャリアを築いてきながら、どういった形でマネジメントにも取り組むようになったのか。フロントエンドに傾倒するようになったきっかけから、ひとつの技術領域を突き詰めた上でその分野のリーダーとしてチームをまとめ、育成に取り組む上での心がけなど、これまでの歩みも含めてお話をうかがいました。 スペシャリストでありマネージャーである必要性があった ユーザーを喜ばせるためにフロントエンドを突き詰める
こんにちは。 Software Engineerのsota1235です。 今回は10Xのセキュリティチームこれまでとこれからについてお話ししようと思います。 隠していたわけではないのですが、 採用資料や対外発表等で特にアピールもしておらず、結果的にステルス活動みたいになっていたので本邦初公開の内容ばかりです。 この記事では 10XおよびStailerにおけるセキュリティの重要性 セキュリティ観点で見る今までの10XとIssue なぜセキュリティチームを作るという判断をしたのか 今までどんな取り組みをしてきたのか 等々をお伝えできればと思っています。 10XおよびStailerにおけるセキュリティの重要性 10Xの提供するStailerはいわゆるB to B to Cのサービスです。 to Cは商品を求めてアプリやWebサイトを訪れるお客さまに対してセキュリティ観点で次の価値を提供する必要が
新しい事業アイデアを育てるプログラムで、どうにかひねり出した仮説を経験豊富な上層部からコテンパンに叩きのめされる。珍しいことではない。よくある構図だ。プログラム伴走をつとめると、こういう局面を必ずといって良いほど目の当たりにする。 あいまいで、何も筋道がみえない中で、それでも仮説を整えて、どうにか最初の段階を乗り越えようと(この手のプログラムはステージ制の設計が織り込まれる)、手がかりを掴んで審判の場に臨む。そこで、即時ノックダウン。3カウントさえ要らない。むしろ早くリングから助け出した方が良いのではないかと思えてしまう。 洗礼の内容としては至極もっともで、正しい。さすが、年の功というべきだ。長年の領域であれば経験に裏打ちされた、確かな教えが洪水となって溢れでてくる。自分の知っている正しいことで、自分の認識している自分の役割(未熟なアイデアをバウンスするゲートキーパー)を果たそうとする。
医療ビッグデータを活かした事業を幅広く展開しているJMDCには、魅力的な経歴や豊富な経験を持ったメンバーが所属しています。今回は、シリコンバレーのスタートアップ企業でCTOを務めた小原さんにインタビューを実施。JMDCへの転職を決断した理由やシリコンバレー行きを目指す人に向けてのアドバイスを聞きました。 <プロフィール> 小原 大樹(こはら だいき) 新卒でITコンサルティング事業を行うフューチャーアーキテクトに入社。その後、アメリカに渡り、シリコンバレーのスタートアップ2社でCTOを経験。ゼロからのプロダクト開発や多国籍メンバーのマネジメントに奔走した。2021年9月にJMDCに入社し、2022年4月からユーザープラットフォーム開発部の部長に就任した。 新卒で入社した会社を辞めてシリコンバレーに挑戦 ーー新卒で入社したフューチャーアーキテクトでは、どのような業務に取り組んだのでしょうか?
世界66か国7,300以上の導入実績を持つCE(カスタマーエンゲージメント)プラットフォーム「Repro(リプロ)」を提供するRepro株式会社(以下、当社)は、6月1日付で執行役員CTOに尾藤正人氏が就任したことをお知らせいたします。 ▲歴代CTOと新CTO尾藤正人氏(写真右下)、代表取締役平田祐介 当社は2014年に創業し、今年で8期目を迎えることができました。 2020年より、コロナ禍でDX推進の動きが強まり、当社の事業領域であるデジタル接客ツールのニーズが増加していることから開発組織を拡大させています。 これらを背景に、拡大した開発組織の生産性最大化を図るべく、数々の企業で開発組織のスケールアップを担ってきた尾藤正人氏(写真右下) を三代目CTOとして招聘しました。 初代CTOを務めた三木明(写真左上)は現在、エンジニアリングスキルを活かし、エンタープライズを中心にデジタルマーケテ
こんにちは。ソウゾウの Software Engineer / Engineering Manager の@motokieeです。連載:「メルカリShops」プレオープンまでの開発の裏側の4日目を担当します。 4日目は、ソウゾウがどのような体制でメルカリShopsを開発しているかについて、Team Topologiesの解説を交えてお送りします。 はじめに チームの在り方には様々な形がありたくさんの議論が交わされていると思います。自分自身も以前いた会社はもちろん、メルカリに入ってからも旧ソウゾウ、JP(日本事業)、メルペイとの関わり合いなど様々なチーム構成を見てきました。 タイトルにあるTeam Topologiesですが、https://teamtopologies.com/ では以下のように定義されています。 Team Topologies is the leading appro
We help product, technology and engineering leaders design high-impact team-of-teams organizations. DESIGNING TEAM-OF-TEAMS ORGANIZATIONS FOR FAST FLOWTeam Topologies is the result of years of research into how successful leaders design team-of-teams organizations delivering business outcomes through technology. What do leaders use Team Topologies For?Team-of-teams design for product-driven and pl
こんちには。Cacoo開発チームの木村(@cohhei)です。みなさんリモートワークしてますか? テレワークを許可されても、約40%が活用していないという調査結果もありますが、現在ヌーラボでは原則オフィスに出社しない方針になっています。今回は福岡オフィスのCacoo開発チームで実施した「ふりかえり」についてご紹介します。 すべてがリモートになる ヌーラボはオンラインコラボレーションツールを提供しています。拠点が離れているメンバーや自宅で作業しているメンバーがいても問題なく業務が進められるよう、普段からBacklog、Cacoo、Typetalkを使ってやりとりをしています。 僕たちCacooの開発チームも家庭の事情などで週に数回ほど在宅勤務を選択するメンバーもいます。一方で、国内のメンバーは全員福岡にいることもあり、ミーティングを全員が出社する日に合わせることもありました。 ただ、昨今の情
こんにちは。READYFOR(レディーフォー)で CTO をしている町野です。 READYFOR Advent Calendar 2020 の25日目の記事になります。 はじめに 早いもので、2019年に READFOR に CTO に参画して、もうすぐ2年が経とうとしています。当時まだ10名に満たなかった開発チームは倍以上の人数になり、おかげさまで全社の社員数も100名を超える規模にまで成長しました。 組織が一定の規模を超えてくると、その規模に合わせた組織の構造化が必要になってきます。この記事では、READYFOR のプロダクト開発体制をご紹介しつつ、組織設計において必ず問題になる「境界マネジメント (boundary management)」について思考を巡らせてみたいと思います。 ミッションと専門性で分かれる組織単位:Squad & Chapter READYFOR では現在、Spo
私たちは同僚についてよく知っていると思い込んでいます。隣のデスクの同僚のコーヒーの好みや、考え込むと親指の爪をかむ上司の癖は知っているとしても、チーム メンバーについて実際はどれほど知っているでしょうか? 何がチーム メンバーの仕事のモチベーションになっていますか? どういう方法でのフィードバックを好んでいますか? 最も集中力が上がり、生産性を発揮できるのはいつでしょうか? 何も思いつかない場合には、アドバイスがあります。チームの仲間と一緒にこのユーザー マニュアル テンプレートを使い、各々の行動原理を掘り下げてみてください。 ユーザー マニュアル テンプレートの使用方法 この演習を最大限に活用するために、各チーム メンバーにこのテンプレートを渡して十分な時間を用意して各自でテンプレートに入力してもらいます。時間と場所を決めてテンプレートのすべての 11 行 (好きなことわざから最大の試練
こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2020 の12日目の記事です。 アカツキは10周年を迎え、それと同時に経営体制が一新され、経営チームExecutive Leadership Team(ELT)が結成されました。 経営戦略の基本方針も変更となり、社内の構造的にも社内の方針としても、アカツキにとって大きな変化のある1年となりました。 私もELTのメンバーとして現在主力であるゲーム事業の職能組織を束ねる立場(Chief of Staff, Games / CoSG)となり、影響の範囲も、責任の範囲も大きく拡大しました。 これまでは、私はVP of Engineering(VPoE)としてエンジニア組織を束ねる立場にあり、一つの職能のことだけを考えておけば良かったです。 しかし今では、エンジニアだけでなく、デザイ
「パンがなければお菓子を食べればいいじゃない」とマリー・アントワネットは“言ってない”そうですね。 そんな事からも、自分の言葉でこのようにブログなど で文章をしたためるのは大事なのかもしれません。 Photo by Youjeen Cho on Unsplashいやね、 「必要な人材が足りなければ、育てればいいじゃない」 なんてフレーズを思いつきまして。なんとなくマリー・アントワネット思い出しちゃった。レッテルって良くないですね。 去る、2021年4月15日 DevOpsDays Tokyo 2021 で発表をさせて頂きました。 話しの風呂敷を広げすぎて、なんだか「上澄み」の発表になっちゃいました。でも、楽しんで頂けたようでなによりです。 そのうち YouTube や記事化が予定されているので、今回観れなかった方は気長にお待ち下さい。 14ケースにわたる文化的負債のお話しをさせて頂いたので
This guide is a collaboration between:Katie Womersley, VP of engineering at Buffer. When I’m writing, you’ll see this: ● Juan Pablo Buriticá, VP of engineering at Splice. When I’m writing, you’ll see this: ▲ When we’re both writing, you’ll see this: ■ ▲ All teams past a certain size become distributed, whether across rooms, floors, buildings, cities, or continents. But tech is only starting to exp
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く