kowさんは天ざる大好き

創作に絶望すると、世界が反転した日記

７月２８日（火）

日記

前日は寝付けずどうしても酒量が増えてしまった。睡眠時間は減るし睡眠の質は低下するし。アラームとの格闘に一度だけ挑んだがすぐにスヌーズを拒否。起床は七時すぎ。今日の仕事も人との対話ばかり。最近はこの役割が多いせいかちょっとだけ負荷が減ってきた。ダメならダメなりになんとかなるし、あまり怒られることがないことが分かってきた。

昨日と変わらない一日。皿洗いを拒否して仕事を開始する。平和な Slack のチャンネルたち。昨日との差異が何かすらよくわからない。オレは同じ毎日を繰り返している。オレは神経生理学的な限界を超えて世界を認識することができない。ありのままの世界は神経生理学を超越しているに決まっている。オレは再現性のある状態として保存されて永遠に再生されいるだけかもしれない。変化を感じることがオレに時間を感じさせる。むしろ時間という概念は必要せずこの世界に棲まうことができる。連続性すらいらない。離散的よい。離散的瞬間が順序だっていると認識さえできればよい。時間と存在はなんであんなに分厚い本になってしまったのか分からない。新しい一日にするために少なくとも昨日はやっていないとオレのアイデンティティが確信できるタスクをやる。なぜオレはこの組織でずっとオレのままなのかという問い、その問いは、なぜ共に成長できないか、という正しい問いにたどり着く。営利活動を拡大するなかでオレたちは成長し、オレたちが成長することで利益が拡大する。開発者にとっては自分たちがプロダクトの発展をコントロールできている自負と自信、経営者、ビジネスサイドからは自分たちのビジネスモデル、販売戦略がうまくいくことで開発に資金投資できているという手応えとやりがい、この成功体験のサイクルが大切だ。オレの見立てではそのサイクルには到底達していない。ニッチなビジネスだから競合がいないだけだし、先行している分有利だなだけ。むしろ将来の市場を開拓しなければジリ貧なのに正しい施策を打てていない。現代の健康ブームは個人的にはどうかしていると思っているし、生権力に対抗する思想がでてきてもおかしくない。楽観すぎる。開発全体としても個人的には技術志向、あるいは技術偏向といっていいかもしれない文化が蔓延している。ユーザーの要求やセキュリティ要求に対して技術的課題のみが議論されがちである。オレたちが理論物理学者とか研究職ならそれでもいいのかもしれない。それなら方法論はある程度きまる、あるいは方法論そのものを議論すればよい。一方で実際的なプロダクトをつくるオレたちは、いまあるプロダクトに整合するにように拡張し、継続的に運用と保守を行い、さらに将来発展できるように、誰もがソフトウェアを改善できるように改変を入れるということをしなければならない。そこには多少新しい技術の話があるかもしれない。それは要求の内容による。だが、実際に書かれるコードのほとんどはその技術的な詳細には関与しない。むしろ疎結合にするために関与してはならないともいえる。技術者はAWSの新サービスやGCPの新サービス、新しい概念やバズっているワードに反応しすぎである。k8s でマイクロサービスの夢をみて失敗する。それは自分たちが抱えている問題のほとんどは技術的課題だという問題分析の誤りに起因しているとおもっている。あるいは、「技術確認によって今の課題が解決する」という妄想によるものだ。ソフトウェア開発が困難である人が作って運用し保守するからだ。人は不確実で命令を遵守しないし、期待したことを達成する保証がない。そして人は居なくなるし、死にもする。コンピューターに正しい指示をし続けることによってソフトウェアは正しく動く。「失われた時を求めて」の続きを書け、といわれて絶望する、実際２０年もののプログラムの保守作業は存在する。当時の文脈、社会背景などを理解しいま、続きを書くなんてことは至難の業だ。プログラミングコードにも多義性はある。ある変数（記号）を違う文脈を使うことができるからだ。プログラミング言語として変数がどのように使われているかを分析して論理的に分解することで理解することはできる。しかしそのプログラムが複雑である場合い、その作業は途方ない時間をようする。循環的複雑度はコンテキストを指数関数的に大量に生成し、なんでもない変数（記号）を暗号にしてしまう。そういうコードを体験したエンジニアは大江健三郎の作品をとても好む傾向があることを知っている。リズムとパターンを理解し、推論と代数的な置き換えを試行錯誤をすることで確定的でない世界が浮かび上がってくる。大江健三郎はエンジニアリング的アプローチから文学に入門するには個人的にはオススメである。大江健三郎は文学における科学の側面を強調した。科学であるから文学は定量的に評価されるようになると言った。ソフトウェア開発はまだ工学の域に達していないというエンジニアは少ない。ただ新しいというものを評価する、WHY を意識せずただ課題を解決するかというだけでツールを選定し採用する。誤った正しいと確信する選択は硬直性うむ。硬直性はソフトウェアの発展性を阻害する。それに気づいて直すとき、そこにいるエンジニアはその技術を選択したエンジニアとは別なことがほとんどだ。そのとき気づくのは正しい技術の選定ではなく、たぶん正しい技術の選定とそれを置き換えることができるための仕組みをセットで考える必要があったということ。そしてそれをソースコードに実現すること、それが難しければドキュメンテーションとして残すこと。どのように残すかはその技術選定をしたアーキテクトに任せられる。境界を定義してインターフェースとその非機能要件を明確にしながら、その技術的詳細をの実装を捨ててしまえ！というやり方もある。オレはこれが好みだ。コラボレーション図を書いてそのメッセージの機能仕様、非機能要件までしっかりと書いておく。さらにインターフェースのユースケースをシーケンス図で網羅しておきたい。ユースケース図はその上位レイヤーとしてユーザーの操作からそのサブシステムにアクセスするパターンを網羅しておきたい。そうすることで、ユースケース図、コラボレーション図（アクティビティ図）、シーケンス図の順で必要な詳細について理解していくことができる。大事なのはインターフェースの先の詳細は理解せずにすむというところだ。ところがこれが昨日するためには UML とはなぜあるのか？　の理解も必要だ。一般的な理由とともに、なぜここにおいてこの UML を残したかというWHYも大事になる。UML 書きたいですか？　NO!!　みんなそうである。ソースを変えたら UML も変えないといけない。メンテナンスコストはゼロじゃない。ソースからわかれよ！　ソースは多義性を含んだ記号だといったな、あれを理解できるエンジニアがどれだけいる？　パフォーマティブな `public getWild() : Wild` とコンスタンティブな `public getWild() : Wild` があるかもしれない。そもそもなぜ、`getWild` という函数として命名する必要があるのか？　そこには何らかのドメイン領域の責務があると考えてよいのか？　テクストのことをしっていればそんなに難しいことではない。エクリチュールを理解しているならなお良い。プログラムの世界においても「もはや」断定的なことがいえない。文学とは違い断定的なことはいえるが、あまりにもありふれていてその価値が低下してきた。かつ、プログラマはソースの快楽を楽しむだけではすまない。原著を書き換えてリリースするときにはそれはチーム（自分たち）の責任だ。
「明日、世界が滅ぶとしてもわたしはこのコードを書く」という人がオレと一緒に働いている人にどれだけいるだろうか。ゼロだ。正しい。明日死ぬのに家族や親密な間柄の人と過ごさないのはどうかしている。一方で何かのアウトプットを出すことで世界とつながり具体的に関わりつつ自分を成長／アップデートさせていく人はいかほどいるのだろうとも思う。
技術偏向にはもう飽きた。技術エキスパートかっこいいのは今も昔も変わらない。でもお前たちの活躍の場はもう限定されている。むしろレッドシーである。優秀なアーキテクトが多すぎる。一方で偉大な現場マネージャーが少なすぎる。本当に大事なのはそこなのに。現場マネージャーは開発者よりも薄給で歯を食いしばって腐らずに頑張っている。
つまりオレはエンジニアとして無能で上位エンジニアになるのは無理そうなので妬んで批判しはじめたということですね。他意しない。ただ、ソフトウェア開発は面白いということだけは本当なので弁解しておきたい。

明日はもう会社休もう。イライラしてこんな日記を書いてしまった。薬を飲んで寝る。