佃さん、上手＠データ通信システムです。
ちょっとコメントさせて下さい。
On Thu, 18 May 2000 09:32:27 +0900
佃 軍治 <tsukuda@....jp> wrote:
>
> 佃です。
>
> ２４章の抄訳を送付します。
> 意訳している箇所がかなりあります。
> 間違いの指摘、コメントなど、お願いします。
>
>
> Chapter 24 What Makes XP Hard
>
> ＜私の思い込みによるまとめ＞
> ＸＰの適用を困難にしている要因を感情とプロセスの２つの側面
> から説明している。
> ・ 感情
> 人に聞けない（技術者として誇りが高い、知らないことがあること
> は恥）、人と協調しない（自分の技術力をアピールしたい）、難し
> いことをやりたい（これも自分の技術力をアピール）
>
> ・プロセス
> 軌道修正の方法(driving project)が企業文化に受け入れない。
>
> つまり、ＸＰを成功させるためには、これらの問題に対処しなけ
> ればならない。
> 感情面では、「みんなと協調し、協力すれば、生産性が高くなる
> こと、プロジェクトが成功すれば個人の評価も上がること、個人の
> 技術力をいくらアピールしてもプロジェクトが失敗すればその個人
> の技術は生かされてなく個人は評価されないこと、を十分に理解し
> てもらう。」ということが重要になるでしょう。
> プロセス面では、軌道修正プロセスをいかに上に理解してもらう
> かが重要でしょう。
> 感情面においては、アメリカよりも日本の方が障壁は少ないので
> はないだろうか？日本ではアメリカほど個人が自分の技術力をアピ
> ールせず、組織として成果を上げようとするので。
>
> ＜タイトル直下の要約部分の全訳＞
> 個々のプラクティスはブルーカラーのプログラマでも実行できる
> が、すべてを一緒に利用し、その状態を保つことは困難である。Ｘ
> Ｐを困難にしているものは、主に感情、特に不安である。
hard は＊難しい＊位の訳でどうでしょうか？困難だと強すぎる感じが
します。章全体があてはまります。
>
> ＜本文の抄訳＞
> ＸＰのプラクティスは簡単である。ＸＰプロジェクトで貢献する
XP is simple, but it isn't easy? とあるので、＊簡単＊よりも
＊シンプル＊とか＊単純＊の方が良いのでは？
> ために博士号を取得する必要はない。しかしそれを一緒にバランス
> よく用いることは困難である。プラクティスはお互いにサポートし
> ている（ｐ７０の図４に関連図あり）が 、バランスを失わせる多
> くの要因（問題、不安、イベント、間違い）がある。
> 必要以上に恐れないで欲しい。ＸＰを実践した多くのグループが
> ある。
> XPを困難にする多くの要因は以下のようなものである。
> 単純なことにすることは困難である。しかし、あなたがより単純
> になることを考え付かなくなるまで、複雑さに満足してはならな
> い。
ちょっとわかりにくいので、原文直訳します。参考にして下さい。
何か複雑なモノが機能していたらそれに感心するかわりに、複雑なこと
に満足しないで、もっとシンプルで同じに機能するモノを思いつかなく
なるまで休息しないことを学ばなければならない。
> 知らないことを認めるのは困難である。しかし、開発を迅速に進
これもわかりにくいので・・下のような流れです。
自分が”知らない”ということを認めるのは難しい。でも、XPを採用
することでチャレンジになる、xpはあなたが学び続けるのと同じ早さ
でしか開発が進まない。人に聞くのも恥ずかしいが・・・
＃＜私の思い込みによるまとめ＞に全部書いてありました。後から読
＃んだので。まあ、書いたのでこのまま残します。
> めるためには、顧客やパートナーに要件や技術を良く聞く必要があ
> る。
> 協調することは困難である。学校教育や会社では個人で考えるこ
> とを奨励している。しかしＸＰではお互いにインタラクトし、新し
> いスキルを学ばなければならない。
> 感情的な壁を取り除くことは困難である。ＸＰのスムーズな運用
> は、感情のスムーズな表現に依存する。
>
> XPは多くのバリエーションを許容できるが、小さな変更が大きな
> 問題になる場合もある。例えば、１．タスクの割り当て ２．担当
これは逆だと思います。
＊小さな問題が巨大な効果をあげることもある＊
> 者によるタスクの評価 ３．誰かの負荷が高ければ再調整 というプ
> ロセスを、１．タスクの評価 ２．タスクの割り当て に変更した場
> 合、各担当者はイテレーション開発の度に、どうやって期間内に開
> 発すればよいのかを最初の１，２日考えなければならない。これは
> プログラマにとって最も生産性の高い状態ではない。
流れが混乱しています。＊変更した場合＊でなく、＊変更前はこういう
問題があったので、こう変更した＊だと思います。
この話は、Ｃ３プロジェクトで見積の問題が発生して、各イテレーシ
ョンで１つか２つのstoryが毎回未達になるのを解決した、という内容
です。
従来のルール
１ 登録（引き受け：sign up)
２ 自分のタスクの見積
３ 誰かオーバコミットなら再調整
チームは３番目の手続きを避けたがったので新ルールに変えた。
１ 全体としてのタスクの見積
２ タスクの登録（引き受け）
（従来手法の）問題は、引き受けた人がタスクの見積を持っていない
ことだった。次の日になって”なんでこれが３日でできるんだ？ 何
がはいってるかもわからなかった”なんて言って来る。これで１日か
２日失ってしまう。
> これは、ＸＰを我々が言うように正確に用いるべきである、と述
> べているのではない。あなたたち独自のプロセスについては、あな
ちょっとニュアンスを変えた方が良いと思います。
全てをを我々が言う通り正確にやるべきだと言っている訳ではない。
＊そんなことをしたら、ひどい結果になる＊
という感じです。
> たが責任を受け入れるべきである。しかしこれがＸＰを困難にして
> いる。
> 一度にちょっとだけハンドルを操作（軌道修正）する「driving
> project」は、多くの組織で一般に行われている「car-pointing」
Driving project はこんな訳にしたらどうでしょう。
・・操作することでプロジェクトを運営するのは、多くの組織・・
（では）
> （最初に決めた通りに実施）の比喩に反する。ＸＰを困難にする最
> 後の要因は、多くの企業文化がハンドル操作（軌道修正）を受け入
> れないことである。会社があなたに、あなた自身が選択したプロセ
> スに反するようなことを求めたとき、あなたには勇気が必要になる
> でしょう。
>
> --
> 佃 軍治 tsukuda@....jp
> 日立製作所システム開発研究所第２部
>