2009-07-25

デッドライン ソフト開発を成功に導く101の法則

正しい管理の四つの本質

・適切な人材雇用する。

・その人材を適所にあてはめる。

・人々の士気を保つ。

・チームの結束を強め、維持する。

(それ以外のことは全部管理ごっこ

安全と変更

・変更は、あらゆるプロジェクト成功のために(ほかの大抵の物事についても)必要不可欠である

・人は安全だとわからないと変更を受け入れない。安全保証されていないと、リスクを避けようとする。

リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である

・人は、面と向かって脅されたときはもちろん、自分に対して不当に権力行使されるかもしれないと思ったときにも、安全ではないと感じるようになる。

負の強化

脅迫は、結果を上げさせる手段としては不完全である

・どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。

さらに悪いことに、目標を達成できなければ、脅迫の内容を本当に実行しなければならない場合もある。

管理者の身体本質的な部分

管理は心、腹、魂、鼻でやるものだ。

 つまり……

 心で指揮をとる。

 自分の腹を信じる(直感を信じる)。

 組織に魂を吹き込む。

 くだらないものを嗅ぎ分ける鼻を持つ。

戦闘指令と管理関係

戦闘が始まるときには、管理者のほんとうの仕事はもう終わっている。

面接採用

採用には、管理必要身体の器官、心臓、魂、鼻、腹をすべて使う(しかし、腹が大部分だ)。

・一人でやろうとするな。二つの腹には、一つの腹の2倍以上の力がある。

・新しく採用した人材には、1回は実証済みの能力レベルプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする。

意見を求めよ。最も採用したいと思った人物は、ほかの優れた人材を知っている可能性が高い。

・話すより聞け。

・これらのことは、下準備をしておけばさら効果がある。

生産性の向上

短期的に生産性を高める方法などない。生産性は、長期的な投資によって向上する。

短期的な効果約束するものは、いんちきである可能性が高い。

リスク管理

リスク管理することによってプロジェクト管理せよ。

プロジェクトごとにリスク調査方法確立して継続せよ。

・最終的な望まざる結果だけでなく、日常リスクに注意せよ。

・それぞれのリスクの実現する確率と予想コスト評価せよ。

リスク現実になる前の初期の兆候予測せよ。

・やる気のある態度を常に引き出そうとしない人物リスク管理人に任命せよ。

・悪い話が上層部に伝わりやすい経路(匿名性など)を作っておくこと。

防御体制の強化

無駄を減らす。

成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる。

・失敗した作業は早く打ち切る勇気を持つ。

・チームの結束については必要のない賭けはしない。既存のチームを探して利用する。

・結束の遅い、または結束しないチームのために後継者が困らないよう、優れたチームは維持する(本人たちにその意思があれば)。

・新しい仕事を引き受ける意欲のある結束の固いチームは、プロジェクトの成果の一つと見なす

プロジェクトの初期にむだにする一日も、末期にむだにする一日も等しく打撃になる。

・一日をむだにする方法はいくらでもある……しかし、一日を取り戻す方法は一つもない。

開発プロセスモデリングシミュレーション

仕事を完成させるプロセスに関する直感モデル化する。

・仲間との対話の中で、プロセスの進行に関する考えを伝えたり修正したりするためにモデルを使う。

モデルを使って結果をシミュレートする。

・実際の結果と照らし合わせてモデルを調整する。

病んだ政治

・いつでもクビを賭ける覚悟必要である

しかし、それでも病んだ政治の影響を受けないとは限らない。

・病んだ政治はどこにでも、最も健全組織にも出現する可能性がある。

・病んだ政治の決定的な特徴は、個人権力と影響力の目標が、組織自然目標より優先されることである。これは、病んだ目標組織目標と相反する場合でも起こりうる。

・病んだ政治副作用の一つは、少人数のプロジェクトを抱えることが危険になることである

測定基準

・すべての製品サイズを測定せよ。

単位を気にするな。客観的尺度ができるまでの間は、主観的単位を使えばよい。

・手に入るすべての基本要素(ソフトウェアの数量化可能な特徴)をもとに合成尺度作成する。

考古学データ収集し、これまでに完了しているプロジェクトから生産性の傾向を算出する。

・合成尺度公式をいじり、その値と、考古学データベースのプロジェクトの労力の相関関係が最良になるポイントを見つける。

過去データベースをもとにトレンドラインを引き、予想される労力を、合成尺度の値の関数として示す。

・つぎに、予想を立てるべき新規プロジェクトのそれぞれについて、合成尺度の値を計算し、それを使ってトレンドラインから予想される労力を割り出す。

生産性トレンドノイズレベルは、予測を立てるときの誤差の目安にする。

プロセスプロセス改良

・優れたプロセスと、プロセスを絶えず改良することは、立派な目標である。それらはまだ、ごく自然目標でもある。優れた技術労働者は、指示があろうとなかろうと、それらに焦点を当てる。

形式的プロセス改良プログラムには時間と金がかかる。一つのプロセス改良プログラムのために、プロジェクトが交替することもありうる。生産性の向上が実現したとしても、そのプログラムを受け入れたプロジェクトプロセス改良の為に費やされた時間相殺できる可能性は低い。

プロセスは、注意深く選んだ一つの手順改良によって、その変更に投資した時間と金に報いるだけの利益を期待できることがある。

プロジェクトの期間中に二つ以上の手順改良に順応することは、現実には期待できない。複数技能改良プログラム(たとえば、全般的CM等級の引き上げ)は、プログラム実施しなかった場合に比べ、プロジェクトの完成を遅らせる可能性が非常に高い。

標準的プロセス危険な点は、人々が賢明な省略を行う機会を失わせることである特に人員過剰のプロジェクト場合標準的プロセスによって全員に行き渡るだけの仕事(役に立とうが立つまいが)が発生するなら、標準的プロセスが厳密に守られてしまう。

仕事のやり方を変える

デバッグ時間を大幅に減らさなければ、プロジェクトの成績を通常より大幅に高める方法はない。

・優れたプロジェクトは、デバッグに費やす時間割合はるかに低い。

・優れたプロジェクトは、設計に費やす時間割合はるかに高い。

相手を好きになり、気遣わなければ、人に違うことをさせることはできない。相手を変えるには、相手の考えていることとその理由理解し、尊重しなければならない。

プレッシャー効果

プレッシャーをかけても思考は速くならない。

残業時間を増やすのは、生産性を落とす方法である

一時的プレッシャー残業は、人々の商店を定め、その仕事重要であるという認識を高めるには有効方法かもしれないが、プレッシャーをかけすぎると、かならず失敗する。

管理者がプレッシャーを使うことが多いのは、ほかになにをすればいいのかわからいから、または、ほかの方法の難しさにひるんでいるかである

・おそるべき推測:プレッシャー残業を使うほんとうの理由は、プロジェクトが失敗したときごまかすためかもしれない。

怒れる管理

管理者の怒りと侮辱は伝染する。上の管理者が怒鳴ると、下の管理者も同じような行動をとる(虐待された子供自分の子供を虐待するようになるのと同じ)

管理者が部下を侮辱すると、それが刺激となって部下は自分仕事にされに力を注ぐと思われている。これが、「飴とムチ」式管理で最もよく使われる「ムチ」であるしかし、侮辱によってだれかの業績がよくなるという証拠はあるのか。

管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである

あいまい仕様書

仕様書あいまいなのはシステム利害関係者の間で対立解決されていないしるである

・入出力の完全なリストのない仕様書は、見込みなしである使用を明確にする最初の一歩にもならない。

仕様書がお粗末だとはだれも言わない。自分のほうが悪いのだと思い込みがちである

対立

・開発に複数当事者が関わっている限り、利害の対立は避けられない。

システムの構築と導入の事業には、特に対立が多い。

システム開発組織ほとんどは、対立解決能力に乏しい。

対立尊重すべきである対立プロらしくない行動のしるしではない。

・全員の勝利条件を尊重することをあらかじめ宣言しておく。あらゆるレベル勝利条件を引き出すようにする。

交渉は難しい。仲裁簡単だ。

勝利条件が相容れないか、または部分的に相容れない場合でも、関係者が対立解決の為に仲裁に移行するように、あらかじめ準備しておく。

・注意:われわれは味方どうしである。敵は問題のものだ。

触媒役割

触媒のような人格というものがある。そのような人は、チームがまとまって結束し、なおかつ健全性と生産性を維持できるようにすることでプロジェクトに貢献する。触媒がほかになにもしなかったとしても(通常はほかにもいろんなことをするが)、触媒役割重要で貴重である

仲裁は、触媒役割特殊なケースである仲裁わずかな投資学習できる。

・「あなたたちの仲裁をさせてもらえますか」というささやか儀式の開始が、対立解決本質的な第一歩になることがある。

人為的ミス

・致命的なのは知らないことではない……知っているつもりで、実は知らない何かだ。

スタッフの人数

・初期に人数が多すぎると、プロジェクト重要設計作業を省略せざるをえない(全員に仕事を与えるため)。設計が完成する前に大勢仕事を割り当てると、人や作業グループの間のインタフェースを最小化できない。

・このため、相互依存性が高まり会議が増え、やり直しが増え、フラストレーションたまる

理想の人数配分は、プロジェクト期間の大部分を少人数のコア・チームで行い、プロジェクトの終盤(プロジェクト期間の最後の6分の1ぐらい)に人数を大幅に増やすというものである

・おそるべき推察:無茶なスケジュールを達成するように決められたプロジェクトは、妥当スケジュールで開始されたプロジェクトに比べ、完成までに時間がかかると思われる。

プロジェクト社会学

会議は、重要ではない人物が出席しなくても心配のないように、小さくする必要がある。欠席者が安心するための最も簡単方法は、議事予定表を発行し、それに厳密に従うことである

プロジェクトには儀式必要である儀式は、小規模な会議や無欠点運動など、プロジェクト目標理想に目を向けるために使う。

罵倒などの怒りから人々を守るために手を打つ。

・注意:怒りは恐怖である。部下に対して罵倒などの怒りの行動をとる管理者は、ほとんどの場合、怖いからそうしているのである

考察:怒りが恐怖であることをすべての人が理解すれば、怒りは、怒っている人が怖がっていることを明確に示すシグナルとなるだろう。起こっている人は、恐怖を表に出したくない。つまり、怒りが恐怖の表れだとみなにわかってしまったら、怒りを吐き出すこともできなくなる(これは怒っている人の問題解決できないが、ほかの人の悩みは軽減できるだろう)。

病んだ政治(再び)

・病んだ政治を下から治療することはできない。むだな努力時間を浪費したり、自分立場危険さら必要はない。

問題自然解決するか、行動するチャンスが来るのを待つしかない場合もある。

奇跡が起こることもある(だが、あてにしてはいけない)。

倹約精神

倹約精神とは、失敗した企業の中で、その失敗の責任者が作った公式である

・それは、組織自然目標である繁栄福祉精神とは正反対である

・「倹約精神」という言葉を聞いたら、その本当の意味である「失敗と恐怖」に置き換えるといい。

急進的な常識

プロジェクトには目標と予想の両方が必要だ。この二つはちがっていて当然である

  • ・適切な人材を雇用する。 日本の会社は現場に人事権がないのでこれがまずムズいよね。出来てもそれを活かせる組織になっていなかったり。

    • 現場に人事権がない これほんっっっっっっっとにそうだよね。 会社で起こるほとんどの問題ってもうこれに尽きるんじゃないかっていうくらい。

      • 現場に人事権なんか与えられるわけ無いだろ。 それは組織崩壊を意味する。 使えない兵隊を死なない程度にうまく使って結果を出すんだよ。 使われる側にはわからんのだろうけど。 ...

        • 確かに現場に人事権与えるなら管理職とか経営陣の役割って何だ?ってことになるよな。同じ会社としてやる必要もない。社員が自営業で業務請負とかやってけばいいってことになる。...

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん