dotkuwaの日記： 思いつく方法 4
自分は昔からずっと、「思いつく方法」を教わっていません。
だから、プログラミングでは写経とかでしか学べませんでした。
プログラミングは写経で十分だと思いますが、仕様を思いつく方法
はそれでは不十分だと思います。
・まず一般に出回ることが無い。
・プログラミングと違い、大きな全体は小さな部分の集合であると
割り切る事も出来ない。
・すでに有る（やっと手に入れた）実際に成った仕様を写経しても、
自分が思いつく足しにならない。
からです。
実際の所、
・（一階論理や高階論理を含む論理の）階位を制御する
とか言ってしまいましたが、実際何なのか分かっていませんし、
下手な事を言うと、致命的な事を言ってしまいそうです。
だから、なかなか日記を書けませんでした。
（ただ、プログラミングで命名が重要で困難なのは、これが関係して
いるとは思います。一階で満たされているプログラミング言語で
希少に顕れる高階の兆しです。）
ですが、あえて言いますと、
・仕様の「思いつく方法」は、階位の固定では無く、階位の変動に
よって得られる。
・階位の変動に一階を含めないと、思いついたことが接地されず、
理論倒れに終わりやすいし、高階のみの変動では天才的な何かが
必要になる。
と思います。
試作をした上で、思索し文書化する、を繰り返す。のが、
仕様の「思いつく方法」では無いでしょうか？
とすると、試作が出来ない（プログラミングを書いてテストが出来ない）
人は、仕様を思いつくことが出来ないと思います。
（プログラミング無しに無理やり一階論理を習得した人を知って
いますが、それが出来た人は外に居ません。一階論理を習得するには、
プログラミングが最適です。）
それっこそ、（仕様のレベルでは）意味の全くないコピペをするしか
無い要員になるのでは無いでしょうか？
（プログラミング無しに無理やり一階論理を習得した人は、思いつくこと
が出来る人なので、実際には一階論理を習得していさえすれば良いの
ですが、はっきり言って、その人は自分用のプログラム言語を自分の
中で作った「だけ」に過ぎない様に見えます。その様なことはなかなか
出来ないので、やはり早道は既存のプログラム言語でのプログラミング
の習得です。）
いままで、自分の周りでは、
・設計は設計のみから作るべき（階位は固定すべき）
・これは大変だがやり遂げないといけないし、そのチャレンジは、
成果として認める
というのが主流でした。
でも、あまりに大変過ぎてだれも到達できていません。
ポンチ絵などは、自然と階位の変動を促す技法なので、良いのかも
知れませんが、チャレンジには成り得ません。
普通にプログラミングが出来、実務を経た人が、試作しながら、
文書化するではダメなのですかね～。
難しいですね (スコア:0)
顧客自身が自分が望むものをわかってないこともありがちですから
# ここで例のブランコの画像をw
本当に本当に難しいです (スコア:1)
望むのを許されるためには、望む人間も階位の変動を身に着けないとだめだと
思います。本当に幹を切って左右に柱を立てるのが必要なら、その説明を
受け入れないといけないですし、重役席が本当に必要なのか、それとも別の
所ですべきことなのか、望む人間が考えるべきです。
＃あのブランコの画像は全て正しいとおもいます。
そうで無いなら、もはや顧客たり得ないと思います。労務倒産よろしく、
撤退するより無いと思います。
使えれば充分 (スコア:0)
Re:使えれば充分 (スコア:1)
たとえば、
初めは、
・成果を一覧にして出来たらチェックを付けろ
だったのが、
・一覧として事前に書けるもののみを成果として
認めるからチェックを付けろ
になったりして、
階位をピン止め出来て、管理する側としては最高の
パフォーマンスが得られたのかも知れませんが、
それ以降、どんな成果も得られなくなってしまう。
思いつく方法を失ってしまうから。
ですが、
手法として「一覧に書けるもののみを成果」
とする方法だってあり得るのは確かで、
それに対抗するには10年20年をかけて、実際に、
・その手法では成果を得られない
というファクトを得るより無いと思います。
そうして100年200年経てば、きっと「それ以外の
状態」をできなく出来るでしょう。
思いつく方法は、実際にやりさえすればよいだけ
だと思います。
もちろん、「試作など認めない」という方針下に
有る場合は、そうで無くなるまで10年20年待つより
ないでしょうけれど。。。