著書「外資系コンサルは無理難題をこう解決します」発売中

なにがエンジニア(の書くコード)の価値を決めるのか

プレジデントオンラインのこちらの記事を読みました。

参考 日本人エンジニアの給料が上がらない理由 | プレジデントオンライン | PRESIDENT Online

「40代にもなってマネジメントもできないエンジニア」など、かなりキツめの物言いの記事で、一部で話題になっているみたいです。

さて、上の指摘は「プログラマ→SE→プロマネ」というキャリアパスが一般的な日本のIT業界だけでなく、「エンジニア→シニアエンジニア→プロダクトオーナー」的なパスがグローバルであることを考えれば、正しい指摘でしょう。

しかし、個人的にはちょっと違うビューを持っています。

日本のエンジニアが安く買い叩かれているのは、マネジメントができないからではなく、マーケティングができないからではないのでしょうか。

なにがモノの価値を決めるか

モノの価値は一定ではありません。いいモノを作ったからと言って、高く売れるとは限りません。

これは食品でもスマホでも、ソースコードでも同じです。いくらいいモノを作っても、その価値が認められなければ安く買い叩かれます。(もちろん一定の相関はありますが)

ではなにがモノの価値を決めるのでしょうか?

500mlの水はいくらで売れるか

たとえば、ここに500mlペットボトルに入った水があったとします。さて、この水は一体いくらだと思いますか?

100円?そうかもしれません。

安い店なら80円?たしかにその通りです。

では砂漠の真ん中でいまにも干からび息絶えそうな大金持ちは、この水をいくらで買うでしょうか?

1万円?10万円?いや、100万円くらい出すかもしれません。その1本のペットボトルで自分の命が助かるんですから。

これが、買値=価値の決まり方です。

価値を決めるのは「関係性」

つまり同じモノでも、買うヒトとモノの関係が変われば、価値は天と地ほど変わるんです。

「いいモノ⇒高く売れる」ではなく、「高く売れるモノ⇒買い手にとっていいモノ」。順番が逆なんです。

世界で誰もかけない難解で複雑なアルゴリズムを実装しても、その価値が誰にも伝わらなければ、いくら草を生やしても誰の目にも触れずGitHubの奥底に沈んでいくでしょう。

「自分の作ったモノ」に対し、いかに「買い手との関係性」を定義するか。これがモノの価値を決めるんです。

そのコードのもたらすベネフィットを語れるか?

だからこそ、このコードは誰にどんな価値をもたらすのかを真剣に考えるべきではないでしょうか。コードの価値を自ら証明するのです。

でないと、いつまでたっても「1日に書いたコード行数」「コミット数」「ファンクションポイント数」「こなしたテストケース数」など、物量だけで評価される世界から抜け出せません。

 

「Reactを使ったWebアプリが作れます」結構。

「MariaDBのパフォチューなら誰にも負けません」素敵です。

「AzureとAWSとGCPをまたいだ処理を自在に書けます」すばらしい。

 

で、それがどのようなビジネスベネフィットにつながるんですか?

これに答えないと、多くの場合ITを理解していない「お金を出す側」はちんぷんかんぷん。

「そうなの。じゃ標準人月単価100万で買うわ」でフィニッシュでしょう。

 

「Reactを使ったWebアプリで現行のスマホアプリを代替すれば、Androidの多機種対応でかかっていたコスト月300万くらい浮かせられます

「そのMariaDB、ぼくにチューニングさせてくれれば、1晩かかったバッチを30分にできます経営層がスピーディーな意思決定できるようになって、売上機会ロスを減らせます

「バラバラに使っているクラウドの運用管理を一元化する仕組みを作れます。そうすれば運用人員が30%くらい減らせると思います」

 

このように、買い手の課題を自分のコードがどう解決するか、つまり買うヒトと自分のモノの関係性を定義するストーリーが語れれば、きっともっと、エンジニアにつく値札は高くなるのではないでしょうか。

粗雑なコードでも喜ばれた例

手前味噌で申し訳ないですが、コードとベネフィットをストーリーで紐づけた例を1つ紹介します。

参考 記事間の内部リンク構造を可視化するWordPressプラグイン「Show Article Map」 – naenote.net

書いたコードはとても簡単で、全部で100行もありません。

  • 記事のデータを引っこ抜く
  • 記事内のaタグから内部リンクを識別する
  • 記事と記事のマップデータを作る
  • 外部のJavaScriptライブラリで可視化する

ぼくはエンジニアとしては三流なので、中身は粗雑ですし、コードの品質も悪いです。作るのにも5時間くらいかかりました。知っている人なら、きっと30分かからずもっと良いモノが作れるでしょう。

にも関わらず、かなり多くの人に使っていただき、界隈では少し有名な人の目に止まって「いいね」とコメントいただいていたり、ありがたいことに大変好評いただいています。

その理由は、上の記事において、ユーザの課題をコードがどう解決するか、ストーリーを書いて伝えたからです。

つまり粗雑なコードであっても、ユーザの抱える課題(問)と自分のコードができること(解)のつながりが明確に伝えれば、きちんと評価されるんです。

ユーザとコードの関係性を「ストーリーを語り伝える」部分が、「匠の技」に固執するあまり安く買われてしまうエンジニアに足りない部分じゃないのかな、と思うのです。

まとめ:「匠の技」に甘んじていないか

そもそも、冒頭で紹介した記事の根幹をなすものはこの部分でしょう。

世界のエンジニアは何ができるかで名札と値札が決まる。「ビッグデータの解析でこんなことができる」とか「こういうゲームのこの部分をつくった」とか「この橋の構造設計をした」とか、どの領域で何ができるのかで名札が付き、マーケットでの値札が決まってくるのだ。

出典:日本人エンジニアの給料が上がらない理由 | プレジデントオンライン | PRESIDENT Online

つまり、「何ができる」レベルまできちんと語れれば値札がつくということ。

その「何ができる」の目線の高さが、世界と日本で全然違うのでは…と思うのです。

  • 世界:課題解決のインパクトを語る
  • 日本:モノのできの良さを語る

もちろん、それを評価する側が「そんなん知らない年功序列や」と言ったらそれまでです。

しかし、だからといって「技術の匠」の世界に閉じこもっていたら、あがる給料も上がらなくなってしまうのではないでしょうか。

自分の書いたコードはどんなベネフィットをもたらすのか?誰のどんな問題を解決するものなのか?

一度、自分のコードに「売り文句」をつけてみてはいかがでしょうか。

仕事術の本を書きました
「天空の剣」を探すより「こん棒」を育てろ

仕事術は、レベルアップする武器と似ています。
違うのが、Lv.100のこん棒=鍛えあげられた基本の仕事術が一番使える点。
しかし、中には鍛えても育たない「ハズレ武器」も……
では、どれを育てればいいのか? 43の「当たり武器」をまとめました。

話し方・伝え方

関連おすすめ記事

この記事を共有する
著者プロフィール
NAE

IT戦略とデジタルマーケティングを主に扱う外資コンサル。「こうしたほうが早くない?」が口癖の効率化マニア。目指す人物像は三国志の左慈仙人。詳しいプロフィール、お問い合わせはこちら

NAEをフォローする
スポンサーリンク
NAEの仕事効率化ノート

コメント

コメント以外のご意見・ご要望、管理人へのご連絡などは、お問い合わせからどうぞ