A Quote // 3rd June 2011

コンサルタントの仕事はなかなか奥深い。たとえば企業のトップに対するインパクトでいうと、三つの発展段階があるように思う。第一段階は、論理・分析攻め。正しい(と思われる)解を自分で求めることができ、それをファクトと分析で論理的に説得しようとする段階だ。たとえば、他の投資を全部凍結してでもすぐ中国に進出すべきという提案に、社長が「いやだなぁ」と言ったら、次の日、更に150ページの分析でぐうの音も出ないほど徹底的にたたみかける。更に難色を示されたら、更に分析をする。論理はほぼ完璧になる。社長のタイプにもよるが、この場合八割がた中国へは進出しない。

 次の段階はやや面白い。社長が中国進出に反対と知ると原因を探ろうとする。単に個人的に大陸が嫌いらしい、と知ると、単純に好きになってもらおうとする。一緒に連れて行こうか、など、楽しいことを考え始める。分析もレポート書きも全て放り投げて視察旅行の最高の演出を考えたりするわけだ。成功の確率はぐっとあがる。

 最後はかなりの完成形だ。社長に、「こいつが言うならやってみるか」と思わせるオーラと信頼関係だと思う。コンサルタントが人間力で仕事をする段階だ。

A Quote // 4th May 2011

チャンスが訪れたときに準備ができているという状態は、裏を返せば「チャンスが訪れなければ、無駄なものを抱え込んでいるだけに過ぎない」とも言える。

何が有益になるかは予測できないので、可能な限り「無駄に終わるだろう行動」を増やして機会に備える。むしろ機会が訪れるのか否かすらも忘れて、無駄な行いを積み重ねた方が良い結果に繋がる。

A Quote

本の中には、すでに分かっているようなこととか、おそらく一生関係なさそうなこともあるので、そこは飛ばして、必要なのはこのあたりだな、と思ったらそこを丁寧に読む。ばーっと読んでいて、最近よく目にするワードだな、これが自分が知りたいようなことだな、と思ったら、しっかり読む。そんな風にして本を読んでいくと、難易度のかなり高い本でも読めます。それを全部、最初からちゃんと読もうとするからダメなのですね。

A Quote // 1 note 

2. 自分を低く評価する

例えば奥さんが「ウチのダンナは優しいし、ルックスもいいし、稼ぎもいいし、がんばりや。だけどね……」と続くと、もうこれで終わっちゃうんです。だから「Yes、But」でつながないことです。「Yes、And」でつなぐんです。「ウチのダンナは優しいし、ルックスもいいし、稼ぎもいいし、がんばりや。そして、性格がもっと温かくなればもっといいよね」と、こう言われたら、どうですか?
(中略)
 なぜ直そうという気になるかというと、言われた側がリソースフルな状態になるからです。いい気分になって、いろいろできる状態になる。なので、扱う課題が簡単に見えてくるのです。また、認められた、承認されたという気持ちになるので、「じゃあ、さらに承認されるためにやろう」という気になります。

A Quote // 1 note 

1. 高すぎる目標はやる気をくじく

 高すぎる目標がある場合の対処法は、高すぎる目標から現実を引き算するのではなくて、現実から最悪を引き算することです。仕事がうまく行かない、という状態でも、とてつもなく最悪だったとしたらどうだろう、と考えてください。仕事は1件もこない、受けた仕事のすべてがキャンセル、全部のお客さんからクレームがきて、しかも上司に怒鳴られて、社長に呼ばれてクビになって……と最悪を考えてみてください。そうすると、まあ、先月よりは良かったなとか、これはできたなとか、喜んでいるお客さんもいるじゃないかとか、そう思うことで、高すぎる目標を少し中和することができます。

A Quote

チャンスは、空気のように誰にも均等にある。
したがって、速く走る者ほど時間あたりに多くのチャンスに出会う。
森博嗣

Photo Post // 30th April 2011

れいぞうこ。

れいぞうこ。

たぬぶらー // 29th April 2011

Crazy Panda Commando Roll (by littlefishtravel)

A Quote

受託をしていると、時に途中で時間がなくなって納品が間に合わないことだってある。そんな時決まって言われるのは、「技術力がない」というセリフ。結果、技術力を高めなくては、という反省に行き着くことが多い。でも、実際は営業フェーズ・仕様策定・ハードの調達・プログラミング・というそれぞれの過程において遅延が発生している。例えば、営業が発注書をもらうのに時間がかかったり、仕様が決まらなかったり、後から仕様が二転三転するなど。その結果、当初予定していた1ヶ月のプログラミング期間が半分になったりする。それを「技術力」が足りないの一言で片付けることは、本質と違うし、プラスにならない。そのため、DECOLOGではこのトータルの流れを「開発力」と呼んでいるそう。

全体の技術力をあげるよりも、開発力をあげる方が問題解決に繋がるようなことが多い。具体的には、仕様の策定のバージョン管理ができるようにしたり、営業の書類ツールをドキュメント化するといったような取り組みで、「開発力」アップに取り組んでいます。

Photo Post // 28th April 2011 // 1 note