dotkuwaの日記: プロレスラー 5
(良くは知らないのですが)プロレスラーの悪役は、
必ずいい役にやられるのが決まりだと思います。
しかし、いい役が衰えて技を受けられなくなったら、
悪役がいい役をやっつけて良いと聞いたことが有ります。
大規模開発で、末端のプログラマーなど、まさに
この「悪役」の立ち位置です。
まじで、「正しさよりも権威」の世界で、周りの人も
「正しい」と認めてくれたような自分の意見も全て
打ち砕かれます。
(プログラミングには「正しさ」が常に複数存在する
からだとは思います。)
そして、「悪役がいい役をやっつけて良い」に相当する
場面も確かにあります。
設計(自然言語)での言いな過ぎは、要求の意図の伝達に
漏れが生じ、個々のプログラマーのバラバラな判断が
各所に埋め込まれ、テストの際まで発覚しないひどい事に
なると思います。
しかしこの場合は、「悪役がいい役をやっつけて良い」に
相当する場面とはならないです。
ただただ、「バラバラな判断」をしたプログラマーが
責められ続けるだけで、プログラマーの悲哀が見られ続ける
だけです。
これに対し、
設計(自然言語)での言い過ぎが複数絡み合う場合の
特定の場合、
・どんなに好意的に解釈してもプログラムにすると、
代名詞のキャラが被る。当然動かない。
・これが、より根本的な設計箇所で起きると、一週間位、
すべての人の手が止まり、発注側の偉い人と
プログラマーの古手の複数人とで鳩首し、
当然の帰結として、設計を無視する方向になる。
・その様にこじれる理由は、その問題は自然言語だけでは
検出できず、実際にプログラミングをして初めて
分かるから。
となります。
これに関する第一通報者はたいてい末端のプログラマー
になります。悪役の逆襲です。
なにが言いたいかというと、
・ショーストッパーになりたくない設計者は、
必然的にプログラミングを学び、まずい言い過ぎの
絡み合いが起きない様にしなければならない
のでは無いか?
という事です。
昔から自分は、「設計者とはどうやって思いつくの
だろうか」と不思議でしたが、絶対、プログラミングの
知識なしには、思いつきの貫徹など不可能だと
思うに至りました。
逆に、「アジャイル」などは、
・言いな過ぎ気味を旨とする。
・『発注側の偉い人とプログラマーの古手の複数人と
で鳩首し』を年中行事としてやる。
やり方だと思います。お金がいくら有っても足りない
やり方だとしか思えません。
プロレスとアジャイル (スコア:1)
プロレスラーの悪役は、必ずいい役にやられるのが決まりだと思います。
まあ、それが伝統的なプロレスの筋書きですね。
とは言え、悪役(専門用語でヒール)の人気が高ければ、いい役(同ベビーフェイス)に勝つこともあったり。
しかし、いい役が衰えて技を受けられなくなったら、悪役がいい役をやっつけて良いと聞いたことが有ります。
普通はそんなことは許されないですね。
ベビーフェイスもヒールも、あらかじめ決められた筋書き(同ブック)に従って試合をやることになっています。
通常、これを破ること(同ブック破り)は許されません。
ブックでベビーフェイスがヒールに勝つとされていれば、ヒールが勝つことは許されないわけです。
ただ、ベビーフェイスが衰えたために、ヒールが勝つというブックもあり得ます。
しかしそれはブックでそう決まっていたから、そう言う試合になるというだけで、レスラーの勝手なブック破りの結果ではありません。
ただ、ブック破りがまったく無いわけでもありません。
衰えた、というのとは違いますが、試合中の事故・怪我で試合の続行が難しくなった場合に、その時のレスラーやレフェリーの判断で緊急避難的にブックが破られる、なんてことはあります。
いずれにせよ、レスラーは、ベビーフェイスだろとヒールだろうと、ブックに従うという意味で同列で、システム開発に置き換えれば、どちらも末端プログラマーです。
一方、設計者は、ブックを作るブッカーに相当するんじゃないでしょうか。
お金がいくら有っても足りないやり方だとしか思えません。
アジャイルって、頻繁に変更される仕様や、激しく変化する環境への対応を目指したものですよね。
そういうことを例えば、ウォーターフォールでやろうとすれば、アジャイル以上にお金がかかるんじゃないでしょうか。
つまり、本質的に困難な(≒お金がかかる)開発に対応するための手法を、そう言う本質的な難しさが無い場合に適用するのは正しくない、ということでは。
Re:プロレスとアジャイル (スコア:1)
>>これに関する第一通報者はたいてい末端のプログラマー
>>になります。悪役の逆襲です。
>ただ、ブック破りがまったく無いわけでもありません。
>いずれにせよ、レスラーは、ベビーフェイスだろとヒールだろうと、
>ブックに従うという意味で同列で、システム開発に置き換えれば、
>どちらも末端プログラマーです。
>一方、設計者は、ブックを作るブッカーに相当するんじゃないでしょうか。
もちろん、指摘した末端のプログラマーが得出来る訳では無い
です。むしろきまり悪くなると思います。設計者で無いのに
設計者の真似事をさせられるからです。
(自分も、毎日11時まで、べったりそういうプログラミングを
やり続けて、終わって積もって溶けた雪ががりがり言う道すがら、
口ずさんだのはBrave Songでした。)
ここにこそ、問題点が有ると思います。
テストがどうしたとか、モブがどうしたとか、Devがどうしたとか
実務者に歓迎されて居ない新手法というのは、大抵、
・プログラマー(の単価、知るべき地位)なのに設計をさせられる
のが本質です。
単価とか地位とか関係ない学校とかでのトレーニングでは
良いのかも知れません(たとえ「テストを最初にやれ」でもです。)
しかし、単価と地位が有る世界に持ち込もうとすると壁に直面する
ことになると思います。
そしてそれは壁では無く、(その場の)原理原則に反したことによって
生み出された、仮想的な反力に過ぎないと思います。
そして、こればかりは、自然法則に準ずる形で、(そういう場では)
あまねく起きると思います。
Re:プロレスとアジャイル (スコア:1)
>そしてそれは壁では無く、(その場の)原理原則に反したことによって
>生み出された、仮想的な反力に過ぎないと思います。
要するに壊れ得る壁でも、扉を隠すカーテンでもなく、力に対して
応じた力がかかる、絶対に壊れないものだ、
と言いたかったのでした。
Re: (スコア:0)
よく「ウォーターフォールは古い! 非効率! クソ! アジャイルに対応できないと時代遅れ! 滅ぶ!」とか言われてましたが、
それ自体は間違い(正確ではない)であると。
あくまでケースバイケース、いままでウォーターフォールやそれに近いやり方でいまいちだったもののみに対して提示された、新しい手法でしかないってことか。
何でプログラマーと設計者を分けたがるか! (スコア:1)
プログラマーと設計者を分けたがるのには理由が
有ります。
※実は自分は設計・設計者の実務経験は0です。
※プログラマーを30年やってきて、隣接する職業の
※設計者について、
※「これ以外に説明がつかない。絶対これだ!」
※という単なる考えに基づいて、設計・設計者に
※ついて語っているという事にご留意ください。
プログラマーは、
・見える範囲で矛盾無い記述をしなければならない
・「見える範囲」とは渡された設計書の範囲と
ほぼ同義です
です。
それに対し設計者は、
・必要な範囲で矛盾無い記述をしなければならない
・あるいは、必要な範囲を分割し、インターフェース
を策定し、個々の範囲で矛盾無い記述をしなければ
ならない
・後工程がつかえているので、最大限手早くしないと
ならない
です。
これにより、設計者は、
・仮説を立てたり、駄目でやり直したり
をし、
・必要な範囲全体を考えないといけない、
それも素早く。
となります。そうすると、個人的な表現で言うと、
・脳みそがパキッと音をたて
ます。その上、
・コーヒーなどを沢山飲み
ます。
すると何が起きるかというと、
・一気にくたびれます。
・たとえるなら、大学入試の試験後とかです。
・長続きしません。定時で帰って、翌日午前半休
を取ったりします。
ですので、設計者はひと段落ついたら、QA担当に
なったり、文書作成をしたりするでしょう。
要らない文書であっても、設計者のアニーリングの
為には必要不可欠です。
---------------------
さて、
このパキッという位まで考えるのを、最低時間が
有り、超過時間もやらなければペイしない様な
プログラマーがやったらどうなるでしょうか?
〇んだり、数年再起不能になったりするでしょう。
特に経験の少ないプログラマーに無理やりやらせたり
すると、
・自分は偏ってしまった
と深く深く悩み、戻ってこられなくなるでしょう。
ですから、無理なんです。新しいなんとかとかいう
のは!!!
#一番まずいのは、設計者になるべき管理職が、
#「見える範囲でのみ」仕事をする事でしょうけれども
#それはまた別の話だと思います。
#(管理職は設計者のさらに向こう側で、何年たって
見ても何も判りませんでした。)