トム・デマルコ講演の個人的メモ　04/01/29

〜ゆとりの法則　アジャイルな組織のシークレット〜

講演の時に私が取ったメモです。取り急ぎそのまま掲載します（笑）。

この時点で既に私の意見も混入されていますので、正確に表記したものでは ありません。その点ご了承を。表記もロクに見直してませんし HTMLレイアウト的にもムチャクチャですがそんなこた百も承知だガマンして読め（開き直りかよ＞俺）。

現在求められているもの

→ルールが変化したため（Change Rules)→効率よく！

挙句の果てには「忙しさ自慢」すら行われるようになってしまった
More busy,Very busy! No! More I!

→変動要因として
　・上司
　・ＩＴ動向、スピード
　　→要求は激しくなる一方

→でもそれで本当にいいの？

経営者／管理者としての命題
　→「より早く動くためには？」
　　　→でも実際に変われるの？

　変わるためには２つの問題がたちはだかっている

↑これらは相互影響を与えている
　　　　　　　　　↑過剰最適化
　　　　　　　　　↑効率が良すぎる
　　　　　　　　　結果、変化すること自体に苦痛を感じる。

　これらは企業が特化し過ぎることによって発生
　（byフィッシャー「抜本的定義」
　ex.キリン（地面に落ちている草が食べられない）

　変化への恐れ
　　・同僚が既に退職している
　　　→自分も同じ目に遭うかもしれない→失業への恐れ
　　・ルーチンワークの過度なスピード追求

　　　結果、変化を望まないようになってしまう
　　　→自己否定、初心者返りへの恐れ

　　・変化を恐れる←→忙し過ぎる
　　　　　　　　　　　　・変化する時間がない、という言い訳になってしまう

　でも実際にはどちらかを嫌が上にでも選ばなければならない
　　→変化する？
　　→変化しない？

　数並べゲームのたとえ（ゆとりの法則p.11）

　９ピース埋まってしまったゲーム＝改善しすぎた企業
　　　（早く走るけど曲がることのできない車と一緒）

　本来空いているべき１ピース＝ゆとり（Slack）
　Slack =　変化を引き起こすための自由度
　　　　　　→人
　　　　　　→時間
　　　　　　→費用
　　　　　　→床面積、etc いろんなものへと変化する。

★俊敏性の法則（The Agility Principle)

　なぜゆとりが必要なのか？

　→俊敏性（Agile）への対応を可能にするため

　誤解を解いておきたいこと

　Fast V.S. Slackの対立関係で考えてはいけない
　SlackによってFastを促進する方向性で考える必要がある

　その例：（byゆとりの法則p.32を改変）

　（１）→（３）→
　　↓　　　↑
　（２）→→↓
　　　　　（４）→

（４）の効率が一番悪く、（１）〜（３）もそれぞれ待ち時間があったので、（４）をクビにして、（１）〜（３）で（４）の仕事をするようになりました。
その結果、（１）〜（３）のはほぼ１００％仕事するようになりました。 しかも給料は１人分減らせましたバンザーイ。

　→これは効率化ですか？→答え：Ｎｏ．

理由：スピードが落ちるから。
（１）〜（３）が複数のタスクに関わることにより、タスクを こなすための待ち時間（しかかり）が以前より増加してしまった。したがって、個々の部分では効率的にみえても、全体から見ればスピードが遅くなったようにしか見えない。
→これは効率化か？

　→組織の効率化がかえってスピードを落とす結果になっている

ex. 病院
昔：医者が来るまで９０分
今：医者が来るまで６０分、看護婦が来るまで６０分、
　　　検査の結果を知るのに６０分
　　　でも医者も看護婦も以前より忙しい

優先順位（Priorization）の設定方法

　→既に分類は機能していない
　　　　→子供のやり方、と表現

　そんなことやってるとどうなるか→全部やるに決まってる

　→こうなっちゃう例

　（図１）単独のプロジェクト

　（図２）すべてのプロジェクト
　　　　　＊粘土のように積み上げられる

そこにさらにもういっこ。これもプライオリティ「高」だからやらざるをえなくなる。もちろん人員の追加なんかもってのほか

　となると、こうなる！

　　（図３）

　　結果：すべてのプロジェクトが右に移動→全プロジェクトが遅延を起こす

という訳で、こんな子供のやり方はもうやめましょう。
これからはオトナのやりかたっすよ、オ・ト・ナ。

　設定の規律（Priority discipline）

　→これも「変化」

　"WORDS OF WISDOM FROM TIM LISTER."
　プロセスという言葉はすべて間違っている。（要和訳）

　どのプロジェクトをやるか／やらないかを決断することの方が重要！！

開発プロセスに対する抜本的変化

軽量プロセスの登場（XP/SCRAM/クリスタルetc)
　→重量化プロセスへの反発
　　　＊プロセスを追加したところでスピードは上がらない！
　　　　そんなプロセスいらねー！

ex. 1976年頃、構造化ドキュメント／図表化を推進していた時、コンサルの相手はこれまでの従来のプロセスを捨てようとしなかった。
結果、これまでの従来プロセスでの成果物と、構造化Docの成果物の 両方を作ってしまた→当然スピードはボロボロ

　＊教訓：「かつてのやり方」を蒸し返すな！窓から投げ捨てろ！

軽量化プロセスが出てきた時代的背景
→軍の進化形態に共通点を見出せる
かつては鎧の強度さが重要された、しかしその後騎馬隊の登場によりスピード重視に変化。
その後戦車の登場により盛り返すも、戦闘機によって再びスピード重視。
→同じようなことが開発プロセスにも言える。

プロセス＝鎧
スピード＝騎馬隊
　動きが早い方がいい、という価値観に変化している

＊実現するための一手段としてのXP(Kent Beck)。
→今までのやり方にこだわる人には嫌悪感があるかもしれない。
が、これからの価値観に応えるためには必要な知識がここにある、と
ご推薦の言葉（笑）。

最近のシステム開発は難しくなっている(HARDER...)

　１：システム開発自体が目立つものであり、それ自体が高リスク
　Ｑ：なんでこうなっちゃったの？
　Ａ：簡単なものはもう全部作っちゃったもーん。あとは難しいのしか残ってないもーん。

　２：ソフトウェアとは変化をもたらすことである。
　　そしてその変化に対してその開発者は必ず矢面に立たされる。
　　変化が起こる以上、必ずそのシステムによって勝つ者、負ける者が現れる。
　　でも厄介なことに、開発者は勝者／敗者共に味方につけなければならない。

→これらのことから、従来の開発能力（テストやデザイン、マネジメント含む）に加え、対立への対応スキルを持つことが、現在の開発者に求められるスキルである。

→これもまた、人材に対して求められる「変化」

人望的な変化（THE DEMOGRAPHICS...)

ソフトウェア産業は、かつて０だったものが、いまでは巨大産業。３５００億ドル以上の資金（＝賃金）が動いている。しかし、なんでここまで巨大になることができたのか？（そこまで大きくなるまで人が増えることができたのか？）

　↑良い側面
　↓悪い側面

現在では

→結果、単純な数計算で考えても若い人が流入してこない
→（さらにはIT業界に対するネガティブイメージの先行（Q&Aにて追記））
→どんどん若い人が入ってこなくなる

かつては平均22歳程度だったソフトウェアハウス従業員の平均年齢が、今では50歳前後にまではねあがっているケースもある
　（hiroK注：アメリカならではの傾向もあるかも？）

　結果今後予測される悲観的予想：
　今後ITワーカーを見ることはできないかもしれない
　（We may never have enough knowledge workers again.)

現状：クライアントの某ソフトウェアハウスはもうおっちゃんばかり。
そんな風景を見てなおさら若い人は「こんなところ行かなくていいや」 と思ってしまう。
→20XXには今いる人も定年迎えて、従業員がいなくなっちゃう

品質（Quality...)に対する考え方の変化

　厳しくなってきている、でも本当にそうなの？見方を変えてみよう。

・現在の価値観
　　悲劇的な欠陥があるソフトウェアは低品質のソフトウェア
　　　　欠陥率低い＝品質高い、という認識。

・・・でもさ？みんな使ってるでしょ？MicrosoftのIE（場内爆笑）。よく落ちるしウイルスまがいの動きするし。それでもみんな使ってる。
なぜ？→結局便利だからじゃない？＋世界が変わるほどのインパクトがあったからじゃない？

インパクトに比べたら実は欠陥なんかどうでもよくなってしまうという考え方はできませんかね？
　→品質と利便性、実は無関係と考えることができる

　デマルコ氏にとっての「もっとも美しいソフトウェア：」
　　→PhotoShop
　　　　・これによって写真に対する考え方が変わった
　　　　・それに比べたら多少欠陥があろうがどうでもいい
　　　　　（by「ゆとりの法則」p.125）

　でもその一方でこれに対立する考え方をしたところもある。
　　→米コダック社。コスト削減に異常な執念を燃やすも、結局は日の目を見ず
　　　低迷を続けている。PhotoShopの考え方に見向きもしなければ
　　　製品に対して新しい提案をすることもなかった。
　　　→コスト削減思想がもはや時代遅れになっていることの表れ

まとめ（Prescription for a new era)：これからの提案

・効率を追求しない、少し遅らせる（＝ゆとりを与える）
・変わらなければならない。
　　効率よりも俊敏性（Agile)を求めよ。

＊かつて日本は効率／品質／勤勉さで恐れられていた。
　今でも効率／品質／勤勉さでは日本の方がずっと優れている。
　しかし経済の結果だけはいまだにアメリカの方が上。
　（1980年時にデマルコ氏が通産省の役人と面談した際、
　　役人に「2000年までに経済でアメリカを抜く」と予言されるも、
　　見事なまでに大ハズレ）
　これは日本が、俊敏性への転換ができなかったからではないか？
　1990年以降、急激に「方向転換できる能力」が問われるようになったことの表れ

・忙しさは味方ではない
　　→忙しいということはAgileではない
　　　現時点で抱えているプロセスは既に重すぎる
　　　　・何を省くか／軽くするかの視点
　　　　・優先順位（＝オトナのやり方）
　　　　の確立が必要

・役に立つプロダクトを選択せよ／それ以外は捨てる

　「デスマーチプロジェクト」はなぜ発生する？
　本来必要であれば、確実に完成できる期間／費用が与えられて然るべき。
　　　　　　　　　　　　　　　　　　（by.「熊とワルツを」p.192）
　それが無いということは、作らせる側が「時間をかける価値も無い」プロジェクトと 　みなしているということ。
　完成させるための時間を与えるか、クズとみなして捨てるかの決断が必要。

・「やること」＜「やらないこと」
　やらないことの決断の方が重要。

・人的資材への投資／ITWorkerの確保が必要

　→いずれも変化を伴う。
　　でもこれができなければ、いずれは消えてなくなる運命を辿るでしょう。

・ゆとりの考え方

　この考えが絶対的に正しいかどうかには私には言いきれない。
　しかし私にとってはこの考え方は既に身に染みついている。
　→「ゆとりの法則」は書いた後、自分で３０回読みなおした（マジかよ！by.hiroK）

　完全に忙しいということは、成長の機会が無いに同じ。
　自分自身はもちろん、自分が部下を持っているのならその部下に対しても
　同じことが言える。
　個人にチャンスを与えないのは、給料を支払わないのと同じ行為。
　　　　　　　　　　　　　　　　　　　　　　　　（byゆとりの法則p.36）

　デマルコ氏は「ゆとりの法則」脱稿後、コンピュータにもビジネスにも
全く関係のない小説「DARK HARBOP」を書き上げた。
これは氏自身が「１年かけて失敗の可能性のあることができた」という意味で 自分自身を評価している。→各個人個人が（皆が小説を書く必要は無いにしても）こうゆう成長のチャンスをつかむことが重要なのではないでしょうか。

「やらなければならない」×　→　変化　→　「自ら成長する」○
　　　↑
　　　効率の追求×

質疑応答：

Ｑ：ゆとりを持て、言うのはわかったけど、結局何が必要なの？
Ａ：これはパラドックスである。
　　何が必要か、ではない。「何が不必要か」を考えて欲しい。
　　（ナイス切り返し(笑)）

Ｑ：全社ではなく、組織（部課）単位でゆとりを振り分ける、
　　（ある部課は効率優先、ある部課はゆとり優先）
　　という考え方の方が効率的なような気がするが？
Ａ：戦略的には「Ｙｅｓ」かもしれない。
　　しかし全社的にはゆとりの配分に関して社員に不公平感を与えることになる。
　　平等にゆとりを与えないのは知識労働者にはお勧めできない。

Ｑ：「ザ・ゴール」のTOCの考え方と共通するところが多いが？
Ａ：TOCは「効率の追求」をめざすもの。
　　確かに「ゆとりを集中化し、それをボトルネックの回避にあてる」という
　　言い方をすることもできる。
　　ただし、TOCはあくまで工場等の生産としての考え方であり、知識労働者に
　　これを当てはめるのには無理がある。
　　TOCの場合、ゆとりの所有権／行使権は経営者にあり、
　　個々の作業者は自由にゆとりを使うことができない。これでは
　　知識作業者に関しては成長を望むことはできない。

　　でも実際TOCの考え方はすばらしいと思うので読んでみることを
　　お勧めしますよ（とフォローが入る(笑)）。

Ｑ：ドラッガーについてはどう思われますか？
Ａ：ドラッガーは私のヒーロー。私が彼に追いつくためにはあと最低３０年は 生き続けなきゃいけません（笑）

Ｑ：２００７年問題に対して、今ＩＴ業界に人が入ってこないことが逆にチャンスになるという見方もありますが、これに関してはどう思いますか？
（注：若干質問の意味がわかりませんでした、聞こえたことをそのままメモしてます）
→質問されたご本人がコメントしていました。
Ａ：例えばアメリカではＹ２Ｋも同様にチャンスと言われていた。
しかし実際にはそんなことはなかった。これには「Ｙ２Ｋ以前に仕事をやりすぎたために停滞化してしまったのでは」という意見がある。
ひょっとしたら２００７年問題でも同様のことが起こるかもしれない。
でもその時を待つよりは今動くことの方に力をいれたほうがいいんじゃないかな？

Ｑ：若い人達を再びＩＴ業界にひきつけるためのアイデアが欲しい。
Ａ：例えば、自分の親がITワーカーで、そこで解雇されるなどの経験があった場合、その子供はＩＴに対して嫌悪感を抱くかもしれない。
（これもアメリカならではかなぁ？by.hiroK）

でも心配はしないで欲しい。以下の２つの理由がある。
まずひとつめはシステムを作るという仕事は昔も今も変わらず創造的で 魅力的な仕事であるということ。
ふたつめに、チームワークに関するソフトウェアのアプローチは他のどの仕事よりも ユニークであることが言える。かつてのITワーカーといえば、一匹狼でコミュニケーションが下手、そんな人の方が向いている、と言われていました。しかし今は違う。チームを組んでその中でコミュニケーションを駆使してシステムを組み上げることができる人が向いている。そしてそうゆう人は間違い無くこの仕事に魅力を感じるはずだ。

Ｔｏｐ