dotkuwaの日記： 目的だ手段だで消耗するのは 3
目的だ手段だで消耗するのは、「ドメイン指向」の中で起きると
思います。
自分が仕事したてで、正式文書にまじで青焼きなんか有り、
FSPのGEMのライブラリでソースを管理しているなんて頃は、
「ドメイン指向」とは言わず、「業務知識・業務の言葉で考えろ」
とかでした。（まぁ、同じですよね。）
コンパイルのJCLをSUBMITして、区分編成に書き出したりとか
手段で満ち溢れていた頃なら、「業務の言葉で考えろ」は、
有りがたい警策になっていたと思います。
しかも、「ドメイン指向（業務の言葉で）」がうまくハマると
最良の設計になるのもまぎれもない事実です。
（自分はこれが正しいと信じています。）
実はここが問題です。「ドメイン指向」のドメイン（？）の間に
なにかエッジが有る筈です。
それを跨ぐと途端にダメになるエッジです。
エッジと名の付くものは、「知る人ぞ知るものだが、基本的に
好意的にみられている」エッジの此岸に有るものや、そうではなく、
「なんでこの様なものが標準なんだ」と誰もが訝しがる彼岸に有る
ものが有ります。
「業務の言葉で考え」た上、手段が有るものが此岸で、無いものが
彼岸です。
なにしろ、「業務の言葉」は自然言語で、しかもシーズを度外視し
ても言説として成立するからです。
うまくハマると最良の設計になるやり方を、プログラミングなんてやら
なくていいという口車に乗った人が教わったら、良かれと思った全ての
物が彼岸になるでしょう。
（この説明は現実と合っていると思います。）
「ドメイン指向（業務の言葉で）」は弁証法的怖さが有り、初学者が
知るべきではないのかも知れません。
-----------
まぁ、でもプログラミングが無くても、彼岸に渡らない秘訣は有ります。
それは、
・業務知識から考えて「兼ねる」をしてはいけない対象を兼ねない。
（キャラが被らない様にする。）
・業務知識から考えて「兼ねる」をしてもかまわない対象もなるべく
兼ねない。
（キャラが被らない様にする。）
です。
「業務」で「兼ねる」をしてはいけないものを兼ねる設計にすると、
本番移行が完全にとん挫するでしょう。
「業務」で「兼ねる」をしてもかまわない対象も、数年したり、
業務改善をしたりする際に、大きな障害となるに違いありません。
（なにか保守をする度に、「この箇所のこれこれは、こうして下さい。
業務的に（？）MUSTです。」説明しまくっている中堅の技術者が
いたら、基本的なところでキャラを被してしまったのかも
知れません。）
「業務の言葉で考える」場面で、しかもキャラが被ることは彼岸への
第一歩だと知るべきです。
少々説明が必要です。 (スコア:1)
＞うまくハマると最良の設計になるやり方を、プログラミングなんてやら
＞なくていいという口車に乗った人が教わったら、良かれと思った全ての
＞物が彼岸になるでしょう。
ここに少し説明が必要でした。
プログラミングをやっていない人が技術的な事を判断する際、大抵、
・プログラミングをやっている人の顔色を覗う
事でしていると思います。
昔なら、彼・彼女も新人で、頼れる先輩も沢山居て、先輩が良いと
思う顔色を覗っていたはずですが、
その内、先輩の顔色が青くなる事を言う・やるのが最適だと気づきます。
これは考えて気づくのでは無く、実体験からの非言語的な、反射的な
気づきです。
当人に指摘をしても、まったく分からないと思います。
さらに時間が経って、先輩がみんないなくなり、自分が第一人者に
なった時、今までの気づきを「さーこれから」実践しようとするのは
不思議では有りません。
その条件で、「先輩の顔色が青くなる」事を実践する人間は、
「良かれと思った全ての物が彼岸になっ」ても全くに当然です。
Re: (スコア:0)
まあ結果至高ですよ。本当は結果志向と書きたかったのだがこっちのほうが良いな。
Re:少々説明が必要です。 (スコア:1)
確かに逆転の発想で、
・手段の有無に関わらず何でも要求してかまわないし、TDDだってペアプロだって
かまわない。
・ただし、要求の内、「不可能だ」という結果に対しても金を払う。
風にすれば筋は通ります。
（ICT的な）手段が有ろうが無かろうが、業務は業務なんで、そのドメインの範囲
で何とかするのは理に適っています。