たまに部下から相談を受けることもあります、
どうすれば一人前になれるのか、どのくらい時間がかかるのか、ということをよく聞かれますが、今回はそれについて書いてみようと思います。
一般的なITエンジニアの成長モデル
まずはいつもみたいにChatGPTに聞いてしまいます。
今まではGoogle先生ですが、最近はとりあえずChatGPT先生という感じです。
あなた
ITエンジニアで一人前になるにはどのくらいの時間がかかりますか？
ChatGPT
ITエンジニアになるために必要な時間は個人の学習ペースや学習方法、専門化の度合いなどによって異なります。一般的には、以下のような要因が関与します：
- 学習のスピードと方法: 自己学習、オンラインコース、大学の学位プログラムなど、学習方法によってかかる時間は異なります。また、学習スピードも個人差があります。
- 専門化の度合い: ITは広範囲にわたる分野であり、セキュリティ、ネットワーキング、ソフトウェア開発、データサイエンスなど、様々な専門分野があります。専門分野においてより高度なスキルを身につけるためには、より多くの時間が必要です。
- 実践経験: 理論だけでなく実践経験も重要です。プロジェクトに参加し、実際の問題を解決することで、スキルが向上します。
- 資格取得: 一部の分野では、特定の資格取得が求められることがあります。資格取得にかかる時間も考慮する必要があります。
一般的に、ITエンジニアとして一人前になるまでに数年から数十年かかることもあります。しかし、基本的なスキルを身につけて実務経験を積むことで、比較的短期間でエンジニアとしてのスキルを獲得することも可能です。最終的には、継続的な学習と実践が重要です。
うーん、思った以上によくまとまっている。ChatGPTの回答はパーフェクトかなと思ってしまいました。正直私も聞かれて困るので「人によって違う」という回答をすることがあります。中学生の頃からプログラミングしていれば有利でしょうし、大学で専門的に学んでいれば有利でしょう。ただ、そういうことだけで決まらないので複雑です。
そもそも、「一人前」という言葉がかなり抽象的です。私自身の経験で、自分で一人前になれたかなと思ったのがおよそ30歳の頃です。少し抽象的にまとめますが、以下のようなイメージです。
- 中規模のPMができる
- システム開発を自力でできる
- わからない技術は自分で調べて解決できる
- マニュアルを読み込んでファクトを積み上げる癖がついている
- トラブルが発生しても解決できる
- システムにパフォーマンスチューニングができる
ちなみに、これら全てを独力でできる必要はないかもしれません。システムは必ず仲間と作っていくものですし、一人でやるには限界がすぐにきます。ただ、そういう仲間と会話がきて、仲間の良さを引き出せる力は必要です。
なお、一般的にこれらのスキルをエンジニアリングスキル、ヒューマンスキルに分類して整理する手法もあります。この方がより具体的でわかりやすい気はします。例えば、
エンジニアリングスキル
- Pythonのコーディングスキル
- SQLの記述スキル
- MWの構築スキル
ヒューマンスキル
- コミュニケーション能力
- PMスキル
などです。とはいえ、こういう整理をしたとしても「Pythonのコーディングはどこまでできれば一人前なの？」という、一人前のレベル定義はかなり難しいです。コードの読み書きができれば一人前なのか、フレームワークや関連パッケージを使いこなせて一人前なのかでも大分違ってきますしね。なので、「一人前」を聞かれた時に「人によるね」と回答してしまうことが多いのです。
私の経験
基本的に一人前の定義自体が曖昧なので、「人によるよね」と回答していても、質問してくれた後輩の回答にはならないですよね。「そんなこと聞きたいんじゃないよ」って思うでしょう。私もいろいろ試行錯誤してきたのですが、この手の質問をされた時には具体的に自分のキャリアを公開しています。
要は、私のキャリアを見せて、「本人に考えてもらう」という手法です。同じ話をしても感じ方は人それぞれでしょうし、行動に移すとなるとそれもまた人それぞれです。
ちなみに、本を２冊書いていますが、およそ5年前の私のプロフィールはこんな感じです。Amazonにも公開されているのでコピペします。
（なんか知らない間にレビューが28件もついていて驚きました。ありがとうございます）
三菱UFJインフォメーションテクノロジー株式会社 インフラアーキテクト、クラウドチームマネージャ。
1978年生まれ。神奈川大卒。新卒後3年は下積み経験という位置づけでSIerに勤務。主にクラサバ系アプリケーションの実装を担当。データベースの知識をつけてから某大手証券のシステム部門に転職。当初は引き続きアプリケーション開発をしていたものの、トラブルを契機にアプリケーションのチューニングを担当。データベースを中心とするチューニング部隊を組成。その後社内クラウドの立ち上げとともに、インフラ部門にチューニングメンバーごと異動。社内クラウドのコンセプト、インフラ設計をおこなった。その後、三菱東京UFJ銀行(現、三菱UFJ銀行)に入行し、2016年より三菱UFJインフォメーションテクノロジーに出向。市場系システムを担当しつつ、標準化チームも運営。現在は標準化に加え、約100人のメンバーで行内のAWS開発を一手に引き受けつつ、全体アーキテクチャを検討している。
このプロフィールをベースにもう少し年代ごとにまとめつつ、今回のテーマである「一人前＝30歳くらい」についてもう少し書いていきます。
最初の3年間
プロフィールにも書いていますが、SIerで3年間アプリケーション開発をしていました。なんで3年間なのかというと、入社式に社長が「我が社は踏み台にしてもらって構わない」と言っていたからです。真意は今もわかりませんが、そういうビジネスモデルだったとも思います。いずれにしろ、「じゃー踏み台にするか」と思ったのは事実です。
3年というのはお世話になった大学の教授に3年はやりきれと言われていたので、それを守りました。その3年間ですが、1年目は大した仕事をしていませんでした。PCの入れ替え作業とか雑用に近かったです。その後１つ目の開発現場でC言語とシェルの開発を学び、２つ目の開発現場でJavaを少し学びました。
ちなみに、当時Oracleの旧プラチナの資格を取ると月給が５万円上がるという話があったので、2年目の中盤くらいに取ってしまいました。ベンダー資格取得に時間を使ったことは今でも良かったと思います。
あと、今思い返して良かったと思うのは、２つ目の開発現場の先輩がスパルタだったってことです。基本的にわからないことは自分で調べて、その上で質問をしないと絶対に教えてくれませんでした。Oracle8を使っていたのですが、５センチくらいのマニュアルが20冊くらいあって、それを全部読んでいました。はじめはどこに何が書いてあるのかわからなかったのですが、２ヶ月もすると大体書いてある場所がわかるようになったので、ほとんどの部分を自分で調べられました。その解決力が１つの自信になったと思います。
次の3年間
自信満々というわけでは無いですが、転職活動をしてみるとほとんど受かりました。当時はインターネット拡大期でエンジニアが枯渇していたので、資格合格を話すとかなり評価してくれていました。
一社目が金融系システムの開発だったのもあり、金融に絞って転職活動しました。証券会社のシステムを選んだのですが、そこではアプリケーション開発を勉強していました。言語はJavaでフレームワークを導入したり、GOFのデザインパターンを考えたりしていました。また、当時アジャイルがまだ無い世界観で、新しい現場ではスパイラル開発を取り入れていて、それにもチャレンジしたりしていました。もう無くなってしまいましたが、RUP（ラショナル統一プロセス）を採用していて、あの考え方は今でも好きです。
それらの経験は単にJavaを開発するだけでなく、開発プロセスを学ぶ機会にもなりましたし、成長できるきっかけになりました。ちなみに普通のプロジェクトだけでなく、アーキテクトっぽい仕事をやらせてもらえたのは、自分でマニュアルを読んで調べる部分を評価してくれていたのだと思います。一人前のイメージにも書いた「マニュアルを読み込んでファクトを積み上げる癖がついている」はエンジニアとしてはかなり重要だと思います。
その次の2年
ちょうど新卒6年目くらいの頃に、会社にとって一大事というくらいのトラブルに見舞われました。それがプロフィールに書いているトラブルです。金融系システムの場合、大トラブルが発生するとお客様にご迷惑をおかけするだけでなく、当局への説明など、いろいろと大変なことが発生します。イメージとしては、お家存続の一大事みたいな感じです。
その時のトラブルは急増する取引にシステム増強が追いつかなかったのが原因なのですが、そもそもシステムリソースを無駄に使うアプリだったという要因もありました。そこから半年間かけてSQL１万本を全てチューニングしていくという地味な作業をしました。そうやってチューニング専門部隊ができて、はじめて自分のチームと呼べるものができた感じでした。
ちなみに、このトラブルではもう１つ私のキャリアに大きな影響を与えていて、いわゆる業界の第一人者に出会えたことです。全ての領域において超人的なスキルを持っていて、ついていくだけでも必死という感じでした。そういう機会に恵まれたのは今思えば運が良かったと思います。本の出版もその時の人脈を伝手に相談して出させてもらいました。
とまあ、こんな感じです。運が良かった部分もあるとは思いますが、日々の努力と出会いがタイミングよく噛み合ったとも思います。
大事なのは日本語
さて、ここまでの話は気の利いた先輩なら話してくれることもあると思います。ここから少し個人的に感じている部分を書いていきます。
あくまでも体感的な部分ではありますが、エンジニアの７割は日本語がめちゃめちゃです。日本人なので日本語を話せて当たり前、大学まで出ていれば書けて当たり前なんですが、それでも酷すぎると感じる人は多いです。語学として日本語を見つめてこなかったからだと思うのですが、卒論を書いた人でも多くの人の日本語は変で、うまく書ける人は少ないです。
言語というのはエンジニアにとっても大事です。設計書を書く必要がありますが、それは正確でなければならないです。その日本語がおかしいと意味がわからなくなってしまうのです。報告書についても同様です。実は私は文章を書くことに自信がありました。大学受験の論文模試の成績が良かったからです。それでも前職の時の上司に指導され、勉強し直しました。そのエッセンスをここでは書きますので、特に若手の方は意識することをお勧めします。
細かくいろいろ指導されましたが、以下の2点を守ればかなり良くなると思いますし、私も後輩にそうやって添削しています。
- 主語述語を明確にする
- １つの文章は200文字までにする
1つ目は当たり前な部分もあるのですが、主語と述語を明確にする必要があります。この骨格が歪むと何を言っているのかわからなくなります。そんなの当たり前だと思っている人もいるかもしれませんが、日本語の場合主語を省略できるので、文章の途中で主語が変わっていることがあります。これを無くすことがビジネス文章の基本だと思います。
2つ目にはいろいろな効果があります。教わった時になるほど、と思ったのですが、200文字は書く側からすると一回で言いたいこを詰め込める量、読む側からすると一気に読んで頭に入りやすい量なんです。これが300文字以上になってくると情報量が多くなって、脳内バッファから溢れてしまう人も出てくると思います。
つまり、多くの人が読みやすくて情報がスッと入ってくる絶妙な量が200文字です。ちなみに、メールを書くときの掟も教わってました。200文字の発展系なのですが、1つの段落で文章を3つまでで500文字以内にするという方法です。1つの文章が最大200文字なので、3つの文章で１段落を構成すると、
3×200=600文字
になります。600だと微妙に多いので、500文字にするという感じです。この500文字も絶妙な数字で、これを超えるとダラダラした文章になって、何を言っているのかわからなくなりがちです。ちなみに、経験的に段落は3つまでがいいと思います。それ以上になると長文になりすぎますからね。そういう意味で、３段落×500文字で、1500文字以内にまとめるのがいいと思います。
今回、「一人前」にあえて日本語を加えたのは、これらはできて当たり前なんですが、意外とできていない人が多いからです。自分はできていると思っていても、一度自分の文章を見直してみると良いと思います。ちなみに、偉そうに日本語について語ってますが、出版社の編集者の日本語力は私よりも何倍もすごいです。表現のわかりやすさが洗練されていて、格の違いを感じます。
一流になるにはOSの理解
最後に、日本語と同じく重要なOSの理解を加えたいと思います。OSがどうやって動いているのか、カーネルやプロセスの動きや意味がわかっていて説明できることが大事です。これもできるエンジニアはわかって当たり前の話なんですが、ブラックボックス化してしまっているなと思うことはよくあります。
特に、「コーディングしか経験のないエンジニア」にはこういう傾向が見られます。例えば、Linuxでcpコマンドを発行したときに、内部でどう動いているか説明できますか？「ファイルがコピーされる」だけではブラックボックス化された回答です。OSがどのようにファイルを管理していて（ファイルディスクリプタの動きとか）、どのタイミングでディスクに書き込まれて保存されることが担保されるのか（ファイルシステムのどこでキャッシュを持っているのか）、そういう仕組みをOSの観点から説明できるのか？ということが大事なんです。
もちろん全てのコマンドの裏側を理解して使う必要はありませんが、少なくとも考えてみようと思った時にシステムの動きを想像できないと、エンジニアとしては一人前ではありません。もしそれができないとトラブルが発生した時に解決できませんよね。そういう意味でOSの理解はとても大切ですし、基礎の基礎になるのですが、その大切さを語ってくれる人はあまりいないと思います。
ちなみに、自分の知識の判定方法としてオススメなのが以下の本です。この本をパラパラと眺めて全部わかっている人は基礎が身についています。逆にわからない部分がある人（特にプログラマー）はもう少し勉強が必要です。
絵で見てわかるOS/ストレージ/ネットワーク 新装版
まとめ
今回はよく聞かれる質問について、私が回答している方法をまとめてみました。30歳までにどういうキャリアを描けばいいのかは人それぞれですが、参考になれば幸いです。また、見落とされがちですが、「日本語」と「OSの理解」は大切なので敢えて加えてみました。この2点も確認すると良いと思います。
Discussion