| 芦屋： | さて，今日は昨日の続きで提案の骨子とテーマを考えていこう。繰り返しになるけど，キーワードは面倒くさい。一つ目は東さんが我々の提案を「面倒くさい」と思わせないほど先方が喜ぶ「オリジナルのセールスポイント」，もう一つは東さんの社内調整作業の「面倒臭さ」を軽減してあげること。では，整理して考えていこう。まず，一つ目から。
|
| 岡田： | 東さんが喜ぶセールスポイントは，「安心」，「現場混乱なし」，「不満なし」ということですね。
|
| 芦屋： | うん。でも，それは抽象的なので，そのままでは駄目。これをブレイクダウンしていこう。まず，「安心」，「現場混乱なし」，「不満なし」と東さんが思える状態とそれを実現するための方策はどういうものが必要かな。
|
| 坂本： | ・・・さあ，どうですかね。あちらの会社のことはよく分からないな。例えば，先方のテストも大事になると思うけど，こちらの仕事ではないですし。
|
| 芦屋： | まあ，考える上では，役割を意識しないほうがいいよ。まず，両者にとってあるべき状態とその諸策を考える。役割分担論はその後でいいよ。
|
| 坂本： | でも，役割を明確にしておかないと先方の仕事もこちらにやらされますよ。ますますコストがかかるじゃないですか？
|
| 芦屋： | では質問。今回の仕事はどこからが先方で，どこからがこっちの仕事なの？岡田が分かるんなら言ってみてよ。
|
| 岡田： | それは，すぐには言えませんよ。今回のケースは単なる請負のシステム構築ではないんだから・・・一歩間違えば，何でもやらされる可能性がありますよ。だから，できるだけこちらでやることは少なくしないとまずいんじゃないですか？
|
| 芦屋： | そう。その通り。だからこそ全工程を通した両者のあるべき作業分担がいる。それを考えるためには，先方と当方を横断的に見た裏のプロジェクトマネージメントが必要なんだ・・・まず，全体を一つのプロジェクトと考えて，タスクを定義する。そして，プロジェクトリスクを洗い出し，リスク対策の諸策を検討，プロジェクト運営に盛り込む。そして，最適な先方と当方の役割分担を考える。ここで大事なのは，まず，役割分担を明確にして提案することだよ。それをした上で，どこまで先方のタスクをサポートするのか提案すること。これが上手くできると先方は満足を感じるんだ。
|
| 岡田： | 先方のタスクをサポートすることが満足につながる？
|
| 芦屋： | そう。例えば，先方のユーザが行う業務テストは先方のタスクだよ。基本的に我々には先方の業務フローやオペレーションが分からないから僕たちではテスト計画を書くことができないんだ。
|
| 坂本： | それは，その通りですね。
|
| 芦屋： | 岡田の言ったように，こんなタスクをこちらで引き受けてしまったら大変だ。当方に責任があるのに，タスクが遂行できないのだから，待っているのは「失策」というレッテルだ。これは絶対避けなければならない。
|
| 坂本： | 当然ですね。
|
| 芦屋： | でも，このタスクを先方が「自身の責任タスク」と理解した上で，当方がサポートする形を提案をしたらどうだろう？
|
| 坂本： | サポートする形ですか？
|
| 芦屋： | そう。あくまで先方のタスク・・・でも，テスト計画の作成やオペレーション時の先方ユーザへの教育支援などをしてあげたら非常に先方は助かるはずだよ。
|
| 岡田： | そりゃ，そうでしょうね。でも，そこまでする必要があるのでしょうか？
|
| 芦屋： | ・・・岡田，まだまだ今回の我々の立場が読めてないな。どうせ，先方はあとからサポートを要求してくるんだ。だったら，最初からサポートというサービスを提案項目にして，喜んでもらったほうがいい。
|
| 岡田： | どういうことですか・・・
|
| 芦屋： | 我々は商品を卸して売ってもらう側だよ・・・立場は弱い。もし，当社の商品を卸すことができても，今後とも相応のサービス提供を余儀なくされるんだよ。
|
| 岡田： | ・・・
|
| 芦屋： | 東氏は，一人か二人で先方のシステム導入を担当してる。営業担当の戸塚さんはシステムはまったく分からない。だから，東氏には大きな負担がかかるはずだよ。だから，最初から見えているんだよ。我々に要求されることは・・・
|
| 坂本： | 東氏が忙しくなって仕事が回らなくなる・・・先方のシステム導入の準備が乱れる・・・先方の社内で東氏が責められる・・・東氏が我々にサポートを強く要請する・・・我々は断れない・・・
|
| 芦屋： | そうなってみろ。準備できてなかったら，絶対にサポートできない。そのときになって，急に先方の業務を調べたって身につくものか・・・結局，見えているんだよ結果は。
|
| 岡田： | 言われていることは分かります。でも，それは，考えすぎではないのでしょうか？そんなのは最悪のシナリオ・・・悲観的過ぎるシナリオではないのでしょうか？
|
| 芦屋： | では，岡田，そうならないと君は言い切れるのかな。そうならないシナリオを教えてほしい。
|
| 岡田： | それは・・・
|
| 芦屋： | 岡田，坂本・・・いいか。仕事は準備しすぎてやりすぎということはない。準備・・・事前にシナリオを考えることは頭の中でできる。物を作ることもないから金もかからない。でも，準備がいい加減で，途中で問題が起こって，それまでの構築物が無駄になったら損がでる・・・これがいいわけがないんだよ。
|
| 岡田： | ・・・確かに
|
| 芦屋： | もっと言おうか・・・今回の先方サポートはもっと他の意味もあるんだよ。
|
| 坂本： | もっと他の意味？
|
| 芦屋： | そう。この機会に，先方の業務を理解して，今後当方でコントロールしていきたいと思っている。つまり，前回言った「顧客担当者から業務知識を奪う」というヤツだ。こちらは最初は損かもしれないが，上手くやれば将来的な得はとれる・・・「損して得とる」の提案術だよ。
|
| 坂本： | そうか。当方に知識を集積していって，今後の当社の先方に対する影響力を拡大していこうというわけですね。
|
| 芦屋： | そう。結局，コンサルティング提案とはこういうことなんだ。先方の"面倒くさい"部分に訴求するサービス提供，当社に損にならない・・・先方に感謝される物言い，そして，先方に対し末永く影響力を発揮できるための諸策とそれを実現するシナリオが必要なんだ・・・岡田，坂本，ビジネスというのは受身ではいけない。目的を達成するための全体最適化を行い，シナリオに落とす。そして，それを進めていく。そういう”準備”こそが必要なんだよ。
|
