読者です 読者をやめる 読者になる 読者になる

「ドラッカー風エクササイズ」って何それ美味しいの?

↓これ面白そう。美味しいのかなぁ?

ドラッカー風エクササイズ

アジャイルサムライ−達人開発者への道−」に載ってるらしいんですが、読んだはずなのに記憶にないです。。

どんな時に使うのだろう。

プロジェクトを始めるときにする質問だそうです。(シンプルで強力なチームビルディングの手法)

4つの質問

1. 自分は何が得意なのか?

これはプロジェクトにjoinする前から知っとかなきゃならないことだ。

○○やりたい!って上昇的な気持ちも大事だけど、今の自分の現状がどのようなものかちゃんと伝わらないと信用されないし、誤解を招く。

(自分の得意不得意って人生のどの辺から気づき始めるもんなんだろう。どんなきっかけで知るのだろうか。)

2.自分はどうやって貢献するつもりなのか?

プロジェクトがどのようなものかを知ったタイミングで判断ロジックが走る類。 リズミカルに話が進むと、フロー体験っぽくてすごく幸福な気持ちになるかもしれない。

でも幸福な気持ちになるのはいいが、ちゃんとコミットメント出来るか?ってことがもっと重要。

3.自分が大切に思う価値は何か?

これもプロジェクトにjoinする前にもあるもので、 プロジェクトが大切にしているものと刷り合わせられるとたぶん幸せになれるんだと思う。

たしかCODE COMPLETE 第2版 上に書いてあったような気がするんだけども、 本来だったら「早い安いうまい」のすべてを大切にするべきなんだけれども、プロジェクトによっては全部求めた場合に、どれも中途半端になっちゃう可能性が高い。

  • 開発速度を重視するのか?
  • プログラムの可読性を重視するのか?
  • 品質を重視するのか?
  • 実行速度を重視するのか?
  • ドキュメントを重視するのか?
  • コミュニケーションを重視するのか?

そのプロジェクトは何を重視してるのか。

(たしかこんな内容だったと思うけど・・・若干あやふやだ後で読み返そう。)

4.チームメンバーは自分にどんな成果を期待してると思うか?

これはプロジェクト+メンバの特性を知ったタイミングで処理される事柄。

人的リソースは常にネックになる部分。 プロジェクトのメンバ構成によって役回りも変わるもの。

プログラマになるときもあれば、顧客の視点に立つこともあるだろうし、デザイナーになるときもあるよね。 ただし、なるべく強みが期待されてそこにコミットメントできる方が重要ですよね。

ふと思ったこと。

普段から己を知るっていう自己マネジメントができてる人って強いなぁ。

自己マネジメントできてる(己を知ってる)からこそ、Noと言えるんだと思う。

「そこは私の得意分野ではありません。他をあたってください」と。

ただ自分の年齢的(26歳)にはまだまだ知るべきことが沢山あるときなんだから断ることで自分を知ることを逃すことにもなる可能性があったりするのかもしれない。

逆に言うと若さ→失敗の可能性が高いってとこさえ認識してればそれはそれで、自己マネジメントの第一歩かもしれない。

知的労働者の寿命は企業のそれより長い現代において、自己マネジメントは重要。

関連エントリ

関連リンク