解説記事
組織的創造性を覚醒させる「揺さぶり」の質問
1. 序論：不確実性時代における「問い」の戦略的機能現代の組織運営において、リーダーシップの機能は「正解を提示すること」から「適切な問いを投げかけること」へと劇的な転換を遂げている。経営環境の複雑性が増し、過去の成功モデルが通用しない「乱気流」の時代において、既存の論理的帰...
リーン・バリュー・ツリー（LVT）
企業にも個人にも「ありたい姿」がある。だが、願いや努力だけでは戦略にはならない。リーン・バリュー・ツリー（Lean Value Tree: LVT）は、そのビジョンを実現可能な形に落とし込み、意思決定と投資を一貫して導く仕組みである。ThoughtWorks社の著書『EDG...
顧客フィードバックの流れを作る
顧客フィードバックは、集めるだけでは価値になりません。営業、カスタマーサクセス、サポート、プロダクト、開発に分散した声を、意思決定に使える形で流す必要があります。よくある状態は、声が多すぎて逆に見えなくなることです。要望リストは増えるが、どの顧客のどんな状況で起きた問題なの...
プラットフォームチームの考え方
プラットフォームチームは、他のチームが価値提供に集中できるように、共通基盤や開発体験を提供するチームです。単にインフラを管理するチームではありません。よいプラットフォームは、利用チームの認知負荷を下げます。環境構築、デプロイ、監視、認証、権限、ログ、セキュリティ対応などを、...
システムを変えるふりかえり
ふりかえりは、感想を共有する場ではありません。チームの働き方というシステムを少しずつ変える場です。もちろん、気持ちを出すことにも意味はあります。しかし、毎回「よかったこと」「困ったこと」を話して終わるだけでは、同じ問題が繰り返されます。ふりかえりの価値は、次の行動が変わるこ...
OKRとプロダクト戦略
OKR は、目標と主要な結果を結びつけるための仕組みです。プロダクト組織で使う場合、単なる目標管理制度として導入すると失敗しやすくなります。OKR が効くのは、プロダクト戦略とつながっているときです。どの顧客に、どんな価値を届け、どの事業上の変化を狙うのかが曖昧なままでは、...
アジャイルなガバナンス
ガバナンスという言葉は、アジャイルと相性が悪いものとして扱われることがあります。管理、承認、統制、監査といった印象が強いからです。しかし、ガバナンスが不要になるわけではありません。むしろ、変化の大きい環境では、適切なガバナンスがなければ組織は安心して権限委譲できません。アジ...
WIP制限はチームの集中を守る
WIP は Work In Progress、つまり仕掛かり中の仕事です。WIP制限は、同時に進める仕事の数を意図的に制限することです。一見すると、同時に多くの仕事を進めたほうが速く見えます。しかし実際には、切り替えコスト、待ち時間、レビューの滞留、優先順位の衝突が増え、完...
AI時代の2025年にPdMが読むべき5冊
5 Must-Read Books for Product Managers in 2025: Mastering AI and Productivityという記事がありました。そこに挙げられている5冊の本を紹介します。Reimagined: Building Produc...
意思決定を記録する
組織が大きくなると、意思決定そのものよりも「なぜそう決めたのか」が失われやすくなります。決定の背景が残っていないと、後から参加した人は同じ議論を繰り返し、過去の判断を単なる好みや政治として受け取ってしまいます。意思決定の記録は、会議録を詳細に残すこととは違います。必要なのは...
Team Topologies の最初の一歩
Team Topologies は、ソフトウェア組織をチームとチーム間の関係から設計する考え方です。組織図をきれいに描くことではなく、認知負荷を下げ、価値の流れをよくすることが目的です。いきなりチームタイプを当てはめる前に、まず見るべきものがあります。価値の流れを見る最初に...
Product Ops
Product Ops は、プロダクトマネジメントを組織としてうまく回すための機能です。個々のプロダクトマネージャーを助けるだけでなく、プロダクト組織全体の意思決定、データ活用、顧客理解、プロセスを整えます。プロダクトマネージャーが増えると、同じような問題が繰り返し起きます...
チームのメトリクス
ソフトウェア開発チームのパフォーマンスを表すメトリクスとして有名なものに「Four Keys Metrics」があります。 デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 変更のリードタイム - commit から本番環境稼働までの所要時間 変更障害率...
仮説としてのロードマップ
ロードマップは約束の一覧ではありません。未来に対する仮説の集合です。もちろん、組織には計画が必要です。営業は顧客と会話する材料が必要ですし、経営は投資判断をしなければなりません。開発チームも、次にどの領域へ向かうのかを知らなければ準備ができません。問題は、ロードマップを「決...
Opportunity Solution Tree
Opportunity Solution Tree は、顧客の機会と解決策をつなげて考えるための可視化手法です。Teresa Torres の継続的ディスカバリーの文脈でよく知られています。プロダクト開発では、アイデアがいきなりバックログに入ることがあります。「この機能がほ...
デュアルトラックアジャイル
デュアルトラックアジャイルは、探索（Discovery）と提供（Delivery）を並行して進める考え方です。開発チームがスプリントで実装している間に、プロダクトマネージャーやデザイナーが次に作るものを調べる、という単純な分業の話ではありません。本質は、作る前の不確実性と、...
プロダクトディスカバリーの基本ループ
プロダクトディスカバリーは、何を作るべきかを決めるための探索活動です。単なるユーザーインタビューでも、アイデア出しの会でもありません。顧客の問題、解決策の仮説、事業上の意味、実現可能性を行き来しながら、作る前に不確実性を下げる活動です。基本のループは、次の4つで考えると扱い...
アウトプットではなくアウトカムで見る
アジャイル開発でよく起きる誤解は、「たくさん作れるようになること」を目的にしてしまうことです。スプリントごとに多くのチケットを閉じ、計画どおりに機能を出し続けても、顧客や事業に変化が起きていなければ成果とは言えません。アウトプットは作ったものです。機能、画面、API、ドキュ...
15%ソリューション
組織にいる人が何かを変えようとしたときの影響力は限定されており、最大15%であるという研究が元になっている。残り85%はその他の要因で決まるが、わずか15%を変えるだけでも効果的な変化が訪れる可能性がある。100%を目指すと失敗するという意味でもある。 Morgan, G...
チャタムハウスルール
イギリスのチャタムハウス（王立国際問題研究所の本部）に由来する。会議の参加者は受け取った情報を自由に使用できるが、発言者の身元や所属、あるいは他の参加者の身元や所属を明らかにすることはできないというルール。参考 チャタムハウスルール - Wikipedia
ベガスルール
2003年にラスベガス観光局がキャンペーンとして発表したキャッチコピー「ベガスで起きたことはベガスに残る（What Happens in Vegas, Stays in Vegas）」に由来する言葉。ラスベガスで起きたことは秘密にしておきましょうという意味が転じて、会議で話...
戦略展開
戦略展開は、組織の戦略を現場の行動や学習につなげることです。経営層が方針を出して終わりではなく、チームが何を優先し、何を測り、何を学ぶかまで接続します。戦略が現場に届かない組織では、各チームがよかれと思って別々の方向に努力します。活動は多いのに、全体としての成果が出にくくな...
オペレーティングモデル
オペレーティングモデルは、組織が価値を生み出すための動き方を表したものです。組織構造だけでなく、役割、意思決定、プロセス、指標、技術、会議体、ガバナンスを含みます。戦略があっても、オペレーティングモデルが合っていなければ実行できません。顧客価値を素早く届けたいのに、意思決定...
変革疲れ
変革疲れは、組織が多くの変更や施策にさらされ続け、現場が疲弊している状態です。新しい制度、ツール、組織変更、目標、改善活動が次々に来ると、人は変化への関心を失います。変革疲れが起きると、「また始まった」「どうせ続かない」「現場を見ていない」という反応が増えます。これは抵抗で...
Go-to-Market
Go-to-Market は、プロダクトを市場に届け、顧客に使われ、買われる状態を作るための戦略です。プロダクトを作るだけでは、市場に届くとは限りません。GTM では、対象顧客、価値提案、価格、販売チャネル、マーケティング、営業、カスタマーサクセス、導入支援などをつなげて考...
ポジショニング
ポジショニングは、顧客の頭の中でプロダクトをどう位置づけてもらうかを設計することです。何のためのプロダクトで、誰にとって、どの代替手段より、なぜ良いのかを明確にします。機能が多くても、顧客が「これは自分の何を解決するものか」を理解できなければ選ばれません。ポジショニングは、...
セグメンテーション
セグメンテーションは、市場や顧客を意味のあるまとまりに分けることです。すべての顧客を同じように扱うと、誰にも強く刺さらないプロダクトになりやすくなります。分け方は、業種、規模、職種、利用頻度、課題、成熟度、購買プロセス、支払意思などさまざまです。重要なのは、プロダクト判断に...
ペルソナ
ペルソナは、顧客やユーザーの代表的な人物像を具体化したものです。年齢や職種だけでなく、目的、困りごと、行動、制約、判断基準などを含めます。ペルソナの価値は、チームが同じ顧客像を見ながら議論できることです。「ユーザーはどう思うか」という抽象的な会話を、「この状況のこの人ならど...
カスタマージャーニーマップ
カスタマージャーニーマップは、顧客が目的を達成するまでの体験を時系列で可視化するものです。認知、検討、購入、導入、利用、継続、問い合わせなどの流れを、顧客視点で見ます。ジャーニーマップの目的は、きれいな図を作ることではありません。顧客がどこで不安になり、どこでつまずき、どこ...
サービスブループリント
サービスブループリントは、顧客体験とそれを支える裏側の業務を一緒に可視化する方法です。顧客の行動、接点、フロントステージ、バックステージ、システムやプロセスを並べて見ます。プロダクトの問題は、画面上の体験だけでは説明できないことがあります。問い合わせ対応、審査、通知、社内承...
Blameless Postmortem
Blameless Postmortem は、障害や失敗の後に、個人を責めずに原因と改善策を探るふりかえりです。目的は責任追及ではなく、再発を減らし、システムを強くすることです。人を責めると、次から問題が隠れます。早く共有すべき兆候や判断の迷いが表に出なくなり、組織は学習で...
ガードレール
ガードレールは、チームが自律的に判断するための境界条件です。細かい承認や指示ではなく、守るべき原則、制約、判断基準を示します。自律性は、何でも自由に決めることではありません。予算、セキュリティ、法務、ブランド、品質、運用リスクなど、組織として守るべきものがあります。ガードレ...
システム思考
システム思考は、問題を個別の出来事ではなく、相互に影響し合う構造として見る考え方です。組織やプロダクトでは、原因と結果が単純な直線にならないことが多くあります。たとえば、リリースが遅い原因を「開発が遅い」と見るだけでは不十分です。優先順位の変更、承認待ち、テスト環境、技術的...
チームの境界
チームの境界は、どこまでをそのチームが理解し、判断し、責任を持つかを決める線です。境界が広すぎると認知負荷が高くなり、狭すぎると依存関係が増えます。よい境界は、価値の流れ、ドメイン、技術的な結合、運用責任を見ながら設計します。組織図の都合だけで決めると、実際の仕事の流れとず...
Stream-aligned Team
Stream-aligned Team は、特定の価値の流れに沿って責任を持つチームです。顧客、プロダクト、サービス、業務領域など、価値が流れる単位に合わせて作られます。職能別チームでは、ひとつの価値を届けるために多くの引き継ぎが必要になります。Stream-aligned...
Enabling Team
Enabling Team は、他のチームが新しい能力を身につけられるように支援するチームです。Team Topologies で定義されるチームタイプのひとつです。プラットフォームチームがサービスを提供するのに対し、Enabling Team は知識移転や能力獲得を助けま...
Architecture Decision Record
Architecture Decision Record（ADR）は、重要な技術的意思決定を短く記録する文書です。何を決めたか、なぜ決めたか、どんな選択肢を検討したか、どんな影響があるかを残します。システムが成長すると、なぜその技術や設計を選んだのかが忘れられます。背景を知...
技術的負債
技術的負債は、短期的な判断によって将来の変更や運用が難しくなる状態です。急いで作ったコード、十分でないテスト、古い依存関係、複雑な設計、属人化した運用などが含まれます。技術的負債は、すべて悪いわけではありません。学習のために短期的な実装を選ぶこともあります。問題は、負債を認...
バリューストリーム
バリューストリームは、顧客に価値が届くまでの一連の流れです。アイデア、意思決定、設計、開発、レビュー、リリース、運用、フィードバックまでをひとつの流れとして見ます。組織は部署や職能で分かれていますが、顧客価値はその境界をまたいで流れます。バリューストリームを見ると、どこで待...
Communities of Practice
Communities of Practice は、同じ関心や専門性を持つ人たちが、チームや部署を越えて学び合うコミュニティです。たとえば、プロダクトマネージャー、スクラムマスター、SRE、UXリサーチ、データ分析などのコミュニティがあります。組織がチーム単位で動くほど、知...
意思決定権
意思決定権は、誰がどの判断をする権限を持っているかです。組織では、責任は求められるのに決定権がない、相談先が多すぎる、誰が決めたかわからない、という問題がよく起きます。意思決定権が曖昧だと、スピードも納得感も下がります。会議は増え、判断は先送りされ、後から「聞いていない」が...
Delegation Poker
Delegation Poker は、権限委譲の度合いを話し合うための方法です。マネージャーが決めるのか、チームが決めるのか、その中間なのかを段階的に表します。権限委譲は「任せる」だけでは曖昧です。どこまで任せているのかが不明だと、チームは確認待ちになり、マネージャーは期待...
ワーキングアグリーメント
ワーキングアグリーメントは、チームが一緒に働くうえでの合意事項です。会議の進め方、レビューのルール、連絡手段、対応時間、意思決定の方法などを明文化します。暗黙の期待が多いチームでは、すれ違いが増えます。ある人は即レスを期待し、別の人は集中時間を大切にしているかもしれません。...
Team API
Team API は、チームが他のチームとどう関わるかを明示した情報です。Team Topologies の文脈で使われることが多く、チームの責任範囲、提供するもの、依頼方法、連絡先、期待する入力などを示します。チーム間の関係が曖昧だと、依頼の仕方、優先順位、責任範囲が毎回...
社会技術システム
社会技術システムは、組織を人やチームの社会的な側面と、技術やプロセスの側面が結びついたシステムとして見る考え方です。ソフトウェア開発では、ツールやアーキテクチャだけを変えても、働き方や意思決定が変わらなければ成果は限定的です。逆に、組織文化だけを語っても、技術的な制約が残っ...
コンウェイの法則
コンウェイの法則は、組織が作るシステムは、その組織のコミュニケーション構造を反映しやすいという考え方です。たとえば、フロントエンド、バックエンド、データ、運用が強く分断されている組織では、プロダクトにもその境界が表れやすくなります。ユーザーにとってひとつの体験でも、内部では...
認知負荷
認知負荷は、人やチームが理解し、判断し、扱わなければならない複雑さの量です。ソフトウェア開発では、ドメイン知識、技術、運用、調整、例外処理が認知負荷になります。認知負荷が高すぎると、チームは遅くなります。新しいことを学ぶ余裕がなくなり、変更の影響を読むだけで時間がかかり、特...
心理的安全性
心理的安全性は、チームの中で率直に発言しても対人関係上のリスクが過度に高くない状態です。仲がよい、優しい、衝突がない、という意味ではありません。心理的安全性が高いチームでは、ミスを早く共有し、わからないことを質問し、反対意見を出し、助けを求めることができます。これは学習速度...
機会費用
機会費用は、ある選択をしたことで失った別の選択肢の価値です。プロダクト開発では、何かを作るという判断は、別のものを作らない判断でもあります。チームの時間、注意、学習機会は有限です。小さな機能でも、設計、実装、レビュー、リリース、運用、問い合わせ対応が発生します。その間に、よ...
Impact Mapping
Impact Mapping は、目的から施策までのつながりを可視化する手法です。「なぜやるのか」「誰の行動を変えたいのか」「どのように変えるのか」「何を作るのか」を階層で整理します。基本の問いは次の4つです。 Why: どんなゴールを達成したいのか Who: 誰の行動...
Cost of Delay
Cost of Delay は、ある仕事を遅らせることで失われる価値です。単に工数が大きいか小さいかではなく、遅れるほど何を失うのかを考えます。たとえば、法令対応、障害につながる技術的負債、季節性のあるキャンペーン、競争優位に関わる機能では、同じ工数でも遅延の影響が大きく異...
RICE優先順位づけ
RICE は、Reach、Impact、Confidence、Effort を使って優先順位を考える方法です。プロダクトバックログや施策候補を比較するときに使われます。Reach は影響する人数や件数、Impact は効果の大きさ、Confidence は見積もりの確信度、...
A/Bテスト
A/Bテストは、複数のパターンを比較し、どちらが望ましい結果を生むかを検証する方法です。ボタン文言、導線、価格表示、オンボーディングなどで使われます。重要なのは、事前に仮説と成功指標を決めることです。「なんとなく良さそう」ではなく、「この変更で初回設定完了率が上がるはず」と...
コホート分析
コホート分析は、同じ時期や条件で集まったユーザー群を追跡して、行動の変化を見る分析です。たとえば、1月に登録したユーザー、特定キャンペーンから来たユーザー、ある機能を使い始めたユーザーを分けて見ます。全体平均だけを見ると、改善や悪化の原因が見えにくくなります。新規ユーザーが...
Pirate Metrics
Pirate Metrics は、AARRR とも呼ばれるプロダクト成長の見方です。Acquisition、Activation、Retention、Referral、Revenue の頭文字を並べたものです。顧客がプロダクトを知り、最初の価値を体験し、継続し、紹介し、収益...
North Star Metric
North Star Metric は、プロダクトが顧客価値をどれだけ生み出しているかを代表する指標です。チームや組織が同じ方向を向くための中心的なメトリクスとして使われます。よい North Star Metric は、売上だけでも、単なる利用回数だけでもありません。顧客...
Product-Market Fit
Product-Market Fit は、プロダクトが市場の強いニーズに合っている状態を指します。単にユーザーがいる、売上がある、機能がそろっているというだけでは十分ではありません。PMF に近づくと、顧客が継続して使い、周囲に勧め、明確な価値を感じ、販売や導入の摩擦が少し...
Jobs to be Done
Jobs to be Done は、顧客がプロダクトを「雇う」理由に注目する考え方です。顧客は機能そのものが欲しいのではなく、ある状況で達成したい進歩のためにプロダクトを使います。たとえば、タスク管理ツールを使う理由は「タスクを登録したい」ではなく、「チームの認識ズレを減ら...
プロトタイプ
プロトタイプは、アイデアや仮説を検証するための試作品です。完成品に近いものだけでなく、紙のスケッチ、クリック可能な画面、簡単なデモ、手作業の運用もプロトタイプになります。プロトタイプの価値は、早く学べることです。実装前に、ユーザーが理解できるか、操作できるか、価値を感じるか...
MVP
MVP は Minimum Viable Product の略です。学習に必要な最小限のプロダクト、または最小限の実験と考えると扱いやすくなります。MVP は「機能を削った小さい製品」ではありません。重要なのは、検証したい仮説に対して十分に学べることです。場合によっては、実...
リトルの法則
リトルの法則は、フローを考えるときに役立つ基本的な関係です。ざっくり言えば、仕掛かり中の仕事が多いほど、完了までの時間は長くなります。よく使われる形は「平均リードタイム = 平均WIP ÷ 平均スループット」です。たとえば、仕掛かりが20件あり、1日に平均5件完了するなら、...
累積フロー図
累積フロー図（Cumulative Flow Diagram）は、仕事が各状態にどれだけ溜まっているかを時系列で見る図です。カンバンやフロー改善でよく使われます。各列の幅が広がっているところは、その状態に仕事が溜まっていることを示します。たとえば Review の層が広がっ...
サイクルタイム
サイクルタイムは、仕事に着手してから完了するまでの時間です。リードタイムが依頼から完了までを見るのに対し、サイクルタイムは実際に流れ始めてからの時間を見ます。サイクルタイムを見ると、チーム内の流れがわかります。実装は早いがレビューで止まる、レビューは早いがテストで詰まる、着...
リードタイム
リードタイムは、仕事が依頼されてから完了するまでの時間です。顧客やステークホルダーから見ると、「いつ頼んだものがいつ届くか」に近い指標です。リードタイムが長い組織では、優先順位の変更、待ち時間、承認、手戻り、並行作業が積み重なっていることが多くあります。実装時間そのものより...
カンバン
カンバンは、仕事の流れを可視化し、仕掛かりを制限し、継続的に改善するための方法です。カードをボードに貼ることだけがカンバンではありません。基本は、仕事がどの状態にあるかを見えるようにすることです。Ready、Doing、Review、Test、Done のような列を作ると、...
バックログリファインメント
バックログリファインメントは、プロダクトバックログを次に扱いやすい状態へ整える活動です。項目を分割し、目的を確認し、受け入れ条件を加え、優先順位や依存関係を見直します。リファインメントは、プロダクトマネージャーだけの作業ではありません。開発者、デザイナー、QA、必要に応じて...
スプリントゴール
スプリントゴールは、そのスプリントで達成したい目的を短く表したものです。単なるチケットの一覧ではなく、チームが何を実現しようとしているのかを示します。スプリントゴールがあると、スプリント中に予想外のことが起きても判断しやすくなります。すべてのチケットを完了させることより、ゴ...
ベロシティ
ベロシティは、チームが一定期間に完了したストーリーポイントの量です。スクラムでは、過去数スプリントの実績から、次にどれくらいの仕事を引き受けられそうかを考える材料として使います。ベロシティは予測のための道具であり、目標にするものではありません。「今期はベロシティを20%上げ...
ストーリーポイント
ストーリーポイントは、仕事の相対的な大きさを見積もるための単位です。時間ではなく、複雑さ、不確実性、作業量をまとめて表します。「この仕事は何時間かかるか」ではなく、「過去のあの仕事を2ポイントとすると、これはどれくらいか」と考えます。相対見積もりにすることで、細かい時間予測...
受け入れ条件
受け入れ条件は、あるバックログ項目が期待どおりにできたかを判断するための条件です。ユーザーストーリーが「なぜ作るか」を表すなら、受け入れ条件は「何が満たされればよいか」を具体化します。受け入れ条件がないと、開発者、プロダクトマネージャー、テスター、ステークホルダーがそれぞれ...
ユーザーストーリー
ユーザーストーリーは、ユーザーにとっての価値を中心に要求を表現する方法です。よく使われる形は「誰として、何をしたい、なぜなら」です。たとえば「管理者として、請求前に未確認の明細を一覧したい。なぜなら、差し戻しを減らしたいから」のように書きます。重要なのは形式そのものではあり...
Definition of Ready
Definition of Ready（準備完了の定義）は、バックログ項目を開発に着手できる状態にするための条件です。チームがスプリントやフローに仕事を入れる前に、最低限そろっているべき情報を明確にします。Ready は、すべての仕様を固めることではありません。着手してすぐ...
Definition of Done
Definition of Done（完成の定義）は、チームが「この仕事は完了した」と言える条件を明確にしたものです。単に実装が終わった状態ではなく、レビュー、テスト、ドキュメント、リリース準備など、価値として届けられるために必要な条件を含みます。完成の定義が曖昧だと、チケ...
Thinkers 50コミュニティが選んだ最も影響力のある経営本（2023）
Thinkers 50から2023年の「最も影響力のある経営本」のリストが出ていました。古典的な本と新刊の両方が掲載されていますが、ここでは新刊のほうを紹介します。キーワードを眺めるだけでもトレンドが見えてくるのではないでしょうか。なお、Amazonの書籍情報をDeepLで...
組織変革フレームワーク
Prosci 変更を準備する 変更を管理する 変更を強化するADKAR Awareness(認知) Desire(欲求) Knowledge(知識) Ability(能力) Reinforcement(定着)AIM: Accelerating Impleme...
4Cフレームワークを使ったワークショップの作り方
企業で研修をすると、人事の方などから「こういう研修ができる社内講師を増やしたい！」という声をいただきます。社内講師を育てる立場にあるわけではないので、そんなこと言われても「はーそうですか」という答えになってしまうんですけど……いちおう私が参考にしている方法がありまして、あま...
スクラムマスターが読むべき5冊
Agile42に「Five books every ScrumMaster should read」というエントリがありました。タイトルだけ引用しておきます。 Mike Cohn, Succeeding with Agile Software Developmen...
WIP制限の値の設定方法
カンバンのWIP制限の値をどのように設定すればいいか。『Agile Project Management with Kanban』にマイクロソフト社のXboxの例が載っていたので、紹介したい。 A: 1人の作業員が1か月にできる平均作業量 ← すべてのプロセス B: プ...
リーンキャンバスから事業計画書へ
引き続きリーンキャンバスのネタ。リーンキャンバスを書いたら、あとはもう建物の外に出るなり、プロトタイプやらMVPやらを作るなりして、足や手を動かしていただければいいのですが、大きい企業さんだとそういうわけにもいかず、プロジェクトを進めるにはドキュメントが必要になります。事業...
新規事業の4つのアプローチ（PGTM）
リーンキャンバスの研修を何度かやっているうちにわかってきたことがあります。アイデアの想起にいくつかの種類があるようなのです。ここでは代表的な4種類についてまとめてみたいと思います。ペイン型リーンキャンバスは左端に「課題」のボックスを用意しています。お客さんは何らかの課題を抱...
アジャイル認定資格というもの
アジャイル関連の資格が多いようなので、どれだけあるか調べてみました。他にもあると思いますが、目立ったものは網羅できていると思います。スクラムアライアンス日本でも多くの人たちが、認定スクラムマスター（CSM）と認定プロダクトオーナー（CSPO）を取得していると思います。講師に...
アジャイル導入の「最小限」の読書リスト
『Manage It! 現場開発者のための達人式プロジェクトマネジメント』などで有名なJohanna（かわいいおばちゃん！）が、「アジャイル導入の「最小限」の読書リスト」を公開していました。http://www.jrothman.com/services/minimum-r...
雑誌『anan』で「アジャイル」
キムタクが表紙の『anan』 No.1914の特集は「人はチームで強くなる！」でした。コンビニで見かけて気になっていたので、早速購入して読んでみました。そのなかでも特に気になったのは、「ココッパ」というアプリを開発されているユナイテッド株式会社さんの紹介記事です。 IT業...
スクラムマスターは開発メンバーになれるのか？
スクラムに関する資料を作っていて疑問に思ったのでQuoraで質問してみました。自分で訳しておいてあまり覚えていないので、改めて「スクラムガイド」を読んだんですが、明示的に書かれているところはありませんでした（兼任できるというようなニュアンスはある）。で、はじめてQuoraを...