メッセージ。 - diary

たとえば、普通の(遅延評価のない)プログラミング言語では、関数の適用順序は一通りしかない。f(1)は「fという関数を1に適用する」ということだし、f(1+1)は「fという関数を1+1の結果である2に適用する」ということだ。

後者のf(1+1)では、1+1=2が終了した後でしかfは適用されない。関数fが適用されたとき、fは渡された引数の値が何であるかを知るが、それがどうやって導出されたかを知らないし、知ることはできない。なぜなら、もう評価されて値になってしまったものが引数の値として渡されるから。

でも、遅延評価の言語では事情が異なる。f(1+1)と記述され、fが1+1に適用されるとき、関数fに引数として渡されたものは、「2」ではなく「1+1」だ。だからfの定義として、「引数として渡されてくるのは2つの数値の足し算だ。だからfよ、お前は足し算がなされる前の数値をそれぞれ2倍にして足し算するのだぞ」と定義してやれば、実際そういった計算ができる。f(1+1)は、1*2 + 1*2 = 4という結果に評価される。

少なくとも理論上はそういうことができる。で、その理論上できることをプログラムの記述上どのように表記するのか、という問題に1つの解を与えたものが、FunctorとかMonadとかです。…ってことであってますかね？

たぶん、詳細設計書が必要かどうかは、いま（あるいはここ数十年ずっと）起こっている問題の本質じゃない。

より本質に近いことは、コの国の開発では詳細設計書を作成するために必要な期間や工数がないことだ。上流レベルでの仕様変更が多発したり仕様が決まらなかったりした場合でも、納期が変わらなかったり下流に落ちてくるお金が変わらなかったりする。そもそも始まる前から、無理な納期や無理な予算でやることを強いられる「やるしかない」案件が多すぎる。そんな状況で、正しい内容の詳細設計書を正しい方法で作ることができるだろうか？

ソフトウェアの開発には時間や工数がかかること、よくあるウォーターフォール型で開発を進めるなら要求・機能・詳細設計で仕様変更が発生したときには、上流側がしかるべき工期延長と予算増加を受け入れなければならないこと、とはいえフェーズが詳細に進んでから上流仕様の問題点を発見しえないリスクはそれなりに大きいのでリスクバッファが必要なこと、そしてこれが重要なことだと思うのだが、リスクが現実の問題に顕在化してきたときに、より下流や弱いところばかりに皺寄せが行かないようにしなければならないこと、そういったことを、発注元から最下流の現場まできちんと理解していなければならない。

だが実際にはそれができていない。全般的に、コミュニケーションレベルの問題が多いような感じがする。日本には言葉で議論する土壌がないのと、上流(客)=偉い、下流(店)=口答えは許されないという風習によって引き起こされているのではないかと思っている。そういうこともあって、とくに問題になりがちなのは、これまで付き合いのないお客やチームでの案件だ。流動性の低い環境ならそれでもいいのだが、そうではなくなって問題が起こっている。日本の風習や土壌がスケールを阻んでいるといえるかもしれない。

いろいろあったけど（あるけど）、一応元気です。

世の中の半分の人は、平均点以下の点数しか取れない。

ぼくは、ただみんなを幸せにしたいだけなんだ。