What is it, naokirin?

今後の進路決定があったので書き残しておく

決まったことがあるので、いろいろ書き残しておくことにします。

まずは内定

とある第一志望の企業に内定もらいました。
職種はソフトウェアエンジニアです。

身に余る高い評価をいただいたと思っているので、これから一年間いろいろがんばってみようと思っています。

これもひとえにこれまで指南していただいた方々のおかげです。Twitterでも、勉強会でも、大学でもいろんな方にお世話になりました。
ありがとうございます。

これからどうするか

ひとまず就活というものに追われることがなくなったので、自分がよりよい形で入社できるようにプログラミングやソフトウェア開発関連の知識や技術は貪欲に学んでいこうと思ってます。

ただそれ以前に大学院生なので、研究をしっかりすることも重要(というのは内定をもらった会社の社長さんにも言われました)。なので、その辺りはバランスをちゃんととりつつやっていこうと思ってます。
研究としては物理専攻なのでもちろん物理の分野ですが、場の量子論という分野の内容をやることになると思います。正直場の量子論と一口に言っても幅広いのですが、どの辺りをやるかは未定です。(多分もうそろそろ決めると思う・・・)

プログラミングやソフトウェア開発関連は、今は関数型言語OCamlと定理証明支援器のCoqをやっています。あとはC++Pythonに関してはもう少し深くやってみたいです。やりたいことに関して、手元に本もあるのであとはやるだけです。

アジャイル開発やソフトウェアテストに関してもちょっとずつではありますが勉強中です。私自身が非常に興味があって勉強しているのもあるのですが、入社予定の会社が今アジャイル開発を推進していることも上げられます。社長さんになぜ推進しているかを聞いて非常に納得できたというか、今まで少々腑に落ちていなかった点も解決の糸口がみえたので本を読みながらがんばっています。

なぜソフトウェアエンジニアだったのか

実際、ここが一番書き残したかったところです。
それは「なぜソフトウェアエンジニアを志望したのか」ということです。

私の場合、プログラミングは好きなのでそれ自体理由ではあるのですが、プログラミングだけであれば別にIT業界に入る動機付けとしては低かったです。大学1年の終わりからプログラミングを始めましたが、大学3年のころまでずっとただ好きなだけでIT業界に入って自分はそれでいいのかな思ってて、非常に悩んでいました。
ただ好きだったら、趣味で十分だと思っていました。まあ、IT業界はブラックばっかりというのは耳にたこができるくらい聞いてましたし、その中で戦うにはプログラミングが好きっていう感情だけでは私にとっては動機としては不十分かなと。
それは今でも変わらなくて、好きなだけだったらきっとIT業界ではないもっと別の業界にいっていたと思います。(もちろんIT業界だったかもしれませんが、ソフトウェアエンジニアのような職種ではなかった可能性も否定できないです。)

それが大学3年の頃に転機が訪れました。
とはいえそれほどすっごい話ではないのですが、友人の学科のグループ演習を見たのがきっかけです。内容としては簡単なソフトウェア開発を少人数のグループで行う、というものでした。まあ、実際のソフトウェア開発現場から比べれば非常に楽なものでしょうが、それでもグループでの開発で起こる数々の問題を目の当たりにしました。誰が悪いと指を指して言うことではなくて、

  • グループ開発になれていない(意思疎通ができてない)
  • オブジェクト指向言語(その演習ではJava)になれていない
    • オブジェクトの概念が理解できてない
    • コードが書けない
  • エラー(Javaなので実際はException)が読めない
  • テストがかけない
  • 仕様を理解しきれていない
  • そもそもメンバーの一部にやる気がない

といったもので、率直に言って「ああ、これがよく聞く『炎上するプロジェクト』ってやつの縮図なのかな」と思ったものです。実際は炎上する以前の問題を抱えていた気がしますが、当時はそんな風に思いました。
そのときに、「プログラミングは開発単位(もっというとプロジェクト単位)で見なければだめなんじゃないのだろうか」と感じました。「感じました」といっても実際のその段階では「プログラマ vs プログラム」では駄目だということをうっすらと意識した程度です。

この後、ソフトウェア開発自体に手を出してみたのですが、まだアジャイル開発という段階より前の段階でウォーターフォールモデルやスパイラルモデルと言った開発モデルを学習していました。(このころまで開発手法とかモデルなんてほぼ知識皆無でした。プロジェクトにおける上記のような問題を目にした後にウォーターフォールモデルの勉強を一からスタートとか、今考えると笑えないです。。。)

さらに友人がTDDに関連する卒業研究を始めたあたりから、自分自身もアジャイル開発に興味がわきました。
この頃プログラミングだけでなく、「プロジェクトを“良くする”」ということであれば仕事としてやってみたいのではないか、と思い始めます。それをしっかり行うなら、プログラミングやテストと言ったものを知っている、「(つまり現場と乖離していない)プロジェクトマネージャ」が一番の近道だと思いました。

プログラミング自体もこの頃から、オブジェクト指向言語だけでない関数型言語やその他様々な言語をやってみようと思い、

コンピュータプログラミングの概念・技法・モデル(IT Architect' Archiveクラシックモダン・コンピューティング6) (IT Architects’Archive CLASSIC MODER)

コンピュータプログラミングの概念・技法・モデル(IT Architect' Archiveクラシックモダン・コンピューティング6) (IT Architects’Archive CLASSIC MODER)

をやってみたり、自分だけでない人とやっていくときにいかにしてやっていくかをコードレベルで考えるために
Code Reading―オープンソースから学ぶソフトウェア開発技法

Code Reading―オープンソースから学ぶソフトウェア開発技法

CODE COMPLETE 第2版 上

CODE COMPLETE 第2版 上

を読みました。
この時期にIT業界を強く志望するようになりました。

最近感じたこと・思ったこと

それから1年半たちました。
まだまだ学び足りないことはたくさんあります。
人とコミュニケーションをとりながらソフトウェアを作り上げるというのは非常に大変です。それはこの1年半、そういったことを意識することで見えてきました。

最近までプロジェクトを“良く”したいなら「プログラミングやテストと言ったものを知っている「プロジェクトマネージャ」が一番の近道」だと思っていました。

でもそういうことだけではない気がしてきました。
私は「真の開発者」になりたかったのではないか、と思いました。
「真の開発者」というのは、「第一に開発のために、チームの一員として働くプロフェッショナル」ということです。
きっと開発を第一に、つまり「プロジェクト成功」を第一に考えたチームメンバとして働きたかったわけです。

おそらくプロジェクトを支えることは「プロジェクトマネージャ」や「チームリーダ」という立場がもっとも向いているのだと思います。
でも開発やプロジェクトを良くするのであれば、ただ「プロジェクトマネージャ」や「チームリーダ」になればいいということではなく、「真の開発者」として、「プロジェクトマネージャ」や「チームリーダ」になる必要がある、そう思いました。
つまり、まずは「真の開発者」としてやるべきことをやるのが近道だと。

というのが最近考えたことです。「真の開発者」ってなんだか厨二臭いですが、正しい開発者としてのあるべき姿だと信じています。だから私は第一に開発のために、チームの一員として働くプロフェッショナル、「真の開発者」となるべく、がんばります。まだまだ遠い道のりですが…


千里の道も一歩から、ですよね。