大鳴です。
先日のデブサミ2004でのデマルコ講演、
某メーリングリストでの無料招待券に当選して参加してきました。
# それならそっちに投稿するのが筋ですよね・・・。
メモの羅列ですけどレポートをお送りします。
間違い・不足・不明瞭などのご指摘いただけるととてもありがたいです。
# 図(figure_1〜figure_4)を添付しているのですが
# メーリングリスト的にOKでしたっけ?
----------------------------------------
＜ルールの変化＞
・ソフトウェア産業において、数年前の仕事の仕方ではもはや不充分。
今変わってきていることは何か？
・仕事のスピード・効率への要求: Faster! Faster! Faster!
・仕事の条件の厳しさ: Harder! Harder! Harder!
・品質の重要性---増しているはず・・・本当に？:
Quality matters more (less) than ever.
・人口動態の問題: The demographics are killing us.
＜スピードについて＞
・コンサルタントとして顧客の会社の話を聞くと、
きまって次の2つのことが問題として挙がる。
・仕事のスピードが遅いこと
・変化できないこと
→実は一方が他方の原因になっている。
・スピードを上げるには組織が変化する必要がある。
問題は、本当に変化するつもりがあるのかどうかということ。
・変化することができない組織の特徴:
・最適化のしすぎ/効率の高めすぎ
・・・効率を上げ最適化すればするほど変化できない。
＜例＞
キリン
(長くなりすぎた首のせいで地面のものを食べることはもうできない)
・変化への恐れ
・・・変化するということは、
それまでの知識を放棄して初心者に戻ることを意味する。
恐れが多いほど変化できない。
・超多忙
・・・変化には時間がかかる。
忙しいことは変化しない言い訳にも利用される。
忙しいほど変化できない。
・「ゆとり」の必要性: No slack, no change.
効率化を進めると変化することができない。変化にはゆとりが必要。
「ゆとり(slack)」とは:
変化を可能にする自由度の度合い。
時間的なもの、予算的なもの、人員、オフィスの空間、
あらゆる意味において。
＜例＞
+-+-+-+
|7|1|6|
+-+-+-+
|4|8|3|
+-+-+-+
|2|5| |←ここは空き
+-+-+-+
1マスの空きを使い、1から8の数字が書かれたコマをスライドして
順番に並べ替える遊び。
これはスペースの効率という観点から見直してみるととても非効率的。
そこで・・・
+-+-+-+
|7|1|6|
+-+-+-+
|4|8|3|
+-+-+-+
|2|5|9|←9を埋めてみた
+-+-+-+
とすることで使っているスペースは11%も効率アップした!!
しかしその代償として、一切コマを動かせない、
つまり変化できなくなってしまった・・・。
・しかし、スピードを上げたいのにゆとりを持たせていては
遅くなってしまうのではないか？
→そんなことはない。ゆとりで速さを得ることができる。
＜例＞
4人の作業者が書類を順に処理していくことを考える。
―□→Hans ―□→Helga→
｜ ↑
□ ―□―／
↓／
―□→Georg―□→Ralph→
各作業者の手前の箱は
処理されることを待っている書類置き場(inbox)である。
4人の作業者の実際の労働時間を誰かが計ってみたとする。
すると、それぞれ100%には満たないことが分かった。
(Hansは70%でRalphは50%で・・・等)
Ralphをクビにしてその作業を残った3人に割り当てると
ちょうど3人が労働効率100%になったとする。
これで、効率という意味ではすばらしい状態になった!!
ここでinboxの様子がどうなっているかを考えてみる。
作業者のアイドル時間中 = その人のinboxは空
なので、今やアイドル時間がないということは、
各書類がinboxに留まる時間が以前より長くなっていることになる。
つまり、仕事が終わるのを待つ顧客から見ると、
全体としてのスピードは落ちていることになる。
＜例＞
病院においても、作業効率を高めすぎた結果、
健康診断にかかる時間が以前よりすっかり長くなってしまった。
・Bill Gatesの言葉:
「以前は最も適応できる者が生き残ったが、今は最も速い者が生き残る。」
・というわけで、DeMarcoの"Agility Principle":
"Business is not the same as busy-ness."
(ビジネスとは忙しいということとは違う。)
偉大な企業は忙しくしていない。
・ゆとりについては1冊の本を書いている。
Ton DeMarco「ゆとりの法則 誰も書かなかったプロジェクト管理の誤解」
伊豆原 弓・訳 日経BP ISBN: 4822281116
http://www.amazon.co.jp/exec/obidos/ASIN/4822281116/
・ゆとりのなさが組織のスピードを落としてしまうことを別な観点から。
それは、「優先順位のつけ方」について。
・優先順位をつける際の最も一般的なアプローチは・・・
・各プロジェクトには優先順位が与えられる。
「高」「中」「低」といったように。
・すべてのプロジェクトは優先順位「高」に設定される。
・新しいリソースを追加することなく新しいプロジェクトが追加される。
・このとき何が起きるかをPrio Diagram
(http://www.access.ch/imczuerich/systemprio.html)
で見てみる。(# このリンクはもう無効みたいですが・・・)
・自分が担当するproject5は
時間経過に対してこれだけのリソースが必要(figure_1)。
・これを含め組織全体では
これだけのプロジェクトが計画されている(figure_2)。
・しかし、管理者はここへこのようなプロジェクトを
どうしても追加したい!!(figure_3)
・リソースはそのままで追加した結果、全体ではこのようになり(figure_4)、
それぞれの終了期日は遅くなってしまった・・・。
・優先順位のつけ方は、本当はこうするべき("Priority Principle"):
・本当に順位をつける
(優先順位1のものは1つ、2のものも1つ、・・・というように)。
・優先順位順に人を割り当てる。
・プロジェクトはやるべきであるといえるまでやらない。
大人になることを学ぶ!
・Tim Lister(DeMarcoのビジネスパートナーでもある)の言葉:
「プロセスについて語られているのを聞くといつも、
それらがすべて間違っていると思う。
われわれに必要なものは
プロジェクトを行うためのよく考え設計されたプロセスなどではなく、
そもそもどのプロジェクトを行うかを決めるプロセスの方だ。」
・ここで少し「プロセス」について。
プロセスの世界でも変化が起きている。
この25年来プロセスは重くなり続けてきたが、
その反動として最近「軽い」(thin, light)方法論が登場してきた。
・XP (eXtreme Programming)
・Crystal Methods
・S.C.R.U.M.
・Dymanic System Development Methodology
・スピードを上げたいのであればプロセスを重くしてはいけない。
つまり、すべきことを加えるのではなく、省かなくてはならない。
＜ちょっと脱線＞
分厚い仕様書の山という事態を打開するために、
図を利用した仕様書の書き方について本を著したことがある。
それを使ってくれたある組織では、
その新しいやり方で作った仕様書のほか、
旧来の分厚い仕様書も一方で作っていた。
(DeMarcoの本当の意図は理解されていなかった・・・。)
・歴史を振り返ると、軍事の世界でも同じような「ふれ」が起きている
(「鎧」と「機動性」のふれ)。
鎧の時代→騎馬隊の時代→戦車の発明→マジノ線→・・・
"Your former process is your armor."
・「軽量」プロセスの例: XP
Kent Beck
「XPエクストリーム・プログラミング入門 ソフトウェア開発の究極の手法」
長瀬 嘉秀・監訳/永田 渉、飯塚麻理香・訳 ピアソン・エデュケーション
ISBN: 489471275X
http://www.amazon.co.jp/exec/obidos/ASIN/489471275X/
これを知ることで、次にどう変化するか(何を省くか)を学ぶことができる。
＜厳しさについて＞
・今日われわれの構築しようとしているシステムには次のような特徴がある:
・より多くの利害当事者
・より多くの衝突
・より短いスケジュール
・より低い予算
・より高い可視性(目立つこと)
・より高いリスク
厳しくなってきているわけは、
簡単なものはもうずっとまえに作ってしまったからである!
・「衝突」について少し。
ソフトウェアというのはそれ自体何かの方法を変えるものである。
つまり、開発者はその変化の最先端にいることになる。
このとき、以前のやり方をしていた人と
そのソフトウェアを使って新しいやり方をしようとしている人の
両方の協力が必要となる。
しかし、ここに衝突が起きることは必至!
つまり、ソフトウェア構築というのはそもそも
「衝突-集約」的(conflict-intensive)である。
だから、(コーディングだとかテスティングだとかのスキルだけではなく)
そうした衝突の解決スキルというのはとても重要で、
この産業には不可欠なものといえる。
そうしたスキルをもっと評価すべき。
＜人口動態について＞
・これまで、IT産業の労働力には次のような供給源があった:
・ベビーブーム
・女性の職場進出
・戦後の教育レベルの向上
・しかしこれらの供給源はもう枯渇しており、
IT労働者の平均年齢はだんだん上がってきている。
・Bruce Taylor(KM World出版社)の言葉:
「われわれはもうこれほどの知識労働者を得ることはないかもしれない。」
・今は経済が停滞しているためにそれほどはっきりしないが、
経済が活性化すればこの問題が表面化すると思われる。
＜品質について＞
・現在、「品質」といえば「欠陥率の低さ」で見るのが普通となっている。
つまり、
・欠陥が少ない = 品質が高い
・欠陥が多い = 品質が低い
・しかし、これについてもっと違った見方をしてみよう。
＜例＞
Microsoft Internet Explorer
このソフトウェアは「Internet Exploder」(explodeは「爆発する」の意)と
揶揄されるほどに欠陥が多い。
しかし、とても多くの人がそれを使い続けている。
「だって、便利だもの!!」
このソフトウェアはそれだけ世界を便利にした、世界を変えてしまったのであ
る。
＜例＞
Adobe Photoshop
DeMarcoが認定する世界最高品質のソフトウェアはこれである。
このソフトウェアは、
法的な証拠能力という点でも、個人の思い出作りという点でも、
「写真」というものの性格をまったく変えてしまった。
世界を変えてしまったのである。
(Kodak社はこのことを理解しておらず、コスト削減の最適化を目指してしまい、
変化できなくなってしまった。)
・世界を変えてしまうようなソフトウェアが品質の高いソフトウェアである。
それは、開発者にしてみれば
「こういうものを作ってみたい!」と思うようなソフトウェアである。
＜まとめ＞
・以上のことから、この新しい時代のための処方箋として:
・より効率を落とそう。
・プロセスを軽くしよう。
・優先順位のつけ方を学ぼう。
・プロジェクトの選択は賢く行おう。
いかに構築するかよりも何を構築しないかを決めることの方が大切である。
・人的資産にもっと投資しよう。
・デス・マーチになっているプロジェクトは、
相対的にみてそもそもやる必要のないものがほとんどである。
・'80年代までアメリカ人は日本人を恐れていた。
高い効率、規律、品質、教育などを持っていたから。
しかし、日本人がアメリカ人を経済的に超えることはできなかった。
それは、今回話したようにルールが変わってしまったからだった。
つまり、今や必要なのは変化の能力なのである。
＜最後に＞
・「ゆとりの法則」を書いてから、
"Driven-by-clock is a mistake"ということに気づいた。
完全に忙しい一日というのは、成長のない一日ということである。
「ゆとり」に気づいてからは、
もっと自分の成長に力を注がなければならないと思うようになった。
・組織がその構成員に個人的成長の機会を与えないというのは
給料を与えないというのと同じくらい重大で、
そういう組織からは結局人は離れていくだろう。
その際、「効率」はそうした個人的成長の敵であり、
個人的成長は企業にとっても必要なものである。
＜質疑応答＞
・「何が必要か」をどう決めたらいいのか？
→構築するものの数を減らそう。
つまり、ドメインをより狭めるべき。
外部へ安く委託するようなものは、はじめから作る必要のないものである。
・会社全体にゆとりを持たせるのではなく、
一部にゆとりを持たせて残りには効率を求める、という方法はどうか？
→全体に効率を求める、という方法よりはましだろう。
しかし、頭脳労働者に個人的成長の機会を与えないというのは
間違っていると思う。
・TOCとの関係
→Goldratt氏は効率の専門家であり、
著書「ザ・ゴール」はすばらしい著作だと思う。
そこではゆとりをマネージメント側に集中させるべき、
という考えが示されている。
しかし、「ザ・ゴール」は工場での話であって、
知識労働者にこの方法を適用するのは問題があると思う。
・若者が夢を持たなくなってきているが、どう夢を伝えたらいいか？
→かつてのような終身雇用制は'90年代に崩れてしまったため、
今の若者の親の世代がIT産業に敵対意識を持っている傾向はある。
しかし、IT産業は
・本質的に魅力的な仕事
・ほかの産業では見られないようなチームワークのあり方をもつ
という特徴を持っている。
----------------------------------------
大鳴