「成功よりも失敗から多くを学べる」とか「失敗からしか学べない」とよく言われます。
でもそれって本当なんでしょうか？
実は成功からしか学べないこともあるんじゃないかなと最近思っています。

成功からは学ぶことが少ないと言われるのは、どうしても成功してしまうと、その成功体験が邪魔をして見落としてしまうことが多いからのような気がします。

そう考えると成功から学ぶには、まず成功することで見落とされてしまいがちなことを認識しておくことが重要。

さらに、検証をスムーズにすすめるために、どのように検証していけばよいのかをフレームワーク化しておけば効率よく気づきを得られます。

ということで、ここでは成功から何が学べるのか？どのように検証していけばよいのか？について個人的見解をまとめてみる。

プロジェクトが成功すると、成功が原因で見過ごしてしまうことがあると思います。
成功を検証する方法を考える前に、まず成功するとなぜ成功原因を見落としてしまうのか（あるいは勘違いしてしまうのか）について考えてみます。

成功を自分たちの実力やスキルであると思い込み、運や偶然、市場の状況などの外部要因を無視してしまう。

「内部要因 ＋ 外部要因 ＝ 成功」という式が成り立つとすると、実は自分たちの力でどうにかすることができる内部要因よりも、外部要因の影響が大きかったりする。

ちなみにプロジェクトが失敗したときは過度に外部要因のせいにしたがったりしますよね？
「今回は時期が悪かった」とか「いやぁ運がなかったに尽きますね」とか。
人間って不思議な生き物です。
また、長期的なプロジェクトの場合、より運や偶然で成功した可能性が高くなる気が個人的には感じます。
長いスパンのプロジェクトでは、プロジェクトを振り返ってみると、現在の行動や戦略、意思決定が最終的な結果には、ほとんど影響しない気がします。個人的には。

プロジェクトが失敗したとき、そのプロジェクトが重要であればあるほど関係者はひどく落ち込みますし、その原因についても必死に考えます。
特に社運を賭けたプロジェクトや何年も続けてきたプロジェクトであれば尚更。

逆に大きな成功を収めれば当然、関係者はみんなハッピーだし、盛大なお祝いも行われるでしょう。
そしてその成功の余韻に浸り、「失敗していないのになぜ振り返る必要があるのか？」「なぜ見なおさなければならないのか？」という考えが頭によぎり、いつしか成功原因について考えることすら忘れてしまいます。

もしかしたら関係者はみんな、成功の理由を明らかにして、次のプロジェクトをドライヴできるような戦略を見出したほうが良いと、頭の中では思っているかもしれないのに、その場の余韻に流されてしまう。

それでは、成功したときにどうやって振り返ればよいのかについて考えてみます。
おそらく色々とやり方はあるのでしょうが、個人的にはプロジェクトが成功する度にルーチンワークで振り返りを行っていくことを考えると、フレームワーク化しておくことは大事な気がします。
振り返りを行う度に、違う方法で行っていたら、その度に余計なバイアスが入ってしまいますし、何より振り返り自体に時間がかかってしまいそうです。
そこで、成功した時に検証するフレームワークをいくつか考えてみました。

自分たちの力が及ぼすことができる内部要因と、自分たちの力が及ばない外部要因に分けて振り返るようにする。
振り返ってみると、もしかしたら偶然性が非常に強いことがわかるかもしれません。
その場合、今後のプロジェクトでの再現が難しいかもしれない。

でも、それを知ることは大事。
外部要因の中で、多少でも偶然を必然に変えることができることが見つかるかもしれませんし。

逆に内部要因を得たとしても、実はその内部要因は外部要因との相互関係の上で成り立っていたかもしれません。
内部要因と外部要因の相互関係についても意識しておいたほうが良いかもしれません。

何もない中で、さて成功を振り返ろうと関係者が集まったところで、そもそもどうやって振り返れば良いの？と悩んでしまいます。
そんな時は、あらかじめどんなプロジェクトでも活用できる質問を用意しておいて、その質問に沿って振り返っていけば効率的です。

例えば次のような点について議論してみる。

このプロジェクトのそもそもの目的は何だったのか？
実際にプロジェクトが進行する中で何が起きたのか？
なぜそのようなことが起きたのか？
では、次回のプロジェクトではどうするのか？

振り返りを行うときに、時間軸を意識することは大事です。
プロジェクトによって、スパンは数ヶ月から数年と時間軸は大きく異なります。

短いプロジェクトであれば、終了後に振り返れば良いかもしれません。
でも、数年に渡るようなプロジェクトの場合、長いスパンで振り返ると、どうしても外部要因が大きな要因として見えてきてしまいます。
そんなときは、適切な時間軸を意識して適宜振り返ることが重要かもしれません。

少なからず成功には運や偶然性が含まれているもの。
そのため、成功した原因を得たとしても、それを繰り返しても成功するとは限りません。

当然ですが、スポット的に振り返っても意味がありません。
何事も継続性が大事。

以上、個人的にもまだまだできてないことなので、自戒の意味を込めてのエントリでした。
異論はおおいに認めます。

エンジニアだろうが営業だろうがバックオフィスだろうが、そこにビジネスが存在しているのであれば、最終的なゴールは「クライアントを満足させる」ことだと思っています。
（バックオフィスにだって、従業員というクライアントがいますよね）

クライアントを満足させることとは、突き詰めてみると「クライアントをハッピーな気分にし続ける」ことだと思います。

仕事をしていると、「クライアントのビジネスの成功を手伝うこと」だったり、「従業員の業務環境を改善していく」といった、最終的なゴールに目が行きがちです。

当然それは大事なことだと思うのですが、「クライアントをハッピーな気分にし続ける」ことが目的であるという前提で考えてみると、実はもっと大事な戦略があるのではないかと思います。
　
それは「日々の対応の中でクライアントを笑顔にすること」。

個人的にはまだまだ出来ているとは言い難いですが、自戒の意味も込めて普段私が心がけている「クライアントをハッピーな気分にする」8つのことをご紹介します。

笑顔はクライアントを安心させます。大きな課題に直面したときこそ、笑顔で対応しよう。
その笑顔でクライアントは、「この人だったら親身に対応してくれる」と感じるでしょう。

クライアントと電話で話をしている時でも、笑顔を忘れない。
相手が見えていなくても、話すトーンで相手が笑っているのかどうかは分かるもの。
もちろん、メールのやりとりも笑顔を心がけながら文章を書くように意識すると、自然と明るい文章になります。

クライアントとの会話の中に、必ずクライアントの名前を使うようにしよう。
自分の名前を呼ばれることで、クライアントは話に集中し、今まで以上に内容を理解しようと思うし、名前を呼ばれることでクライアントとの人間関係もよくなるはずです。

当たり前のことだけど、当たり前すぎて忘れがち。
クライアントが気を使った行動をしてくれたら「ありがとうございます」、クライアントがお礼を言ってくれたら「どういたしまして」。
そんな些細な行動の積み重ねで、あなたの存在を記憶してくれるはず。

システムを購入したら終わりではなく、永続的なお付き合いを心がけよう。
そのときに、何かを売ろうという考えは捨てて、「あなたの事を常に考えているのです」という気持ちを伝えよう。
クライアントが、「私のことを気にかけてくれている」と感じでもらうことが重要。
そのために、最近の仕事の様子を聞くだけでもよいし、購入してもらったシステムの調子を聞くのも良いかも。

人は自分のことを受け入れられることが好きです。
「あなたは特別なクライアントです」という気持ちを伝えることは、クライアントが喜ぶのはもちろん、良い印象を持ってもらえるはずです。
さらに戦略的に行うには、クライアントに伝えてくれそうな人に、クライアントが素晴らしいということを伝えてみよう。
直接伝えるよりも、人づてで良い評判を聞く方が、人は喜ぶものです。

例えあなたが解決出来ない問題であっても、努力したことや難題を解決しようとしたことはクライアントに見せよう。

クライアントと親密な関係になったら、パーソナルなプレゼントをあげてみよう。
あなたが好きな本とか、クライアントの趣味に関するものとか。

「売上を上げるため」などと、下心丸出しでやるのはナンセンス。
そもそも本来の目的である、「クライアントをハッピーな気分にし続ける」という価値観からも外れる行為です。
あくまでも、クライアントとは「クライアントをハッピーな気分にし続ける」という価値観を大事にしながら付き合っていきたいものです。
　　　
「クライアントを笑顔にすることがビジネスの成功を生み出す」

というビジネスの当然のルールを忘れないようにしないといけないなぁと思います。

私はネットワークエンジニアを生業としてはいるのですが、どちらかというとフロント側のエンジニアなので、機械を相手にするのと同じぐらいクライアントを相手にしています。

当然クライアントに提案して商品やサービスを買ってもらうことがゴール。

理想は、顧客のニーズをすくい上げ、ニーズに合った商品やサービスを提案し、顧客に買ってもらうこと。

でもそれはあくまで理想であって、この仕事を長く続けていると、それをゴールにしてはいけないことに気付かされます。

エンジニアや営業の中には、「顧客のニーズをすくい上げ、ニーズに合った商品やサービスを提案することがビジネスである」という理想論ばかり振りかざす人もいます。

でも、現実のビジネス社会では、売らなちゃいけない商品やサービスがすでに決まっていて、なんとしてもクライアントに買ってもらわないといけないという場合も少なくないんですよね。

さらに泥臭く自分達の提案を正当化する理由を並べ立てることも場合によっては必要だったり。

理想は大事だけど、それだけでは競争社会をサバイブしていけないよねと思う今日この頃です。

最近、ある問題に対して、問題を問題と捉える人もいれば、問題と気付かずに流してしまう人もいて、どうすればどんな人でも一律に問題を問題として捉えることが出来るのだろう？
ということを考えていました。

そもそも問題とは？というところから考えてみると、問題とは「目標やあるべき姿と現状のギャップ」と捉えることが出来そうです。

問題を問題として捉えることが出来ないってのは、「目標やあるべき姿を認識出来て居ない」のか、「目標やあるべき姿が間違っている」のかのどちらか。

では「目標やあるべき姿」を正しく認識するためには？

そこで考えたのが、インプットは必ず、「4W」のフィルターに通すというもの。
具体的には、「誰が(Who)」「いつ(When)」「どこで(Where)」「何を(What)」
の4つ。

• What
  そもそも何のために必要なのか？本来のイシューは何かを捉え直す。
• Who
  誰にとっての問題なのか？立場によって問題は大きく変化する。
• When
  いつの時点の問題なのか？時間軸を明らかにする。
• Where
  どこに問題があるか？今まで見ていた範囲を広げて、大きな範囲で考えてみる。

これらを総合的に判断し、「あるべき姿」を明確に認識する。
その「あるべき姿」と、「現状」を比べてみて、ギャップがあるのなら、それは問題であると認識できる。

ちなみに、WhyとHowを除いたのは、問題と捉えた後に、その問題を解決する時に使うもの（なぜ問題なのか？どのように解決するのか？）であって、問題を捉えるときには必ずしも必要とは言えないんじゃね？って理由で。

まずは個人で実践してみようかなと。

「解決法が見えないんじゃない、問題が見えないんだ」
（Gilbert Chesterton）

「シンプルに説明できないということは、
君がそれを理解していないということだ」
（Albert Einstein）