1. 事業ドメイン価値定義
我々は何のために存在しているのか。事業を通じて叶えたいことは何か。検討に先立ち、自分たちの思いを表出する。本ステップの回答は、花火マップを用いた未来課題検討の際の「初期値」としての役割を担う。これにより、後続する「ビッグ５」や「未来課題」が総花的な一般論に陥ることを回避できる。
2. 関わる主体（利害関係者）のリストアップ
定義された価値内容の実現に関わるのは誰か。前ステップで定義された価値内容を物語にした時の登場人物に相当。本ステップを新たに追加した狙いは、現行ビジネスにおける直接的な顧客のみに縛られないようにすること。未来を見据えた新たなビジネスモデルは、現状において直接的取引関係にある顧客に対して、新たなパートナーと協働して向き合うことになるかもしれない。また、共通価値テーマのもとで構成されたエコシステムにおいて、新たな取引先を見い出すかもしれない。はてまた、現状において直接的取引関係にある顧客が、その先の顧客から選ばれる続けるための成長ドライバを考えていく必要もあろう。そこで、前ステップで検討された価値定義に関わる利害関係者を広く捉え、「SIerなどパートナーになりうる存在」「B2Bの場合はその先にいる取引先やユーザー」「行政」など利害関係者を想定しておくことが望ましい。
本ステップで発生しうる不具合として、やみくもに利害関係者を数多くリストアップすることに時間を浪費することが挙げられる。重要なことは、後続ステップにおいて直接的な顧客のみに縛られた未来課題検討に陥ることを避けることである。利害関係者の抜け漏れ防止は最重要事項ではない。検討を進めていく過程で重要な利害関係者の存在に気がつくことがあれば、その時にリストに追加すればよい。
もう一つの不具合は、(1)リストアップした利害関係者数が多く、(2)利害関係者の記述が固有名詞ではなく一般的なカテゴリ表現になっている場合、その後の検討が抽象的な一般論に陥る恐れがある。これを避けるため、リストアップした後に検討対象となる利害関係者を取捨選択し、各主体をペルソナ化することが対策として考えられる。
3. 各主体の関心事
主体ごとに、関心事を検討する。ここで挙げられる関心事は、「5～10年後」という時制は加味されておらず、「現状の関心事」である場合が多い。そこで、主体別に関心事が挙げられた後に、「これらは現在の関心事ではないですか？」「これらの中で、現時点では顕在化しておらず、将来に顕在化する課題はどれですか？」と問うて各関心事の時制を確かめる。その問いに対する回答として「現時点でも課題であるが、5～10年後も依然として課題であり続ける。だから、これは未来課題だ」が想定されるが、この種の回答に対する対処として「求められる達成レベルは、現在と将来で違うかもしれませんが、それはOEの問題であり、課題項目そのものとしてはすでに存在しているということですね？」と確認する。
4. 未来の関心事変化の可能性（新機軸となりうる未来課題の存在可能性）
未来を見据えると、今後、各主体の関心事に新規事項は発生するか否か？答えは“YES” or “NO” の二択。前ステップで各主体の関心事の時制を確認したことを受けて、「1. 事業ドメイン価値定義」から見て、未来は前出の主体に新たな課題がありそうかどうかを直感的に判断することを促す。本ステップを明示的に扱う理由は、これまでのWSにおいて花火マップを作成しても現在とちっとも変わらない課題しか導出できなかったケースが散見したため。本ステップの狙いは、後続する「ビッグ5の選択」と「花火マップづくり」が、「現在課題とは一線を画す新課題を導出するためだぞ！」ということを強く意識してもらうことにある。花火マップを手間暇かけて実行する目的と必要性をメンバー各人に自覚してもらうことにある。
5. ビッグ５の選択
各主体の未来の関心事を占うにあたり、着目すべきキーワードは何か。PESTキーワード集を読み返して、3～5個を選ぶ。その際、同方向のキーワードばかりを選ばないように注意する。たとえば、AI、IoT、ビッグデータなど先端ICT技術に集中したキーワード出しが考えられる。選んだキーワードが、X軸、Y軸、Z軸のようにそれぞれ直交関係にあるくらいが理想的。
6. 未来課題リスト
具体的に何ができるようになればよいか。複数人で検討する場合は、マインドマップを模した花火マップを用いてブレーンストーミング形式で取り組むのもよい。
ここでリストアップすべきは “Do結果” なのか、それとも “Doニーズ” なのかという議論があるが、現時点での可能性としては、本ステップは “Do結果” が相応しいのではないかと思われる。未来課題の言い回しは、「いかに、・・・を、・・・するか」というイシュー形式が望ましいと考えられるが、その際に、主語（特定の利害関係者名）を記載するかどうかが今後の課題として挙げられる。しばらくの間は、主語を記載するパターンと意図的に主語を割愛するパターンの両方がありうると考えておきたい。イシュー表現の際、次の点を考慮したい。
(1)イシューの表現形式： イシュー表現は「～の最大化」あるいは「～の最小化」のどちらかの言い回しに置き換え可能な内容がよい。これができれば後続するDo展開がやりやすい。ただし、「～の最大化」あるいは「～の最小化」に置き換え可能かどうかはファシリテーターの頭に中に留め、メンバーには余計な思考上の負担をかけないために教示しない。
(2)イシューの表現内容： 最大化および最小化の対象について、「豊かさの最大化」「充実感の最大化」などの心理的要因や価値評価ワードや抽象名詞を用いた表現は、「それは具体的に何を意味するのか？」「それは具体的に何がどうなることをいうのか？」というwhatの堂々巡りを招く。Do結果表現は、主観を排した客観的な測定可能な尺度に置き換えられるものが望ましい。一つと手がかりとして、その未来課題が示唆するスクリプトを想像し、そのスクリプトの良し悪しを測る尺度を想定してみるのはどうだろうか。
7. 事業ドメイン価値再定義
前ステップで述べた2つの留意点をふまえたイシュー表現ができれば、各イシューは「自分たちは、どのようなスクリプトに関わりたいと思っているのか」、「そのスクリプトがどうなればいいと思っているのか」、「どういうスクリプトにおいて、何がどうなればいいと思っているのか」、「どういうスクリプトにおいて、何が達成されることを願っているのか」といった問いの答えを示しているも同然。「これらの未来課題を総称すると、我々は事業を通じてどのような価値を実現したいと願っているといえるか」という観点から、事業ドメインの価値をあらためて定義したい。なお、再定義する際は、今後リードユーザー法で水平展開していくことに備えて、程よい抽象化を施した表現が望ましいと思われる。ただし、過度な抽象化は、新幹線車内広告系の表現内容になり、検討時の思考停止を引き起こす恐れがある。「程よい抽象化」がどの程度なのかについては今後の課題。
8. 未来課題の尺度化
各未来課題を「～の最大化」or「～の最小化」のどちらかの言い回しでDo結果の表現形式に変換する。この検討は前述の「ステップ6. 未来課題リスト」において、ファリシテーターの頭の中で既に済んでいるが、これをメンバーの共に明示的に行い、次のステップに備える。その際、スクリプト概念を持ち込むと後続ステップをなお一層効果的に進めることができる。ただし、それをするのは2回目以降のPDCAとし、初回トライアルではメンバーの思考負荷を下げるためにスクリプトを不使用にしたほうがよい場合もある。
9. Do結果の系統化
必要に応じて、Do結果を小割する。本ステップは今後の課題の本丸の一つ。これまでは、Do結果から直ちにDoニーズに変換していたが、Do結果表現が過度に大きい場合、Doニーズに変換しようがないケースが見受けられた。大きなDo結果の場合、それに従属する子分Do結果に小割しておいたほうが検討しやすいことが予想される。目的-手段の要領ではなく、要素分解の要領で系統的に小割することを考えたい。どこまで小割していけばよいのかについての基準づくりは今後の課題。小割するたびに、「それを達成するために、何をどうすればよいか」を考え、その答えが観察可能な行為だった時が小割作業終了のサインかもしれない。
10. Do展開
Doニーズの表現形式は、「・・・を・・・する」という第３文型表現。求められる要件は、第三者から見て観察可能な行為であること。すなわち、Observationalか否か。前ステップと同様、本ステップも今後の課題の本丸の一つ。これまでのケースで見受けられたDo展開中の現象は次のとおり。
（１）Do結果とDoニーズの混同： 検討者本人はDoニーズだと思っていることが、内容をみるとDo結果である場合が非常に多い。両者の混同を引き続こす最大の原因は、Observational（第三者から見て観察可能な行為）の意味を理解できていないこと。検討者本人がDo結果とDoニーズを混同していたとしても、ファリシテーターがそれに気づけば修正できるが、Do結果とDoニーズの見極められないファリシテーターは事態を解決できない。
（２）方策好き： 「議論を深めることなく、すぐに方策を考えたがる」という現象が頻発する。Do展開したら目的語が直ちに方策名になることを避けるため、「それをするには、どうすればいいですか？」という “How” ではなく、「それは具体的に何をするのですか？段取りを表してみましょう」という “What（詳細な段取り表現化）” の教示に改めたい。これは「詳細スクリプト表現」といってもいいかもしれない。
（３）淡々とした意思のない展開： 展開することそのものを目的化すると、淡々と現状分析しただけになりかねない。Do展開は、ロジックツリー状に論理的に考えればよいというものではなく、意思をもって展開することが求められる。つまり、論理は論理でも、上位の事象を構成する要素に帰納推論すればよいのではなく、しかるべき価値基準をルールにした演繹推論が求められる。Do展開の良し悪しを測る評価基準は、(1) 論理的に正しいかどうかに加え、（2) 展開のされ方が自分たちらしいかどうか。前者だけなら、帰納推論でも演繹推論でも満たせるが、後者は演繹推論でしか満たせない。某プロジェクトにおいて、自分たちらしい展開の様子を「パナ展開」と呼んでいたことが象徴。この演繹推論問題によって新たに生まれる課題は、「自分たちらしさ」を表す価値基準を、あらかじめどのように明示化しておくかということ。少なくとも、事業ドメイン価値定義だけでは対応できない。解決策の筆頭は、DICモデルではないか。
演繹的にDo展開するサポートする側に求められる能力は、さきのDo結果とDoニーズの混同問題の比にならないほど高い。すくなくとも、クリティカルシンキングの完全マスターは必須。これがないと話にならない。しかし、クリティカルシンキングだけでも事足りない。‘鵑弔了?櫃魴襪岷蜈菴簣瀬襦璽襪虜猯繊淵ライアントが言い放つ言葉の断片）を拾い集める能力に加え、⊇Δそ犬瓩榛猯舛捻蜈菴簣瀬襦璽襪領嚇戮鯆汗阿垢詛塾蓮蔽蠑櫺修閥饌硫修旅圓来）、さらには、Ｎ嚇拂汗宛紊留蜈菴簣瀬襦璽襪鬟ライアントが使いこなせるようにルールの言い方をあの手この手で多様に言い換える語彙を持ち合わせていること、け蜈菴簣瀬襦璽襪硫樟瀋蠍紊慮‘ぜ圓砲茲觴尊櫃留蜈菴簣世亮蠹舛ぁ覆燭箸┐弌屬海留蜈菴簣瀬襦璽襪亡陲鼎韻弌△燭箸┐个海譴呂海Σ鮗瓩任ますか？」とYES/NO回答可能な叩き案の提示）、イ気の手伝いが自転車の補助輪に相当するイメージであるのに対し、検討者が自立的にトライアンドエラーの繰り返している様子を見ながらの演繹推論ルールを精緻化する、などなど。しかも、これらをほぼ瞬間的に高速で実行する必要がある。論理的思考力や語彙力に加え、「反射神経（即応性）がものを言う」ともいえる。
（４）文脈形成ではなく、要素出しに腐心： Do展開において、特定レイヤーの要素出しに腐心する検討者が少なくない。いろいろな要素を出したくなる気持ちはわかるが、重要なことは、縦ラインの充実化ではなく、横ラインの「文脈づくり」。つまり、「欲しい結果（Do結果）を得るために、どんなDoが未来のニーズになりうるか？」「その未来のDoニーズを満たすために、我々はどんなDoを担うべきか？」という目的-手段の文脈づくり。特定のレイヤーで漏れがないようにありったけの要素出しに腐心するのは時間の無駄使い。まずは、文脈づくりを最優先すべき。そのあと、ほかにも文脈があるのではないかという視点から、レイヤー内の要素出しに取組むことが望ましい。特定レイヤーの要素出しに腐心している状況に修正をかけられるようにするための策は、完成すべき図面を到達点として明示的にしておくこと。しかし、実際の現場では言うほど簡単ではない。目まぐるしく事態が動いているため、メンバー各人には、プレーヤーとしての自分とは別に、場をモニタリングしている自分も存在させておかなければならない。だからファリシテーターが必要ということになるが、ファリシテーター役に徹する人を設定しても、到達点から見て、いまのこの状況をどう見ればいいのか、目の当たりにしている状況から何を読み取り、どう働きかければよいかを即断することは難しい。
11. 自社担当Doの選定
Do展開表に記されたDo要素のうち、自社が担うDoを選ぶ。
12. ハード・ソフトの検討
自社が担うDoをハード・ソフトに置き換える
13. 顧客進歩プロセスの検討
ハード・ソフトの検討まで一通りの流れを経験後、顧客Do結果を再検討して顧客進歩プロセスを描くとよい。お星さまに相当する「親分級Do結果」に向かって、最初に達成すべきDo結果は何か。そのDo結果を土台にして次に達成すべきDo結果は何か。それら一連のDo結果があればこそ、ファイナルステージで達成すべきDo結果は何か。そのようなホップ・ステップ・ジャンプ形式でDo結果達成のストーリーが顧客から見て魅力的であるほど、長期にわたる良好な顧客関係性が築かれると同時に、各Do結果を実現するための道具としてのハード・ソフトが継続的に顧客によって取り入れられ、顧客シェアが高まる。顧客進歩プロセスを組み立てる際の留意点として、次の点が挙げられる。
(1) スクリプト概念を持ち込むことができるようであれば、「現状スクリプトから、理想スクリプトへの移行は即座に実現困難だとすれば、移行過程を全3期構成で考えた場合、どのようなプロセスが考えられるか？」という問いかけが有効。
(2) 共創目的めある「親分級Do結果」を出発点として、ジャンプ→ステップ→ホップという逆の順で、バックキャスティングの要領で考える。後ろのステップは、前のステップが成り立っていることが前提になるように組み立てる。ホップとステップをひっくり返しても特に違和感がないという場合、両者は独立であるという意味であり、一方がもう一方を前提にしている関係ではない。
14. Do展開表の完成
左から「ホップ/ステップ/ジャンプの区別」、「Do結果」、「一次Do」、「二次Do」、「三次Do」、「自社担当可否」という順で項目が並ぶ表において、自社担当可と判定された行の最右列にハード・ソフトの名称および概要を記してDo展開表を完成させる。
今後の課題として、自社製品ハード・ソフトを具体的に検討するにあたり、新たに「保証項目」という列を設けて、ハード・ソフトの機能に求められる要件を明記するようにしたい。
さらに別の今後の課題として、Do展開表とQFD品質表とのドッキングを考えたい。これができれば、品質保証体系図における「ソリューション企画」の管理手順フロー化ができる。
15. マネタイズ・シナリオの策定
【後日に記載】
16. 自社Doの洗い出し
マネタイズ・シナリオの実際にものにするために自社オペレーションに求められる諸活動を洗い出す。詳しくは、後日に加筆。
17. 活動システム図の構築
前ステップで洗い出された活動間の前後関係に着目して、全体構造を活動システムとして作図する。作図中に活動項目の不足に気づく場合が多いことから、適宜、活動間の因果を補う活動を追加する。
活動システム ver.1は、あくまで特定顧客のDoに応えるための全体像に過ぎない。実際には、当該顧客のほかにも多くの顧客Doに効率よく対応できるようにしなければならない。また、顧客対応の経験を重ねることによって、オペレーションを習熟させていくことが求められる。「いかに多くの顧客に対応するか」「いかにオペレーションを習熟させていくか」という視点から、それを支える活動を新たな項目として検討し、活動システム ver.2としてアップデートする。詳しくは、後日に加筆。
我々は何のために存在しているのか。事業を通じて叶えたいことは何か。検討に先立ち、自分たちの思いを表出する。本ステップの回答は、花火マップを用いた未来課題検討の際の「初期値」としての役割を担う。これにより、後続する「ビッグ５」や「未来課題」が総花的な一般論に陥ることを回避できる。
2. 関わる主体（利害関係者）のリストアップ
定義された価値内容の実現に関わるのは誰か。前ステップで定義された価値内容を物語にした時の登場人物に相当。本ステップを新たに追加した狙いは、現行ビジネスにおける直接的な顧客のみに縛られないようにすること。未来を見据えた新たなビジネスモデルは、現状において直接的取引関係にある顧客に対して、新たなパートナーと協働して向き合うことになるかもしれない。また、共通価値テーマのもとで構成されたエコシステムにおいて、新たな取引先を見い出すかもしれない。はてまた、現状において直接的取引関係にある顧客が、その先の顧客から選ばれる続けるための成長ドライバを考えていく必要もあろう。そこで、前ステップで検討された価値定義に関わる利害関係者を広く捉え、「SIerなどパートナーになりうる存在」「B2Bの場合はその先にいる取引先やユーザー」「行政」など利害関係者を想定しておくことが望ましい。
本ステップで発生しうる不具合として、やみくもに利害関係者を数多くリストアップすることに時間を浪費することが挙げられる。重要なことは、後続ステップにおいて直接的な顧客のみに縛られた未来課題検討に陥ることを避けることである。利害関係者の抜け漏れ防止は最重要事項ではない。検討を進めていく過程で重要な利害関係者の存在に気がつくことがあれば、その時にリストに追加すればよい。
もう一つの不具合は、(1)リストアップした利害関係者数が多く、(2)利害関係者の記述が固有名詞ではなく一般的なカテゴリ表現になっている場合、その後の検討が抽象的な一般論に陥る恐れがある。これを避けるため、リストアップした後に検討対象となる利害関係者を取捨選択し、各主体をペルソナ化することが対策として考えられる。
3. 各主体の関心事
主体ごとに、関心事を検討する。ここで挙げられる関心事は、「5～10年後」という時制は加味されておらず、「現状の関心事」である場合が多い。そこで、主体別に関心事が挙げられた後に、「これらは現在の関心事ではないですか？」「これらの中で、現時点では顕在化しておらず、将来に顕在化する課題はどれですか？」と問うて各関心事の時制を確かめる。その問いに対する回答として「現時点でも課題であるが、5～10年後も依然として課題であり続ける。だから、これは未来課題だ」が想定されるが、この種の回答に対する対処として「求められる達成レベルは、現在と将来で違うかもしれませんが、それはOEの問題であり、課題項目そのものとしてはすでに存在しているということですね？」と確認する。
4. 未来の関心事変化の可能性（新機軸となりうる未来課題の存在可能性）
未来を見据えると、今後、各主体の関心事に新規事項は発生するか否か？答えは“YES” or “NO” の二択。前ステップで各主体の関心事の時制を確認したことを受けて、「1. 事業ドメイン価値定義」から見て、未来は前出の主体に新たな課題がありそうかどうかを直感的に判断することを促す。本ステップを明示的に扱う理由は、これまでのWSにおいて花火マップを作成しても現在とちっとも変わらない課題しか導出できなかったケースが散見したため。本ステップの狙いは、後続する「ビッグ5の選択」と「花火マップづくり」が、「現在課題とは一線を画す新課題を導出するためだぞ！」ということを強く意識してもらうことにある。花火マップを手間暇かけて実行する目的と必要性をメンバー各人に自覚してもらうことにある。
5. ビッグ５の選択
各主体の未来の関心事を占うにあたり、着目すべきキーワードは何か。PESTキーワード集を読み返して、3～5個を選ぶ。その際、同方向のキーワードばかりを選ばないように注意する。たとえば、AI、IoT、ビッグデータなど先端ICT技術に集中したキーワード出しが考えられる。選んだキーワードが、X軸、Y軸、Z軸のようにそれぞれ直交関係にあるくらいが理想的。
6. 未来課題リスト
具体的に何ができるようになればよいか。複数人で検討する場合は、マインドマップを模した花火マップを用いてブレーンストーミング形式で取り組むのもよい。
ここでリストアップすべきは “Do結果” なのか、それとも “Doニーズ” なのかという議論があるが、現時点での可能性としては、本ステップは “Do結果” が相応しいのではないかと思われる。未来課題の言い回しは、「いかに、・・・を、・・・するか」というイシュー形式が望ましいと考えられるが、その際に、主語（特定の利害関係者名）を記載するかどうかが今後の課題として挙げられる。しばらくの間は、主語を記載するパターンと意図的に主語を割愛するパターンの両方がありうると考えておきたい。イシュー表現の際、次の点を考慮したい。
(1)イシューの表現形式： イシュー表現は「～の最大化」あるいは「～の最小化」のどちらかの言い回しに置き換え可能な内容がよい。これができれば後続するDo展開がやりやすい。ただし、「～の最大化」あるいは「～の最小化」に置き換え可能かどうかはファシリテーターの頭に中に留め、メンバーには余計な思考上の負担をかけないために教示しない。
(2)イシューの表現内容： 最大化および最小化の対象について、「豊かさの最大化」「充実感の最大化」などの心理的要因や価値評価ワードや抽象名詞を用いた表現は、「それは具体的に何を意味するのか？」「それは具体的に何がどうなることをいうのか？」というwhatの堂々巡りを招く。Do結果表現は、主観を排した客観的な測定可能な尺度に置き換えられるものが望ましい。一つと手がかりとして、その未来課題が示唆するスクリプトを想像し、そのスクリプトの良し悪しを測る尺度を想定してみるのはどうだろうか。
7. 事業ドメイン価値再定義
前ステップで述べた2つの留意点をふまえたイシュー表現ができれば、各イシューは「自分たちは、どのようなスクリプトに関わりたいと思っているのか」、「そのスクリプトがどうなればいいと思っているのか」、「どういうスクリプトにおいて、何がどうなればいいと思っているのか」、「どういうスクリプトにおいて、何が達成されることを願っているのか」といった問いの答えを示しているも同然。「これらの未来課題を総称すると、我々は事業を通じてどのような価値を実現したいと願っているといえるか」という観点から、事業ドメインの価値をあらためて定義したい。なお、再定義する際は、今後リードユーザー法で水平展開していくことに備えて、程よい抽象化を施した表現が望ましいと思われる。ただし、過度な抽象化は、新幹線車内広告系の表現内容になり、検討時の思考停止を引き起こす恐れがある。「程よい抽象化」がどの程度なのかについては今後の課題。
8. 未来課題の尺度化
各未来課題を「～の最大化」or「～の最小化」のどちらかの言い回しでDo結果の表現形式に変換する。この検討は前述の「ステップ6. 未来課題リスト」において、ファリシテーターの頭の中で既に済んでいるが、これをメンバーの共に明示的に行い、次のステップに備える。その際、スクリプト概念を持ち込むと後続ステップをなお一層効果的に進めることができる。ただし、それをするのは2回目以降のPDCAとし、初回トライアルではメンバーの思考負荷を下げるためにスクリプトを不使用にしたほうがよい場合もある。
9. Do結果の系統化
必要に応じて、Do結果を小割する。本ステップは今後の課題の本丸の一つ。これまでは、Do結果から直ちにDoニーズに変換していたが、Do結果表現が過度に大きい場合、Doニーズに変換しようがないケースが見受けられた。大きなDo結果の場合、それに従属する子分Do結果に小割しておいたほうが検討しやすいことが予想される。目的-手段の要領ではなく、要素分解の要領で系統的に小割することを考えたい。どこまで小割していけばよいのかについての基準づくりは今後の課題。小割するたびに、「それを達成するために、何をどうすればよいか」を考え、その答えが観察可能な行為だった時が小割作業終了のサインかもしれない。
10. Do展開
Doニーズの表現形式は、「・・・を・・・する」という第３文型表現。求められる要件は、第三者から見て観察可能な行為であること。すなわち、Observationalか否か。前ステップと同様、本ステップも今後の課題の本丸の一つ。これまでのケースで見受けられたDo展開中の現象は次のとおり。
（１）Do結果とDoニーズの混同： 検討者本人はDoニーズだと思っていることが、内容をみるとDo結果である場合が非常に多い。両者の混同を引き続こす最大の原因は、Observational（第三者から見て観察可能な行為）の意味を理解できていないこと。検討者本人がDo結果とDoニーズを混同していたとしても、ファリシテーターがそれに気づけば修正できるが、Do結果とDoニーズの見極められないファリシテーターは事態を解決できない。
（２）方策好き： 「議論を深めることなく、すぐに方策を考えたがる」という現象が頻発する。Do展開したら目的語が直ちに方策名になることを避けるため、「それをするには、どうすればいいですか？」という “How” ではなく、「それは具体的に何をするのですか？段取りを表してみましょう」という “What（詳細な段取り表現化）” の教示に改めたい。これは「詳細スクリプト表現」といってもいいかもしれない。
（３）淡々とした意思のない展開： 展開することそのものを目的化すると、淡々と現状分析しただけになりかねない。Do展開は、ロジックツリー状に論理的に考えればよいというものではなく、意思をもって展開することが求められる。つまり、論理は論理でも、上位の事象を構成する要素に帰納推論すればよいのではなく、しかるべき価値基準をルールにした演繹推論が求められる。Do展開の良し悪しを測る評価基準は、(1) 論理的に正しいかどうかに加え、（2) 展開のされ方が自分たちらしいかどうか。前者だけなら、帰納推論でも演繹推論でも満たせるが、後者は演繹推論でしか満たせない。某プロジェクトにおいて、自分たちらしい展開の様子を「パナ展開」と呼んでいたことが象徴。この演繹推論問題によって新たに生まれる課題は、「自分たちらしさ」を表す価値基準を、あらかじめどのように明示化しておくかということ。少なくとも、事業ドメイン価値定義だけでは対応できない。解決策の筆頭は、DICモデルではないか。
演繹的にDo展開するサポートする側に求められる能力は、さきのDo結果とDoニーズの混同問題の比にならないほど高い。すくなくとも、クリティカルシンキングの完全マスターは必須。これがないと話にならない。しかし、クリティカルシンキングだけでも事足りない。‘鵑弔了?櫃魴襪岷蜈菴簣瀬襦璽襪虜猯繊淵ライアントが言い放つ言葉の断片）を拾い集める能力に加え、⊇Δそ犬瓩榛猯舛捻蜈菴簣瀬襦璽襪領嚇戮鯆汗阿垢詛塾蓮蔽蠑櫺修閥饌硫修旅圓来）、さらには、Ｎ嚇拂汗宛紊留蜈菴簣瀬襦璽襪鬟ライアントが使いこなせるようにルールの言い方をあの手この手で多様に言い換える語彙を持ち合わせていること、け蜈菴簣瀬襦璽襪硫樟瀋蠍紊慮‘ぜ圓砲茲觴尊櫃留蜈菴簣世亮蠹舛ぁ覆燭箸┐弌屬海留蜈菴簣瀬襦璽襪亡陲鼎韻弌△燭箸┐个海譴呂海Σ鮗瓩任ますか？」とYES/NO回答可能な叩き案の提示）、イ気の手伝いが自転車の補助輪に相当するイメージであるのに対し、検討者が自立的にトライアンドエラーの繰り返している様子を見ながらの演繹推論ルールを精緻化する、などなど。しかも、これらをほぼ瞬間的に高速で実行する必要がある。論理的思考力や語彙力に加え、「反射神経（即応性）がものを言う」ともいえる。
（４）文脈形成ではなく、要素出しに腐心： Do展開において、特定レイヤーの要素出しに腐心する検討者が少なくない。いろいろな要素を出したくなる気持ちはわかるが、重要なことは、縦ラインの充実化ではなく、横ラインの「文脈づくり」。つまり、「欲しい結果（Do結果）を得るために、どんなDoが未来のニーズになりうるか？」「その未来のDoニーズを満たすために、我々はどんなDoを担うべきか？」という目的-手段の文脈づくり。特定のレイヤーで漏れがないようにありったけの要素出しに腐心するのは時間の無駄使い。まずは、文脈づくりを最優先すべき。そのあと、ほかにも文脈があるのではないかという視点から、レイヤー内の要素出しに取組むことが望ましい。特定レイヤーの要素出しに腐心している状況に修正をかけられるようにするための策は、完成すべき図面を到達点として明示的にしておくこと。しかし、実際の現場では言うほど簡単ではない。目まぐるしく事態が動いているため、メンバー各人には、プレーヤーとしての自分とは別に、場をモニタリングしている自分も存在させておかなければならない。だからファリシテーターが必要ということになるが、ファリシテーター役に徹する人を設定しても、到達点から見て、いまのこの状況をどう見ればいいのか、目の当たりにしている状況から何を読み取り、どう働きかければよいかを即断することは難しい。
11. 自社担当Doの選定
Do展開表に記されたDo要素のうち、自社が担うDoを選ぶ。
12. ハード・ソフトの検討
自社が担うDoをハード・ソフトに置き換える
13. 顧客進歩プロセスの検討
ハード・ソフトの検討まで一通りの流れを経験後、顧客Do結果を再検討して顧客進歩プロセスを描くとよい。お星さまに相当する「親分級Do結果」に向かって、最初に達成すべきDo結果は何か。そのDo結果を土台にして次に達成すべきDo結果は何か。それら一連のDo結果があればこそ、ファイナルステージで達成すべきDo結果は何か。そのようなホップ・ステップ・ジャンプ形式でDo結果達成のストーリーが顧客から見て魅力的であるほど、長期にわたる良好な顧客関係性が築かれると同時に、各Do結果を実現するための道具としてのハード・ソフトが継続的に顧客によって取り入れられ、顧客シェアが高まる。顧客進歩プロセスを組み立てる際の留意点として、次の点が挙げられる。
(1) スクリプト概念を持ち込むことができるようであれば、「現状スクリプトから、理想スクリプトへの移行は即座に実現困難だとすれば、移行過程を全3期構成で考えた場合、どのようなプロセスが考えられるか？」という問いかけが有効。
(2) 共創目的めある「親分級Do結果」を出発点として、ジャンプ→ステップ→ホップという逆の順で、バックキャスティングの要領で考える。後ろのステップは、前のステップが成り立っていることが前提になるように組み立てる。ホップとステップをひっくり返しても特に違和感がないという場合、両者は独立であるという意味であり、一方がもう一方を前提にしている関係ではない。
14. Do展開表の完成
左から「ホップ/ステップ/ジャンプの区別」、「Do結果」、「一次Do」、「二次Do」、「三次Do」、「自社担当可否」という順で項目が並ぶ表において、自社担当可と判定された行の最右列にハード・ソフトの名称および概要を記してDo展開表を完成させる。
今後の課題として、自社製品ハード・ソフトを具体的に検討するにあたり、新たに「保証項目」という列を設けて、ハード・ソフトの機能に求められる要件を明記するようにしたい。
さらに別の今後の課題として、Do展開表とQFD品質表とのドッキングを考えたい。これができれば、品質保証体系図における「ソリューション企画」の管理手順フロー化ができる。
15. マネタイズ・シナリオの策定
【後日に記載】
16. 自社Doの洗い出し
マネタイズ・シナリオの実際にものにするために自社オペレーションに求められる諸活動を洗い出す。詳しくは、後日に加筆。
17. 活動システム図の構築
前ステップで洗い出された活動間の前後関係に着目して、全体構造を活動システムとして作図する。作図中に活動項目の不足に気づく場合が多いことから、適宜、活動間の因果を補う活動を追加する。
活動システム ver.1は、あくまで特定顧客のDoに応えるための全体像に過ぎない。実際には、当該顧客のほかにも多くの顧客Doに効率よく対応できるようにしなければならない。また、顧客対応の経験を重ねることによって、オペレーションを習熟させていくことが求められる。「いかに多くの顧客に対応するか」「いかにオペレーションを習熟させていくか」という視点から、それを支える活動を新たな項目として検討し、活動システム ver.2としてアップデートする。詳しくは、後日に加筆。