年収が上がらないのは、「一つ上の構造」を知らないから
IT業界を見ていると、キャリアアップとともに年収が上がっていく人と、同じところでとどまっている人の差が見えやすい。そして、年収が上がらない人には特徴がある。
ぼくはプログラマーだったんですけど、たしかに全然給料上がりませんでした。
どんな特徴があるんでしょう？
その前に、ITプロジェクトにおける構造について話をしておこう。
仕事は上流工程から下流工程に流れるようになっている。
※ここではSIer系の事業モデルを例に紹介
プロジェクトによって若干の差異はあるのだが、だいたいこんな感じになっている。
・同じく経験豊富なシニア/ミドルクラスのコンサルが導入プロジェクトを管理する
・システムの各領域別にチームリーダーがいて、顧客と要件定義を進めていく
・要件に基づき設計に落し込み、開発者は設計に基づきプログラミングで実装を行う
あ、知ってます。IT業界の人だったら常識ですね。
そうだ。しかし、知ってはいても理解している人は少ない。
え、どういうことでしょう。
分かりやすく解説しよう。
ペンちゃんにとって、一つ上の工程を担当するのは誰だ？
設計担当はシステムエンジニアの人です。
図でいうとジュニアコンサルですね。
そのジュニアコンサルから仕様を伝達されるとき、説明をよく理解できなかった経験はないか？
確かに、システム用語ではない言葉が出てくると、わからないときがあります。
前に経理システムのプログラミングをしたことがありました。借方とか貸方とか、費用勘定とか資産勘定、貸借対照表とかっていう言葉が基本設計書に出てきていて、全然わかりませんでした。
そのときはどうしたんだ、ペンちゃん。
結局、わからない言葉は飛ばして、どういう値の時ときにどういう動作をするかっていう、プログラミングレベルでの言葉に言い換えてもらって、なんとか実装が出来ました。
そのとき、ペンちゃんに経理や会計の知識があれば、少なくとも設計書の用語レベルでは困ることはなかったと思わないか？
うーん、確かにそうですけど、こちらはプログラミングしか知らないので、読みにくい基本設計を渡されると困っちゃいますね。
開発者の立場なら、その言も一理ある。
しかし、それは同時に自らプログラマーとしての立場に縛り付けてしまう言葉でもある。
そうなんですか？
そうだ。当然だが、上流工程に行けば行くほど年収は高くなる。
なぜならば多様な知識・知見・経験が上に行くほど要求されるようになるので、人材としての価値も上がるからだ。
IT業界で年収を上げたいと思うならば、上流工程に行くべきだ。
だが、「私はプログラムしか出来ません」と自己を規定してしまった瞬間、上流工程に行く道が閉ざされてしまう。
プログラマーをずっとやっていても年収は上がらないんですか？
フリーランスになったり、プログラマーとしての希少価値を高めることで年収を上げることはできる。だが、フリーランスになる際は気をつけねばならないことも多いし、エージェント選びをしっかりしないといけない。また、プログラマーとしての希少価値を高めるということは、それなりに才能が必要になる。天才肌のエンジニアはたくさんいるからな。よって凡人は上流工程を目指すのが良いと思う。
上流工程を担当するにはどうしたらいいのか
これはシンプルだ。
上司やリーダー、上流工程の担当者に「君、設計や要件定義も頼むね」と言われればいい。
お、そうなんですか。早く言われると良いなあ。
残念ながらペンちゃんは一生言われないぞ。
働き方を変えない限りな。
え～～～。
上司やリーダーのその言葉を引き出すためには「こいつになら一つ上の工程も任せられそうだな」と思わせなければならない。しかし、そのアクションを何も取っていなければ、一生そのままだ。
どうしたらいいんでしょう？
上流工程を任されるための理屈はシンプルだ。上流工程について自主的に理解する、あるいは理解するための努力が見える、という上への歩み寄りがあるかどうかだ。逆に自分の領域に固執するように見えていては、引き上げてはもらえないということだ。
なるほど。たしかに、以前担当した経理システムで分からなかった言葉は、特に意味も調べずそのままでした。
実は上流工程を担当できる人材は常に不足しており、上流工程の担当者は「設計や要件定義も担当できるプログラマーはいないか」という視点でいつも人材探しをしている。
だから、システム知識だけでなく業務知識も理解しようとする姿が見えれば、何時でも何処でも何度でもチャンスがある。それがIT業界だ。
でも上流工程なんてやったことないし、どうすれば……。
経理システムを構築したなら、簿記三級でも勉強してみるといい。
「あのコードはこういう意味だったのか！！」という、知識と記憶が連結され、自分の仕事の意味が三次元的に理解される知的体験を得ることが出来るだろう。
ほんとうですか？
経理が見えれば会社が見える。そもそも簿記の知識というのは、会社の活動を知るためのとても有用なものだ。私は全社会人が勉強すべきものだと思っているよ。
特に一流のビジネスマンには、業種を問わず必須科目だ。
なるほど、システムのことだけやってても、いずれ袋小路になるんですね。
システム外のこともある程度知っていると思われれば、上流工程に引き上げてもらいやすくなる。プログラムをとにかく実装するだけでなくて、業務的な側面もみてみるといい。
年収が上がらない人の特徴 ～こういう人は要注意～
以前、要件定義～基本設計のあたりを担当できる人材が欲しくて募集をかけた時の話だ。何人かの提案が人材会社よりあったが、人材不足で、いずれも開発者経験が長く上流工程の経験がなさそうな人物ばかりだった。
それでも一応面接してみようと思い、会ってみた。しかし予想はいい方向には外れなかった。これはその時のやり取りだ。
とある日の面接にて
履歴書によると、前のプロジェクトでは「リース債務取崩処理の画面構築を担当」とありますが、このリース債務の取り崩しとはどのようなものですか？
はい、テンプレートに基づいた画面実装を行いました。画面上で左右に一覧表を表示させて、入力者が一覧表の行を選んでコミットボタンを押すと、承認層ユーザに自動でワークフロー（承認依頼）通知が出ます。承認されると、その行のステータスが処理済みになる仕組みです。
えーと、リース債務の取崩しとは、どういうものかを説明できますか？
……？？
この画面では、入力者は左右の金額を確認して、合っていればOKボタンを押してコミットします。
左右の一覧表とは、何を表示していますか。
えーと、設計書では左が償却予定？と右がリース支払実績？だったと思います。
そこに表示されている金額は、どうやって計算していますか？
わかりません。そこは別の人が開発したモジュールから流れてくる数値を表示するところなので。
なるほど。ちなみに、この機能が必要である理由は何だと思いますか。
？？？？？
設計書があって、その開発を依頼されたからじゃないですか？
はい、わかりました。ありがとうございました。
なにがいけないのか？
これはぼくでも何が悪いかわかりますよ。
「リース債務取り崩し」っていう経理処理があるんですよね？
その中身を訊いているのに、この人はシステム上の画面処理の説明に終始しています。
よくわかったじゃないか。どうした。
ぼくと上流工程担当者の間の会話に通ずるものがあるからです（笑）
他人事だとわかりやすいですね～。
勘違いしてほしくないのは「リース債務取崩し」を知らないから悪いと言っているのではない。経理担当者でもパッと説明できない場合も多いだろう。
しかし、この機能の上流工程担当者は、確実に理解して要件定義を行っており、それを設計に落とし込んだものを、この応募者が構築しているという構造がある。
その構造を意識できているかどうか？を面接で確かめたんだ。
まあ、要件定義とか基本設計を担当する人として募集をかけたのにこの感じだと、厳しいかもしれないですね。
これは人材紹介会社の提案がミスマッチだったと思いますよ。
人材不足だから仕方ないし、この応募者が悪いとは全く思わない。しかし、「そういう視点で見られている」という事実は確実にある。そして、それはつまり上流工程に引き上げられるチャンスなのだということでもある。
なるほど。まずは自分が作ってるものってなんなのか？という事に興味を持つほうがいいですね。
そうだ。例えばだが、
何も知らされず、ただ石を削る作業を延々とさせられている人と、
ピラミッドを作る礎となる石を削る作業と知っている人と、
どっちがモチベーションが上がるだろうか？
その場限りの日雇いの意識と、数千年後まで称えられる巨大事業の一部を担っている意識では、もはや仕事の品質すら別次元のものに代わってくると思わないか？
現場リーダーが教えてくれれば良いんですが。
自分から興味を持つ方が好まれる。現場リーダーも、そうやって作業の意義を説明したが、開発者に「何言ってんだこいつ」みたいな目で見られてスベった、という経験を持つ人もいる。
モチベーションを与える動機づけというのは難しいんだ。
相手に興味がない状態では、何を言ってもスベるだけだからな。
そうして「まあ開発者は黙々とコード書いてくれてればいいや」と考える現場リーダーが出来上がる。
不幸な構造ですね。
そういうことだ。しかし、開発者に知識がなかったとしても、興味を持っていることをリーダーに伝えるだけでも、上流工程に引き上げてもらいやすくなる。それが年収アップの第一歩だ。
それでは、今回はここまでだ。
にほんブログ村
