デマルコ 基調講演
【だれも教えてくれないマネージメント】
〜ゆとりの法則〜
マネージメントというとプロセスを語る人が多い
『そんなことよりも重要なことをマネージメントしないといけない。』
・部下の動機付け
・適材適所に配置
・最適な環境の構築
問題
・プロセスは意味あるマネージメントの元でないと効果がない
・マネージメントトレーニングは簡単な部分だけ教えてくれる。(重要な部分は教えてくれない)
・そして、最も重要なのは「組織の中でマネージメントスキルを学ぶ仕組みが存在しない」
『重要な事は現場で学ぶしかない。
⇒生まれながらのマネージャでないとマネージメントに失敗する』
THE PARADOX OF IMPROVEMENT
CMMとかISOとか組織の成熟度の指標は存在するが
・よいマネージメント+低いCMM=いい結果を残す 例:Microsoft
・悪いマネージメント+高いCMM=さっぱり 例:NTT
・よいマネージメント+高いCMM=もちろん、いい結果
『プロセスよりも優れたマネージャーを育成するべし』
役に立たないマネージメント教育
・予算の立て方(予算がどうあるべきかではない)
・スケジュール(ツールの使い方とか)
・タスク管理
・報告書の作り方
だれも教わらないマネージメント
・人選、配置
・離職防止
・対立の解決
・チームの作り方
・チームをいかに維持するか
・動機付け
・誉める
「よくやった」と誉めるのは人の行為に対して判断を下している。
判断を下す⇔人を誉める 相反することでは? 誉め手の立場が上である。
⇒自分自身の心から誉める。 I feel 「あなたのおかげで私はうれしい」
・感謝する
感謝を口に出すのは難しいが、相手に伝わらなければ感謝していないのと同じである。
心から気持ちをこめてありがとうと言う。
・話を聞く
態度・聞く姿勢+相手の言うことを理解していると表現する(自分の言葉で相手の意見を反芻)
・信頼する
先に信頼を与えることで、部下は信頼にこたえようとする
学習体験における4つの要素が必須
1.先生
2.教材
3.ほかの学習者
4.そして、自分(学習者)
『マネージャーのOJTでは何も存在しない』
成功するマネージメントのために
マネージャーチーム
報告会はミーティングではなくセレモニーである
・ミーティング 全員が同じことについて話し、考える
・セレモニー ボスに報告するだけ Teamとは言えない
『よい組織はセレモニーをなるべく少なくする。』
組織はマネージメントスキルをどう学ぶかを学ぶ必要がある。
『Management By Team を実現せよ』
組織図のTreeでは、、、管理職の間の空白が危険な存在である。
BAD PRACTICE 管理者同士はチームではなく競合者である。
良い例:
HPでは マネージャの下に二人のサブマネージャ、その下にそれぞれ二人のチームリーダがいる。
しかし、実際はその7人が協力してプロジェクトを成功に導いていた。
マネージャーチームによる管理⇒グループオーナーシップ によるマネージャの育成
まとめ 7つのプラクティス
1.マネージメントチームを作る
2.アジャイル(俊敏な)ワークチームを作る
(チームを作るからには個別の和よりもうまくいく必要がある
⇒バラバラの方がうまくいくというチームは根本的なところが間違えている)
3.聞くこと
4.感謝すること ありがとう>無理にでも言う>心から言う>自然に言う
5.誉めること (自分の立場で誉めること)
6.対立の解決
7.スケジューリング
参考文献
Robert Bolton People Skills 読むべし
Tom DeMarco The Deadline
Tom DeMarco Peopleware
Q&A
Q:チームワークを高める触媒者の生産性が低い場合、生産性を高めるべきであるか?
A:その人が効率的でなくても全体で効率がいいならそれでいいのでは?
その人をトレーニングするのが本当に正しい方向なのか考えないといけない。
そもそも、ソフトウェア生産においてトレーニングを受けたらエキスパートとして働ける
能力を要求されるが、人はショパンを習った次の日に滑らかに弾くことを要求しますか?
トレーニングし、実践したあとで実力が付く。結局、ゆとりは必要だよ
コーチングして教えることは教える人も学ぶことができる。コーチはコストでないので認めよう。
Q:開発者なのですが組織におけるマネージメントを改善していくのはどうすればいいのでしょうか?
A:まず、できないことがあります。
『リーダーシップで上を変えることはできません』これはどんなに努力しても無駄です。
横の人を望むように仕向けなさい。
・横にリーダーシップを発揮することで
1.自分が上にあがることができる。上にあがったときに下を変える。
2.自分と横が一緒に上にあがったときにマネージャーチームを組織する
この2つを実現することができるようにがんばりなさい。
【リスクマネージメント チュートリアル】
〜熊とワルツを〜
RISK MANAGEMENT
・3つの最悪なケース
・1つの有効なツール
・モンテカルロの嘘
・リスク追跡の尺度
・恐ろしく、また素晴らしい事実
・過去における5つのリスクパターン
・リスク管理してる?
・3つの最悪なケース
例)火事におけるリスク
1.リスクがあることを見ようとしない
⇒木造住宅
2.起きうるリスクに備えない
⇒消火設備がない
3.リスクが起きたという指標がない
⇒警報機がない
例)デンバー空港の工事の遅れ
1.ソフトウェアがクリティカルパス
(ソフトウェアは納期に間に合わない可能性がある)
2.遅れた時のことを考えない。
(空港の通路を広くすればよかった)
3.移行の指標はあったが誰もみようとしなかった。
(ベストエフォートの契約、1ヶ月前にも赤信号)
・1つの有効なツール
リスクダイアグラム
例)あるプロジェクトについて分かること
・1月には無理だ
・4月に仕上がる確立が一番高い
・5月になれば50%の確率で完成する
・12月には確実にできている。
こんなグラフができる
***
*********
*************
*********************
******************************
- 1--2--3--4--5--6--7--8--9-10-11-12-完成期日
期日を固定した場合は横軸が機能や品質になる。
・
モンテカルロの嘘
FP法で測定したからといって、人月が計算できるのか?
例)20KFP=52人月
これは
統計学的平均から出したものだが意味を持たない。
実際には不確実性が含まれる。
・リスク追跡の尺度
色々なRISKダイアグラムを作成して統合的にプロジェクトの不確実性を取る
インプット 規模、離職、期間、技術力 etc
アウトプット あるものを尺度にしたリスクダイアグラム
期待している日付けと実際の日付をグラフにして遅れを検知する
・恐ろしく、また素晴らしい事実
『リスクマネジメントは積極的にリスクを負うために行う』
⇒ リスクを負ってでも新しいビジネスを行うために、本当にリスクを見る必要がある。
=本音で話さないとリスクを背負えない。
・過去における5つのリスクパターン
1.サイズが大きく
2.予想が違い
3.離職
4.意見の不一致(不協和音)
例)仕様がなかなか完成しない。しかし、曖昧なプログラムは存在しない
5.生産性の変化
・
リスク管理してる?
ソフトウェアの
リスク管理はだれが行う??
委託する側とされる側の両方が行うべきだ。
リスク管理の6つのTest
1.起きうるリスク(の原因リスト)を10〜20項目列挙できますか?
2.それぞれのリスクが具現化する確立・具現化したときのコストを見積もりましたか?
3.リスクが起きたときの以降指標がありますか?
4.起きたらプロジェクトがだいなしになるコアリスクを把握していますか?
5.リスクダイアグラムを使っています?
6.納入予定日とすべてがうまく行った完成予定日は離れていますか?
(納入予定日のほうが完成予定日より先というのは論外)
・QA
Q:企業文化で否定的意見を言いにくい
A:会議の初めに+−と両方の意見を言うように冒頭で通知
たとえば、、、
最悪な事態がおきたとしてその原因をみんなで考えてみる。
(例:プロジェクトが1年遅れた。遅れた理由をみんなで議論する)