四則演算で一番難しいのは、間違いなく引き算
「人生は引き算で幸せになる！」
「やることは徹底的にシンプルに！」
巷にこういう本やネットの記事が溢れてます。
これを否定する気は全くなくて、むしろ、自分もこれは正論だと思います。
やることを減らせば、力を注ぐ対象が絞られて集中できる分、成功率はグッとあがります。
他の人が20の力を注いでるものに対して、こっちが80の力を注げるんですから。
「選択と集中」
戦略の基本ですね。
でも、今回は選択と集中の重要性だったり、それをどうやって実現にしていくのかについて言及はしません。
ただ単に、
「引き算って難しすぎ…」
って思うことが最近あったから、それについて書くだけです。
最近、仕事で似たようなトラブルが起きてるという現状がありました。
（個人単位ではなく、会社単位で）
そこで、この現状を改善すべく、問題点を特定して、それに対する解決策を立てて実行に移しました。
解決策を実施したてだったので、効果はまだ断言できませんが、以前よりトラブルは減ってる印象です。
今後もこれを続けて、都度修正を加えながらこの仕組みを運用していこうと思います。
おしまい。
めでたしめでたし。
ではないんです。
実は、この解決策には大きな問題点が一点あったのです。
それは、トラブルを防止するために、今までの仕事の流れに新しいプロセスを加えたこと。
わかりやすく言うと、「A→B→C」という仕事の流れに「D」を付け足したこと。
そう、足し算の発想なんです。
何が問題かって、「D」はその作業単体で見ると一分でできる作業なんですが、自分が抱えてる案件毎に「D」を行う必要があって、一人あたりの案件数が40件/月ぐらい、そして、人数が五人なので、
1分×40案件/月×5人=200分
会社として、200分/月、時間のロスが生じることになってしまうのです。
単体で見ると一分なんで、まぁいいかと思ってやっていたのですが、少し高い視点から見ると、結果として大きなロスが生まれてます。
視野が狭すぎました。
時間、手間がかからない解決策を立てるべきでした。
でも、今回以外のことでも、「まぁ時間かからないしいいや」って思ってやってる、省けることって多いように思います。
例えば、サンプル送る時にいちいちレター書くのとか、やめていいかもしれませんよね。
気付けたなら、明日から色々やめればいいやって話なんですけど、非常に悩ましいんです。
それは、この「ひと手間」が、意外と効果的だったりするから。
いきなりサンプルが送られてくるより、レターが入ってて、商品のコメントがあった方が、自分だったら絶対いい印象持つし、購買意欲掻き立てられますもん。
それに、日頃からいい印象持ってるお客さんは、多少の無理も聞いてあげようって思いますもん。
塵も積もれば山となるとはよく言ったもので、ひと手間も積もれば大きな効果につながりますが、時間に着目してすると、大きなタイムロスにも見えます。
このバランスの見極めがとてつもなく難しい。
だから、結果として引き算ができない、そんな現状が続いてしまうのです…。
問題発見の仮説立て→検証→問題の特定→問題解決の仮説立て
前回の記事で、仮説についての考えで「少しニュアンス的に伝わりにくい」、「間違って伝わる可能性がある」箇所があったので、補足します。
以下が問題箇所。
別に、最初の問題特定が完璧じゃなくていいんです。
仮説ベースで進めて、実際に検証の段階で間違いに気づいたら、もう一回問題を特定をすればいいだけの話です。
これだと、問題発見の仮説立てと問題解決の仮説立てを一気に済ませてしまうような印象を受けますが、実際は違います。
問題発見の仮説立てと問題解決の仮説立ては、分けて行うべきだと思います。
つまり、
問題発見の仮説立て→検証→問題の特定→問題解決の仮説立て→実行→検証…
というのが、あるべき一連の流れです。
なぜか？
それは、いくら解決策を考えたところで、その前提となる問題点が間違っていたら、解決策が当たる確率が格段に低くなるからです。
病院に行って、「話を聞く限り胃に腫瘍あるっぽいから、とりあえず腹切るわ」って言われたら怖いですよね？
そこはまずCTスキャンとかじゃないの？ってなりますよね。
問題解決も一緒で、まずは腹を切るべきかどうかをCTスキャンして見極めましょう。
（ここでいう「CTスキャン」は問題点の仮説検証手法で、「胃に腫瘍があるっぽい」というのが仮説そのものです）
ただ、「最初の問題特定は完璧じゃなくていい」と言ってるのはその言葉の通りです。
医者がCTスキャンして、やっぱり腫瘍がありそうだから腹を切ったけど、何もありませんでしたっていうのはなかなかマズイですが、ビジネスではそこまで取り返しがつかないようなことって、あんまりないじゃないですか。
むしろ、多少は間違っててもいいから解決策を実行して、違ってたら「再度問題特定→PDC」のサイクルを高速で回して、真因に迫っていく方がよっぽど効果的なわけで。
完璧な問題特定を目指してずっと考え込んで、何もしない方が罪です。
何もしなかったら、何も学べませんからね。
よって、問題発見と解決の仮説立てについての結論は以下の通りです。
問題解決の仮説立ては、問題発見の仮説を検証してから。
でも、最初から「絶対に100%何が何でも天に誓って間違いない」っていうレベルで問題を特定する必要はない。
ただ、「検証してみたけど、これでよさそう」っていうレベルまではもっていくべき。
問題解決とPDCAと戦略と、時々じゃなくて、ずっと仮説
タイトルが盛りだくさんで、見てるだけで胸やけおこしそうですね。
一単語で一記事書けるところを、欲張って、四単語を一記事で書いちゃいます。
この四つの単語は普通に社会人として生きてたら、一回は見たり聞いたりしてるはずです。
会社の研修でかもしれないし、本屋でかもしれないし、意識が高いブログでかもしれませんが、確実に「接触」してるはずです。
どれも聞いたことがない人は、まぁ、うん、その、頑張って強く生きてください。
ただ、問題なのはこれらの概念を知ってるのに使いこなせていないこと。
どこに問題があるのでしょう？
おそらくですが、これらの概念をバラバラに捉えてるところに問題があるんじゃないかと思います。
どうしてそんなことになってるのでしょう？
だって、バラバラに教わったもん！
じゃあ、これらをバラバラに捉えず、統合して考えみたら、理解して使えるようになるんじゃないでしょうか。
結論から書くと、PDCAも戦略も、問題解決の一部にすぎません。
そして、仮説は友達みたいなもんです。
「ずっとそばにいてくれる」的な。
意味不明だと思うので、解説していきます。
まず、ここで言ってる問題解決は「広義の問題解決」のことで、「問題発見」と「狭義の問題解決」によって構成されています。
数式にすると、
広義の問題解決＝問題発見＋狭義の問題解決
です。
問題を解決するには、まず、何が問題かを明確にしないといけません。
いきなり、解決策の立案（＝狭義の問題解決）に走ったらダメです。
病院行って、いきなり薬出されたら怖いですからね。
なので、まずはしっかりと問題を特定にかかりましょう。
以下の手順がオススメです。
1. 問題の定義（what）
2. 問題部分の特定（where）
3. 問題の原因の把握（why）
（例）
過度に太ってることが問題（what）
カロリーの過剰摂取、それもジュースによるものが多い（where）
「ジュース＝高カロリー」って認識がなかった（why）
こんな具合に、問題の真因を特定します。
そしたら、狭義の問題解決（How）にとりかかりましょう。
ただ、いきなり思いついたことをやったらダメです。
何もしないのもダメです。
やりっぱなしもダメです。
はい、わかりましたね。
ここでPDCAの登場です。
PDCAとは、狭義の問題解決（How）を各ステップに分解したものなのです。
P+D+C+A=狭義の問題解決（How）
なのです。
Plan（何をして、それによって何を期待するのかを明確にする）
Do（ちゃんとやる）
Check（やったことを検証する）
この3ステップを行うことが、狭義の問題解決です。
「Aciton」がない？
そう、ここが重要なポイント。
Actionが入るからPDCAがややこしくなると思うんです。
計画して、実行して、検証して…
ここまで着実なのに、
改善！
で、一気にジャンプしちゃってます。
それまでの三つの単語と「改善」は、明らかにレベル感が違いません？
「いや、改善って具体的に何よ…？」って個人的に思います。
なので、「改善」をもっと具体的にしましょう。
以下のような具合に。
改善＝二回目以降の問題の特定＋二回目以降のPDC
検証して、計画とズレてたら、問題設定をもう一度するべきです。
問題設定が違ったまま、解決策ばかり考えても無駄ですから。
本当の病気がわからないまま、薬をあれこれ試すようなもんです。
だから、検証の後は、「問題の発見」に戻りましょう。
解決策を考えて、実行して、また検証するのはそれからです。
うまくいった場合も、「なぜ、うまくいったのか」という真因を特定してから、次の打ち手に反映を考えていかないと、ただのまぐれ当たりに終わってしまいます。
で、「戦略」ですが、これはPDCの中のPlanだと思って問題ないと思います。
狭義の解決策の、さらにPlanという一部なので、戦略ってやつは広義の問題解決の極々一部です。
わりとカバー範囲狭めです。
最後に、仮説。
これは少しだけ問題解決、PDCA、戦略から独立してます。
（話が最初と少し違うのはご愛嬌）
仮説は、問題解決をするうえで、ずっと意識してないといけません。
問題を特定する時も、解決策を考える時も、常に仮説ありきです。
別に、最初の問題特定が完璧じゃなくていいんです。
仮説ベースで進めて、実際に検証の段階で間違いに気づいたら、もう一回問題を特定をすればいいだけの話です。
大事なのは、「問題特定＋PDC」を高速で回していくこと。
そしたら、真因にたどりついて、効果的な解決策も打てます。
ただ、「何を問題として捉えて、解決策を考えたか」は明確にしておきましょう。
長くなったので、問題解決、PDCA、戦略、仮説の関係性を簡単にまとめます。
広義の問題解決＝問題発見＋狭義の問題解決
問題発見＝what＆where＆why
狭義の問題解決＝Plan+Do+Check
Plan＝戦略
仮説＝ずっとそばいる友達（笑）
最後の方が駆け足なのは、きっと気のせい。
眠くなってきたらからではありません。
ぼくの二日間戦争
「アップデート終了まで60時間」
地獄かよ、iOS8.3…。
iPhone歴7年目にして、手垢がつきまくって真っ黒な「画面を割る」という愚行を働いてしまいました。
液晶部分がバキバキに割れたのではなく、縁の部分に1cmぐらいのヒビが入っただけだったので、別に放っておいてもよかったのですが、神経質な部分が全面的に出てきて、落とした2秒後ぐらいに「iPhone 画面 ヒビ 修理」でググってました。
バッキバキに割れたまま使ってる女子高生のメンタリティを少しは見習いたい。
調べた結果、どうやらまだ保証期間内、かつ、保険的なものに入っていたようで、8,000円ぐらいで新しいiPhoneに交換してくれるらしいです。
（gj、9ヵ月前の自分）
生まれて初めて「保険」というもののありがたさを感じました。
今まで、「人を脅して金を巻き上げるシステム」だと思っててごめんなさい。
で、新しいiPhoneを受け取って、ルンルン気分でデータを復元しようとしたら、新しいiPhoneはOSが8.2のままだから、8.3のバックアップデータを復元できないとのこと。
まぁ当然OSをアップデートしますよね。
そしたら表れたのが、冒頭のメッセージ。
それも、「アップデートを要求しています」のメッセージが1時間ぐらい表示された後に表れたもんだから、ダメージ大きいです。
何この、時間差すごいワンツーパンチ。
さすがに60時間は待てないので、アップルのサポートセンターに電話します。
最近よく思うんですけど、サポートセンターの電話番号が記載されてない企業多すぎません？
特にIT企業。
いや、たしかにサポートセンターの維持コストが高いから削減したいのはよくわかります。
かかってくる電話の内容も8割はどうでもいいものか、ググったら分かるようなことだってのもよーくわかります。
ただ、残りの2割の「ググってもどうにもならない、ならなかった問題」を抱えてる人からすると、電話番号が見当たらないのはすごいストレスなんです。
ここらへんのバランス感覚は非常に難しいですね。。
閑話休題。
サポートセンターの男性いわく、wifiでアップデートするより、iTunesでする方が早いとのことなので、早速やってみます。
が、なかなかiTunesとiPhoneがつながってくれません。
アップデート以前の問題。
この状況に対して、「こういう時のマニュアルをお送りするんで、その通りにやってみてください」と、サポセンの男性。
送られてきたマニュアル通りにやってみたり、他にも調べてみたものの、全く改善しません。
ここまで頑張ってダメだったんだから仕方ない、もう一回電話だ…！
「土日の営業は17時までとなります（自動応答）」
お兄さん、早くあがりたかったろうに、定時直前に電話して引きとめてごめんよ。
僕だったら無視して帰ってた…。
その後も色々調べたものの、結局何も進まず、土曜日終了。
そして、今朝9時前。
サポセン営業開始まで少し時間があったので、「嫁のiPhoneでアップデートしてみたらどうなるんだろ？」と思ってやってみたら、嫁のiPhoneが1分もしないうちに死にました。
バックアップとかそういうことは聞かないでください。
失意の中、9時になったのとほぼ同時に電話。
今日対応してくれた女性も頑張ってくれたものの、解決の糸口はつかめず。
「申し訳ありません、エキスパートに転送しますので、少々お待ちください…」
エスカレきたー。
「エキスパートが担当＝即解決」という図式を頭の中に描いていましたが、ここからが本当の地獄でした。
5時間、エキスパートの女性（以下Aさん）と電話しましたらからね。
もうなんか色々やりすぎたので、ここは省略します。
ただ、ここで感心したのは、Aさんの対応。
今までの担当者が、いきなり解決策を提示してきたのに対して、Aさんはまず、どこに問題があるのかを特定しようとするアプローチでした。
問題の定義→問題の特定→問題の原因の把握→解決策の立案
Aさんはこの問題発見＆解決のセオリーに非常に忠実。
問題解決が日常業務であるサポセンの人たちとって、このセオリーを守ることは何よりの武器となると思うのですが、きちんとできてる人は意外と少ない印象です。
7割ぐらいの人はいきなり打ち手を指示してきます。
こういう人たちは以下の3タイプに分けられると思います。
1. マニュアル実行型
「○○という症状の時は××してみる」というマニュアル通りに指示を出してるタイプ。
「問題の定義」はできてますが、「問題の特定」と「原因の把握」はできてません。
サポセンは一件当たりの対応時間の短さが結構問われるので、こうやってマニュアル化することで時間短縮を図ってるってのもあると思います。
あと、人材の育成が楽でしょうね。
若い人に多く見られるタイプです。
2. 歴戦の猛者型
いきなり打ち手を提示してくるという点では、マニュアル実行型と同じですが、打ち手が出てくるまでのプロセスが大きく異なります。
マニュアル型がいきなり「解決策の立案」にジャンプするのに対して、歴戦の猛者型は自分の中で「問題の定義」から「解決策の立案」を行ったうえで、最後の「解決策の立案」の部分のみ、こちらにアウトプットとして提示してきます。
場数の多さがこれを可能にするので、ベテランに多いです。
3. 天才型
場数の多さではなく、頭の回転の速さで、瞬時に「問題の定義」から「解決策の立案」を行う人たち。
極一部、こういう人たちもいると思います。
まぁ正直どちらのタイプも問題を解決してくれれば、こっちとしてはそれでいいんですが、問題の特定から始めて、現象の因果関係を説明してくれた方が、似たようなトラブルが起きた時にこっちで応用して自分で解決できるから、ありがたいんですよね。
それに、結果的にその方がサポセンにかかる電話も減ると思うんです。
今回はAさんの頑張りも空しく、
「問題特定できないから、とりあえず、カメラのキタムラでアップデートしてきてください…」
という結果になりましたが、問題を解決するうえで忘れてはならないセオリーをAさんに再認識させてもらいました。
Aさん、昼食も摂らずに根気強く対応してくれてありがとうございました！
ちなみに、妻のiPhone5はなぜか新品交換となり、それでなんとか押し切れるかと思いましたが、妻の表情は険しいままでした。
この土日で得たもの
・新品のiPhone6
・問題解決セオリー（再認識）
この土日で失ったもの
・時間
・妻のiPhoneデータ
カメラのキタムラがアップルの修理事業に乗り出してることに関しては、また別の機会に考えてみたいと思います。
