アジャイル開発がうまくいっていない気がするというチームに確認すべきこと
みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります（内容が具体的になっていればもう解決までそう遠くありません）。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの？」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません（その場合は適宜用語を読み替えてください）。 確認ポイント いきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか？」 です。この確認をしないうちに「スクラムイベントは全部やっているか？」とか「プロダクトバック
(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book
本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl
プロダクトマネジメントを学ぶための推しの書籍
プロダクトマネジメントを学びたい人、プロダクトマネージャーにおすすめの書籍です。 以下、記載した書籍のリストです ## Product Management ### プロダクトマネジメントを広く理解する 「プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける」オライリージャパン (2020/10/26) https://www.amazon.co.jp/dp/4873119251/ 「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで」翔泳社 (2021/3/3) https://www.amazon.co.jp/dp/4798166391/ 「INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント」日本能率協会マネジメントセンター (2019/11/1) https://www.amazon.co.jp/dp/4
PdMと事業開発って結局何が違うんや - estie inside blog
はじめまして！estie（エスティ）取締役の束原です。 現在私は10名程度のチームで新規事業の立上げに奔走しているのですが、本記事ではその中で発生した問いと学びについて書いてみました。 元は社内向けに書いた記事ですが、現在PdMや事業開発、事業責任者をやっている方や、今後やっていきたい方の参考になれば嬉しいです。 この記事で分かること estieにおいてPdMと事業開発が2つ役割として存在する意味 サービス立上げや大規模な機能開発を行う際に、PdMと事業開発がestieで大切にして欲しいポイント 結論 「どこまでがPdMの仕事で、どこからが事業開発の仕事なのか」という問いに答えはなく、必ずしも仕分けすることはできない 従って、あらゆるチームに適用可能な責任範囲を予め設定する必要はなく、アサインされる人の得意分野によって流動的に設定すれば良い 事業の立上げやグロースには、「リーダーシップ」と
プロダクト系議論をチームでするときのコツ｜小城久美子 / ozyozyo
「プロダクトビジョンを定めたい！」しかし、一人で考えても浸透しないし、人を巻き込んで抽象度の高い議論をするのも難しいし…という方に向けて、最近気づいたコツを言語化してみます。 ✅ 重要な議論ほど人数を絞る。MAX5人。「ビジョンは重要なので各部署から代表者を集めて…」などとしているとあっという間に大所帯になります。大所帯で議論はできないので、コアメンバーとレビューメンバーに分けて、議論はコアメンバーで進行しましょう。 リモートで実施する場合、議論の難易度が上がるのでコアメンバーはビデオを必ずONにして安定した回線を用意してもらいましょう。難しいメンバーはレビューメンバーになってもらいます。 ✅ 民主主義的な決定をしない！を共有する多数決での意思決定は最悪です。その会議の参加者の人数比率によって決まります。エンジニアとビジネスサイドの参加者のどっちが多いかで決めるのは意味がありませんし、意思
1億円を投資した、プロダクトリニューアルが失敗に終わった理由｜山田修 | Osamu Yamada
こんにちは。Micoworks代表の山田と申します。 私はこれまでに10年ほど会社を経営させていただいておりますが、多くの失敗をしてきています。 その中でも投資額として最も大きかった失敗が「採用管理システムのリニューアルプロダクトを潰してしまったこと」でした。 2,3年ほど前の話になりますが、リリースまでに1億円程度を投下しておりお金の損失はもちろんですが、BizやCSメンバーも多大なリソースを費やし、会社の成長を失速させてしまいました。 当時は「この時間を丸々MicoCloudに投下していれば、もっと成長していたのに、、、」と自分の未熟さを何度も悔いていました。 この話の真因は「非エンジニアの経営者が、プロダクト開発の工数や進め方を理解できていないままプロジェクトを進めてしまったこと」だったと感じています。 そこで備忘録を兼ねて、noteのテーマとして取り上げてみたいと思います。 ※テッ
絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ | LayerX
業務フローをなめらかにするために絡み合う複数プロダクトに、マイクロサービスならどう向き合うかの話です。LayerXのバクラクシリーズの話です。 完璧な設計＆アプローチとかではなく、現実にあったケーススタディとして、優しく見ていただけると幸いです。
半年でテック組織が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
保有ETHを全て売った男は何を考えているのか
USのクオンツヘッジファンドであるNumeraiのCEO、リチャード氏は、 数年前に26セントで買ったETHを約2,500ドルで全て売却した と2022年05月09日に自身のTwitterアカウントで公表しました。 このtweetは（本人によると、思いがけず）プチバズり、後日↓のyoutubeチャネルにてインタビューも行われました。 私自身は仮想通貨について限定的な知識しかないのですが、動画で語られた内容はとても面白かったので簡単にまとめておきます。 リチャードに同意する、同意しない、興味ない様々あるとは思いますが、hypeに踊らされず自分の頭で考え、行動することのできる同氏の意見は、仮想通貨に違和感を持っている人たちはもちろん、多くの人に対し刺さるものがあるかもしれません。 （注）自分の英語力の都合でまとめに間違いのある可能性があります。なるべく↑の一次情報をご覧ください。 Q & A
30人が参加するプロジェクトで桁違いのパフォーマンスを発揮するためのチームデザイン - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。シニアスクラムマスター（初めて名乗った！）の天野 @ama_ch です。開発本部に所属するアジャイルコーチとして、組織内を横断的に支援しています。最近は、 kintone フロントエンドリアーキテクチャ（フロリア）プロジェクトの支援に注力しています。 フロリアプロジェクトの概要はこちらの記事をご覧ください。 blog.cybozu.io 現在、フロリアには約30人のメンバーが参加して日々活動しています。チームの規模が大きくなると、コミュニケーションが難しくなり、効果的なチームワークを発揮するのがどんどん難しくなっていきます。フロリアでは、昨年後半頃からだいぶチームの規模が膨らんできたため、今年からチームを再編し4チーム体制に切り替えました。 今回は、フロリアが数十人規模でもチームワークを発揮するために、チームの設計や運用で意識しているポイントを紹介します。 目指している状態 最
SmartHRにおけるクロスファンクショナル実践例 - SmartHR Tech Blog
こんにちは！ SmartHRで開発したり、アジャイル推進したり、筋トレしたりしてるkouryouです。 SmartHRでは顧客の価値の最大化を目指し、日々開発プロセスの改善を行っています。 特に私の所属する基本機能のDチーム*1では、以前からクロスファンクショナルを強く推進しています。 本日はクロスファンクショナルとは何なのか？やってみてどんなメリットがあったのかをまとめました。 クロスファンクショナルとは スクラムガイドでは機能横断型と翻訳されています。 機能横断型というのは、エンジニアリング、デザイン、QAなど複数の職能（スキル）を持つことを表しています。 そして機能横断型という言葉は、チームに対して使われることが多いですが、個人に対しても使われます。(例: プロダクトエンジニアがデザインもできる、QAエンジニアがコードも書けるなど) SmartHRにおいてチームが機能横断型であること
事業開発者・プロダクトマネージャーが知っておくべきフレームワーク7選｜Shin
プロダクトマネージャーという仕事はビジネス・デザイン・エンジニアすべてのスキルが求められる総合格闘技のような仕事です。その分、やることも多く忙しくなりがち。 しかし、再現性の高いプロセスというのは仕事が変わってもそのまま活用できます。その代表例がフレームワークです。 今回は世の中に数あるフレームワークのうち、プロダクトマネージャー・事業開発者が絶対知っておいた方が良いと判断したものを厳選してみました。 プロダクトマネージャー向けフレームワーク4選1. Product Prioritization Frameworkhttps://www.product-frameworks.com/Gusto-Product-Prioritization.htmlこちらはもうプロダクトマネージャーであれば無意識に考えていてほしいくらいシンプル、かつ大事なフレームワークです。 expected：期待値の大き
全てのメンバーにアクセシビリティー研修を実施しはじめました + 研修資料を公開します - freee Developers Hub
こんにちは、 freeeでデザインシステムを作っていたりアクセシビリティーのいろいろをやっていたりする id:ymrl です。 freeeではfreeeアクセシビリティー・ガイドラインを策定して、誰でも使えるアクセシブルな製品開発ができるよう取り組んでいます。これまでも、開発者（エンジニア、プロダクトマネージャー、デザイナー）向けには実習を含むアクセシビリティー研修を行ってきました。 そしてこのたび10月から 対象を全新入社員向けに拡大 してアクセシビリティー研修を行うようになり、あわせて開発者向けの研修も内容を整理したので、今回はその紹介をします。 なぜ全員に研修をするのか これまでのアクセシビリティーの取り組みは、プロダクト開発を中心に進めてきました。「だれもが自由に経営できる統合型経営プラットフォーム」をビジョンに掲げている以上、まずは提供しているSaaSが誰でも使えるものになってい
小さな会社のPMになったあなたへ - Qiita
はじめに みなさんこんにちは！ チャットボットによる会話広告プロダクト『fanp』を開発する株式会社ZEALSで、プロダクトマネージャー（以下PM）兼エンジニアをやっている福本です。 今年はProduct Manager Conferenceの盛況などもあり、”PM”という職種についての世間の理解がより深まった一年だったのではないかと感じています。 しかし、そんな中で色々なPMの方とお会いして話をすると、会社のフェーズや業種によってPMの仕事内容に驚くほど違いがあることがわかります。 この職種の不定形さが、多くのPMの方々（僕含む）を苦しめているのではないでしょうか。 そこで今回は、PMの”役割”ではなく”実際の仕事”にフォーカスして、具体的なPMの仕事をみなさんにお伝えしていきたいと思います。 具体的には、「この記事をプロダクトと見立て、どのようにプロダクトを開発（記事を作成）しローンチ
正しくないものをつくらない。7つの失敗パターン
正しくないものをつくらない。7つの失敗パターン1. Toshihiro Ichitani All Rights Reserved. 正しくないものをつくらない Ichitani Toshihiro 市⾕聡啓 - サービスづくり7つの失敗パターン - 2. Toshihiro Ichitani All Rights Reserved. http://about.me/papanda0806 Ichitani Toshihiro 市⾕聡啓 ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ 0 → 1 3. Copyright (c) 2017 Guild Works Inc. 本⽇のテーマ のべ200本以上(推
初めて書くPRD（プロダクト要求仕様書）
今回はIncrementsでQiitaのプロダクトマネージャーを担当されている及川さんにお話を伺います。早速ですがQiitaの概要やサービスコンセプトについて教えてください。 Qiita ... 当時の記事は2017年のものですので、今では立場も変わられており内容もアップデートされていると思いますが、何を記載すべきかを以下に列記します。 1. 概要 2. 背景 3. 製品原則 4. スコープ 5. 対象ユーザー 6. ユースケース 7. 市場分析 8. 競合分析 9. 機能要求 10. UX要求 11. システム要求 12. セキュリティ要件 13. プライバシー要件 14. パフォーマンス要件 15. リリーススケジュール・マイルストーン 16. マーケティング計画 プロダクト・マネージャーは海外ではmini-CEOとも言われるように、市場分析やマーケティング計画などといったプロダクトの
CASHのユーザビリティを支える（泥臭い）技術
クラウドネイティブな省エネサービスの内製開発で、BizDevOpsを実現する / Achieving BizDevOps in in-house development of cloud-native energy-saving services
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクト開発における結果目標の功罪、そして状態目標へ
プロダクトのための地味な動き - 地味PM meetup
爆速で価値あるプロダクトをリリースするためのチームビルディング
