2009/03/23

Mac vs Windows 美しさを知る?

先日、休日を利用して中原淳一展に行ってきました。

中原氏はイラストレーター、人形作家で、展覧会には人形だけでなく、絵や彼が創刊した雑誌が展示されていました。

その中でグッときた言葉があります。

「美しさに欠けてはならぬものは、清潔です。」

「美しい心の人は、一日では生まれません。」

うーん、考えさせられます。



そして、興味を持ったのが、箒カバー。

掃除道具として、毎日を美しくするためにとても重要な役割を果たしているのに、扱いが余りにも・・・ということで箒カバーを付けたら、箒の扱いももっと良くなるのでは・・・。

ということで、箒カバーが何点か展示されていましたが、年代を見ると、1954年!!

戦後間もない時期に箒カバー。

その感覚にびっくりします。


今の時代感覚なら箒カバーは何となくわかります。

例えばパンのトースター。

朝食の時に数分だけ、トースターとして機能します。

それ以外の23時間50数分は、トースターとして機能しません。
むしろ部屋を彩るインテリアの一つです。

このように考えると、トースターとしてよりもインテリアとして機能している時間の方が長い。

だったらインテリアとして素敵なデザインのものを・・・。

と考えて、自分はトースターを選んだりするのですが、この感覚が商品に反映されているか否かは結構重要かもしれません。

例えばノートパソコン。

インテリアとして置いておくなら、圧倒的にMacですよね。

でも入力キーボードの良さは、ThinkPad Xシリーズに勝つものはありません。

インテリアとしてノートパソコンのハードを見てみると、とても面白いです。
Windowsのノートパソコンでもインテリアにマッチするようなものが、いろいろなメーカーから出ています。

ハードウェアは使わない時も意識したデザインで、ソフトウェアは機能の最大化を目指す。
(もちろんハードウェアの制約でソフトウェアがおろそかにならないように・・・。)

こんな視点でモノ作りをするといいのかなぁと、箒カバーを見ながら考えちゃいました。

展覧会の期間はとても短いのですが、時間があったら行ってみるといいと思います。
オススメですよ。

2009/03/16

東京マラソン 2009

昨日、凄いことが起こりました!!

それは自宅-オフィス間を自転車で移動中、信号に1回しか停まらなかったことです。
(どこからどこまでかは、この後の文章の中でお察しいただければ。)

日曜日は人と車が少ないうえ、路上駐車をしている車がほとんどないため、快適に走ることができます。

結果として、いつもよりスピードが出せることになり、信号の流れが良くなったのかなと思います。

都内を自転車で走っていると、時速20kmを継続して出すのはなかなか難しいのですが、マラソンで2時間ちょっとで走ろうとすると、時速20kmぐらいなんですよね。

自転車で20kmを出している時の体感は・・・

このスピードで2時間ちょっと走り続けるなんてありえない!

それぐらい速いペースです。

実際にマラソンを自分の目で観たことはないのですが、物凄く速いんじゃないのかなと思います。

来週東京マラソンが開催されますが、スタート地点が自宅近くなので、そのスピードを観てみようかなと思ったり思わなかったり。

(実際は交通規制をされてしまい、当日は自転車で出かけにくいんですよね。仮設トイレが至る所に設置されて、溢れんばかりの人、ひと、ヒト・・・。

午前中はおとなしく家にいる方が正解なのですが・・・。)

2009/03/14

衝撃の姿

先日、自転車で帰宅途中に衝撃の映像を目にしました。

それは・・・

防毒マスクにメガネをかけ、ヘルメットをかぶって自転車に乗っている人!!

テロ攻撃にでもあったのかと・・・。
花粉症って、それぐらい強烈なのかもしれませんね。

2009/03/13

ABeam Consultingは変わった!?

当ブログですが、「アビーム」というキーワード検索でやってくる方が結構います。

就職活動を行っている学生さんかなぁということで、以前ABeam Consulting応援企画のエントリを書きました。

自分が就職活動を行っている時と比較すると、今は随分変わったと思います。
インターネットを活用すれば情報はすぐ手に入ります。

とはいえ、ちょっとだけ注意点というか、気を付けた方が良さそうなことを書いておきます。

個人的には、ABeam Consultingにはとてもお世話になりました。
自分にとって最高の会社だったし、尊敬できる方達が今でも活躍しています。

ホント、良い会社で就職先として真っ先にオススメできる会社です。

が、私自身、そのアビームを辞めて随分と経ちます。

ここ何年か振り返ると、自分自身が大きく変わったことに気付きます。

となると、当然アビームも私がいた時とは大きく変わっているに違いありません。
(自分が在籍した4年半で社名が2回?、3回?変わっちゃうような会社ですから・・・。)

ですからABeam Consulting応援企画で書いた内容も遠い過去の思い出であって、今とは違うことはたくさんあるはずです。

従って、そのような情報だけで、何かの判断をするのは非常に危険だと考えています。

自分で書いておきながら、こんなことを言っちゃうのもどうかと思うのですが、私のエントリは過去に在籍した社員の思い出話です。

今、まさに現場で活躍している方とはリアリティが違います。

そのあたりを踏まえながら、参考にしていただければ嬉しいです。
(久しぶりに会っても相変わらず・・・な人達ばかりなので、良い会社には違いないと思いますが・・・。)

2009/03/12

【番外編】Mac vs Windows ToDo管理

Mac vs Windowsシリーズ。

今日は番外編です。
というか、独り言です。

全く持って意味がないのでスルーをお願いします。(笑)

最近、仕事でもMacとWindowsを両用しているのですが、ひとつ困っていることがあります。

それがタイトルにある「ToDo管理」。

Web上でやればいいじゃん・・・というのが答えなのかもしれませんが、Mac、WindowsとiPod Touch、この3つをうまく同期させることができないだろうか・・・。

カレンダーは完璧に運用ができているので、ToDoも同じようにやりたいのですが、これだ!!という方法が見つかっていません。
(方法がないわけではないのですが、どうもシンプルでないのが・・・。)

とりあえずブログに書いておけば、それを読んだ方が私に会った時に情報をくれたりすることがあるので、今回も書いておきます。

探すよりアプリを作った方が早いのかもしれませんが・・・。

2009/03/11

Mac vs Windows 前進するエネルギー

前回のエントリに対してフィードバックを頂きました。

ありがとうございます!!
自分も書きながら頭の整理ができるので、とても嬉しいです。

さて、そのフィードバックの中で、あることが書かれていました。

-------ざっくり抜粋-----------
Macとして動くには、前進するエネルギーが必要。
でも、Windowsとのスピード感や考え方の違いが大きいと、徐々にその差に対するストレスが溜まる・・・。
そういう時は、どういう風に考えて対処すればいいのか?
--------ここまで-------------

ということで、今回はこの辺を考えてみたいと思います。
前回と同様ですが、前2回のエントリを読んでいない方は、何のこっちゃ全くわからない話が続きますので、前2回のエントリを読んでから、この続きをお読みいただければと思います。

早速ですが、Windowsとのスピード感や考え方の違いが大きいと、徐々にその差に対してストレスが溜まりますよね。
その気持ちわかります。

そこでの対処法として忍耐強くなるというのがあります。
でも私は正直、そこまで忍耐強くありません。

我慢できないなら、その差を埋めるしかない!
では、どのようにしているのか?

それぞれの立場で考えてみます。

まずは、「Windowsな上司」と「macな部下」の場合です。

前回のエントリで「裏でMacな動きをする」と書きましたが、もう少し詳細を書くとわかりやすいかもしれないと思ったので、その辺を書いてみます。

前回のエントリで書きましたが、さっさとWindowsな仕事を終わらせて、Macな世界に引き込むのが一番ですが、そうもいかないことが多いですよね。

なかなか結果が見えなかったりすると、Macな動きをするのも大変で、働きかけに対するモチベーションの維持は難しくなってきます。

そのような時にどうするか?
先にざっくり結論を言ってしまうと、「ゴールの違いは許さないが、そこに至るまでのプロセスの違いは全然OK」。

なんのこっちゃ、さっぱりわからないと思いますので説明していきます。

私はWindowsな上司(私の場合はお客様ですが・・・)とスピード感や考え方の違いが大きいと感じた場合、下記3ステップを行っています。

1、前のステップに戻る
2、掘り下げて違いを見つける
3、違いに対応する

スピード感や考え方の違いが顕著に出るのは、スケジュールや段取りなどです。
そこで前のステップに戻ります。

ここでは「ゴールを明確にする」ですね。(第1ステップ)

次に2ステップ目の「掘り下げて違いを見つける」ですが、ゴールを大きく2つに分けます。
「目的」と「目標」です。

「このスケジュールと段取りで、一体何を実現しようとしているのか?」、目的を確認します。
確認する際にどこまで確認するかという基準ですが、私はここまでやっています。

「目的を達成すると何がどう変わるか具体的なイメージが共有できるまで」

つまり、誰々さんが、この時に、こんなことをして、こんな結果が出る・・・と普段の動きがイメージでき、かつ結果がどうなるかわかるぐらいまで落とし込みます。

そこまでイメージして相手にぶつけると、大体違いが出てきます。

Windowsな人は書かれたことしか実行できません。
従って、過去の経験を持ち出してイメージしているのですが、これからやろうとしていることは過去と全く同じではありません。

従って、どこか曖昧だったり、全く異なる状況が出てくるはずです。
(業界が同じでも、会社が違えば社風や仕事の進め方、考え方が違うのは当然ですよね。
それを前回と同じやり方で進めようとするとコンサルは失敗します。)

ちなみに確認する際の注意点ですが、間違っても「目的は何ですか?」とそのまま聞いてはいけません。

先ほども書きましたが、Windowsな人は書かれたことしか実行できません。

個別具体的なことしか書かれていませんので、このような抽象的な質問には、まず間違いなくフリーズします。
(もしかすると上司としての威厳を保つために、適当なことを言うかもしれません。
質問に回答できないのは、自分の愚かさを証明することになる・・・という恐れは誰しも持っていますので。)

従って、相手の得意な個別具体的な内容で確認します。
ちなみに私は、下記2つのやり方で違いを確認します。

・具体例を提示して合っているか間違っているか確認する。(Yes or No形式ですね。)
・上司が前提としている経験の詳細(主にその経験が持っている背景や制約条件、前提条件など)を確認する。

よりプログラム的に言うと、

・Windowsは親クラス(目的)を持っていない。
・従って、こちらが仮定した親クラスに基づいて、子クラス(状況/場面)を何個か実行してみる。
(実際に実行するのではなく仮に実行したら・・・という仮定の話です。)
・実行した結果を例に、合っているか間違っているか確認しながら、親クラス(目的)を明確にしていく。

親クラスを持っていない、Windowsでは「手段の目的化」が多いです。

手段が目的になっていますので「そもそもこれって何がしたいの?」と、自分自身に問いかけてみます。
その問いかけに対して自分なりに答えを出します。

次にその答えに対して、具体的な状況/場面を当てはめていきます。

最後に相手にその状況/場面を説明しながら「これって実現したらハッピー?」、「実現したいの?したくないの?」と確認していきます。

この作業を繰り返しながら目的を明確にしていきます。

ちなみに、このプロセスを行うと嬉しい事が2つあります。

1、影響範囲がわかる。(事前に対応しておいた方が良さそうな所などがわかります。)
2、対応策や目標、実行計画などを立案する際の判断基準、判断材料になる。

そして、ステップ3の「違いに対応」します。

先ほどのプログラム的に言えば、

・親クラスに基づいて、Windowsが想定していなかった子クラス(状況/場面)をどうするか一緒に考える。

目的が明確になれば、その対応は出しやすくなります。
対応が決まれば、目標設定も出来ますよね。
(目的に沿った目標から対応策を出すアプローチももちろんアリです。)

このステップも先ほどと同じように、個別具体的な内容で対応策と目標を提示しながら相手と詰めていきます。

ここで仮に自分が一番だと考えている対応策と目標があったとします。
しかし相手はそれが一番だと思っていないというギャップがあったとします。

このような場合、目的が明確になって共有されているのであれば、そのまま相手が一番だと思うものに任せるようにしています。

これが先ほどの「ゴールの違いは許さないが、そこに至るまでのプロセスの違いは全然OK」という意味です。

やり方は人それぞれ得手不得手がありますので、押し付けるのは良くないです。
具体的な内容を押し付ける・・・まさにWindows的(笑)。

自分達がコミットしていることを行った方が結果も得られやすいような気がします。

なので、実行は任せつつ(自分がやることもありますよね!)、もしうまく行かなかった場合を想定して準備をしておく・・・これが前回のエントリで書いた「裏でMacな動きをする」ということになります。

第三者的な立場で見ると、依然としてWindowsとスピード感や考え方の違いがあるのは確かですが、違いはプロセスのみ。
達成することは必ず共有する・・・ということになります。


では、次に行ってみましょう。
「Macな上司」と、「Windowsな部下」です。

ここまで随分と書いてきたので、読むのが大変ですが、もう少しお付き合いください。(笑)

Windowsな部下に対するポイントはたったひとつ。

「大いに期待するが、その実現時期は期待しない。」

取り組んでいる仕事に対するスピード感や考え方の違いが大きいのであれば、先ほどと同じように目的を明確にして共有します。
そして前回のエントリで書いたアプローチを取ります。

しかしWindowsな考えをMacになってもらうことを期待するのは、前回も書きましたが、5、10年スパンで考えないと難しそうです。
従って、すぐに実現できる・・・という期待は持たないのがポイントかなと思います。

なぜ上記のように考えているのか、私自身、苦い経験がありますので、そちらを披露しながら進めていきたいと思います。

個人的にMacな考えで仕事を進めていると、相手にも同じような考え方で仕事をすることを期待してしまいます。
そこで、Macな考えを披露したり、その身に付け方を教えてあげたり・・・相手を思っていろいろと尽力してしまいます。

しかし、一歩下がって相手の立場で考えてみると・・・

・Macな考えを押し付けることが、Windows的な指示と同じ。

つまり自分の成功体験を押し付けていると、相手はWindows的な指示と同じと捉えるわけです。
(そりゃそうですよね。自分は今までWindows的なやり方できたのですから。)

しかしMacな考えは抽象化されている。

従って、教わったことなのに実行できない・・・ということになってしまいます。

そして下記、負のループができます。

1、身に付け方も含め、やり方を教える。
2、本人はわかったと理解している。
3、でも実際の現場で活用できない。
4、なぜできないのか・・・こちらのストレスがたまる。
5、相手も自信をなくす。
6、同じような状況が訪れる度に失敗して、さらに自信をなくす。

ちなみに私は前職を辞めて起業する際の引き継ぎで失敗しています。

限られた時間の中で、後任の方には私と同じかそれ以上に活躍してもらわないといけません。
従って、自分が持っているもの、あらゆるものを伝えました。

つまり後任として大いに期待していたわけです。

期待していた・・・と書けば聞こえはいいですが、相手の立場に立つと、
「期待=プレッシャー」でしかありません。

結果として、日に日にプレッシャーが厳しくなっていきます。
結果として、その方は体調を崩され倒れてしまいました。

「何かわからないことがあったら何でも聞いてください。」
「出来ない事があったら教えてください。一緒にどうすればいいか考えましょう。」

一見、相手を助ける言葉もプレッシャーになってしまうのです。

ということで、時間的制約があるとうまくいかないです。

従って長い目で見てあげなきゃ・・・と思うのですが、その際に気を付けていることがあります。

それは「自分や他人と比較しない」ということです。

Macな人になってもらうための具体的なアプローチは前回のエントリで書きましたが、その進捗具合を過去の自分や他人と比較しないということです。

比較をするのは、その人の「過去」と「現在」です。

過去のあなたと比較すると、現在は随分Macな考えになったよね!

と伝える様にします。

ちなみに私は、相手がMacになっていく様を確認しながら都度褒めています。
が、私の場合、褒めるポイントを探っていくうちに、過去の自分と比較して、「もっと早くできないもんかな?」なんて傲慢な考えが出てきてしまうので、相手に質問することにしています。

「過去の自分と変わった所ってどこ?」と相手に質問することで、自分がMacな考えになっていったポイントを挙げてもらいます。
そのポイントを褒めることで、過去の自分と比較しないよう心がけています。

正直、この辺は忍耐・・・という言葉が合うかもしれません。

ただ考え方として「その人の成長に貢献できる環境を用意することが出来て良かった」と捉えるようにしています。

カメさんなのか、うさぎさんなのかは人それぞれですが、一歩でも前進しているのは素晴らしいことだし、それを褒める文化や認める社風を大切にしていきたいと考えています。

この辺りは起業して、自分自身が変わった所ですね。

部下だろうが、お客様だろうが、そういったことは関係なく、その方の人生を豊かにするために、自分がちょっとでも関わったり貢献できたりできるのは、とても嬉しいことです。

もっともっと多くの方に貢献できるように日々こつこつと頑張っていきたいですね。

ということで、放談は以上です。


追伸)
とても長い文章をお読みいただき、誠にありがとうございました。
Mac vs Windows なかなか面白いテーマですね。

タイトルでvsと書いていますが、個人的には決して対立しているわけではないと思います。

「お互いの違いを認めて、得意な所を相互に活かせるようにするためにはどうしたらいいか?」を意識するようにしています。

組織で仕事をしていると、なかなか違いって認めにくいんですよね。
違いを認めた瞬間に、優劣、善悪の話になってしまいますので・・・。
(ここまでのエントリを読んでいただけるとわかると思いますが、自分がMacな動きをしているだけに、Macの方がWindowsより良さそうに見えますよね(笑))

先人達の言葉や知恵を借りるとすると「思いやり」、「許す」、「忘れる」と言った言葉が大切になってくるような気がしています。

個人に落とし込むと「余裕を持つ」、「相手を受け入れる器を持つ」こういった人間になれば、先ほどの言葉を大切にできるような・・・。

資本主義社会の中で、数字や結果に追われている中で、どう実現していくのか、なかなかチャレンジングですが、そこが仕事の醍醐味かもしれませんね。

2009/03/10

Mac vs Windows 仕事の任せ方

前回のエントリに対して、早速コメントをいただきました。

ありがとうございます!!

素早いフィードバックには、こちらもテンポよく応えていきたいです。
ということで、どんどん行っちゃいましょう。

今回のテーマは「仕事の任せ方」です。

上司と部下の関係でMacとWindowsで、どう変わるのか、私の経験を踏まえつつ考えてみたいと思います。

ちなみに「Windowsな上司と、Windowsな部下」、「Macな上司と、Macな部下」。
この組み合わせは相性がいいので、割愛しますね。

難しいのはこの2つ。
「Windowsな上司と、Macな部下」、「Macな上司と、Windowsな部下」。

このような組み合わせの時に、どうやって仕事を任せていけばいいのか考えていきます。

前回のエントリを読んでいない方は、何のこっちゃ全くわからない話が続きますので、前回のエントリを読んでから、この続きをお読みいただければと思います。

では、まずは「Windowsな上司と、Macな部下」です。

ちなみに私個人の経験としては、Windowsな上司と仕事をしたことがありません。

そりゃそうですよね。
コンサルティング会社でWindowsな動きをしていたら大変なことになってしまいます。

ということで、ここでの話は、「Windowsな上司」を「Windowsなお客様」に見立てて、そこから得た経験を基に話をしてみたいと思います。

いきなりですが、「Windowsな上司」に仕事を任せられた「Macな部下」が取るべき行動は「任された仕事をとにかく早く終わらせる」こと。

スピード命。
小さな成功や成果をとにかく早く実現することです。

Macな視点で全体像を見ると、Windowsな指示は的外れであったり、やったことはないけどもっといいやり方を思いついたりします。

しかしWindowsな上司は、自分に経験のないことはできない。
ソースコードに書かれてあることしか実行できません。

そこで、Macな視点が正しいと正論をぶつけても、経験がないことは実行できない。

時間ばかりが過ぎて何も変わりません。

ですから、遠回りだと感じてしまうかもしれませんが、まずはWindowsな指示を実行する。

そこで結果を出して初めてこちらの意見に耳を傾けてもらう環境ができます。

例えば、結果が良ければ、「こんなやり方もありますよ。」、「こんなことをしてみたいのですが・・・。」と新たな提案ができます。

この時に予定より早く仕事を終わらせておけば、上司は部下を遊ばせておくことはできませんので、自分の提案が通りやすくなります。

一方、結果が悪ければ「大丈夫です。対応策としてこんなやり方があります。」と提案ができます。

意地悪な言い方になってしまうので書きたくないのですが、コンサルティングの現場でお客様がWindowsな視点でいる時に、それを実行しつつ、裏でMacな動きをするための準備をしていることがあります。

Windowsに合わせているように見せて、裏でMacな動きをする。

最初に承認を得て実行するのではなく、裏で実行して後で許しを得る感じでしょうか・・・。
(実際は許しを得る・・・というよりも事前に対応してもらっていた・・・ということで喜んでいただけるケースの方が圧倒的に多いですが。)

Windowsな仕事は、ただでさえ忙しい中にさらに仕事が増えるし、かつそのやっている意味もイマイチ・・・と感じてしまうので、やる気の維持がポイントになるかもしれません。

しかし個人的には次のステップやステージに行くための大切な準備だと思っています。
「失敗は成功の母」、「急がば回れ」ではないですが、組織が一体感を持って進めていくには必要なステップだと思います。

全くの蛇足ですが、大きな会社はこのステップを必ず踏みます。
それだけ遠回りする余裕があります。

一方、小さな会社は余裕がありませんので、このステップを外さなければいけない時があります。

で、本題に戻ると、エリヤフ・ゴールドラット氏が「ザ・ゴール」という本で書かれていましたが、スループット(成果物などのアウトプット)を最大・最適化するためには、ボトルネックを見つけて、他の全てをボトルネックに従属させる、そしてボトルネックを徹底活用する。

徹底活用したら、ボトルネックの能力を少しずつ高めていく・・・と言っています。
(随分端折ったので詳細は本を読んでいただければ。)

今回の話で言えばボトルネックはWindowsな上司です。

ですから、まずはWindowsな上司に合わせる。

そして結果を出す。

結果を出した後に、新しい提案をすることでWindowsな上司の能力を高めていく・・・というアプローチです。

とにかく小さな成功でも構いませんので、できるだけ早く成果を出すことがポイントになってきます。

ここでひとつ注意点です。
今まで書いてきたアプローチは主にホワイトカラーの方達におススメのアプローチです。

製造業などモノ作りの現場、生産現場では、なかなか裏でMacな動きをするのは予算などいろいろと制約がありそうですよね。

制約のある所でも上記アプローチが全く不可能だとは思いませんが、ホワイトカラーの方達には特にやりやすいアプローチであることは確かです。

では、次にWindowsな上司の立場を考えてみましょう。

とにかく自分がボトルネックなわけですから、細かい指示はしないで、部下に任せる器の大きさを見せてください!

と無責任な発言をしちゃってもいいかもしれないですね。(笑)

というのは冗談で、Windowsな上司が心がけるのは、これもMacな部下と同じですが、「スピード命」です。

Windowsな上司ですから、おそらく事細かにプロセスまで指示をしちゃうはずです。

Macな部下にしてみれば、面白くありません。

親クラスがはっきりしないくせに、プロセスなど内容はやたら細かい。

そんな仕事の任せ方をしちゃうはずです。

王道としてMacな指示の仕方を身に付けてほしい所ですが、世の中はそこまで悠長に待っていられません。

ですから、Windowsな上司としては、「まずはやってみてほしいんだ。その後にもっと良いやり方がないか考えてみよう」といったスタンスで、とにかく自分が考えていることを、さっさと実行させてしまうのがいいのかなと考えています。

つまり自分が指示している内容はあくまでテストで、実行して結果を見ていく中で、もっと良いやり方があったら提案してくれよ・・・みたいな雰囲気を作るといいかもしれません。

ただ注意点としては、このやり方を実行すると、必然的に仕事の納期が厳しくなります。(Macなやり方を実行する時間的余裕を作らないといけないですから・・・。)

すると納期が厳しいWindowsな指示より、こっちの方が効率が良くないですか・・・というMacな提案を受ける可能性があります。

でも本人はWindowsな動きを一回しないと納得しないですよね?
ですから、納期の設定はちょっとしたさじ加減が必要になります。


それでは2つ目の「Macな上司と、Windowsな部下」に行きたいと思います。

結論から言うと、Windowsな部下にはMacになってもらいましょう!!

と言いたい所です。

が、これがなかなか難しい。
私もチャレンジしていますが、5、10年スパンで考えないと難しそうです。

例えば、前回のエントリで書いた「約束を守る」

これ難しいことは何も言っていないですよね?

誰でも理解できます。

でもちゃんとできない。

こんなケースが頻発します。

そこで本人に聞いてみたのですが、この親クラスに至るためには、1ステップ、2ステップ階段を昇らないとダメみたいです。

その階段が個人によって異なるので、話が余計難しくなってしまいます。

ということで、Macな上司はどうやってWindowsな部下に仕事を任せるか?

私がよくやるステップは下記の通りです。


1、Macな指示をして、どのように進めていくかやり方を聞く。

これはどういうことかと言うと、今回の目的、目標や背景などを説明して、どうすればいいか考えてとお願いします。


2、具体的な進め方の例を提示する。

上記1の指示をすると、Windowsな部下は何をすればよいのか全くわからないためフリーズします。

何をどう考えればいいのか全くわからない状態になりますので、ある程度フリーズしたのを見計らって、こちらが具体的な進め方の例を提示します。

(自分が指示した内容に対して期待するアウトプットは何だったのかを示す。
つまり、お願いした仕事の成果をはかる基準を具体例で示す。

注意点は基準を示しても、具体例がないとWindowsな人は理解できないです。)


3、こちらが提示した具体的な進め方に味付けをしてもらう。

上記2の具体的な進め方を聞くと、Windowsな部下はそれを実行すればいいんだ・・・とソースコードに書いちゃいますので、すぐにそれをやりたがります。

そこでやらせてしまっても構わないのですが、Macな考え方を持ってもらうために、提示した具体的な進め方を参考に自分なりのアレンジをしてもらいます。

ちょっとできるようになってくればアレンジではなく、もう一つの進め方案を出してもらいます。

この時「オレは5つの進め方を思いついたから、頑張って1つぐらいは考えてみようよ。」と言って励ます・・・など、しょーもないテクニックがあったりします。(笑)

さらにしょーもないことを書くと、自分でアレンジをしてもらうことで、その仕事に対する責任を持ってもらう効果も狙っていたりします。(笑)


4、アレンジした進め方を実行する。

5、フィードバックを行う。
Windowsな部下には、実行した行動が事細かに記述されています。

そこで、自分の仕事の「再現性」を実現するために何が必要なのか、一緒に考えていきます。

その際に、他の業界だったら、他の会社だったら・・・など、できるだけ今回経験したこととは、事象が異なるものを例にしながら、「再現性」を担保するために必要な要素を抽出していきます。

Macな人には簡単かと思いますが、このような作業を行っていくと「目的が大事だよねー。」とか「背景は確認しないとねー。」など、どんどん抽象化されていきますよね。

その作業を何度か積み重ねて、Windowsな部下のソースコードをきれいにしてあげます。


6、きれいなソースコードを実行する。

もちろんきれいにしてあげた後には、実行させないと、またWindowsな動きに戻ってしまいますので、何度も抽象化の作業をしてあげないといけないです。
(これが前述の時間がかかりそう・・・と書いた所です。)


こんな感じでしょうか?

個人的には、新入社員の時に先輩同士の「Mac」と「Mac」のやりとりが忘れられません。

最短、最速で本質を突いた議論をしているのは、今思えば芸術です。
(日本語だけでなく、英語バージョンもあったりします。
もっと凄いのは英語がしゃべれない、全く理解できない人が、英語しか話せない人とやりとりしている多言語バージョンもあります。(笑))

そのような環境で仕事ができれば楽だし、楽しいのは間違いないのですが、それでも結果はまた違った所にあるのがビジネスの面白い所ですね。
(Macだからと言って、必ずしも毎回うまくいくわけではないですよね。)

2009/03/09

オブジェクト指向とマネジメント

えーっと、前回のエントリで書いた「仕事の経験や実績を重視する人が陥る罠」の説明ですが・・・「楽しみに待っています」というコメントを頂いたので、早速ですが、書いてみます。(笑)

エントリをしてスグにコメントをもらっちゃうと、ついつい頑張っちゃいますね。

では、早速書いていきますが、ひとつ注意点を。

これからオブジェクト指向など専門的なものが出てきますが、都合のよい解釈、定義で書いていきます。
理由はアカデミックな厳密さよりも、普段の仕事に活かせることに重きを置いているからです。

つまり、それによって普段の仕事が今よりもちょっとでも良くなるならば、適当な理解でもOKというスタンスで行きます。

従って、これって厳密に言えばオブジェクト指向じゃない・・・と思われる方は、スルーした方がいいと思います。

では行きまーす。

前回のエントリでも書きましたが、MacとWindows、両方を使っていく中でソースコードがどういう思想で書かれているのかわかるような気がしています。

簡単にいえばMacはオブジェクト指向。従って、何か処理をする時に都度インスタンス化して対応します。

一方、Windowsはあらゆる状況をすべてソースコードに書いているような気がします。

従って、Windowsはソースコードが長いので、処理が遅い。

何か修正があると、修正箇所が多かったり、影響範囲がわかりにくい、スパゲッティソースになりやすいなどなどいろいろと問題がありそうです。

一方、Macはシンプルにクラス化されていそうです。
ですから修正などの変化も強そうです。

(プログラムの経験がない方へ、ごめんなさい。かなり端折って書いています。ここまで書いてきて理解できないのはわかっていますが、オブジェクト指向の説明はあまりにも長くなってしまいますので・・・。)

では、これを一般的なビジネスパーソンに例えて話をしてみます。

例えばMacなビジネスパーソンは親クラスに「約束を守る」というソースコードが書かれています。
そして子クラスに「アポイントの場面」や「成果物の提出」などのビジネスシーンが書かれています。

従って、Aさんと仕事をする時には、アポイントの場面ではインスタンス化して「約束の時間の10分前に到着する」という処理を行います。

また成果物の提出では、「納品前に1回上司にレビューを受ける」など都度インスタンス化して対応します。

一方、Windowsなビジネスパーソンは、あらゆる状況がソースコードに書かれています。
今回の場合ですと、「Aさんと会う時には約束の時間の10分前に到着する」、「Aさんと仕事をする時には納品前に1回上司にレビューを受ける」と書かれています。

一見、同じに見えるのですが、両者には違いがあります。

例えば、Bさんと仕事をする場合、Windowsは「Bさんと会う時には約束の時間の10分前に到着する」と同じ内容を記述しないと動きません。

一方、Macはインスタンス化すればいいので、ソースコードの変更はいりません。

ここがMacなビジネスパーソンとWindowsなビジネスパーソンの分かれ目です。

Windowsなビジネスパーソンはソースコードに書かれていなければ処理ができません。
従って、ソースコードに書くのですが、成果物の提出では、重要度と緊急度を判断してそれぞれに違った処理を施していたりします。

相手の立場にたった重要度と緊急度ならば大きな問題にならないですが、自分が抱えている仕事の中で、重要度と緊急度を判断したりします。

そうすると、相手にとって重要かつ緊急なのに、自分が重要ではなく緊急ではないと判断して納品が遅れた処理を行ったりします。

Macなビジネスパーソンにすれば親クラスに「約束を守る」というソースコードが書かれています。
従って、重要度と緊急度がどうであろうと「約束を守ろう」とします。

この差が処理結果に響いてきます。

このように考えると面白いことが出てきます。

例えば業界経験や実績。

Macなビジネスパーソンは親クラスに仕事で成果を出すための原理原則が書かれてあるので、他の業界でも応用ができます。

一方、Windowsなビジネスパーソンは、その業界に対する経験が書かれていないと、全く実行ができません。

「愚者は経験に学び、賢者は歴史に学ぶ」という言葉がありますが、まさにMacなビジネスパーソンは自分の経験や他者の知恵から、自分なりに親クラスを作っていきます。
(この親クラスを作るのが大変ですね。抽象化をしないといけませんので。個人的には仮説として親クラスを作って検証しています。)

一方、Windowsなビジネスパーソンはどんどん経験を積むしかありません。
経験を積むということは、それだけソースコードを書くことになるのですが、書けば書くほど処理は遅くなるし、ソースコードの内容もどんどん細かくなっていきますよね。

突然ですが、私はMacな動きをしています。

それはなぜか?

コンサルティングという仕事をする時に経験で勝負をしたらお客様に勝てないからです。
当然ですが私が社会人になる前から現場の最前線でバリバリやってきた方に、経験で勝とうなんておこがましいです。

では、そのような中でどうやったら結果を出すことができるのか?

そう考えると必然的にMacな動きをせざるをえません。

幸か不幸か私は結果論としてMacな動きをしています。
(はじめから狙って行っていたわけではないので、凄いだろという自慢をするつもりはないです。)

それでは本題に戻ります。
上記2つの違いがある中で「仕事の経験や実績を重視する人が陥る罠」を考えてみましょう。

仕事の経験や実績を重視する人は、ほぼ間違いなくWindowsなビジネスパーソンです。

このような方は「ソースコードにどれだけ詳しく書かれてあるか」、「同じようなソースコードがどれだけたくさんあるか」が大事です。(量と細かさですね。)

従って、マネジメントの立場でWindowsな部下に仕事を任せるならば、できるだけ似たような経験を流用して書き加えるような流れを作ります。

ただその仕事で得たことを抽象化して他に応用することは本人は苦手だと思いますので、そのようなことを期待して任せるのは避けた方が良さそうです。

また、新しい取引先を増やそうという時には、Windowsな方は業界や実績を重視します。
が、同じ業界でも会社が変われば、状況は大きく違います。

従って、業界経験や実績が多いから・・・とお願いすると、100%失敗します。
それを防ぐためにも、「例えば、このような場合で自社はどうなるか?」という質問を繰り返しながら、自分達に当てはめて考えることをおススメします。

一方、Macなビジネスパーソンですが、注意しないといけないことがあります。

それは「Macな動きをする方は少ない」ということを認識することです。
これはどういうことかというと、私の経験を紹介して説明します。

私は今までお付き合いする会社を見極める時にMacな考えを使っていました。

例えば親クラスに「約束を守る」というのが書いてあります。

そうすると提案時における打ち合わせで5分遅れた時にこう考えていました。

「一事が万事。打ち合わせに遅れた・・・ということは、仕事の納期もいい加減かもしれない。」と注意していました。

しかし・・・。

Windowsなビジネスパーソンだと「打ち合わせの時間を守ること」と「納期を守ること」は別物です。
打ち合わせの時間はいい加減なのに、仕事としてお金を払うとしっかりと納期を守っていたりします。

とにかく別物です。

自分の親クラスでもってあらゆる状況をみると、都度処理結果が異なって混乱します。

ですから、非常に面倒だと考えてしまいがちですが、あらゆる場面で都度見極める目が必要になります。


と、長々と書いてきましたが、最後にひとつ。

MacなビジネスパーソンとWindowsなビジネスパーソンをどのように見極めるか?

正直、ここはチェックリストか○×で判定できればいいのですが、この分け方自体、最近考えたことでまだこれといった見極め方法はありません。

そのような中で個人的な経験を踏まえると、Macなビジネスパーソンの親クラスには、基本的なことが書かれています。
「約束を守る」、「挨拶をする」、「相手の立場に立つ」など、躾と言われるレベルぐらい単純かつわかりやすいことが書かれています。

そのような単純なことを、複雑な仕事の中で一貫して徹底できている方はMacな感じがします。

また、何かを行おうという時に・・・

Macなビジネスパーソン・・・抽象化しようとする、本質を見極めようとする。
Windowsなビジネスパーソン・・・具体例、詳細例を確認する。

といった傾向があるかもしれません。(あくまでも印象論ですが・・・。)


ちょっとダラダラ長々と書いてしまいましたが、お話はここまでです。

どこまで伝わったでしょうか?

もう少し時間が経って整理ができてくると、もっとわかりやすく書けるかもしれませんね。

と言って、駄文に対する言い訳をしました。
自分の頭が整理されていないことをこういった言い訳でごまかそうとするのは良くないですね。

私自身、まだまだ精神的に甘い所があります。

反省しています。

ということで、異論、反論、大歓迎です!
そういった意見を頂いたりする中で、自分の頭が整理されてきますので、フィードバックがあると嬉しいです。

よろしくお願いします。


<独り言>
Windowsを貶めているような印象を受けられる方がいらっしゃるかもしれませんが、そのようなつもりは全くありません。

両者の対比を鮮明にするためにちょっと強調して書いてある所があります。
(実際Windowsのソースコードがどう書かれているか知りませんし・・・。)

従ってMacな動きをした方がいいよ、Windowsな動きをした方がいいよ・・・というつもりもありません。

自分の得意な型を徹底的に磨いていくのがいいのかなーと考えています。

2009/03/08

変化を促すもの

3月は多くの会社が年度末となります。

ということで、新しい年度に向けて、さまざまな移り変わりがあります。

その中で私個人も大きな変化がありました。

それは・・・。

Mac最高!!(笑)

昨年末にMacbookを購入して、いろいろいじっているのですが、これ最高ですね。

今までテキストベースの世界で生きてきたような気がするのですが、映像、画像、音楽、音声など他の表現手段を手に入れたような気がします。

Windowsでは、使い勝手が悪くなるので、できるだけアプリをインストールしないように心掛けていたのですが、Macちゃんはどんどん入れて使い倒しています。(それでもパフォーマンスが落ちないのが嬉しい)。

また使っていくうちに両者の違いがわかるようになりました。
裏のソースコードがどういう思想で作られているのかがアプリを使っていると何となくわかってきます。

これはソースコードを書いている方に話をすると納得が得られるのですが、文章で書くには少々難解なので割愛します。

と言いつつ一言で言うならばMacはオブジェクト指向で書かれてあるのでシンプル。windowsは・・・。

この話を一般ビジネスパーソンに流用して「仕事の経験や実績を重視する人が陥る罠」を説明することができました。

これも機会があれば、どこかで書いてみたいと思います。

マネジメントの立場にいる方が部下に仕事を任せたり、役職にない方でも新たに取引先を増やそうとしている時など、様々なビジネスシーンでどうすればいいか、気を付けるポイントは何かがわかると思いますので・・・。

楽しみにしていてくださいね。
(と言いながら、気が向いた時に書くので、時期は全くわかりません。(笑))

2009/03/07

衝撃の新事実

私事で誠にすみません。

2001年、社会人生活のスタートと共に一人暮しを始めて丸8年。

昨日、初めて東京都23区推奨ゴミ袋45リットルがきれました。
何枚入りなのかわからないですが、100枚入りを買ったとも思えません。

多くて50枚入りでしょう。
(50枚入りも売っているかどうか・・・。)

仮に50枚だったとしても6x8=48。
年平均6枚。2ヶ月に1回45リットルのゴミを出しています。
(実際は1年ぐらいホテル暮らしをしていて、ほとんど家にいなかったので7x7=49。
年平均7枚ぐらいだと思います。)

このゴミの量。ほぼDMやチラシの量と言ってもいいでしょう。

正直、ウチのゴミのほとんどはポストに入っているDMやチラシです。

2ヶ月に45リットルのDMやチラシを多いとみるか、少ないとみるか・・・。

実際の所、DMやチラシで何か行動を起こしたことは全くないので、効果がないことを考えると、私に限って言えば紙の無駄使いと言えそうです。

紙ゴミ、本音を言うと減らしたいなあと思っているんですけど、どうしたらいいんでしょうね?

ということでオチも何もありません。

一人暮らしを始めて随分と経つのに、その間、ゴミ袋を買っていないことに気が付き、めちゃくちゃ驚いたので、そのままブログネタにしてしまいました。

もしかすると他にも何かあるかもしれません。

2009/03/06

ああ、勘違い

野球のWBCが始まりましたね。

日本にはぜひ頑張ってもらいたいです。

ところでWBCのテレビ中継ですが、日本対中国だとこのように表示されます。

日4 - 0中

日本ハム対中日に見えてしまうのは私だけでしょうか?

さらにドラゴンズファンとしては、なんか悔しく感じてしまいます。(笑)

2009/03/04

ABeam Consulting応援企画 第?弾

ブログのアクセス解析を見ると、例年、年が明けると、就職活動中の学生と思われる方がこのブログに訪れています。

どうやらABeam Consultingの情報を求めて、訪れているようです。
残念ながら私はABeam出身者というだけで有益な情報は持ち合わせていないのですが、どんな会社だったのか語ることはできます。

ということで、年に1回、やるかやらないか・・・「ABeam Consulting応援企画 第?弾」。
今回もABeam出身者である私がABeamを振り返ります。

起業して随分と月日が経ってしまいましたが、多くの会社とお付き合いしていく中でビックリしたことがあります。

それは「仕事の品質が低いこと」。

納品されたものの、「ホントにこれが最終形?まだ途中なんじゃないの?」と疑ってしまうようなものが納品されてくることがあります。

特にホワイトカラーと呼ばれるような方達の仕事は顕著にこの傾向が出ています。
「どうして品質が低いんだろう???」と疑問に思うことが度々ありました。

結論から言ってしまうと、仕事の品質が決して低いわけではありませんでした。

ABeamで働いている方達の品質が高かった・・・ということです。
つまり、その世界でしか働いていなかったので、ABeamが基準になってしまっていたのです。

世間的な感覚では、それは「高い」基準になってしまいます。
その視点で判断していたため「仕事の品質が低い」と思ってしまったわけです。

この点だけでもABeamはオススメの会社です。
自分が知らないうちに品質の高い仕事ができるようになっているわけですから・・・。

では、なぜ品質の高い仕事ができるのか?

その違いは何なのか自分なりに振り返ってみました。

一言で違いを表現すると、おそらく「仕事に対する誇り」というか「自分自身に対するプライド」というか、そういった言葉になるのかなと思います。

質の低い仕事をしている自分が許せない。
品質の悪い成果物を提出するのはありえない。

そのような気概を持った方達が多かったような気がします。

大工さんで例えるならば、屋根裏も含め誰が見る、見ないに関わらず一切手を抜かない・・・そんな感じです。
(個人的には、誰も見ないからいいだろう・・・と手を抜いた仕事が多いのにびっくりです。)

また、このような気概を持った方達が語る言葉はとても重みがありました。

これはどういうことかと言うと、先ほどの「仕事の品質が低い」と思われてしまった方達と比較するとわかります。

「仕事の品質が低い」と思われてしまった方達は、成果物の品質が低いことを指摘すると、「ごめんなさい」、「申し訳ありません」と言って、すぐに修正します。

つまり謝罪することにとても慣れています。

謝罪することに慣れている方達の謝罪は正直、心に響くことはありません。
修正もいつもやっている仕事・・・という認識です。

一方、気概を持った方達の謝罪は、それこそ断腸の思いといった感じです。
相手に迷惑をかけてしまったことはもちろん、自分自身に対しても許せない・・・そういった思いが表情や言葉に出ていたりします。

そりゃ、そうですよね。

その仕事に対してコミットメントしたわけですから、それが果たせないのは許せません。
約束を守れなかったのは最悪です。

・・・というのが普通の感覚だと思うのですが、そうではない会社やビジネスパーソンは思った以上に多いです。

今回、約束は守れなかったとしても、まぁ後で何とかカバーできるでしょう。
あの人は謝れば許してくれるから、まぁいいかな。
納期が厳しかったから、そりゃ難しいよ。
予算がない中で、そこまではできないよ。

そういった意識を持っている場面に出くわすことは多いです。

従って、最初の約束も「いいですよ」、「大丈夫ですよ」と非常に安請け合いをしています。
この安請け合いの感覚がわからず、ABeamの時と同じ様に大丈夫だと思ってお願いして、過去何度も痛い目にあっています。(どれだけのお金と時間を失ったか・・・。)

一方、気概を持った方達はそんな安請け合いはしません。
自分が約束できるのはどこまでか徹底的に議論してハッキリさせてから、コミットメントします。
(だから質の高い仕事ができるわけなのですが・・・。)

ABeamに行く、行かないはどちらでも構いませんが、下記心構えはこれから大きな可能性を秘めている若い方達にはぜひ持っていてもらいたいなぁと思っています。

・約束は守る
・謝罪は切腹と同じ(ゲームのゲームオーバーみたいにリセットしてやり直せるものではない。)

小さなことから大きなことまで、「約束したことは必ず守る」。
たったそれだけのことで、できるビジネスパーソンとして評価されます。

正直、それは最低限備えているべきことで、本来はその上で何を成し遂げたのか・・・が評価されるべきだと思うのですが、そこまで至っていない場面が多いようです。

良い就職活動、そして素晴らしい社会人人生を送られることを祈っています。

追伸)
ある特定の会社や個人をやり玉にあげて責めるつもりは全くないため、誤解を招かないよう具体的な仕事を挙げませんでした。

従って抽象的な表現になっているため、わかりにくい、おもしろくない・・・と思われる方がいるかもしれませんね。

そのような方は、これから歩んでいく仕事の中で、該当する場面があるかもしれない・・・とアンテナを立てておくといいかもです。