Sign in

Waicrew
アジャイル開発、リーンスタートアップ、デザイン思考の情報を発信します。
以下は、Kent Beckによる「Programmer Test Principles」の翻訳です。本人の許可を得て掲載します。
チョコレート対バニラ

TDD対BDD。このテストツール対あのテストツール。テストビフォー対テストアフター対これは動くから俺を信じろ。ある時期から、こうした詳細に関する議論には飽きてしまった。もっと原則について議論したい。

詳細に関する議論はなかなか結論に至らずに、話が行ったり来たりする。チョコレート対バニラ。チョコレート。バニラ。チョコレート。バニラ。

詳細の議論に負けを認めさせられるようなことがあっても、その譲歩は絶対的なものではない。私の状況がチョコレートを勧めているのに、私にバニラを食べさせてくれと言えるだろうか? これでは埒が明かない。

原則

一方、原則は議論を生み出す基盤になる。原則には賛成しても状況が違っているのなら、答えは違ってくるかもしれないが、そこで論争になることはない。原則が、異なる状況における異なる答えを生み出したのである。

詳細で論争するよりも、原則で論争したほうが生産的だ。私が完全性よりも速度を優先していると主張しても、あなたは速度よりも完全性を優先していると主張することができる。両者がそれぞれの状況において「正しい」。つまり、それぞれのニーズを満たす最高の決断をしているのだ。それと同時に、こうしたレベルで原則について議論することで、お互いの違いをうまく理解できるようになる。

プログラマーテスト

テストは神託である。「嗚呼、大いなる神託よ、これをデプロイしたら何が起きるというのか?」「我が子よ、大惨事が発生するだろう」。このように、テストはデプロイの結果を予言してくれる。

プログラマーテストは神託であり、コーディングと意思決定を繰り返すことによるフィードバックを提供してくれる。また、プログラマーテストは、難しい制約の組み合わせの影響を受けることになる。

プログラマーのテストは高速でなければいけない。フィードバックはプログラミングの流れを妨害してはいけない。スローテストはコーディングの意思決定をバッチ化してしまう。後続のテストの失敗はデバッグが困難である。これは、意思決定の1? 意思決定の2? それとも2つの組み合わせ?

どれだけ速ければ速いのか? 1秒未満が境界のように思える。目を離す間もないくらい、待ち時間が短いからだ。これが10秒だと椅子に深く腰掛けて目を離すことになるだろうが、新しいことを始めるほどの時間ではない。1分はコンテキストスイッチだ。デバッグのコストが高まり、実行するテストの数を減らしたくなる。

プログラマーテストは確定的でなければいけない。よく見かける「当てにならない(flaky)」テストは除外にするにしても、この主張が物議を醸すことになろうとは思ってもいなかった。確定的ではないテストは即削除する、というFacebookの方針が私は好きだった。カバレッジを下げたくなければ、テストができるように設計を変更して、テストを改めて書けばいい。

プログラマーテストは予言するものでなければいけない。神託が「デプロイしろ」と言ったのに、デプロイが失敗したのなら、神託を信じることをやめるだろう。

プログラマーのテストは、振る舞いの変化に敏感であり、構造の変化に鈍感でなければいけない。つまり、プログラムの振る舞いが安定しているように見えるなら、テストを変えるべきではない。

構造を変えないテストには、特定のスタイルの設計だけでなく、特定のスタイルのプログラミングと設計の両方が求められる。「このオブジェクトがこのメッセージをこれらのパラメータを持つオブジェクトに送信してから、あのメッセージをあのオブジェクトに送信すること」のようにアサートしているテストをよく見かける。だが、このようなアサーションは、世界で最も醜いプログラミング言語の構文だ。オペレーションの順序を気にしなければいけないとしたら、それはシステムの設計が間違っている。

プログラマーテストは安価に記述できなければいけない。テストを書くことに給与が支払われるわけではない。「a) きちんと動作」する「b) 変更できる」コードに対して給与が支払われるのだ。テストがそれを支援することもあるだろうが、他の条件が同じであれば、テストにかける労力は少ないほうがよい。

プログラマーテストは安価に読めなければいけない。テストは(コードと同様に)書くよりも読むことのほうが多い。

プログラマーテストは安価に変更できなければいけない。ひとつの振る舞いを変更したことで、テストがいくつもレッドになることがある。テストは個別に検討および変更できるようにすべきだ。そうすれば、テストが変更の非常ブレーキになる。

まとめると、プログラマーテストは、

  • プログラマの待ち時間を最小限にする。
  • 信頼して実行できる。
  • デプロイ可能かどうかを予言できる。
  • 振る舞いの変化に反応する。
  • 構造の変化に反応しない。
  • 安価に書ける。
  • 安価に読める。
  • 安価に変更できる。

なんとも解決が難しい制約の組み合わせである。なかには矛盾しているものもある。どれが最も重要で、どうすればそれを最大限に満たすことができるかを見つけよう。そして、それがあなたの仕事である。

領域

私がプログラマをコーチするときに懸念しているのは、彼らがテストの領域を探索したことがないことだ。テストに1分以上かかっているが仕方ない。テストを非確定的にするしかない。コードの構造を変えたときにもテストを変更せざるを得ない。そんなことはない。

上記の原則を考えてみよう。原則に違反しているテストを見つけよう。同様のテストで原則を守っているものを想像してみよう。そのようなテストが書けなければ、テスト対象のソフトウェアの設計を、プログラマーテストの原則を満たすテストが書けるようなものにしてみよう。


以下は、Kent Beckによる「Fast/Slow in 3X: Explore/Expand/Extract」の翻訳です。本人の許可を得て掲載します。

ソフトウェア企業の偉い人が「私たちは遅いでしょうか?」と聞いてきた。

3X思考の使い手である私は「まあ、そうですねえ……それは曲線のどこにいるかで決まりますね」と答えた。

要約

Explore/Expand/Extract

3Xの記事を書いてからしばらく経つので、簡単に説明しておこう。アイデアやプロダクトや企業が成長していくと、価値を最大化する振る舞いが劇的に変化する。

  • 探索(Explore)―無関心を克服するために、小さな実験を数多く試してみる段階。
  • 拡大(Expand)―拡大のボトルネックを解消するために、次に制約となるリソースの制限を緩和する段階。
  • 抽出(Extract)―成長を維持するために、成長が終わっても継続的に収益性を高める段階。

「速い」か「遅い」か

「速い」か「遅い」かは、曲線のどこにいるかで意味が違ってくる。

探索―アイデアが生まれてからフィードバックを得るまでにかかる時間は? 大企業だと社会構造が複雑であり、リスクの許容度が低く、抽出の考え方が文化の大部分を占めているため、この遅延時間が増える傾向にある。また、遅延が「実験数が減る → 成功数が減る → 1つの実験に対するのプレッシャーが高まる → 実験数が減る」というフィードバックループを生み出すことになる。

時間/日/週/月あたりに、どれだけ実験を行なっているだろうか? 増えた遅延時間は、実験を行う人員を増やすことで一時的に低減できるかもしれない。だが、遅延は指数関数的に増加し、投資は一時的なものである。探索における成功とは常に予期できないものなので、速度の指標は「件数」にしておくとよいだろう。

拡大―新たなボトルネックにすばやく人やお金を投入しているか? 成長を滞らせるボトルネックは、時間が経てばだいたい判明する。だが、ボトルネックを軽減できる人やお金が動かないこともある。元の場所にいたほうが有益だからだ。

Facebookのエンジニアリングでは、新たなボトルネックに非常にうまく対応していた。最も優秀なエンジニアたちが、厄介な技術的問題に群がるのである。Facebookはこのようなレベルのレジリエンスを達成するために、大きな成功を犠牲にしてでも、喜んで対価を支払っている。複雑なマネジメント環境で、このような対価を支払う組織はそう多くはない。だが、これは実現可能である。

抽出―収益性の高いプロジェクトにかける時間は? こうしたプロジェクトは、収益を高めるかコストを減らす。成長している組織は、もはや価値を提供しないプロセス、引き継ぎ、遅延を放置している。使い物にならなくなったものが膨れ上がる危険性があるため、もはや価値を提供しないプロセス、引き継ぎ、遅延を排除する必要性(あるいは、レジリエンスを高めることで、価値を提供できるプロセス、引き継ぎ、遅延を増やしていく必要性)を省みることがない。

Conclusion

「私たちは遅いでしょうか?」

「探索しようとしていて、本質的な理由がないのに実験に時間がかかっているのであれば、遅いでしょうね。あるいは、月あたりの実験数が少ないのであれば、やはり遅いでしょうね。

拡大しようとしていて、重要なリソースが欠けているために成長できず、右往左往しているとしたら、遅いでしょうね。

抽出しようとしていて、収益性の高いプロジェクトに必要以上に時間がかかっているとしたら、遅いでしょうね」


以下は、Ash Mauryaによる「What is a Job-To-Be-Done (JTBD)」の翻訳です。本人の許可を得て掲載します。

「JTBD(Job-To-Be-Done)」の理論やフレームワークをご存知でしょうか。私は数年前にクレイトン・クリステンの有名な「ミルクシェイクの調査」ではじめて耳にしました。

すぐに興味を持ちましたが、得られる答えよりも疑問のほうが多くなりました。

そこで、見つけられたものすべてに目を通し、さらにはBob Moesta、Chris Spiek、Tony Ulwick、Alan Klement、Des TraynといったJTBDの思想的リーダーや実務家たちと一緒に仕事をすることにしました。このことは、私の「顧客フォースキャンバス」と「イノベーターのギフト」のプロジェクトに大きな影響を与えています。

それでもなお、2つのことが気になっています。

ひとつは、JTBDの一般的な定義が、循環的で、多面的で、意図的に曖昧になっていることです。もうひとつは、多くのケーススタディが「よくできた手品」のように感じられることです。つまり、言われてみれば当然なことであっても、自分のプロダクトで再現するのは非常に難しいのです。

まずは、定義の問題に取り組みたいと思います。もっと明確で、簡潔で、シンプルな定義にすることで、自動的に2つめの問題に進めるはずです。

定義の問題

よく見かける定義をいくつか紹介しましょう。

  • 循環的な定義:「人々はプロダクトを購入するのではなく、ジョブを片づけるためにプロダクトを雇用する。」

ジョブは「ジョブを片づける」ものだそうです。何ですかそれ?

  • 多面的な定義:「人々が達成しようとしているタスク、ゴール、目的。あるいは、解消しようとしている問題。」

「タスク」「ゴール」「問題」は、まったくの別物です。どうしてジョブが3種類の違ったものになるのでしょう?

  • 意図的に曖昧な定義:「人々が成し遂げようとする進歩である。」

どうすれば「進歩」を調べられるのでしょうか?

定義の出典元を明記していないことに気づいたでしょうか。ここではわざとやっています。経験豊富な実務家ならばソースを知っているでしょうし、好奇心の強い人ならばすぐにソースを発見できるはずです。出典元を明記しなかったのは、定義の良し悪しについて審判を下すことが私の目的ではないからです(不要な議論を引き起こしたいわけでもありません)。これらの定義には重複する部分が多々あります。私は上記の定義をバラバラにして、うまく繋ぎ合わせたいと考えています。

以下の定義は、JTBDを私なりに理解・実践しやすくしたものです。あなたの意見をコメント欄でお聞かせください。

JTBDとは何か?

  • シンプルな定義:「JTBDとは(トリガーに反応した)満たされていないニーズやウォンツを表したものである。」
JTBDとは(トリガーに反応した)満たされていないニーズやウォンツを表したものである。

注:「ジョブとは、満たされていないニーズやウォンツである。」のようにさらにシンプルにすることもできるでしょう。しかし、これは行動につながる定義ではありません。ジョブJTBDとの違いは、満たされていないニーズやウォンツに向かう「タイムボックス」の緊迫感です。トリガーがこれを生み出しています。言い換えれば、ジョブは「あったらいいな」と願うこと。JTBDは行動の前兆です。

私たちは一日中、トリガーイベントに遭遇しています。つまり、一日中「JTBD」に遭遇しているということです。

  • 午後12時36分、お腹がへった。ご飯を食べよう。
  • 午後7時36分、お腹がへった。今日は妻の誕生日。高級レストランに彼女を連れて行こう。

トリガーとは、JTBDを形づくるコンテキストを定義するものです。

注:進歩は、劇的なものや意欲的なものである必要はありません。「空腹から満腹になるまで」のようなシンプルなもので構いません。

トリガーが発生するたびに新しいソリューションを探す必要があると、認知的負荷が増えすぎてしまいます。したがって、ほとんどの場合、既存の代替手段(どこかでランチを食べるなど)で済ませています。

注:JTBD実践者のなかには、プロダクトの雇用と解雇(購入とスイッチ)にフォーカスしている人もいます。私の場合は、JTBDを購入やスイッチとは切り離しました。雇用にスイッチは不要だからです。たとえば、以前購入したプロダクトを再利用すれば、ジョブを片づけることができます。

スイッチのトリガーは、期待違反を伴う特別なトリガーです。既存の代替手段がジョブを片づけるのに不十分だったときに発生します。それは、これまでとは異なる新しいソリューションを模索するときでもあります。

上記のランチの例では、新しいレストランを探すきかっけになるでしょう:

  • 状況の変化(例:新しい仕事の初日)
  • 悪い経験(例:いつものレストランで食中毒)
  • 認識イベント(例:新しいレストランがオープンしたと聞いた)

注:通常のトリガーは、なじみのあるソリューション(既存の代替手段)を優先するJTBDを表しています。スイッチのトリガーは、新しいソリューションの可能性をもたらす期待違反を生み出します。

スイッチを促されると、顧客は自分のジョブに最適なものを求めて、複数の製品を評価・試用します。「雇用」は最初の重要なステップですが、あくまでも最初のステップです。すぐに価値を届け(アハの瞬間)、新しい「現状」とならなければ(習慣になる瞬間)、すぐに解雇リストに記載されるでしょう。


以下は、Kent Beckによる「Coaching Engineers」の翻訳です。本人の許可を得て掲載します。

tl;dr 有償でエンジニアのコーチをします。詳細と待ち時間についてはお問い合わせください。

物語の結末

2018年2月にFacebookを退職する直前に、トップ1%のエンジニア(現在および過去にレベルE7以上だったエンジニア)のオフサイトミーティングに参加しました。海辺のリゾートでバスを降りると、私がコーチをしていた生徒が複数いることに気づきました。そのうち何人かは昇進したことを知っていましたが、その他の生徒には驚かされました。

私にとって、胸がはちきれるほどの誇り高き瞬間でした。私は、生徒たちと関係を築き、彼らの成功のために心の底から尽力してきました。多くの生徒らが成功を収めたことを目の当たりにして、私は大いに驚き、嬉しくなりました。物語はさらに続きます。

Facebookの上位レベルのエンジニアのほとんどは、最初からそのレベルで雇用されています。社内で昇進したのは、参加者のうちわずか40人です。うち6人が私の生徒でした。彼らは5年間で4〜5回昇進していました。

彼らの成功にとって、私の貢献は一部だったかもしれません。彼らは才能があり、勤勉で、幸運でした。それでも、私は誇りに思っています。

私の物語

私が新人の23歳のエンジニアだったとき、Ward Cunningham(彼の功績のなかではWikiが最も有名)と仕事をする幸運に恵まれました。Wardは、Smalltalkを教えるコースを作っていました。それは、用意された配管シミュレーションを生徒が拡張するというものであり、彼は誰かを相手にその説明をする練習をしたいと考えていました。その後の彼との1年半が、私のキャリアを大きく変えたのです。

最初は、Wardがプログラミングして、私はそれを見ていました。数日後、彼が気づく前に、私はタイポを発見しました。数週間後、私は名前付けと設計の矛盾点を見つけました。それがシンプルにするきっかけとなりました。

プロセスが進むにつれて、私たちはキーボードとマウスを交換していることに気づきました。ゾーンに入っているときは、ひとりがキーボードを操作して、もうひとりがマウスを操作していました。最終的なコードには一貫性があり、どちらがどの部分を書いたのかわからないほどでした。どのように書くべきか意見が分かれるたびに私たちは手を止めて、問題について議論していました。

継続的な関係性、具体的な作業、抽象的な議論、これらの組み合わせにより、私の学習は加速していきました。自分がどれだけ知っているか、どれだけ学ばなければいけないかを正確に把握できました。プロがどのように問題に取り組んでいるかを間近で見ることができました。また、自分の能力と可能性に自信が持てました。

Wardは、彼が若いエンジニアだったときに、どのような指導を受けたのかという話をしてくれました。先輩エンジニアは無愛想でせっかちな人ばかりだったそうですが、仕事に熱心な可能性のある若手には喜んで目をかけてくれたそうです。

http://wiki.c2.com/?WardAndKent

次は私の番

ヤギの飼養期間は、私はほとんどリモートでコーチングしていました。週に1回、生徒と2時間のビデオ/スクリーン共有セッションを行うのです。Facebookに就職したとき、何か貢献できる方法がないかと探していました。友人のPeter Domovが「コーチングを試してみてはどうか」と提案してくれました。そして、コーチングプログラム「g2G」を開始しました。これまで数百人を超えるFacebookのエンジニアが参加しています。

最初は素朴に技術スキルを教えようと思っていました。リファクタリング、パターン、テストについて話したいと考えていました。ですが、技術スキルならば、生徒たちは独学で習得できるのです。独学で学ぶのが難しいのは、個人的なスキルと対人的なスキルです。たとえば、コミュニケーション、共感、自信、注意などです。自己認識を新たにすることで、彼らの技術スキルは実を結ぶことができるのです。

このプログラムはFacebookの通常の仕組みと相容れなかったため、私たちはその効果を実証することに苦労しました。ですが、数年後に「コーチングを受けた生徒は、コーチングを受けていない同等のエンジニアと比べて、その翌年に昇進する可能性が2倍高い」ことが判明しました。退職するまでに、私は150人以上のエンジニアをコーチしました。このプログラムの生徒は数百人を超えています。

私からの提案

退職後の活動のポートフォリオの一環として、私はコーチングを提供することにしました。理想的な対象者は、大きな可能性を秘めており、進歩がないことに不満を抱いており、阻害要因を掘り下げる時間のないマネージャーの下で働いており、何とか改善したいと思っている人たちです。私は上記に該当する1年目から20年目のエンジニアにコーチングすることに成功しています。

コーチングの内容は、約1か月で1時間のセッションが10回と、その後の月ごとのフォローアップが全5回となります。また、10回のセッションの前後に、生徒とマネージャーと話し合いを実施します。

各セッションは、ペアプログラミングと会話を組み合わせたものになります。生徒は、自分の仕事の経験について話し、私の話を聞いて、次のセッションの宿題を受け取ります。最初のセッションは常に対面で行いますが、その後のセッションについては対面またはリモートとなります(私はサンフランシスコを拠点にしています)。


以下は、Kent Beckによる「test && commit || revert」の翻訳です。本人の許可を得て掲載します。
新しいスタイル VS テスト駆動開発

Limbo on the Cheap」のなかで、新しいプログラミングワークフローを考案しました。テストが成功するたびにコードをコミットする「test && commit」というものです。Oddmund Strømme(私が最初に出会った、私と同じく対称性に取り憑かれたプログラマ)が、テストが失敗したらコードをリバートすべきだと提案してくれました。私はこのアイデアが大嫌いだったので、とりあえず試してみることにしました。

そのコマンドは「test && commit || revert」になります。テストが失敗したら、コードはテストが最後にパスしたときの状態に戻るのです。

私は「test && commit || revert」に賛同はしていませんし、そのトレードオフについて説明するつもりもありません。動作はするでしょうけど、あんまりうまくいかないんじゃないかと思います。まあ、みなさんも試してみてはいかがでしょうか(新しいプログラミングワークフローなら何でも試してみたい人向け)。

とは言ってみたものの

「test && commit || revert」はうまくいかない、そんなふうに考えていた時期が私にもありました。常にテストを動かさなければならないとしたら、どうやって進捗するのだろう。ときどきミスをするんじゃないの?コードを大量に書いたあとで、それが全部消えたらどうなるだろう。絶対イライラするでしょ?

その驚くべき答えは、いずれも「はい」になります。あなたは以下のようにコードを書くこともできるのです。

はい、ときどきミスをするでしょうけど(埋没コストの誤りをしなければ)間違ったコードがすぐに削除されるのはよいことです。大量のコードを消されたくないなら、グリーンとグリーンのあいだに大量のコードを書かなければいいでしょう。

はい、コードが消えたらイライラするでしょうけど、同じことをもっとうまく、もっと確実に、もっとインクリメンタルにやれる方法が見つかるはずです。

インクリメント

Limboは、小さな変更を即座に伝えることで、技術的なコラボレーションを拡大させるものです。TDDはLimboでは機能しないでしょう。プログラマが10万人いたとして、1つのテストの失敗で他のすべてのプログラマに負担をかけることなどできないからです。テストが大量に失敗していたら、誰も何が起きているのかを把握できないでしょう。変更を反映するには、すべてのテストをパスさせる必要があります。

一方、「test && commit || revert」は、すべてのテストをグリーンに保ちます。ですが、大きな問題を小さなステップで一気に解決することなどできません。では、「test && commit || revert」を使うときの「ステップ」とは何でしょうか?


産業能率大学さんの通信講座「デザイン思考入門 」の監修を担当しました。

最初は「通信講座でデザイン思考が学べるわけないですよね?」と、監修者一同あまり乗り気ではなかったのですが、関係者のみなさんの努力で、最終的にはなかなかよい教材になったのではないかと思います。

カリキュラム

  1. 共感:ユーザーの声を聴き、実態を知る
  2. 定義:潜在的なニーズを把握する
  3. 発想:潜在的なニーズに応える、アイデアを発想する
  4. プロトタイプ:発想したアイデアを、”ざっくり”かたちにしてみる
  5. テスト:アイデアの有効性を確認する 実践の注意点:「デザイン思考」はどこからでも、何度でも繰り返そう
  1. デザイン思考に取り組む姿勢
  2. デザイン思考を促進するチームづくりと「場」づくり
  • 絵本仕立ての物語を通じて、デザイン思考の要点を確認します。
  • 具体的な課題と結びつけながら、デザイン思考のメソッドを実践し、マインドと共に体得します。


※本記事は旧版です。最新版(2019年9月)はオフィシャルサイトからPDFをダウンロード可能です。

この作品は The Kanban Guide for Scrum Teams の翻訳です。クリエイティブ・コモンズ 表示 — 継承 4.0 国際 ライセンスの下に提供されています。

目的

カンバンにおけるフローベースの考え方は、スクラムフレームワークとその導入を強化・補完する。チームがこれからスクラムを使う場合でも、これまで長年スクラムを使ってきた場合でも、カンバンは適用可能である。

この「スクラムチームのためのカンバンガイド」は、Scrum.orgのコミュニティのメンバーとカンバンのコミュニティのリーダーがコラボレーションして生み出した結果である。その両者が協力して「スクラムチームのためのカンバンガイド」を支援している。カンバンとスクラムを組み合わせれば、プロのソフトウェアの実践者が恩恵を受けることができるだろう。そのことが、両者の共通した信念である。

スクラムガイドとの関係

本ガイドは、スクラムガイドを置き換えるものではない。軽視するものでもない。スクラムフレームワークのプラクティスを強化・拡張するために設計されたものである。本ガイドの読者は、すでにスクラムフレームワークを使ってプロセスを運用しているものとする。したがって、スクラムガイドも全体的に適用される。

カンバンの定義

カンバン(名詞):見える化され、進行中の作業(WIP: work in progress)が制限されたプルシステムを使用するプロセスにより、ステークホルダーの価値の流れを最適化する戦略。

カンバンの定義の中心にあるのは「流れ(フロー)」の概念だ。流れとは、プロダクト開発のシステム全体における顧客価値の動きである。プロセスの全体的な効率性・有効性・予測可能性を向上させることで、カンバンは流れを最適化する。

カンバンとスクラムの理論

まずは、スクラムガイドの重要な教義を簡単に復習したい。

スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。経験的プロセス制御の実現は、透明性・検査・適応の3本柱に支えられている。

スクラムでは、スプリントバックログの透明性を義務付けているが、その実現方法の指針についてはほとんど提示されていない。また、作業項目がプロダクトバックログに入るまで、プロダクトバックログからスプリントバックログに至るまでの流れについて、あるいはインクリメントが「完成」したあとで作業項目に発生するあらゆることについても、透明性を確保する方法は定義されていない。

そこで、カンバンの登場だ。スクラムチームは、作業項目を新たな方法で見える化することで、本ガイドで紹介しているプラクティスを適用し、価値の提供をうまく最適化できるだろう。なお、これらのプラクティスは、リーンシンキングの原則、Product Development Flow、待ち行列理論などを参照・応用したものである。

価値の流れを最適化することで得られる有益な副作用は、プロセスとプロダクトに対する検査と適応の機会が増えることだ。カンバンによって顧客のフィードバックループを強化するというのは、経験的なプロセス改善の実績のある戦略である。

カンバンの透明性・見える化・流れに対する過剰なまでのフォーカスと、スクラムフレームワークを組み合わせれば、最適な顧客価値を提供するプロセスをデザインする強力な基盤となるだろう。

ワークフローの定義

流れを最適化するには、スクラムの文脈における流れの意味を定義する必要がある。スクラムチームは、以下のような要素を含む「ワークフロー」の定義を作らなければいけない。

  • スクラムチームが作業の開始と終了を認識する時点
  • スクラムチームのシステムを流れる顧客価値の単位(通常はプロダクトバックログアイテム(PBI)になるだろう)
  • PBIの誕生から終了までの流れを示すワークフローの各状態(少なくとも1つはアクティブな状態が必要になる)
  • 作業が各状態を流れていく明確な方針(スクラムチームの「完成」の定義やステージ間の引き取りの方針の定義などが含まれる)
  • 進行中の作業(WIP)の制限
  • 作業項目が完了するまでにかかる時間を予測するサービスレベル期待値(SLE: Service Level Expectation)

ワークフローを定義するのはスクラムチームの責任だが、以下のような考慮すべき要素がいくつかある。

  • まだアクティブではない作業項目を「開始していない」と認識すること
  • アクティブになった(開始された)作業項目を「進行中(WIP)」と認識すること
  • 事前に用意したアクティブな状態をすべて通過した作業項目を「終了した」と認識すること

以上をまとめると、「ワークフロー」の定義には、作業そのものの定義(作業項目)、プロセスの開始状態、作業項目のアクティブな状態、プロセスの終了状態に関するスクラムチームの共通認識が含まれる。

注意してほしいのは、「ワークフロー」の定義における状態は、スプリントバックログで定義された状態とは一致しないことがある、ということだ。たとえば、スクラムチームの「ワークフロー」の定義には、スプリントバックログの上流・下流・内部・外部の状態が含まれる可能性がある。同様に、ワークフローを移動する作業項目はプロダクトバックログアイテムには当てはまらず、スプリントバックログやスクラムにも該当するものがない可能性もある。すべての状態を通過しない作業項目もあれば、アクティブな状態を順番に流れていかない作業項目もある。

「ワークフロー」の定義の作成と適応は、既存の作成物に影響を与えたり、逆に影響を受けたりする可能性がある。ただし、プロダクトオーナーと開発チームの作成物に対する責任については、スクラムガイドに従うべきである。

サービスレベル期待値(SLE)

SLEとは、任意の項目がワークフローの開始から終了まで流れる時間を予測するものである。SLEには2つの部分が含まれる。経過日数とその確率だ(例:「作業項目の85%が8日以内に終了する」)。SLEはスクラムチームの過去のサイクルタイムをベースにしている。サイクルタイムを計算したらカンバンボードに貼り付けておこう。サイクルタイムのデータがなければ、まずはスクラムチームで最善の推測を行い、SLEを計算するのに十分なデータが集まったあとで置き換えればいい。

スクラムチームが「ワークフロー」をどのように定義しようとも、本ガイドの中心的な概念はワークフローである。本ガイドのあらゆる要素は、スクラムチームがどのように「ワークフロー」を定義しているかに大きく依存する。スクラムチームが作業の流れを経験的に改善していくにつれて、ワークフローの定義も変わる可能性があるだろう。むしろ、変わるべきである。なお、本ガイドのその他の要素と併用するときには、一貫した「ワークフロー」の定義を用いるべきである。一貫性によって、カンバンの透明性に対する完全性が保証されるからだ。

カンバンのプラクティス

スクラムチームは、以下の4つの方法を使用して流れの最適化を実現する。

  • ワークフローの見える化
  • WIPの制限
  • 進行中の作業項目のアクティブな管理
  • 「ワークフロー」の定義の検査と適応

カンバンボードを使った見える化は、スクラムチームがワークフローを透明化する方法である。カンバンボードによって、適切な時期に適切な会話を促すことができる。また、改善の機会を積極的に提案することができる。

WIP(Work in Progress)とは、スクラムチームが作業を開始したが、まだ終了していない作業項目のことを指す。カンバンボードを使用するスクラムチームは、これらのWIPを「開始」から「終了」まで明確にコントロールする必要がある。そのコントロールは、通常はカンバンボードの数値で示される。この数値のことを「WIP制限」と呼ぶ。WIP制限は、ひとつの列、複数まとめた列、ボード全体の作業項目に対して設定できる。スクラムチームがWIP制限を設定すると、ワークフローのその部分にはWIP制限の数値以上の作業項目を引き取ることができない。スクラムチームは、何を制限とするか、それをどのように適用するかをコントロールする。

WIPを制限すると、主な副作用として「プルシステム」が生まれる。作業を開始すべき明確なシグナルを受け取ったときに、スクラムチームが作業を開始する(プルする)ことから、「プルシステム」と呼ばれている(要求されたときに作業を開始する「プッシュ」システムとは異なることに注意)。定義された値をWIPが下回ると、それが新しい作業を開始するシグナルになる。

スプリントもWIP制限の一種と考えることができる。スプリントの定義によれば、これは一定期間内に開発チームが取り組む作業量をコントロールする方法である。開発チームが(通常はスプリントプランニングで)選択したときにだけ、作業項目がスプリントバックログにプルされる。意図するしないにかかわらず、スクラムはこのような流れの基本的なプラクティスを最初から受け入れてきた。カンバンのWIP制限は、スプリントよりもさらに粒度が細かく、明確なものである。これは、ワークフローを支援するだけでなく、スクラムチームのフォーカス、コミットメント、コラボレーションについても改善してくれるものである。

WIP制限は流れの実現に欠かせない要素だが、それだけでは十分ではない。流れを実現する3つめの方法は、進行中の作業項目のアクティブな管理だ。アクティブな管理には、以下のようなものがある。ただし、これらに限定されるものではない。

  • ブロックされた作業項目にすばやく反応する
  • 作業項目がワークフローを出ていくのとほぼ同じ速度で、新しい作業項目がワークフローにプルされるようにする
  • 作業項目が放置されず、設定したSLEに従って完了できるようにする
  • 1つ以上の列に積み重なった作業を取り除く

これらの多くはデイリースクラムで扱うことになるだろう(「フローベースのデイリースクラム」を参照)。ただし、進行中の作業項目に対するプロアクティブ(事前)、アクティブ(最中)、リアクティブ(事後)の継続的な管理については、スクラムチームの責任で確実に実施する必要がある。

方針とは何か。これはスクラムチームにおけるワークフローの「ゲームのルール」と考えてほしい。方針の小さな変更が、スクラムチームのパフォーマンスに重大な影響を与える可能性もある。スクラムガイドには、最小限の明確な方針と、文脈固有の方針(例:スクラムチームの「完成」の定義)を見つけるための方法が記載されている。スクラムチームがカンバンを適用する場合、スクラムガイドにカンバンのプロセスの明確な方針を補完したいと考えるだろう。こうした方針は、スクラムチームの「ワークフロー」の定義に含まれることになる。

「明確」とは、これらの方針が何らかの形で書き記されていて、あるいは見える化されていて、スクラムチーム全体が理解していることを意味している。スクラムチームのメンバーがわかるように、カンバンボードには必要な方針や参照先をすべて貼り出しておくべきだ。

明確にすべき方針の例として、作業項目が「開始前」から「開始」、「進行中」から「終了」へと移動するタイミングをスクラムチームがどのように定義するか、がある。スクラムチームは間違いなく、本ガイドで求められる方針とは別に新たな方針を追加することになるだろう。

流れの指標と分析

スクラムの文脈にカンバンを適用するには、最低限の流れの指標の収集と分析が必要になる。これらの指標は、進行中の作業項目のアクティブな管理に欠かせない。また、流れを透明にして、フローベースの検査と適応を可能にする。これらの指標は、スクラムチームのアプローチの現在の健康状態とパフォーマンスを反映している。また、スクラムチームの機能と提供する価値を改善するポイントを指し示している。

カンバンを使用するスクラムチームが追跡すべき基本的な4つの指標を以下に挙げる。

  • Work in Progress(WIP):開始されたが終了していない作業項目の数(開始や終了はスクラムチームの「ワークフロー」の定義に従う)。
  • サイクルタイム:作業項目が開始してから終了するまでの経過時間。
  • 作業項目の年齢:作業項目が開始してから現在までの経過時間。
  • スループット:単位時間あたりの「終了した」作業項目の数。スループットの測定値は作業項目の個数であることに注意。

サイクルタイムと作業項目の年齢を計算するには、スクラムチームが(少なくとも)各作業項目の開始日と終了日を記録する必要がある。

これらの指標はスプリント全体で(特にスクラムイベントで)監視する必要がある(後述のフローベースのイベントの項目を参照)。もちろんスクラムチームが検討したい指標は他にもあるだろう。これらは最低限の指標である。

フローベースのイベント

スクラムの文脈におけるカンバンは、スクラムガイドに記載されているイベント以外のイベントを必要としない。ただし、フローベースの視点を使用すると、スクラムのイベントが強化されるだろう。

スプリントとは、検査と適応のリズムであり、定期的な「心拍」である。スプリントの定期的なサイクルと要素は、そのままでも流れの管理に適している。スプリントには、スプリントプランニング、デイリースクラム、開発作業、スプリントレビュー、スプリントレトロスペクティブが含まれる。スプリントに含まれるイベントは、カンバンの流れの指標を検査するフィードバックループとして機能する。同様に、カンバンのアプローチは、スクラムの導入を検査するフィードバックループとして機能する。

フローベースのスプリントプランニングでは、流れの指標を使いながらスプリントバックログを構築する。たとえば、過去のスループットを使用して、スクラムチームの次のスプリントにおけるキャパシティを把握する。スクラムチームのSLEは、スプリントの最初の数日間の作業に影響を与える可能性がある。

フローベースのデイリースクラムでは、流れを維持するためにスクラムチームができることすべてを実行しているかを確認する。デイリースクラムの目的はスクラムガイドの記載と同じだが、カンバンボードを囲みながらミーティングを開催すること、流れが滞っているところやスクラムチームが流れを回復できるところにフォーカスしていること、といった部分が異なる。フローベースのデイリースクラムで考慮すべき追加事項は、以下のとおりだ。

  • ブロックされている作業項目は何か?スクラムチームがブロックを解除するにはどうすればいいか?
  • 進行中の各作業項目の年齢は?SLEを違反している(違反しそうな)作業項目は?スクラムチームがそれらの作業項目を完了させるために何ができるか?
  • カンバンボードに記載されていない作業項目について、スクラムチームがそれらを完了させる能力に影響を与えるような懸念事項はあるか?

スクラムガイドには、スプリントレビューのプロセスの詳細な骨子が記載されている。こうした活動だけでなく、カンバンの流れの指標を検査することで、進捗をモニタリングする新たな対話が生まれる。たとえば、スループットをレビューすると、プロダクトオーナーが有望な予定日やデリバリーの日程を検討するときに役立つ情報が手に入るだろう。また、スクラムチームのSLEをレビューすると、プロダクトオーナーがプロダクトバックログを修正する機会が生まれるだろう。

フローベースのスプリントレトロスペクティブでは、流れの指標や分析を検査することで、スクラムチームのプロセスの改善(プロセスにはスプリントレトロスペクティブも含まれる)を判断するのに役立つ。カンバンを使用しているスクラムチームは、次のスプリントの流れを最適化するために「ワークフロー」の定義を検査・適応できる。スクラムチームのWIPを見える化するために累積フロー図を使用していれば、平均サイクルタイムや平均スループットも役に立つだろう。

スクラムガイドでは、スプリントレトロスペクティブはスプリントレビューが終わってから、次のスプリントプランニングが始まる前に実施することになっている。カンバンを使用するときもこれは変わらない。ただし、フローベースのレトロスペクティブはスプリントの境界と一致させる必要はない。「ジャストインタイム」で実施して構わない。ただし、それによってチームの「ワークフロー」の定義がいつでも変更される可能性が出てくる。そうした変更はスクラムチームのパフォーマンスに大きな影響を与えてしまうため、スプリントレトロスペクティブの定期的なリズムで変更したほうが、複雑性が軽減され、透明性が向上するだろう。

最後に

スクラムはプロセスやテクニックではない。人々が複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に提供するためのものである。スクラムガイドが指摘するように、その他のテクニック、方法論、プラクティスの入れ物としても機能する。

流れを最適化するカンバンのプラクティスは、適切なものを適切な時期に検査し、その検査にもとづき、必要に応じて適応する機会をスクラムチームに与える。カンバンの透明性・見える化・流れに対する過剰なまでのフォーカスは、フィードバック、経験主義、最終的には顧客価値の提供を最大化するだろう。

歴史と謝辞

一般的に「カンバン」と呼ばれるプラクティスの集合は、2006年にCorbisのチームで生まれたものである。これらのプラクティスは多種多様な国際コミュニティに急速に広まった。こうしたコミュニティが、長年にわたりこの手法を強化・進化させてきたのである。

本ガイドは、Scrum.org、Professional Scrum Trainerのコミュニティ、Steve Porter、Yuval Yeret、Daniel Vacantiによって共同開発されたものである。

Louis-Philippe CarignanとCharles Bradleyの協力に感謝したい。また、これまでにカンバンを成長させ、成功したリーン・アジャイル戦略にしてくれた実践者たちにも大いに感謝している。


ビジネス価値の計測と経験的マネジメントの活用によるビジネス成果の継続的改善方法

2018年9月

この作品は、Scrum.orgが提供する「Evidence-Based Management Guide」の日本語訳であり、クリエイティブ・コモンズ 表示 — 継承 4.0 国際 ライセンスの下に提供されています。

概要

アジャイルなプロダクトデリバリーのプラクティスを導入している組織は、ビジネス成果よりも活動やアウトプットの改善にフォーカスしがちであり、提供する価値を向上させるという本当の目的を見失いやすい。

アジャイルは目的を達成するための手段であり、目的そのものではない。つまり、アジャイルプラクティスを導入するときに最も重要なのは、ビジネスの業績を向上させることである。組織がこのことを見失うと、意図しない、望ましくないような結果を招く、それでいて「わかっている」かのような質問をマネージャーがするようになる。たとえば、以下のような質問だ。

  • 「コードの品質レベルは?」
  • 「ビルドは自動化してる?」
  • 「コードの規約に沿ってる?」
  • 「コードを頻繁に統合してる?どのくらい?」
  • 「チームのベロシティは向上してる?」
  • 「テストファーストやってる?」

これらの質問に対する答えは興味深いかもしれないが、組織が提供する価値やそれを引き出す能力を向上させるものではない。プラクティスそのものを監視しても、その有効性を示すエビデンスにはならない。たとえば、チームのベロシティを追跡しても、チームが顧客やユーザーにとって有益な何かを提供できているかどうかはわからない。

価値を計測しなければ、アジャイルの取り組みは直感と想定にもとづくものになってしまう。一方、エビデンスベースドマネジメント(EBM: Evidence-Based Management)のアプローチでは、組織が提供した価値を計測することで、組織のアジリティのエビデンスとする。また、組織が価値を提供する能力の計測と向上の手段を提供する。このアプローチにより、組織の会話は個人的な好みや意見から、実証的なエビデンス、ロジック、インサイトにもとづいたものへと変わり、組織は合理的かつ事実による意思決定を行えるようになる。

エビデンスベースドマネジメント

エビデンスベースマネジメント(EBM)は、経験主義的なアプローチである。顧客に届ける価値とその手段を計測する能力、その両方を改善するために指標を利用する能力を組織に提供する。

図1:EBMは4つの重要価値領域(KVA: Key Value Areas)から構成される

それぞれの重要価値領域(KVA)は、価値の異なる側面、あるいは組織が価値を提供する能力にフォーカスしている。これら4つのKVAをすべて備えていない組織は、短期的には価値を提供できるかもしれないが、それを持続させることはできないだろう。価値を提供すること、ステークホルダーが幸せなこと、従業員が満足していることも重要だが(現在の価値)、市場からの需要にあわせてタイムリーに提供できること(市場に出すまでの時間)や、イノベーションを持続できること(イノベーションの能力)についても、組織は明らかにする必要がある。プロダクトに対する継続的な投資は、そのプロダクトが適切な能力を保持していれば実現できる指標(未実現の価値)によって正当化される。

現在の価値(CV: Current Value)

現在、プロダクトが顧客に提供している価値を明らかにする。

CV(現在価値)を見る目的は、現時点で組織が顧客やステークホルダーに提供している価値を最大化することである。このとき、将来の可能性のある価値ではなく、現在に存在する価値だけを考慮する。組織がCVを継続的に評価するために必要な質問を以下に挙げる。

  1. ユーザーと顧客はどれだけ幸せか?その幸せは増加しているか?減少しているか?
  2. 従業員はどれだけ幸せか?その幸せは増加しているか?減少しているか?
  3. 投資家やステークホルダーはどれだけ幸せか?その幸せは増加しているか?減少しているか?

CVを向上させるものはさまざまである。たとえば、ユーザビリティの向上、顧客やユーザーのアウトカムの改善、働きやすい職場環境の構築などがある。CVを顧客やユーザー、投資家の視点から見るのは当然だが、従業員の態度まで考慮すると、価値の生産者は従業員だと認めることができる。価値の保守・持続・強化の方法を理解した従業員は、組織のなかで最も重要な資産である。幸せな従業員の生産性は高い。

それぞれのKVAの例は、付録に記載している。

市場に出すまでの時間(T2M: Time-to-Market)

新しい機能、サービス、プロダクトをすばやく提供する組織の能力を示す。

市場に出すまでの時間(T2M)の目的は、組織が価値を提供するためにかかる時間を最小化することである。T2Mを積極的に管理しなければ、これからも価値を持続的に提供する能力があるとはいえない。組織がT2Mを継続的に評価するために必要な質問を以下に挙げる。

  1. 組織は新しい実験からどれだけ早く学ぶことができるか?
  2. どれだけ早く新しい情報から学び、取り入れることができるか?
  3. どれだけ早く顧客に価値を届けることができるか?

T2Mを向上させるものはさまざまである。たとえば、社内のコミュニケーションのボトルネックの解消、デリバリーパイプラインの自動化の改善、アプリケーションの保守性の向上、技術的負債の排除などがある。つまり、待機時間や仕事の遂行時間を短縮するものすべてが該当する。

イノベーションの能力(A2I: Ability to Innovate)

顧客のニーズをうまく満たせるような新しい機能を提供するプロダクト開発組織の能力を示す。

イノベーションの能力(A2I)を見る目的は、新しい機能を提供したり革新的なソリューションを提供したりする組織の能力を最大限に引き出すことである。組織がA2Iを継続的に評価するために必要な質問を以下に挙げる。

  1. 組織が新しい価値を提供することを妨げる要因は何か?
  2. 顧客やユーザーがイノベーションの恩恵を受けられなくする要因は何か?

チームが新しい機能や価値を提供することを妨げるものはさまざまである。たとえば、欠陥の修正や技術的負債の排除に時間をかけすぎる、複数のブランチやバージョンを保守する必要がある、アプリケーションアーキテクチャが複雑だったりモノリシックだったりする、本番環境のようなテスト環境がない、オペレーショナルエクセレンスの欠如、コードマネジメントプラクティスが貧弱、分散型意思決定の欠如、有能で情熱的なチームメンバーを教育・雇用できない、などがある。価値の低い機能やシステムの障害物が累積すると、プロダクトの保守や障害物の排除に予算や時間が消費され、イノベーションの能力が低下していく。また、ソフトウェアのインストールが難しい、インストールしたいと思えるほどの機能がないなど、ユーザーや顧客がイノベーションの恩恵を受けられなくする要因によってもA2Iは低下していく。

未実現の価値(UV: Unrealized Value)

潜在的なすべての顧客のニーズを完全に満たせば実現可能な将来の価値を示す。

未現実の価値(UV)を見る目的は、これから組織がプロダクトによって実現するであろう価値を最大化することである。組織がUVを継続的に評価するために必要な質問を以下に挙げる。

  1. 現在の市場または他の市場で、組織は追加的な価値を創造できるか?
  2. 未開拓の機会を追求する労力とリスクに価値はあるか​​?
  3. 追加的なUVを獲得するために追加投資すべきか?

これらの質問は、他のプロダクトのUVと切り離して答えられるものではない。あるプロダクトに投資するという決定は、他のプロダクトに投資しないことを意味する。CVとUVの両方を考慮することで、組織は現在と将来のメリットのバランスをとることができる。

たとえば、市場のテストのために使用されている初期バージョンなので、CVが低くなっているプロダクトであっても、市場の可能性が高いことを示すことができれば、UVは非常に高いものとなる。CVが高くなくても、潜在的なリターンが見込めるのであれば、CVを向上させるためにそのプロダクトに投資することが認められることもあるだろう。

逆に、CVが非常に高く、市場シェアが大きく、競合他社がおらず、顧客が非常に満足しているプロダクトは、追加の投資は認められないだろう。これは、利益性は高いが、プロダクトの投資サイクルは終わりに近づいている古典的な「金のなる木」のプロダクトである。

先行指標と遅行指標

先行指標は、KVMの変化を比較的すばやく検知して、高速な反応を可能にする。遅行指標は、しばらくあとになってから変化を示す。指標は本来、先行指標でも遅行指標でもないが、計測の頻度によっていずれかになる。したがって、収益を毎日計測するなら、それは先行指標となる。毎月あるいはさらに頻度が少なければ、それは遅行指標となる。

真の先行指標ならば、遅行指標から報告される成果を推測できる。たとえば、ビルドや統合の成功は、リリースの安定性や予測可能性を示す有望な予測因子である。

顧客満足度の先行指標は入手が困難だが、利用データをプロキシとして使えばいい。トランザクションの放棄率を見れば、アクティビティが正常に完了したかどうかを把握できる。シンプルな利用データであっても、少なくとも機能が使用されているかどうかは把握できるだろう。場合によっては、プロダクトの利用方法についても把握できる可能性がある。

満足度の計測は、情報を収集する時間によって、先行指標にも遅行指標にもなりうる。たとえば、「従業員の満足度」の先行指標ならば、退出前に「今日の仕事はどうでしたか?」などの簡単な質問に答えるボタン😀😐🙁を押すことで情報を収集できる。

「従業員1人あたりの収益」やプロダクトの収益性を計測する「プロダクト比率」のような真の遅行指標は、さまざまな要因の影響を受けるため、プロダクトがうまく価値を生み出せたかという一般的なことしか把握できない。

指標を検査するときは、相関関係と因果関係を区別することが課題となるだろう。指標の変化の真因を探る仮説を導くために、意義のあるデータ駆動の会話をするためには、人間の判断とボトムアップの知性が必要になる。こうした会話は、指標を望ましい方向に変えるための、新しい行動につながるインサイト、仮説、実験を引き起こす可能性がある。

EBMを使って実証的に改善する

「どっちに行くのかわからなければ、どっちの道へ行ったって大した違いはないさ」
― ルイス・キャロル

KVAを計測するだけで、いくつかの改善が始まる。すぐに改善機会が示されるからだ。体系化されたアプローチを使用すれば、組織はソフトウェアの投資からもたらされる価値を継続的に学習・改善することができるため、さらによい結果がもたらされる。本物の長期的な改善を生み出すために、以下の学習ループを確立してもらいたい。

1. 価値を定量化する

EBM学習ループの最初のステップは、価値をKVMとして定量化することである。KVMそのものを定義してそれに合わせるプロセスは、組織にとって有益なものとなるだろう。最適化すべきものの周囲に透明性を生み出すからである。

2. KVMを計測する

EBM学習ループの次のステップは、関心のあるKVMの初期値またはベースラインを確定することである。このステップは、プロダクトの実用可能性と、組織がプロダクトを提供する能力について、初期の視点を提供する。そして、相対的な長所と短所の周囲に透明性を生み出す。

3. 改善するKVAを選択する

現在の組織の価値とそれを明らかにする指標を明確に理解することで、ソフトウェア組織のマネージャーは、どのKVAを変化させるのが最も有益かについて、情報にもとづいた決定を下すことができる。

ひとつの学習ループで多くのKVAに影響を与えないようにしてほしい。一度に多くの要因を変えようとして改善や計測が遅くなるよりも、漸進的な小さな変化によってすばやく結果を計測するほうが優れている。同時に複数の要因を変えてしまうと、活動と成果の因果関係を把握するのが困難になる可能性もある。短いサイクルと少しの変化が、組織全体のアジリティを持続的に改善する最も効果的な方法である。

4. 対象となるKVAを改善する実験をする

改善するKVAを選択したら、効果があると思われるプラクティスをいくつか選択して(多すぎてはいけない)実験を始めよう。たとえば、品質を向上させたいソフトウェア組織は、欠陥のKVMを削減することにフォーカスするだろう。あるいは、開発チームのテストカバレッジや品質を向上させるために、テストファーストのプラクティスを導入しようとするだろう。

5. 結果を評価する

実験の結果を計測できたら、変更前のKVMと比較すべきである(ステップ4を参照)。実験によって改善が見られたら、その変更は継続する。改善が見られなかったら、別の改善に挑戦する。KVAが望ましい結果になるまで、学習ループを続ける。

結論

「計測できなければ改善できない」
―ピーター・ドラッカー

EBMのKVAは、プロダクトのデリバリーのパフォーマンスについて、全体的な視点を提供する。プロダクトが顧客やユーザーに価値を提供していなければ、生き残ることはできないため、CVが最も重要である。ただし、顧客やユーザーの体験は全体像の一部にすぎない。幸せで熱心な従業員がいなければ、顧客に届ける価値を持続および改善することは不可能である。また、幸せな投資家がいなければ、従業員が改善するのに必要な資金が不足する。

プロダクトが提供する価値をすばやく改善するには、新しい価値を頻繁に提供する必要がある。つまり、プロダクトのT2Mを改善する必要がある。仕事を高速化するというだけではない。高速化しても持続させることは困難である。そうではなく、障害物の把握と排除をすることが、高速なサイクルでデリバリーするのに必要不可欠なのである。

高速なT2Mで話は終わりではない。高速なリリースサイクルがわずかな改善しかもたらさないのであれば、プロダクトの価値を高速に向上させることはできない。組織のイノベーション能力は、リリースごとに重大なイノベーションを提供する能力によっても決まる。この能力を計測することで、組織は過去に囚われた障壁を取り除くために必要なインサイトを手に入れることができる。

組織のパフォーマンスを改善することは、周期的で反復的なプロセスである。現状の計測、パフォーマンス目標の設定、すばやく実行できる小さな改善の実験の作成、その影響を見るための再計測、それを何度も繰り返す。

注記

エビデンスベースドマネジメントは無料であり、このガイドによって提供されている。EBMの一部のみを導入することは可能だが、その結果はエビデンスベースドマネジメントではない。

謝辞

エビデンスベースドマネジメントは、Scrum.org、Professional Scrum Trainerのコミュニティ、Engagement Managerのコミュニティ、Ken Schwaber、Christina Schwaberによって共同開発された。

付録 — KVMの例

CV

  • 従業員1人あたりの収益:この比率(総収益 / 従業員数)は業界内の主要な競争指標である。業界によって大きく異なる。
  • プロダクトコスト比率:計測対象のプロダクトやシステムにかかる総費用およびコスト。運用コストも含まれる。
  • 従業員満足度:従業員のエンゲージメント、エネルギー、熱意を計測するのに役立つ感情分析の一種。
  • 顧客満足度:プロダクトに対する顧客のエンゲージメントと幸福度を計測するのに役立つ感情分析の一種。
  • 使用指標:機能別の利用状況を計測して、顧客がプロダクトをどの程度有益だと思っているかを推測する。また、機能にかける実際の使用時間が、期待と一致しているかを確認する。

T2M

  • ビルドと統合の頻度:単位時間あたりのビルド(統合されてテストされたもの)の回数。頻繁にあるいは継続的にリリースしているチームであれば、実際のリリース回数を計測する。
  • リリースの頻度:単位時間あたり(継続的、日次、週次、月次、四半期ごとなど)のリリース回数。これは、新規的で競争力のあるプロダクトにおいて、顧客を満足させるために必要な時間を評価するのに役立つ。
  • リリースの安定期間:開発者がリリースの準備ができたと言ったときから、プロダクトの問題を修正して、実際に顧客にリリースされるまでにかかった時間。これは、貧弱な開発プラクティス、その基盤となる設計やコードベースの影響を表すのに役立つ。
  • 平均修復時間:エラーが発見されてから修正されるまでの平均時間。これは、組織がエラーを修正するときの効率性を明らかにする。
  • サイクルタイム:リリース作業に着手してから実際にリリースするまでの時間。組織が顧客にリーチするための能力を計測するのに役立つ。
  • リードタイム:アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを享受できるようになるまでの時間。顧客やプロダクトによって、この指標は大きく異なる。顧客満足度の要因でもある。
  • 学習時間:アイデアや改善をスケッチして、構築して、ユーザーに提供して、その利用を学習するまでにかかる時間。

A2I

  • 使用指標:頻繁に使用されるプロダクトの機能を計測したもの。使用されない機能を特定するのに役立つ。
  • イノベーション率:新しいプロダクトの機能に費やした労力やコストを、すべてのプロダクトに費やした労力やコストで割ったもの。新しいプロダクトを提供する組織の能力についてのインサイトが得られる。
  • 欠陥のトレンド:前回の計測から欠陥の変化を計測したもの。欠陥とは、顧客、ユーザー、組織にとってのプロダクトの価値を低下させるものである。一般的には、意図したとおりに動作しないことを指す。
  • オンプロダクト指標:現在のバージョンのプロダクトを使用しているユーザーの割合。
  • インストールされたバージョンの指標:現在サポートしているプロダクトのバージョン数。これは、組織が古いバージョンのサポートや保守にかけている労力を表している。
  • 技術的負債:プログラミングにおける概念であり、「クイック・アンド・ダーティ」なソリューションをあとで修正することになったときに発生する、追加の開発やテストの作業を表したもの。
  • 本番環境のインシデントのトレンド:インストールされたプロダクトの問題を修正するために開発チームが中断された回数。インシデントの回数は、本番環境の安定性を示すのに役立つ。
  • アクティブなブランチ数、ブランチ間でコードをマージする時間:デプロイするバージョンが異なると、コードのブランチも異なるため、「インストールされたバージョンの指標」とよく似ている。
  • コンテキストスイッチにかかる時間:ひとりあたりの一日のミーティングの回数や、チームメンバーがチーム外の人を助けるために中断された回数がわかれば、問題の規模を把握するのに役立つ。

UV

  • 市場占有率:プロダクトが市場を占める相対的な割合。
  • 顧客(ユーザー)満足度ギャップ:顧客またはユーザーが望む体験と実際の体験の格差。


BY MARTIN ERIKSSON ON AUGUST 24, 2018

以下は、Martin Erikssonによる「Mastering the Problem Space for Product/Market Fit by Dan Olsen」の翻訳です。

Product/Market Fit(PMF:製品/市場フィット)という言葉は、2007年にMarc Andreesenが作り出した。それ以来、新製品やスタートアップにとって非常に重要な目標となっている。だが、バズワードというものは、過度に単純化され、誤解されてしまうものだ。『The Lean Product Playbook』の著者であるDan Olsenが「Mind the Product San Francisco」の講演において、PMFの主要部分とその達成方法について語ってくれた。

PMFのピラミッド

プロダクトや企業によって明らかに違いはあるものの、このフレームワークはPMFの達成に必要な普遍的な条件やパターンを網羅している。ピラミッドの各階層は、次の階層を構築するために検証すべき重要な仮説となっている。それが最終的には、PMFを達成することにつながる。

  1. ターゲット顧客 — 誰のために価値を提供しようとしているか?
  2. 満たされていないニーズ — ターゲット顧客のニーズは何か?
  3. 価値提案 — 「あなたのプロダクトがどの顧客ニーズを解決しようとしているか」「顧客があなたのプロダクトから受け取るベネフィット」「あなたのプロダクトが他のプロダクトよりもうまくニーズを解決できること」などに関する仮説。
  4. 機能セット — 上記のベネフィットを顧客に提供する機能。
  5. ユーザーエクスペリエンス — 顧客がベネフィットを得るためのインタラクション。

最初の2つの階層(「ターゲット顧客」と「満たされていないニーズ」)が「市場」である。ただし、市場をコントロールするわけではない。ターゲットにする顧客やニーズについては、自分で選択することができるが、これらのニーズを自分で変更することはできない。あなたがコントロールできるのは、ピラミッドの次の3つの階層である。つまり「プロダクト」だ。

問題空間と解決空間


BY JAMES GADSBY PEET ON DECEMBER 1, 2017

以下は、James Gadsby Peetによる「How High Performance Organisations Innovate at Scale by Barry O’Reilly」の翻訳です。

行動のあり方を変えることができれば、これまでとは違った方法で世界を体験できるようになるでしょう。そうすれば、考え方も変わります。Barry O’Reillyは「Mind the Product London 2017」での魅力的な講演のなかで、組織づくりにはこうしたことが常に求められると述べました。人々が問題なのではなく、人々の周囲に居座っている「システム」が問題なのです。

私たちが導入しているマネジメントプロセスやシステムは、市場のスピードや複雑さに合致していません。年次業績評価、四半期計画、予算編成といった方法では、効率的にビジネスを運営できるだけのスピードに対応できません。

大企業は、モバイルアプリや十分な資金をかけたディスラプティブ(破壊的)なアイデアを活用できないという結果は避けたい、と考えています。こうした問題の根源は、成果(アウトカム)ではなく結果(アウトプット)に対して報酬を出しているところにあります。

デリバリーのギャップを埋める

ベイン・アンド・カンパニー社による2005年の有名な調査「Closing the Delivery Gap」では、80%の企業が優れた提案をしていると答えています。ですが、それに同意している顧客はわずか8%です。組織を成功させるには、このギャップを埋めなければいけません。顧客の体験は「あればうれしい」というものではなく、組織の戦略の中心に位置づけるべきものです。

Barryは、これらの問題に対応している高パフォーマンス組織と一緒に仕事をするなかで、以下のような共通点を発見をしました。

  • テクノロジーは、顧客に関するイノベーション・テスト・学習をこれまで以上に可能にする戦略的な能力である。
  • 実験を可能にするために、仕事のプロセスやプラクティスを反復的・適応的にする必要がある。
  • 組織全体の学習不安を軽減すれば、新しい価値をもたらす新規的な事柄を試すことができる。
  • 大規模にイノベーションを実現する能力は、単一のチームに依存すべきではない(すべてのチームに組み込まれ、すべてのチームが責任を負うべきである)。他人の教訓に耳を傾け、そこから学び、それを自分たちの領域に適用する必要がある。

アジャイル開発、リーンスタートアップ、デザイン思考の情報を発信します。

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store