まず言っておこう、間違いなく「否」であると思う
単価というのは一番定量的で評価基準として採用されやすいことは事実であると思う
それ故に、単価≒給料だと思う人がいてもおかしくないですね
ただ、本質的に考えてみてほしい
そもそも、単価が上がったから社内の評価があがったのであろうか？
単価ってなんなのか
単価ってどう上げるのか
単価が上がるとはどういうことなのだろうか
本記事では評価の結果は給料のアップということと定義し、考えを始めようと思います
単価をあげるにはどうする必要があるのか
本章は是非「自分が人を雇うとしたらどうか」、「自分がチームメンバーを評価するとしたらどうか」という視点も入れて読んでいただきたいです
そもそも単価とは
準委任、SESの場合は簡単ですね
お客様からいただく人月単価（1ヵ月働いた分の対価）がそれにあたります
エンジニア単価とは、その業務に対するエンジニア1人の価格、月あたりで示した料金のことです。月あたりの要員1人価格ということで、とくに「人月単価」ともいいます。
請負の場合、人月単価をどう考えるかという点はありますが、以下のように考えることもできます
請負金額を期間で割って1ヵ月あたりの予算を出す
1ヵ月予算を作業者人数で割るとそれが一人当たりの単価になる
(総額 ÷ 期間) ÷ 頭数
単純計算してしまうと、スキル差による単価の差を考慮できていないので微調整する必要がありますが、考え方としてはこれがベースになります
同じことをやり続けていて単価はあがるのか
淡々と与えられた仕事を与えられた分だけやっていて単価があがるのか
まぁ普通に考えるとあがらないですよね
もちろん2年も3年も続けていたら上がるんでしょうけど、それは期待以上の働きができるようになったから上がったんでしょう
もし仮にすぐ上がったのだとするとそれはお客様からの精一杯の感謝の気持ちの結果なので、当たり前と捉えないようにしましょう
まずはここからスタートです
熟練度で単価をあげるべきなのか
個人的にこの問いに答えを出すのに悩みましたが、結論としてはNO。
熟練度があがればそれだけこなせる仕事の量も変わりますし、質も変わります
そのため単価あがるのが当然じゃないかという考え方も当然あるでしょう
しかしですよ？
特に試用期間的な取り決めがなければ、そもそも単価というのは「熟練度が高まった時に出るパフォーマンス」の観点で算出されていることがほとんどであると思います
なので、「1年経ってやり方になれてきて熟練度が上がってきたから単価を上げてくれ」という要求はそもそも筋違いなのだと思ったのです
では単価をあげるにはどういう成果と行動が必要なのか
積極的に必要なリスクをとりにいく（容易に成果のでないことを進んで行う）
作業者視点で見るリスクとは
- 機能的に難しい設計や実装
- 作業効率を上げる提案&構築をする（スケジュールの範囲内できること）
- HELPや遅延報告
リーダーはやりたいなぁと思っていても、時間がないからという理由で後回しにしていたりやらないと判断していることが多いと個人的には思います
さらには、昨今の現場ではエンジニアとしても優秀な人がリーダーをやっていて、開発の手数としても数えられているケースすらあるため、難しい機能や共通機能などのタスクを抱えているケースも多い
そこに手間のかかること前向きに自らやろうとする人がいたらどうか。
頼るに決まってます。
※ ただし自分のスキルにまったく合わない事をやろうとしても失敗に終わる未来が見えるので、自身のスキルの範囲内で「頑張ればできそうな事」にフォーカスして積極行動しよう
積極的にコミュニケーションをとりにいく（→ 作業の円滑化に繋げる）
相手との関係性が構築されてないと正しく仕事を遂行できない環境にはそもそも問題があるという観点は否定はしないです
ですが、そんな正しく仕事をできる環境が世の中にあふれていないこともご理解いただけるのではないかと思ってます
そこでやはり重要となってくるのが通常業務の枠を超えたコミュニケーション。
知らない人と知っている人、どちらと仕事をしたいかと問われると、知っている人だ
話しやすい人と話しずらい人、どちらと仕事をしたいかと問われると、話しやすい人だ
という答えが大半なのではないだろうか
そんなアドバンテージを取るためにはやはりコミュニケーションは重要なのである
つまり言いたいのは、周りが嫌がる事を周りよりも積極的にやるというのが近道ということ
あなたの所属している組織やチームの中を見てみて欲しい
- 積極的に必要なリスクをとりにいく人はいるだろうか？
- 積極的にコミュニケーションをとりにいくひとはいるだろうか？
おそらく、エンジニアチームであればあるほどこのような行動をとる人は少数派なのではないでしょうか
チームメンバーの大半が自身のタスクに対して受動的かつ保守的で、必要最低限のコミュニケーションしかとらず、黙々と作業に没頭する。
そんなチームのリーダーは次第に孤独感にさいなまれ、リスクのあるタスクを溜め込み、関係性の基盤ができてない故に相談が命令と近くなり、メンバーの主体性（この文脈だとすでに主体性など存在するのか疑問だが）が失われ、やる気も意義も楽しさもないチームが出来上がる。
失敗する未来を容易に想像できます
そんなリーダーを救えるのはこの記事を読んでいるあなたしかいない
チャンスと捉え評価を爆上げさせましょう！
逆に多数派であればそれは絶対に良いチーム。評価云々をあまり気にせず自分も仲間に入ろう！
自然とチームの成果が形となり、あっという間に給料なんか上がっていることだろう
注意しなければいけないエンジニアが抱きやすい勘違い
飛ぶ鳥を落とす勢いで評価をグングン上げていっている、またはこれから上げていこうとしているそこのあなた
実際に私もハマったことのある、エンジニアにありがちな勘違いをここで紹介したいです
- 私は誰よりも（このチーム内では）考えてコードを書いているから偉い
- 私は誰よりも（このチーム内では）美しいコードを書けるから偉い
- 私は誰よりも勉強してるからすごい
- 私は絶対あいつより仕事してる
- 画期的な仕組みを導入した私はすごい
- あの勉強をしてないあいつ、エンジニアとして失格だよな
チームでの仕事とは結局「役割分担と助け合い」です
そんな小さい枠組みの中で周りと比べて偉いだのすごいだの。。
くだらないプライドはやる気やHRT原則の邪魔になるだけなのでさっさと捨てて、「こっちは俺に任せろ、そっちは任せたぜ相棒」的な考え方にあらためて欲しい
ここからは視点を変えよう
これまでずっと「単価の上げ方」 について考えてきました
単価を上げるには、チーム最適を目指すことなのではないかと言い換えることができるかと思います
チームが最適化されると生産性が上がり、今まで以上の成果がでるからですね
では、チームを持っているのはあなたが所属しているところだけでしょうか？
チームというのをどういう単位でとらえるか
自身が所属していて普段接する機会が一番多いチームが一番イメージしやすいものですが、チームはそれだけではありません
- あなたが所属している開発チームもチーム
- あなたが所属しているプロジェクトチームもチーム
- あなたが所属している会社の部署もチーム
- あなたが所属している会社の事業部もチーム
- あなたが所属している会社そのものもチーム
こう捉えることはできますよね
あなたの給料を決めるのは誰か
そこで考えてみて欲しい
「あなたの給料を決めるのは誰ですか？」
開発チームのリーダーでしょうか？
それはもしかすると貢献している先が開発チームのみであるというのであれば、開発チームリーダーの評価（つまりは単価に近いもの）をベースに給料が決まるかと思うので、「サラリーマンエンジニアの評価は単価である」という結論となるでしょう。
ですが
あなたは開発チームのメンバーである前に所属してる部署のメンバーであるし、ひいては所属している会社のメンバーなんです
なので、サラリーマンエンジニアの評価は単価であると悲観する前に、貢献の先を広げてみてはいかがでしょうか
そうするとあなたの評価は 単価+α に必ずなります
貢献とはなにか
では貢献とはなんでしょうか
実際に何をすると貢献なのでしょうか
状況に応じてだと思いますが、少し具体的に考えてみましょう
- チケットをたくさん消化した → プロジェクトチームに貢献
- みんなが嫌がる作業を一手にひきうけた → プロジェクトチームに貢献
- チーム内にナレッジをたくさん共有して、みんなのパフォーマンスを上げた → プロジェクトチーム/所属部署に貢献
- 全社イベントを開催して社員の親睦の輪を深めるた → 所属部署/会社に貢献
- 社外発信をして会社と自分の知名度を上げた → 会社に貢献
少し考えるだけでも色々なことができそうです
但しこれらはいままでの自分の殻を破る必要のある行動かもしれません
ですが、前述の通り、評価を上げるというのは「周りが嫌がる事を周りよりも積極的にやるというのが近道ということ」なのです
今持っている技術ははたして自分だけで習得したものであるのか
なぜナレッジの共有や全社イベント、社外発信など、貢献の先を変えると評価されるのか
それは一人では技術力を高めることはできないからです
我々エンジニアは技術を提供してお客様から対価をいただいてます
そのためどう技術力を向上させるかというのはどの会社さんも課題として感じていることではないでしょうか
自身の成長の源泉は他人のアウトプット
ごく稀に、全部自分自身で考えつき、作り上げたという人もいるかもしれないですが、大半は違います
もちろん、一生懸命に勉強して周りよりも成果をだしたあなたは本当にすごいです！
ただ忘れてはいけないことがある
そのあなたが勉強に使ったその本は誰かが書いた本であるし、そのWEB記事は誰かが書いた記事であるし、そのプロジェクトで経験していることは誰かがベースを作ってその上で開発しているし、そのおかげであなた自身新しい発見をしている
つまり、基本的にはあなた一人だけでは成長も貢献もできないのです
自分が勉強しようと思ったものは多分誰かも勉強しようと思っている
自分が進まなくて困ったところは多分誰かも進まなくて困っている
「自身の成長の源泉は他人のアウトプット」と捉え、ぜひみなさんも誰かの成長のために貢献してみてはいかがでしょうか
エンジニアの評価は単価なのか
さて、だらだらと書いてきましたが、まとめに入っていきたいと思う
エンジニアの評価は単価なのか
対お客様でも、対所属会社でも、対上司でも、対仲間でもやる事の軸は実は変わらない
他人に感謝される仕事とは一体なんなのか
どの範囲の人に感謝される仕事をするのか
プロジェクトチームも、部署も、会社も、大きく見れば社会も、それぞれ問題を抱えている
どこまでの問題に立ち向かい行動するかによって評価は変わってくるのではないでしょうか
結論、冒頭の通りで評価は単価だけではない。です！
+αを狙っていきましょう
こんなエンジニアになってみてはどうか
最後に私から提案。こんなエンジニアを目指してみてはいかがでしょうか！
- 与えられたタスクを円滑に進めることができるのはもちろん基本
- 「円滑に」というのは決して「遅れたりしない」とかそういう話ではない
- 必要なコミュニケーションを怠らずスケジュールの許容範囲内でゴールまでもっていけること
- 自分の意見をちゃんと言う
- 埋もれないことが重要。あなたの発言は必ずチームを良くする
- 必要な説明を怠ったり、文脈に沿わないまったく関係のない意見をしないという点は気をつけよう
- よく聞き、よく話す
- 人のアドバイスをちゃんと聞くことができる
- 人にアドバイスをすることができる
- タイムマネジメントがしっかりしている
- 必要以上に話しすぎないし、必要以上に聞きすぎない
- 必要以上に没頭しない
- 必要以上に作り込まない
- ただ、この「必要」の閾値は状況によって変わるので、仲間とコミュニケーションをとって認識を合わせる
- 頼もしい言葉をいう
- リスクをとって誰かを安心させることも時には重要
弊社、株式会社SORICHは、クラウドネイティブなアプローチを得意とするシステム開発会社として2006年4月からサービスを提供しています。コロナウイルスの流行を受け、2020年3月から社員の9割以上がテレワークで勤務をするようになりましたが、現在も変わらず大手外資系企業をはじめとしたお客様からご愛顧をいただいております。
代表・馬屋原は学生時代にエンジニアの過酷な労働環境を目の当たりにし、「エンジニアが幸せに働くことができる場所を作りたい」という思いから大学を卒業後すぐに当社を設立いたしました。社名の由来でもある「社会を豊かに」という企業理念のもと、会社に関わる全ての人の豊かさのループの始点となれるよう、今後も技術力を活かして社会に貢献してまいります。
SORICHでは常時、システム開発部の採用窓口をオープンしております！
2023年9月現在ではクリエイティブ事業部の窓口もオープンしています！
typeさんやen転職さんで募集がストップしている場合でもこちらからご応募いただけます！
noteでは、社内活動について記事を執筆し、投稿してます。
こちらもぜひ！