シェルスクリプトのキモいところ

シェルスクリプトインタプリタを作ろうかと、シェルスクリプトの仕様を調べています。気持ちの悪い仕様をいくつか見つけました。仕様書*1を見ながら、dash で試しました。

丸括弧と波括弧のふるまいが違う。

丸括弧はサブシェル、波括弧はコマンドのグルーピングをするための似たような文法ですが、ふるまいが異なるので戸惑います。

$ (echo hello)
hello

丸括弧はコマンドの前後にスペースも要らず、丸括弧内のコマンドが実行されます。

$ {echo hello}
{echo: not found
$ { echo hello }
Syntax error: end of file unexpected (expecting "}")
$ { echo hello; }
hello

しかし、波括弧はコマンドの前にスペースか改行をを入れて、コマンドの後ろにはセミコロンか改行を入れる必要があります。波括弧は優先順位が低くてコマンド名や引数として見なされてしまいます。きっと、波括弧は「あとづけ」なのでしょう。

リダイレクトだけでコマンドになる。
$ >abc
$ ls abc
abc

リダイレクトだけでコマンドとして成立します。

引数とリダイレクトは順不同である。
$ echo a 1> A b 2> B 3> C c
$ cat A
a b c
$ ls
A  B  C

引数とリダイレクトを混ぜてもよい。

$ 1> A echo 1 2 3
$ cat A
1 2 3

リダイレクトはコマンドの前に持ってくることもできます。

条件式の末尾に & が使える。

シェルスクリプトの if 文の条件式はただのコマンドですが、その中でバックグラウンドジョブを作る & が使えてしまいます。

$ if false& then echo hello; fi
hello
$ 
[1] + Done(1)                    false

この場合、条件式は真になります。

関数定義に if 文、 for 文、 case 文などが使える。

シェルスクリプトの関数の中身は通常、波括弧でくくったグループで書きます。

func() {
    echo hello
}

実は、丸括弧で書くこともできます。

func() (
    echo hello
)

ここまではそんなに驚かないのですが、if 文、for 文、while 文、case 文などを関数の定義の後ろにいきなり書いても正しいです。

func() if true; then
    echo hello
fi

func() for i in 1; do
    echo hello
done

 func() case A in 
    A) echo hello
esac

dash だと、単コマンドでも関数を定義できました。bash は無理でした。POSIX の仕様的には bash の方が正しそうです。

func() echo hello
関数定義にリダイレクトが付けられる。

どこで使うのだろう?

func() {
    echo hello
} > /dev/null

ケリー基準

ケリー基準という、賭けに投じるべき額の総資金に対する割合を与える式があります。次のような問題があったとしましょう:

  • 賭けに勝つと掛け金の r 倍が利益になる。賭けに負けると掛け金分が損失となる。賭けに勝つ確率は p である。総資金の一定の割合 f を賭け続けるする。このとき、最も資産が効率よく増える割合 f* は?

答えは以下となります。

f:id:fjkz:20180721103719p:plain

分子は賭けの収益率の期待値です。期待値が正でない賭けを何度もする価値はありません。一方、分母はいわゆるオッズであり、賭けの手堅さを示しています。リスクの大きい大穴を狙うなら総資金に対して大きな割合を賭けてはならないということをケリー基準は教えてくれます。

さて、リスクとリターンを最適化するということが金融工学の目的ですので、このケリー基準は資産運用にも使えそうに見えます。リスク資産(株や債権)をどれぐらい持つことがもっとも効率のよい運用になるのでしょうか?

そこで株式バージョンのケリー基準を計算してみました。なお、 Kelly criterion - Wikipedia に書かれている結果と私が導出している結果は異なっていて、私の結果の方が複雑です。おそらく私が幾何ブラウン運動の過程を理解しておらず、抜けている仮定があるからと思われますが、大筋は一致しています。

投資をするときは利益を期待して投資をします。期待利益率を r とします。配当や物価の上昇、企業の成長による株価の上昇による利益をここでは期待利益率とします。

株価は期待とは別にまるでランダムかのように上がったり下がったりします。今回は株価にはランダムで、トレンドもなく、動きが予想できないような動きがあるとします。ボラティリティと呼ばれるような変動です。単位期間に σ の割合で株価が上がるか下がるかを、それぞれ 1/2 の確率で、するとします。なお、 σ > r > 0 です。運が良い場合に株は r+σ の利益率、運が悪い場合に株は r-σ と負の利益率となります。

株に一定比率 q で投資をするとします。株価が上がれば一部を現金に変え、株価が下がれば追加で投資をして、総資産に対する株式の割合を一定に保つとしましょう。このとき運がよいシナリオでは、単位期間後の総資産は (r + σ + 1) q + (r0 + 1) (1 - q) となります。運が悪いシナリオでは、単位期間後の総資産は (r - σ + 1) q + (r0 + 1) (1 - q) と σ の符号が逆になります。ここで、r0 は無リスク資産の利益率です。国債や銀行の定期預金の利率です。

単位期間後の総資産の期待値は f:id:fjkz:20180721134208p:plain です。何回も試行したときの、利回りの話をしているので、ここでは算術平均でなくて幾何平均とするべきです。

これが最大となる q (=q*) が今回欲しい値なので、微分値がゼロとなる q を求めると、 f:id:fjkz:20180721134746p:plain となります。

ケリー基準と同様に期待値をリスクで除した割合が、最適な割合となりました。(幾何ブラウン運動を仮定して導出した方が、q* = (r - r0)/ σ ^2 ときれいです。)

記号だと味気ないので値を入れてみましょう。

無リスク資産の利率は 0.05 %とします。株に期待できる利益率は 5 % でしょうか(数値の感覚が有無のが素人と玄人の違いですが、素人なのでよく分かりません)。ボラティリティは 20% ぐらいですか?このとき q* は 1 を超えるので、全ての資産を株に投資するべきという結論になります。そうであれば株価はもっと高いはずなので、5 % の利益を期待するのは多すぎるようです。

期待される利益を 3 % としますと、q * = 0.6 です。無限回の試行を仮定していて、リスクが過小評価されていますので、実際に総資産の 6 割も投資するのはリスクが大きすぎるように思います。しかし、どんなに欲張っても資産の 6割以上を単一のリスク資産に賭けるのは逆効果だということが分かります。

マネージャをマネジメントする。

マネージャと呼ばれる職種の人はどこの組織にもいます。いわゆる中間管理職の人々です。個人の人格は別にして、彼らには組織上の機能の要請から、共通の行動原理があります。マネージャは例外なくこの行動原理にしたがって動きます。特に優秀なマネージャであるほど原理に忠実に動くものです。そのため、マネージャというロールの人々は行動の予測がしやすい; 別の言い方をすると御しやすい人々だと言えるでしょう。マネージャをマネジメントするのは、サラリーマンスキル(コンピテンシというやつ)の一つで、彼らをコントロールできた方が楽に仕事ができるようになります。

今回は、私が長年の観察により発見しましたマネージャの行動原理を挙げまして、マネージャを御する方法を考えてみたいと思います。

マネージャは自分の立場を守る。

全ての管理職は自分の立場を守ること、つまり保身を最も優先します。自らの責任範囲で悪いことが起こらないことに最も注意を払って、仕事をやり過ごすことに注力します。それがミッションなのだから当然です。一般社員と比すればマネージャは責任感が高いでしょう。また、マネージャはもっと上の人に一般社員より遥かに厳しく詰められます。責任は責任範囲の中にしか生まれませんので、責任範囲を守ることに執着するのは自然なことでしょう。

一方で、責任範囲の外にはあまり興味がないものです。例えば、事業の利益や会社の利益、あるいは人類の利益になんかは、一般社員と同程度によそごとだったりします。前の会社でマネージャが「こんな泥船の部署……」と言ってたのには、それはお前の責任やろと思ったりしましたが、マネージャというのはそういうものです。

基本的にマネージャは自分の立場を守ることしか考えない――これが第一原理です。マネージャは組織上の部署の機能に忠実です。内心は別のことを思っていても、立場的に立場を守るようにしか動けないものです。不自由と言っていいかもしれませんが、大人には不自由が好きな人が結構います。制約条件の中でうまく立ち振る舞うことによろこびを感じる人、要するに出世志向の強い人です。また、しばしばいる考えの読みづらい冷徹なマネージャも、おおむね頭の中にあるのは自分の立場のことだけです。覗いたことはないものの、その仮説でもって説明できなかった場面には未だ出会っていません。

マネージャが部下のことを慮るときも、それは立場上やっているだけと考える方がよいです。部下の利益も彼らにはよそごとです。彼らはわれわれの人生になんて興味はない。彼らは親ではありません。部下が自分の立場を守るのに有用か、あるいは有用にするのにはどうすればよいのかにしか興味がないと考えた方が、彼らとは付き合いやすいでしょう。

一般社員として仕事をするときも、マネージャの立場を守るのに有益になるように仕事をするのが、彼らには喜ばれます。天下国家のためなることであっても、彼らはそれを仕事とは認めません。「2つ上の役職の立場に立って考える」というのが、サラリーマンとしての上手な立ち振る舞い方だと言われていまして、マネージャにとって有用に働くのが平社員にとっては楽な生き方です。

マネージャは受動的である。

組織にはトップダウンボトムアップというのがあって、大体のマネージャはボトムアップを好みます。上がってくるレポートを聞くだけ、これをやっていいですかという相談に承認するだけ、稟議書に判子を押すだけ、といったやってきた情報に相槌を打つ仕事をボトムアップと呼んでいます。ボトムアップで来るものに対して頷いて、たまに思いつきで適当にコメントを返すというのが楽ですよね?君臨すれども統治せずといった感じでしょうか。元よりマネージャのロールとして、承認フローやレポートラインの中継以外の役割を求められていないという場合もあろうかと思います。それは彼らが好んでそうしたのとそれでうまく回った結果そうなったのでしょう。

いくら赤べこの張り子人形のように頷いているだけを好んでいても、うなずくだけでは済まない問題がボトムから上がってくることもあるかと思います。しかし、それはそんな厄介事を上申する奴が悪いのです。「なんでなんだ」と詰問すれば、問題を引き受けずに投げ返すことができます。再び前の会社の話で、ゼネラルマネージャ級の人が「重大な障害が起きてしまいました。起こした人は反省してください。」と言ってました。確かに彼らの立場からしたら、問題は自分のあずかり知らぬところで「起きる」もの・下々が「起こす」ものでしょう。でも、そんなスタンスで僕らに話されても、何も変わらないのだろうと思ったものです。

偉い人は、座って待っていたら、下僕たちが問題の解決策を持ってきてくれて、実行してくれることを期待しています。いわゆるマイクロマネジメントは疲れますので、やりたくないのです。意思決定もしたくないし、頭を使うこともしたくない、指示も出したくない。報・連・相でいうところの相談は嫌がる。言ってしまえば、彼らはマネジメントなんて仕事はしたくないのです――これが第二原理です。一般社員のわれわれは、これを理解する必要があります。

そして、マネジメントをしたくないマネージャのために、われわれは「忖度」をしなければなりません。言わずとも知らないところで勝手に問題が解決しているというのが偉い人にとっては理想的な状態です。上官が何も言わないのに下官と意思疎通がとれるのは、忖度という高度なコミュニケーションを下官がとっているからです。大学にいた頃に、助教の人が「先生はこうおっしゃるだろう」とか「先生がおっしゃったことの真意はきっとこうだろう」と、教授の思いを憶測して動いていました。当時は忖度という言葉を知らなかったから、シャーマンになって教授の霊を憑依させているんだと揶揄しておりました。人間には、他の人の思いを脳内でシミュレーションできるという能力があります。面白いことに現実の上司と脳内の上司のいうことに大きな齟齬はありません。私たちは、現実の上司の意向に加えて、脳内の上司の意向に従って、働くべきなのです。脳内上司に忠実な人が有能なスタッフとされます。

マネージャは不確実なものを嫌う。

報・連・相のうちの相談は嫌がったとしても、権限と責任の範囲内での意思決定をすることはマネージャの仕事です。われわれとしてもスタンプラリーをクリアするために、判子を押してもらう必要があるので、彼らに意思決定をしてもらう必要があります。

判を押す人から見ますと、確実に正しい答えであることに対しては判を押しやすいものです。サイコロを振って1以上の目が出ることを保証してくださいと言われて、それを認めるという判断をするのは容易です。一方で、確実でないことを判断するのは難しいことです。サイコロを振って1の目がでることを保証しろと言われても、それを認めることはできません。6の目が出たらどうするのでしょうか。テメーそんなものに判を押しやがってと責められますよね。明らかに誤った判断をしないというのが、責任というものです。現実は、理想的なサイコロの目と違って、確率など計算できない種類の不確実さを持っています。これに対して判断を下すことは難しいことです。

そのため、マネージャは不確実な状況下で意思決定をするのを嫌がります――これが第3原理です。こういうときには、意思決定をしないという判断がしばしば行われます。つまり現状維持、問題の先送り、負債の繰り延べです。ポイントは、これらが結果として誤った判断だとしても、意思決定をしていないので、責を負うことはないということでしょう。そもそもマネージャには明らかに誤った判断をしてはならないという職責はあっても、結果に対する責任ないですから。

正しいことの蓋然性が高い解、つまり明らかに正しい答えを認めないというのは、明らかに間違った判断ですから、マネージャは立場上これを拒絶するわけにはいきません。われわれとしては、明らかに正しい答えを用意しておいて、マネージャがただうなずくだけで良いようにお膳立てするべきです。彼らが一緒に悩んでくれて彼らから答えが見つかるなんてのは期待せずに、彼らが頭を使わないようにするのが正しいです。

現実はきれいではないので、不確実なものです。現実をそのまま反映したら、きれいでない判断材料になります。そういうのは持って行ってはいけません。いい感じに抽象化して、筋が通っている情報であるようにきれいにしなければなりません。具体的な「正しい」情報が欲しい人は、元より一次情報にあたりますので、それをしない人はそもそも正しい情報なんて求めていません。彼らの要望に合わせて、クリーニングされた情報を渡してあげるのが、親切です。


悪意をもって長々と書いてしまいました。個人の人格は別として、マネージャという役は好きではない。理想的なマネージャは機械化が可能だとすら思っているし、彼らを機械化するように動くのが理想的なサラリーマンなのではないかと思っています。理想的なサラリーマンは、結局コンサルタントや官僚のようになってしまうのでしょう。

また、仮に間違ってマネージャにさせられてしまったら、私もマネージャの行動原理にしたがってロボットのように動くのだと思います。飼い犬とはつらいものです。

接点 t を見つける

現実はおそらく一つなのだろうけれども、どの断面で切り取るかによって見え方は全く異なるものになります。人の知性では世界をそのまま認識することはできず、何かしらのフィルターを通して世界を見て解釈します。フィルターとはフレームワークパラダイムやモデルと言い換えてもよいでしょう。生きていますと世界をもっと合理的に解釈できるような新しいフィルターを見つけたり、これまでのフィルターでは解釈しきれないような新しい事象に出会ってフィルターが外れたりします。このときが生活していて最もよろこびを得るときだと、私は思っています。

「接点 t 」とは、高校数学で2次関数・3次関数の数曲線の接線を求める問題の有名な解法のことで*1、この解法を初めて学んだときに狐につままれたような気持ちでした。接点 t はこちらが勝手に置いたもので、それを通る接線なんて存在するかどうかも分からない virtual なものです。しかし、方程式に解が存在したとき、接線が実在するものとして現れる。ないのにあるとはどういうことだ?解があることが存在するということなのだという新しい視点に、世界がひっくり返えるような驚きを感じました。

学びのよろこびとは、できなかったことができるようになるとか、生活の役に立つとか、実学としてのよろこびもあるものの、世界の見え方が変わる以上のよろこびには未だ出会ったことがありません。狭い視野から見た既存の世界を維持するために働いている人々は、一体何が楽しくて生きているのだろうと不思議に思ったものです。学びを否定し、変化を嫌がる――そういう人が社会のほとんどを占めていると知ったことも、強烈なパラダイムシフトでした。

数の世界よりも、今では人間の世界の方が面白いです。数学はきれいになるように作っているからきれいなのですが、社会は複雑で汚いです。一見複雑な社会や人が、理にかなって見えるフィルターを発見するのが、楽しい。社会や人に関しては「物語」と呼ぶのが適当でしょうか。社会や人が合理的でなければならない必然性はどこにもなく、社会や人を統べている一般法則なんてきっとないのでしょう。それでも、人間の悲喜こもごもを見て、そこに物語を見出すのは無上のよろこびなのです。

社会にはいろんな人がいます。均質でない人々が集まると、衝突があったり、化学反応といわれるような思いもよらない結果になったりします。事件が起きる現場では人は思いもよらない動きをします。人は間違うし、裏切ります。そういう現場に居合わせたいものです。

また、物語を見たいがために、デスゲーム的なもの・スタンフォード監獄実験・ミルグラム実験みたいなものを主催することを夢想します。もちろん犯罪でも悪事でもないことが前提です。私はきっと社会実験がしたいのでしょう。バンク*2という会社の実験的な試みを見て、羨ましく思います。あのサービスを始めてから彼らの世界観はきっと大きく変わったでしょう。

新しいパラダイムを見つけるというのは偉業です。他者の世界観を変えるようなパラダイムを見つけたいものです。世の中の人は世界が変わって見えることを求めていないのかもしれませんが、社会というのは変わり続けているので、それを合理的に解釈できる新しい枠組みが必要です。商売も新しい枠組みに嵌ったビジネスが成功しているのだと思います。ただの趣味であることに加えて、実利的な目的のためにも、俺の「接点 t 」を見つけたい。

愚者は経験に学び、賢者は歴史に学ぶ

経験とはそう大切なものなのだろうか。

何かをするにあたって、経験が全くないよりは豊富に経験があった方が上手くできるでしょうし、年の功が役に立つことはあります。役に立つとは問題を解決するのに有効かどうかということです。問題を解くことに効果があるならば、その経験は敬うべきものでしょう。

一方で、いくら経験があるとのたまわれても、問題の解決の助けにならなければ、その経験は尊重できません。「昔の誰々が同じようだった」などと経験があることを自慢されたところで、役に立ちません。ただ昔話をしたいのか、自分の優位性を示したいかでしょうから、雑談であればなんぼでもヨイショします。しかし、こちらが問題を抱えていて困っているときに、自慢話を聞かされることはいささか迷惑でもあります。

我々は問題の解決がしたいだけです。その仕事をやっている年月の長さが必ずしも解につながるわけではなく、また解の出処が経験から得た見識でなければならないという決まりごともないのです。実際にはものを知らないのにも関わらず、自分は経験豊かで解法は全て知っていると思うことは困った考えです。自分の経験にしか拠り所がないというのであれば、頭の中の引き出しの数が少なすぎるように思います。

人の歴史は長く、人の数も多い。それに比べて人ひとりの経験など、ちっぽけなものです。おおかたの問題は別の誰かが遭遇していて、既に解決されていて、記録にのこっています。どうしてそれを知らないでいられましょうか。

愚者は経験に学び、賢者は歴史に学ぶ。

ビスマルクの言葉で、「歴史に学ぶ」はもともと「他人の経験」だったのが、かっこよくするために「歴史」に変わったそうです。高校の時分、テキストにこの言葉が出てきたときに、先生が「自分の経験からも学ばない人もいますけどね」とボソッと言っていたのが心に残っておりまして、その先生の言葉も含めて、座右の銘となっております。自分の経験からも他人の経験からも学んでいくのが賢者への道なのでしょう。

経験からの学びを Kolb という人がモデルにしていまして、「経験学習モデル」という名で知られています。「経験→省察→概念化→実践」という4段階を繰り返して人は経験から学習していくというものです。

https://www.simplypsychology.org/learning-kolb.jpg

歴史を知っていれば、Kolb の経験学習モデルのうちの概念化が簡単になるか省けます。無から概念を組み上げなくても、先人が既に概念化しているので、それを当てはめればよいのです。他人の経験則を最初に知ったときは、すぐにはぴんとこないかもしれませんが、後から似たようなことを経験したら、あれはそういうことだったのかと思うことがありますよね。あるいは「これ進研ゼミで出たところだ」と即座に解が見えることもあるでしょう。

先人の経験の上に自分の経験を乗せて概念を強化していけば、学びはブーストします。巨人の肩の上に乗ればより遠くが見えるようになるものです。歴史に知恵を借りれば、無教養な人の20年・30年の経験なんて取るに足らないものであって、人類の歴史を背負って未来を切り開いていくのが現代に生きる我々の務めだと信じます。

社員は大事にされなきゃ貢献もしない

4月――どこからともなく新入社員が会社に入ってきます。私も会社員をしている時間がずいぶん長くなってしまい、彼らを指導する立場になってしまいました。会社員をやっているものの、私は会社組織というものがあまり好きではないのだが、彼らには会社組織に愛着を持ってもらって、貢献してもらいたいと思います。それが仕事ですし(仕事自体はそんなに嫌いではない)。

自分をないがしろにする組織に、貢献しろとは無理な話でして、働いて欲しかったらこちらが良くしてあげなければならない: まともな給料を出す; 事務所はきれいにする; 研修には予算を出す; 自分がやりたくない仕事をおしつけない; ちゃんとした人と働かせる; 目を疑うような雑な仕事のメンテをさせない; そもそも仕事として成立していることをさせる。軽んじられていると感じたら、ちょっとでもやる気のある人はすぐに去りますし、そうでない人も組織を軽んじて邪魔をするでしょう。

こういうところは淘汰されたらいいのにと思うけれども、組織というのは意外にしぶといもので、なぜか存続しています。それは悪い組織であっても、支えている人がいるからで、こういう人らは世の中を悪くしているのではないかとさえ思います。仕事だからといって世の中を悪くしてよい法はないし、仕事はもっと尊いものであってもいいように思います。

私としましては、組織への忠誠心をもってもらって、組織に貢献しもらうためには、社員にはたくさん与えるべきだと思っています。給料・予算は経営者が決めることだから、私にはどうすることもできませんが、それ以外の私が操作できることに関しては、気持よく働ける環境を整えてあげるべきでしょう。それが仕事だというのもあるのですが、それが社会を良くすることだと信じているからです。それもかなり直接的に世の中を良くすることだと。仕事でやっているだけなので、当人からのお礼も感謝も求めてないのですが、仕事ですから会社からの対価は欲しいですね。

社員に与えるべきものといったら、学びです。会社というものはおっさんにこそ教育が必要だと思いますが、そうは言っても若者は学ぶことが多いし、学ぶ意欲が多少はありますので、何も学べないのはつらいものです。

逆に覚えることを覚えたら、返さなくても別の会社に行ってくれていいとも思います。人の入れ替わりが多いことが悪いこととも思ってないし、どこでも働けるしいつでも辞められるという状態になって、それでも働き続けたいと思えるところがよい職場だと思っていますので。会社の教育で得られたものであっても、能力に見合った給与なり機会なり環境を与えるのは、会社の責務であって、それをしたくないからと社員を囲いこむための人事制度を作ったり、学びを与えないというのは良くない会社だと思います。

私は良き師に出会えず(と自分では思っていて)、延々と無駄な時間を過ごしてきたので、自分がして欲しかったことは若者にはしてあげたいと、余計なお世話かもしれませんが、思うわけです。

実装に依存するな、仕様に依存しろ

仕様とはわかりくい概念です。辞書には次のようにあります:

製品や注文にあたって、あらかじめ定める仕上がり品の構造やデザイン。

仕様は発注者が定めて、受注者がそれに従うもののようです。仕様書を固めて、そのとおりに製造し、仕様書と照らし合せて完成品を検品する。一度つくっておしまいという工程であれば、これが全てでしょう。作って動いてで全てであれば仕様書なんて納品されたら燃やしてしまっても問題ないはずです。実際そういうスタンスのいい加減なところだと、仕様書は適当に共有フォルダに放り込まれて、管理もされていないでしょう。

しかし、仕様は実装を行う人や検査を行う人だけが参照するものではありません。仕様は、作る人だけでなく、使う人も従わなければならないものです。仕様として定められていることが満足されることを期待してよい――という約束事が仕様です。つまり、仕様とは利用者と提供者の「契約」です。契約とは双方が守るものであって、一方を縛るものではありません。

利用者は仕様にないことを期待してはなりません。同じ仕様を満たすやり方は幾通りもあります。ここではこれを実装とよびましょう。利用者は仕様に依存するべきであり、実装に依存するべきではありません。利用者は中身の実装なんて知るべきはないし、仮に知っていたとしても知らないふりをして、機能を利用せねばならないのです。このことを「デルメルの法則」と呼びます。

例えば、ある関数 getItem()AbstractItem というインターフェイスをもつオブジェクトを返すという仕様だとして、 ConcreteItem クラスを返す実装になっていたとしましょう。呼び出し側は次のようなことをしてはなりません。

ConcreteItem item = (ConcreteItem) getItem();

これの何が悪いのかというと、getItem()ConcreteItem 以外のものを未来には返すかもしれないからです。今は確かに ConcreteItem だけしか返さないかもしれませんが、そんなことを約束していなければ、他のものを返せれても文句は言えません。非互換だとか言われても、知らんがなとなります。

仕様に違反した使い方をして壊れたら、悪いのは利用者です。実装に依存するのは、ねこを電子レンジに入れるがごとき愚行です。

さすがに上記のような言語仕様で決められているようなものを、わざわざ無視して汚くしてしまう人は少ないですが、見た目に汚くないと人はしばしばこういうことをします。どこからか裏ワザを見つけきて、それを利用して問題を解決しようとするのです。どうも裏ワザを利用して問題を解決するのが、エレガントな解法だと思っているようです。

しかし、このような下手のハッカー気取りは間違っていまして、中身なんてどうでもよいことです。仕様書がないからブラックボックス化しているとしばしば言われますが、仕様書とはブラックボックス化するためにあるものです。利用者が中身に興味を示さないように用意するのが仕様書であるということを我々は理解するべきでしょう。