プロダクト開発における目標設定で陥りがちな罠とそれを回避する目標設定について
プロダクトマネージャーという仕事はビジネス・デザイン・エンジニアすべてのスキルが求められる総合格闘技のような仕事です。その分、やることも多く忙しくなりがち。 しかし、再現性の高いプロセスというのは仕事が変わってもそのまま活用できます。その代表例がフレームワークです。 今回は世の中に数あるフレームワークのうち、プロダクトマネージャー・事業開発者が絶対知っておいた方が良いと判断したものを厳選してみました。 プロダクトマネージャー向けフレームワーク4選1. Product Prioritization Frameworkhttps://www.product-frameworks.com/Gusto-Product-Prioritization.htmlこちらはもうプロダクトマネージャーであれば無意識に考えていてほしいくらいシンプル、かつ大事なフレームワークです。 expected：期待値の大き
イーロン・マスクが YouTube チャネルでスペース X のテキサス工場スターベースの中を歩き回りながらロケット製造や電気自動車について説明しているのを観た。ツイートしたこの件。 これがめちゃくちゃに示唆に富んでいて面白かった。この日のイーロン・マスクは饒舌で楽しそうなので、かなり魅入ってしまった。きっと彼はカンファレンスや会議室の中でインタビューを受けるよりも、工場でみんながロケット作ったり作業している場で語った方が情熱を込めていろいろ説明してくれるんだと思う。 この中で製造工程の話があって、これはロケット製造などの特定分野だけでなく、IT やその他の分野にでも当てはまる普遍的な知見だと思ったので意訳してみた。ざっとビデオを観て印象に残った部分だけを意訳した。あくまで大枠で言ってることをまとめただけなので、もし詳細に興味があればぜひビデオを観てイーロン・マスクの話を直接聞いて確認してく
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
質とスピード（2020春版） 2020/02/13 @ デブサミ2020
序章駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、迅速に開発できて、仕様変更にも対応できる、素晴らしい開発手法を取り入れてるところがあるらしいんやわ〜。」 内海「そんなもんアジャイルに決まってるがなぁ〜! 今やシステム開発と言えば、アジャイル。素早く変化に対応できるってゆーのが特徴なんよ。そもそも名前が “迅速” を意味する英語やねんから、アジャイルに決まってるがなぁ〜。」 チームの人数駒場「最初、オレもそう思たんやけどな、なんでも 40 人ぐらいで開発してるらしいんやわぁ〜。」 内海「ほなぁ、アジャイルちゃうかぁ…。アジャイルでは 5〜9 人ぐらいが推奨されてるからなぁ〜。40 人もおったら、とてもやないけど、コミュニケーションが成立するとは思われへんなぁ〜。効率の悪い伝言ゲームになるのは目に見えてるからなぁ〜。おかん、他にもなんか言うてなかった
by Austin Distel 「ひどいソフトウェアが生まれる場合、問題は特定のエンジニアリングではく、マネージメントにあることが多い」と語る、Googleのプロダクトマネージャーを経てシンガポールの公安部門向け技術開発を行うLi Hongyiさんが、「よりよいソフトウェアはどうやって構築するのか？」をつづっています。 How to Build Good Software https://www.csc.gov.sg/articles/how-to-build-good-software Hongyiさんは、ひどいソフトウェア開発の問題点を一文で「プロジェクトオーナーが解決すべき問題を明確にすることなく解決策としてのソフトウェア構築をスタートさせ、関係者からの長い要望リストを、フルスクラッチで開発を行おうとする外部の開発チームに委託すること」とまとめています。 一方で優れたソフトウェア開
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
ソフトウェア開発において、Todo、Doing、Doneを貼りつけた、シンプルな「かんばん」を使っている人は多いと思います。ただ、「リーンなかんばん」を使っている人は、まだまだ少ないでしょう。ここでいう「リーンなかんばん」とは、Kanbanという方法論で使われるツールです。 今回は、リーンかんばんの作り方について、Marcus Hammarberg氏の「Kanban in practice」という資料をベースに解説してみたいと思います。 用語について この記事では、わかりやすくするために、従来のかんばんとリーンかんばんをわけて表現します。また、かんばん上の縦の領域をステージ（舞台・段階）と呼び、横の領域をレーンと呼んでいます。 さらに、かんばんにはカードや付箋が貼りつけられます。カードと付箋の使い分けについては、また別の機会に整理したいと思います。
“なぜ納期を守れなかったのだろうか？” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？ Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと（S、M、L、XL）、また種類ごと（ストーリー、テスト、バグ）に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目：開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目：変動があるのは、ほとんどがチケットが開始される前（SomedayからBacklogまで）の段階です。これは、関係者が仕様を理解して作業の優先順位
※本記事は旧版です。最新版（2019年9月）はオフィシャルサイトからPDFをダウンロード可能です。 この作品は The Kanban Guide for Scrum Teams の翻訳です。クリエイティブ・コモンズ 表示 — 継承 4.0 国際 ライセンスの下に提供されています。 目的カンバンにおけるフローベースの考え方は、スクラムフレームワークとその導入を強化・補完する。チームがこれからスクラムを使う場合でも、これまで長年スクラムを使ってきた場合でも、カンバンは適用可能である。 この「スクラムチームのためのカンバンガイド」は、Scrum.orgのコミュニティのメンバーとカンバンのコミュニティのリーダーがコラボレーションして生み出した結果である。その両者が協力して「スクラムチームのためのカンバンガイド」を支援している。カンバンとスクラムを組み合わせれば、プロのソフトウェアの実践者が恩恵を受
この記事は Rakuten Advent Calendar 2016 の記事です。 こんにちは、アジャイルモンスターこと及部敬雄（@TAKAKING22）です。 現在は最近できたスタートアップの部署に所属しており、エンタープライズスタートアップの成功例をつくるべく、チームづくりからプロダクトマネジメントから越えられる壁はすべて越えるつもりで日々奮闘しております。 今日はカンバンについて取り上げてみます。 ペンと付箋があれば始められる オンラインサービスも数多く存在する アジャイル開発を取り入れているか否かに関わらずエッセンスを取り入れることが可能である など導入のしやすさから、今ではメジャーなソフトウェア開発手法の1つになっています。実際に皆さんの現場でもカンバンを運用している、あるいはまわりで運用しているチームがいる方も多くいらっしゃるのではないでしょうか？ 楽天でも、私がカンバンを始め
Henrik Knibergさんのブログで「One day in Kanban land」という記事を見つけました。そこでは、かんばんの使い方のポイントがうまく描かれたマンガが紹介されています。各国語に訳されているので、ヘンリック氏に許可をいただき、日本語訳してみました。 赤い人がプロダクトオーナー（PO）の役割で、青い人たちが開発チーム（DEV。ここでは2名ずつ2チーム）、緑の人がテスターだと思います。テスターチームはデプロイまで担当しているみたいですね。 また、「TODO」「開発」「デプロイ」という各ステージにはWIP（Work in Progress：仕掛り作業）が制限されています。WIP制限とは、各ステージにWIPの数以上のカードを貼ることができないというルールです。
これまでの「カンバン」の課題週一で行っているプロセス改善委員会にて、いくつかカンバンV2に関する課題点などがエンジニア・POなど職種問わずあがるようになりました。いくつか代表的な課題点についてまとめます。 「エピック」「ストーリー」など言葉の定義から認識がバラバラで、チケットの大きさがわからないカンバンV2では、各ストーリーやタスクなどを紐付ける大きな単位として「エピック」を定義し各エピックごとに横軸のレーンを用意、それぞれのレーンの中でストーリーやタスクなどを動かし、プロジェクトのステータスを表していました。 しかし、運用していくにつれ、各チーム間でエピックやストーリーとして言われているものの粒度がバラバラに・・。エピックとして扱うものがストーリーとしてカンバン上に鎮座し何週間も動きがないチケットがあったりと、それぞれのプロジェクトチームごとに異なる粒度でチケットが定義されていました。
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 WIPの制限についてExplaining why Limiting WIP is so importantにて良い説明があったのでご紹介します。 ※図は上記サイトより引用 1. WIP(仕掛り中)の同時許容個数を減らす個人的には1開発者が同時に着手するタスク数は1〜2個であるべきと思っています。 したがって、WIPが「2 * チーム人数」より多いのは実質的に制限がなされていないことになってしまい効果が出ないかもしれません。 現実的に何個にするのかは仕事の内容やチームの人数に依存するので、運用しながら順次見直していけば良いでしょう。 ただし安易に数値を増やすことは慎むべきです。 2.
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く