dotkuwaの日記： 上司の要求と依存性逆転の原則 6
日記 by
dotkuwa
上司に言われて自分の作業（社内システム管理）のWBSを書きました。
すると、
・有る範囲（サーバーのログとか、プロキシのログとか）のアノマリー
（いつもと違う事）を探す
↓
・問題を見つけたら、対処する。
ばかりになりました。それに対して上司は、
・なんで問題を初めに列挙しないんだ。そうで無くては管理にならない。
と言わんばかりでした。
アノマリーが何で起きるかというと、外部のせいです。自分の問題では
有りません。サーバーのハードが壊れたり、攻撃が来たり、で全部
外部のせいです。外部要因を内部に抱えた時、アノマリーが起きます。
だから、作業者はいつも受け身です。問題は外部から来るので、あらかじめ
列挙することが出来ません。
これって、
・依存性逆転の原則にしたがって作った良い設計が破綻する時
と同じでは無いでしょうか？
外部からのライブラリ（典型的にはDBアクセスの部品）を関数の中から
参照する時、依存性逆転の原則は破綻します。
でも、「まともな仕事」（自分の責任範囲で、過剰な楽観を捨て、
主体的に問題を摘み取る）をするには、外部要因を内部に引き込む
事が必須です。
でも、そうするとアノマリー（いつもと違う事、あらかじめ列挙できない
事）を抱え込むことになります。これでは「管理」になりません。
その点でも、関数型プログラミングの「良い設計」と同じです。
関数型の良い部分は、実用的なプログラムでは、
『本当に些細な枝葉に過ぎなく』なります。
でも責任有る行動のとれるプログラムはそれ以外（UI部や配線部）
が大量に必要になります。
やはり、関数型は古く（COBOL的な）、しかも好い古さでは無い、
単なる欠落した存在で、オブジェクト指向はそれを補った結果だと
思います。
「オルグ活動」 (スコア:1)
1990年代後半、2000年問題はまだ少し先の頃、
自分も含めた人間が仕事をしていると、
社内の人間では無い、見栄えのいいお兄さんお姉さんが
やってきて（まさに）「オルグ活動」（としか言いようの無い）
演説を始めたことが有りました。
たぶん、会社が頼んだ、コンサルタント系の人だったのだと
思いますが、想像でしか有りません。
曰く、
・このままの開発方法ではダメだ。
・技術的な細かさより、もっと根本的な事を、初めから
考え直さないといけない。
・プログラミング能力は脇に置いて良い。
・このやり方は困難だとは思うが、経営とも話を付けて
いて、これにチャレンジした人は全て高成果を保証する。
さぁ、やってみないか！ と、いう訳です。
汎用コンピュータで10年選手になっていた自分は対象外だった
様ですが、もっと若手は手を挙げない訳が有りません。
自分は、
プログラムレベルの細かさで記述して見ない事には、
「思いつく」為のユビキタス言語すら手に入らない、
通俗的な、一般的な、コンピュータシステムにはそぐわない
言葉で考えざるを得なくなるとしか思えず、
変だとは思っていましたが、逆らう事はもちろん不可能でした。
問題は、
★「このやり方は困難だ」どころの困難さでは無かった
点です。
「思いつく」人見習いとして、成果を上げていた人の下に付いて
いる内はまだ、良かったのですが、当然一本立ちする様に
なります。
すると「思いつく」人はどうするかというと、
・周りの人が困ることをする
様になります。
技術的な細かさを封じられた人間は、周りの人間の
挙動のみが世界となり、周りの人間が困ることをした
時が一番エモーショナルなので、それを体得してしまう
のです。
そしてそういう人がプロジェクトのトップに立った時、災悪は
一斉にみんなに降りかかります。
自分の全霊をかけてプロジェクトを完遂しようとするのですが、
まさにその霊は悪霊でした。
果てに、みんないなくなり上の人は外部から招へいしないと
ならなくなりました。
もちろん、そんなチャレンジはバブル景気だったから出来たの
だと思います。
いま再度やろうとしても、「高成果を保証」してくれる人は
何処にも居ません。
ばかばかしい話です。
類似の事象 (スコア:1)
1990年代後半、2000年問題はまだ少し先の頃、すごい開発手法だ
と言われていたのが、
・設計をして（先のことなど一切考えず）プログラミングは最小限にし、
修正が必要なら「設計からやり直す」。
です。一時期、全部そうなりました。
しかし、「設計からやり直す」をした所は聞いたことが有りません。
一応、出来たら手のひらをかえすように、そのプログラムを修正しろ
です。
「思いつく」人が養成出来ていれば、本来通りのやり方になったのでしょうし、
もし出来ているならば、このやり方はかなり勝率の高いものだったでしょう。
まったくそうならなかったのは、まったく「思いつく」人が養成出来なかった
傍証でしょう。
－－－－－－－－－－－－－－
さて、そうして、どんなに成果が無くても高成果を与えたりして、新しいやり方
をして何が良かったのでしょうか？
それは、
・権限を得る事が出来た
だと思います。
・状態を表すもの（確固として有るフラグだけでは無く、経路・文脈など
陰に表すものも含む）間のキャラが被っていない
状態は、別に難しいものでは無いと思います。
ただ、
・影響範囲が広くなる
のも事実です。
ある世界全体を2分するキャラ配分は、ある世界全体を2分する権限が必要
です。
とにかく、ややこしい事を言って、手を引かせ、必要な範囲の権限を得る
ことこそがシステム開発です。
ただ、最近はこの手のやり方がうまく行かなくなっています。
・前は、やる気と技術が有り、生活もかかっている人間が多くいて、
無理くり手を引かせても「お願いですからやらせて下さい」と
食い下がってくることが期待された
ですが、
・今後は、やる気と技術は有っても、完全に足を突っ込み切らない人間
ばかりで、手を引かせたらそれっきり
です。
－－－－－－－－－－－－－－
今後は、
・新しい権限配分を考える
事が必要だと思います。
・プログラミングの世界に限り、ある世界全体を2分する権限であっても、
それ程大きな身の程無しに、付与する
技術が必要だと思います。
そして、それにより、それを通じて、
・状態を表すもの（確固として有るフラグだけでは無く、経路・文脈など
陰に表すものも含む）間のキャラが被っていない
状態が出来上がるのです。
うま味の発見 (スコア:1)
キャラ配分と権限なんて、普通仕事でプログラミングをしている
人以外では、思いつかないと思います。
さらに、普通当然の如くに権限が与えられている様な人にも、
思いつかないと思います。初めから設計者として職業人生を始めた
人や、教師がそうです。
さらに、学校などで班ごとにプロジェクトでプログラミングをする
場合に、リーダーシップをとる「知っている人」も思いつかない
と思います。
うま味たっぷりの肉ばかり食べる欧米人に、うま味を発見出来なかった
のと一緒だと思います。
さらに、リーダーシップの下で班員として勉強している人も、違和感は
覚えるでしょうけれど、そこまで思いつきもしなかったと思います。
＃30年間まじめにやってきたのに、ちっとも権限をもらえず、引退して
＃管理系になってようやく、内製ソフトで権限をもらえた人間だから
＃思いついたのでしょう。
－－－－－－－－－－－－－
でも、有り得る話だと思います。
ソフトウェア分野で、金離れはいいが最悪の顧客と言われている人々が
居ますが、彼ら／彼女らは権限の専門家です。なんであそこまでこじれるのか
（自分は実際に遭遇したことは無いので、インターネットとかからのまた聞き
ですが）。
状態を表すもの間のキャラが被っていない様にする為には、それら全体を
考える必要が有ります。しかし権限配分となると、大抵
・人間毎にある状態、別の人は別のある状態
を取り扱います。それを跨ぐのは越権行為で、コミュニケーションによって
解決すべきと言うのが規範です。
しかし、プログラミングでは、
・関係するすべての状態を表すものを一度に何とかする
必要が有ります。権限の切り方が、
・人間のみの集団での作業
と、
・プログラミングでの設計施工作業（設計と施工は一体です）
で違うからだと思います。
プログラミングの専門で無い権限の専門家がかむと、えらい事になるのは
だからだと思います。
メタレベルでキャラが被っている (スコア:1)
問題は、
・「権限」という（メタレベルで）状態を表すものの
キャラが被っている
からで、
・プログラミングで必要な範囲の「権限」が有り、
人間だけでの作業で必要な範囲の「権限」が有り、
（以下「権限プ」、「権限人」という）
・与えられるのは「権限人」で、それだけの権限では
作業を開始できない。
・作業をする前に思い付き、説得出来て「権限プ」を
得られればいいが、その様な思いつく人間は居ない。
・勝手に作業しても、お金にならず、困る。
というシナリオです。
もう、繰り返し繰り返し起こっている事です。
悪いのは、プログラミング活動なのに、自然に、
「権限プ」が与えられない事です。
現状、それが与えられるには、誰にも負けないだけの
プログラミング的な張ったりを言えた人間だけですが、
張ったりを言えたからといって、作業が出来るという
事は示しません。たんに手を引かせて、「権限プ」を
得るだけに過ぎません。
しかし、プログラミングでは、作業中にも話し合わないと
いけません。ですので張ったりで手を引かせた人間と
相談しなければならないと言う気まずい状態になります。
悪いのは、自然に「権限プ」を寄こさない風潮です。
ウオーターフォールが主原因でしょうけれど、
アジャイルやスクラムでは自由過ぎます。
必要なものを寄こしさえすれば、済むだけだと思います。
問題があることが分かっているなら何故あらかじめ対処しておかないんだ (スコア:0)
あらかじめ列挙したらしたできっとこういう。
Re:問題があることが分かっているなら何故あらかじめ対処しておかないんだ (スコア:1)
コメントありがとうございます。
全くです。極言暴論の人もそうですが、
『「何を作るか」、そして大本の「何を発想できるか」』を思いつく人が
居て、自分らはそうで無いから安いんだとか言いますが、そんな人居ない
では無いですか。まだそう言うなら、いままで「思いつく人」として高禄を
はんでいたが、実際は思いついていない人を糾弾して損金を取るべきです。
せめて。
要するに、
・状態を表すもの（確固として有るフラグだけでは無く、経路・文脈など
陰に表すものも含む）間のキャラが被っていない
状態にするには、やってみないと行けず、やってみる人（手を動かす人）
がある程度＊＊＊設計＊＊＊しないとならず、テスト結果でユーザーが
ある程度＊＊＊設計＊＊＊しないとならず、だから今が有るのでしょう。
逆に、
・状態を表すもの（確固として有るフラグだけでは無く、経路・文脈など
陰に表すものも含む）間のキャラが被っていない
状態になりさえすれば、
・制御は創発する
し、それ以外の要因による制御の発生は無い為、
制御を層化・局在化出来ないし、（なのでUI層、配線層、計算層としました。）
・状態を表すもの（確固として有るフラグだけでは無く、経路・文脈など
陰に表すものも含む）間のキャラが被っていない
状態になりさえすれば、KISS、DRY、YAGNI、PIE、SLAP辺りは全て満たされる
ので、それらが満たされるのも、実際やってみないと行けないのでしょう。
それだけの事かも知れません。