「いちばんやさしいPythonの教本」は、Pythonicなプログラミング入門書

8月10日に「いちばんやさしいPythonの教本」が出版されました。

書籍は、ビープラウドのメンバー、鈴木たかのり（@takanory）、杉谷弥月の２人で執筆しました。

レビューには、私も含めて以下のメンバーが参加しています。

社内レビュアー

• @shimizukawa
• @hirokiky
• @okusama27
• @haru860

ヘルプコラミスト

• @hirokiky

読者対象者

以下の方々が対象です。

• プログラミングを始めたい
• Pythonを学びたい

内容構成

書籍は10章構成です。

内容は、以下のように大きく５つに分かれています。

【1】プログラミング入門

プログラミングを始める方向けの内容です。プログラミングとは何か、どのように動作しているのかをPythonを使って丁寧に説明しています。

• 1章 Pythonを学ぶ準備をしよう
• 2章 コマンドプロンプトに慣れよう
• 3章 基礎を学びながらプログラムを作成しよう

【2】Pythonの基本文法

最も基本的かつ頻繁に使用する文法について説明しています。

• 4章 繰り返しと条件分岐を学ぼう
• 5章 辞書とファイルの扱いを学ぼう

【3】はじめてのアプリケーション開発

対話型のbotをつくりながら、Pythonのライブラリの使い方を学びます。

• 6章 会話botを作ろう
• 7章 ライブラリを使いこなそう
• 8章サードパーティ製パッケージを使いこなそう

【4】はじめてのWebアプリケーション開発

8章までつくったbotをWebアプリケーション化します。Webアプリケーションの基礎を学びます。

• 9章 Webアプリケーションを作成しよう

【5】Pythonのさらなる学び方

Pythonをさらに学ぶための、情報源となる書籍、サイト、コミュニティを紹介しています。

• 10章 さらに知識を身につけるための学び方

この書籍で読者が得られるもの

短時間でスイスイと読めて理解できる

この書籍では、プログラミングを始めたばかりの方が、プログラミングをスムーズに理解し、速習できることを１番の目的としています。

書籍を読むときに、分からない用語があったり、専門用語が当たり前に使われていると、その時点で読者の理解が止まってしまいます。

この書籍では、読者がプログラミングを理解する妨げにならないよう、内容構成、サンプル、図、説明の仕方にいたるまで、時間をかけて精査しています。

Pythonicな書籍

書籍では、わかりやすい文章を書くことは当たり前のことです。

なので、あえてここで書くことではないかも知れませんが、チーム内では以下のようなことを気をつけて内容を精査しました。

• 説明文章が冗長になっていないか。短く説明できないか

  → 文章が長いと、脳内メモリを使ってしまい、理解しにくくなる

• 説明、用語が曖昧になっていないか。明示的に説明できているか

  → 説明、用語が曖昧で暗示的だと、脳内で他の知識との突き合わせ確認が入り、理解が止まる

• 用語に表記のブレがないか

  → 表記にブレがある場合、脳内で他の知識との突き合わせ確認が入り、理解が止まる

気づいてみると、これら気をつけていたことは「Zen of Python」*1 に書かれている内容そのものです。

• Explicit is better than implicit.

  暗示するより明示するほうがいい

• Readability counts.

  読みやすいことは善である

• Simple is better than complex.

  複雑であるよりは平易であるほうがいい

• There should be one-- and preferably only one --obvious way to do it.

  たったひとつの冴えたやりかたがあるはずだ

これらをチームで繰り返した結果、簡潔で明示的な表現を良しとするPythonのように、読む人にとって理解しやすいPythonic(Pythonらしい)な書籍に仕上がりました。

また、書籍が全ページカラーなので、読者の直感的な理解の助けになるでしょう。

つまづきやすい概念も挫折せずに学べる

学びの段差をなるべく低くするように内容を練り、構成しています。

初心者向けの書籍は、基本的な内容を並べれば書籍になるわけではありません。

執筆時は、以下の作業の繰り返しです。

• 概念や専門用語を、理解できる小さな単位に細かく分割
• 伝わりやすい平易な表現を探す
• 表現をつなげて文章にする
• 何度も読み、理解しやすいかどうか反芻する

どのように説明したらプログラミングを始めたばかりの方が、つまづかずにプログラミングの概念を理解できるのか。

そのノウハウは、弊社の研修： BePROUD Pythonトレーニングや、弊社サービスのPytnonオンライン学習プラットフォームPyQで、Pythonプログラミング初心者向けのコンテンツを作成したり、教える経験の中で培われています。執筆者だけでなく、上記のレビュアーもPython研修の講師、PyQのコンテンツ作成を担当しています。

初めてプログラミングを学ぶ方も、日々忙しく時間がない中で、プログラミングを学ぼうと思い立った方がほとんだと思います。

そのような忙しい時間の中で、学んだ時間がムダにならないよう、挫折せずに学ぶことができる弊社のノウハウがこの書籍には盛り込まれています。

読み終えたあと、次のステップにスムーズに進みやすい

5章までで基本文法を学んだあとは、対話型のbotに機能を追加していくカタチで、Pythonの使い方を学んでいきます(6〜9章)。

対話型のbotのサンプルでは、この書籍で学び終えた人が、自分でアプリケーションをつくるという次のステップをイメージしやすいよう、実践的な内容を意識しています。

6〜9章を学ぶことで以下のこともあわせて知ることができます。

• アプリケーションに機能を徐々に追加していく流れ
• つくったアプリケーションをWebアプリケーション化する方法

Pythonは、それ単体でさまざまなことが実現できるライブラリが幅広く揃っていることで、バッテリー同梱(batteries included)と呼ばれています。

Pythonと同じくこの書籍も、プログラミングの基本、Pythonの基本文法、アプリケーション開発、Webのサーバーサイド開発まで、幅広く同梱されていますので、この一冊で応用できる基礎が身につきます。

オンラインPython学習プラットフォームPyQとのコラボレーション

書籍には、PyQ 用のキャンペーンコードが記載されています。

PyQへの会員登録時にキャンペーンコードを入力していただくと「いちばんやさしいPython教本」で学んだ内容がオンライン上で、プログラムを動かしながら学習することができます。（基礎文法のコンテンツも学習可能）

最後に

「いちばんやさしいPythonの教本」を読みやすく学びやすい内容に仕上げるために、原稿が印刷所に入る数時間前までチームメンバーで粘り、内容を精査しました。

執筆陣・レビュワーにとっても満足のいく書籍に仕上がりましたので、ぜひ手にとって頂ければと思います。

プログラミングは、体で憶えるというスポーツのような側面もあります。

この書籍では、シンプルながら実践的なプログラムのサンプルを用意しています。

ぜひ、実際に手を動かしながら、プログラミングを楽しく学んでください。

いちばんやさしいPythonの教本 人気講師が教える基礎からサーバサイド開発まで (「いちばんやさしい教本」シリーズ)

*1:Zen of Pythonとは、Pythonの思想をまとめた文章です。「import this」とPythonのプロンプトに打ち込むことにより表示されます。

「強み」はどのように活かすか〜匠MethodにおけるSWOT分析活用の考察（匠塾 2017年8月開催まとめ、その２）

2017年8月10日の匠塾*1の各人の発表時に「自分の強みは、モデルのどこに書けば良いのですか？*2」という質問がありました。

わたしは答えを２つ考えました。

答え1

価値デザインモデルの「コンセプト」に強みの要素を入れると良いでしょう。

コンセプトは「ビジョンを実現するための構想」「ビジョンを実現するための戦略的要素」なので、「強みを活かして何をするか」という観点を入れたコンセプトを入れてみるのが良さそうです。

価値分析モデルの「手段」（＝要求分析ツリーの業務要求）に記述できますが、埋もれてしまう可能性もあります。

答え2

匠Methodの「組織モデル」に「SWOT分析シート」*3がありますので、これを使いましょう。

自分の答えに対して生まれた問い

二つ目の答えとして「SWOT分析シート」をあげたものの「SWOT分析を匠Methodでどのように活用するのか？」については、その場で答えはありませんでした。

匠塾の後、山の日と土日のあいだに私なりに考えた*4ので、今日は「匠MethodにおけるSWOT分析の活用」をテーマに書きます。

SWOT分析とは

WikiPadiaには以下のように書かれています。

SWOT分析（-ぶんせき、SWOT analysis）とは、目標を達成するために意思決定を必要としている組織や個人のプロジェクトやベンチャービジネスなどにおいて、外部環境や内部環境を強み (Strengths)、弱み (Weaknesses)、機会 (Opportunities)、脅威 (Threats) の4つのカテゴリーで要因分析し、事業環境変化に対応した経営資源の最適活用を図る経営戦略策定方法の一つである。

つまりSWOT分析は「経営戦略を策定するための方法」ということです。

SWOT分析で戦略を策定してはいけない

戦略を策定するための方法を紹介しておいて「SWOT分析で戦略を策定してはいけないとはなにごとだ！」と思うかも知れません。

その理由を説明します。

まず、SWOT分析について説明します。SWOT分析を下図に示します。

SWOT分析のプロセス

上図のようにSWOT分析は、以下の３つのステップで進めます。

ステップ１　SWOT分析

自社や自社の製品・サービスの強み、弱み、機会、脅威をマトリックスに記載します。

ステップ２　TOWS分析

TOWS分析は、クロスSWOT分析とも呼ばれ、「TOWS」の名は「SWOT」を逆さまにしたのが由来です。

以下の４つの組み合わせの視点から、施策案を検討します。

• 強み☓機会→積極姿勢の施策
• 弱み☓機会→弱点強化の施策
• 強み☓脅威→差別化の施策
• 弱み☓脅威→防衛／撤退の施策

ステップ３　戦略策定

TOWS分析をもとに、何をどのような順番で実行していくか、戦略を策定します。

SWOT分析で戦略策定の何がいけないのか？

SWOT分析は、古くからある手法で一見理にかなってそうですし、実際SWOT/TOWS分析をやってみると、良さそうな施策のアイデアが浮かんできます。

何がいけないのでしょうか。

それは「人の感性の不在」です。

関わる人（ステークホルダー）がどのように感じて、どのように嬉しいか。

その視点がSWOT分析から生まれてきた施策には欠けています。

「モノ」「カネ」「情報」「人（リソースとしての人）」をうまく組み合わせただけの「論理的な理屈だけの施策」になっているのです。

「理屈だけでは人は動かない」といいますが、「論理的・合理的なだけの施策」では人は動きませんし、無理やり動かしてもモチベーションが低いので失敗します。

実際に「論理的・合理的なだけの施策」で、失敗した事例をコンサルタントが赤裸々に書いた書籍があります。

申し訳ない、御社をつぶしたのは私です。

大手コンサルティングファームを渡り歩いてきた実力派コンサルタントが、「戦略計画」「最適化プロセス」「業績管理システム」などの戦略論・システムを振りかざして、企業を何度も崩壊させてきた過ちを告白した書籍です。

この書籍を読むと「論理的・合理的なだけの施策」がいかに失敗するかが分かるでしょう。

さまざまな戦略理論と匠Methodの違い

匠Methodと、昔から数多くある戦略理論の違いはなんでしょうか。

昔から数多くある戦略理論が戦略という「論理」だけにフォーカスをあてているものが多いのに対し、匠Methodは、関わる人（ステークホルダー）の感性、嬉しいことに、フォーカスをあてているということです。

人の感性（嬉しいこと）にフォーカスをあてる効果

企画・戦略策定の段階から、ステークホルダーの嬉しいことに共感することで、以下の効果が生まれます。

• 強引に説得するのではなく、その人が納得するための話がしやすくなる
• 自分たちの利益だけを追求するのではなく全体最適を考えているので、協力者が増える
• 多くのステークホルダーに共感したことによる広い視野の獲得。広い視野から生まれる的確な判断と行動

匠の夏祭り2017のセカンドファクトリー大関さんの事例は、当初IT活用の視点だけでうまく進まなかったプロジェクトが、価値分析モデルを使い、地元の人（徳島県）などのステークホルダーに共感し、広い視野を獲得したことで、協力者が増えプロジェクトが成功した良い事例です。

経営者・リーダーにとっていちばん大切なこと

あるとき、かつて経営の神様といわれたパナソニック創業者の松下幸之助に「経営者にいちばん大切なことを一つ挙げるとするとなんですか？」とあるコンサルタントが質問したそうです。いつもは質問に間髪入れずに回答する松下幸之助が数分考え込んだ結果、「一つではないといけませんか。二つではだめですか？」と言い出しました。

確認後の最終的な回答は二つでした。「人間観を確立すること。宇宙の哲理を把握すること」です（ほんとうは失敗続きだった「経営の神様」 P120より）。

ほんとうは失敗続きだった「経営の神様」

匠Methodの感性と人間観の確立

匠Methodで「人はどのような時に嬉しく、価値を感じるのか」という感性を明確にイメージするには「人間とはこういうものだ」という的確な観点を持っている必要があるでしょう。この観点が人間観です。

匠Methodの論理と宇宙の哲理の把握

ビジネスを考えるときには、ビジネスモデル、つまり、ヒト、モノ、カネ、情報が、どのような論理、理屈で動くかを考える必要があります。

ビジネスモデルは生態系そのものであり、生態系の論理、理屈を深く考え、本質を掴むことは、宇宙の哲理ともつながりそうです。

まとめると以下のようになります。

• 感性：人は何を嬉しいと思い、価値を感じるのか？（「人間観の確立」により深く考察できる）
• 論理：ビジネスはどのように動くのか？（「宇宙の哲理の把握」により深く考察できる）

究極をいうと、この２つをいかに極めるかで匠Methodをつかって創造されるものが変わってくるでしょう。

「宇宙の哲理の把握」のために、システム思考について学んでおくのもおすすめです。

世界はシステムで動く ―― いま起きていることの本質をつかむ考え方

匠MethodにおけるSWOT分析の使い方

それでは、SWOT分析は匠Methodでどのように使えばよいのでしょうか。

結論をいうと、施策のアイデア（施策案）を出すためです（下図参照）。

ここで生まれた施策案が、匠Methodの基本モデル（ステークホルダーモデル、価値デザインモデル、価値分析モデル、要求分析ツリー）のインプットとして活躍します。

SWOT/TOWS分析から生まれた施策案は、３つの使い方が考えられます。

• 価値分析モデルの「手段」
• 価値デザインモデルの「ビジョン」「コンセプト」
• プロジェクト企画案

（１）価値分析モデルの「手段」

TOWS分析の施策案をそのまま、価値分析モデルの手段に使います。

価値分析モデルを作っている際、施策のアイデアがなかなか出にくい場面があります。

漠然と施策のアイデアを考えるよりも、SWOT/TOWS分析から生まれた施策案は鋭い視点をもつでしょう。

（２）価値デザインモデルの「ビジョン」「コンセプト」

以下の記事にも書きましたが、施策案を段階的に抽象化し、価値デザインモデルのビジョン、コンセプトに昇華させる使い方です。

shacho.beproud.jp

A,B,C と生まれた施策を「A+B+C→X」と思考をジャンプできるかがポイントです。A+B+Cのままだと現状の延長線上を未来を描くことになります。

（３）プロジェクト企画案

施策案が、そのままプロジェクトの企画案になる場合もあります。

例えば、弊社運営のPyQをTOWS分析で考えると「Pythonにおいての実績・ブランド」という強みと「プログラマー需要の上昇」という機会があり、「オンラインPython学習プラットフォームのPyQをつくる」という施策が生まれ、それが、プロジェクトの企画案になります。

Pythonにおいての実績・ブランド（強み）☓プログラマー需要の上昇（機会）＝ PyQ

SWOT/TOWS分析の具体的な進めかた

SWOT分析

まずは、SWOT分析の進め方です。以下のサイトを参考にさせていただきました（いろいろサイトを見ましたが一番まとまっていました）。

www.s-naga.jp

強みのリストアップ

企業の強み・弱みは、以下の視点から考えます。

• 財務の視点
• 顧客の視点
• 業務プロセスの視点
• 人材と変革の視点

# コアコンピタンス経営

2000年頃、コアコンピタンス経営が一世を風靡しました。その後、経営戦略理論としては廃れてしまったのですが、企業の強みを考えるための視点としては、まだ使える気がします。

WikiPediaによると、コア・コンピタンスは次の3つの条件を満たす自社能力のことです。

• 顧客に何らかの利益をもたらす自社能力
• 競合相手に真似されにくい自社能力
• 複数の商品・市場に推進できる自社能力

匠Methodの「シーズ」にも該当し、再考の余地がある理論と思われます。

# 個人の才能・強み

キャリアデザインの場合は、以下の書籍のWebツール「ストレングスファインダー2.0」を使って、自分の才能を抽出し、そこを起点に強みを考えていくのも良いでしょう。

さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0

この書籍によると、才能とは、「無意識に繰り返される思考、感情、行動のパターン」であり、知識（学習と経験によって知り得た真理と教訓）と技術（行動のための手段）が組み合わさることにより、強み（常に完璧に近い成果を生み出す能力）になるとのことです。

ちなみに、私の才能は以下の５つでした。

• 最上志向
• 学習欲
• 自己確信
• 個別化
• 達成欲

弱みのリストアップ

強みと一緒に弱味もリストアップします。

リストアップした項目を「強みなのか弱みなのか」という議論を始めてしまうと、延々と終わりません。

それは、周りの環境によって、強みにも弱みにもなることがあるからです。

たとえば「会社が小さい」は、会社が小さくて有利な場面・環境もあれば、不利な場面・環境もあるということです。

チームの思考が、攻め重視の場合「強み」に、守り重視の場合「弱み」に入れておきましょう。

（攻め重視も守り重視も決まってない場合は、楽観的に「攻め」に入れておきましょう）

機会・脅威のリストアップ

機会と脅威のリストアップする際、外部環境を捉えるための観点をあげておきます。

# マクロ外部環境

PESTと呼ばれる４つの観点です。

• Politics(政治)
• Economy(経済)
• Society(社会)
• Technology(技術)

# ミクロ外部環境

3Cと呼ばれる3つの観点です。

• 顧客
• 自社
• 競合

業界内の外部環境として、5Forcesと呼ばれる5つの観点です。

• 新規参入
• 既存競合
• 売り手圧力
• 買い手圧力
• 代替品の脅威

# イノベーションの７つの機会

P.F.ドラッカーの「イノベーションの７つの機会」を観点として、機会（チャンス）を観察するのも良いでしょう。

イノベーションと企業家精神【エッセンシャル版】

書籍に書かれているのは、以下の7つです。

1. 予期せぬことの生起。予期せぬ成功、予期せぬ失敗、予期せぬ出来事。

2. ギャップの存在。現実にあるものと、かくあるべきものとのギャップ。

3. ニーズの存在（プロセス・ニーズ、労働力ニーズ、知識ニーズ）

4. 産業構造の変化

5. 人口構造の変化

6. 認識の変化、すなわち、ものの見方、感じ方、考え方の変化

7. 新しい知識の出現

イノベーションを生み出すことは、どの企業にとっても必要なことです。この7つの機会を観察し、自分たちにとっての機会（チャンス）を見いだしましょう。

強み☓機会→積極姿勢の施策

強みに対して、外部環境の機会が訪れているので、積極的な施策を考えます。

弱み☓機会→弱点強化の施策

自社の弱点を補強し、リスクを下げるための守りの施策を考えます。

品質面、財務面、法律面などの施策になるでしょう。

強み☓脅威→差別化の施策

脅威を遠ざけて立ち位置を築くための、差別化の施策を考えます。

差別化を考える上で、参考になる２つの書籍を紹介します。

ストーリーとしての競争戦略 ―優れた戦略の条件 (Hitotsubashi Business Review Books)

「ストーリーとしての競争戦略」は、いかに他社と差別化し、模倣されにくい製品・サービスをつくるかという視点を学べます。

この書籍はPyQを企画時にチームメンバーで読み、とても参考になりました。

[新版]ブルー・オーシャン戦略―――競争のない世界を創造する (Harvard Business Review Press)

ブルーオーシャン戦略は、低コスト化と高付加価値化という相反することを両立させ、バリューイノベーションを起こすという考え方です。

• 「減らす」「取り除く」ことによる低コスト化
• 「増やす」「付け加える」ことによる顧客価値向上

弱み☓脅威→防衛／撤退の施策

戦争は殿（しんがり）が一番難しく、勝ち戦よりも負け戦が難しいと言われるように、撤退戦略は、事業戦略でも最も難しいといわれます。

撤退の機会を逃すと大きな損失を生みます。そのような観点で、防衛／撤退の施策を検討します。

まとめ

私は、古今東西で生まれるさまざまな戦略論が使えないといっているわけではありません。

戦略論は論理という面で秀逸であるものが多く、施策を生み出すために重宝できるでしょう。

しかし、論理だけでは片手落ちで、人の感性と論理が組み合わさってこそ、戦略が絵に描いた餅にならず、人を動かし価値を創り出す戦略になります。

これからもさまざまな戦略論や経営論が生まれてくるかと思いますが、「その戦略理論は、人の感性の面にフォーカスしているか？」という視点で見てみるのも良いでしょう。

こうなってくると、組織モデルにある「BSC匠戦略マップ」も気になるところです。

新たな知見が得られないか、情報にあたり再考したいところです。

キャプランとノートンの戦略バランスト・スコアカード

*1:毎月開催されている招待制の匠メソッドを学ぶ会です。株式会社アクティアCOO 高崎健太郎さんを塾長とする有志によって開催されています

*2:発表していた人は自分のキャリアデザインに取り組んでいました

*3:匠Business Place 萩本順三さんのAjile Japan2017 のスライド：AgileJapan 2017 ビジネスアジャイル 匠Methodとスクラムの25スライド目参照

*4:私なりの考えなので、匠Methodのコンサルティングガイドなどに書かれている公式のものではありません。参考程度でお願いします。

エレベータピッチのつくりかた（匠塾 2017年8月開催まとめ、その１）

2017年8月10日に匠塾*1に参加してきました。

私は「匠Methodでつくったモデルをエレベータピッチで説明するには」というテーマのチーム（通称ヘンタイチーム）に参加しました。

エレベータピッチを使う場面

エレベータピッチは、会社で地位の高い人や投資家にエレベータの中で20〜30秒でプレゼンすることなので、自分にはそのような機会がないと思う人は多いかもしれません。

一方、初対面の会話は、どの人にもあります。

仕事で取引先の人と初めて話す、社内で他部署の人と話す、社外の勉強会の懇親会などです。

そのとき、自分は日頃何に取り組んでいるかを、簡潔に伝えるためにエレベータピッチは効果的です。

私が匠塾で参加したチームでは、以下のようにエレベータピッチについてまとめました。

エレベータピッチの目的

エレベータピッチの目的は、以下を短時間で達成することです。

• それいいね！と言ってもらえること
• 「もっと話を聞かせてよ」と次の機会につなげること（印象に残ること）

エレベータピッチの構成要素

エレベータピッチは、以下の（１）〜（４）を伝えます。時間があれば（５）を伝えると、納得感、説得力が加わります。

• （１）私はどうしたい？（ずばりひとことで）
• （２）私が〜することで
• （３）その結果、誰が

• （４）〜のベネフィットを得ます

  • サブベネフィット
  • メインベネフィット

• （５）実現を裏付ける裏付け・証拠・エビデンス・バックグランド

匠Methodとのマッピング

同じチームだった関満徳さん が下図を書いてくれました。

これをもとに、昨年匠道場*2で実施したワーク（テーマ：もし自分が秋田県知事に立候補するなら）をマッピングしたのが下図です。

マッピングのポイント

チームでは、以下のようなポイントを検討しました。

（１）私はどうしたい？（ずばりひとことで）

なるべく短い時間でズバッと伝えるためには、キャッチコピーの方が意味が凝縮されているということで、キャッチコピーを使うことにしました。

決めたキャッチコピーを「エレベータピッチで使えるものになっているか？」という視点でチェックしてみることで、洗練させていくことができるでしょう。

※ビジョンは、エレベータピッチのあと、２回目以降にじっくり話す場面で伝えるということになりました。もちろん、ビジョンを使っても簡潔に伝わる場合は、ビジョンを使ってもOKです。

（２）私が〜することで

価値デザインモデルの「コンセプト」を使うことになりました。

コンセプトは「ビジョンを実現するための構想」「ビジョンを実現するための戦略的要素」ということで、行動的な要素が入ってきます。

価値分析モデルの手段=業務要求から選ぶことも可能ですが、具体的すぎる場合が多いので、コンセプトから選ぶのが良いと思われます。

※要求分析ツリー上でコンセプトと、業務要求はつながってきます。業務要求を見つけてからコンセプトに遡っていくのも良いでしょう。業務要求とコンセプトがツリー上でつながらない場合は、コンセプトの見直しが必要です。

（３）その結果、誰が

価値分析モデルに並べたステークホルダーから、もっとも重要なステークホルダーを選びます。

（４）〜のベネフィットを得ます

（３）のステークホルダーが、どのようなベネフィットを得るかを２つ説明します。

# メインベネフィット

最も優先度が高いベネフィット（嬉しいこと）を伝えます。明確さを増すために、具体的な目標や期限を伝えます。ゴール記述書の「何を、いつまでに、どうする」を使うことにしました。

# サブベネフィット

２番目に優先度が高いベネフィットを伝えます。メインベネフィットに相反するベネフィットを上げられるとなお良いでしょう。相反するベネフィットを伝えると「なぜ、そんなことができるの？（詳しく知りたい）」と興味をひくことが出来ます。

相反するベネフィットを考える際には、ビジョナリー・カンパニー ― 時代を超える生存の原則の「「ORの抑圧」をはねのけ「ANDの才能」を活かす*3」が参考になるでしょう。

書籍では、相反するものとして以下の例があげられています。

• 変化と安定
• 慎重と大胆
• 低コストと高品質
• 創造的な自主性と徹底した管理
• 未来への投資と目先の利益
• 綿密な計画による進歩と臨機応変に模索しながらの進歩

野球などのスポーツでいえば「育てながら勝つ」が該当するでしょう。

一見、矛盾していることを同時に成し遂げることによって、平凡さを抜け出し、印象に残りやすくなります。

「AなのにB」という発想法は、キャッチーなタイトル・テーマを生み出す時にも有効なので憶えておくと良いでしょう。

• 中学生なのに、将棋でデビューから30連勝
• 学年で成績がビリなのに東大に合格
• 脚が遅いのにエースストライカー
• 育成選手出身なのに、侍Japan入り
• 県でトップの進学校なのに甲子園出場
• FAや移籍で主力選手が抜けていくのに優勝
• 小さなチーム、大きな仕事

最後にビジョナリー・カンパニーで紹介されている言葉をお伝えしておきます。

「一流の知性と言えるかどうかは、二つの相反する考え方を同時に受け入れながら、それぞれの機能を発揮させる能力があるかどうかで判断される」

「Andの才能」を伸ばし、価値あるものを世の中に創り出しましょう。

# メリットとベネフィットの違い

メリットとベネフィットの違いは、よく言われていることなので、簡単に書いておきます。

• メリット：ウリ・特徴
• ベネフィット：「メリット」によりもたらされる嬉しいこと（体験・変化）

「ベネフィットが正確に伝わっているか？」「メリットではなく、ベネフィットを伝えているか？」という視点でエレベータピッチをチェックしてみるとよいでしょう。

（５）実現を裏付ける裏付け・証拠・エビデンス・バックグランド

エレベータピッチを20秒〜30秒で伝えたあとに、さらに時間の余裕があれば、なぜエレベータピッチで説明したことが実現できるのかを説明します。

これにより「なるほど」と思わせ、エレベータピッチの言葉に信頼性をもたせる効果があります。

具体的には、以下のような内容です。

• 今までの実績（導入実績、顧客数、事例となる顧客など）
• 経歴
• 実験、検証の結果
• 実現するためのリソース（方法論・メソッド、営業力、技術力など）

最後に：自分のエレベータピッチを用意しておこう

冒頭でもお伝えしたように、自分のキャリア、仕事、事業について、初対面のひとに説明する場面は、意外と多くあります。

そのような場面で、簡潔に効果的に話せるように、匠Methodで、自分のキャリア、仕事、事業についてモデルをつくり、自分のエレベータピッチを用意しておくのはいかがでしょうか。

初対面で話した相手の印象に残り、予想もしなかった展開が待っているかもしれません。

匠塾について

匠塾は招待制の勉強会です。匠メソッドに興味があり、匠塾に参加してみたい人は、私にFBメッセージでお声がけください。

「ORの抑圧、Andの才能」について書かれた書籍はこちら

ビジョナリー・カンパニー ― 時代を超える生存の原則

匠Methodについて書かれた書籍はこちら

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

*1:毎月開催されている招待制の匠メソッドを学ぶ会です。株式会社アクティアCOO 高崎健太郎さんを塾長とする有志によって開催されています

*2:匠メソッドのライセンスを購入している企業の社員のみが参加できる月１回開催されている匠メソッドの勉強会

*3:「ORの抑圧」とは逆説的な考え方は簡単に受け入れず、一見矛盾する考え方は同時に追求できないとする理性的な見方。「ANDの才能」とは、さまざまな側面の両極にあるものを同時に追求する能力。AかBのどちらかを選ぶのではなく、AとBの両方を手に入れる方法を見つけ出す見方。

なぜ人は複雑なリモコンのようなWebサイトをつくってしまうのか

「複雑！すべての機能をとても使いこなせない」

数多くボタンが並んだAV機器のリモコンを見て、過去に思ったことがある人も多いでしょう。

しかし、いざ自分がWebサイトを企画する側になると、複雑なリモコンと同じものをつくってしまいがちです。

誰もが、シンプルで使いやすいWebサイトをつくりたいと思っているはずなのに、なぜ、そのようなことになってしまうのでしょうか。

順に考えていきます。

小さな労力で大きな価値を

Webサイトを開発するリソース（お金、時間、人）は、どのような企業でも有限です。

そのため、なんでもかんでも思いついたものを、つくるわけにはいきません。

小さな労力でWebサイトをつくり、大きな価値を生み出す努力が必要です。

そのためには、当然ながらWebサイトの開発スコープを絞ります。

顧客の対象を絞る

スコープを絞るには、顧客の対象を絞るのが１番手っ取り早い方法です。

たとえば、顧客の対象候補として、Aさん、Bさん、Cさんがいたとします。 (この場合のAさん、Bさん、Cさんは同一のステークホルダー*1です）

勝負の分岐点

結論をいうと、Aさんだけに顧客の対象を絞れるかどうかで勝負が決まります。

「なぜ顧客対象を絞らないといけないか」を考えます。

下図のように、Aさん、Bさん、Cさんを対象顧客とした場合（線の上側）と、すべてのリソースをAさんに投資した場合（線の下側）で、それぞれ「6」のリソース（水色の四角）をサイト開発に使えるとします。

上側は、Aさん、Bさん、Cさんそれぞれに「２」しか開発できず、「２」の価値しかもたらされません。

一方、下側は、Aさんに対し「６」を開発でき、「６」の価値が生まれます。この時点で「４」の差が生まれます。

次のフェーズで、下図のように、さらに「６」のリソース（青の四角）を投資します。

上は合計「４」の開発、下は合計「１２」の開発です。

差は「８」になり、差は２倍になりました。

Aさんに特化したWebサイトは、Aさんと同じようなタイプの顧客を増やしていけば良く、Aさん向けにリソースも集中投下できますので、今後ますます差は広がります。

数多くのWebサイトが存在する時代に、このように差がついてしまったら、顧客には二度と選択してもらえないでしょう。

多くのステークホルダーを取りに行く弊害

Aさん、Bさん、Cさんを対象としたほうが、量が稼げて、ビジネスを拡大（スケール）できる可能性はあると考える人もいるかもしれません。

例として、Aさん、Bさん、Cさん向けのWebサイトをつくったとします。

Aさんがサイトを訪れた時に、Bさん向けの機能、コンテンツが目に入った場合、自分のためのサイトではないと思い、離れてしまいます。

こうなっては、せっかく広告で誘導しても、離脱率は上がり、広告費はムダになります。

逆に、Aさん向けにつくられたサイトに、Aさんと同じようなタイプの人「Aさん②」が来た場合は、自分のためのWebサイトだと直感するため、使い続けてもらえる可能性は高くなり、リピート率が上がるでしょう。

ビジネススケール戦略

どのようにビジネスを拡大していくかですが、Aさんの次に、似たようなタイプのAさん②、Aさん③と展開していくのがもっともやりやすい進め方です。

そのあとに、Aさんで成功したら、Bさん、Cさんに顧客層を横展開していくという進め方もありえます。

しかし、最初からAさん、Bさん、Cさんを顧客対象にするのは、上記の理由からおすすめしません。

顧客を絞れない理由

しかし現実には、Aさんに顧客を絞ることはなかなかできません。

考えられる理由をいくつかあげてみます。

クレームを過剰に恐れてしまう

企画担当者は、顧客からのクレームを過剰に恐れ「クレームが来たらどうしよう」と考えてしまいがちです（特に顧客サポート担当が、別の部署として分かれている場合）。

クレームが来ないようにするために、その顧客のために過剰にケアしてしまいます。

顧客の声を真に受けてしまう

以前、マクドナルドで客にアンケートを取ったところ「ヘルシーなハンバーガーやメニューがあったら良い」という答えが多かったので、そのようなメニューを追加したことがありました。しかし、そのメニューはまったく売れずにすぐに終了してしまいました。

そのように、顧客は、基本無責任なものです。

顧客の声を聞く必要はありますが、顧客の声を絶対視してしまうと、自分たちの強み、良さ、目指しているもの、求められているものを見失ってしまいます。

顧客、売上が少なかったらという恐怖

「マス」に対してWebサイトを売り「皆が同じものを買う」時代は終わり、顧客は「自分のためにつくられた製品やサービスを購入する」というのは、企画担当者は頭では理解しています。

しかし、顧客を絞ると、売上が少なくなってしまうのではという不安に襲われます。

そして、安全を取り、顧客の範囲を広めに取ってしまいます。

そうなると「マス」に対して商品を売ることに逆戻りするので、当然、顧客に対しての訴求が弱くなります。

企画担当者の不安

上記の顧客を絞れない理由に共通することは「企画担当者の不安」に根ざしていることです。

ここで起きる不安は以下のようなものです。

• クレームがSNSに広がって、サービスの評判が落ちたらどうしよう
• クレームが来て、自分が責められたり責任を問われたらどうしよう
• せっかく興味を持ってくれた顧客が離れていったらどうしよう
• 製品の売上が少なくて、成果があがらなかったらどうしよう
• 失敗して、出世に響いたらどうしよう（出世を気にする人の場合）

この不安は人の本能であり、大部分の人がこのように反応します。

そして防衛本能が働き、安全策で無意識に顧客の幅を広げ、あれもこれもと、機能がほしくなります。

その結果、複雑なサイトができあがります。

このようにならないために、どうすればよいのでしょうか。

顧客の幅を広げない（余計な機能をつくらない）思考法

まずNoという

37 Signals社の「Getting Real」「小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則」に載っている方法ですが、何か機能を追加したくなったら「まずNoという」方法です。

「No」というとネガティブでディフェンシブなように思えますが、「No」といったあとに「なぜNoなのか？」を考えることで、妥当な理由があれば「No」は正しかったことになります。

アイデアは無限に湧いてきます。

まず「No」ということで、生まれたアイデアを「良さそうだね」という軽いノリで、つくり始めてしまうことを防ぐことができます。

YAGNI

YAGNI（ヤグニー）とは、"You ain't gonna need it”の略で、「機能は実際に必要となるまでは追加しないのがよい」とする、エクストリーム・プログラミング*2における原則です。

なくても、実用上困らない機能を、必要な人もいるかもしれないという理由で作り込んでしまうことがあります。

このような機能は、要望が増えたときに作るべきです。

要望が出たときではなく、要望が増えたときです。

YAGNIの思想を頭に留めておけば、不必要な機能をつくってしまうことは、かなり減らせます。

「まずNoという」とYAGNIで、顧客の幅を広げてしまったり、余計な機能をつくってしまう可能性はだいぶ減ります。

しかし、「企画担当者の不安」という根本的な問題は解決されていません。

どのようにすれば、企画担当者の不安は減らせるのでしょうか。

事業責任者、経営者を巻き込む

事業責任者や経営者が、企画担当者に、機能の仕様や使い勝手などを全任しているケースも多いと思います。

しかし、上記で説明した人の防衛本能により、担当者は顧客の範囲を無意識に広げてしまいます。

その結果、複雑なリモコンのようなWebサイトが出来上がります。

そのようにならないために、事業責任者・経営者は「その顧客には嫌われよう」「そのクレームは気にするな」「その機能は要望が多くなったら考えよう」などと、都度、意思を伝える必要があります。「誰に嫌われるか」という意思決定です。

この意思決定は事業責任者・経営者レベルの意思決定です。

匠Methodでは「こたつモデル」という考え方があります。

「こたつモデル」は、経営者・事業責任者、業務担当者、システム担当者が、こたつに入るように身体を突き合わせ、お互いにプロジェクトの方向性について意思統一を図ります。

企画担当者は、事業責任者・経営者に「こたつ」に入ってもらい、意思統一を図り、Webサイトの顧客の幅を日々つとめて狭めるようにしましょう。

（事業責任者・経営者が、「マス志向」であったり決断できない人だと、こたつに入ってもらってもつらいのですが）

まとめ

上記の話は、ひとことでいうと「選択と集中」の話です。

しかし「企画担当者の不安」により、「選択と集中」は難しくなります。

それは、顧客を絞れなくなることから来る、機能過多を引き起こします。

そのためには、事業責任者・経営者と同じ土俵で意思統一をはかることです。

事業責任者・経営者は「誰に嫌われるか」の意思決定を日々伝えましょう。

おもいきって顧客を絞り、その顧客に最大の価値をもたらそうとすると以下のメリットが得られます。

• 市場での立ち位置の確立（専門Webサイトとしての差別化）
• 顧客の定着（リピート率の向上）
• 低い新規顧客獲得コスト（広告費が少なくて済む）
• 開発コストの低減（集中的投下）
• 集客効果（同じようなユーザーが集まっていることにより、同じユーザーが集まる）

「企画担当者の不安」を乗り越え、経営者・事業責任者、企画担当者の意思統一をはかり、顧客の「選択と集中」によって、価値あるWebサイトを創り出しましょう。

以下の２冊は、シンプルなWebサイトをつくりたい方におすすめです。

「まずNoという」が書かれている書籍はこちら

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

「こたつモデル」が提唱されている、匠Methodの書籍はこちら

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

*1:ステークホルダーとは、企業・行政・NPO等の利害と行動に直接・間接的な利害関係を有する者を指します。具体的には、消費者（顧客）、従業員、株主、債権者、仕入先、得意先、地域社会、行政機関などです。楽天のようなECショッピングモールサイトを例にすると、Aさん、Bさん、Cさんは「購入者」という同一のステークホルダーです。「出店者」は別のステークホルダーです。

*2:ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法である。WikiPedia

勉強会で話すと何が良いのか〜Developers Summit 2017 Summerで登壇しました

7月28日に開催されたDevelopers Summit 2017 Summer で、「コミュニティを長く続ける秘訣」というセッションでお話させて頂く機会をいただきました。

BPStudyは、2017年8月の開催で、丸10年（2007年9月開始で、12か月☓10年=120回）になるということで、BPStudyをテーマに発表しました。

セッションで話した中でも「勉強会で話すと何が良いのか、どのようなことを話したら良いのか」ということをあらためてブログに書きたいと思います。

このエントリーが、勉強会でこれから発表してみようと思っている人のヒントになればと思います。

私が言いたいことを、少しおおげさにいうと「勉強会で発表すれば人生が変わる」ということです。

そのように思うようになったのは、私が勉強会やカンファレンスなど人前で発表することを繰り返してきたことによって、以下のような経験をしたからです。

• 自分の経験やノウハウがカタチとしてまとまり、自分の財産になり活用できた
• カタチとしてまとまったことが土台となり、更に新しい発想につながった
• 発表を聞いた人や、スライドを見た人から新たなオファーがあるなど、自分の予期しないところで、さまざまな効果が生み出された

勉強会で話すためのポイントを３つお伝えします。

ポイント１ やりたい→やるへの変化（心が変わる）

勉強会で発表するには、まず自分が発表しようと思い立つところからです。

「いつか発表したい」と思っていても、その時は永遠に訪れません。

「やりたい」から「やる」と決心した瞬間が、人生が変わるスタート地点です。

ポイント2 話すテーマ

勉強会で話すといっても、話すことがないという人もいると思います。テーマを見つけるコツをお伝えします。

視点を変えるとネタが生まれる

日頃の自分の取り組み、環境、経験などは、自分にとって当たり前になっていて、平凡に思えるものです。

人それぞれにさまざまな個性があり、まったく同じ人はいないのと同じように、まったく同じ仕事やチーム、プロジェクトは存在しません。

自分の環境やそれまでのキャリアから、人に伝えると役立つものはないか考えてみましょう。

客観的な視点で見つめてみると、ヒトに伝えるネタが生まれるものです。

本に書いてない内容を話す

テーマは本に書いてない内容が良いでしょう。本に書いてあることを説明するだけなら、本を読んだり、Webの記事を読めば良いからです。

本に書いていない内容とは、たとえば以下のようなものです。

• やってみてどうだったか、実際のところどうなのか？
• やってみて得た知見
• チームに導入してチームメンバーの反応はどうだったか
• 技術の発表されたばかりの最新情報
• コツ・独自の理論

コミュニティの運営経験、初心者が初心者なりに苦労した話、若手が若手なりに苦労した話、他の人は詳しくないが自分は詳しいこと、異なる分野同士の組み合わせ（掛け算）などもよいでしょう。

ポイント3 勉強会で話すメリット

3点目に勉強会で話すメリットをお伝えします。

スキルアップと財産づくり

発表する１番のメリットは、自分の暗黙知が形式知になることです。

暗黙知とは「経験や勘に基づく知識のことで、言葉などで表現が難しいもの*1」です。

暗黙知が暗黙知のままでは人に伝わりませんし、自分でも認識が難しいものです。

人に伝えようとして、なんとかカタチにしようとすることで、半ば強制的に暗黙知が形式知に変わります。

自分の中の暗黙知を絞り出し、形式知にするのは最初はとても時間がかかります。

しかし、何回か発表を重ねていくと、知識のベースがあるので時間が短縮されます。

形式知は自分の財産となり、何度も再利用可能になり、かつ思考の土台になることでしょう。

登壇依頼が来ても、割りと気軽にOKすることができるようになります。

ただし、私は同じようなテーマで登壇依頼が来ても、必ず内容を最新のもの、その場にあったものにバージョンアップして、同じスライドで話さないようにしています。その方が自分にとって成長があるからです。

自分の強みや世の中のニーズが分かる

勉強会で発表をすると、聞いている人の直接の反応をもらったり、Twitterでの反応が大抵あります。

このようにフィードバックを得られると、自分の強みや、世の中でどのような情報が必要とされているかなどのニーズが見えてきます。

プラスのフィードバックは自分の自信につながりますし、マイナスのフィードバックは自分を見直すきっかけにもなります。

自分の強みと社会のニーズを知ることにより、自分は何に力を入れていくべきか、立ち位置はどこか、などが見えてくることでしょう。

自分の新しい可能性が見えてくる

IT業界は「話を聞く」側から「話をする」側になるための参入障壁がとても低い業界です。

さまざまな勉強会がありますし、まずはLTで話し、実績を積んでいくことであるジャンルでの権威としてのポジションを築くことができるかも知れません。また、それらをきっかけに、人のつながりができたり、新しい可能性が見えてくることもあるでしょう。

ただし、これは勉強会で話す副次的効果です。勉強会で話すことの第一の目的は、自分のスキルや経験を他の人に伝えることや、自らのスキルアップに置きましょう。

話をする多くの場はコミュニティなので、自分の名声やポジションを第一の目的にすると、それが見え透いてしまったり、人間関係を壊してしまうなど、ろくなことがありません。

まとめ

勉強会で話すまでのポイントとして、（１）やりたい→やるへの変化（心が変わる）、（２）話すテーマ、（３）勉強会で話すメリットについてお伝えしました。

このエントリーが勉強会で発表してみようと思う人にとって、ヒントになれば幸いです。

日々、人はさまざまな経験をして学習し、それを暗黙知として蓄積しています。自分の仕事での経験、勉強していること、興味をもっていることで人に伝えられることがないか考えてみましょう。必ず見つかるはずです。

そのためには、社内でも社外でも仲間内でも勉強会で話そうと思い立つことがスタート地点です。そのためにはLTに参加登録して話すことを確定させてから、内容を考えるのもおすすめです。

自分の知識・経験・知見をカタチにして話すことによって、人に伝わり、それを繰り返すことによって、自分でも予見できないようなことが起こることでしょう。

BPStudyでも登壇者を常時受けつけていますので、Facebookのメッセージで私宛までご連絡をいただくか、Twitter:@haru860でDMもしくは、リプライをいただければと思います。

発表スライド

企業主催勉強会BPStudy〜個人が輝くコミュニティを目指して from Haruo Sato

*1:WikiPediaの知識経営論における「暗黙知」より

ビジョン、コンセプトを導き出すファシリテーション（匠塾(2017年6月) 開催まとめ）

2017年6月8日（木）に匠塾*1に参加しました。

7月の開催のまとめと前後してますが、内容をまとめました。

テーマ

私は、匠メソッドの知見・暗黙知をまとめて形式知にするチーム（通称ヘンタイチーム）に参加しました。

価値デザインモデルのビジョン、コンセプトの導き出し方というテーマに取り組みました。

匠メソッドのビジョン、コンセプトとは

• ビジョン

  将来の目指す姿、ありたい姿を文章、言葉で表現したもの

• コンセプト

  ビジョンを実現するための構想。３つあげる

必要なスキル

プロジェクトのビジョン、コンセプトを導き出すには、以下のようなスキルが必要です。

• 想像力

  • プロジェクトメンバーが納得して目指したいと思えるような未来をイメージする力

• 言葉づくり

  • 目指すビジョン・コンセプトを抽象的過ぎず、具体的過ぎず的確に言葉で表現する力

• バランス感のあるコンセプトづくり

  • 施策・手段検討につながるバランスの良い３つのコンセプトにまとめる力

これらのスキルはファシリテーター・リーダーだけが必要なものではなく、チームで持つべきスキルです。属人性が高く、暗黙知が大きい領域です。

As-Isの把握

ステークホルダーモデルで、ステークホルダーの洗い出し、各ステークホルダーが抱えている問題点をあげていくことによって、現状を把握します。これが最初のステップです。

未来を描くうえで、現状をしっかりと把握しておくことは重要です。

現状を的確に把握しておかないと、いかに理想的な未来を描いたとしても、ふわっとした絵に描いた餅となってしまう可能性があります。

現状を把握せずに、理想的な未来について話しているリーダーを想像してみてください（よほどのカリスマ型リーダーなら別ですが）。

価値デザインモデルまでの進め方

ステークホルダーモデルで現状(AsIs)を把握したあと、価値デザインモデルを作成するまでの進め方は、以下の２パターンがあります。

• （１）価値分析モデル→価値デザインモデル
• （２）価値デザインモデル→価値分析モデル

それぞれの進め方のメリット、デメリットを以下にまとめます。

（１）価値分析モデル→価値デザインモデル

まずは価値分析モデルから始めるパターンです。

• メリット

  • 施策・手段のアイデアがある程度出ているので、プロジェクト実現のイメージがつきやすい
  • 価値分析モデルは手をつけやすいので、話を進めやすい

• デメリット

  • テーマ・ドメインが大きい場合、ステークホルダーがつかみづらい。スコープが広がりすぎた価値分析モデルになりやすい

（２）価値デザインモデル→価値分析モデル

次に価値デザインモデルから始めるパターンです。

• メリット

  • 明確な未来像を既にもっている場合や、長い間構想してきたプロジェクトの場合は、ビジョン、コンセプトがまとまりやすい

• デメリット

  • 詳しくないテーマ・ドメインの場合や、未来のイメージが湧いていない場合は話が停滞しやすい

２つの進め方の共通課題

ビジョン、コンセプトを導き出すには、上記で書いたように「想像力」「言葉づくり」「バランス感のあるコンセプトづくり」というスキルが必要なので、議論が停滞したり迷走する可能性を秘めています。

具体的施策を段階的に抽象化し、
ビジョン・コンセプトを導き出すファシリテーション

ヘンタイチームでは議論の停滞・迷走をなるべく防ぐために進め方をまとめました。

下図は全体像です。

ステップ1 Asisの把握

Asisの把握は上記と同じです。

ステップ2 具体的施策のアイデア出し

現状を把握した上で「やりたいこと、やったほうがよいと思うことは？」という問いで、施策・手段のアイデアをブレストします。

いきなりビジョンやコンセプトを考えるよりも、具体的施策ならアイデアを出しやすいものです。

施策・手段のアイデアを以下の３つの視点で分類すると、さまざまな立場の視座を持てるようになり意外なアイデアが出るかもしれません。

• （１）すぐにやれそうなこと（現場担当者の視点）
• （２）少し頑張ればやれそうなこと（現場リーダーの視点）
• （３）遠い未来にやれそうなこと（経営者の視点）

ここでの施策・手段のアイデアは、後のプロセスの価値分析モデルの手段、要求分析ツリーの業務要求、IT要求、解決策につながってきます。

この段階でアイデアをじっくり出しておくことで、後のプロセスのスピードアップにもつながるという効果もあります。

ステップ3 グループ化、抽象化

ステップ2 で出たアイデアをグループ化したり、グループ間を関連付けたりします。 その上で各グループにタイトル・見出しをつけていきます（言葉づくり）。ステップ２の発散から収束していく段階に入りますが、グループ化、抽象化することで全体が見えてくると新しいアイデアが生まれてくるものです。新しいアイデアが出たら、それも追加していきましょう。

ビジョンやコンセプトの言葉づくりをいきなり始めるよりも、具体的な施策・手段をもとにしているので、言葉づくりの難易度が下がるというメリットがあります。

ステップ4 コンセプト・ビジョンの導出

ステップ3 で徐々に抽象化したものを「やりたいこと・実現したいことはどういうこと？」という問いのもと、ビジョン、コンセプトの言葉づくりをします。

すぐ下の抽象度まで言葉づくりが出来ていれば、ビジョン、コンセプトの言葉づくりもやりやすいのではないでしょうか。

ショック療法（新意識へのシフト）

目の前の問題から見えている施策・手段を抽象化し、そこからビジョンを描いても、現在の延長線上にあるビジョンになってしまう可能性があります。

思考をジャンプし、新意識にシフトしたビジョンを打ち出すには、上記のステップ2、ステップ3、ステップ4 のそれぞれで、新意識へシフトするためのショック療法を施すのが良いでしょう。

たとえば、以下のような問いを発してみると良いでしょう。

• 技術ドリブンで、Howからの突き上げはできないか？
• 現意識の延長で考えていないか？
• 自分たちの強み・パーソナリティと社会的な機会を活かせているか
• やろうとしていることは他社にとって模倣しにくいか？

うまくいかないファシリテーション

最後に、うまくいかないファシリテーションについて、２つのパターンをあげておきます。

強引な（専制的）ファシリテーション

• ファシリテーターが「結果イメージの予測」をした方向に議論を強引に持っていってしまう
• メンバーのアイデアをファシリテーターの判断のもとに切り捨ててしまう

このファシリテーションでは、メンバーが置いてきぼりになり、納得感がない得られないことがしばしばあります。

ファシリテーターは、結果を出そうと力んだり、急いだりするよりも、より良いものが創造される場づくりを重視すると良いでしょう。

問題点→解決策実行の進め方

このファシリテーションは、以下のように進めていきます。

• （１）現状の問題点を把握
• （２）問題点を解消するための施策をブレスト
• （３）施策に優先度をつける
• （４）優先度の高いものから実行

この進めかたでは、問題点を解消したとしても、根本的な状況は変わらないことが多いでしょう。

それは、目の前のひとつひとつの問題に小手先で対応したとしても、部分最適にしかならず、全体最適につながらないことが多いからです。

全体最適につなげるには、新意識にシフトしたビジョンを描き、それに基いて行動することです。

まとめ

今回書いた、ビジョン、コンセプトを導き出すまでのファシリーテションに正解はありません。

対象ドメインやプロジェクトメンバーによって、変わってくることでしょう。

今回メインに書いた「具体的施策を段階的に抽象化し、
ビジョン・コンセプトを導き出すファシリテーション」は、匠道場*2の課題での経験をもとに、ヘンタイチームで議論された内容が書かれていますが、これはファシリーテートの１パターンでしかありません。

課題の実例については、いずれ書きたいと思います。

匠メソッドに興味があり、匠塾に参加してみたい人は、私にFBメッセージでお声がけください。

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

*1:毎月開催されている招待制の匠メソッドを学ぶ会です。株式会社アクティアCOO 高崎健太郎さんを塾長とする有志によって開催されています

*2:匠メソッドのライセンスを購入している企業の社員のみが参加できる月１回開催されている匠メソッドの勉強会

匠塾(2017年7月) 開催まとめ〜価値デザインモデル：「コンセプト」の性質について

2017年7月13日（木）に匠塾*1に参加してきました。

価値デザインモデルの「コンセプト」について

私は、匠メソッドの知見・暗黙知をまとめて形式知にするチーム（通称ヘンタイチーム）に参加しました。

テーマは、価値デザインモデルの「コンセプト」についてでした。

コンセプトに関する話題の中でも、私が匠道場6月のまとめで不明点としてあげていた「コンセプトの性質：戦略ベースのコンセプト、コンセプトベースのコンセプト」が話の中心になりました。

プロジェクトデザインのスコープ

匠メソッドのセッションで、どこまでを議論のスコープとするかという話から始まりました。

• 匠メソッドのモデリング対象は、プロジェクトデザインである

• 会社-事業-製品-機能（サブシステム）という階層がある場合、匠メソッドでモデリングするプロジェクトは以下の３つに分類できる

  • 企業デザインプロジェクト（会社-事業）
  • 事業デザインプロジェクト（事業-製品）
  • 製品デザインプロジェクト（製品-機能）

• 企業デザインプロジェクトで、製品や製品の機能までを対象とするのは、スコープを広げすぎ

• 事業デザインプロジェクトで、製品の機能までを対象とするのは、スコープを広げすぎ
• 事業デザインプロジェクト、プロダクトデザインプロジェクトで、企業ビジョンは脇において意識はしておく

Howの手探りによる実現性の検証

• 企業デザインプロジェクト、事業デザインプロジェクトで、製品の実現可能性を考慮せずに、モデルをつくっても、現実性の無いモデルになってしまうおそれがある。
• その場合、Howの手探りをすることにより、実現可能性を検討することにより、現実性を考慮した検討をすることができる

Howの手探りをどのようにするか（例）

匠道場で、私が入ったチームの課題で、R&D要素が強いプロジェクトをテーマにしていました。

そのとき、価値デザインモデル、価値分析モデル、要求分析ツリーまでつくったところで、以下の図のように画面、処理、データの入出力の関係を検討しました。

それにより、実装（How）について、どのようなデータが必要なのか、どのような技術を使うのか、どのような研究が必要なのか、既にどのような技術があるのか、その技術はどの段階まで進んでいるのかなどというところまで話ができて、プロジェクト実現に向けて具体的なイメージをチームで持つことができました。

コンセプトの性質

戦略ベース

• それぞれのプロジェクトのスコープに収まる、ビジョン、コンセプト、目的を導き出す

• 匠Method: 〜新たな価値観でプロジェクトをデザインするために〜に記載されている戦略ベースの説明（「第７章 匠Methodで商店街の風呂屋を復活させる」）

  • プロジェクトで最も重要なことを３つ挙げようといったトップダウン的発想。
  • 業務改革や作業改善などプロジェクトのコンセプトを考える時に活用されるアプローチ

コンセプトベース

• コンセプトベースについては結論は出ないが以下のような話をしました

  • プロダクトデザインプロジェクトで、会社ビジョンをプロジェクトのビジョンとした場合に、製品のコンセプトが戦略要求の一部分（目的レベルの下）、もしくは業務要求になるのではないか
  • さらに抽象的なコンセプト見出すなど、コンセプトの見直しにより、戦略ベースと同じツリー階層に最終的には落ち着くのかもしれない

• 匠Method: 〜新たな価値観でプロジェクトをデザインするために〜に記載されているコンセプトベースの説明（「第７章 匠Methodで商店街の風呂屋を復活させる」）

  • プロジェクトにとって非常に重要なアイデアにスポットを当てて、ボトムアップ的にコンセプトを導き出す
  • 製品企画や特徴のあるサービス（ビジネスモデル）の企画のコンセプトを考えるときに活用されるアプローチ
  • 導き出されたコンセプトは、戦略要求の一部分、あるいは下位の業務要求といったように局所的に位置づけられる

IIBAのGUTSY-4における4つのモデルとフェーズ

プロジェクトのスコープの考え方は、IIBAのGUTSY-4における4つのモデルとフェーズに似ているものがあるのではないかという話も出ました。

各チームの発表を聞いて参考になった話

• 匠メソッドの進め方はブレーンストーミングに近いが、普通のブレーンストーミングはどこまでも議論を深めてしまいがち。匠メソッドはフレームがあるので、アイデアを出しつつも行きすぎにならないのが議論しやすくて良い
• （テーマ：ファミタクチーム）店舗を始めるのに、従業員を多く雇う、待遇を良くするなどというところから行動を始めるように考えてしまったが、それだと事業が成り立たないということに途中で気づいた。事業をまず成り立たせるというところから始めるようにしてから、アイデアに現実性が出てきた

• （テーマ：納涼大会）「上下関係の壁を壊す」「ダンス」「Beat the summer」というアイデアが生まれてから、話がスムーズに進むようになった

  • （コメント）匠メソッドのセッションの序盤では、アイデアが出ない、アイデアは出るが、腹落ちしないというすっきりしない時間帯があります。「上下関係の壁を壊す」「ダンス」「Beat the summer」などの「キーアイデア」とも呼べる、チームメンバーの話の呼び水となるアイデアが出るまで、どのようにファシリテートしていくか。セッション序盤におけるファシリテーターの重要スキルの１つでしょう。

• (質問）匠メソッドのチームは何人ぐらいが良いのか？ → A. 多くても8人くらいが良いでしょう

  • （コメント）こたつモデルを形成するために、誰を呼ぶのかという視点が大事。その上で適切な人数を考える

まとめ

約１時間半のワーク時間で、良さそうなアイデアが各チームでかたちになるので、匠メソッドを使うスピードが上がってきているのを感じます。

私自身は、匠メソッドについて考えていること、今までの経験や疑問点などをお互いに話しているうちに、頭の中がまとまったり、新たな知見を得たりと、２時間の時間以上に収獲が大きいです（感謝）。

匠塾によって匠メソッドを経験したことがある人の輪が広がってきています。さらに皆で楽しみながら学んでいきたいです。

匠メソッドに興味があり、匠塾に参加してみたい人は、私にFBメッセージでお声がけください。

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

*1:毎月開催されている招待制の匠メソッドを学ぶ会です。株式会社アクティアCOO 高崎健太郎さんを塾長とする有志によって開催されています