2000年代初頭を生きた42歳SEのキャリア論～半生を振り返って～

はじめに

こんにちは。
私は現在42歳SEで、元請けSIer企業に所属しています。社内での役割はSE兼ITコンサルタントで、お客様へのソリューションを提案したり、請けた仕事はプロジェクトリーダーとなって設計・実装・テスト・リリースまで一気通貫でやります。

年齢や役割もあり、後進のキャリア育成についても考えなければならないようなこの頃にあって、今回の「エンジニアキャリアについてあなたの考えをシェアしよう！」のキャンペーンを目にして、自分のキャリアを振り返る形で参加してみたいと思いました。

20年以上にわたるIT業界での略歴を記載しますと、次のようになります。

年	年次	業務形態
2003～	1年目	3次～4次請けSIerで、SESを中心に5年を過ごす
2008～	6年目	2次請けSIerに転職し、SESで同じ現場で10年以上過ごす
2019～	18年目	元請けSIerに転職し、現在に至る

今の若い世代はおろか、同じ現場で10年以上在籍し続けるなど、同年代にあっても参考になる方は少ないと思いますが、IT業界を生き抜いてきたという意味ではこういうモデルケースもあるかと思いましたので、何らかの参考になれば幸いです。

ほぼ半生を振り返っており非常に長いです。記号等も含みますが20000字近くあります。真剣にお読みくださる方は、休み休み読んでいただければ幸いです。

振り返ってみて、私の中の「気付き」だと思われる箇所を太字にしてあります。

情報化社会・IT革命といわれた時代

少年期

　私は人口20万人くらいの地方の市で生まれました。
　プログラマーになりたいなぁとぼんやり思ったのは小学校高学年くらいの頃でした。
　計算すると、80年代後半～90年代ということでしょうか。
　ファミコンが大好きだったので、漠然とゲームを作れるようになりたいなと思ったのです。

　思ってはいたもののプログラミングに触れる機会はなく、初めてプログラミングをしたのは中学生のときでした。
　友達の家に富士通のパソコンがあり、何かのBASICを動かすことができて、CIRCLE文で円を描いたりLINE文で線を引いたりして遊ばせてもらいました。緑色の円をFOR文で段々大きくしたあと、内側から黒い円で段々塗りつぶしていき「シャイニング」（※クロノトリガーというゲームにでてくる魔法）のアニメーションだと言い張っていました。これが初めてのプログラミング体験です。何か文字を打ち込んだら画面に現れる、それは本当に魔法のようでした。その「呪文」の組み合わせ次第でなんでもできそうな、無限の可能性が黒い画面の向こうに広がっていて、我こそはその世界の王であるぞという気持ちにさせてくれました。憧れのプログラミングは憧れ以上にエキサイティングだったのです。

　進路を決める頃には「情報化社会」やら「IT革命」やら言われ始めました。
　丁度Windows95がニュースになった頃合いです。まだクラスにはパソコンを持っている人は少なく、ワープロ（※）で文書が作れるだけでも「変わった趣味」でした。私はよくワープロで親のPTAの仕事で作る「懇親会のご案内」といったプリントを手伝っていました。

　（※）ワープロ
　正式名称はワードプロセッサ。様々な種類の文書を作るための機能を搭載した専用のコンピュータ。年賀状印刷のために一家に一台という時代もあった。

　そんな社会情勢もあり、もともとプログラマーになりたかった私は、地元の高専の情報工学科を志望しました。それに大学に行くお金がないことも分かっていたので、就職率99%と言われた高専のブランドが丁度良かったのです。ところが当時は田舎の高専でも情報工学科は人気学科で、倍率2倍以上は当たり前と中々難関でした。
　地元の高専は5学科あり、機械・電気・電子・情報・建築です。第三希望まで書けました。
私は勉強が得意ではなかったため試験は奮わず、情報工学科に落ちました。学科は伏せますが第三希望すれすれで高専には入学できたのでした。

青年期（プログラミング黄金時代）

　地元の高専には敷地内に「図書館」があり一般開放もされているくらい蔵書も多かったようです。
　それに各学科の授業で使うような専門書がありますので、私はよく情報工学の本を目当てに放課後に通いました。類は友を呼ぶで、パソコンに興味のある友達もできて、この本がよかったなどと情報交換をしあいました。もちろん専門的な内容は全然わかりませんでしたが、ライトな本もあり、点だった知識がつながっていくような感覚はありました。

　当時、家では父親のおさがりのPC-98でDOS-BASICが動くようになっていたので、BASICを覚えたかったのですがドンピシャの本はなく、全く関係のないFORTRAN入門のような本で「アルゴリズムは学べる」として読んだりしていました。インターネットが流通していない時代であり、とにかく「関係ありそう」で外堀を埋めていくような学びしか当時はできなかったのです。

　また、図書館の書庫と呼ばれる薄暗い部屋には雑誌のバックナンバーがあり、読者投稿プログラムを掲載していた「マイコンBASICマガジン」のバックナンバーの特集記事なんかもよく読み耽っていました。

　そのうち情報工学科の友人もでき、色々教わることができました。
　初めて簡単なゲームを作ってフロッピーに入れて友達に配りました。それが仲間内でうけ、次々と新たな作品を作りました。
　その頃私の書いたプログラムはそれこそGOTOしてGOTOで戻ってくるような酷いものでしたが、私はそれの何が悪いのかとさえ思っていました。
　しかし、情報工学科の友人が色々とサンプルを作ってくれたのですが、そのコードの美しさに衝撃を受け、それを改造したり部分的に真似をしたりすることで自分のプログラムスキルやコーディングセンス、プログラムに対する考え方などが飛躍的に洗練されていったことを覚えています。

　1998年頃には家でも電話回線でインターネットが使えるようになり始めました。
　私はホームページ作りに夢中になりました。まずそんなことは周りの誰もやっていなかったし、カッコよいものに思われたのです。
　デザインするのも面白く、特にFrontPageのようなツールなどは使わずメモ帳でHTMLタグをひたすら手で打ち込んで作ることに強いこだわりを持っていました。それが何かスマートでストイックなものに感じられ、またプログラムと同じような「呪文が形になる」錬金術的な要素も感じられ好きでした。私と同年代であれば

<META HTTP-EQUIV="Content-Type" CONTENT=”text/html; charset=Shift_JIS”>

くらいは何も見ないで打ち込める人もいるのではないでしょうか？

　そういった時代の中で私はプログラミングスキルとして、perlで掲示板やチャットなどのCGIと呼ばれるアプリケーションを自分で作れるようになりました。
　ローカルではHot Soup Processor（HSP）というフリーのプログラミング言語が好きでゲームやユーティリティなどを作っていました。実行ファイルを作って配布できるというのがよくて、いつかVectorにフリーソフトを出すんだと息まいていました。とはいえ、振り返ってみるとHSPで作品と呼べるような代物は1個だけですね。今は亡きFLASHのように画像にエフェクトをかけながら音楽とともに動画を流すようなアプリケーションを作ったのですが、それを使って、中学生が訪れる学校見学会のときに学科の紹介動画を作って流したのです。大真面目で小難しい言葉が散りばめられた学科紹介に突如現れたファンシーな動画に、中学生達は一様に笑顔になっていました（※私調べ）。嬉しかったですね。

　そんな中で就職活動もそろそろ始めないといけないという頃、私は初めてマイコンBASICマガジンにプログラムを投稿するようになりました。初投稿は箸にも棒にも掛かりませんでしたが、何回かの投稿のうち「今月の投稿者」に名前が載ったのが励みになり、ある時、遂に自分で考えたゲームプログラムが掲載されたのです。

　私は送られてきた掲載誌に自分の名前と原稿が載ったのを見て、夢が叶ったような気持ちでした。
　情報工学理論をちゃんと学んだわけでもない自分だって認めてもらえるじゃないかと。
　「コードが見やすい」「アイデアがゲーム性をよくしている」といった編集のコメントも嬉しかったです。

　このことが私の中では転機となりました。
　私はプログラマーとは、なんだかんだいっても情報工学を学んだ人がなるものだと思っていたのです。
　しかし雑誌に掲載されたことで社会に認められたような気がして、私はITの道を目指すことを決意しました。
　私の学科は情報とは縁遠いものでしたので、プログラマーのような職種の募集はないと思い、せっかく手に入れた就職率99%のブランドを放棄して、インターネットを使って自分でITの会社を探して応募しました。
（今思うと、同期でも情報系の仕事に就職していた者はおりましたので、私の思い込みだったのですが）

　特に流行していた「Webデザイナー」というものになりたくて、自分のホームページも武器にして就職活動をし、なんとか東京の小さなSI会社に就職が決まりました。

　こうして私のSE人生が幕を開けました。

3次～4次請けSES 時代

社内開発へのこだわり

この頃のスキルセット

分類	内容
言語	N88-BASIC、Perl-CGI、HTML、JavaScript
DB	なし
OS	Windowsクライアント系のみ
ツール	Word, Excel
資格	なし

　私が入った会社は経営理念では聞こえのいいことを謳っていましたが、自社で何かを作っているわけでもなく、ただ現場にSEを派遣しているだけという、2000年代にはよくあったSE派遣業の小さな会社でした。新卒採用は後にも先にも私しかいないような会社でした。社長は何か新しい事業をやりたがっていましたが、その何かがあるわけではなく、よく「何かないの？」と社員に聞いてきたものです。

　私は田舎の学生あがりで視野が狭かったため、「会社に毎日来てプログラムをするんだ」というスタイルに固執していて、現場に出ずに社内で作業したいとワガママを言っていました。　といってもそんなにやることがあるわけではなく、仕事がないときは学習したり自社ホームページの改訂などを担当していました。
　フロアにいるのは私と部長と社長と＋数名のエンジニアだけ。その数名も数日たつと現場に行く。事務もいない。私は新宿の雑居ビルでパソコンに向かいながらピンポンが鳴ると受付にでて応対し、お客様にお茶を出すこともありました。
　時々社長に、「なんかやりたいことがないの？」と聞かれても答えに窮してしまい、答えられない自分にもやもやする日々を送っていました。

　そんな私にも時々お金の発生する「仕事」を社内に持ってきてくれました。
　最初に携わったのはVB6とOralceの購買管理システムだったと思います。
　当時社内に5人くらいのエンジニアがいましたが支店からやって来たPLは、唯一の新人である私を明らかに舐めていました。実際VBはやったことがなかったので粛々と担当分を作りあげました。それが結構筋がいいねと褒められたので、学生時代に培ったコーディング力が生きたのではないかと思っています。

　私は趣味では相変わらずホームページ作りを続けていて、今はもう亡いですが「FLASH」という基盤にかなり傾倒していました。動画編集ツールのようにタイムラインにオブジェクトを配置して、オブジェクトにモーションと呼ばれる動きを定義できる他、レイヤーという概念があってそれらを重ねることができる。またActionScriptという言語でオブジェクトレベルにもタイムラインレベルにもプログラムを書くことができ、まさにデザインとプログラミングが融合したような総合開発環境であり、これ1つでなんでも作れるじゃん！　と思ったのです。FLASHからCGIを呼び出して、サーバーサイドで計算した結果をクライアントに返すこともでき、無限の可能性を秘めていると思いました。
　FLASHを勉強していたので、会社のホームページを改訂するときにFLASHのムービーを取り入れたり、Webサイトに自作のミニゲームを載せたりさせてもらえました。

　また、その頃「個人でサーバを立てる」ことがなんとなく流行っていて、私も自由にCGIやWebサイトを立ち上げられる環境があるといいなと思って、ヤフオクで買ったDELLのPCにFreeBSDを入れて、自宅にサーバーを立てるようなこともやりました。
　するとその経験を生かせる仕事も見つかりました。
　その頃は個人でもADSL回線を引いている時代だったのに、会社の支店にある自社サーバーの回線は1時代前の OCN の「専用線（128Kbps）」という代物で、日頃から社長にやりたいことないのかと言われて追い詰められていた私は、サーバーごと東京に移してADSL契約をしてコスト削減しつつ通信速度あげましょうと社長に提案したのです。
　じゃあそれやってみようかということになり、プロバイダの人と打ち合わせしました。外部の人に名刺を渡したのも初めてだったかもしれません。
　移行の日には休日出勤してFreeBSDのセットアップを行いました。
　メールサーバーはqmail、WebサーバーはApacheで個人サーバーを立てるといってもDNSはDDNSという仕組みしか使ったことがなかったため、BINDを使ったDNSサーバーを構築することは初の試みでもあり、そもそも周りに有識者が誰もおらず、責任重大で恐ろしかったのを覚えています。事前に本を買ったり、情報収集はかなりしました。（実際当日何かで躓いたのですが何とか解決できました。）
　失敗したら翌日から誰もメールが使えなくなる、そんなことを考えながらサーバー移転は無事終えることができました。深夜まで一人で作業し、非常に長い一日だったことを覚えています。

　また、CGIのスキルが活かせる仕事も舞い降りてきました。ある観光系団体のWebページでホテルの検索システムを作りたいということだったのです。
　私は得意のPerlと当時フリーのデータベースだったMySQLを組み合わせたシステムをリーダーに提案し、3ヶ月ほどで作り終えました。自分が作ったシステムが世に出るというのは感慨深いものでした。

初めての常駐プロジェクト（尊敬できる人との出会い）

この頃のスキルセット

分類	内容
言語	N88-BASIC、Perl-CGI、HTML、VB6、Flash、JavaScript、SQL
DB	Oracle(少し), MySQL
OS	Windowsクライアント, FreeBSD
ツール	Word, Excel
資格	なし

　ホテルのシステムを作り終えた後あたり、2年目くらいの頃になります。2003年頃でしょうか。私の中でいつまでも社内に拘っていてはダメだという意識がようやく芽生えるようになりました。社長に相談し、外に出ることが決まりました。社長に「変わったじゃん」と言われました。

　丁度社内の数名が行っていたプロジェクトで人手を募集していました。自動車会社のコールセンター向けのCRMソフトの導入プロジェクトでした。開発チーム・ナレッジチーム・技術支援チームといったチームがあり、60人くらいは稼働していそうなプロジェクトでした。
　私はここの現場のリーダーの人と一緒に技術支援チームという立場で入り、開発者のためのサンプル構築などをしました。
　このリーダーがすごい人だったのです。Oracle Pratinum保持者で、プログラミングの知見は深くて広い。それでいてリーダーであり物事を推進していく姿勢が周りからどれだけ信頼されているか。この人こそ一流だと思いました。私は外に出てよかったと思いました。

　それでもあるJavaScriptが動かなくてリーダーが困っているときがありました。私はCGIやWebサイト構築でJavaScriptもよく書いていたのでコードを見たときピンときました。Switch文の変数とCase文の型があっていなさそうだったのです。
　2000年代初頭のJavaScriptといえばどこでエラーが起きているのかさっぱりわからない、何なら動いてるように見えるが InternetExplorerが無言で「！」のアイコンを左下にこっそり表示している、そんなものでしたのでエラーの原因を見つけるのが大変だった覚えがあります。
　私は「ここをこうしては？」ということを伝えて、それが結果的にあたりでした。
　それから私はリーダーに信頼され、時には相談もしていただけるようになりました。

　そのプロジェクトには2ヶ月ほどしか在籍していませんでしたが、そのリーダーとのエピソードは思い出深いものがあります。
　私があるとき「それだと開発者の方が困るんじゃないですか？」と話したとき「このプロジェクトのどこに”開発者”がいるの？」と言われて面食らったのを覚えています。コピペしかできず創造性のないプログラマのことを揶揄して言ったのでしょう。
　また「誰さんが取締役で～」みたいな話になり、私は昔から他人の事情には興味を持てなかったので「そういうの知らないんですよね～」と言ったら 「知らないんじゃなくて知ろうとしてないだけでしょ？」 と言われてはっとしたことも覚えています。

2つ目の常駐プロジェクト（スキル発揮時代）

　私は自動車のプロジェクトの後、またすぐ別の現場に入りました。そこでは実に3年ほど過ごしたのです。
　この時代ですので、3次～4次請けくらいで入っていたかと思います。
　通信事業者向けのオーダー申込受付システムで、プロジェクト全体では100人規模、2次請けの会社ごとに領域を持っていて、画面チーム・外接チーム・バッチチーム・料金システムなど色々なサブシステムとチームがありました。私が入った会社は20人ほどが常駐している画面チームでした。私はそのさらに1領域である3～5人のチームに在籍しました。
　このときのリーダーは人望のあるタイプで私のよき理解者であり、私の能力をふんだんに引き出してくれたように思います。
　画面がCRMソフトのデザイナで作られた画面、バッチがOracleのPL/SQLで、主に画面デザインとPL/SQLを書くのが仕事でした。

　私はその頃は自分はプログラムの腕一本で食べていく存在なんだということに強いこだわりを持っており、業務を覚えようとしない人間でした。業務を覚える人は別の人の仕事で、自分はプログラムのエキスパートなんだ、と線引きして、関係ないことを知りたくないと拒絶していたわけです。その代わり、プログラムを作るのは速かったらしく、サンプルを作ることや、部分的な開発では「もうできたの？」といわれることが多かったので、許されている部分もあったのです。

　あるとき打ち合わせに出て、「あのコードなんだっけ～」とコード値の話になったとき、そこにいる誰もわかりませんでしたが、私はソースコードをよく見て覚えていたので「XXです」と答えました。それから私の発言力が高まったような覚えがあります。
　このことは私の成功体験の１つとして後輩には話してきたのですが「コード値を覚えていてコード値で会話できると強いよ」ということです。システムはコード値で動いているので、そのコード値をドキュメントを見ないといけないのでは遅いというわけです。今では個人の記憶に頼るような不確かな仕事は逆に違和感を覚えます。しかし、今のように会議室にノートPCを持ち込んでその場で調べられる時代でもなかったわけです。生き字引的な人はどこのプロジェクトにも一定数いたもので、そういう人に聞けばたいてい答えが返ってくる。「どこに何があるかを知っている」というのは、その時代の生存戦略の一つだったのではないかと思います。

　私は在籍期間とともにプログラムだけでなく領域リーダーの仕事を手伝うようになり、要件定義書に自分のチームの対応内容を書いたり、時にはエンドユーザーとの打ち合わせに同行したりするようになりました。
　エンドユーザーに触れる、このことは下請けで入っていた自分にとっては、実力が認められないとできない誇らしいことのように思われました。
　1つ成功体験があります。エンドユーザーの話を聞くようになってから、大分経ってからのことですが、話を整理するため仮の表にまとめたのです。横軸にユーザーのやりたいこと、縦軸に想定シチュエーションみたいな表で、ぶつかったところに「どうする？」みたいな。　すると、「○○さん、いい表作ったね」と言われて、それを叩き台として打ち合わせが開かれたのです。話を可視化することで物事が前に進むということを知った1つの体験です。

　また私はここで多くの便利ツールを開発しました。クリップボードを監視してエビデンスを自動でExcelに貼り付けるツール（流行らなかった）や、ソースをHTMLで成形するツール、ソースをPerl正規表現で検索するCGI、テストを半自動化するツールなど。
業務システムに携わっているプログラマにとっては自分の作ったものを使っているエンドユーザを見る機会は中々ありませんが、ツール開発ではユーザーはプロジェクトメンバーであるため、ユーザーの喜ぶ顔が見られ、フィードバックも得られるのです。
　また、ツールとはシステムの縮図であって、誤解を恐れずに言えば 結局のところシステムというのは、インプット→処理→アウトプットの集合体でしかない ということが、ツール開発を通じて肌感覚でわかりました。これらを如何につなげるかということで、システム間を補う技術にも明るくなっていきました。例えば一回TXTファイルに吐き出すとか、それをバッチファイルで拾えばできるとか。当たり前のことなのですが、その時の私にはその言語でできなければできない、という思い込みのようなものがあったのです。それがIN/OUTということがわかると、「この言語で書かれているからできない」と思っていたことが、「できる」という考えに変わり、色々なことに応用できるようになっていったのです。これはツール開発に閉じた話ではなく、後々の仕事においても非常に有益な発見だったように思います。
　さらにツールを作ろうとすることは課題意識を身に着けることでもあります。SEならば、業務の困りごとに敏感でなければなりません。Excelが重くて困っているお客様に「そんなの別にいいじゃん」と思っていたら仕事になりません。メンバーや自分が困っているからこういうツールがあったら便利だ、と思って作るのです。その感覚が大事です。SEはお客様の業務をシステムによって改善する人です。自分の仕事を改善できない人にどうしてユーザーの仕事を改善できるのでしょうか？
　このようにツール開発はSEの素地を作る上では素晴らしい行為ですので私は後輩にはよくツール開発をすべきというようにしています。

3つ目の常駐プロジェクト～初めての転職

この頃のスキルセット

分類	内容
言語	N88-BASIC, Perl-CGI, HTML, VB6, VBA, Flash, JavaScript, SQL, PL/SQL
DB	Oracle, MySQL
OS	Windowsクライアント, FreeBSD, HP-UX
ツール	Word, Excel, 携わったCRMソフト
資格	なし

　3年も在籍し、ほかのメンバーが毎日使うツールの開発者であり、チームのサブリーダーとして、共同他社との打ち合わせも行う。リリース前には椅子を並べて寝るくらい忙しかったですが、私は自分の仕事に満足していました。一方で、もっと上の仕事もしたいと思うようになっていました。例えばリーダーをやるとか。そしてリーダーになれないのは所詮下請けの下請けだから、責任ある仕事は任されないんだとその時は考えていました。
　そういうモヤモヤもあったのと、これ以上の成長があるのかを考えて、長年過ごしたプロジェクトを離任しました。

　そして1年ほど別のプロジェクトに参画しました。
　そこは銀行のバックオフィスのシステムでWindows2000Serverの更改をようやくしようというところでした。エンドユーザー→エンドユーザーの情報子会社→SIer→自社という結局下請けではありましたが、前のプロジェクトで自信をつけていた私は新しい仕事でもやれると思っていました。
　ところが最初の数か月は、前のプロジェクトがかなり居心地がよかったから出来ていたんだと思い知らされました。前のプロジェクトでは多少遅れたりしても残業したり泊まり込んだりしてどうにかなっていたことが、ここでは、しっかりと期限が定められコントロールされ、本来あるべき「仕事」に甘くなっていたのです。

　それでも、システムがわかってくると、プロパーの書いた設計書を渡されて、ここはどうなってるんですか？と考慮漏れを指摘したり、開発面でスピードを発揮できると段々と評価されるようになりました。思えばいつも発信することでプレゼンスが向上していったように思います。
　ここではAccessとOracleをつないだ帳票を結構直したり新規で作ったため、私はAccessについてもかなり自信がつきました。

　ただ、この頃は自分のキャリアとしてのモヤモヤはずっとあり、私は漠然と要件定義のような上流工程に携わりたいと思うようになっていました。
　下請けばかりの自社と低いままの給料にも不満を抱き始め、遂に人生初めての転職を決意しました。

　私は「自分で探す」ということになんとなくこだわりがあったため、エージェントに頼らずに探してみようと思いました。エージェントにお願いする＝人に頼る＝恥ずかしい、負け、みたいな感覚が当時の私にはあったのです。
　3年在籍していた通信事業者のプロジェクトでは色々な会社が領域ごとに参画していたのですが、私はそこで楽しそうに仕事をしているなと思える会社があったので、その会社のホームページから応募してみました。その会社であれば、要件定義に携われるくらいの規模であることは仕事を見ていて知っていたからです。つまり、元請けSIerの協力会社、二次請けの会社ですね。
　紹介ということではありませんでしたが、面接では御社の誰々と仕事をしたことがありますと話し、裏で彼らの働きかけもあったかと思いますが無事に採用が決まりました。ただ、私がそのプロジェクトに戻ることはなく、その会社の別の部署に配属されることになりました。

2次請けSESプロジェクト時代

業務知識を身に着けたきっかけ

この頃のスキルセット

分類	内容
言語	N88-BASIC、Perl-CGI、HTML、VB6、VBA、Flash、JavaScript、SQL、PL/SQL、DOSバッチ
DB	Oracle, MySQL, Access
OS	Windowsクライアント, Windows2000, FreeBSD, HP-UX
ツール	Word, Excel, 携わったCRMソフト
資格	なし

　私は初日に配属されたプロジェクトに最終的に10年以上在籍しました。
　機関投資家向け有価証券管理システムで、数社の機関投資家に納入し、新規の機関投資家向けにシステムテストをしているところでした。
　全体では100人くらいが常時稼働していました。サーバーはHP-UX、画面はJava、バッチ処理はCsh/C言語、EUC帳票がAccessVBA、夜間バッチはJP1で動く、C言語は珍しいかもしれませんが、それ以外はどこにでもありそうな大規模プロジェクトです。

　私の会社はそのときは5人くらいのチームで、その新規機関投資家向けサブシステムを担当していました。
また、そもそもが大炎上プロジェクトで、リリースが1年遅れているという状態だったのがようやくカットオーバーできそうというタイミングでした。

　このとき私は6～7年目というところでした。
　CもJAVAも趣味レベルでしか経験がありませんでしたが、コードは読めたので取っ掛かりは大丈夫でした。
　のちに「ANSI C言語辞典」を購入しますがバイブル的存在として最後まで使い込みました。

　そのような大炎上プロジェクトですからドキュメントが整備されているであろうはずもありません。一応、環境構築手順書なるものはあったのですが、あちこち情報が古すぎて今は違うのを使っている、みたいなことがありすぎて使い物になりませんでした。
　私の最初の仕事は、自分のチームのためにJAVAの環境構築手順を作り上げることでした。
　すでに環境ができている他チームの人の環境をキャプチャさせてもらったり、プロパーに新しい情報をくれとお願いしたり、自分で試行錯誤しながら数日かけてなんとか環境構築ができました。今までの総合力を試されるような局面でしたが、後から上司に「まさかできると思わなかった」という風に高く評価していただけたことを覚えています。

　また、話は変わりますが私はここまで資格をまったくもっていませんでした。
　前職で1～2年目くらいのとき情報処理試験の過去問題を見ましたが、全くわからなさ過ぎて、「あ、これ無理だ。」と思考停止していました。やっぱり専門の授業とか受けてないから無理なんだとそのときは諦めていました。

　転職した会社では資格に補助がでて年収もあがるというのと、今までの自分は仕事に関することや趣味に関するプログラミングだけをやってきて体系的な知識がないことが弱点だと思っていましたので、試験勉強をすることにしました。私は転職して1年強の間に、基本情報・応用情報・Oracle Bronze, Silver, Gold をとりました。体系的な知識が身について、またやったことのない分野でも勉強すればいいんだということがわかりました。

　そして、あるとき遂に要件定義の打ち合わせに参加することになりました。私は今までの知見が活かせると思いました。
　しかしそこで私は何も発言できなかったのです。そこで飛び交っている言葉も、背景も知らな過ぎたのです。
　業務知識を取り入れることを忌避してきた私はそこで打ちのめされたわけです。
　業務知識がないがゆえの失敗も多く経験しました。例えばユーザーの受入テストの質問に全く答えられなかったり、システムテストのやり方で実際の業務とはかけ離れたデータを使ってしまったため不具合を見落としたり。

　それから上司に諭されたのもあって、自分でも業務知識の必要性を感じて、業務知識を学ぶことにしました。
　仕事に直結する業務知識などありません。若者がよく役に立つことだけを教えてほしいと思うのと同じように、私も最初は関係なさそうなことを学びたくありませんでした。しかし、結局はそれを待って何もしないでいる間にも時間は過ぎていくこと、学んでも無駄にはならないだろうと思って踏み出しました。

　携わっているパッケージには会計システムも備わっていたので、まずは簿記から始めました。
　簿記3級なんて一ヶ月で受かるよという先輩の言葉を真に受けて轟沈しました。そのあともう一度勉強して受け直して合格し、簿記2級まで取りました（私は勉強が得意ではないので、簿記2級は3回かかりました）。
　また資格補助は出ませんでしたが、証券外務員二種というのが一般公開されていて取得しました。お金がでなくても自己投資する、そんなことへの必要性が7～8年目くらいでようやくわかりはじめていたのです。
　また金融関係の実務書も結構読みました。

　●『証券業務の基礎』

　●『生命保険入門』　※顧客が保険会社だったときに読みました。

　●『証券決済システムのすべて』

　●『金融読本』

　これだけやれば流石に結果もついてくるもので、業務知識が実務に活かされてきた実感も増えてきました。
　例えば簿記をやったことで会計システムの仕訳の仕組みが設計書に書いてあること以上に理解できるようになりましたし、要件定義の仕訳イメージをTバー(T字勘定)で分かりやすく表現できるようになりました。

　証券外務員資格や証券系の本を読んだことで金融を取り巻くお金の流れが分かり、機関投資家であるお客様がどういう立場で何をしたいと言っているのかが分かるようになりました。いつか上司が 「業務知識の基礎はプレイヤーだよ」 と言っていましたが、その意味が分かりました。金融であれば銀行・投資家・取引所・ほふり・決済機関などの各プレイヤーの役割とつながりを知ることで、学びやすくなるのです。

　そうしていつしか業務要件をお客様の言葉で記述できることになったのが「変わった瞬間」だと思っています。要件定義論はまた別の機会にと思いますが、お客様は自分たちが普段使っている言葉で表現されると理解できますし「SE」に対する警戒心も薄れるのです。

自分のやりたい仕事を目指して

　10年という在籍期間ですので、死にたくなるような大失敗も、自慢したくなるような伝説的成功もありました。
　私の操作ミスで本番DB定義を破壊したときにはどうしようかと思いました。
　また、私のコーディングミスが原因で障害が発生し、そのとき二重の判断ミスでリリース巻き戻しをする提案をしてしまい、上席に徹夜で説明対応に追われました。よく考えれば暫定対処さえすればリリース巻き戻しなんてしなくてもよかったのに自分の埋め込んだ障害だと分かっていたから焦っていたんですね。

　ぜひ成功体験も話させてください。ある案件の要件を聞きにプロパーとお客様の元へ同行したときのことです。
　お客様は今の枠組みでは実現が難しい要望を話されていて、うーんじゃあ取り下げですかねぇという雰囲気になり、同行していたプロパーもやむを得ないという表情でした。私は頭の中では「できる」と思っていたので、勇気を出して「こうすればできます」と言って、そこにあったホワイトボードにサブシステムとデータの流れの絵をサーっと描いたのです。その絵でお客様が理解してくださり、無事に案件獲得につながりました。600万円くらいの案件だったかと思いますので、私のチームもその案件でメンバーをしばらく維持することができたわけです。私は自分の腕一本で600万円を稼ぎ出したんだと誇らしかったです。そして、これがおそらく私がやりたい仕事の原点でした。

　この頃というのは、オフショア開発が台頭しはじめ、いずれプログラムを書く作業なんて無くなると言われていました。取引先の社長がよく「日本人特有の帳票文化を始めとする業務知識というのはオフショアに任せることはできないから日本のSEは業務知識を学びなさい」と言っていました。

　私はプログラミングが好きで業界に入りましたが、実のところ限界も感じていました。アルゴリズムやシステムの組み合わせによって問題解決するのは自信があります。しかし、メモリ効率、CPU負荷、言語のアーキテクチャ、そういったプログラムの本質的なものへの理解が浅いことが自分でもわかっていました。学生時代には、BASICでVRAMのアドレスに直接値を書き込んでPC-98とは思えない爆速のペイントツールを作ってウヒャヒャヒャと海老反りしていたような猛者が周りに何人もいたのてす。彼らのようには一生かかってもなれない。printfで標準出力にテキストを出力できることは分かっていても、それがどのようにして為されるのかは分かっていない。平たく言えばプログラミングを上辺でしか理解できていないし、理解しようという意欲も持っていない自分にこの先プログラマーとしての道を極めることの限界を感じていました。

　そんなときに業務の時代がくるという話は、私にとっては渡りに船というものでした。
　私は、自分の将来について考えたとき、先の成功体験のような仕事がしたいと思っていました。業務とシステムの仲立ちをするような役割にニーズがあるのではと。今もかもしれませんが当時はオールマイティは目指すべきではないと言われていました。「強みを持て」というわけです。お客様はどちらかでしか評価しないからです。
　であるならば、業務と技術両方のエキスパートであることを示せばいいのではないかと思いました。技術系も業務系も上位の資格を取ればいいのです。私は要件定義の専門家なら情報処理試験のシステムアーキテクト、業務の専門家なら証券アナリストだろうと思いました。
　仕事は毎日が繁忙期で常に終電という日々が続いているプロジェクトでした。そういう中で仕事をしながら勉強をすることは相当に大変でした。システムアーキテクトは午後2の論文だけがどうしても論理飛躍してしまい、毎年午後1までは受かるのですが論文で落とされました。ただ、努力とその間の実際の仕事の経験が生かされ、4年目には説得力のある論文を書くことができ、ようやく合格できました。実際、4回目の試験論文を書き終えたとき「これで落ちたら無理」と思える出来栄えだったことを覚えています。
　証券アナリストは、一次試験を受けるための教材をまず購入し、その後、証券・財務・経済の3科目に3年以内に受からなければなりません。一次試験合格後、さらに3年以内に二次試験に受かる必要がありますが試験は年1回しかありません。通常早ければ2年で2次試験まで合格するという証券アナリストですが、私は1年1科目ずつ3年ギリギリで1次試験に受かりました。その後二次試験は難しく、3年とも不合格となり、私は継続するか諦めるかを選ばなくてはなりませんでした。結果的には継続を選択したその年の試験で合格できました。志してから実に7年かかったのです。合格したのは、もはやこのプロジェクトを離れてからの話になります。
　資格を取得すれば称号として対外的に示せるという気持ちもありましたが、実のところ資格はその過程に意味があるものだと思います。資格をとるまでの7年間が無駄だったのではなく、合格のためには幅広く深く知識を身に着けて学ばざるを得ない、その学びの過程で十分スキルアップはしているのだと思います。

　1つだけ証券アナリストの職業行為基準の一節をご紹介します。（職業行為基準とは会員原則のような、ともすれば誰も読まないようなタイプの文書ですが、証券アナリストの試験では職業行為基準に照らし合わせた問題行動を指摘するというものがあるので、結構目を通すのです）

会員は、前項の業務を行う場合には、その時々の具体的な状況の下で、専門家として尽すべき注意、技能、配慮および勤勉さをもってその業務を遂行しなければならない。

　私はこの一節を時折思い出すと、SEもまたシステムの専門家としてこのような姿勢で仕事に向かわねばならないと、いつも心新たな気持ちになります。

　この頃、仕事のポリシーとして考えていたことは、いつも過去の自分と先人を上回ることです。
　SESの現場では現行踏襲、前例主義が横行しています。特に金融系は「固い」ので尚更でしょう。私も作業のプロセスを変えたわけではありません。ただ、要件定義書やシステムテスト仕様書は分かりやすい表現を目指して、図をなるべく用いて可視化の表現を高めることを心がけました。先人の資料が業務要件を文章だけで書いていたら、それを絵に表したものをつける。次の案件ではもっとわかりやすく出来るなと思ったら、さらにブラッシュアップした図にする。システムテスト仕様書はシナリオを表にし、フローで表し、どの部分がテスト範囲なのかを明確にし、ユーザーにとって利用マニュアルになるようなシナリオとエビデンスを作る。
　案件を追うごとに前回の資料を超える。いつも自分の中の集大成であること。 そんなことを繰り返していたら、「これは○○さんじゃないと作れないですね」と言われる資料を作れた時もありました。半分お世辞だと思いますが、追及していたことが認められた瞬間でもあり、素直に嬉しかったです。

2回目の転職活動

この頃のスキルセット

分類	内容
言語	N88-BASIC, Perl-CGI, HTML, VB6, VBA, Flash, JavaScript, SQL, PL/SQL, DOSバッチ, Csh, C言語, Java
DB	Oracle, MySQL, Access, SQL Server
OS	Windowsクライアント, Windows2000, FreeBSD, HP-UX
ツール	Word, Excel, 携わったCRMソフト, 携わったソリューション, JP1
資格	基本情報, 応用情報, システムアーキテクト, 証券外務員2種, 簿記2級, 証券アナリスト（一次試験まで）

　さて、プログラマーとして参画した私も10年も在籍していれば、年次とともに会社の立場も昇進しますしプロジェクトの役割もSEからPL/PMと変わっていきます。
　この間転職を考えたこともありましたが、まだやってないことがあると言い聞かせ踏みとどまってきました。実際、私はプログラム→設計→要件定義と担当領域を増やし、受け持つエンドユーザーも増え、チームのメンバーも増え、その間はすべて新しい仕事をしてきたと思っています。

　ただ、あるときお客様の次年度の案件ラインナップの打ち合わせに参加したとき、その話には加われない自分を見たのですよね。元請け会社のリソースにまで責任を負っていないと。

　最初に入った会社で責任ある立場でないと仕事を任せられないと悟ったのと同じように、これ以上の責任ある仕事は二次請けではもうないと分かったのです。あとは元請け会社の言うことを聞きながら、プロジェクトを維持していくための効率化やマネジメントをしていくだけなんだと。
　私の中で何か違うなと思いました。私は自分の手で作ったものに責任を持ちたいし、満足してもらいたかったのです。エンドユーザーとも直接会話する中で、もっと直接的な関係性の中で喜ばれたいとも思いました。

　その頃私は30代後半でした。もともとあまり変化が好きでなく、一つの道を究めたいと思う性格でしたので、まだやれてないことがあるなどと言いながら、最新技術から取り残され、金融しかやっていなくて、そのプロジェクトでは生き字引的な存在であっても、このままでは「レンタル何もできないおじさん」になってしまうと思ったのです。

　私は転職することを決意しました。コロナ禍の前年くらいの頃です。
　今度はエージェントに登録し色々な企業の面接を受けました。30代後半のエンジニアがお客様と近いところで仕事がしたいと願って転職する、エージェントによればよくある話なのだそうです。

　私は一次面接は結構通りました。今でも中堅SEは争奪戦が繰り広げられていますが、その頃すでに30代中～後半のSEは売り手市場だったのです。金融系の事業会社も受けましたが、事業会社を受けるには私の視座が低くフィットしませんでした。
　また、30代中盤なら鍛えられるけど、後半だとちょっとね…という会社もありました。私の方も一次面接を受けていくたびに自分がどういう会社に入りたいのかが明確になってきました。
　最終的には10社以上受けたと思いますが、その中で、一番ビビッときた会社に決めました。
　ポイントは受付・面接室の照明が明るかったことと（笑）、面接者の人柄が感じられたところでした。

実際、私が明るいと思った部屋で面接をしたのは2社くらいしかありませんでしたので、企業の人事担当者におかれては照明をケチらないことを提言いたします。中途採用は夜の面接が多いと思いますので、特に。

元請けSIerとしての現在とこれから

　私は今その会社で、SE兼ITコンサルタントという風な仕事をしています。自社製品だけでなく他社製品も視野に入れたソリューション提案というスタイルで、お客様の業務改善に全力を注ぐ仕事です。
　お客様の話を聞きながら価値ある提案をするために、事前の情報収集・業務理解に努め、ヒヤリングした雑談のような事柄を図式にまとめて認識共有する。システム化する上では経験に基づいたメリデメの提言をし、納得感を持っていただく。資料と説明の創意工夫で提案に説得力を生み出す。
　そういった自分自身の強みによって顧客の信頼を得て次の仕事につながった時は心の底から嬉しいです。
　過去の成功体験の時に感じた、やりたかったことが今できているのだと思います。

　これから先は、ITコンサルタントとして先頭に立って新しい仕事を切り拓き、後進に開発を引き渡していくようなスキームを作って、安定的に収益を得られる環境を作れたらいいなと思っています。また、同じように提案の創意工夫に面白味を感じてくれるメンバーを育てていきたいと思っています。
　それとプロフェッショナルとしてあり続けたいですね。
　そのためにはSEとして少しでも現場には関わっていたいです。現場から遠ざかって感覚がアップデートされていないのに意見だけする人にはなりたくないと思っています。

私のキャリア論

　ここまで読んでいただきありがとうございました。
　多くの先達が自分の人生を振り返って「チャンス」というものに言及します。
　私も、自分のSE人生を振り返り言及するならば「チャンスは突然訪れるものである」と言いたいです。
　チャンスはいつも前触れなく突然訪れるので、チャンスが訪れたときに掴めるよう日々研鑽をしておかなければならないんだと思います。
　研鑽をしていないがゆえに、要件定義の打ち合わせで発言できない（チャンスが訪れても掴めない）。
　研鑽をしているがゆえに、個人サーバを構築していたのが本社サーバー移転につながる、趣味のPerlが仕事になったりツール開発に使えたりする、システムの理解を深めていたからこそ、お客様の前で絵を描いて説明できる。

　あるいは順番が逆で、研鑽をしていることでその事柄への解像度が上がり、それまでの自分であればチャンスと感じとれなかったことがチャンスだと感じ取れるようになるのかもしれません。
　私は、ここでいう「日々研鑽」とは、毎日努力するということとはちょっと違うと思います。私は何も努力していない時期のほうが圧倒的に多かったので。
　ただ、仕事において今までの自分より（あるいは先人の成果物より）もレベルの高いものを作るという仕事観が、自分の仕事に学びの必要性をもたらしてくれました。そのことが、特に流動性・不確実性の高いIT業界のキャリア形成においてフィットしたのだと考えています。

　最後に本を一冊ご紹介します。
　以前知人からお勧めされずっと眠っていた本なのですが、今回の文章を書くにあたり「キャリア」への解像度を高めるために読みました。まさに今の時代、なぜキャリアを考えなければならないのか？という問いに対する自分なりの解を見つけられる良著です（もっと若い時に読んでおくんだった）。自身のキャリア形成に悩める若者やキャリア指導をしていくマネージャー層にもお勧めしたい一冊です。

　長くなりましたが、これで私のキャリア論を終わります。
　ご清覧いただき、ありがとうございました。