2006-10-29 :-)
_ 09:00
起床
_ 11:00
酔っ払いは神田でラーメン食う夢を見るか
_ 12:00
HDD レコーダーから DVD-R( video ) に書いてみた( 初めてマニュアル読んだよ! )
書いた DVD-R を Windows の何かプレイヤーで再生してみたらプレイヤーが「 応答なし 」になったのでタスクマネージャーによって殺戮。
_ おやつ
富良野牛乳プリン。
_ すべてを破壊するもの
急須の蓋を割ってしまた。
_ システム開発 火事場プロジェクトの法則—どうすればデスマーチをなくせるか?
だいぶ前に読み終えたんだがまとめ。
付箋紙たくさん。
2 部構成。
- 第一部「 火事場プロジェクトの○と× 」デスマーチのための確認項目
- 第二部「 デスマーチを斬る 」組織行動の本質を書いたもの
三輪は第二部に注目した。
人生履歴
著者やまざきさんの流れ。
- 新人
- デスマーチ
- 疲れる ← 三輪はいまここ
- 会社を辞める
- お金について学ぶ ← 以前やまざきさんからここの助言を貰った
- ひとについて学ぶ
- ビジネスについて学ぶ
- 価値とは何か
一生飢えない
魚を与えれば、その人は一日飢えないでいられる。
魚の捕り方を教えれば、その人は一生飢えないでいられる。( p.146 )
技術の howto だけでなく技術の本質を学ぶ。
技術に限らない。
普段使っている道具はなぜこのような形になっているのか、この道具を使っているときに自分は何をしているのか、日本酒はなぜ米から作られるのか。
ものはお金を出せば買える、サービスはお金を出せば得られる。お金を出して「 金は出した、あとはよろしく頼む 」だけでは、得られたサービスが正しいのか、自分の要求を満足しているのか判断できない。判断できるならそれでいい。
たとえば保険のひとに「 保険どうすか? 」と言われ、「 契約したのであとはよろしく保険屋さん 」だけではその保険は本当に必要なのか、無駄なことは無いのか、そもそも保険が必要なのか、そのサービスに金を払う意味はあるのかを判断できない。三輪がまさにそれ。
自分だけではハッピーになれない
最良の結果は全員が自分とグループ全体の利益を求めると得られる( p.242 )
- デスマーチは組織に問題がある
- 組織には自分も含まれる
- 組織にたいして自分は何が出来るか
分かりやすいたとえ話があった。
たとえば、2 人の姉妹が 1 つのケーキを切り分けて食べようとする。
姉は言う。「 おねーちゃんが切って、分けてあげるからネ 」
しかし、妹は反論する。「 そんなのやだ! おねーちゃんは自分の方を多くするに決まっている! あたしが切る! 」
どちらも、自分のやりたいことしか考えていない。しかし、ナッシュならおそらくこう言う。
「 まず、お姉さんがケーキを切って、次に、妹が好きなほうを選びなさい、そして最後に、残ったケーキをお姉さんが取りなさい 」
( p.243 )
自分だけでなく、2 人ともハッピーになる。
自分がハッピーになるためには組織をハッピーにする。組織がハッピーになれば結局自分もハッピーになる。
お互いが価値を高め合うために
- まずは自分を高める
- 高まった自分の価値で、まわりの価値を高める。
- お互いがお互いに影響を与え、お互いの価値を高め合う。
( p.248 )
まず自分を変えるところから始める。相手を変えようとしてはいけない。相手を変えるには多大な労力が必要だし、そもそも労力を費やしても相手は変わらないかもしれない。相手を変えるのではなく自分を変えるのである。
幸運は努力し続けた人にのみ渡されるプレゼント( p.249 )
ともあれ、三輪は証券会社と契約するところから始める。ぃゃすいません、リサーチだけはしたんです、いま出ます。
ref.
4774128813
_ ハレ晴れ
チャリ
_ アート・オブ・プロジェクトマネジメント
PM はプロジェクトのメンバーが円滑に作業できるように立ち回るのが仕事である。
シンプルは簡単ということではない。( 中略 )シンプルは簡単と同じ意味の言葉ではないとうことを心に刻んでおいてください。例えば、マラソンを完走するということはシンプルな行為です。まず走り始めた後、途中で投げ出すことなく 42.195 km を走り抜けばよいのです。( p.4 )
私が愛用している日々のマントラは、「 いい仕事をしよう 」というものです。チームメンバーと廊下ですれ違ったり、ホワイトボードの前でプログラマと仕事をしていると、みんなが「 やぁ、スコット、何やってんだい? 」と声をかけてきます。すると私は「 いい仕事をやってるんだ 」と笑ながら応えるのです。( p.21 )
PM( プロジェクトマネージャー )は何をすべきかについて書かれたもの。
- 計画
- 設計
- プログラミング
- テスティング
など、プロジェクトの各段階において PM がおこなうことをすべて網羅しているが、コミュニケーションの部分が印象に残った。
コミュニケーション上のよくある問題
コミュニケーションには以下の問題( とその原因も )があると書いている。( p.213 )
- 前提
- 明確さの欠如
- 聞く耳を持たない
- 指示
- 問題のずれ
- 個人攻撃/人格攻撃
- 嘲笑、冷やかし、非難
「 君の言ったことんなんて関係ない、相手がどう聞いたのかそこが問題になるのだ 」( p.213 )
- 言った/言わない
- 私はこう言っただろう
- 君が言ったことは私はこう解釈した
という問題はよくある。「 相手に伝わっていないということは言っていないのと同じだ 」と三輪の父も言っている。コミュニケーションにはこれらの問題があることを認識しておく。そしてそれらの原因を認識しておく。問題が起きそうな状況になったらよく注意して会話すること。
メンバーがベストを尽くせるように支援する理由
昔、私が Windows チームにいた頃、自分の時間のすべてを、他のメンバーの作業支援に使っていると感じていたことがありました。当時の私は( 直接報告を受ける立場の )マネージャになってまだ日が浅く、メンバーの作業の火消しを手伝ったり、アドバイスを与えることに奔走した挙げ句に疲れ果て、一人になりたいと思うようになったのです。( p.224 )
著者はのちほど気づくが、これこそが PM の仕事である。
PM は自分のために仕事をするのではなく、他人( チームメンバー )のために仕事をする。チームメンバーと対話し、チームメンバーを鼓舞し、外部の圧力からチームメンバーを守り、チームメンバーの問題( あれば、そしてたいていある )を把握する。
信頼と過ち
問題を引き起こした人物が私のオフィスに入ってっくるたびに、以下の 3 つの考えを持ち続けておこうとしている( p.305 )
として以下 3 つ。
- 彼がその件について私のところに相談しに来てくれたことを喜びます
- その問題が何であれ、どのようにすれば解決を支援できるでしょうか?
- 彼が学ぶことのできる教訓があるかどうかを確認する必要があります
先ず PM がチームメンバーを信頼する。PM が信頼していれば、チームは PM を信頼するようになる。
問題を起こした人物にたいして頭ごなしに非難してはいけない。非難しても問題の解決にならないし、非難されることでチームメンバーが萎縮してしまう。そしてチームメンバーは PM へ問題を隠蔽するようになる。
面白い例がある。
あなたの部下がオフィスに駆け込んできて、「 私のオフィスが燃えているんです! 」と金切り声を上げているときに、「 おいおい、馬鹿なことをするんじゃないよ。なぜそんなことになったんだ? 君には失望したよ 」と言うようなものです。( p.307 )
問題を非難するだけなら誰でも出来る。
非難ではなく問題解決のための提案が必要なのだ [2005-05-26]。
さらに全体のこと
「 わたしが知らないスゴ本は.. 」が細かく書いている。
ref. わたしが知らないスゴ本は、きっとあなたが読んでいる
4873112990