山根です。
長文になったので、結論だけ前に持ってきます。
意見の相違は、生い立ちの相違によるんだと思いました。
＃あやふやですが、合意には達しないように思ったので。
濱井さんのおっしゃっていることは正しいし、
理解はできるのですが、私の過去には
残念ながら当てはまりませんでした。
On Tue, 27 Nov 2001 14:59:02 +0900
k-hamai@....com wrote:
> 濱井です。
> 2001/11/20 20:51:51 +0900にe-yamane@....jpさんが送られた
> メールに関する返信です。
>
> >> [XP-jp:02808]でも書いているように、「逆は必ずしも真ならず」
> >> です。「わかりやすいプログラムは行数が多い」は、一時期のBASIC
> >> プログラム等では成り立ちましたが、「行数が多いプログラムは
> >> わかりやすい」が成り立ったことはないと思います。
> >この文、矛盾していると思います。
>
> どこが矛盾しているのでしょう？
濱井さんの文章からは、
・「わかりやすいプログラムは行数が多い」は、
一時期のBASICプログラム等では成り立つ。
・「行数が多いプログラムはわかりやすい」は成り立ったことはない。
という主張しかかかれていません。
そのBASICの一時期では成り立つと言っているのに、
成り立つ場面は無いといっているから矛盾していると
申し上げた次第です。
> 一時期のBASICプログラム等では、速度をかせぐため、1行でも
<snip>
> プログラムもあったわけです。
は、濱井さんがその文章を書いているときに思っていることです。
思っていることが全て相手に伝わるわけではないのですよ。
上記文章を読めば、
同様なことは、アセンブラ→Ｃに転向したプログラマが
多い時期にも同じ動向があったという私の文章と
*ほぼ*同意の内容だと思います。（し、濱井さんの文章も
矛盾しません）
＃私もその後何度か文章を継ぎ足しているので、
＃言葉足らずであったことは事実ですけど。f(^_^;
> >> 変えることが顧客の利益となり、変えさせることは直接的には開発側の
> >> 利益とはならないのですから、「変えてもらう」でもニュアンスが
> >> 強すぎるような気がします。「変えることを助言する」ぐらい
> >> でしょうか。
> >濱井さん的に*あえて言うなら*と言うことでしょうね。
> >矛盾していますよ。（ゲームになりません）
> >もしこの記述が真なのであれば、プログラマから、
> >「変えることを助言する」事も無いと思います。
>
> ＊直接的＊には開発側の利益とはならない、と言っただけで、全く
> 開発側の利益とはならないとは言っていませんが。
予想通りの反応です。f(^_^;
では、濱井さんの考えておられる間接的な利益とはなんでしょう？
直接的な利益がなく、そして直接的な損害もなければ、
そこにアクションはないでしょう。
また、プログラマが、助言できる部分とはどういう事を
お考えでしょう？
多分、この二点が、分かれば濱井さんのおっしゃることが、
お馬鹿な私にも理解できると思います。
私は、
・同等なビジネス価値が提供でき、コストを抑える方策があれば、
その方式を提案してみる。（同等な価値があると判断するのは
当然顧客です）
顧客のメリット：費用対効果が高くなる
プログラマのメリット：余計な物を作らなくて良い
・顧客が要求しているストーリの優先順位がどう考えても、
逆転している時に、
「こっちの方が高くないですか？何故こちらの方に
価値を見出したのですか？」と提案してみる。
（変更と言うより質問に近いですが・・・）
顧客のメリット：優先度の誤りがなくなるor
プログラマの理解が深まる
プログラマのメリット：謎な機能を謎のまま作り込まなくて良い。
（謎な機能は作ってて面白くない）
・見積り結果、顧客が望むリリースプランと、
自社のリソースがマッチしない場合に、
リリースするストーリの削減（次点のストーリーの
コストによってはストーリーの増加はありえます）を
お願いする。
顧客のメリット：無理な実装が行われないため、
適切な設計で適切な品質のストーリを
得られる。
プログラマのメリット：モチベーションがさがらず、
笑ってお仕事できる。;-D
For customerの気持ちが強まる(?)
と言うところでしょうか？
> >> 「オーバーワーク」のことは、この場合関係ないと思います。
> >あの、記事の文面は、「スコープの削減」についてのお話です。
> >私も、「スコープの削減」を主に話を展開していました。
> >＃にょにょるさんも、そう感じ、あのようにかかれた物と推測します。
> >スコープの話をされていて、オーバーワークは関係ない
> >となると、ここの記述自体が無意味な物になり、
> >上で濱井さんがレスされた文も無駄な一文となりませんか？
>
> 「週40時間労働」というプラクティスに忠実であれば、オーバーワーク
> になることはないと思います。現実には、見積もりを誤ってオーバー
> ワークになることもあるでしょうが、それは、「スコープの削減」
> とは、別に議論すべき問題だと思います。
これは、おっしゃる通りだと思います。
が、あの記事では、以下濱井さんが書かれていた
「ある程度まともな顧客」以外にフォーカスを当てていたのだと思います。
そして、「プログラマ」の権利として「スコープの削減を願う」
事を謳っていないウォーターフォールであれば、「お客様は神様です」的
発想で、ごり押しされてきたのでしょう。
＃押し返すための錦の御旗がないからです。
> >> もちろん、顧客の側はできるかぎり支払いを少なくしたいし、
> >> 開発側はできるかぎり利益を多くしたいので、その調整は厄介
> >> ですが、XPにかぎったことではないですから。
> >ですね。ウォーターフォールでも、スコープの決定は難事です。
> >が、予定したコスト以上の物を顧客はごり押ししてはいけない。
> >＃ごり押しすると、最終的に品質が下がる等副次的デメリットが生じるから
> >と言う事をプログラマの権利と明文化しているから、
> >議論の対象になるのでしょう。
>
> 顧客がごり押しすると志気が下がり、ごり押ししなかった場合以下の
> 結果しか得られない、というようなことは、XPでもウォーターフォール
> でも往々にして起きることだと思いますが。「プログラマの権利」
> として明文化されてなくても、ある程度まともな顧客なら、そう無茶は
> 言わないと思います。
この辺のお話を聞く限り、私（と記事を書かれていた人）と
濱井さんの生い立ち(?)にかなり違いがありそうですね。f(^_^;
あんまり、そんなお客さんに会ったことは無いように思います。
＃全く無いわけではありません。
が、最終的にごり押ししていたのは（議論するのがめんどくさくなった）
管理者のようにも思います。
最終的にモチベーションを下げていたのは顧客ではなく、
管理者だったようにも思います。
と言ってしまうと、多分このお話自体意味は無くなって、
全然状況は好転しなくなります。
明言化されない箇所に部分についてどう振舞うかは、
各個人の器量にかかわります。
だから、私や記事を書かれた人または、もっとどん底の人に
光を与えたのがＸＰなんです。
逆を言えば、濱井さんのおられるような良好な環境であれば、
「ＸＰ」という錦の御旗が無くても「プログラマの権利」と
「顧客の権利」が尊重され良好なシステム開発がなされていくんだと
おもいます。
＃でも、ドキュソな管理者はやっぱり頑なに昔の方法論を
＃ごり押しするのでしょうね。(T_T)
> >> ウォーターフォールに比べれば、顧客を大事にしていると思います。
> >> ウォーターフォールで大事にしているのは、顧客ではなく、
> >> ＊要求仕様＊ですから。
> >これでは、ウォーターフォールで仕事している人は
> >人でなし見たいです。(T_T)
>
> 批判しているのは人ではなく手法です。ウォーターフォールで仕事を
> するかぎり、各個人が顧客を大事にしようとしても、手法からくる限界
> があるということです。もちろん、XPにも限界はありますが、ウォーター
> フォールより限界は高いということです。
なるほど。
濱井さんの考えを理解しました。
確かに、私も会社の利益と顧客の利益との間で板ばさみで
悩んでおりました。
> >> >顧客は、大事にしていないと思いますよ。f(^_^;
<sbip>
> >上記観点での、反論が頂きたかったです。
ご意見ありがとうございます。
> 要求仕様の決定に関する、ウォーターフォールとXPとの違いは、
> 最初に決定するか、徐々に決定していくかの違いで、顧客がやるべき
> 作業に大きな差はないと思います。
> 顧客の労力も大差ないと思います。時間的なプレッシャー等の点で、
> むしろ、XPの方が労力が少なくてすむ面すらあります。
この文章を見て、私と濱井さんで意見がずれているところが
分かりました。
濱井さんは、*まともな*顧客、管理者、プログラマと
お仕事をした場合は、顧客の労力は変わらない。
むしろ減るんだ。というお話だと理解しました。
私が言っていたのは、普通もしくはそれ以下の人と
仕事した場合はどうか？
と言うところだと思います。
・仕様の決定には顧客は参画せずに「動けばいいよ」で、
概略や詳細設計フェーズは終え、動作し始めてから、
ここは、あぁでもないこぅでもないと言われる。
・顧客の要求を飲むのが（無理難題であっても）当然でしょう
という風潮に合った。
・とにかく猛烈に残業してでもノルマを達成しろ
と、無理難題のスケジュールを押し付ける管理者。
・プログラムを書くことが仕事（動くかどうかは別問題）
と考えているプログラマ。
等などの場面に立ち会っているからですね。
上でも書いた通り、濱井さんのような環境の方には、
ＸＰという（言い方は悪いですが）マニュアルは無くても、
うまくプロジェクトは機能するはずなんです。
でも、そうではない環境の方だって多いんです。
１冊もプログラムの書籍を所有していないプログラマや、
「人月の神話」すら読んでいない管理者、
要求を言い放つだけの顧客。
このような場面を切り捨ててはいけないですよね。
みんなが路頭に迷わず楽しく仕事をするためには、
そのための良い指針が必要になります。
ウォーターフォールではこのあたりの話は規定が無いはずです。
だから、規定の無い箇所をどう振舞うかは個人の器量にゆだねられるんです。
そのため、私のように変な状況で働いて人もいれば、
濱井さんのおっしゃるような比較的恵まれた環境にいる人も
でてくるのです。
当たり前のことを明言しているＸＰってだから
いいんじゃないんですかねぇ。
＃うぅ、なんか愚痴っぽくなってしまいました。
> オンサイト顧客に関しても、プログラマが顧客のところで仕事を
> するというやり方もありえますから、顧客の負担が大きいとは
> 言い切れないでしょう。
茶々ですが、
スペースが無かったり、ちょくちょく質問されてうざかったり、
「ペアプロうるさい！！」とか思われないですかね。f(^_^;
Eiji Yamane（山根 英次）
E-Mail:e-yamane@....jp (Official)
e-yamane@....com (Private)
URL:http://www.ne.jp/asahi/e/yamane/index.html