前回のエントリではファクトにこだわる事が重要だと述べましたが、それを実践するにあたっての注意点を。
続きを読む
2008年05月10日
ファクトにこだわる / コンサルタントの心得
コンサルタントの仕事の基本の基本は、ファクトとロジックです。
今回はそのうちの１つ、ファクトについて。
なぜファクトが重要か？
それがクライアントと、あるいは他のステークホルダーと渡り合う際の最も強力かつ確実な武器になるからです。
続きを読む
今回はそのうちの１つ、ファクトについて。
なぜファクトが重要か？
それがクライアントと、あるいは他のステークホルダーと渡り合う際の最も強力かつ確実な武器になるからです。
続きを読む
2008年01月13日
考えるなら Why? 聞くなら How?
日経ビジネス Associe のリレー連載「私の始末書」、2008.1.1号の西濃運輸社長 田口義隆さんの回より。強調は市井。
続きを読む
数字を分析し直してみると、目標を達成できている店とできていない店があることが分かりました。最初、私は達成できていない営業所に「なぜやれなかったのか」と聞いていました。すると彼らはあれやこれやと釈明してきました。ある時、達成できていた営業所に「どうやったの？」と聞いたところ、「こうやったらできた」とノウハウを教えてもらえたのです。このとき、私はやっと、現場を動かすには Why? ではなくて、How? と質問しなければうまくいかないということを知りました。
続きを読む
2007年10月20日
動向分析の視点：結果か手段か
どうでもいい一言からヒントが得られたのでメモ。
Ａ「御社は規模が急成長してますよね」
Ｂ「えぇ、でも社員数増加は結果じゃなくて手段なんですよ」
Ａ「え？」
Ｂ「人がすべての商売ですから、人材のポートフォリオを確保してビジネスの安定性を出したいんです。利益が増えた結果として規模が大きくなっているわけじゃなくて、利益を安定させる手段として人を増やしているんです」
企業動向を見るとき、ある事実がその企業にとって結果なのか、手段なのか。
外から見るとわかりにくいですが、大きく意味合いが変わるポイントでもあります。
事実を掴んだあとに分析のとっかかりとして最初に立てる仮説としても使える視点ですね。
Ａ「御社は規模が急成長してますよね」
Ｂ「えぇ、でも社員数増加は結果じゃなくて手段なんですよ」
Ａ「え？」
Ｂ「人がすべての商売ですから、人材のポートフォリオを確保してビジネスの安定性を出したいんです。利益が増えた結果として規模が大きくなっているわけじゃなくて、利益を安定させる手段として人を増やしているんです」
企業動向を見るとき、ある事実がその企業にとって結果なのか、手段なのか。
外から見るとわかりにくいですが、大きく意味合いが変わるポイントでもあります。
事実を掴んだあとに分析のとっかかりとして最初に立てる仮説としても使える視点ですね。
2007年10月03日
スタートアップ/ラップアップミーティングがもたらす５つの効果
方法論メモ。
スタートアップミーティングとラップアップミーティングは良いです。
スタートアップミーティングとラップアップミーティングとは、それぞれ朝夕に行う 10 分から 15 分程度のミーティングです。
チーム内全員参加、定刻スタート定刻完了がルール。どんなに忙しくても出席必須です。
何をやるかというと、最低限度の情報共有のみ。逆に最低限度に絞るために 15 分までという制限があるともいえます。
この時間内で全員が今日何をやるか/やったか、課題、対処案、作業の再割り振りなどを話します。
リーダーは他チームの動きや全体進捗を皆に伝えます。
これをやると何がいいか。
定期的に新鮮な情報を全員が得ることで、プロジェクトにリズムが生まれるんですよね。
そしてリズムがグルーヴを生んで、気づくとプロジェクトがスムーズに進むようになっている。
信じられないかもしれませんが、やってみるとこの濃密なコミュニケーションによる効果にはスゴいものがあります。
続きを読む
スタートアップミーティングとラップアップミーティングは良いです。
スタートアップミーティングとラップアップミーティングとは、それぞれ朝夕に行う 10 分から 15 分程度のミーティングです。
チーム内全員参加、定刻スタート定刻完了がルール。どんなに忙しくても出席必須です。
何をやるかというと、最低限度の情報共有のみ。逆に最低限度に絞るために 15 分までという制限があるともいえます。
この時間内で全員が今日何をやるか/やったか、課題、対処案、作業の再割り振りなどを話します。
リーダーは他チームの動きや全体進捗を皆に伝えます。
これをやると何がいいか。
定期的に新鮮な情報を全員が得ることで、プロジェクトにリズムが生まれるんですよね。
そしてリズムがグルーヴを生んで、気づくとプロジェクトがスムーズに進むようになっている。
信じられないかもしれませんが、やってみるとこの濃密なコミュニケーションによる効果にはスゴいものがあります。
続きを読む
2007年09月19日
論理思考と行動指向
論理思考のテキストに必ず書かれている、So What? を考えよ、とのアドバイス。
「だから何が言えるの？」との問いかけで、演繹思考を促したり、思考を具体化したり、問いに対応する答えにより近づけたりします。
以前通ったビジネスクールでもクラスを通じた口癖となっていました。
で、これが実務レベルではこれは Action oriented, 行動指向となる場合が多いように思えます。
チームメンバー（後輩）と話していて So What ? と問いかける時、ほとんどの場合が
「で、そのロジックの結果として誰が何をするの？」
という形になっていました。
例えば「ここがイヤな感じだねー」なんて話題の時に、
「イヤな感じって？」→「リスクがありそう」
「ではリスクがあるか否かを確認するには何を明確にすべき？」
→「AがBかを聞けばいい」
「何をもって B と言える？」→「CとDが揃えばいい」
「じゃ、誰がそれをやる？」→「Eさんが経緯上適任」
「OK、じゃぁEさんにCとDを確認する仕事をやってもらおう、締め切りは今月末で十分だね」
…といった具合です。
「あぁ、うんヤダねぇ、ありがちだよねー」と終わりそうな雑談の中から、
「誰がいつ何を」 という、責任を伴った具体的なタスクに落とし込みました。
So What ? は論理のピラミッドを組み際に事実からメッセージを「抽出」「結晶化」させるための問いかけとして、いわば抽象化のために使われますが、逆に具体化させて地に足の着いた仕事の進め方を得るためにも使えるようです。
「だから何が言えるの？」との問いかけで、演繹思考を促したり、思考を具体化したり、問いに対応する答えにより近づけたりします。
以前通ったビジネスクールでもクラスを通じた口癖となっていました。
で、これが実務レベルではこれは Action oriented, 行動指向となる場合が多いように思えます。
チームメンバー（後輩）と話していて So What ? と問いかける時、ほとんどの場合が
「で、そのロジックの結果として誰が何をするの？」
という形になっていました。
例えば「ここがイヤな感じだねー」なんて話題の時に、
「イヤな感じって？」→「リスクがありそう」
「ではリスクがあるか否かを確認するには何を明確にすべき？」
→「AがBかを聞けばいい」
「何をもって B と言える？」→「CとDが揃えばいい」
「じゃ、誰がそれをやる？」→「Eさんが経緯上適任」
「OK、じゃぁEさんにCとDを確認する仕事をやってもらおう、締め切りは今月末で十分だね」
…といった具合です。
「あぁ、うんヤダねぇ、ありがちだよねー」と終わりそうな雑談の中から、
「誰がいつ何を」 という、責任を伴った具体的なタスクに落とし込みました。
So What ? は論理のピラミッドを組み際に事実からメッセージを「抽出」「結晶化」させるための問いかけとして、いわば抽象化のために使われますが、逆に具体化させて地に足の着いた仕事の進め方を得るためにも使えるようです。
2007年08月30日
上司が２人います
コンサルティングファームで働き、ふと特徴的だなと思ったのでメモ。
うちの会社だけかも。
まず、私には一般的な意味での上司はいません。
プロジェクトに入れば責任範囲のツリーに従い、私の働きに対して責任を持つ人が私の上に入るので、その人を上司と呼ぶことはできます。
とはいえ、それはプロジェクトの中の話。
一旦プロジェクトを離れてしまうと、組織の上長としての上司はいません。
ですから評価は純粋に各プロジェクトでの働きで勝負できます。
特定の上司との人間関係やいざこざで悩んだりということがないのは良い点ですね。
一方で、過去の貯金をつかって今の言い訳をする、といったこともできませんが…。
いずれにしても、これが一人目の上司。
で、２人目というのがプロジェクトの外にいる、いわゆるメンターです。
会社として用意している役割なので、メンターと呼ぶにはちょっと抵抗がありますが…
この人は下に付いた者の成長に責任を持つ人で、年に数回会って面談し、現在の成果や今後のキャリア、学習目標、といったことを話し合います。
年に数回の面談でキャリア上の影響を与えうるかどうかというと私は信じていなくて、その意味でもメンターとは違うと思っています。
ただ、プロジェクトの外にいながら、組織からそれなりの権限を与えられているため、便利に使わせてもらえるのはありがたいです。
例えば重要なトレーニングがプロジェクトの山場と重なった時、普通ならプロジェクト優先となりますが、自身の成長と天秤にかけた上でトレーニングを取りたければ、メンターがプロジェクトマネージャとかけあってくれます。
私たちは「成果」を出す必要がある一方、「成果を出す能力」を磨き続ける必要も当然あります。
「成果」は当然プロジェクトの中から強く要求されますが、そのせいで「成果を出す能力」を失いがちです。（それ以前にすべての土台たる健康を害する人が多いのも不幸なことですが…）
これを組織としてバランスを取ろうとしているのは、非常に面白い試みだと感じました。
こういう原則論に立ち帰った時、それがどうインプリされているか/しているかまで考えるのは結構刺激的ですし、イノベーションの種が隠れていそうですね。
うちの会社だけかも。
まず、私には一般的な意味での上司はいません。
プロジェクトに入れば責任範囲のツリーに従い、私の働きに対して責任を持つ人が私の上に入るので、その人を上司と呼ぶことはできます。
とはいえ、それはプロジェクトの中の話。
一旦プロジェクトを離れてしまうと、組織の上長としての上司はいません。
ですから評価は純粋に各プロジェクトでの働きで勝負できます。
特定の上司との人間関係やいざこざで悩んだりということがないのは良い点ですね。
一方で、過去の貯金をつかって今の言い訳をする、といったこともできませんが…。
いずれにしても、これが一人目の上司。
で、２人目というのがプロジェクトの外にいる、いわゆるメンターです。
会社として用意している役割なので、メンターと呼ぶにはちょっと抵抗がありますが…
この人は下に付いた者の成長に責任を持つ人で、年に数回会って面談し、現在の成果や今後のキャリア、学習目標、といったことを話し合います。
年に数回の面談でキャリア上の影響を与えうるかどうかというと私は信じていなくて、その意味でもメンターとは違うと思っています。
ただ、プロジェクトの外にいながら、組織からそれなりの権限を与えられているため、便利に使わせてもらえるのはありがたいです。
例えば重要なトレーニングがプロジェクトの山場と重なった時、普通ならプロジェクト優先となりますが、自身の成長と天秤にかけた上でトレーニングを取りたければ、メンターがプロジェクトマネージャとかけあってくれます。
私たちは「成果」を出す必要がある一方、「成果を出す能力」を磨き続ける必要も当然あります。
「成果」は当然プロジェクトの中から強く要求されますが、そのせいで「成果を出す能力」を失いがちです。（それ以前にすべての土台たる健康を害する人が多いのも不幸なことですが…）
これを組織としてバランスを取ろうとしているのは、非常に面白い試みだと感じました。
こういう原則論に立ち帰った時、それがどうインプリされているか/しているかまで考えるのは結構刺激的ですし、イノベーションの種が隠れていそうですね。
2007年07月19日
Google alert が凄い
Google のサービスに Google alert ってのがありますが、これが凄いです。
一言でいうと Google による Web 切り抜きサービスでしょうか。
昔、エグゼクティブは秘書に新聞の切り抜きをさせていたそうですが、Google の精度とスピードで自分のメールアドレスにレポートが届きます。
キーワードを登録しておけば、Google が報道系サイトをウォッチしてくれて、そのキーワードを使った新たなページが見つかるとメールで知らせてくれます。
注目の新技術、クライアント名、クライアントのCIO名、自社名、特定の（ディープな）有名人を登録しておくと、かなりの精度とスピードで情報収集ができます。
これならお客様と話すのにニュースを知らずに恥をかくこともないですし、有名人の選択次第では個人名をキーとした分野アンテナになりそうです。例えば山崎秀夫さんを登録することで、SNS やソーシャルウェブ、ナレッジマネジメント、IT とヒューマニティの関わりなどに関するアンテナが立てられます。
まぁ試しに気になるキーワードを登録してみて下さい。
まさに百聞は一見に如かず、Google が自分の秘書になってくれる快適さは素晴らしいものがあります。
一言でいうと Google による Web 切り抜きサービスでしょうか。
昔、エグゼクティブは秘書に新聞の切り抜きをさせていたそうですが、Google の精度とスピードで自分のメールアドレスにレポートが届きます。
キーワードを登録しておけば、Google が報道系サイトをウォッチしてくれて、そのキーワードを使った新たなページが見つかるとメールで知らせてくれます。
注目の新技術、クライアント名、クライアントのCIO名、自社名、特定の（ディープな）有名人を登録しておくと、かなりの精度とスピードで情報収集ができます。
これならお客様と話すのにニュースを知らずに恥をかくこともないですし、有名人の選択次第では個人名をキーとした分野アンテナになりそうです。例えば山崎秀夫さんを登録することで、SNS やソーシャルウェブ、ナレッジマネジメント、IT とヒューマニティの関わりなどに関するアンテナが立てられます。
まぁ試しに気になるキーワードを登録してみて下さい。
まさに百聞は一見に如かず、Google が自分の秘書になってくれる快適さは素晴らしいものがあります。
2007年05月06日
フィードバックのコツ：即座に行動を、感情と愛をもって
一分間マネージャという本と、私が今所属している会社のガイドラインをもとに。
フィードバックとは誉めたり叱ったり、良い点悪い点を伝えることです。
1 分間マネージャでは「フィードバックは王者の朝食」と書かれていました。フィードバックが普段から色々な場所で自然と行われているチームは、間違いなく強くなっていきます。
まず何より、失敗を見つけようとしない。成功を探す。
過ちを見つけたら正すべきですが、基本姿勢として誉められる点を探すべきです。
人間は誉められた方が気分がいいですし、気分がよければそれだけで生産性が上がります。知識労働者においてはモチベーションというのは非常に重要です。
即座にフィードバックする
リーダーやマネージャーが犯しがちなミスは、メンバーを長いこと放置し、年次評価などのタイミングでそれまでの駄目な点をぶちまけ、バッサリとやってしまうことです。
不慣れな人間は、徐々にしか学ぶことはできません。ですから徐々に徐々に、軌道修正してあげる必要があります。
シャワーの温度を適温にしようとして苦労したことはありませんか？あれが大変なのは操作から実際に温度が変わるまでにタイムラグがあるからです。
人の成長も同じ。年に一回、「冷たすぎる！」と一気に温水の蛇口をひねったり、逆に冷水をひねったりしたってうまくいきません。温度を見ながら、ひねってから変化までにタイムラグがあることを考えながら徐々に修正していくしかありません。
どういうわけか、人は上に立つと「下は自分が期待していることを正確に理解している」「下は私の期待に沿った行動をとって当たり前」と思いこみがちですが、努力もなしに期待している内容が伝わっていることはまずあり得ません（その際には是非 S.M.A.R.T. な目標設定を一緒にやりましょう）。
フィードバックすべき行動を見たらすぐにフィードバックするのが最も効果的です。
行動をフィードバックする
フィードバックの対象は、人格ではなく行動でなければいけません。一般的な表現、主観的な表現もいけません。具体的かつ客観的でなければいけません。そしてもちろん、イメージや噂話にもとづいてはいけません。
例えば「君はプログラムの品質に気を配っていない」は駄目で、「君はウォークスルー前にセルフチェックをしなかった」であるべきです。どうしても一般的な「感覚」で語ってしまいがちですが、それを指摘されてもどう修正していったらいいか、相手はわかりません。
感情をこめる
誉める時は自分がどんなに気分がいいか、逆に失敗を指摘する時はどんなに残念に思っているかを伝えます。
1 分間マネージャでは数秒の沈黙を使って相手に感じる時間を与えるようアドバイスしています。
人の感情というのは深く響き、残ります。指摘は理性的に行うべきですが、相手により強く効果を残すためには感情に訴えかけるのが効果的です。
愛情を伝える
誉めた時はもちろん、負のフィードバックであっても相手を大事に思っていること、期待していることを伝えます。
最近の日本人はこういうコミュニケーションを苦手ですし、新人などは引いてしまうかも知れません。
ですから直接的な言葉以外の方法でもいいでしょう。ですが、行動について触れた後は人格を肯定することが絶対に必要です。
何よりも一番重要なのは、周りのメンバーの成長を心から願うことだと思います。
もっとも簡単なマネジメント本
課題の共有・目標管理
有能な管理者になるためには？
フィードバックとは誉めたり叱ったり、良い点悪い点を伝えることです。
1 分間マネージャでは「フィードバックは王者の朝食」と書かれていました。フィードバックが普段から色々な場所で自然と行われているチームは、間違いなく強くなっていきます。
まず何より、失敗を見つけようとしない。成功を探す。
過ちを見つけたら正すべきですが、基本姿勢として誉められる点を探すべきです。
人間は誉められた方が気分がいいですし、気分がよければそれだけで生産性が上がります。知識労働者においてはモチベーションというのは非常に重要です。
即座にフィードバックする
リーダーやマネージャーが犯しがちなミスは、メンバーを長いこと放置し、年次評価などのタイミングでそれまでの駄目な点をぶちまけ、バッサリとやってしまうことです。
不慣れな人間は、徐々にしか学ぶことはできません。ですから徐々に徐々に、軌道修正してあげる必要があります。
シャワーの温度を適温にしようとして苦労したことはありませんか？あれが大変なのは操作から実際に温度が変わるまでにタイムラグがあるからです。
人の成長も同じ。年に一回、「冷たすぎる！」と一気に温水の蛇口をひねったり、逆に冷水をひねったりしたってうまくいきません。温度を見ながら、ひねってから変化までにタイムラグがあることを考えながら徐々に修正していくしかありません。
どういうわけか、人は上に立つと「下は自分が期待していることを正確に理解している」「下は私の期待に沿った行動をとって当たり前」と思いこみがちですが、努力もなしに期待している内容が伝わっていることはまずあり得ません（その際には是非 S.M.A.R.T. な目標設定を一緒にやりましょう）。
フィードバックすべき行動を見たらすぐにフィードバックするのが最も効果的です。
行動をフィードバックする
フィードバックの対象は、人格ではなく行動でなければいけません。一般的な表現、主観的な表現もいけません。具体的かつ客観的でなければいけません。そしてもちろん、イメージや噂話にもとづいてはいけません。
例えば「君はプログラムの品質に気を配っていない」は駄目で、「君はウォークスルー前にセルフチェックをしなかった」であるべきです。どうしても一般的な「感覚」で語ってしまいがちですが、それを指摘されてもどう修正していったらいいか、相手はわかりません。
感情をこめる
誉める時は自分がどんなに気分がいいか、逆に失敗を指摘する時はどんなに残念に思っているかを伝えます。
1 分間マネージャでは数秒の沈黙を使って相手に感じる時間を与えるようアドバイスしています。
人の感情というのは深く響き、残ります。指摘は理性的に行うべきですが、相手により強く効果を残すためには感情に訴えかけるのが効果的です。
愛情を伝える
誉めた時はもちろん、負のフィードバックであっても相手を大事に思っていること、期待していることを伝えます。
最近の日本人はこういうコミュニケーションを苦手ですし、新人などは引いてしまうかも知れません。
ですから直接的な言葉以外の方法でもいいでしょう。ですが、行動について触れた後は人格を肯定することが絶対に必要です。
何よりも一番重要なのは、周りのメンバーの成長を心から願うことだと思います。
1分間マネジャー―何を示し、どう褒め、どう叱るか!
posted with amazlet on 07.05.06
K.ブランチャード S.ジョンソン 小林 薫
ダイヤモンド社 (1983/01)
売り上げランキング: 22332
ダイヤモンド社 (1983/01)
売り上げランキング: 22332
おすすめ度の平均: 
もっとも簡単なマネジメント本 課題の共有・目標管理 有能な管理者になるためには？目標設定のコツ：領域外をSMARTに落とす
今回はより良い目標設定のコツを。
個人的に立てる目標でもいいですが、どちらかというと他人と合意を取る必要のある、会社の目標管理で設定する目標で真価を発揮します。
まずは目標設定するテーマですが、その目標の領域の外から持ってくるとよいです。
例えば個人の目標であっても社訓や会社のミッションステートメントの要素を網羅するようなテーマを並べたり、年次目標であっても中期経営計画からテーマを拾ったりします。
設定する目標の対象や期間が決まっていると何となくその枠内で無難に選びがちですが、より大きなアクションへの貢献は常に意識すべきであり、特定の目標もそれと整合性を取っているべきだからです。
次にそのテーマごとに、S.M.A.R.T. を意識して具体化します。
Specific ― 具体的で十分に詳しく、解釈のブレがないこと。「何をどれだけ」が明確であること。
Measurable ― 数値で測定できること。感覚で評価されないこと。量ならば個数、回数、金額などを具体値で。質ならば欠品率、ライン当たりバグ数、ユーザー満足度 4.5 pt 以上など数値化すること。
Achievable ― 達成可能な範囲で挑戦的であること。非現実的でないこと。
Relevant ― 重要であること。単なるアクティビティやルーチンワークではないこと。個人や組織の優先事項に沿っていること。
Time-bound ― 達成すべき期間や納期が明確であること。
Web で調べると、この S.M.A.R.T. にはいくつものバリエーションがあるようです。
ですがそのココロは基本的に同じで、
・誰が見ても達成の度合いを評価/判断できるように
です。
理想郷は各人が胸に秘めてさえいれば各人の原動力となり、それだけで価値を持ちますが、目標は違います。組織からの評価にしろ、自己評価にしろ、目標は後日必ず評価にさらされます。
その評価が有用なものとなるかどうかは、目標が適切に設定されたか否かによって左右されてしまいます。
例えば私はあるアウトソーシングのプロジェクトで「オフショア化の視点からすべての成果物に関して提案をする」という目標を立てました。
「中国関連の経験を活かしプロジェクトに貢献する」なんていう目標も設定しがちですが、これでは何を基準に測ったらいいかわかりません。
成果物という測定単位を明確にすることで、何割達成したか否かが客観的に示すことができます。
一方で、このような目標設定だと「質はともかく、すべての成果物にクチを出せばよい」とも取れてしまいます。そこは理解したうえでの目標設定でした。提案の質を測定するのは困難ですし、「課題指摘」ではなく「提案」なので意味のない茶々入れはカウントされません。
このようなバランス取りは毎回必要にはなりますが、S.M.A.R.T.な目標を目指してバランス調整すること自体が、仕事やプロジェクトの意味を見つめ直す良い機会にもなります。
個人的に立てる目標でもいいですが、どちらかというと他人と合意を取る必要のある、会社の目標管理で設定する目標で真価を発揮します。
まずは目標設定するテーマですが、その目標の領域の外から持ってくるとよいです。
例えば個人の目標であっても社訓や会社のミッションステートメントの要素を網羅するようなテーマを並べたり、年次目標であっても中期経営計画からテーマを拾ったりします。
設定する目標の対象や期間が決まっていると何となくその枠内で無難に選びがちですが、より大きなアクションへの貢献は常に意識すべきであり、特定の目標もそれと整合性を取っているべきだからです。
次にそのテーマごとに、S.M.A.R.T. を意識して具体化します。
Specific ― 具体的で十分に詳しく、解釈のブレがないこと。「何をどれだけ」が明確であること。
Measurable ― 数値で測定できること。感覚で評価されないこと。量ならば個数、回数、金額などを具体値で。質ならば欠品率、ライン当たりバグ数、ユーザー満足度 4.5 pt 以上など数値化すること。
Achievable ― 達成可能な範囲で挑戦的であること。非現実的でないこと。
Relevant ― 重要であること。単なるアクティビティやルーチンワークではないこと。個人や組織の優先事項に沿っていること。
Time-bound ― 達成すべき期間や納期が明確であること。
Web で調べると、この S.M.A.R.T. にはいくつものバリエーションがあるようです。
ですがそのココロは基本的に同じで、
・誰が見ても達成の度合いを評価/判断できるように
です。
理想郷は各人が胸に秘めてさえいれば各人の原動力となり、それだけで価値を持ちますが、目標は違います。組織からの評価にしろ、自己評価にしろ、目標は後日必ず評価にさらされます。
その評価が有用なものとなるかどうかは、目標が適切に設定されたか否かによって左右されてしまいます。
例えば私はあるアウトソーシングのプロジェクトで「オフショア化の視点からすべての成果物に関して提案をする」という目標を立てました。
「中国関連の経験を活かしプロジェクトに貢献する」なんていう目標も設定しがちですが、これでは何を基準に測ったらいいかわかりません。
成果物という測定単位を明確にすることで、何割達成したか否かが客観的に示すことができます。
一方で、このような目標設定だと「質はともかく、すべての成果物にクチを出せばよい」とも取れてしまいます。そこは理解したうえでの目標設定でした。提案の質を測定するのは困難ですし、「課題指摘」ではなく「提案」なので意味のない茶々入れはカウントされません。
このようなバランス取りは毎回必要にはなりますが、S.M.A.R.T.な目標を目指してバランス調整すること自体が、仕事やプロジェクトの意味を見つめ直す良い機会にもなります。
2007年05月01日
リアルスピードハックス-仕事のスピードを一ヶ月で3倍にする技術
最近 Lifehack という、昔でいう仕事術のようなものが流行りですね。
Lifehack はストレスフリーが１つのキーのようで、私も結構好きです。
で、そんな Lifehack 本の中にシゴタノ！というブログを書いている大橋さんによる「スピードハックス - 仕事のスピードをいきなり3倍にする技術」という本があります。
勉強会で著者自ら「いきなり3倍ってのは編集がつけた。目指すけど無茶だよね」なんておっしゃってました。
3倍のスピードというのはかなり魅力的です。（シャア的な響きを除いて、ね）
いきなりは無理かも知れませんが、資産管理でよく言われる複利効果を持ち出せば、3倍という夢のような数字を意外と現実的な期間で（計算上）実現可能なことに気づきました。
例えば、毎日 6% ずつスピードアップしていけば、20 営業日、一ヶ月でトータル3倍に達します。
昨日１時間かかった作業を、今日4〜5分短縮するだけです。
継続していくのはツラそうですが、案外無理でもないかな、と思いませんか？
集中力を上げたりするだけでなく、邪魔を防止したりツールを導入してもいいんです。
6% は小さく見えるけど実際には無理だよ！というのなら、1% でも構いません。
これだと3倍に至るのに 110 営業日、それでも半年かかりません。次回の年次評価には余裕で間に合うでしょう。
昨日１時間かかった作業を、36秒だけ短縮すればいい計算です。
もちろんコレは嘘が入ってますけどね。
作業改善の効果というのは複利ではなく積み上げ式（36秒の短縮を110回やったら36×110=3960秒＝66分）ってのが実際でしょうし、それすらも間断なく継続して続けていくのは相当の苦労が伴うはずです。
また、そもそも我々の仕事は量だけでなく質で測られる面も多いので、スピードが3倍になったからといってそれがすなわち成果が3倍になるわけではないです。
とはいえ、こういった計算で「できるかも」感をもって改善にあたるのは悪いことではないでしょう。
それに複利で簡単に3倍にはならなくとも、トヨタなどの実例を見ても日々のカイゼンを積み上げること自体は長期的な強みになりえるはずです。
Lifehack はストレスフリーが１つのキーのようで、私も結構好きです。
で、そんな Lifehack 本の中にシゴタノ！というブログを書いている大橋さんによる「スピードハックス - 仕事のスピードをいきなり3倍にする技術」という本があります。
勉強会で著者自ら「いきなり3倍ってのは編集がつけた。目指すけど無茶だよね」なんておっしゃってました。
3倍のスピードというのはかなり魅力的です。（シャア的な響きを除いて、ね）
いきなりは無理かも知れませんが、資産管理でよく言われる複利効果を持ち出せば、3倍という夢のような数字を意外と現実的な期間で（計算上）実現可能なことに気づきました。
例えば、毎日 6% ずつスピードアップしていけば、20 営業日、一ヶ月でトータル3倍に達します。
昨日１時間かかった作業を、今日4〜5分短縮するだけです。
継続していくのはツラそうですが、案外無理でもないかな、と思いませんか？
集中力を上げたりするだけでなく、邪魔を防止したりツールを導入してもいいんです。
6% は小さく見えるけど実際には無理だよ！というのなら、1% でも構いません。
これだと3倍に至るのに 110 営業日、それでも半年かかりません。次回の年次評価には余裕で間に合うでしょう。
昨日１時間かかった作業を、36秒だけ短縮すればいい計算です。
もちろんコレは嘘が入ってますけどね。
作業改善の効果というのは複利ではなく積み上げ式（36秒の短縮を110回やったら36×110=3960秒＝66分）ってのが実際でしょうし、それすらも間断なく継続して続けていくのは相当の苦労が伴うはずです。
また、そもそも我々の仕事は量だけでなく質で測られる面も多いので、スピードが3倍になったからといってそれがすなわち成果が3倍になるわけではないです。
とはいえ、こういった計算で「できるかも」感をもって改善にあたるのは悪いことではないでしょう。
それに複利で簡単に3倍にはならなくとも、トヨタなどの実例を見ても日々のカイゼンを積み上げること自体は長期的な強みになりえるはずです。
2005年11月14日
中国人エンジニアとの会話
最近、オフショア開発にどっぷり関わっています。
中国人エンジニアとやりとりをうまく回す、いくつかのポイントが見えてきました。
１つ目は、よく聞くこと。
コミュニケーションの基礎として、まず相手を理解すること、少なくとも理解する努力を相手に見せることは重要です。
よく会話はキャッチボールに例えられますが、「うまく投げること」を重視する人と、「うまく受け止めること」を重視する人の２種類がいるように思えます。一般に日本人は受ける側、欧米人は投げる側ですね。中国人も投げる側に分類できると思います。ですから、話を聞くだけだと相手はドンドンしゃべり続けます。こちらから適宜質問を投げたり、相手の言っていることを言葉を変えて表現してみたりして、話の軌道修正をかけながら、じっくり聞きます。
２つ目は、言いたいことを整理しシンプルにすること。
大量の言葉を浴びせると、たまたま聞き取れたところだけ理解して全体を理解したつもりになりかねません。なので、ここだけは外してはいけない、というポイントを一言にまとめ、それを繰り返します。周辺や背景の話をしても、必ずそのポイントに話を戻してから会話をしめます。
コツは、（表現上日本語で長くなっても）英単語２個程度で表現できるようポイントを練ることですかね。 5W1H＋α か、Yes/No くらいまで絞り込めると確実に伝わります。
３つ目は、必要なら言葉以外の手段を使うこと。
一般に技術用語は英語ですので、用語レベルで苦労することはないでしょう。（稀に通訳がその言葉を知らないために、「実体同士の関係を表した一覧表が欲しい」なんて言われたりもします。ER図の事です）
同様に、ベン図やカルノー図などはコンピュータサイエンスを学ぶ過程で彼らも身に付けています。これを使わない手はありません。システムやプログラムを表現するためだけでなく、仕事のプライオリティや責任範囲など抽象的な概念を表現する手助けにもなります。
４つ目は、具体的に話すこと。
一般則で伝えると、誤解や誤認識が発生しがちです。
例えば、「工数に照らして、実施困難な条件はテストしなくても構わない」は伝わりませんでした。多くの日本人エンジニアは「ああいうパターンだよな」と頭に浮かぶのですが、外国人エンジニアには伝わらないことがあります。クライアント数など物理的に困難なケースや確率論的にしか発生しないケースなど、具体例を挙げると笑って「それは無理ですね」と理解したようでした。
一般則的な表現の方が楽なのですが、イメージが湧き易いように具体例を添えないと伝わらないケースがあります。
およそ１ヶ月間、中国人エンジニアとやりとりしていて気づいたポイントは以上です。
まだ 10 人程度と話した範囲での私の感想レベルなので自信はないのですがもしかしたら中国人は帰納的な思考の方が得意なのではないかという仮説があります。
受け取る時だけでなく話す時も例ばかり挙げてきて、私が「つまりこういう事ですか？」と聞くと首を縦に振る、ということが何度もありました。
単純に言葉の壁と奮闘する中での「もがき」の１つかも知れませんが、もしかしたら有用なヒントになるかも知れません。
中国人エンジニアとやりとりをうまく回す、いくつかのポイントが見えてきました。
１つ目は、よく聞くこと。
コミュニケーションの基礎として、まず相手を理解すること、少なくとも理解する努力を相手に見せることは重要です。
よく会話はキャッチボールに例えられますが、「うまく投げること」を重視する人と、「うまく受け止めること」を重視する人の２種類がいるように思えます。一般に日本人は受ける側、欧米人は投げる側ですね。中国人も投げる側に分類できると思います。ですから、話を聞くだけだと相手はドンドンしゃべり続けます。こちらから適宜質問を投げたり、相手の言っていることを言葉を変えて表現してみたりして、話の軌道修正をかけながら、じっくり聞きます。
２つ目は、言いたいことを整理しシンプルにすること。
大量の言葉を浴びせると、たまたま聞き取れたところだけ理解して全体を理解したつもりになりかねません。なので、ここだけは外してはいけない、というポイントを一言にまとめ、それを繰り返します。周辺や背景の話をしても、必ずそのポイントに話を戻してから会話をしめます。
コツは、（表現上日本語で長くなっても）英単語２個程度で表現できるようポイントを練ることですかね。 5W1H＋α か、Yes/No くらいまで絞り込めると確実に伝わります。
３つ目は、必要なら言葉以外の手段を使うこと。
一般に技術用語は英語ですので、用語レベルで苦労することはないでしょう。（稀に通訳がその言葉を知らないために、「実体同士の関係を表した一覧表が欲しい」なんて言われたりもします。ER図の事です）
同様に、ベン図やカルノー図などはコンピュータサイエンスを学ぶ過程で彼らも身に付けています。これを使わない手はありません。システムやプログラムを表現するためだけでなく、仕事のプライオリティや責任範囲など抽象的な概念を表現する手助けにもなります。
４つ目は、具体的に話すこと。
一般則で伝えると、誤解や誤認識が発生しがちです。
例えば、「工数に照らして、実施困難な条件はテストしなくても構わない」は伝わりませんでした。多くの日本人エンジニアは「ああいうパターンだよな」と頭に浮かぶのですが、外国人エンジニアには伝わらないことがあります。クライアント数など物理的に困難なケースや確率論的にしか発生しないケースなど、具体例を挙げると笑って「それは無理ですね」と理解したようでした。
一般則的な表現の方が楽なのですが、イメージが湧き易いように具体例を添えないと伝わらないケースがあります。
およそ１ヶ月間、中国人エンジニアとやりとりしていて気づいたポイントは以上です。
まだ 10 人程度と話した範囲での私の感想レベルなので自信はないのですがもしかしたら中国人は帰納的な思考の方が得意なのではないかという仮説があります。
受け取る時だけでなく話す時も例ばかり挙げてきて、私が「つまりこういう事ですか？」と聞くと首を縦に振る、ということが何度もありました。
単純に言葉の壁と奮闘する中での「もがき」の１つかも知れませんが、もしかしたら有用なヒントになるかも知れません。
2005年05月30日
仕事のリードタイム短縮のために
私の課題の１つは、仕事のスピード感が遅いことです。
個々の単位作業の速度が遅いわけではなく……
他人に聞くのが遅れる理由は２つ自覚していて、
コストパフォーマンス度外視は、自分への教育効果が十分に上がる範囲ならアリかと思います。でも資料の場所を知ってるか知らないかといった単純なケースもあり、立ち止まって、得られる効果の価値を考えてみることも必要そうです。
他人への遠慮は、他人の作業とその時点での集中具合が見えないだけに難しいところです。「向こう一時間の間のどこかで10分時間を下さい」と割いてもらう時間帯を向こうに判断してもらったり、「この作業のここで困っています、今止めるとこういった後続作業も遅れます」と話したりして、全体でのコストベネフィットのすり合わせをしています。
また根本的に「他人に聞く」というのが「判断を求めている」のか「知識を求めている」のかで、かなり違いがあります。
他人の知識を求めることが多いのであれば、どこかでまとまった教育機会をもらうのも１つの手ですね。
他人の作業待ちの原因は
社外の人（連携先のシステム担当）やお客様が相手のケースが多いため、質問のところと同様の密度のコミュニケーションが取れてないのが問題のようです。
個々の単位作業の速度が遅いわけではなく……
- 自分で抱え込みがち。
詰まったところで疑問点をまとめ、識者に持っていくタイミングが遅い。 - 自分の作業外の待ちが多い。
回答待ち、他人の作業待ちが多く発生する。
他人に聞くのが遅れる理由は２つ自覚していて、
- 調べることで身につくスキルもある、とコストパフォーマンスを意図的に度外視している。
- 他人の仕事を中断させることに遠慮してしまう。
コストパフォーマンス度外視は、自分への教育効果が十分に上がる範囲ならアリかと思います。でも資料の場所を知ってるか知らないかといった単純なケースもあり、立ち止まって、得られる効果の価値を考えてみることも必要そうです。
他人への遠慮は、他人の作業とその時点での集中具合が見えないだけに難しいところです。「向こう一時間の間のどこかで10分時間を下さい」と割いてもらう時間帯を向こうに判断してもらったり、「この作業のここで困っています、今止めるとこういった後続作業も遅れます」と話したりして、全体でのコストベネフィットのすり合わせをしています。
また根本的に「他人に聞く」というのが「判断を求めている」のか「知識を求めている」のかで、かなり違いがあります。
他人の知識を求めることが多いのであれば、どこかでまとまった教育機会をもらうのも１つの手ですね。
他人の作業待ちの原因は
- 相手の負荷状況が見えない
- 相手に回答のプライオリティが伝わりきらない
社外の人（連携先のシステム担当）やお客様が相手のケースが多いため、質問のところと同様の密度のコミュニケーションが取れてないのが問題のようです。
2005年05月13日
条件を意識する / 論理思考の基本態度
ここでいう条件とは、制約条件と前提条件の２つです。
制約条件とは解決方法に対する制限のことです。
実行不可能な解決案を出さないために、という意味もありますが、それ以上に、無意識のうちにありもしない制約条件を自分で勝手にかけていないかをチェックする意味でも重要です。超えてはいけない柵を越えないよう気をつける一方、本当に超えてはいけない柵なのか、ただの白線を勝手に「柵の代わりに用意されたものだ」と思い込んで近づかなかったりしていないか、検討します。逆説的ですが、枠を超えた思考をするために、枠とは何か、何が枠なのかを見つめなおすわけです。
アルコールはソフトドリンクと比べて割高ですが、その理由は原価の違いの他に酒税の存在もあります。酒税という販売価格上の制約条件の中、ビール業界の各企業は戦っていました。その中、発泡酒という一見制約条件の枠の外にある戦場へ早く戦いを展開した企業が、業界の情勢を大きく変え、ひいては企業体力の差にまで繋がってしまったのは記憶に新しいところです。
前提条件とは解決にあたって、成り立っていなければならない条件です。
制約条件と違い、成り立っていることを利用して、解により近づけることが多いです。ちょうど数学の問題に現れる「条件」に似ています。制約条件を策や枠に例えましたが、前提条件はどちらかというと「足場」として積極的に判断材料として活用します。
一方で、一般的な解決案を個別のケースに対して適用する場合やその逆の場合などに、これを意識しないと痛い目にあいます（一般論は多くのケースに当てはまるよう、前提条件を「仮定」していることが多いです）。演繹を話題にする際にまた触れますが、暗黙のうちに前提条件を立ててしまい、それを相手と共有できていないがために議論が平行線を辿ることもよくあります。また、本当に足をかけて大丈夫な足場なのかの検証も重要です。
制約条件とは解決方法に対する制限のことです。
実行不可能な解決案を出さないために、という意味もありますが、それ以上に、無意識のうちにありもしない制約条件を自分で勝手にかけていないかをチェックする意味でも重要です。超えてはいけない柵を越えないよう気をつける一方、本当に超えてはいけない柵なのか、ただの白線を勝手に「柵の代わりに用意されたものだ」と思い込んで近づかなかったりしていないか、検討します。逆説的ですが、枠を超えた思考をするために、枠とは何か、何が枠なのかを見つめなおすわけです。
アルコールはソフトドリンクと比べて割高ですが、その理由は原価の違いの他に酒税の存在もあります。酒税という販売価格上の制約条件の中、ビール業界の各企業は戦っていました。その中、発泡酒という一見制約条件の枠の外にある戦場へ早く戦いを展開した企業が、業界の情勢を大きく変え、ひいては企業体力の差にまで繋がってしまったのは記憶に新しいところです。
前提条件とは解決にあたって、成り立っていなければならない条件です。
制約条件と違い、成り立っていることを利用して、解により近づけることが多いです。ちょうど数学の問題に現れる「条件」に似ています。制約条件を策や枠に例えましたが、前提条件はどちらかというと「足場」として積極的に判断材料として活用します。
一方で、一般的な解決案を個別のケースに対して適用する場合やその逆の場合などに、これを意識しないと痛い目にあいます（一般論は多くのケースに当てはまるよう、前提条件を「仮定」していることが多いです）。演繹を話題にする際にまた触れますが、暗黙のうちに前提条件を立ててしまい、それを相手と共有できていないがために議論が平行線を辿ることもよくあります。また、本当に足をかけて大丈夫な足場なのかの検証も重要です。
2005年05月08日
何が問題かを考える / 論理思考の基本態度
問題とは「望む状態と現状との差」です。
何か問題を解決しようと考える際、まず問題自体についてきちんと考えておかないと、無駄が生じます。
問題について「なぜ？を５回繰り返せ( 5 Why)」とよく言われますが、以下のようなポイントについて考えると効果的です。
何か問題を解決しようと考える際、まず問題自体についてきちんと考えておかないと、無駄が生じます。
問題について「なぜ？を５回繰り返せ( 5 Why)」とよく言われますが、以下のようなポイントについて考えると効果的です。
- 症状を問題と取り違えていないか
「集中力が落ちた」は「睡眠不足」による症状で、「睡眠不足」は「業務負荷が高い」ことによる症状かも知れません。このケースで、集中力を上げる方法を検討しても効果的ではありません。 - 解法を問題と取り違えていないか
症状の話と似ています。「彼と同等のスキルを持った人をいかに調達するか」は１つの解法で、問題はあくまで「特定個人に業務負荷が集中している」ことです。作業標準化で要求スキルを下げる、可能な範囲で要求作業品質を落とすといった解法もありえます。 - 問題の所有者は誰か
問題が「望む状態と現状との差」である以上、誰かが「望む」ことが問題存在の前提です。その望んだ人こそが、問題の所有者です。問題の立ち振る舞いを少し変えたり、問題の所有者が考え方や価値観を変えたりするだけで、問題自体が蒸発してしまうこともあります。（多少のレスポンスの問題は、Now Loading...の文字とシンプルでユニークなアニメーションで蒸発させられるのは有名です）また、問題の所有者を意図的に変える/広げる/転嫁することで新たな視点が得られることもあります。 - 解決すべき問題か
問題を解決することに集中しすぎてはいけません。解決にかかる（時間的、スキル的）コストとベネフィットのバランスは常に意識すべきですし、また解決することが自己目的化してしまっては、本末転倒です。
2005年03月08日
頼まれ仕事の納期
今暇？ちょっこコレ調べてくれる？
と、こまごまとした依頼はどこの職場でもよくあると思います。
作業の中断というのは、どんな仕事をやっていても効率を落とすもの。
今の作業との兼ね合いで、この飛び込み用件をどうスケジューリングするか？
いわゆる仕事術と呼ばれる Tips のうちの１つです。
私は国内のメーカー系 SI から外資コンサル系 SI に移りました。
外資だといっても働いているのは日本人ばかり、お客様も基本的に日本人ばかり。
（例外的にグローバル案件だと互いに海外オフィスの人間も交えますけど）
基本的に文化の違いはそうはないなぁ、と感じていたのですが、この小さな依頼ばっかりは前職場ではあり得ないだろう、という会話が成り立ちます。
以下、実際にあった会話。
「市井くん、君 Excel 詳しかったよね？こういうのって VBA 組まずにできそう？」
「んー、いつまでに回答したらいいですか？」
「できれば今すぐ。でも考えて思いつきそうだったら言って。作業着手を明日に先延ばすから」
「考えるって、何分くらい考える価値あります？」
「そうだな、さしあたり 10 分。そこで今日中かかるか仮回答もらえる？」
「10分ならいいですよ。今やってるのは、さほど緊急の仕事でもないので。
普通の Excel 関数の組み合わせでどうにかなりそうですね…」
スケジューリングをどうするか、を考えるには、そもそも重要度と緊急度を天秤にかけ、スキルと時間という資源を配分する必要があります。
そのためには、依頼する側、される側でそれら判断材料を共有しなければならない。
考えれば当たり前なんですけど、普通なかなかできないですよね。
私の前職場でも一方的に指示が来るだけでした。
先輩に対して「考える価値あります？」なんて絶対に言えなかったです。
でもせめて納期確認ぐらいはしてもよかったかな、と思います。
…なんて書いてて、自分で書いた「プロの心得：外を見つめる。まっすぐに。」と被るのに気がつきました。
私も先輩も、チームとしてのアウトプットという「外」を見ず、互いの上下関係だけを意識して仕事をしていたのかも知れません。
こりゃぁ、気づいていないところで色々やっちゃってるかも知れませんね、私。
ドラクエトークで盛り上がる「すーぱーSEへの道」より「調べ物を頼まれたら」のトラックバックでした。
と、こまごまとした依頼はどこの職場でもよくあると思います。
作業の中断というのは、どんな仕事をやっていても効率を落とすもの。
今の作業との兼ね合いで、この飛び込み用件をどうスケジューリングするか？
いわゆる仕事術と呼ばれる Tips のうちの１つです。
私は国内のメーカー系 SI から外資コンサル系 SI に移りました。
外資だといっても働いているのは日本人ばかり、お客様も基本的に日本人ばかり。
（例外的にグローバル案件だと互いに海外オフィスの人間も交えますけど）
基本的に文化の違いはそうはないなぁ、と感じていたのですが、この小さな依頼ばっかりは前職場ではあり得ないだろう、という会話が成り立ちます。
以下、実際にあった会話。
「市井くん、君 Excel 詳しかったよね？こういうのって VBA 組まずにできそう？」
「んー、いつまでに回答したらいいですか？」
「できれば今すぐ。でも考えて思いつきそうだったら言って。作業着手を明日に先延ばすから」
「考えるって、何分くらい考える価値あります？」
「そうだな、さしあたり 10 分。そこで今日中かかるか仮回答もらえる？」
「10分ならいいですよ。今やってるのは、さほど緊急の仕事でもないので。
普通の Excel 関数の組み合わせでどうにかなりそうですね…」
スケジューリングをどうするか、を考えるには、そもそも重要度と緊急度を天秤にかけ、スキルと時間という資源を配分する必要があります。
そのためには、依頼する側、される側でそれら判断材料を共有しなければならない。
考えれば当たり前なんですけど、普通なかなかできないですよね。
私の前職場でも一方的に指示が来るだけでした。
先輩に対して「考える価値あります？」なんて絶対に言えなかったです。
でもせめて納期確認ぐらいはしてもよかったかな、と思います。
…なんて書いてて、自分で書いた「プロの心得：外を見つめる。まっすぐに。」と被るのに気がつきました。
私も先輩も、チームとしてのアウトプットという「外」を見ず、互いの上下関係だけを意識して仕事をしていたのかも知れません。
こりゃぁ、気づいていないところで色々やっちゃってるかも知れませんね、私。
ドラクエトークで盛り上がる「すーぱーSEへの道」より「調べ物を頼まれたら」のトラックバックでした。
2005年03月07日
業務の視える化ツール、ノリとハサミの MagiCa
情報システムは業務を改善/改革するためにあり、その前提として業務を分析しなければなりません。
誰がいつどこで何のために誰と何をどうやってするか、その量は質は、というのが「パッと見てわかる」状態にないと改善のしようがありません。
これを支援する楽しいツールを知りました。
「わたしが知らないスゴ本は、きっとあなたが読んでいる」より「続マジカのひみつ」で紹介されている、StarLogicの Magica です。
改変しなければ再配布自由とのことなので、PDF(875KB)を置いておきます。
効果については上記トラックバック先の記事を参照して下さい。
お客様のゲンバで気軽に作業を開始できるのがいいです。
例え UML であっても、システム屋の言葉が出てくるとゲンバの方は身構えます。
そこにノリとハサミで、ってのがイイですね。
すごく楽しそうだしイタズラっぽい感じがして好きです。
自分の仕事としてはお客様の業務分析はしていないので、とりあえず自分の仕事をこれで視える化してみようと思います。
非定型作業で効率化が難しいと思って改善に着手できずにいますが、何か新たな課題が視えるようになるかも知れません。
誰がいつどこで何のために誰と何をどうやってするか、その量は質は、というのが「パッと見てわかる」状態にないと改善のしようがありません。
これを支援する楽しいツールを知りました。
「わたしが知らないスゴ本は、きっとあなたが読んでいる」より「続マジカのひみつ」で紹介されている、StarLogicの Magica です。
改変しなければ再配布自由とのことなので、PDF(875KB)を置いておきます。
効果については上記トラックバック先の記事を参照して下さい。
お客様のゲンバで気軽に作業を開始できるのがいいです。
例え UML であっても、システム屋の言葉が出てくるとゲンバの方は身構えます。
そこにノリとハサミで、ってのがイイですね。
すごく楽しそうだしイタズラっぽい感じがして好きです。
自分の仕事としてはお客様の業務分析はしていないので、とりあえず自分の仕事をこれで視える化してみようと思います。
非定型作業で効率化が難しいと思って改善に着手できずにいますが、何か新たな課題が視えるようになるかも知れません。
2005年02月20日
クリティカルシンキングを支えるハート(心臓)
本屋を覗くとクリティカルシンキングが流行しているようです。
演繹と帰納といった基礎からMECEにロジックツリー、SWOTや4Pというツールに自省的思考が主だったテーマのようです。
そういったいわばビジネスで戦う上での筋トレ本の中にあって、筋肉に血液を供給する強い心臓を作ってくれたのがこの本。
他人に対する優しさの醸成と、自覚症状を感じてからの自分のメンテナンス
考えるを考える
思い当たるふしが、、
自分の思考のクセを知れ！
思考系の本100冊分
インパクトのある表紙ですが(笑)、中身はハードです。
この本で言う思考の生活習慣病とは以下の４点です。
これらに対処するための方策として７つの思考習慣、思考のシフトチェンジ、思考の基本動作が紹介されています。
私にもかなり思い当たるフシがありますね〜。特に最初の２個、放棄と依存。
考えよう、となればもちろんある程度以上の水準で考える自信はありますが、知らず知らずのうちに放棄や依存で思考回路にスイッチが入らないことがあります。
気づかぬうちにいつの間にか、というのがまさに生活習慣病。
いくら思考のテクニックを身につけても、頭が回り始めなければ意味がないですよね。
その怖さに気づかせてくれた良書です。
思考の生活習慣病に対処する方策もよく整理されていて「使え」ます。
演繹と帰納といった基礎からMECEにロジックツリー、SWOTや4Pというツールに自省的思考が主だったテーマのようです。
そういったいわばビジネスで戦う上での筋トレ本の中にあって、筋肉に血液を供給する強い心臓を作ってくれたのがこの本。
考えるプロが明かす「思考の生活習慣病」克服法
posted with amazlet at 08.05.10
船川 淳志
講談社
売り上げランキング: 134999
講談社
売り上げランキング: 134999
おすすめ度の平均:
他人に対する優しさの醸成と、自覚症状を感じてからの自分のメンテナンス 考えるを考える 思い当たるふしが、、 自分の思考のクセを知れ！ 思考系の本100冊分インパクトのある表紙ですが(笑)、中身はハードです。
この本で言う思考の生活習慣病とは以下の４点です。
- 思考の放棄。例えば…
- これだけの情報では判断できないですよ
- だって私はプログラミングしかやってきてないですから
- そんな事考えたって意味ないよ
- やったことないからわかりませんよ
- 思考の依存。例えば…
- 経済誌にそう書いてあったからです
- だって皆もやってるじゃない
- やはりこれからはアスペクト指向だな！
- 先輩もそうやってきたし変える必要はないです
- 思考の歪み。例えば…
- 日本は島国なので閉鎖的だ
- アメリカは犯罪が多く危険だ
- 値段を下げろ、消費者は安価な物を求めている
- プログラマは喋るのが嫌いだよね
- 思考の偏り。例えば…
- 知識が不足する分野の議論で声の大きい人に納得してしまう
- 同じロジックなのに自分の立場を俎上に乗せると結論が変わってしまう
- Windows と Linux を技術的な観点から評価しているはずが開発モデル論になってしまう
- 設計の美しさと同様のこだわりが運用への配慮に表れない
これらに対処するための方策として７つの思考習慣、思考のシフトチェンジ、思考の基本動作が紹介されています。
私にもかなり思い当たるフシがありますね〜。特に最初の２個、放棄と依存。
考えよう、となればもちろんある程度以上の水準で考える自信はありますが、知らず知らずのうちに放棄や依存で思考回路にスイッチが入らないことがあります。
気づかぬうちにいつの間にか、というのがまさに生活習慣病。
いくら思考のテクニックを身につけても、頭が回り始めなければ意味がないですよね。
その怖さに気づかせてくれた良書です。
思考の生活習慣病に対処する方策もよく整理されていて「使え」ます。
2005年02月19日
図表のタイトルには内容の説明よりもメッセージを
プレゼンテーションや報告書で使う図表のタイトルには、内容の説明よりもメッセージを使うべき。
これ、社会人になってから教わって目から鱗が落ちました。
同じ図表やチャートでもタイトルは「過去10年間の製品別売上の推移」よりも「重要製品は化粧品から健康食品に移っている」の方が優れている、というわけです。
そもそもドキュメント全体の目的が意見の主張や意思決定者の説得やならば、その論拠をデータで示した図表だって、何がしかのメッセージを読み手に対して発しているはずです。というよりも、書き手は発したくてその図表を載せたはずです。
純粋な統計資料ならば、図表自身が示す「事実」をタイトルにすればよいけれど、
プレゼンならば図表を使って自分が伝えたい「メッセージ」をタイトルにすべき。
なるほど。
最近はメディアリテラシーとか総合科目とかあるらしいから違うかも知れないけれど、私が小学校の時なんかでは図表のタイトルは図表が伝える「事実」を採用しなさい、って教わった気がする。
これ、社会人になってから教わって目から鱗が落ちました。
同じ図表やチャートでもタイトルは「過去10年間の製品別売上の推移」よりも「重要製品は化粧品から健康食品に移っている」の方が優れている、というわけです。
そもそもドキュメント全体の目的が意見の主張や意思決定者の説得やならば、その論拠をデータで示した図表だって、何がしかのメッセージを読み手に対して発しているはずです。というよりも、書き手は発したくてその図表を載せたはずです。
純粋な統計資料ならば、図表自身が示す「事実」をタイトルにすればよいけれど、
プレゼンならば図表を使って自分が伝えたい「メッセージ」をタイトルにすべき。
なるほど。
最近はメディアリテラシーとか総合科目とかあるらしいから違うかも知れないけれど、私が小学校の時なんかでは図表のタイトルは図表が伝える「事実」を採用しなさい、って教わった気がする。
