4月からソフトウェアエンジニアとして働いています。すでにご報告はしましたが、学部時代に指導してくださった先生方には、改めて感謝を記しておきたいと思います。
学部時代には、小腸上皮細胞におけるペプチドトランスポーターの吸収メカニズムや、エニオン凝縮の圏論的一般化、数学では入学前から興味のあった∞-圏といった、それぞれの分野の先端に触れる機会に恵まれました。∞-圏については、モデル圏のDwyer-Kan局所化からはじめて擬圏への移行を再構成したり、(∞,n)-圏のSegal的アプローチについて取り組みました。いずれも第一線で研究されている先生方のもとで学ぶことができたのは、本当に光栄なことだったと思います。
所感
新卒での就職から一ヶ月ほど経って感じるのは、学問と仕事は思ったよりも地続きだということです。特に、問い方が大事であるという点において。学問は文字通り「問いを学ぶ」ことですが、ソフトウェアエンジニアリングでも事情は変わりません。先生に繰り返し言われたのは、PEPT1の輸送効率を調べたいという漠然とした関心を、測定可能な問いに落とし込むところが研究の本体だということでした。仕事でもまったく同じで、ユーザーが困っているらしいという観察から何を解くべきかを定式化するところに一番頭を使いますし、答えを出す技術は後からついてきても、問いの立て方を間違えると正しく解いても意味がありません。
そして、この問いを立てる部分にこそ経験が活きてくるのだと思います。ソフトウェアエンジニアリングではシンプルなやり方が好まれるので、シニアのエンジニアが使う技術はジュニアの私とほとんど変わりませんが、問いの角度や着眼点が違います。同じ問題を前にして、（エンジニアリングのプロセスとして）何を問題としてどの順序で手をつけるか、何をやらないと決めるか…経験が蓄積するのはそこであって、技術の引き出しの多さではないのだと感じています。だとすれば、この問いのセンスを意識的に蓄積させていくことに、エンジニアとしてのキャリアの価値があるのだろうと考えています。何より、そこにエンジニアリングの面白みがあるのではないでしょうか。
ドメインと問い
ソフトウェア設計の世界では、現実の複雑な業務（ドメイン）を紐解き、その核心的な概念をコードの構造へと落とし込む「ドメインモデリング」が非常に重要視されています。システムがビジネスの変化にしなやかに適応し、変更に強い状態を保つためには、業務の関心事とプログラムの構造が一致していなければならないからです。
しかし、この業務の真の姿は最初から自明なわけではありません。ユーザーの漠然とした要望や、複雑に絡み合ったルールの中から、真に解くべき問題は何なのか、システムにおける本質的な概念はどこにあるのか、と問い続けて整理しないといけません。どれほどきれいなコードを書く技術があっても、この問いを間違えてしまえば、実態から乖離した、変化に脆いソフトウェアができてしまいます。興味深いのは、関心領域を切り取る（ドメインモデリングや、問いを立てる）ことが、ソフトウェアの品質やエンジニアリングのインパクト両方にとって価値がある、ということです。
会社選び
ただし、これはエンジニアが問いを立てる側にいる場合の話です。就職活動のとき、この点をかなり気にしていました。日本では「エンジニア」という言葉がやや多義的で、同じ肩書きでも、自社プロダクトの課題設定から携わる人もいれば、多重の請負構造を通じて上流が定義した仕様を実装する人もいます。後者の世界では、その構造の中にいるエンジニアは、どれほど腕が立っても問いを立てる経験を積むことができず、何年経っても「答えを出す」側に留め置かれることになります。
どんなに優秀な学生でも、問いを与えられてデータを取るだけの環境にいたら研究者にはなれないように、環境によって蓄積されるものがまったく変わってきます。ちなみに私は外資系に就職したのですが、日系企業で就職活動をしたこともないので、語れるほどの違いはわかりません。需要があれば就職活動の詳細もいずれ書こうと思います。