年越しだから新福菜館でラーメン食べた．チャーハンも食べたところ，チャーハンおいしかったけど，食べすぎた．おいしいとは思う．おいしいけど，食べすぎるというのはよくない．
View this post on Instagram
しかしながら，年末感というか，プレミアム感を出すために，普段はラーメン食べてるのに，チャーハンも追加するというのは，ベネフィット感があると主張したとして，誰かれも怒られることはないと思う．しかし，そもそも，たくさん食べればめでたいという価値観は，戦後にチューイングガム大量に噛むと甘みが増すとか言ってる時期で卒業すべきであって，このようなグローバルオポチュニティー世紀である21世紀に，世界中が貴重な資源を取り合いオポチュニティーな感じがあるのに，そうやって，たくさんチャーハン食べるとチャーハンのうま味が増すとか，わけわからないことを言ってる人がいるということこそが，このオポチュニテョー自体の，先走り感，つまり，一部の人は，そうやって合意が取れていても，その他の人からすると，ただちょうちゅお，蝶々とかを追い掛けてるだけなのに，なんで，そんなに責任を負う必要があるのか，オポチュニティー感が急に出てきても困るよ，私にだって，家族がいて，先祖がいて，墓があり，二階建の家と，向かいにはマンションもあるし，毎朝マンションの前の道の枯葉は掃いて回っておるのだよ，それが，君たちのような若造オポチュニティーに，邪魔される筋合いはないね，君達はそうやって，今はそうやって，地球のため，わたしたち地球，かけがえのない地球のためといって，うまいことをいって，協力しようとしているのだけど，それは，つまり，若い人たち，君たちはね，そうやってね，若い人たちは将来があるからといって，意識が高めに設定されている．つまり，どういうことかというと，ソフトウェアを作っているとして，めちゃくちゃな部分があるとして，いくつか，取り得る姿勢がある．一つは，俺は正社員であって，このような立場でも，会社からは認められているということで，めちゃめちゃなコードは置いといて，新しいコードを書き続ける．これは，どういうときにこうなるかということを予想すると，ベンチャーとかスタートアップとかで，数年以内に，このコードがめちゃくちゃに金を稼いで，数年以内に会社ごと売ってしまうので，金は稼いでいるから，品質はともかく，数年もちこたえれば良い，という形．こういうときには，数年後に自分が関わっていないのが分かるから，自分さえ理解していればそれでよい．それで，めちゃくちゃにコードを書いて，儲かって，自分が脱出すればよいという，そういう考えかたもある．まあ，自分が脱出しなくても，めちゃくちゃ儲かれば，それを支えてくれる仲間たちがやってきて，めちゃめちゃなコードを全部書き直してくれる，という形もあると思う．クックパッドは最初へんなコードだったのが途中からRailsになったという話もある．次にありそうなのが，自分はずっとこの会社にいるので，めちゃくちゃなコードであっても，自分が責任を持つ，だから，テストコードもなくていいし，現に金を儲けているのだから，これでいい，という考えかたで，これは，中小企業的で，うちのおじいちゃんも，顧客の名簿とかめちゃくちゃなのだけど，俺は覚えているからそれでいい，とか言ってる．これは自己犠牲的で美しいという話もあるけど，美しいのは当人だけであって，こういう状況では，息子とかも介入できないし，仮に新しい人を雇っても，こういうところに入って一緒に仕事するという形にはならないし，これではスケールしない．一番良い状態というのは，こういうコードで金をゲットしているのはおかしいから，ちゃんとした形に書き直しましょう，と言うことで，テストも書くし，リファクタリングもするし，ドキュメントもちゃんと書きましょう，という状態だと思う．これは意識が高いといって避けがちで，理想論という話もあって，きのう学生と飲んでたら，そんなのは理想論であって，トレードオフであって，うまくいかない，とか言われたのだけど，個人的には，エンジニアとしては，こうするしかないと思う．金ゲットだけを考えると，一番いいのは，すぐに売り抜けることだという話をしたとして，そうだとしても，売り抜けるのに失敗すると，数十年とか，そのコードをメンテナンスすることになる．リーンスタートアップもそういう感じだと思っていて，何度か資金のある限りピボットして，うまくいったら金ゲットみたいな感じだと思う．仮にそれに失敗したら，そこからはすぐに脱出しないといけないのだけど，エンジニアとしては，作った以上は責任を持たないとけない．そうすると，最初の数年はいいけど，あとの十数年はめちゃくちゃなコードをめちゃくちゃなまま維持することになる．それは避けたい．すぐに金ゲットして脱出できればいいのだけど，そういうのはエンジニア的には制御不能である．したがって，エンジニアとしては，会社の感じが変になると，ずっとそれをメンテナンスすることになるので，コードをきれいに保ちましょう，と言うしかない．いまのは極端な話だけど，コードがめちゃくちゃで，不利益を被るのは，エンジニアなので，エンジニアが声をあげて，そもろもこんなコードはおかしい，みたいな話をしなければならない，と思う．そうでなければ，他に言う人がいないので，納期の許す限り，どんどん品質が下がっていく．管理する人がいないのだから，当然である．品質を上げたいと思う人がいないのに勝手に上がることはない．そこで，経営的な視点を入れると，完全に不具合のないソフトウェアを毎回作れ，というのは，現実的でない．そういうことをしようとすると，証明付きのソフトウェアを作ることになるけど，そうすると，すごい時間がかかるし，こうこう，こういうタイミングでクリックしたときには，どうなりますか，とか，こまごました話が無限に出てきて，いつまで経っても完成しない．ボタン1つ増やしたいだけで，2年も掛かっては，ビジネスとして破綻する．というので，現実的な時間で終わらせる必要がある．経営的に見ると，テストとかドキュメントを省くと，一瞬は，とにかく早く終わらせることができるのだけど，長期的に見ると，テストない部分やドキュメントない部分で，将来的に困ることになる．だから，テストやドキュメントは書こうということになっていて，最近のモダンなGitHubを使ったワークフローでは，コードレビューもして．CIも通して，これだけやれば，masterにマージしてよい，ということになってる．世の中的にはそれで済んでるけど，最近は，それだけでは済まないと思っていて，つまり，テストやCIでは済まない，仕様の妥当性という問題があると思っていて，CIは通っているけど，なんでこんな仕様なのか，みたいな話になることがあって，理不尽な仕様なんかがあると，エンジニアの予想を越えるところで，理解しがたい構造が突然出てきて，交通事故みたいになる，ということがある．そういうのは，普通のチームなら，ミッションステートメント的なのがあって，たとえば，無料の電話を提供する会社なら，「広告は入るけど無料で通話できる若者向けの電話である」とか，そういうミッションステートメントの元に，チーム全員が同じ意識で，コード書いたり，機能を考えたりしてる．その中で，たとえば，ブルジョア向け通話機能というのがあったら，これはミッションステートメントから外れているので，やめませんか，とか，ミッションテートメントから外れているけど，これを続けるなら，そもそもミッションステートメントがおかしいので変えましょう，みたいな議論ができる．そこにチームが介入できなくなって，ミッションステートメントにも書いてないし，誰もやりたくないけど，他の理由で，とにかくやる，みたいになると，良くない状態になる．エンジニア的には，こういうプロダクトだと思って作っているので，そのためなら，多少の複雑性などは，自分達の能力でカバーするか，そもそも仕様が変ならよりよくしたい，という気持ちでやっているけど，それと外れる，政治的な都合などで，ここはこうするしかないみたいな，複雑性が増しているところがあるとしたら，ただの事故現場にしか見えないし，モチベーションを保てない．仕様を自分たちの制御下に置くことで，コードと仕様を一体化して，最適な解を探して，めちゃくちゃいいものを作っていたので，それが，片方取られると，良いものは作れないし，そうなると，言われたものをただ作る，みたいになってしまうので，クリエイティビティを発揮する機会もない．今日は年末だったので，蕎麦的なものを食べようと思って，ラーメンとチャーハン食べたのだけど，それが，政治的な理由で，ラーメンは未来永劫メンマ入りのみ許可する，みたいになってしまうと，それを上回るおもしろメニューとか出来るはずがないし，それを，メンマ入っても意味ないのでやめましょう，とか，ルールを変える手段もないようでは，せっかく，クリエイティビティある人が集まっているのに，その本来持ち得た能力を使えず，よそから降ってきた仕様を実装するだけ，みたいになるとしたら，本当にもったいないと思う．だから，ラーメンとチャーハンは完食した．
