14年目のエンジニア・1年目からのふりかえり

明日から4月。
明日で社会人・エンジニアになり13年経過したことになる。
ここに来て改めて13年をふりかえってみたくなったので、まとめてみた。

1年〜3年目（2006年〜2008年）

とあるきっかけで、自分はある業界向けのパッケージソフトを自社で開発・販売している会社に新卒入社した。かっこよく言えば「ベンチャー」「スタートアップ」とも言えるが、小さな小さなソフト会社だった。

使用していた言語は、入社当初はVB6.0。その後製品のリプレースに伴いVB.NETに触れていく。

プログラムを書く事自体は楽しめていたし、対象となる業界にも興味が持てていた。しかし、業務時間以外に独学で勉強するといったモチベーションはなかった。プライベートな時間は趣味や友人達と遊ぶことに費やしていた。恥ずかしい話だが、社会人やエンジニアとしてのキャリアプランなんて全く頭になかったというのが正直なところ。

だが、今回のふりかえりで思い出したことがあった。

当時会社ではテストチームが発見したバグを、Excelで入力したレポートを印刷して開発者に共有していた。レポートに修正があれば再度印刷したり、手書きで直したりと、こんなフローを自分はとても無駄に感じていた。そのような状況の中、調べた結果、世の中には「バグレポートシステム」というのが存在していることを知る。
調査した中から自分はMantis Bug Trackerというツールを発見し、空いているPCにインストールさせてもらい、社内に展開。Mantisはたしか2年ぐらいは運用されていたと思う。その後、バグ報告以外にもタスク管理が出来るツールとして「Backlog」を発見。これも自分で発見して社長に提案した。Backlogはその後10年以上社内で使用され続けることになった。

また、ソースコードは当時ファイルサーバーで他のプログラマの方と共有していた。（！）起こって当たり前の状況なのだが、上書きミスして1日分の作業を捨てる事故を起こす。対策案を調べる中、世の中には「ソースコード管理ツール」というのが存在していることを発見。 IDEがVisual Studioだったこともあり、MSのTeam Founadion Serverを提案。
こちらも自分でインストールして社内で運用を始めた。

ここまでふりかえると、当時ソフトウェア開発についてはそこまでモチベーションが高いわけではなかったが、

業務フローにおいて無駄と思える部分を発見する
解決策を探す
解決策を提案・実施する

といったことがこの時点で行えていたんだな、と今回のふりかえりで思い出せた。

4年〜6年目（2009年〜2011年）

2009年頃はiPhoneの普及とともにiOS アプリ開発が盛り上がる。 2010年にはiPadが登場。社内でもiPadを使った製品の企画が立ち上がり、iOS開発に携われることになった。スクールにも通わせてもらえることになり、Objective-Cのスキルを身につけることができた。

さらに2010年頃からどういう風の吹き回しか、ビジネス系の書籍を読み始める。会社のしくみ、マーケティング、経済や世界情勢の本など。池上彰の本とか、「カンブリア宮殿」の書籍版とかを読んでいた。

この辺り、社員の動かし方とか商品の売り方とかに興味が持てたのは、自分は自社開発で、なおかつ小さい会社だったので、営業とか販売とかバックオフィスなどが、自分がよく見れる範囲に存在していたからだったのではないかと思う。

そして、読書の範囲はソフトウェア開発方面まで広がる。
ふりかえると当時ターニングポイントになったのは「オブジェクト指向でなぜつくるのか」だったと思える。
この書籍をきっかけに
・Java言語で学ぶデザインパターン入門
・リファクタリング
といった名著も読み漁り、テスト駆動開発/XP/アジャイルという概念を知ることになる。
当時はその他に、
レガシーコード改善ガイドや、アジャイルソフトウェア開発の奥義など、ディープな書籍にも手を出したりしたが、ほとんどきちんと理解できていなかったと思う・・・

このようなきっかけからか、この頃にはTeam Foundation Serverを使った自動ビルドや、自動テストの実装にも着手を始めていた時期だった。

7年目〜9年目（2012年〜2014年）

iOS アプリ開発をきっかけに、デザインやユーザーインターフェースにも興味がわき、
当時はUI関連の書籍をよく購入していた。

辺りがとても面白かった。アジャイル・サムライも2012年ごろに購入していて、
SCRUM BOOT CAMP THE BOOKも2013年頃。
仕事では実践する機会はなかったが、アジャイルへの「憧れ」は募るばかり。

また、この頃に業務でAWSを使用する機会があった。
クラウドコンピューティングにこのタイミングで触れることが出来たのは良いきっかけだった。

10年目〜12年目（2015年〜2017年）

10年目ということになり、引き続きメイン製品の保守開発でコーディングは行いつつ、リーダー的なポジションでマルチに動いていた。要件定義、ビジネスパートナーさんとの調整・成果物確認、リリース計画の管理と開発に関わることはすべて携わっていた。採用面接などにも参加し、自分が採用に関わった人が期待通りに成果を上げてくれるのはとても嬉しい体験だった。
一方、辞められてしまうのもとても辛い体験だったが・・・。

開発チーム内の人数も増え、ソフトウェア開発はチームをうまく回していく事が非常に重要で難しいことであると理解し始める。また、いわゆる企画・営業のビジネスサイドと、開発のエンジニアサイド間の協調にも悩んだ時期だった。
この辺りの軋轢がなぜ起こるかは、のちに「エンジニアリング組織論への招待」によって明確になったのだが・・・。上記の問題を少しでも改善したく、Backlog上での要望・要求と要件とタスクの優先順位を明確にするルール作りなどを積極的に行っていた。

トム・デマルコのピープルウェアなど、
チーム・組織についての書籍に特に興味が惹かれる時期だった。

そして人の出入りも多い時期で、様々な経験を積んだ開発者の方たちと出会い別れていく中、自分は1つの会社、1つの分野、1つの製品しか知らないまま、このまま時間が過ぎてしまっていってよいのか？という思いが募り始める。