序
キャリア振り返りキャンペーンということで、Findyのお守りが欲しいのでざっくり自分のやってきたことや、やりたいこと、今考えていることなんかを、定期的に言葉にしておくのもよいかなと思い、書いてみることにしました。
あんまり細かいことは書けませんが、内省は大切です。
やってきたこと
地方大学の文系学部を卒業し新卒でSIerに就職、その後なんだかんだ同じ会社で10+n年が過ぎました。転職は一度もしていません。
- もともとは地元で公務員になるつもりだったのですが、軒並み落ちてしまいちょっと辛い思いもしました
- 今考えると、性格的に公務員としてうまくやっていけたとは思えないので、面接官の見立ては正しかったということでしょう
プログラミングに初めて触れたのは、その昔MacにバンドルされていたHyperCardというオーサリングツールで、子どもなりにゲームを作るなどして楽しんでいました。この経験が無ければIT業界で仕事をしようとは思わなかったでしょう。
業務システムの開発
私のキャリアの大半は、大きく分けて２つに分けられます。一つはBtoBの受託開発およびSES業務で、特に入社～5年目ぐらいまではいろいろなことをやらせてもらいました。言語で見てもCOBOLやVB6.0といった、私の入社当時ですでに"レガシー"だった言語から、ExcelやAccessのVBA、C#、Java、JavaScript、PHP、そしてTypeScriptまで。
- こうして言語を列挙すると、それほど多くはないなという感じもします
これらの開発の多くは顧客側の現行環境に影響を及ぼさない形で実施されていたので、最新バージョンでの開発など夢のまた夢で、.Net FrameworkやJDKのバージョンは数世代前のものが指定され、DBはちょい古めのOracleやSQL Server、場合によってはアレとかアレとかが指定されるという感じでした。
多くはウォーターフォール型の開発であり、プロトタイピングやイテレーションを回していくような比較的今っぽい開発の経験は、あまりありません（ゼロではない）。
開発はもとより、要件定義から概要設計、詳細設計、UT以降のテスト工程から納品まで、一通り経験できたので、システム開発がどのように進んでいくのかは、おおむね理解できていると思います。
- とはいえ、要件定義はまだ経験が薄いという自覚があります。もっと経験を積みたいですね
保守
もう一つはシステムの保守作業で、これも日常のトラブル対応から、数か月間の開発を伴うようなスポット案件まで、いろいろやりました。データベースのマイグレーションやシステムのバージョンアップ、急場しのぎのシェルスクリプト書き、といった技術的な内容もそうですが、システム利用者や他システム担当者との各種調整など、ソフト面のスキルというか、自分の中での折り合いの付け方はここでだいぶ鍛えられたと思います。
- 世の中には良い意味でも悪い意味でも、すごい人がいるものです
小規模なチーム
これは作業スタイルの話なので、業務システム開発の一環として、という話になります。
ここ何年かは、小さな開発チームを率いる、というと大げさですが、2～3人のメンバーに開発を任せて、私は主にレビューとテストの設計、顧客との調整を通して品質に責任を持つ、という形で仕事をする機会がちょくちょくありました。
悔しいことに、このスタイルでやった仕事は、私が自分でコードを書くよりも品質が良いです。まだまだ勉強が足りないのだと思いますが、岡目八目ということにしておきます。
危機感
こういう環境ですから、自主的に勉強しない限り新しい技術やフレームワークに触れることはほぼなく、自分の出来ることというのはなかなか増えないし広がっていかないです。
- プログラムはそこそこ書けているという自負はありましたが、せいぜい地元のゲーセンでは強い方ぐらいのレベルであり、スキルが可視化されるWeb上や転職市場で通用するようなものではありませんでした
このままだと技術者としての価値は漸減し、選択肢は閉ざされ、会社に依存するしかなくなってしまう。そんな危機感が特にここ数年で急激に強くなり、IPAのスペシャリスト試験を受けてみたり、Qiitaに記事を書いてみたり、Next.jsでブログを作ってみたり、ITエンジニア向けの転職サイトに登録してみたりしているわけです。
- 直近で転職する意欲はあまりないのですが、いざ転職しようとなったときに準備を始めたのでは初速が足りないので
- ところで、最近の転職サイトは（良い悪いは別にして）スキルや発信力を点数で出してくれたりして、ちょっと楽しいですね
心がけていること
上記の危機感から、自分が成熟するためにどうしたらよいのかを考えて、ここ2，3年で気を付けることにしたのが以下のことです。
- 十分に実践できているかはまた別の話ですが…
プログラミングに固執しない
やっぱり開発が好きですし、「俺は開発者だ」という自負も持っていますが、仕事でそれに固執することはやめました。プログラマーだから、マネージャーだから、営業だから、客だから、金払ってるから、金貰ってるから……というのが自負を超えて表出すると、おおむねトラブルになり、必要以上に状況を破壊することになります。
原典に当たる
Qiitaにはお世話になっているのでこんなこと書くのもアレですが、原則1次資料である公式ドキュメント、場合によってはGitHubでコードそのものにもあたります。少なくともそれを厭わないことが大事です。
- 最近だと、React、Drizzle ORM、Next.js、dnd-kit、Firebaseの各種Extensionのソースをちょっと読みました
知識より知恵
ネット上には「これをこうしたいときはこうすればよい」というHow toが星の数ほどあり私もお世話になっていますが、単にHowをたくさん集めてもあまり強くなれないという気がしています。なぜそれでうまくいくのかまで考えをめぐらせることを意識しています。これはプログラミングだけではなくて、ビジネス書や自己啓発書などでも一緒です。
今使える知識はもちろん大切ですが、反射的に出せるアクティブ知識に詰め込める量には限界があるので、多少時間が掛かっても都度必要なHowを導き出せるようになることが理想です。名前がついてた方が意識しやすいので、自分の中ではこれを論理的想像力というキーワードにしています。
- ゲームで例えるなら、Howを集めるのは一時的な攻撃力バフであり、Whyを集めるのはレベル上げです
- 他のプログラマーと仕事していて、この人仕事できるな、強いな、と思うときって、大体コレじゃないでしょうか？
Qiitaにはポエムタグのついた記事がたくさんあり、賛否あることも承知していますが、個人的には結構好きです。その人の考え方がわかるからです。技術的知見だけがプログラマーを強くするわけではないと信じています。
本を読む
上記に関連しますが、特定のフレームワークや言語の本だけではなく、「達人プログラマー」のようなプログラマーの心構え・考え方についての本や、その他ビジネス書一般も広く読むことにしています。
やりたいこと
これまでは受託開発がメインということもあり、私は一つの「プロダクト」に責任を持つ、という仕事をしたことがありません。
それもあって、自分がプロダクトの行く末を決める、そのために脳漿を絞る、そういうPdMの仕事には常にあこがれがあります。
今の仕事の延長でたどり着ける気は…まああんまりしないので、どこかで決断・意識のパラダイムシフトが必要になるんだろうなと思っています。とりあえず直近はプロダクトマネジメント系の本を何冊かあたってみようかな。
「やりたいこと」を周囲に言っておくと、案外叶うことがあるというのが、実感を伴う形でわかってきたので、漠然としたことでもいいので表明してみるのがおすすめです。
終わりに
ずいぶんと独り善がりな長い文章を書いたものですが、これまで自分のキャリアを振り返るということをしてこなかったので、キャンペーンが良いきっかけになりました。
この文章もまた、自分のキャリアを考える・振り返るきっかけになればと思います。
手の赴くまま書きましたが、nが二桁になる頃に、また振り返って答え合わせをすることにします。