りもじいはじめまして！
未経験者に向けた IT キャリアの入門ブログを運営している
りもじい です。
学生から社会人にかけて IT に関わって 20 年ほどになります。
転職したての会社で 4 ヶ月でクビ になるなどトラブルもありながら、その後の転職には成功し、自社開発企業で 10 年以上勤め、Web サービスや社内情報システムなど多彩な業務に関わりました。おかげさまでキャリアアップも順調に重ねることができ、サーバやネットワークを担当するエンジニアから始まって、最終的には会社の主要プロダクトのマネージャーを務めることもできました。
またプライベートな面でも、共働きの妻と 2 人の子供と家族 4 人で楽しく充実した生活をおくっています。
IT 業界と言えば革新的なイメージが強く、デキるエンジニアと言えば仕事にも技術にも前衛的でストイックな印象を持つ人も多いのではないでしょうか。確かにそういったスゴ腕のエンジニアもいらっしゃいますが、私はいたって安定志向タイプで、日々の生活、キャリアの考え方、仕事の進め方など安心・安定・安全を第一に考えてしまう性格です。かつて「石橋を叩いても渡らなそう」と評されたこともありました。
そんな私がこの度、安定志向のITキャリア入門 | 安心してエンジニアになるための 7 ステップ というブログ・動画による情報発信を始めることにしました。このブログ・動画では次の 3 点をコンセプトに情報をお伝えします。
- IT 未経験者にも分かりやすく
- 個人の実体験を絡めた見解を提供
- 7 つのテーマに分類して情報を体系化
このプロフィール記事では、次のようなことをお伝えしていきます。
- 私が IT の道に足を踏み入れたキッカケ
- IT 歴 20 年で得た経験と学び
- 自身の個性への向き合い方がキャリアに及ぼした影響
- この入門ブログが生まれるまでの経緯
IT キャリアやこのブログにご興味を持った方は是非ご一読いただければ幸いです！
IT に関わることになったキッカケ
はじめての HTML
中学か高校の頃に、自宅には父が購入した Macintosh がありました。シムシティや三國志あたりのゲームをしていた記憶はあるのですが、あくまでそれはゲーム機の延長にあった存在でした。
はじめて IT に触れたと感じたのは、大学生になってからです。とある機会に簡単な HTML を書いた時だったように記憶しています。
その時の自分はそのような事を積極的に学ぶ意欲や術は持っていませんでした。たまたま詳しい人とクラスで仲良くしていて、その人から「簡単にできるよ」といった類の言葉をかけられたのがキッカケになりました。それならと、大学内のパソコンが並んでいる教室で次のような簡易的な HTML をメモ帳ソフトで書いてみました。
<HTML>
<BODY>こんにちは</BODY>
</HTML>ブラウザで開いてみるとそこには入力したばかりの「こんにちは」という文字がちゃんと表示されています (画像は当時のものではなく「こんな感じだった気がする」というイメージです)。
当時の自分にとって、パソコンの画面に表示されるものは知らない誰かが難しい技術を駆使して作り上げたもの、というイメージでした。「え、こんな簡単なの？！」と感動したのを覚えています。
りもじい実際に書いた HTML の内容はもうちゃんとは覚えていないものの、その時の感情はいまだに覚えていますね。
大学のサーバ・ネットワーク運営で得た成功体験
ITに少し興味が湧いてきた時期に研究室を選ぶ事になりました。この時期に１つの成功体験を積み、IT の面白さに引き込まれることになります。
私が在籍していたのは情報系ではなく、サイエンス系の学部でした。しかしその学部には IT に力を入れ、学部のシステム管理を研究と並行して行う少し変わった研究室がありました。
その研究室では「物理実験」という名前の実習の中で、パソコンをパーツごとにわざわざ一度バラしてから組み立てたり、当時は手間のかかる Linux OS のインストールを行わせたり、簡単なプログラミングを学ばせるという意外な取り組みを行っていました。
それまで授業において得意不得意はあれど、面白いと感じる事は無かったのですが、この講義は初めて「楽しい！」と感じるものでした。
講義が面白かったのは、研究室に在籍する先輩たちもチューターとして多く参加しており、講義に力を入れていたというのもあります。ただ、ついていくのが大変そうなクラスメイトも少なくなかったので、個人的に相性が良かったのかなぁと思っています。
先輩たちはプログラムをカタタタッとキーボードで素早く打ち込んでおり、カッコいいなぁと思ったものです。
りもじい当時はプログラムは謎の文字や数字の羅列に見えてましたので、何かを参考にするでもなくタイピングしていく姿には驚きました。
そんなわけで、研究室はIT的な面白い事ができそう、という少々やましい理由で選ぶ事にしました。
研究室に属してからは本来の研究活動はそこそこに、IT関連の活動にのめり込んでいきました。色々させてもらいましたが、楽しかったなと思うものの一つに、研究室があった学術棟に無線ネットワークを導入した、というものがあります。
今でこそどこでもWi-Fiが利用でき、ご家庭でも無線が基本、というところが多いかと思います。しかし当時の大学はまだ有線LAN、つまりインターネット通信する時はパソコンにネットワークケーブルを繋ぐ、というスタイルが一般的でした。場所を移動するとパソコンのネットワークは一旦切れちゃう、が普通でした。
数台の無線LANルータを研究室のお金で購入させてもらい、いくつかの部屋に設置して回りました。学術棟全体は1台の無線LANルータではカバーできないため、複数台のルータ間で連携する設定を行い、移動時に通信が途切れないようにしたりもしました。
りもじい広さの点では家庭ではなかなか無いことだったので、設定後に学術棟の中をノートパソコンを持ってウロウロしながら、「おぉ、移動しても通信が途切れないなぁ。これは快適♪」と喜んでいました。
ただ、無線ネットワークは制限しないと近くにいる人が誰でも利用できてしまうという問題がありました。今ほどセキュリティに厳しい時代ではありませんでしたが、研究室や学部のネットワーク内に建物の近くに来た人が簡単につなげてしまうのは困ります。一方でシステム運用が専業の人もいないので、利用者一人一人の機材の無線ネットワーク利用の設定作業を誰かが手動で行うということもできません。
ここでプログラミングに触れる機会が訪れました。学部には既にプログラミングに長けた先輩達が作ったユーザ管理システムが存在していました。今時のようにブラウザからフォームに対して氏名や所属などの必要な情報を入力できるようになっています。これで学部共通のサーバにアカウントが発行されて利用可能になる仕組みが整っていました。
先輩たちと相談し、このシステムに手を加えて、無線ネットワークの接続に必要な情報も入力してもらうよう改修することにしました。無線の機器情報を利用者と紐づけ、申請者のみが無線ネットワークを利用できるよう方針も固まります。
先程の実習でプログラミングの基本は少し学びましたが、本格的にプログラムに触ったのはこれが最初だったように思います。もちろん初めから書けたわけではなく、しばらくはひたすらプログラムを読み込んでいました。幸いマニュアルは整備されていて、システムに詳しい先輩も近くにおり、動作試験のためのテスト機材にも困りませんでした。恵まれた環境の中で、プログラムをいじってみたら動かなくなったり、といったことを何度も繰り返しながら徐々に修正を加えていきます。
周りの方の助けも得つつ、基本的には自分が中心となって無線ネットワーク利用のためのシステム改修を完了できたように記憶しています。完成した時の喜びもさることながら、改修後のシステムや設置した無線ネットワークを研究室の仲間たちが便利そうに使ってくれることが嬉しかったです。
これらの経験は次のような成功体験を自分にもたらしてくれました。
りもじいIT による自動化は面白い！
周りの人からも感謝されて嬉しい！
その後 20 年ほど色々とありつつも、自分の中で IT 技術について好意的な感情が強いのはこの体験のお陰かもしれません。
大学〜研究所〜自社開発 Web サービス企業での様々な経験
プログラミングの進化から学びの面白さを体験できた大学時代
その後の大学生活は本来のサイエンスの研究を脇に置いて、IT に関して興味に任せて色々学びました。 それ以前は受験勉強の経験もあって学びはしんどいという印象でしたが、この機会を通じて 学ぶことの面白さを体験 することになります。
この時期は、Fortran （フォートラン）という伝統的なプログラミング言語と、 Ruby （ルビー）という新しめの言語を学ぶ機会がありました。
 Fortran |  Ruby | |
|---|---|---|
| 登場年 | 1954年 | 1995年 |
| 主な用途・利用シーン | 天気予報や宇宙に関する 計算など、大学 や研究機関での 利用が中心 | 多くのウェブサイトや アプリ開発に利用 |
| 実行速度 | 極めて高速 | ウェブサイトやアプリ としては利用するには 十分に速い |
| 書きやすさ※ | いろいろ面倒 な場合も多い | 書いていて 楽しい |
その当時はこの両方を使う必要があったので、それぞれの良さを理解して活かす必要がありました。言語の特徴を理解する中で、プログラミングをしてきた先人たちが何を望み、それがどのように形になってきたか、についても少し想像が及ぶようになってきました。
例えば、「洗う」という動作があったとして、食器に対して洗うことと、衣類に対して洗うことは、実際に行う作業は異なりますよね。プログラムは理屈っぽく融通が効かないので、「スポンジに洗剤をつけて食器をこすって汚れを落としてから泡を洗い流す」であるとか、「洗濯機に衣類と洗剤を入れてスタートする」など具体的な手順を伝えてあげる必要があります。それに対して相手が人なら大抵の場合、「洗っておいてもらえますか」とお願いすると対象物 (食器 or 衣類) に応じて適切に行動してくれますよね。
Ruby では「対象物」を意味する「オブジェクト」と表現されるプログラムのセットの中に具体的な手順を組み込むことができます。食器と衣類用にそれぞれオブジェクトを用意しておけば、「洗う」という指示を出せばそれぞれ適した動作が行われるわけです。なお、このようなやり方はオブジェクト指向プログラミングと呼ばれるのですが、 Fortran はこのような考え方ができる前の言語なので、具体的な手順を直接指示するプログラミングが必要です。
これを聞いて
それは便利でいいね！ 新しいプログラミング言語を開発した甲斐がありますね！
そりゃ便利かもしれないけど、プログラミング言語をわざわざ新しく開発までするようなものなの？
とそれぞれ感じる方がおられるでしょう。Fortran のような言語でも同じ結果を得ることはできますし、「どう書けるか」という問題でしかないわけです。プログラミングする人がちょっと楽になるだけの、非合理的な行動と言われても反論は難しいかもしれません。
ただその時の私は、そのようなちょっとした楽をするためにわざわざ新しい言語を作っちゃうような変な人たち (良い意味) がいる IT の世界に魅力に感じ、ワクワクしました。そのおかげなのか、この時はプログラミングの概念や技法など、新しい情報が頭の中にスルスルと入ってきてとても楽しかったと記憶しています。
中学校まではそこまで勉強嫌いではなかったものの、高校あたりから勉強=つまらない、の意識が芽生えてしまい、受験勉強では知識の詰め込みであったり 1 つの正解を緻密に求めるプロセスなどが苦痛でした。大学に入ってからも勉強や学習に対しては強い苦手意識が残ったままでした。
インプットした知識から頭が活性化して想像力が豊かになり、様々なイメージが湧いてくるという経験は、学びって面白い！ という実感をもたらしてくれました。
ITエンジニアの役割を客観的に見ることができた研究所時代
研究所への就職後は大学で手がけていたテーマは手放し、新しい取り組みにチャレンジすることになります。技術スタッフとして研究用の実験的な大規模データ活用システムの構築と運用に携わりました。ここでは IT エンジニアに期待される役割の大きさを目の当たりにすることになります。
大学時代は周囲に研究仲間や先輩、指導教員はいましたが、自分の研究は自分のもの、という感じでプログラムもほぼ一人で手がけていました。研究所では、データ活用システムの構築や運用においては外部の IT 企業と連携し、システムの活用面では研究機関の研究者とコラボするなど、より幅広く人と関わるようになります。
私は研究所の技術スタッフという、研究者と IT 企業の担当者の中間のような立ち位置で動いていましたが、それぞれの違いが印象的でした。
 研究者 |  IT 企業 担当者 | |
|---|---|---|
| 創造性 | 優れた発想 に恵まれる | 基本的には 実績ベース |
| 探求性 | 白黒つくまで とことん追求 | ほどほどで 切り上げ |
| 実務力 | ざっくり | カッチリ |
| 協調性 | マイペース | チームワーク 重視 |
りもじいもちろん実際には十人十色ですので、あくまで平均的なイメージになりますけどね。
どちらが良い悪い、ではなく得意分野が異なるんだなぁ、と感じていました。適材適所になればプロジェクトは成果を上げ、ボタンを掛け違うと途中でつまずいてしまいます。
私が経験した現場は、研究所がクライアント、つまりお客さんであり、 IT 企業側がホストになります。研究者は自由な方が多く、優れた創造性を発揮して華々しい成果をイメージすることは得意です。しかし、そこに向かってチームをまとめて着実に結果を出すのは不得手な傾向にありました。ゴール地点をどこに設定するか、実現性も兼ね備えた上手い落とし所を探る経験が少なかったのかもしれません。
成果を上げたプロジェクトの多くでは、 IT 企業の担当者がゴール地点をどこにするか、研究者と綿密に協議しながら上手くコントロールしていました。ゴール地点を IT 企業側に都合の良いところに決めつけて進めてしまうと、最後になってどんでん返しが起こるリスクがあるため、これを回避するための工夫に見えました。
もちろんこれ自体は私が経験した状況下における一例です。このような交渉力があらゆる現場で求められるわけではありません。IT 企業の中にいれば、協議や交渉とは無縁に、プログラミングなどの IT 系技能のみが求められる現場もあるかと思います。
しかし IT 企業においても、経営層など上の立場の人ほど抽象的な表現をすることが多く、具体的な表現は現場に近いチームで考える場合があります。例えば自社開発企業において、次のような分担を行うシーンもありうるでしょう。
| 内容 | 担当 | |
|---|---|---|
| 方針: 抽象的 | ウェブサービスのユーザーを20%増やす | 経営層 |
| 企画: 概念的 | モバイル環境の最適化により ユーザ体験を改善し、 新規ユーザー獲得時 の取りこぼしを防ぐ | プロダクト マネージャー |
| 開発: 具体的 | モバイルに最適化した登録フォームを開発 | 開発チーム |
どの立場にいるにせよ、隣接する立場から期待される内容を理解したり、期待する内容をうまく伝えないと歯車が噛み合わなくなってしまいます。少なくとも自分が直接関わる人とは、お互いに理解し合えるコミュニケーションを図ることが大切です。
この後に別の職場に移り、そこでは自分自身が IT エンジニアとなるわけですが、その前にプロの IT エンジニアと一緒に仕事をする機会が得られたことは幸運でした。
この経験を得ることで、 IT エンジニアに求められることが単にプログラミングの技能や IT の知識だけではないことを知りました。相手の要望を理解し、具体的な解とその妥当性を示すことも期待されるということを、実体験とともに理解できました。それだけ現場では IT エンジニアに期待されることが幅広く、業務のレベルが高度である分だけ希少価値が高いということにも理解が深まりました。
実務による技術の深化を経験したインフラエンジニア時代
研究所で数年勤めた後、より多くのユーザが利用するシステムに携わりたいと考え、Web サービスを自社開発している企業に転職しました。この現場での経験が、IT エンジニアにとっての実務の価値の高さ への理解を深めることになります。
この企業で提供していたのは、お客さんの多くは企業や自治体という、いわゆる BtoB と呼ばれるビジネスモデルのシステムでした。
数百社のお客さんがビジネスのために利用するシステムであるため、サービスが動かなかったり、おかしな動きをするとお客さんのビジネスに悪影響が生じてしまいます。結果として、信頼の損なってお客さんが離れてしまったり、損害賠償を求められる可能性もある世界です。
そのため、企業ではお金と時間をかけて、サービス品質を高めるために次のような取り組みを行います。
- サービス提供の前に入念な動作テスト
- サーバなど機械の故障でサービスが停止しないよう、複数の機器でシステムを構成
- システムの異常を自動的にエンジニアに通知する仕組みを整備
これらは大学や研究所の中で、ユーザが少人数のシステムにしか触れてこなかった自分にとって、初めて踏み入った領域でした。
しかしそれでも、トラブルは起こる時には起きてしまうものです。そのような場合には、サービスの緊急の復旧対応や、お客さんへの事情説明に追われることになります。お客さんからは「同じようなことは二度と起こさないでほしい」と要求されることもしばしばです。お客さんとしては安心してサービスを利用したいですから当然のお願いでもありますね。
多数のお客さんが利用する自社開発サービスに責任を持つ企業として、再発をどのように防止するかは自社で判断します。その方針を定め、具体的にどうするか検討を重ね、最終的にはサービスに反映させていきます。具体的な内容には触れませんが、10年以上勤めて、次のような様々な観点で見直しを行う経験をしました。
- プログラム
- ハードウェア
- ソフトウェア
- ネットワーク
- 監視システム
- 運用手段
- サービスポリシー
- 組織体制
振り返って思うのは、就職して実務を経験したからこそ実践的な深い技能が得られた ということです。
今は 「IT エンジニアになるためには？」といったウェブの情報が多数あります。IT 学習系のオンラインサービスも手軽に利用でき、プログラミングスクールで実際にエンジニアと学ぶ機会も得られます。以前に比べて IT キャリアをサポートしてくれる機会はどんどん増えていると感じます。もちろんそれらは IT キャリアにとって間違いなくプラスなのですが、得られる技術や知識の深さは実務とは大きく差があります。
こうなってしまうのは仕組み的にやむを得ません。サービスを提供する企業にとって、技術を深化させることはお客さんからの信頼の維持や回復につながります。企業が生き残り、成長する可能性を高めるのであれば企業がそこに人とお金をつけて努力するのは自然な流れです。
一方で、お客さんのような特定の相手がいない状況では、具体的な目的も立てにくいですよね。自由に学べるという事は、なにか特定の方向に技術を深堀りするモチベーションを得にくいということでもあります。
一定の IT 基礎力を身につけるためにウェブの情報、学習系オンラインサービス、プログラミングスクールを活用するのは大賛成です。一方でその先で安定して IT エンジニアとしての価値を発揮できるようになるには、技術の深化が報酬とつながる実務に触れることが不可欠ではないのかなと思っています。
チーム内の相互の信頼関係の重要性を痛感したマネージャー時代
Web サービスを支えるサーバやネットワークに加え、社内情報システムの管理も行うなどいろいろな業務に携わりましたが、その後 IT チームのマネジメントにも挑戦することになりました。ここでは苦い失敗も経ながら、チーム内の相互の信頼関係の重要性 に気づくことになります。
エンジニアチームのメンバーとして入社した際はこれまでの経験もあったため、いくらか状況を俯瞰する力が身についていました。チームの状況を認識し、マネージャーやメンバーが何に困っているか、会社にとってチームに期待されていることは何かといったことを意識的に把握しようと努めました。困っている人の力になったり、期待に応えれば感謝されますし、信頼されて良い評価を得ることができます。そのような意識や努力、そして運もあって、入社から数年後にはチームを率いる立場を任されることになります。
しかしここから、マネージャーとしては長い停滞期 に入ります。プレイングマネージャーとしてチームの役割はそれなりにこなせていましたが、メンバーとの信頼関係は徐々に希薄なものになっていきました。
主な理由は メンバーへの信頼の不足 だったように思います。仕事をこなすために、自分のやり方を押し付けるような進め方をしてしまっていました。「詰める」こともよくありました。メンバーとしては自由度の少ない、窮屈なチームと感じていたのではないかと思います。そのようなことを続けている中で、徐々にメンバーは離れていってしまいました。
りもじい今になって冷静に振り返ればこのように表現できるのですが、当時はその方法が最善であり、良かれと思ってやってしまってたんですね…。それなりにデキるマネージャーであると自認してしまっていました。
転機は会社で行われた管理職向けの研修でした。研修は組織開発支援などを行うコンサルティング会社が企画したもので、2日間に渡って他社の方とも一緒に座学やワークが行われました。そこで次のような気づきを得ることになります。
- メンバーを対等な相手として尊重し、信頼して任せることで、人それぞれの個性が強みとなり、それが長期的な組織の成長につながっていく
それまでの私は、信頼とは管理職や経営層に対してメンバーから得ていくもの、という考えがありました。自らはそれを実践して結果を出していたので、メンバーにも自分と同じように信頼される行動を取ることを求めていました。
そのようにメンバーに期待することは良いのですが、私の場合は信頼するに足るとする水準を自分とほぼ同じところまで引き上げ、その上でマイクロマネジメントまでしていました。結果としてメンバーの個性は活かされず、私のやり方がさらに幅を利かせるという負のループに陥っていました。
りもじい当時の自分を振り返ると失敗したなぁということも多く、メンバーのみなさんには申し訳ないことをしました…。
これに気づいてからは、意識的にメンバーの仕事の進め方には口を出さないようにしました。仕事の結果が良くないものになってメンバーが困ったら相談に来てもらうというスタンスに変えていきました。
しばらくすると、私からの余計な口出しがないのでメンバーの仕事がスピーディになり、また自主性も高まってきました。私自身も本来の仕事の時間が減らない分、気持ちに余裕が生まれます。その結果メンバーとの関係性が改善して仲良くなることが増えました。
仲良くなると会話のテーマも自然とプライベートな事にも及び、相手のバックグラウンドを深く知ることにもつながります。これまでは上司と部下という相対する関係だったのが、対等な仲間としての関係に徐々に変わっていくのを感じました。
その後のことになりますが、人間心理学を学ぶ機会がありました。マネジメントについて知ろうとすると人の心にも関係してくるため、その流れで得た機会でした。その中では、危機感や欠乏感を原動力としたり、孤立した状況での活力の発揮は長続きしにくく、そのスタンスで活動が続けられる人は全体の 2 割程度であることが述べられていました。
その一方で、多くの人が長期的に行動量を増すためには、まず第一に自分の存在が脅かされず安全であるという安心感を感じていること、その上で仲間と繋がっているという感覚がプラスに強く作用する、とありました。これは人間という生物が高い社会性、つまり集団を形成して協力して活動することで生き延び、繁栄してきたという生物としての特性に由来するものであるそうです。これは研修での気づきとも繋がる内容で、私個人にとっては経験と照らし合わせても大変しっくりくる考え方でした。
ITの世界は日々進歩し、常に新しい問題に取り組むことになります。そのスピーディな解決には情報収集→仮説→検証→結果測定（=情報収集）、というループの高速回転がカギであり、行動量をいかに増やせるかにかかってきます。
リーダーやメンバーなど立場の垣根を超え、お互い対等に感謝や尊敬し合える状況であれば、お互いが前向きで元気になり、自然と行動量が増えていきます。これが成果と自信につながり、さらに行動量が増える正のサイクルが生まれます。
このような 相互に信頼できる関係性こそ、安心して IT キャリアを育む環境として理想、というのが長い失敗を経て学んだ教訓となっています。
安定志向な個性の否定から肯定へ：自己理解のキャリアへの影響
さて、ここまでは IT に関わるキッカケやその後の様々な経験や学びについてお話ししました。順風満帆なキャリアを歩んで、立派な実績を残した印象を持たれたかもしれません。
しかし内面的には 自分に自信がなく、できるだけ挑戦を避けて歩んできた人生でもありました。
ここからは私の内面にフォーカスして 20 年のキャリアについて振り返ります。
保守的な性格を認められず自信がつかない青春期
今にして分析してみると、自分に対しての自信のなさは 自身の保守的な性格に対しての否定的な考え が原因だと考えています。
私の基本的な性格は臆病、いわゆる「ビビリ」でありまして、危険や恐怖はできるだけ遠ざけたくなります。ジェットコースターとかホラー映画とかの「怖いから楽しい」系のエンターテイメントは全然分からなかったりします。バンジージャンプとかやったことないですけどホント無理だと思います…。
幼い頃に同い年ぐらいの子たちと池でイカダっぽいもの（分厚い発泡スチロールで作られてました）に乗っていて、「これ転覆するんじゃ？」と怖くなって途中下車したこともあります。サッカーでキーパーやらせてもボールが飛んでくると思わず避けてしまうぐらいのヘタレであります。
今ではこれも 1 つの性質であり、裏表の裏側でしかないのかなと捉えられるようになりました。しかし幼少期から青春期にかけては、このような自身の性質を強く否定する考えを持っていました。保守的な性格であるがゆえに、正の面を伸ばすのではなく、負の面を消すべきだと考えてしまっていたのでしょう。
自分の欠点に日頃から意識を向け続けると、自信はなかなかつかないものです。自信がないと未来は希望よりも恐怖に感じます。そのため、自分の未来の姿を描く気にならず、将来どうありたいかを考えることも避けるようになっていました。
楽しいことだけで勝負を挑んだ 20 代
IT と出会って「面白い！」と感じたのはそんな時でした。面白いことに取り組むとそれまで自分で考えていた以上に力が発揮できます。「自分が楽しいと思える事でなら勝負になるかもしれない」、といったことを考え始めます。楽しいことに夢中になることで経験は得られました。特定の技能について自信が得られた部分もありますが、 1 つ落とし穴がありました。それは、楽しいこと以外から目を背けてしまった ことです。
自分の保守的な性格を否定する考えはこの時も変わっていません。従って楽しいと思って自信を持てたこと以外については自信はやはり足りないままです。むしろ楽しいこととそれ以外との自信のギャップは大きくなっていたのかもしれません。
IT に興味があったのであれば、私が 20 代の当時でも IT に関連する就職はいくらでも可能だったと思います。しかし、大学と一般社会との環境の変化を過度に恐れ、楽しいことだけでどうにかできると期待しました。同じ場所に居続けようとしてしまいます。
しかし、大学は本来研究の場であり、また情報系の分野にいたわけでもありません。その結果、研究者としても IT エンジニアとしても半端 な存在のまま、20 代を終えることになります。
りもじい大学では指導頂いた先生や先輩たちには大変お世話になっていたので、半端な成果のまま出てきてしまって申し訳ないことをしました…。
IT業界への進出と 4 ヶ月での解雇
大学での研究者としての先行きに困難さを感じ、30 代となりようやく大学から外に出ることになります。社会人として実績を積みたいと模索する中で、安心と安定を求める自分にとって 想定外の望まざる経験 も得ることになります。
1社目にあたる研究所では、情報系の研究職へ転向する道もありえました。しかし論文を読み書きすることに心動かず、結局ここでも IT 絡みの仕事に没頭してしまいます。この研究所は技術職に対しては一時雇用の形態を取る職場のため、研究者にならない限り長居することは難しい場所でした。はじめて IT に触れてから 10 年ほど経っていましたが、ここでようやく IT エンジニアとして身を立てるべく IT 企業に転職することを決めます。
2社目は、いわゆるスタートアップ企業に入社することになります。当時は Facebook や Twitter (現 X) の利用者が増えて人気になり、いまや当たり前になった SNS が世間一般でも注目を集めだした時期でした。この企業ではそんな時流に乗って新しい SNS サービスを始めようとしていました。
IT エンジニアとしての実績がなかった私がそのような企業に入社できた理由はよく分かりません。IT の経験が多少はあったことや、少々キャリアが変わり種だったところを面白いと思われたのかもしれません。
結果オーライと言えばそうなのですが、この時の転職活動は苦戦をしていました。やはり実績がないのが大きかったと思います。年齢も 30 を超えていましたしね。応募先はスタートアップ企業に限っていたわけではなく、様々な業種に対して行っていました。大手企業にも中小企業にも応募していました。大半は書類選考で落ちましたし、面接してダメだったケースもありました。こちらが選ぶ余裕はなかったのが正直なところです。拾ってもらってラッキーだった、という転職だったように思います。
新しい職場は 20 名弱の少数精鋭で、私より若い方も多いながら、IT エンジニアの方はみなキャリアとしては私より先輩でした。オフィスも私の入社の数ヶ月前に新設されたもので綺麗でオシャレです。全員が自社が提供するサービスに興味を持ち、自発的な意見を持っていました。活発なディスカッションも多く行われます。私も刺激を受け、IT やビジネスなどの学びを自ら行うようにもなります。
ところが入社して 4 ヶ月目、新しい生活にも慣れた時期に、さらに得がたい経験をすることになります。
ある日、スタッフが一人一人呼ばれて社長らと会議室でミーティングをすることになりました。オシャレなオフィスだけあって、会議室はガラス張りになっていて、誰が会議しているのか普段の席からもよく見えます。ふと目をやると、今は自分の上司が社長らと会話しているようです。近くの同僚と目があったので軽く挨拶などしたのですが、どうも少し元気が無いように見えます。その時は「気のせいかな？」と普通に仕事を続けていました。
さて、自分の番となり、会議室に行きます。そこでの話は、要するに 解雇宣告 でした。会議室に呼ばれた人たちは解雇対象者であったようで、半数程度の方はクビになったと記憶しています。私の上司にあたる方も辞めることになりました。元気がなかった同僚は、私より先に解雇宣告を受けていたのでした。これはその日の夜に催された、解雇されたメンバー同士での飲み会で知ります。
社長からは色々説明を受けた気はするものの、詳細は忘れてしまいました。忘れた、というよりは内容に対しての興味を失っていた、が正しいかもしれません。社長の話を聞く中で、「あぁ、これは解雇される流れだなぁ」と冷静に判断している自分がいて、「さて次はどうしたもんか」を考える頭になっていました。
従いましてここからの解雇の理由については、あくまでも私個人の想像になります。要するに考えていたビジネスが上手く立ち上がらなかったので、やり直すために身軽になろうとした、ということなのだろうと想像しています。雇う人を減らせばそれだけ経費が減りますので、次のビジネスを立ち上げるまでの時間に余裕が生まれます。スタートアップ企業の進め方としては必ずしも悪い方法でもないのかなと理解はできます。また、ポテンシャル採用のニュアンスが高かった私を解雇対象に含む事も残念ながら妥当とも思います。
しかし私としては「早すぎでしょ…！（焦）」という気持ちでした。これまでの経験に IT エンジニアの実績が乗ればその後のキャリアの選択肢はいくらか安定するかなと期待していたのですが、さすがに 4 ヶ月では実績としては短すぎます。またゼロから転職活動かと思うと不安は大きかったです。
りもじいなお、その後ほどなく会社自体も無くなったようです。当時ご一緒した方々は優秀で実績豊富だったこともあり、解雇後も次の職には困らないご様子でした。何名かは今も SNS でつながっていて、お元気でご活躍されています。
キャリアビジョンなき 2 度目の転職活動
さて、何はともあれ転職活動を再開です。しかしその中で 見ないようにしていた問題がちらっと顔を出す ことになります。
幸い（？）前回の転職から間が空いていないため、以前にお世話になったエージェントさんらに早速連絡を取ります。履歴書についても 4 ヶ月前に使ったものがあります。たった 4 ヶ月ではあるものの IT エンジニアとしての実績をせっせと付け足していきます。
会社としてもスムーズな解雇を進めたいこともあってか、一定期間は従業員として給与を出しつつ、転職活動に全振りして良いという話がついていました。今回は多少の実績があるからなのか、エージェントさんのご配慮なのか、その他どなたかのお力添えなのか、ともあれ書類選考がずいぶんとスルスル通り、数多くの面接を行うことになります。多い時は 1 日で 3 社ほどお伺いすることもありました。
面接を数多くするということは、ベテランの IT エンジニアさんらと会話をする機会が増えるということでもあります。多くの面接では次のようなことを聞かれることになります。
今後どういうキャリアを歩みたいと考えていますか？
採用を検討する側は、所属させた部署でモチベーション高く仕事してくれるか、ある程度長く会社で活躍してくれるか、という点を気にしています。実績のある IT エンジニアは簡単に転職できてしまうので、会社や業務に対して本人の方向性がどれだけマッチするかは採用可否の重要なポイントになります。そこでこのような質問もよく出ることになります。
ところが、正直これに困っていました。研究所での経験から「利用者がそれなりにちゃんといるシステムには関わりたい」という想いはありましたが、これはどちらかと言うと IT エンジニアとして一定の実績を積みたいという発想からのものでした。長期的に自らどのようなキャリアを歩んでいきたいのか、いわゆる キャリアビジョンがない 状況が続いていました。
これまで大学や研究所では将来厳しい、だから一応は経験のある IT 関連で、といった消去法的キャリア選択をしていました。自信は未だに足りず、自分はこれからどうありたいかを自らに問うことを避け続けてきた結果でした。
しかしながら、そうこう言いながらも私のこれまでのキャリアを評価してくれる会社も数社あり、その中で 自社開発サービスを提供している企業への転職 が決まります。内面的な課題は残ったままでしたが、前へ進んでいたことでどうにか次への扉を開けることができました。
順調に見える活躍とその裏で失われていった仕事への興味
次の会社には自社開発の Web サービスのサーバやネットワーク、加えて社内情報システムについて管理する部署に配属されました。インフラエンジニアと情シスを兼任するイメージになります。
これまでの IT やコミュニケーションの経験が上手くハマったのか、早い段階から実務を着々とこなして周囲からの信頼を得ることに成功します。お陰様で比較的早いタイミングで出世し、チームを束ねる立場も任されます。
家庭的には妻と共働きになるのですが、入社後に 2 人の子供にも恵まれます。会社はありがたいことにホワイト企業で残業も少なく、フルタイムで働く妻とも上手く家事を分担しながら生活を回していけました。 2 人目の子供の誕生の際は産後で妻の負担が大きい 1.5 ヶ月の間、育児休業を取得することもできました。
りもじいわずか 1.5 ヶ月ではありましたが目の回る日々でした。献立を考えるってこんなに大変なんだ…、とこの時ようやく実感しました…。
しかし、このように順調に実績も上げ、出世することもでき、家庭とのバランスも上手くいく中で１つの問題が静かに進行していました。
10 年ほど勤め、気がつけば IT やビジネス、そして仕事への興味が冷めて いたのです。
これは長い年月を経て徐々におきていた変化で、私自身も自覚したのはしばらく経った後でした。
気づいた頃には妙な思考が頭をもたげていました。仕事が面白くなくなっていて、頑張って成果を上げたら給与を上げてほしい、ではなく仕事が減らないかなぁ (週5→週2,3勤務といったイメージ) 、などと考え始めます。仕事の進め方も第一に個人的な省エネから考える思考回路になっていました。入社当初は熱心に行っていた IT やビジネスに対する能動的な学びもしなくなり、必要に応じて受動的に行うだけに留まっていました。
学びが滞ると、その分野に対する自信も失われていくようです。この頃には「自分は IT エンジニアではないな…」などと本気で思い始めていました。職業人としてのアイデンティティも喪失しつつありました。
なぜこのような変化が起こってしまったのか。それはやはり、未だに キャリアビジョンを描かず、自分がどうありたいかを自分で知ろうとしていなかったことが原因だと考えています。
会社で働いていれば多くの人の意図が絡まります。自分自身はもちろん、チームのメンバー、他のチームの人たちがいます。管理職や経営に責任を持つ人もいます。もちろんお客さんの存在も欠かせません。親会社や子会社と関係がある会社もあるでしょう。それぞれの人が何かしらの「こうしたい」とか「これはやりたくない」という意志を持っています。そしてそれが対立してしまうことは普通にあります。実際にはそれらのバランスをどうにか調整して何かしらのアクションとして落とし込んでいくことになります。
アクションがどのように決まるかと言えば、まずは立場が上の人の意見が強い影響を持ちます。ただ、立場によらず主張が強い意見も反映される場合もあります。少し例が極端ですが、会社での立場が弱くても強い主張を「デモ」として声を上げる、といったこともありますよね。経営層や管理職がこうと決めても、現場のメンバーの強硬な反対で方針が覆ることもあります。
私の話に戻りますが、本来であれば自分はどうありたいのか人に伝えられるよう整理し、それに基づいて物事に対して Yes や No を明確に主張すべきでした。しかしそれをせず、なんとなく周囲に従うスタンスを続けてしまいました。社内の様子を見て当たり障りがない穏当な考えを自分の考えとして刷り込むことを無意識に行っていました。
自らの本来の主張をしていないので当然なのですが、会社で決まっていくことに自分の望みが反映されない状況が続きます。そうなると仕事は自分事から他人事へと徐々に離れていってしまいます。仕事からやりがいが失われ、作業的になることでパフォーマンスも低下し、成果も上がらなくなっていきました。
りもじいIT の経験も積み、社歴も長くなっていたので、そのアドバンテージを活かして会社への一定の貢献をしていたことは確かです。その一方で現状維持活動をこなすことが大半となり、会社の現状を打破するような、成長のための活躍を自ら積極的にするようなことはなくなっていましたね…。
訪れた転機と安定志向のITキャリア入門の着想
仕事に対して半ば無気力になっていたことを当時自覚していたわけではないものの、「このままではいけない」という不安感は強まっていました。
当初は「働かなくて良い方法はないか」の発想から投資に興味を持って調べるようになります。そのころは FIRE という考え方も有名になっていた時期でした。
しかし投資が主要な収入を生める環境にはなく、 FIRE を現実に感じることはできません。また、投資に傾倒していく事への漠然とした不安もありました。
その手の情報を調べていると副業や独立といった情報も入ってくるものの、自分の性格でそれができるという気持ちにはなりません。そういうことができるのは鋼のメンタルを持つ特別な人たちで、自分とは別世界にいる人たちだろうと思ってしまいます。何よりこの時は「働きたくない」のメンタルなので、このような方向性にも魅力を感じませんでした。
そうは言いつつも現状を打破する良い手段も他にないので、色々と情報をたぐることは続けていました。そうこうしているうちに、たまたま人間のメンタルや心理学についても学ぶ機会を得ることになります。
ここで意外にも、自らの安定志向な個性をポジティブに受け入れる方法を知ることになります。思い込みというのは怖いもので、こうと思い込むとそれが事実であるかのように認識してしまいます。個性に対しての自己否定は、繰り返すことで変え難い事実であるかのように自らに刷り込まれていました。個性の受け入れ方を知るキッカケも、それを目的としたものではなく、偶然に掴んだ幸運でした。
思い込みからの脱却によって自分の個性を認めることができるようになると、面白いことが起きました。自分の得意なことやこれまでの実績に目を向け始めた途端、今度は自信がジワジワと湧いてきます。「自分にはこんなこともできるかも」といったアイディアが浮かんできて試してみたくなります。
ここで思い浮かんだのが、IT キャリアに興味を持つ人たちに自分の経験を伝えることでした。
IT エンジニアという職業は数十年前からありますが、その内容は技術革新とともに変化しており、今も注目される職業の１つです。数年おきに新しい 〇〇 エンジニア が誕生する業界でもありますね。
りもじい最近ですと、AI エンジニアやデータサイエンティストなどが有名になりましたね。その少し前だとクラウドエンジニア、セキュリティエンジニアなどでしょうか。今後はどんな職種が誕生するのか楽しみですね。
そのおかげもあってか IT エンジニアになるための学習教材は豊富になり、プログラミングスクールも数多く開校されています。転職エージェントも IT 特化のものが出てきたりしていますね。IT キャリアを支援する環境はどんどん良くなっています。
その一方で、「未経験 エンジニア」で検索すると不安にさせるネガティブなワードも多く出てきます。エンジニアに対するネガティブなイメージを持たれる方も少なくないようです。未経験者が IT エンジニアを目指すことをためらってしまう雰囲気もあるのではないでしょうか。
トラブルが起きれば大変なこともある職種ではありますが、私の目にはそれ以上に未来のある面白い職業に映っています。人生いろいろでしたが、IT エンジニアという職を中心に歩めたことはとても幸運でした。興味のある人にはぜひチャレンジしてほしい、推しな職業です。
そして幸いに、私は人に何かを伝えることが、得意かはさておき嫌いではありません。相手が自分とのコミュニケーションで何か解決したり改善してスッキリする様子を見ると私も嬉しくなります。そんなことを考えていたら、これまで見ようとしてこなかった自分の キャリアビジョンがおぼろげながら見えつつ あるような気がしています。
さて、具体的には何を始めるかを考えました。思いついたのは、私自身の個性とも絡めて、安心して安全に安定した IT キャリアを歩むために知っておくべきことは何か、どのような考え方をすると良いのか、まず何から行動することがオススメするのか、といった情報を整理してお伝えすることでした。この切り口であれば私の個性を活かすこともできそうです。また、今は情報が溢れており、多くの人に振り向いてもらうために人の不安を刺激する情報も多いですが、このブログは安心して見に来てもらえるものにできればと思っています。
私が伝えられる事は正解ではなく、あくまで個人の考えに過ぎません。しかし、安定志向な個性を持つ人間にとっての IT 歴 20 年は、IT 未経験の皆さんにとってなにかの参考にはなるのではと考えています。
この入門ブログで未経験の皆さんに伝えていきたいこと
安定志向のITキャリア入門 | 安心してエンジニアになるための 7 ステップ では、次の 3 点を心がけた情報発信を行います。
- IT 未経験の人にも分かりやすく
- 個人の実体験を絡めた見解を提供
- 7 つのテーマに分類して情報を体系化
まず、専門用語などはなるべく避けて、 IT の未経験者や初心者の人にも分かりやすい表現を心がけます。専門的な言葉が不可欠な場合は解説を加えるなど工夫していきます。
次に、単に理論的にはこうだろう、ではなく、私自身の IT 業界での実経験も織り交ぜた見解をお伝えします。今や一般論は AI がキレイにまとめて教えてくれる時代なので、経験をバックグラウンドにした独自性のある考えをお伝えしたいですね。
そして、お伝えする内容を次の 7 つのテーマに分類します。これは私のこれまでの人生経験から感じた、安心して IT キャリアを始めるための大切なポイントだと考えています。
- IT エンジニア
- IT 業界
- IT 技術
- IT 学習
- コミュニケーション
- キャリアビジョン
- 就職
読んで下さる皆さんが前向きに行動したいと感じるようなメッセージを伝えていきたいですね。
りもじいここまで読んで頂きありがとうございます！ これからもよろしくお願いします！
コメント