概要
新卒のソフトウェアエンジニアとして就職して1年が経過するのでこれまでを振り返る。
結論
- 入社後しばらく抱いていた「満足に仕事ができないんじゃないか」という不安の多くは解消され、日々の業務をこなす程度ならそこまで難しくはないと感じた
- チーム向けのツールを勝手に作っていたら正式な業務としてチームの運用ツールを好きな言語で書けることになるなど、少し背伸びした成功体験も得られた
- とはいえまだまだできないことは大量にあり、終わりのない道を歩き始めたばかり（ヒカルの碁）
筆者の背景
振り返り詳細
この1年をいくつかのトピックに分けて振り返る。試験的に、今回は意識して散文チックにしてみたい。そのため話題があちらこちらへと飛び火する。
技術研修はありがたい
配属される前に数ヶ月の技術研修があった。これがかなり良かった気がする。内容は社内外の技術を使って、フロントエンド、バックエンド、DBを使ったWebアプリケーションを作成するのが主なものだった。この研修を受ける前の私と言えば、フロントエンドとバックエンドの違いを自分の言葉で全く言語化できず、CI/CDのやり方もてんで知らず、REST APIも多分わからない、つまりはど素人だったわけだけど、この一気通貫で概要をさらう研修のおかげでWeb開発の概観に対する直観を得ることができ、それまでWeb開発に対して漠然と抱えていたコンプレックスのようなものが多少解消されたように感じた。多くのプロダクトは、それ自体が複数のコンポーネントから成り立っており、このコンポーネントの区切り方は大体共通認識があること、だからこそそれぞれのコンポーネント間のやり取りには汎用的なAPIが既に提供されており、我々はその使い方を都度調べながら繋ぎ合わせることでシステムを組み上げることができるという認識を得た。そして、このコンポーネントへの分解の仕方、各コンポーネントの一般的な組み立て方、それらの間の連携の仕方は独創性というよりは覚えゲーなところ（特に初期段階）があり、よく言われる「（ソフトウェア）エンジニアは覚えることが多くて大変」という主張の、覚える対象が何を指しているのかということについて自分なりの答え合わせができた。Web開発に対して感じていたハードルが下がったことで何か作ってみたいという気になり、次のようなものを作成した。
- 漫画更新bot
- DBに登録されたweb漫画の最新話が更新されたかをチェックしに行って、更新があった場合はDiscordに通知するプログラム
- cronで毎日1回実行している
- 運用中に漫画が掲載される url と html の構造が変わって処理が失敗したことがあり、そういったイレギュラーに気づけるようにロギングや通知設定を見直した。作り捨てではなく使い続けるからこそ見つかる改善点などに気づけて楽しかった
- アークナイツの便利ツール
配属後の仕事の話
技術研修の後は配属先でOJTが始まった。配属されたチームの扱ってるコンポーネントは多く、必要になる技術領域も馴染みがなくて最初はキャッチアップにかなり苦労した。自分がわからないことを言語化・構造化してはそれをメンバーに尋ねるというサイクルをよく回したが、チームの方は嫌な顔せず毎回丁寧に回答してくれたのでありがたかった。様々なタスクに入りながら過ごしてしばらくしたあと、業務には、似たようなタスクが不定期にやってくることを実感するようになった。学生の頃の授業や部活の練習のように、習熟を目的として集中的に反復するのではなく、タスクは仕事上必要になったタイミングで発生し、それらのほとんどは似たもの同士に分類できる（その分類の種類は仕事による）。従って、一度経験したタスクを次の似たようなタスクに活かすためのメカニズムを外部に任せることはできない。ここで役に立ったのが自分のためのメモあるいはドキュメントだった。世間ではメモの大切さが謳われ、メモの取り方の本が出たりもしているが、自分はそれを大したことだとは思わず今まで一度もメモらしいメモをとったことがなかった。やってみると、メモは仕事以外にも色々役に立ちそうなことがわかってきた。たとえばTwitterのTLにはいつも有益だったり面白そうな情報が出回っているが、それをいつでもその時に摂取できるわけではない。一旦どこかにストックしておいて、後から適切なクエリによってそれを引っ張り出せるようになっているとありがたい。このクエリがディレクトリ構造におけるファイルパスのようなものだと管理が破綻するので、ではタグでやるのはどうかということで今はObsidianを試している。ただしやっぱり「いつ」「何を」メモから引っ張り出すかは本当に難しいので、この部分はAIがいつかやってくれるといいなと思う。一人一人の人生経験だけをDBのデータとして使い適切なタイミングで適切な情報を思い出させてくれる秘書みたいなAIができたらいいな。てか作ってみたい。業務効率化アプリとしての可能性を感じています。
働いてみての気づき色々
ソフトウェアエンジニアとしてチームで働くようになって、いくつか気づいたことを記す。
まずはスクラム開発？について。チームではスクラム開発を採用しているが、自分にはこれが初めてのスクラム開発（というか初めてのチーム開発）だった。ソフトウェアエンジニアリングに限らず、チームで何かを達成する際の問題解決フレームワークとして色々優れているなというのが全般的な感想で、たとえば中高生の学園祭の準備とか集団で何かを決めるときにこのやり方を知っていたらもっと上手くできたかもしれないと思った。スクラムは大雑把にいうと、こいつが関心のある対象のうち最小のものであるタスクを、チームの誰もが不確実性が低い状態で遂行可能にし続けることが目的で、そのためにリファインメントで曖昧な課題を噛み砕いて具体的な受け入れ条件の定まったアイテム（タスクの集合からなる）にしたり、日々のデイリーなどの振り返りで現状の進捗や肌感を共有しながらタスクの再定義や分配を行なっている印象を持った。ただこれができるかどうかはチームの抱えている課題の難易度と、チームメンバーの能力に依存するので、上述のような理想状態でいられることはほとんどないと思う。たとえばリファインメント対象が難しいものであれば、それを噛み砕ける一部の優秀なメンバーへの負担が大きくなってしまうし、チームメンバーのスキルがスクラムの要求水準に満たなければ、タスクを見積られた時間内に終わらせることは難しくなり、それへの適応として当人はプランニングの時点での稼働可能時間を少なく見積もるようになったり、デイリーでのタスクの再振分が頻発することで、スクラムが期待するようなアプローチにイレギュラーが発生する。ただこのような問題はおそらくありふれているので、妥当な解決策があるかもしれない。スクラムに関する有名な本とかもいくつかある気がするので、いつか読んでみたいかも。
続いてこれは社会的責任を負った企業のエンジニアなら普通なのかもしれないが、システムの安全性にすごく気を遣っていると感じた。具体的には、何をするにしてもその正常性の確認のために監視設定を入れたり、様々な観点から結合テストを行なったり、リリースがうまくいかなかった場合の手順やその遂行可能性なども厳しくチェックしていた。一方でこれらが全てプロダクトの安全性に寄与しているのか、しているとしてそれはどの程度なのかはまだ正直よくわからない。ただ静的検証の技術はまだまだ一般的ではない（そもそも目的の性質を証明する方法は現時点でも未解明かもしれない）ので泥臭く良いテストを考えるしかなさそう。
とある挫折、そしてRustという救済の光
社会人になってから経験したちょっとした挫折は、自分が技術的に興味のあることがほとんど共感されないことだった。最初に述べた通り自分は競プロからCSの門戸を叩いて、そこから同じく興味のあった数理論理学からプログラミング言語理論と型システムの分野にいきなりジャンプした珍しいタイプの人間なので、視野やスキルセットがかなり偏っている。好きな分野を答えてもそこから話を広げられず申し訳ない思いをしたことも少なからずあった。自分は何らかの性質を演繹によって保証することに興味があり、その保証された「安心な領域」を社会全体に広げていくことで世の中が生きやすくなったらいいと考えている。そのための手段として世界を記述するプログラミング言語に注目していて、OCamlやHaskellが好きだ。一方でプログラミング言語は非常に強い正の外部性を持つ。つまり、その言語がもたらす恩恵は、その言語自体の本質的な魅力だけでなく、それを使っている人の数、周辺ツールやエコシステムなどに大きく影響を受ける。一般的に広く使われている言語に比べるとOCamlやHaskellにはそのような強みは薄く、この外部性の恩恵に与れないまま、業務領域へのキャッチアップと並行してこれらの言語を使ってプログラムを書き続けることは、自分の能力ではかなり限界があると感じていた。
あるときRustに出会った。正確に言えばRust自体はずっと前から認知していたが、何かのきっかけでRustに入門した。
俺は「いつかやる」をマジでそのままの意味で使っているので、満を持してちゃんとRustに入門します。
— 逢瀬 (@ose20_) 2023年12月24日
とりあえずこれを読めばいいのかなhttps://t.co/0pKoz6Fxzb
まず、ヴァリアント型やパターン（もちろんワイルドカードパターンもある）マッチ構文、式指向なところがプリミティブとして備わっていることがすごく好き。こういった機能がプリミティブとして提供されているなら構文自体もその旨みを引き出そうとした設計になっていて一貫性があって扱いやすいという信念がある。逆にそうでなく、既存の機能をこう組み合わせればこういうこと"も"できるよといった言語では、まずそのテクニックを知っていないとできないし、それがデザイン(?)パターンとして認知されるまで時間がかかるし、なっても認知コストがかかるので、前者の言語との間にはやはり深い深い溝がある。Haskellなどと比べると抽象性はやや劣るけど、逆に、Haskellだと抽象性が高すぎて魔法にしか見えないところをRustは愚直にやっているところがあったりして、Rustのレイヤは一つ下なんじゃないかなという直観がある。だからこそOSや組み込みシステムなどのレイヤでも人気があるのだろうし自分も低レイヤには興味があるのであわよくばRustに連れて行ってほしい。あとRustの所有権やlifetimeの概念が自分にとってはすごくよかった。何でよかったのかというと、自分が修士の時に研究していたテーマと類似点があったから。自分はある特定の言語の型システムの設計とその型安全性の証明をしていたのだが、この体系で安全な型をつけるには変数が存在できるスコープを追跡する必要があり、型にもそのスコープが現れた。自分の体系はずっとひどくお粗末な気がしていたし、プログラマがスコープを書かないといけない言語なんか実用的じゃないんじゃないと思っていたけど、それをRustという人気言語が反証してくれた（Rustにはlifetimeパラメータが型に現れることがある）のが嬉しかった。もちろん自分の研究していた体系は素人のtoy programming languageなのでRustの足元にも及ばないし、そもそも型安全性の証明ができた（と自分が思った）のは修論執筆直前で学会の査読に通ったというわけでもないので客観的な事実としてはただの思い込みなんだけど、Rustに親近感と愛着を覚えるにはそれで十分だった。
Rustはその難しいという評判と打って変わって、周辺ツールやドキュメントは恐ろしく丁寧なところも好きだ。前述したようにプログラミング言語が普及するには正の外部性をうまく使うことが大事だ。開発に便利なツールチェインや丁寧なドキュメントは利用者を増やすことに大きく貢献する。自分もRust自身やRustを使った何かについて発信することで、いろんな人が心地よくRustで開発できるような環境づくりに少しでも貢献できたらと思う。
また、業務とRustの関わりだと、チーム内のとあるオペレーションを自動化するツールをRustで作って共有した。このおかげかはわからないが、今度は業務時間としてチームとして進める別のオペレーションを補助するツールをRustで作れることになった。今はどちらのツールも既に作業に組み込まれていて、自分にしてはすごくいい体験をさせてもらえてありがたかった。
来年度やりたいこと
今年度の振り返りとしてはこれくらいで、次は来年度にやりたいことを簡単に書き出す。
まず仕事がもっとできるようになりたい。チームのプロダクトやそれが依拠している技術に対する理解はまだまだ不足している部分があるので、引き続きできることを増やしていきたい。仕事はできないよりできた方が楽しいからね。一方で、自分のやりたいことと仕事の内容が完全に一致しているわけじゃないので、ちゃんと自分の興味に費やす時間も守っていきたい。あと友達を増やしたい。基本的に超インドア人間で仕事もリモートワークなのでプライベートで人とコミュニケーションを取る機会が非常に少ない。ただ友達を増やそうとして友達を作るのは難しいし自分にも向いていないので、自分が好きなコンテンツに関するコミュニケーションに対してもっと積極的に足を踏み入れていくところから始めたい。
終わりです。
