現在、アジャイルコーチやスタートアップのメンターなどに関する研究を行なっています。これらの活動がイノベーションにどのように貢献するかを明らかにするものです。アンケートやインタビューにご協力いただける方は、以下のURLをご参照ください。

ご協力よろしくお願い致します。

この記事は、Camilla Buchananによる「Prototyping for policy」の日本語訳です。Open Government Licenseの下に提供されています。

Prototyping for Policy(政策のためのプロトタイピング)」とは、2018年11月にThe Legal Design Labがスタンフォード大学d.Schoolで開催したカンファレンスの名称です。弁護士、政策立案者、技術者、デザイナーが集まり、戦略とデザインの世界がどのように出会うべきかについて、さまざまな側面から検討するというものでした。

「政策のためのプロトタイピング」の参加者の様子

プロトタイピングは、プロダクトデザインやインダストリアルデザインのプロセスにおいては一般的なものですが、サービスデザインなどの目に見えないデザインの分野にも応用されています。プロトタイプとは、アイデアやソリューションの解像度の低いモックアップであり、実装前にテストを可能にするものです。プロダクトであれば、ダンボールで作ったものをテストできます。ウェブサイトであれば、手描きのワイヤーフレームでテストできます。サービスのインタラクションは、ロールプレイでテストできます。

以下のエスプレッソメーカーのコンセプトスケッチとモデルは、インダストリアルデザインのプロトタイプの典型的な例です。

いかにしてサービスを守るか

この記事は、Kate Ivey-Williamsによる「Death by double diamond」の翻訳です。本人の許可を得て掲載します。

幸運にも私は、過去にコンサルタント会社において、そして現在は英国の政府デジタルサービス(Government Digital Service)において、サービスデザイナーとして働くことができました。2つの異なる環境で働いたことにより、サービスデザインが直面する課題と、適切にデザインしたサービスを提供するために必要なことについて、多くのことを学びました。

そうした課題はサービスの導入部分にあります。サービスデザインの業界は方法論を身につけています。我たちは適切にデザインされたサービスがどのようなものかを理解しています。そのために何が必要なのかもわかっています。ユーザーエクスペリエンスのシミュレーションやテストに役立つプロトタイプを作成することもできます。それなのに、サービスの導入の前に何かが起きているようなのです。サービスデザイナーがサービスの導入に関わることはほとんどありません。つまり、机上で慎重に作り上げてクライアントに手渡したものが、サービスの導入後に変化しているのです。

その原因の多くは、一般的に使用される「ダブルダイヤモンド」のプロセスが、ウォーターフォールの特性を持っているためです。ダブルダイヤモンドの最後の「提供」ステージのあとに起こるのは、サービスデザイナーが指示書をクライアントに手渡し、クライアント自身にサービスの導入を任せるというものです。これには数年かかることもあります。その結果、ステークホルダーのエンゲージメントがどれだけ高くても、導入後のサービスは当初のデザインとはまったく違ったものになります。

このようなやり方をしていると、サービスデザイナーの意欲は大きく損なわれます。オリジナルのビジョンを踏襲した形で導入されるという確信もなく、デザイナーが壁越しに成果物を放り投げているというような状況です。これはサービスデザインの業界にとっても大きな問題です。現実世界で「我々があれをデザインした」と言えなくなるため、デザインの品質をベースにして自分たちの仕事の価値を売り込むことが難しくなるのです。その結果、現実世界の事例ではなく、方法論を売り込むことになります。こうした方法論には導入部分は含まれていません。サービスを導入するときの課題はそれぞれ異なるため、テンプレートを作るのが難しいからです。

ですが、サービスデザインは方法論ではありません。サービスデザインはサービスのデザインです。グラフィックデザインがグラフィックのデザインであり、プロダクトデザインがプロダクトのデザインであるのと同じです。

サービスデザインの組織のなかには、トレーニングを販売してサービスの導入に影響を与えようとしているところもあります。トレーニングを実施しておけば、クライアントにデザインを手渡して離れたあとでも、サービスデザインを維持できると考えているのです。これには不幸な副作用があります。サービスデザインのコンサルタント会社が冗長で不要だと思われる可能性があるのです。多くの人たちがサービスデザインを理解するのは素晴らしいことです。ですが、1週間のトレーニングは、長年培った調査や業界の経験と等価ではありません。

ダブルダイヤモンドのプロセスに従い、サービスデザインの手法を使用するように教えるのではなく、組織がサービスを提供できるように、みなさんがサービスデザイナーとしての能力を高める必要があります。そして、それを実現するには、サービスの導入部分に関与する必要があります。

ウォーターフォールではうまくいきません。事業会社でもコンサルティング会社でも、サービスデザインの組織はますますアジャイルに移行しています。

アジャイルのおかげで、サービスデザイナーはサービスの導入部分に近づくことができます。そのための方法はいくつかあります。まずは、サービスデザイナーが現実世界に向けてデザインできるようになります。なぜなら、最初から現実世界で仕事ができるからです。サービスデザイナーは提案書を作成して、最後にそれを手渡すだけの存在ではありません。

アジャイルは反復的なプロセスです。つまり、プロセスの途中で(サービスが導入されるまで)サービスデザインを曲げたり変えたりできるということです。実際に動かして反応を見ながら、最高にデザインされたサービスを生み出すことができるのです。

アジャイルでは、特定の手法や「成果物」との結びつきが少なくなります。プロジェクトのステージごとに課題と対策を踏まえながら、アプローチを選択・変更していくことができます。

アジャイルを使うのはインハウスデザイナーのほうが簡単です。事実上、デザイナーであり、クライアントでもあるからです。ですが、コンサルティング会社もこの方向に進み始めています。私が以前勤務していたコンサルティング会社では、業務委託のような形でクライアントとの関係を構築し始めていました。つまり、ダブルダイヤモンドの「発見・定義・開発・提供」を売り込むのではなく、柔軟な契約と予算に移行していたのです。アジャイルにプロジェクトの計画を立案することで、戦略からサービスの試験運用に至るまで、組織に合ったペースでクライアントと協力しながら仕事ができるようになりました。また、サービスデザイナーはほぼフルタイムでクライアントと同席していました。そして、上層部のステークホルダーと協力しながら、デザインしたサービスの準備や提供ができているかどうかを確認していました。

サービスデザインは「提供」で終わりではありません。「導入」で終わりでもありません。サービスは進化を続ける反復的なものです。サービスデザイナーが影響を与えるには、すべてのステージに関与する必要があります。

Kate Ivey-Williamsは、英国のGovernment Digital Serviceのサービスデザイナーです。以前は、ロンドンでEngine Service Designのサービスデザイナーとして働いていました。

2020年10月のことになりますが、『Clean Agile』という本を訳しまして、その著者であるアンクルボブにインタビューした動画が公開されました。

人前でしゃべったりするのは苦手なんですが、最近はオンラインで何かやる機会も増えてたことだし、そんなことを言っていてもダメかなと思うようになりまして、とりあえずPodcastをはじめてみることにしました。

#1 Clean Agile and Tokyo Tech EDP

初回はその『Clean Agile』について軽く触れたあとに、講師として参加している東京工業大学エンジニアリングデザインプロジェクトについて話しました。

#2 Travels and Translations

2回目はGoTOトラベルキャンペーンを使った話、朝ドラ「ちりとてちん」が大好きで聖地巡礼した話、ドーミーイン大好きな話、「スクラムガイド2020」と『達人プログラマー第2版』の翻訳について話しました。

#3 Information and Task Management

3回目は情報管理やタスク管理について話しました。

とまあ、こんな感じで週1くらいで配信していきたいなと思っています。

複数のプラットフォームで配信しているので、ぜひ登録してみてください。

この記事は、Sanjay Poyzerによる「Become a service designer in government: step by step」の日本語訳です。Open Government Licenseの下に提供されています。

公共サービスのデザインは、私がこれまでに経験したなかで最も意義があり、最も満足のできる、最もやりがいのある仕事です。政府のやっていることの背景にある真の意図を考え、大きく改善されたアウトカムを国民に届けられるように、公共サービスに携わる方々をガイドしています。

「どうやってこの仕事に就いたの?」とよく聞かれます。私の話をしてもよいのですが、みなさんが本当に知りたいのは「サービスデザイナーになることは可能なのか? 可能だとしたらどうやって?」なのでしょう。そこで、GOV.UKのようなステップ式のガイドを作成しようと思いました。

1. いろんなことに関心を持つ

私の知る優れたサービスデザイナーたちには、印象的な特徴があります。それは、世界について、そこで生活する人たちについて、それらすべてがどのように動いているかについて、執拗とも言うべき大きな関心を持っていることです。たとえば、Harry Vosは商品の物流について独自の考えを持っています。Kay DaleはDIYが本当に大好きです。Lou Downeはセーリングからゲリラガーデニングに至るまで、あらゆることに取り組んでいます。

物事に関心を持つことは、物事をよりよくするための最初のステップです。何かに興奮すれば、そこからアイデアが生まれてきます。サービスデザインとは、以前とはまったく違うアイデアを持つことだとされますが、それは新しいアイデアではありません。すべてはどこからか盗んできてたものなのです。私が興奮するのは、どこからか何かを取り入れて、それを新しい文脈に持ち込んでいるときです。そのためには、大きな関心の「パレット」を持つ必要があります。本を読んだり、映画を見たり、面白い人たちと話したりしてください。すでに関心のあるスレッドをフォローして、世界がどのように動いているかをもっと詳しく知りましょう。

2. 何らかのデザイン理論を学ぶ

みなさんは(おそらく)研究者になりたいわけではないでしょうから、ここでは意図的に「何らかの」という言葉を使いました。あらゆるデザインの専門分野において、優れたデザインの基本原則を理解することは必要不可欠です。私の専門は音楽でした。そこから多くの重要なスキルを学びました。それらは今でも使っています。たとえば、誰かと一緒に仕事したり、アイデアを生み出して反復させたりするスキルです。あるいは、観客とクリエイターの関係性を理解することも重要です。デザイン理論に関しては、私は以下のような本を読みました。

  • 誰のためのデザイン?(ドナルド・A・ノーマン)
  • Research & Design Method Index―リサーチデザイン、新・100の法則( Bella Martin and Bruce Hanington)
  • ハマるしかけ―使われつづけるサービスを生み出す[心理学]×[デザイン]の新ルール(Nir Eyal)

これは網羅的なリストではありません。あくまでも私の役に立ったものです。私は「GOV.UK Service Manual」や「Design in government blog」からも多くのことを学びました。すでに公共セクターで働いている方は、GDSで開催しているトレーニングコースに参加してみてはいかがでしょうか。

3. サービスとそのデザイン方法について学ぶ

最近はちゃんとしたサービスデザインのコースが(Royal College of Artなどに)ありますが、私はそのようなルートを通っていません。

無料または安価なミートアップやイベントがあったおかげで、私は多少なりとも音楽の分野からテクノロジーの分野に移行できました。サービスデザインを学ぶための優れた方法は、このようなイベントに参加することです。たとえば、Global Service JamsService Design Fringe FestivalGovJam(労働・年金省が支援)などのイベントがあります。

ただし、このことは理解しておいてもらいたいのですが、サービスデザイナーに適した規定のアウトプットなどありません。あるのはよりよいサービスだけです。 ジャーニーマップ、ブループリント、ワークショップなどは、 そこにたどり着くまでに使用するツールにすぎません。

Design Councilがこうしたツールを紹介してくれています。ですが、全体的な「ダブルダイヤモンド」はかなり規定的なものになっています。この危険性については、Kate Ivey-Williamsの記事を読んでみてください。GDS Service Designトレーニングによるリーディングリストも素晴らしいです。

ある時点から「サービスとは何ですか? どうすれば優れたサービスになるのでしょうか?」と質問したくなるかと思います。この数年、GDSでは何度もこのような質問をしてきたために、サービスの実用的な定義優れたサービスの特徴のリストを作成することができました。

4. 何かを届ける

サービスデザインは不思議な仕事です。マネジメント職でもないのに、ロゴやコードなどを指して「あれは私がやった」と言うことができないのです。これがサービスデザインの最大の欠点だと思うこともあります。私は何も生み出してないじゃないかと感じるのです。ですが、サービスデザインはチームスポーツです。私のやっていること(たとえば、実践的でありながら広い視野を持ち、野心的であるようにみんなを説得すること)は、実際に生み出されるものに大きな影響を与えています。

その方法を教えてくれたのは、スタートアップの経営でした。時間とお金がすぐに尽きてしまう環境で誰かのために何かを成し遂げることの本当のプレッシャーを教えてくれました。また、Bethnal Green Venturesのサポートを受けたことも幸運でした。サービスデザイナーを含むメンターを派遣してもらい、現場でサポートを受けながら学ばせてくれたのです。また、その頃にEric Riesの『リーン・スタートアップ』を読み「実用最小限の製品(MVP)」が何であるかを学びました。しかし、本当に重要なのは、自分の周りにいる人たちを集め、誰かの問題を本当に解決できるものを作ってもらうことです。そして、それがどのように使われるかを観察して、何度も繰り返していくのです!

2019年度の東京工業大学エンジニアリングデザインプロジェクトの作品のひとつ「UROBON by チーム窓」を、二子玉川の「蔦屋家電+」に出展することになりました。2020/3/14から5月中旬までの2か月ほど展示予定ですので(追記:7/14まで延長となりました)、ぜひご覧になってください。作品の詳細は以下になります。

今回の出展のきっかけは、前期の授業のテーマを「新しい家電のユーザー体験をデザインせよ」にしたことでした。そのときに、授業で終わらせるのはもったいないので、最終的な作品を家電量販店にディスプレイさせてもらったらおもしろいよねーという雑談を教員同士でしていたのでした。

ところが、雑談レベルで終わるのかと思いきや、東工大のある大岡山駅近隣でめぼしい候補を見つけ、蔦屋家電+にターゲットを絞り、先方にコンタクトして、出展用の予算を確保して……という感じで話がするすると進み、最終的には2月の発表会の様子を見て、全8チームのなかから本作品を選出することになったのです。動こうと思えば動けるものですね!

(なお、他にも出展したい作品はあったんですが、初年度ということで、ひとまずこちらの1作品に絞っています。)

こうして社会とつながりができることは、学生のモチベーションにもつながったようで、チーム窓は発表会後もプロダクトに手を加えています。以下の写真を見ると、発表会のときよりも洗練されていることがわかります。

東京工業大学エンジニアリングデザインプロジェクトでは、来年度以降もこのような活動を続けていきます。また、開発のテーマとチームの活動資金をご提供いただける「パートナー企業」も絶賛募集しておりますので、ご関心のある担当者の方は、ぜひお問い合わせください

以下は、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を表しています。スイッチのトリガーは、新しいソリューションの可能性をもたらす期待違反を生み出します。

雇用は最初の戦いにすぎない

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

大学でデザイン思考を教えているというのは、今どきはぜんぜんめずらしいことではなく、世界中にデザイン思考の授業があるそうです。ただ、同じ「デザイン思考の授業」といっても、たとえば機械系と経営系と情報系では、それぞれ重視する部分がまったく違っています。

せっかくなので、それらのシラバスを見比べてみて、似ているところと違っているところを見つけてみてはどうか? そしたらデザイン思考の本質がつかめるんじゃないの? 理想的なデザイン思考の授業が作れるとよくない?……という感じの論文(プロシーディング)がありました。

Wiesche et al., “Teaching Innovation in Interdisciplinary Environments: Toward a Design Thinking Syllabus.”
https://scholar.google.co.jp/scholar?cluster=6329497326857230509

ここでは、典型的なデザイン思考の授業が時系列に「8つのフェーズ」として設定されています(下図参照)。

基礎知識の習得やチームビルディングを目的とした「Formation」から始まって、プロジェクト全体で「Design Space Exploration(デザイン領域の探索)」を行いながら、あとはひたすらプロトタイピングをしていく感じです。プロトタイピングの部分については、以前書いた「プロトタイプであそぼう」の内容と一致しています。

では、それぞれのフェーズにおける「似ているところ」を見ていきましょう(詳しい内容については、元の論文を参照してください)。

1. Formation

  • デザイン思考基礎:最初にデザイン思考の基礎知識を習得します。
  • ペーパーバイクチャレンジ:チームビルディングの一環として、紙のバイクをみんなで作り、実際に走らせてみるアクティビティです。でも、これってスタンフォードのME310でしか聞かないけどなあ……。経営系のデザイン思考の講義でこんなことはやらないと思います。

2. Design Space Exploration

  • デスクリサーチ:デザイン思考の講義では「リアルな課題」を扱うために、企業などからテーマ(デザインプロンプト)が与えられることが一般的です。まずはそのテーマについて調べてみましょう、というのがこれですね。とはいえ、何も知らない状態で、まずはユーザーリサーチしてみたほうが「デザイン思考っぽい」なあと思います。
  • インタビューリサーチ:普通ですね。
  • ペルソナ:まあ、普通ですね。でも、EDPではジョブ理論のほうがよいと思っているので、この時点でペルソナは使わないようにしています。
  • ステークホルダーマップ:テーマが難しいときや関係者がたくさんいるときは最初に使ったほうがいいですね。
  • ベンチマーキング:これは市場調査なのかな?と思いきや、他の分野や業界からアイデアを転用する、みたいな説明が書いてありますね。類推思考は非常に強力なので、ぜひやったほうがいいと思います。
  • アイデアナプキン:アイデアを殴り書きするのかと思いましたが、そういうわけではなく、テンプレートを用意してそれに記入していく方式らしいです。検索するとこういうページが見つかりました。特に学生が相手だと、テンプレートを用意したほうが授業がスムーズに進みます。
  • ストーリーボード:アイデアによってユーザーの行動がどう変わるのか?というのを物語にするものです。まあ、普通に使いますね。EDPだと、Story Spineを物語のテンプレートに使っています。

3. Critical Function

  • 低解像度のプロトタイプ:局所最適化しないように、かんたんなプロトタイプをたくさん作る感じです。ここはデザイン思考の最も大きな特徴かもしれませんね。
  • テスト:プロトタイプを作ったら当然のようにテストします。

4. Dark Horse

  • ソリューション空間の探索:何らかのプロトタイプを作った時点で、自分たちが勝手に想定していた「思い込み」を特定していきます。
  • 思い込みを捨てる:思い込みが特定できたら、それを捨て去るような斬新なアイデアを考えて、そのプロトタイプを作ります。これが「ダークホースプロトタイピング」を実施する狙いです。

5. Funky

  • ビジネスモデリング:プロトタイピングであれば、これまで作ったものを統合すべきところですが……ここではビジネスモデルキャンバスなどを作り、経済性を評価するといいのでは?と提案されています。

6. Functional

  • ペルソナとインサイトを再構築する:ここから重要なユーザーのためにプロダクトを洗練させていくことになるため、その「重要なユーザー」をペルソナとして改めて設定します。

7. X-is Finished

  • ユーザーエクスペリエンス:最も重要な機能をきちんと動くように作るところです。この段階になると、使い勝手や意匠にも気を配る必要がでてきます。それらをまとめて「UX」としているのでしょう。

8. Final Prototype

  • ビジネスモデル、ストーリー、ドキュメントのレビュー:これまで獲得・作成した情報を整理して、最終的なプロトタイプを洗練させていきます。

授業としてはこれで終わりです。その後、発表会やピッチコンテストなどを実施するところもあるでしょう。スポンサー企業がいる場合は、企業向けのプレゼンをすることもあると思います。

上記の「似ているところ」には登場していませんが、もうひとつ重要なポイントとして「チームの自律性を重視するのか、それとも計画的に授業を進めるのか」があります。学生のモチベーションが高ければ前者が好ましいわけですが、そうとも限らないのが大学の授業です。宿題として「これをやってきてください」と明確に指示を出すこともときには必要になってくるでしょう。デザイン思考が扱う「Wicked Problem(厄介な問題)」は計画どおりに進まないことが特徴なのですが……まあ、仕方ありません。

身も蓋もない結論としては「両者のバランスをうまくとりましょう」になっちゃうんですけども、その手段としてここでは「マイクロサイクル」が提唱されています。巷でよく見るデザイン思考の「5ステップ」とほとんど同じですね。

角 征典 (@kdmsnr)

ワイクル株式会社 代表取締役 / 東京工業大学 特任講師 / 翻訳『リーダブルコード』『Running Lean』『Team Geek』『エクストリームプログラミング』他多数

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