“駆け出しエンジニア”から”できるエンジニア”へ

どうも、合同会社Celalinkの代表をやっているヤナイ( @yusuke_celalink )です。

IT業界へ入ってプログラマーとして２〜３年くらい経ってくると自分の将来のキャリアプランを考える時期に入ってきます。
その後も数年周期でキャリアプランを考える時期はやってきますが、初めてキャリアアップを考える時には漠然とイメージだけ持っているものの、具体的にどういったことを考えれば良いのかわからないと思います。

今回の記事はエンジニア歴が比較的浅い方を対象に「キャリアアップするために覚えるプロジェクトマネジメント」として記事を書いていきます。
プロジェクトマネジメントを経験したことの無い方も是非読んで頂ければ幸いです。

最初に考えるキャリアアップ

IT業界で働き始めた最初の頃は色々と覚えることが沢山あり無我夢中になって日々を過ごすエンジニアの方も多いのではないでしょうか？
数年経ってようやく様々な事に慣れた時に「今後はどうやってキャリアアップしていけばいいんだろう」と感じる人もいると思います。
私自身もIT業界で３年目に入った時に初めて考えました。

• 生涯プログラマーとして活躍したい
• プログラマーは卒業してマネジメントを経験したい
• 将来は独立してIT業界で活躍したい人
  など様々なキャリアプランがあります。

特に将来独立を考えている人であれば上流工程の要件定義はもちろん、コンサル的な提案する能力も必要になってきます。

最初は漠然とした感覚で良いと思います。
同じ仕事をしている仲間や上司で「あの人みたいになりたい」という人がいれば同じキャリアを目指せば良いと思いますし、「楽しい」という感情を優先したキャリアアップも良いと思います。

しかし、どういうキャリアアップを目指すにせよ、「できるエンジニア」を目指すためにはマネジメントは避けて通れない道になります。

プロジェクトマネジメントがどう技術力に関わってくるか？

プログラムが書くのが好きだし、技術力をもっと高めたいからマネジメントの勉強なんてしたくない！
そう考えるエンジニアの方も多いのじゃないでしょうか？

おっしゃる通り、技術力を上げるという観点ではマネジメントを学ぶことには直接繋がりません。
例えば、進捗の管理が上手くできるようになった所で技術力は何１つ上がりません。

しかし、私が実際に数多くのエンジニアを見てきて技術力の高いエンジニアは例外なくプロジェクトマネジメントにおいても非常に高いレベルで仕事が出来ています。
最近では開発手法が増えてきたのであまり言われなくなりましたが、ウォーターフォールモデルでの開発が主流だった時代は「上流工程から下流工程まで一通りできるようになって一人前」なんて言われる時代もありました。

もう既にエンジニアとして数年業務を経験している方は「コーディング」という作業は開発の中の１つの工程でしかないということもわかっていると思います。
これからエンジニアを目指す方は「コーディングはプロジェクトの工程の１つ」という認識を覚えておきましょう。

「良いプログラム」を書くことは「すごいプログラム」を書くことではありません。
メンテナンス性や拡張性を意識したり、システム全体を考えてコーディングができたりすることが「良いプログラム」であり、「できるエンジニア」だと私は考えています。

いやいや、設計書があれば問題ないでしょ！
納期に間に合うようにプログラム作れれば問題ないでしょ！

確かに「成果物を作る」という意味では問題ないかもしれません。
しかし、「その設計方法で大丈夫か」「運用まで意識したコーディングをしているか」などの観点の有無は大きく影響していきます。

設計書を書いている人も同じ人間だからミスしていることも当然ありますし、マネジメントする人が必ずしもプログラムに精通しているわけではありません。
※マネジメント歴が長い人程、コーディングから遠ざかる傾向にあります。

マネジメントを知ることでコーディングする際の視点が変わってくるのでマネジメントを学ぶ必要があります。

プログラマーの価値は低い？

どの会社でも社員のランクを決める給料テーブルの上位の方はマネジメント職ではないでしょうか？
中には実体として年功序列になっている会社も多いので一概には言えませんが、、、

最近ではCTO(Chief Technology Officer)という「最高技術責任者」のポジションを用意している会社が増えてきており、年齢を重ねても技術寄りの仕事ができる環境が整っている会社が増えてきている印象です。
ただ、自身がコーディングするというより、若手の育成や技術アドバイスなどのポジションになっていくと思います。

会社によって役割は変わってくると思いますが、プログラマーとしての価値は少しずつ上がっているように感じています。
正直、言語によって価値も変わってくるので難しいところですが、ずっと技術を触っていきたいと考えている人は趣味で複数言語触ってる人も多いと思うので、やりたい言語ができる会社へ転職するのも１つの選択肢だと思います。

マネジメント側に行くことでプログラマーに戻れなくなるリスク

先程も書きましたが、マネジメント側の方が給料面の待遇が良い会社が多いと思います。
またある程度マネジメント側を経験すると、会社からの要求でプログラマーに戻れる可能性が低くなるリスクがあります。
まぁ当然、マネジメントで実績だしている人に他のマネジメントもお願いしたいですもんね。

規模が小さいプロジェクトなどではマネジメントしつつ、自分でコーディングもできることもあるので、アサインされる業務により会社に「プログラムを書きたい！」という要求を飲んで貰えるか交渉する必要が出てくるかもしれませんね。

マネジメントをしてみてわかること

プロジェクトによってはサブリーダーみたいなポジションがあったりするので、一言でマネジメントといっても誰がどこまでやるのかは会社やプロジェクトによって変わってきます。
そしてマネジメントの方法にも色々な手法があります。

ここでは、例の１つとしてマネジメントを担当しているあなたは以下の役割を持っているとします。

• プロジェクトのスケジュール作成・管理
• システムの詳細設計担当
• コードレビュー

初めてスケジュールを作成して、日々管理をしていると思ったより時間がかかったり、うまくいかないことも出てきます。
設計書も同様に、わかりやすく書いたものがうまく相手に伝わっていなかったり、自分の言葉で書いてみようと思うとなにかわかりにくかったり、驚くことがあります。

コードレビューに関しては自分よりスキルが高い人から学ぶことは多く、逆にスキルが劣っている人には教えながら自分の知識力を再確認することもできます。

このようにマネジメントを学ぶことはプログラマーとしての能力も向上してくれます。
実際はここに書いている以上に体感的に難しいことも多くあります。

マネジメントを経験することでマネジメントをやりたいという気持ちも大きくなるかもしれませんが（笑）

まとめ

自身のキャリアプランを初めて考えるタイミングで一度マネジメントについて経験してみる価値があると思って頂ければ幸いです。
マネジメントが嫌だと感じても、マネジメントを数年経験してまたキャリアプランを考え直す時期になったら改めて技術を突き詰めていく選択をすればいいだけです。

プロジェクトマネジメントも１つのプログラム言語を覚えるくらい沢山の手法やノウハウがネットや書籍で溢れるように存在し、新しい手法が出てきています。

マネジメントとプログラム両方の道を極めるのはかなり難易度が高いですが、キャリアプランを考える上ではどちらも経験することが非常に重要だと考えているため、今回記事を書きました。

読んで頂いた方の参考になれば幸いです！

それではまた。