pmconf 2023 プロダクトと事業を無限にスケールするための最強のロードマップの作り方 / The Greatest Roadmap for Unlimited Scaling your Business and Products
プロダクトマネージャーカンファレンス 2023 Track A 15:35~ LIVE 50min プロダクトと事業を無限にスケールするための最強のロードマップの作り方 https://2023.pmconf.jp/session/zBfEEEcp 近年、多くのプロダクトマネジメントに関する書籍が執筆され、日本でもプロダクトマネジメントが定着しつつある。特に課題発見からMVPローンチ、PMFまでのプロセスは、アジャイル開発関連の書籍の拡充あって、充実してきていると言える。一方で、一度PMFを迎えたプロダクトを更に進化させるためのロードマップの作り方については、未だ確立した方法論があるとは言えず、世界中で議論が続いている。本セッションでは、従来のロードマップの課題と近年議論されている対策を振り返り、その上で、プロダクトと事業を無限にスケールするための新しい考え方を導入し、状況に合わせて変更可
CPOが開発する覚悟 〜コンパウンドスタートアップにおける、爆速の新規プロダクト開発スタイル〜
・各社において実態は様々ですが、プロダクトを開発する役割は分化と深化を繰り返してきました。 ・この流れは一定の合理性がありつつも、フェーズによっては役割を限定せず、覚悟をもった個人に集約させることが爆発力を生むという話をしていきます。 ・兼務をする開発スタイルがいかにプロダクトを良くしていくか見ていきます。
スクラムはロールプレイングゲーム！？『スクラムガイド』でルールを覚えて、Let's game！ | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
こんにちは。たむら＠認定スクラムマスター です。 今回は、先日社内で開発に関わる事業部側メンバー（ノンエンジニア）に向けてスクラムガイドの紹介を行ったので、そのことについて書こうと思います。 イントロ さて、弊社では前TechBlogにも書いた通りアジャイル開発（スクラム）に取り組んでいます。 世間を見回しても最早全く珍しいものではなくなりましたよね！ がっ、しかし！ そのバイブルとも言える『スクラムガイド』をいったいどれ位の人が読んでおり、且つ内容を理解しているのだろうか？とふと気になりスクラムで開発している社内チームメンバーに確認したところ、エンジニアでは半分くらい、ノンエンジニアでは９割近くは読んだことがないという結果となってしまいました。こ、これはヒドイ・・・。 とはいえ、スクラムはやっていても読んだことがあるって人は実は他社でも結構少ないのではないか？と思えます。また、読んでいた
![スクラムはロールプレイングゲーム！？『スクラムガイド』でルールを覚えて、Let's game！ | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/3208d1e37ba8773f9fa9165bc1b1015183834db9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2023%2F11%2Fs_ZMttXcLpam0-e1698805795471.jpg)
開発生産性を改善するためにやったこと
こんにちは、株式会社スマートショッピングでエンジニアリングマネージャーを担当しているleafです 先日開催された Findy Team+ Award 2023 にて組織別部門(50人未満の組織規模)とチーム別部門(レビューリードタイムが早い)を受賞することができましたので、Findy Team+ 導入から今までに取り組んだこと、今後の取り組みについてご紹介させていただきます 初めにやったこと 初期に取り組んだことは2点で、正確な現状把握と目標設定です 運用中のリポジトリに計測を導入したため、放置されたPRなどが残っており、開発状況に関係なく数値が上下することがありました そのため、対象リポジトリの放置PRなどを全て棚卸しし、どうしても制御できないPR(自動生成されるものや隣接チームの依存が大きいもの)に関してはタグを設定し除外することでようやく現状が把握できる状態となりました 目標設定に関
ストーリーポイントではなくアウトカムで開発速度を測る #LayerXテックアドカレ - LayerX エンジニアブログ
こんにちは。LayerX バクラク事業部 バクラクビジネスカード開発チームEMの @shnjtk です。新しいMacBook Proがとても気になっています。スペースブラックいいですね。欲しい。 この記事は LayerXテックアドカレ 13日目の記事です。前回は @itkq による 情報の流通性を上げコミュニケーションを活性化させるNotionデータベース でした。次回は @yossylx が担当します。 今回は、開発チームの開発速度をどのようにして測るかということについてお話します。 ストーリーポイントによるベロシティの計測 ストーリーポイント（SP）とは、アジャイル開発において、開発しようとするユーザーストーリーや機能、その他のタスクの大きさを表す見積もりの単位であり、タスク同士の相対値で表現されます。例えば「この機能はSP 3」、「この機能はSP 5」のように使われます。タスクの完了
エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう - yigarashiのブログ
プロダクト開発のアンチパターン プロダクトオーナー（PO）が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどいアンチパターンであると言えます。 ひとつには、仕様案を持って臨むPO側の精神的な負担があまりにも大きいやり方だからです。ちゃんとした仕事をしているPOならば、そもそも仕様案なんていう細かいところにたどり着くまでに、とてつもない量の不確実性を捌いてボロボロになっているのです。プロダクトのミッション、戦略、プロダクトゴール、ユーザーの課題、仮説検証の設計、MVPの特定、そういった大上段からのヘビーな分解を繰り返して、ようやくたどり着くのが具体的な仕様案なわけで、それを実装が難しいとか
この質問は言い換えると、マネージャー兼プロダクトオーナー、マネージャー兼スクラムマスター、マネージャー兼開発者のありなしです。 スクラムガイド2020では、スクラムチームの構造や説明責任に関する記述は以下のようになっています。 スクラムチーム内には、サブチームや階層は存在しない。 自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。 スクラムチームは、（略）プロダクトに関して必要となり得るすべての活動に責任を持つ。 スクラムチームは、自分たちで作業を管理できるように組織によって構成され、その権限が与えられている。 スクラムガイドでは、マネージャーという単語は登場せず、また個人のパフォーマンスや人事評価などについても一切触れられていません。 したがって、アジャイルやスクラムの原則や価値観を踏まえて、自分たちで答えを考えることになります。 それを踏まえた答えは、「基
限界集落化するIT業界？ - Qiita
はじめに 日本は2021年時点で高齢化率(65歳以上の高齢者の比率)が28.9%の超高齢化社会のようです。 そして、わたし達の勤める会社も高齢化が緩やかに進んで いると思います。意外と認識するのが難しいのですが、すべての人は生きているだけで年を取りますので、会社の構成員の平均年齢は毎年自動で上がります。 会社の高齢化は、IT業界の人口分布を調べると確認できそうです。 出典 : - IT 人材需給に関する調査 － 調査報告書：みずほ情報総研株式会社 レポートは出てきましたが、分かるような分からないような感じですね。 仕事の役割が変わりそうな年代で再集計してグラフ化してみましょう。 みなさんが仕事をしている周りの人達の年齢層はどのようなものでしょうか？ このグラフに当てはまっているでしょうか？ もしもそうであるとしたら、限界集落化が進行している可能性があります。 限界集落化 限界集落とは、人口
開発だけアジャイルな状況を越えて顧客のアウトカムにつなげる一歩/next step in agile development agile japan 2023
「めちゃくちゃ勉強してソフトウェア開発も、アジャイルな開発もできるようになってきた! ところがせっかくうまくできるようになったけど、顧客への貢献にはなかなか繋がらない…」こんな悩みををよく聞きます。 この10年間でスクラムなどのアジャイルに関する情報やノウハウは増え、社会的な理解も広がり、その結果アジャイルははじめやすく、習熟もしやすくなっています。開発チームは急速に学習し、能力が高められやすい状況にあります。 ところがプロダクト価値の観点から見ると、開発チームも社内の他部署も、そして顧客も不満を持っていることがあります。せっかくアジャイルな活動ができるようになっても、プロダクト価値に繋げるまでにいたっていないことが多々あります。 本セッションでは、プロダクトという観点からアジャイルを捉え直し、開発チームや社内の他部署、顧客も満足するためのお話をします。 プロダクトマネジメントなど過去の登
Autonomous Database - Dedicated 技術詳細 / adb-d_technical_detail_jp
こんにちは、角田です。 今回はスクラムでの失敗談です。 PBIへ取り掛かるタイミング みなさんは、プロダクトバックログアイテム（PBI）へ取り掛かるタイミングはいつでしょうか？DROBEでは以前は、 スプリントバックログへ移し、スプリントが始まったら でした。一見正しそうなのですが、肝心なことを見落としていたため、効率的にデリバリーできない状態になっていました。 遅かった影響範囲調査 というのも、スプリントバックログへ移しスプリントが始まった後で、影響範囲の調査や該当箇所の洗い出しをしていました。この影響範囲調査や該当箇所の洗い出しにより、スプリント内での作業時間が圧迫された結果、非効率になっていました。 ディスカバリー不足だった この時のPBIは、ほぼ『やることリスト』化していたのが大きな原因ではないかと思っています。PBIを作る際に、開発チームとPBI作成者とのコミュニケーションが不足
レガシーコードから始まったカイゼンの旅 ─ チームから全社へと 組織を超えて広がった先にある新しい挑戦 - Findy Engineer Lab - ファインディエンジニアラボ
こんにちは！ いきいきいくお（小田中育生、@dora_e_m）です。現在、株式会社カケハシにエンジニアリングマネージャーとして所属しています。カケハシにジョインしたのは2023年10月で、それまでは長い間、株式会社ナビタイムジャパンに所属していました。 ここ数年はアジャイルコミュニティで発信する機会が多いため、「アジャイルの人」という印象があるかもしれません。2011年に書籍『アジャイルサムライ』と出会い、2017年頃から本格的にアジャイル開発に取り組み始め、アジャイルコミュニティにも参加するようになりました。2020年には『カイゼン・ジャーニー』の著者である市谷聡啓さんや新井剛さんとともにアジャイルの入門書『いちばんやさしいアジャイル開発の教本』を執筆する機会にも恵まれました。 私がアジャイル開発に取り組み、その活動を広げてきた原点は「目の前にある課題を解決したい」「よりよい状態へとカイ
ヤフーの会長から、東京都の小池百合子知事のオファーを受けて2019年に都庁入りし、今秋に2期目に入った宮坂学副知事（56）。Wi-Fiがないほど「原始時代」だったというオフィスからファクスをほぼ追放するなど、巨大組織・都庁のデジタル化を一気に進めた。子1人に月5000円を給付する「018サポート」の申請サイトについて寄せられる不満のコメントに、職員らと目を通しながら改善策を探り続けていることなどを紹介し、ユーザーである都民とともにデジタルサービスを成長させようという思いを語った。（渡辺真由子） 宮坂 学（みやさか・まなぶ） 1967年生まれ。1997年ヤフー入社。2012年に社長、2013年にソフトバンク取締役、2018年からヤフー会長。東京都参与を経て、2019年9月から都副知事。 Q 副知事就任のきっかけは A（宮坂氏） もともとは都庁には営業に行く側だったんです。自動車中心の社会から
Chatworkで活躍中のid:daiksyさんを訪問 | はてな卒業生訪問企画 [#6] - Hatena Developer Blog
こんにちは、エンジニアリングマネージャーの id:onkです。 Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の id:onishi、CTOの id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。 id:onkが担当する第6回のゲストは、ビジネスチャット「Chatwork」などを提供するChatwork株式会社でエンジニアリングマネージャーとして活躍されている id:daiksyさんこと、粕谷大輔さんです。 SIer、フリュー株式会社を経て、2014年はてな入社。2021年の卒業までサーバー監視サービス「Mackerel」の開発チームで、エンジニア、サブディレクター、最後はディレクターを務めるとともに、はてなにおけるスクラム開発の浸透に
![Chatworkで活躍中のid:daiksyさんを訪問 | はてな卒業生訪問企画 [#6] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/bb8b2204cb3b035d86c5528e05b99a963c5fc80a/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20230901%2F20230901181038.jpg)
アジャイルやスクラムに関するよくある質問
アジャイルコーチングや各種トレーニングの際によく聞かれる質問についてまとめました。 なお、内容については十分注意を払っておりますが、有効性等は状況によって変わります。お客様の自己責任にてご利用ください。 https://assets.attractor.co.jp/wp-content/uploads/2023/11/0098.webp 675 1200 admin https://assets.attractor.co.jp/wp-content/uploads/2019/12/logo_attractor_medium-300x138.png admin2023-11-10 21:00:162023-11-11 22:16:21Q. プロダクトバックログアイテムはいつ見積もればいいですか？ https://assets.attractor.co.jp/wp-content/upload
こんにちは。Gaudiyでソフトウェアエンジニア兼スクラムマスターをしている Namiki ( @ruwatana ) です。 「チームが向き合う不確実性が大きいと手戻りが増えて価値提供のリードタイムが遅くなる」 「チーム内の心理的安全性の低さや認知負荷の高さによってエンゲージメントが低下して従業員がオンボード・定着しにくい」 ... などなど、昨今のチーム開発はこうした課題で溢れかえっていることかと思います。 結局のところ、我々は具体的にどんなプラクティスを行うことで、こうした課題を解決できていくのでしょうか？ 本稿では、筆者と筆者が4ヶ月ほど前に配属することになったチームがこうした問題に対して執ったアプローチおよびその効果をより具体的に示すことができればと考えています。 プロダクトチーム開発を行う皆様に何かしらの参考になれば幸いです。 1. チーム構成と特性 2. 特性が生み出しうるリ
現代社会は多くのものがソフトウェアで成り立っており、絶えず変化するニーズに応じられる柔軟でスピーディな開発が求められている。その一方、何が正解（ゴール）なのかがわからない、という不確実性の時代でもある。不確実性に対処するには「アジャイル開発」が最も有望だが、その成功裏の実践には、従来の常識の解体と再構築が必要である。アジャイル開発の実践方法を、理論、課題、動向も踏まえ、実例を交えながら幅広く解説する。
「アジャイル型価値開発」という言葉をはじめよう
この数年は、「探索」と「適応」の必要性をひたすらに訴え、その実践に向けて組織に動いてもらう、そのためのあらゆる支援を行う、ということに取り組んできた。「探索」と「適応」という言葉が決して、伝統的な組織に馴染むわけではないが、他に言いようもなく、この言葉を押し通してきた。 正直なところ、探索適応という概念の普及は端緒についたばかりである（ついていると思いたい）。「探索適応がいかに伝統的な組織の現有ケイパビリティや指向性と合わないか」ということを数々の機会で語ってきたが、その必要性についてはもはや確信の域を超えている。「効率への最適化」に最適化していた組織が、かえって目の前のことに、顧客の声に対応できなくなっている、「非効率での安定化」に至っているこの現状を突破するには？ 「探索適応」という手がりは小さな、小さな「希望」になりうる。 探索適応を組織に宿すためには何かしら拠り所が必要だ。そこで、
AccelerateとState of DevOpsをもとにした、DevOps問題意識の移り変わり - Kengo's blog
Accelerate 第1版（以下単にAccelerateと呼ぶ）はDevOpsに関するトレンドを抑えるうえで基本となる本なのですが、もはや古く最新の知見が書いてあるとは言えません。State of DevOpsは毎年アップデートされているのですがコンテキストを丁寧には抑えてくれず、背景を含めて読み解くのが難しいという印象があります。どうもAccelerate 第2版がそろそろ出るらしいんですが、とりあえず現時点での自分の理解をまとめておきます。 端的に言うと、これらは安定したソフトウェアを高速に顧客に提供できる良い開発チームの特徴を踏まえ、皆さんの組織で再現可能にするための研究であり指針です。当然「良い開発チームがあれば常に良い問題解決ができる」というわけでも「ここで定義された良さが組織問わず普遍的である」というわけでもありませんが、顧客の課題に立ち向かうための組織設計において良い仮説を
株式会社ウェイブでCoolmicのエンジニアをしている山﨑です。Coolmicエンジニアチームのマネージャーもやってます。 我々のチームではスプリントレトロスペクティブとしてKPTAによる振り返りを実施していますが、今回それとは別に「象・死んだ魚・嘔吐」を用いた振り返りを実施してみました。 「象・死んだ魚・嘔吐」とは ネガティブな話題にフォーカスする振り返り手法で、何がうまくいっていないのかを浮き彫りにします。 🐘 象(部屋の中の象): 誰もが認識しているが口に出さない問題 🐟 死んだ魚: 放っておくと大変なことになる問題 🤮 嘔吐: 胸の中に秘めている問題 なぜやろうと思ったか KPTA（特にP）や日々のコミュニケーションの効果をより高めるためです。 私達のチームの心理的安全性はそれなりに高いと思っていますが、社歴の浅いメンバーが多いためどうしても遠慮が出てしまったり、みんな優しく
2023-11-02 JaSST'23 Kyushu 招待講演 https://www.jasst.jp/symposium/jasst23kyushu.html 実装完了後の手動テストに依存した開発サイクルに継続的テストのアプローチを適用し、段階的に品質を向上する方法について説明しています。
はじめに こんにちは、プレックスの池川です。 2023年2月に「DevOpsの指標を開発の振り返りに活用しはじめた話」という記事をこのブログに投稿して、はや10ヶ月。10ヶ月の間に振り返りのやり方も変わってきました。 product.plex.co.jp そこで今回の記事では、振り返りのやり方が10ヶ月前と比べて何がどう変わったのかを紹介したいと思います！ 目次 はじめに 目次 エンジニア組織について プレックスジョブ開発チームでの振り返り 振り返りMTGについて KPTについて 開発のパフォーマンス改善について エンジニア全体での振り返り さいごに エンジニア組織について 振り返りについて紹介する前に、プレックスのエンジニア組織について簡単に紹介します。というのも、振り返りの方法を見直すきっかけが「エンジニア組織の拡大」だったからです。 プレックスの開発体制は下記の画像のような事業部制を
東北を中心に、多い時には10近い店舗網を持っていた、CD/DVD販売及び書籍販売店のチェーン「スクラム」ですが、10月22日に宮城県大崎市の古川店の閉店をもって全店舗閉店、屋号が消滅しておりました。 （大河原店）1983年に当時の宮城県泉市に出店、以降各地で開店したり閉店したりで以下のような感じ。 泉店（宮城県・1983-2003） 香寺店（ブックバーン）（兵庫県・1988-1991） 大河原店（宮城県・1995-2022） 古川店（宮城県・1999-2023） 東根店（山形県・2002-2016）☆ 富谷店（宮城県・2003-2015）☆ 札幌桑園店（北海道・2004-2009）☆ 元町店（北海道・2004-2007）☆ 利府店（宮城県・2005-2016）☆ 盛岡南店（岩手県・2006-2009）☆ 発寒店（北海道・2006-2008）☆ 石巻店（宮城県・2007-2016）☆ 仙台中
こんにちは、CX事業本部デザインチームの小峰です。 先日、Agendというメディアさんからインタビューいただきました。 仕事のすれ違いを「ただ、話す」で解決していく、スクラムから学んだチームコミュニケーション―――――クラスメソッド小峰さんインタビュー この中で「ただ話す」を紹介しています。 今回は、これについて少し深掘ってみます。 これを知ったのはインタビューでもお話した通りLeSS Frameworkがきっかけでした。複数チームによるアジャイル開発体制を検討している中で出会いました。いわゆる「大規模アジャイル」の一種です。 「ただ話す」は、大規模アジャイルの学習のために「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法」という本を購入し、そこで紹介されていたものになります。 調整と統合 スクラムガイドでは主に1チームでのスクラム
軽くリファインメントをする時間 いまのチームでは、デイリースクラムのあとに毎日15分だけ、軽くリファインメントをする時間をとっている。目の前のスプリントのタスクのことをいったん忘れて、次のスプリントやもう少し先のことについてチームで相談する時間。 そこでは、PdM（プロダクトマネージャ）が「こういうこと考えてるんだけどどう思う？」って話をしてくれたり、エンジニアが「このあたり早めに改善しておきたいんだよねぇ」って話をしたりしている。 こういう軽い相談の場とは別に、もっと深く議論したいと思ったり、要件がかっちりと決まってきたりしたら、別途時間をとって、軽くないリファインメントでしっかりと相談している。 軽いリファインメントが結構好き 僕はこの日次の軽いリファインメントが好き。自分の「技術的な部分の改善をしたい」という考えをふわっとしてる段階で聞いてもらえるし、PdMがプロダクトの機能追加や改
「世界一流エンジニアの思考法」は強いエンジニアの習慣がいい感じに言語化されていてよかった件 - Lean Baseball
界隈で話題になっている（と私は認識している）「世界一流エンジニアの思考法」を早速読んでめちゃくちゃ良かった, とにかく人に勧めたいぞ！ という現役エンジニア（私）による書籍の感想エントリーとなります. 話題の本めちゃ良かったです. このブログを書く数日前にkindleで買って読む→めちゃいいやん！→紙版も買う←今ここ ってぐらいすごく良かったです*1. 世界一流エンジニアの思考法 (文春e-book) 作者:牛尾 剛文藝春秋Amazon 何が良かったか一言で言うと, 「強いエンジニアの習慣がここまでいい感じに言語化されている！！！」 という所ですね, 割と余すところなく詰まっていると思いますし, 一つ一つのTipsは再現性もあると思います（真似できるかどうかは別として真似は可能*2）. そんな「世界一流エンジニアの思考法」の感想を手短に書きます, 気になる方はお付き合いください. TL;D
「アジャイルソフトウェア開発という概念」の源流は日本なのか 〜『日本企業はなぜ「強み」を捨てるのか 』を読んで〜 - bonotakeの日記
夜中におもむろに書評を書き出す第2段。 日本企業はなぜ「強み」を捨てるのか～増補改訂版『日本“式”経営の逆襲』～ (光文社新書) 作者:岩尾 俊兵光文社Amazon この本自体はとても面白いし首肯できる部分も多いが、1箇所だけイチャモンをつけたい。 そもそもアジャイルソフトウェア開発という概念自体、マニフェスト（注：アジャイルソフトウェア開発宣言のこと）の発表よりも3年早く、1998年に日本の研究者から提案されている。 南山大学の青山幹雄教授による一連の研究である。 （同書より引用） ここで紹介されている「1998年」の「提案」とは、おそらくICSE1998で青山先生が発表した論文 "Agile Software Process and Its Experience" のことだろうと思う。Agile Software Process（ASP）という、実際に富士通の社内で実践されたソフトウェ
私は牛尾剛と申します。米国でマイクロソフトのクラウドを開発するソフトウェアエンジニアをしています。私は過去にははてなで、今は note でブログを書いていますが、幸いなことに沢山の方々に読んでいただけることが多く、文藝春秋の山本さんから提案されてこの度本を出版させていただくことになりました。新著はブログの文章に大幅加筆をしてビジネス書として一から構成したものですが、背景にある思いをお伝えしたいと思います。今回は私がなぜこのようなブログ、そして書籍を書いているのかをブログに書いてみたいと思います。 実は自分にとってはブログや書籍を書いている理由はもしかすると自分の「復讐」かもしれません。とは言えこの「復讐」は日本で働くことがもっと楽しく、もっと幸せで、そしてプロダクティブになるようなポジティブな「復讐」です。 「のび太くん」みたいだった私 私は子供の頃から、運動も、勉強も何もかもできなくて自
キャッチアップ速度が速い #とは
2023年10月 LayerX全社朝会資料より
ブランド一覧はこちらこの記事を読んだ人が他に読んだ記事試乗記ニュース画像・写真モーターショー自動車ヒストリー特集エッセイクルマ生活Q&AFrom Our StaffデイリーコラムCarScope谷口信輝の新車試乗水野和敏的視点池沢早人師の恋するニューモデル思考するドライバー山野哲也の“目”あの多田哲哉の自動車放談webCGプレミアム記事一覧webCGプレミアムプランとは日刊！名車列伝動画ギャラリープレゼントアウトビルトジャパンニューモデルSHOWCASE失敗しない中古車選びカーマニア人間国宝への道エディターから一言カーテク未来招来マッキナ あらモーダ！読んでますカー、観てますカーおすすめの動画小沢コージの勢いまかせ!!リターンズ自動車保険 トヨタレクサススバルマツダスズキダイハツホンダ日産三菱ポルシェメルセデス・ベンツアウディBMWMINIフォルクスワーゲンボルボルノープジョージャガーアル
「引き継ぎできない！」から始まった私のスクラム - 川口恭伸の「はじめてのアジャイル」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。川口恭伸（@kawaguti）と申します。 私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。 また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの
KPTは「チームの力で問題を見つけるふるまい」の養成ギブスです。 ふるまいに慣ていない間は違和感があります。 たとえば次のような問題が起きます。 トライ狙いすぎ問題 KPTの「改善活動」の面に強く期待しすぎて生じる問題です。 無意識に、KPTの成功指標を「TRYの数」にします。 TRYを出すことに意識をとらわれると、慣れている「個人で問題を見つけて解決する」方法を取ることがあります。一つのKPTの場に集まって、参加者がそれぞれ別々に問題を発見して解決します*1。 すると、途中のプロセスが無駄に見えると思います。特にKeepに意味を感じないのではないでしょうか？アイスブレイクの一緒だと思ってはいませんか？たとえばKPTの参加者にKeepを出していない人が居ても問題ないと思っていませんか？あるいは、時間短縮のため事前にKeepやProblemを用意していませんか？ KPTをK→P→Tの順に進め
【資料公開】プロダクトマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2023年10月17日に行われたオンラインイベント「プロダクトマネージャーのしごと - Forkwell Library #33」の登壇資料を公開します。 内容は、新刊書籍『プロダクトマネージャーのしごと』に関するものなのですが、30分という時間で全部を網羅的に紹介するのは無理ですし、ぜひ本書を読んでいただきたいので、僕が気に入っているところと、本書全体を通して中心にある考え方を紹介しました。 ちなみに書籍は16章から構成されていて、そのなかで特に自分が好きなのは「7章 「ベストプラクティス」のワーストなところ」です。 職業柄、日頃から「プロダクトマネジメントではどんなフレームワークを使うといいですか？」「プロダクトマネジメントの日本での成功事例を教えてください」「プロダクトマネジメントのベストプラクティスを教えてください」のような質問をたびたびい
開発生産性、上から見るか 下から見るか / development productivity and cognitive science
Another works社が主催した Developers Meetup 急成長ベンチャーが向き合う「開発生産性」 というイベントでの登壇資料です https://anotherworks.connpass.com/event/294517/ SmartHR基本機能というプロダクトにおいて取り組んできたことを認知科学の観点から見てみる、というお話でした。
スクラムから学ぶチームコミュニケーション―――――仕事のすれ違いを「ただ、話す」で解決していく、クラスメソッド小峰健範さんインタビュー Amazon AWSの技術支援を中心とした事業を行い、様々な技術情報の発信でも有名な株式会社クラスメソッド。 今回はCX事業本部Delivery部でデザイナーのマネージャーをしている小峰さんに、ミドルマネージャーとしてのコミュニケーションスタイルやチーム内スクラムの事例についてお聞きしました。 記事中に専門的な用語なども出てきますが、そこを読み飛ばしながらでも読んでいただければ、チームが活発になるヒントや仕事におけるコミュニケーションの勘所がつかめる内容になっていると思います。 どうぞ最後までお読みいただけましたら幸いです。
SAFe（セーフ、Scaled Agile Framework）は大規模向けのアジャイル開発フレームワークである。ソフトウエア開発だけでなく組織活動にまでアジャイル開発の考え方を拡張していることが特徴だ。ここでの組織は、製品やサービスを開発する事業部門から最大で企業全体までを想定している。 最新版の「SAFe 6.0」が2023年3月に公開された。日本でもNTTデータグループや富士通、NEC、オージス総研、TISといったIT企業などが企業に対して導入支援をしている。デジタル変革（DX）を推進する企業が増える中、事業やサービス開発のスピードを向上させる手法として注目を集めている。 20年間でビジネス向けに進化 SAFeが作られたのは2011年ごろ。米IBMに買収されたソフト会社のRational Software（ラショナルソフトウエア）でシニアバイスプレジデントなどを務めていたディーン・レ
location_city Tokyo schedule Jan 10th 04:15 - 05:00 PM JST place 2F Main Hall EAST奥 (126) people 99 Interested ★★★Deep Diveシリーズ第4弾!!★★★ Deep Diveシリーズでは、主にスクラムを始めたばかりの人、実践しているもののこれでいいのか？と不安を持っている人に向けに、スクラムやスクラムに関連する要素を詳細に解説しています。 これまで以下の3つをお届けしてきました。 プロダクトバックログ Deep Dive（https://slide.meguro.ryuzee.com/slides/107） スプリントプランニング Deep Dive（https://slide.meguro.ryuzee.com/slides/111） スプリントレビュー Deep Dive
なんちゃってスクラム実践者が CSM 研修を受けて痛感したこと（RSM と CSM の違いを添えて） - Qiita
はじめに 9月20日から3日間、株式会社アトラクタ主催の認定スクラムマスター研修 （Certified ScrumMaster） を受講しました。 一言でいうと、「レビュー・フィードバックの大切さをとても実感できる研修」でした。 いろいろ心に残ったことがあったので、参加レポートという名の自分用備忘録を書きます。 経緯 私は 2022 年に Scrum Inc. が提供する認定資格スクラムマスター研修 Registered Scrum Master® Training を受講しました。 その経験を基に、チームにスクラム勉強会などを開催し、スクラムを実践してきました。 しかし、所々でうまくいかず、時間が経つにつれ妥協した結果の自己流スタイルになっていき、以下のような課題を抱えるようになりました。 見積もりをしていない そもそも見積もりをできるまでバックログのリファインメント（分割・詳細化）をし
スクラムチームのパフォーマンスを測定したいと思ったら
みなさんこんにちは。@ryuzeeです。 スクラムチームのパフォーマンスを測定したいとステークホルダーに言われて悩んでいるスクラムマスターは多いと思います。 今回は、スクラムチームのパフォーマンスはどうやって測ればいいのか、何を気をつけるといいのか考えてみましょう。 具体的なメトリクスについては、別の記事で触れる予定です。 測定には目的が必要 ソフトウェア開発に限らず、何かを測定しようとするときには目的が必要です。 目的がないと、リソースがムダになったり、意思決定が難しくなったり、データをめぐって混乱が発生したりするリスクが高まります。 やりたいこと、やらなければいけないことは、だいたいやれる量よりも多いですが、そんな状況で限られた時間や資源を有効に活用するためには、測定が意図する目標とその結果の具体的な活用方法を明確に設定しなければいけません。 「いや、でもいずれ使うかもしれないので、何
依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。 機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手で、様々なタスクが実行されます。その全てを1つのチームで完結することは、プロダクトの規模が大きくなるほど困難になり、より多くの人々が関わるようになります。そこに、チーム境界を越えた「依頼、調整、合意、承認」といったコミュニケーションが発生するのです。 開発フローのクリティカルパスを悪化させるこのようなコミュニケーションの頻度をどれだけ減らせるか。組織設計、チーム設計で最も注視すべき観点の1つは、そこ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムチーム内にマネージャー（評価者）がいてもいいですか
スクラムマスターやマネージャーのための信頼構築につながる傾聴の技術
プロダクトバックログアイテムに取り掛かるタイミングを勘違いしてたはなし - DROBEプロダクト開発ブログ
都庁は「原始時代」だった 元ヤフー会長・宮坂学副知事が語るデジタル化の現在地と展望：東京新聞 TOKYO Web
不確実性や心理的安全性に向き合い自己組織化するチームを作る実践プラクティス
不確実性の時代に、アジャイル開発で向き合っていこう - ZDNET Japan
「象・死んだ魚・嘔吐」フレームワークでチームの心理的安全性を強化する
テスト自動化から、 開発を支える継続的テストへ
【DevOps】開発の振り返りをアップデートした話 - PLEX Product Team Blog
「スクラム」が消滅していたこと - WASTE OF POPS 80s-90s
チーム間の調整テクニックのひとつ「ただ話す」 | DevelopersIO
お願いしなくても毎日その場がやってくる良さ - Mitsuyuki.Shiiba
かつて「のび太君」だった私からの復讐 新刊『世界一流エンジニアの思考法』に込めた思い｜牛尾 剛
ウーブン・シティよ、どこへいく？ ――トヨタが描いた壮大な夢のしまい方 - webCG
KPTでトライ狙いすぎ問題 - @ledsun blog
スクラムから学ぶチームコミュニケーション―――――仕事のすれ違いを「ただ、話す」で解決していく、クラスメソッド小峰健範さんインタビュー
アジャイル開発の考え方を企業全体に適用する「SAFe」、DXで注目集める
ベロシティ Deep Dive - Regional Scrum Gathering Tokyo 2024
チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する｜mtx2s