112
134

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

エンジニアのための「ジョブ理論」まとめ

Posted at

はじめに

「イノベーションのジレンマ」で有名なクレイトン・クリステンセンの最新著作「ジョブ理論」。いわゆるビジネス書の類ですが、なんか話題になってるな……ぐらいに認識してる人はエンジニアでも多いのではないでしょうか。
市場価値の高い(=ビジネス的な競争力につながる)エンジニアスキルを身につけるという観点ではこの手の本を読むことも役立つと思うので、そのエッセンスまとめてみます。
以下、箇条書きが本書に書かれていることの概要、平文が感想というか私なりの解釈です。

要はどんな本?

  • イノベーションを起こすには
  • ユーザが片付けるべき"ジョブ"に着目して
  • それを片付ける最適なプロダクトと組織を作ろう

「イノベーションのジレンマ」等で語られてきた"破壊的イノベーション"をどうやって起こせばいいの?という問いに対する回答、という位置づけの本です。確かに「イノベーションのジレンマ」は読んでなるほど感はあるものの、とは言え何をどう破壊すればよいのかわからず結局持続的イノベーションを続けるしかとるべき道がないくて結果憂き目にあう……というのはまあ心当たりのある人もいるでしょう。
本書はまだ十分に片付けられて(解決されて)いないユーザの"ジョブ"を特定し、それを最適に片付ける方法を組織としてイノベーションを実現するための指針を示すものになります。

ジョブってなんなの?

人が成し遂げようとする"進歩"とその"状況"

  • e.g. "朝車で通勤するユーザにとって、車内で目を覚まさせて時間を潰すこと"
    • →そのジョブを適切に片付けるのは、片手で飲めてカップホルダーに置け、腹持ちがして飲むのに時間がかかる濃厚なミルクシェイク
  • "ニーズ"より複雑な事情=機能的・社会的・感情的側面文脈を考慮する
    • e.g. 同じミルクシェイクでも状況によって片付けるジョブは異なる
  • ジョブは継続し反復するもの

その進歩を実現する(ジョブを片付ける)プロダクトやサービスを作ろうということなのですが、個人的には "課題"とは表現しない ところがすごく刺さりました。"課題"と書くと、なにかマイナスの状況があり、その"解決"となるとそのマイナスをゼロにするような感覚をもちます。ただそうするとエンターテインメントのような、ポジティブな感情をもたらすものはどう位置づけるべきなのか?……というのがずっと腑に落ちていませんでしたが、"進歩"(原文はprogressなのかな?)ということであればゼロから(あるいはすでにポジティブな状態からさらに)ポジティブな状態へともたらすものもフォーカスに入ってきます。実際、本書にも映画のピクサー社の例が出てきます。

形容詞ではなく動詞と名詞で表現

  • e.g. "便利な"はダメ
  • 他の製品カテゴリにも解決策のライバルが存在しうる程度の抽象度
    • e.g. "朝車で通勤するユーザにとって、車内で目を覚まさせて時間を潰すこと" → ミルクシェイク、バナナ、ドーナツ、スニッカーズ、……(ミルクシェイクにとってはファストフードでもドリンクでもないカテゴリの食品がライバル)

このポイントは本書の最後の方に補足的に出てきたのですが、形式的な定義を好むエンジニアとしては「こういうのもっと先に!」と思ったのでした。
より良い製品=より良い解決策、ということでbetter, faster, cheaper(うまい、早い、安い的な)なソリューションというのはパッと思いつくものですが、これらはすべて既存の改善に過ぎないため、イノベーションという観点では適切なジョブの記述ではないでしょう。
また、 他の製品カテゴリが競合になる程度の抽象度 という点は、競争軸を変えるという意味でも重要なのだと思います。例えばiPhoneの競合は既存の携帯電話ではなく、結果的にPCやデジカメ、携帯音楽プレーヤーだった、というように。

どのようにジョブを特定するか?

  • 5つのヒント
    • 身近な生活の中
      • e.g. 楽しく簡単に学びたい → オンライン学習動画カーン・アカデミー
    • 無消費
      • e.g. 格安な宿⇔空き部屋の有効利用 → Airbnbがなければ旅をしなかった人が40%
    • 間に合わせの対処策
      • e.g. 貯蓄の仕組みを子供に教えるのに通常の口座だと最低預金額があったり…… → INGダイレクトの新商品
    • できれば避けたいこと
      • e.g. 多分大したことがない体調不良で医者にかかりたくない → CVSミニッツ・クリニック
    • 意外な使われ方
      • e.g. 食品添加物だった重曹を掃除や洗濯に
  • ユーザの購入(big hire)、利用(little hire)両方のストレスに敏感に
  • 人の観察からジョブの観察へ
    • なぜその選択をしたのか、が重要
  • ユーザインタビューでは広さより深さを

本書で一番肝となる部分ですが、正直ここに関する記述は個人的には満足できる内容ではありませんでした。記述されている事例も結果論的にはなるほどそういうジョブもあるよね、というような。ただ既存のビジネスを分類するには役に立ちそうではあります。
もっともここが一筋縄ではいかないからこそイノベーションは簡単ではないとも言えそうです。上記箇条書きに書いたようなヒントはあるので、顧客(候補)のインタビューでこれらの観点でなぜ・なぜを繰り返して仮説を作っていくことになるのだと思います。ここらへんは私は未読ですがリーン顧客開発あたりが参考になるのかも。
ちなみに新たなジョブを見出すヒントの中の"無消費"ですが、この手の活動を始めたばかりのときはマジで何も無い領域に無理やり解決策を作り上げて 「ブルーオーシャン()です!」 と言ってみたものの実は誰も欲しがらない現実を突きつけられる、というのがあるあるなので注意が必要……否一度は体験しておくべきです。もちろん、プロダクトをリリースして大怪我をする前に。

解決手段=体験の構築

  • 詳細で明確なジョブスペックを作る
    • 機能的・感情的・社会的側面からの記述、トレードオフ、競合、障害物など
  • 数字や統計ではなくストーリー
  • ユーザは何を雇用して何を解雇するか?(代替手段たりうるか?)
  • 購入だけでなく利用の状況も考える
    • 物理プロダクトであってもサービス
  • 究極の姿はジョブと同義の"目的ブランド"化(e.g. ググる)

ではどんなプロダクトを作ろうか!……というところの記述があっさりなのが本書の位置づけを明確にしている気がします。要はジョブを詳細に記述できたら、もはや(技術的な実現のハードルなどはあるかもしれないが)提供すべきものは自明、というわけです。多分。
そんな中でピンときたところは、前項"間に合わせの対処策"パターンでプロダクトを提供しようとする場合、 不十分なプロダクトを解雇して、新たに自社のプロダクトを雇用してもらわなくてはならない というハードルがあるということです。更には変化に対する抵抗も人間の本質としてあるので、その活性化エネルギー的なものを乗り越えなくてはいけないのもイノベーションの難しいところでしょう。またそのような乗り換えという観点で、"便利な"のような形容詞的表現でしかジョブを記述できていないとすると、結局は程度問題の競争優位であって、少なくとも競争のルールを変えるようなプロダクトはできない、と読み取りました。
またパッと見使えそうな商品でも、いざ買ってみたら結局殆ど使わずに放置……ということはよくあるでしょう。これはこの商品は本来片付けるべきあなたの"ジョブ"を正しく捉えてなかった(=ソリューションとして適切ではなかった)ということです。本書では購入するときを"big hire"、利用するときを"little hire"と表現し、ユーザ体験の重要性を説いています。これは目新しいことではなく、流石に浸透してきているのでは……と思いますが、改めて少し違う切り口で説明しているのはスペック表主義的製造業にとどまっている企業もまだまだ多いことの裏返しなのでしょう。

組織とプロセスの設計

ジョブスペックが差異化になる

  • ジョブは持続可能なイノベーションの"北極星"、自律的に(適切に)動くためのもの
  • ジョブスペック(⇔プロダクトスペック)とそれに最適化された組織・プロセスは共有されない
    • プロセス=資源を価値に変換する過程全て

デザイン思考などの本とは決定的に違うと感じたのは、プロセスや組織に踏み込んで継続的にマネジメントしていくための指針が示されている点です。プロダクトやサービスそのものは比較的簡単に真似されてしまいますが、それが片付けようとしているジョブそのものは(それを片付けるプロダクトにある程度表れるとは言え)ダイレクトには他社には記述できず、さらにはそのジョブを最短経路で片付けるための組織やプロセスは基本表に出ないし一朝一夕に作りうるものではないので競争力になりうる、という主張です。これはプロダクト作りに過度にフォーカスしてしまう組織に対してマネジメントの重要性を説得的に示すものだと感じました。
また最適性という以外に、組織のモチベーションにも言及されています。これは私自身新規事業立ち上げの活動の中で感じたことですが、インタビューなどを通じてその人のジョブ(当時は"課題"として認識)が明らかになってくると、その先の課題解決のためのプロダクトづくりのフェーズで「少なくともあの人は喜んで使ってくれるに違いない」というのが非常に心強く感じるものです。不確実性の海を泳いでいくには、そういう"光"のようなものがあるのと無いのでは気持ちの上で大違いです。

データの誤謬に気をつけろ

  • 成長していくとプロダクトが生み出す"能動的データ"に目が行き、ジョブを語る"受動的データ"が隅に追いやられる
    • そして自らをプロダクト視点の狭い市場に縛ってしまう
  • データには必ず仮説と抽象化が伴うもの。そこで生じる誤謬を意識する

「リーン・スタートアップ」でも"虚栄の評価基準"という呼び方で見かけのデータに騙されてはいけない……と警告されていましたが、本書でもジョブという観点でデータの扱いには気をつけるべし、と書かれています。
ここの"能動的データ"・"受動的データ"という言葉の使い方が解釈しづらかったのですが、要はジョブスペックは放っておいて観測されるものではなく、既に見たように丁寧な観察やインタビューによって掘り起こされる"受動的な"ものです。一方で一度プロダクトをリリースすると、ユーザ数や売上など見るからに大事そうな(能動的に主張する)データがどんどん集まってきます。その数字に惑わされると、ジョブから目が逸れてしまい危険だ……ということです。
また猫も杓子も"ビッグデータ"と騒いでいた頃に(今もまだ?)多大なるコストを掛けて学んだ人も多いのではないかと思うのですが、何らかのデータを取るためには目的がなくては意味がない、またその目的も「このデータをこう取れば○○ができるはず」という仮説と抽象化に基づいており、例えば頻度や粒度、あるいはデータの項目自体仮説の検証結果によって変更していかなくてはいけないものです。そのズレ(誤謬)がビジネスの根幹で現れうるよ……というのが本書での警告という理解です。

補足

その他、本書を読んでて私が感じたことを。

"理論"という呼び方はとりあえず忘れとけ

もしかしたら本書のタイトルからすごく体系だった何かを期待する人もエンジニアと言うか理系の人の中にはいるかなと。
あくまで考え方やプロセスに対するフレームワークであって、失敗する確率を下げるやり方に関する書籍です。原題も Competing agains luck ="運と競う"、つまり運任せにせずに不確実性を低めるのが本質です。逆に言えば銀の弾丸は(当然)無い、ということです。

デザイン思考とかリーンスタートアップとかと違うの?

共感を持ってジョブを特定する、ときにエスノグラフィ的手法を用いて……となると、デザイン思考を思い出す人も多いのでは無いでしょうか。これは本書の中でも触れられていますが、ジョブを特定するシーンに置いて、ユーザの体験を共感を持って記述する、という方法論はそのまま適用できるもので、補完しあう関係でしょう。
また、ジョブ理論の特徴は、イノベーションにフォーカスしていることです。同じように不確実性の中で新規事業を立ち上げるための方法論としてリーン・スタートアップがありますが、リーン・スタートアップは基本的には狙うべきビジネスの大小は問題にしていません。また、組織論的なところに踏み込んでいるのもジョブ理論の違いだと思います。

まとめ

すべて腑に落ちたわけではないですし、ジョブの特定などは言うは易しだけど……という気はまだしています。とは言え、従来様々な視点で語られてきたものの集大成感は流石なので、議論のベースラインとしてチームで共有しておく価値は十分あるように思います。
あとは実践して自分自身で洗練させていくのみですね。

112
134
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
112
134

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?