そういうことは何度かある。大学生の終わりに研究ってものの入り口で少しだけ経験したのが最初。
自分はXMLと書誌情報データベースその活用方法みたいな分野の入り口にたって、周辺のあれこれを見て、検索エンジンの未来とインターネットの情報の所有権であるとか到達性であるとか機械可読であることによって変質するものごとについて考えることをしていた。考える、というのは、筋道を探す、その筋道の先にある、まだ見つかっていないことを探す、それが本当にまだ論じられていないことなのかを探す、などということです。SGML/XML/HTMLという変遷、パーサーの軽量化についての議論、エンドツーエンドの暗号化とかSOAPのエンベロープ拡張設計、高速なRPCの実現みたいな周辺議論はそこらへんでやっていた。
（まあ、これについては20年経ってLLMが劇的な実現性をもたらしてくれたような気がする。20年前の自分に教えてあげたい。いや、20年前だと逆に「20年後にはAIが発展して人間がボキャブラリを全てマークアップする必要はなくなる」と未来人に教えてもらったところで、ではその間の20年間はどうするんですかという現実的なことをやっぱり考えていたかな。ついていた教授が産業界の人だったので。）
キャリアのある時期にソフトウェア開発、スタートアップビジネス、小規模組織のマネジメントについて同じようにめっちゃ追ったことがある。こういう時にはこうなると言われている。実績もある。こういう力学が働くのでこの現象はこういう場面にも適用される。人間のバイアスってうこういうのがあるのでシンプルなインセンティブ設計ではうまくいかない。他の会社がこうやってくることは当然考えないといけない。自分はそのときインフラ部門の駆け出しだったので、視点は事業開発や商品設計よりはそれを支えるバックヤード側に偏って解像度が高い。
その中間の時期、炎上プロジェクトを渡り歩いていた時期はプロジェクトマネジメントと腕力についてずいぶん考えていた。最終的に自分が全てを担保すればよいという雑な発想で、綱渡りの進行を何度もやった。その後、それは偶然うまくいっていただけだということを嫌というほど理解した。もっと腕力がある人も失敗をするし、どう考えても自分がカバーできない問題についてチームで取り組まないといけないことがある。考えすぎてハゲそうではあった。死ぬほどスケジュール詰まっているところで大震災とかあって全てがグチャグチャになって、「どうしようもないこともある」という気持ちになっていた。それでもビジネス上、契約上の締め切りはやってくるし。一般論が役に立たない個別の事態に対して思考停止したくなる自分のストレス反応を、どうあってもコントロールしなければならない。pythonとJavaについてはこの時期にかなり詰め込んだ。開発プロジェクトは開発しようとするソフトウェアの将来価値に対して開発投資（つまり人件費とかだ）とランニングコストを天秤にかけて経営判断されるのだ、ということをプレゼンする側になってなるほど納得となったのもこの頃である。
とある仕事で、とある大企業の内製フレームワークと開発標準策定チームにいたことがある。そこでは日本全国津々浦々の公共事業や金融機関などで利用されるシステム開発を引き受けて、一定の品質を担保するための方法論について、ひたすら考えていた。自分は下っ端で、どういうわけかSESから途中で個人派遣契約になったりしていたが、下っ端である意識は特に持たずに最高にうまくいくものを作ろうとしていた。もちろん今の自分ですら手の広さはぜんぜん足りないので、どだい無理ではあったけど、そういう心意気を多少は評価されてはいたらしい。少人数スタートアップみたいなのとは全く違う方法論があり、リスクマネジメントがあり、長期メンテナンスしていけることを契約として盛り込むために、それが可能であることを保証するアーキテクチャを、さらにメタなフレームで構築しようという、割と壮大な取り組みではあって、うまくいっていたのかどうかは知らない（二年くらいで抜けたので） .NETとJavaのビルドシステムとかIDE拡張についてはこの時期に学んでいる。大学を卒業できず留年して教授の手伝いしていた頃やっていた、ソフトウェアファクトリー概念とやっていたことが結びついて面白かった、という経験をした（JavaEEを用いた企業システムの変化速度に対する内部的な分割の議論で、ソフトウェアの変化を促進するためにインターフェイスを公開して内側隠蔽しようぜとか、オーナーシップを持つ組織の力学についても考慮していて、今から考えればそのまんまマイクロサービスアーキテクチャやがな、と面白い）。ソフトウェアファクトリーの思想というのはビルディングブロックの集合としてソフトウェアをみなすこと、ブロックの集まりとして設計を行うことを可能にする抽象化、固有のロジックを可能な限り宣言的に記述できるようなボキャブラリの発明みたいな話であり、それができるなら大企業のソフトウェア開発もスケールするので。
そういう、ある種の問題の設定があり、その問題の成り立ちそのものや、先例も含めて周辺の議論を可能な限り隅から隅まで追っていくことに時間を使う、という仕事を最近できていない。強いて言えば、所属する組織のかたちをよく理解し、関わっている人たちを理解し、その人たちの固有の文脈において生じている非効率を発見して解決する、それによって煽っていく、というような仕事をしているのだけど、どこかでこれは面白くない・興奮しないというような思いがある。パズルを解いたり、思った通りに物事が機能する楽しさはあるのだけど、どこかそれは知識を整理して瞬発力で答えを出すゲームになっていて、自分を拡張できている面白さとはまたちょっと違う、というか。
