エンジニアは給与の主導権を市場にさえ渡していないけない
エンジニアの働き方は様々だ。社員、派遣、業務委託とエンジニア本人の働き方、業務へのコミットで働く場所を選べる時代になった。
肌感として、18年より19年の方がエンジニアの流動性は高いが、オープンしているポジションのスキルセットと応募してくるエンジニアのスキルセットのミスマッチは相変わらずである。
その辺り、つまり採用にも関心があるためタイトルで釣られて読んでみたら、何言っているのかという感想しかない。
市場原理では、需給バランスによって商品やサービスの価格が決定します。人材市場という観点に立てば、エンジニアも、供給が足りなければおのずと給与が上昇していってしかるべきです。
何に対して何を言っているのかと半ばあきれているかというと、エンジニアの供給が枯渇しているのであれば、自然と給与も上がらなければならないと主張している。
まあ、読み物で『べき論』で書かれている場合、ロクな主張に出会った記憶はない。それはさておき、需要過多であることはそのとおりであるが、需要のあるエンジニアは『お前ではない』という需要家サイドの視点が抜けている。いくら需要があったとしても、供給されるエンジニアのスキルがレガシーだったり、単機能工なエンジニアにマーケットがあるのかということである。
もちろん、オープンしているポジションそれ自体のコンピテンシレベル（組織内でのバリュー評価の位置付け）が高く、それに見合うかそれ以上であれば相応の報酬を支払うから結果的に給与は高くなるが、もともと報酬は高いエンジニアだろうから前述のロジックとは一致しない。
更に、次の記述を読むとがっくりしてしまう。
しかし、海外から安い労働力を呼び込むことで、人件費の上昇は抑えられ、結果としてエンジニアの給与はいつまでも上がらないのです。
引用 同上
確かに、オフショアが流行ったのは固定費である人件費の削減が一因であることは誰もが否定しないだろう。
だが、エンジニアの市場価格の話をしておく一方、エンジニアの給与はオフショアの単価に引っ張られて上がらないのかというと、それは違う。
どういうことかというと、オフショアの安い労働力で人件費カットを起因としてエンジニアの給与が上がらないという図式は成り立たない。その関係が成り立つのは、オフショアに出された仕事を請け負っていたエンジニアは同じ仕事をしている限り、オフショアと同じ単価に寄せられるか、よくて維持かもしれないが、オフショアの仕事とは別の需要のあるスキルセットを持っているエンジニアは別の需要の単価で取引する。
端的に言えば、オフショアに持っていけるほどの仕事しかできないエンジニアはもともと市場的に価値はそれなりでしかなく、コモディティ化したスキルには相応のプライスしか値付けされない。
エンジニアは市場で期待値の高いスキルを有していなければ、高い給与の引き合いがそもそもない。
それよりも、なのであるが、引用した所の物言いのニュアンスがどうもアレである。なぜ、エンジニアの価格を市場が勝手に決めるのか。違うだろう。採用でも転職でも業務に関わっているとわかるのは、転職応募者と採用側の相対で最終的には給与を決める。提示するのは採用側であるが、意思決定ではエンジニア側にもリジェクトする権利を持っている。エンジニアが市場で期待する価値から離れていると思えば、エンジニア側からお祈りすればいいのである（実際、報酬は転職時の重要な意思決定の観点である）。
ここだけ読めばいいのであるが、市場に期待するスキルを持ち、それに見合う報酬をくれる会社を探せばい良いのである。お金の主導権を他人に渡していないけない。
PFU Happy Hacking Keyboard Professional BT 無刻印/墨 PD-KB600BN
- 発売日: 2016/04/12
- メディア: Personal Computers
プロジェクトは課題解決をしなければならないが、チームは課題解決ばかりしてはいけない
プロジェクトは課題解決をしなければならないが、チームは課題解決ばkりしてはいけない
矛盾しているか、矛盾していないと思うか。
プロジェクトの場合、課題はプロジェクトの進捗上の障害であるから、解決しなければならない。
ことの起こりとして、課題はアクティビティの予実の較差や制約条件の取違もしくは前提条件の未達など、こう進められるはずだ、こう出来るはずだ、が実現しないと見込まれるか、実際、できなかったから課題になる。
であるから、プロジェクトの課題は解決しなければ、プロジェクトはQCDSのいずれかを達成できな可能性がある。よって、プロジェクトは課題を解決しなければならない。
一方、チームはどうか。課題解決ばかりして、なぜいけないのか。
業務の活動には、課題はつきもので、それは運用をしているから生じる。業務運用を設計したときのデザインがもともと悪い、チームの対外が変化して影響を受ける、チームの体制が変わるなど、運用は生き物である。
プロジェクトのチームではどうか。プロジェクトのチームなら課題を解決しなければならないのではないか。
一見、そう見えるが必ずしもそうではない。運用の不都合は改善した方が良いのは当然だが、（色々と課題になるくらいの問題が内在しているとはいえ）運用は回っているのである。
ではどうして課題解決ばかりしてはいけないのか。
それはチームが近視眼的な思考に縛られて、チームとしてのToBeを蔑ろにしてしまうからである。プロジェクトや業務のどちらのチームであったとしても、チームの活動として達成したい目的を持っている。それはプロジェクトの目的の達成だったり、チームのビジネスの目的を達成だったりする。
その目的を達成するために、チームとしてなりたい姿がある。それに近づくには、チーム全員で目的を理解し、同じ方向に進まなければならない。そのとき、手間の課題ばかり解決していると『なんのために』やっているか目的を見失う。
１件ごとの課題として認知するが、それを解決することで、チームの目的を達成できるかはまた別である。チームは、その課題を解決することでチームの目的を一番達成できる課題を解決した方が良い。つまり、チームの存在にとって、優先しなければならない課題であるか、それを選択する見識を持って挑む必要がある。
しばしば、ロールの帽子や目線や俯瞰などと表現される、アレである。
小さい失敗と計測すること
イタリアンでアラカルトのサラダを摘みながら、アーキテクトの話を聞いていると知らないことが世の中にたくさんあることに気づけてよかったな、と思う。
だから、多少の知見なり実践知のないところでは素人だし、専門外のところをやっているエンジニアはすごいなと思う。
この年齢になっても相変わらず間違いが勘違いや失敗をする。ただ、大きく失敗はしないようになった。
失敗は小さく。
リカバリができるサイズで。
アーキテクトの言うには、若いエンジニアで失敗をしたくないです、と言うエンジニアと、僕は完璧ですと言うエンジニアがいるのだそうだ。
なんだかな、と思わなくもないが、どちらにしろ、ご苦労様です。
成功したプラクティスは再現も再構成もできないが、計測されている小さな失敗は回避できる。
だから計測をしなければならない。
計測をして、リソースの許す限りの中で、もっともまともなものから所産を選択するのである。
退職エントリまとめ（2019年7月〜9月）
2019年版の退職エントリのまとめ。はてブで退職エントリで検索した結果を7月から四半期ごとに括ったものである。
この四半期も多いなと思い始めると途中から作業感が半端なく出てきて何をやっているのかと思わなくもないが、これで色々なエンジニアがいるのだなと思うのでいいのだろう。
7月
い続けてやりたいことがないと辛いね。
6月にやめた人。
これも6月にやめた人。
Yの人は割と転職活動してますよね。
6月にやめた人。
これも6月にやめた人。
グルメ系。
3月にやめてた人の。
これも3月にやめてた人の。
NEC。
すっかりいいイメージがない。
スーパーエンジニア社長との戦い
転職したいと書いて、転職したエントリ。
異動エントリ。
NTT。
音楽家！
やりたいことがあるのはいいですね。
退職エントリを書いて、はてなに転職した人。
8月
エンジニアからライターへ。
後編。
お大事に。
９ヶ月前に転職した人の話。
memorandumcedretabri.hatenablog.jp
退職してからひと月後の心情。
Web辞書会社の給料は安い。
ドワンゴを退職。N高立ち上げに関わったんだ。
退職のご挨拶。
退職エントリなんて書けないよというエントリ
6月に退職したエントリ
辞める時の退職に対するマインドが変わってるw
知財系女子
3月に退学して就職するのね。
9月
退職予定エントリ。新しい。実際、有休消化もある実質退職日とかあるからねぇ。
博士課程か、ちょっと憧れる。
人前で話すのは本当に回数なんですよねぇ。
廃業エントリ
10年後のなっていたい姿を持っているのはいい転職になる気がする。
retrogameraiders.hatenablog.com
1年で2回目！
パワハラで春に退職…
さいげかー。
院へ
From→Toのみ。
ロクでもないプロジェクトのシステム運用と自分のキャリア
ロクでもないプロジェクトは世の中に多い。実際、ロクでもない案件にアサイメントされたことがある。会計システムの再構築プロジェクトは、プライムベンダとサブコンの関係は良いとは言えず、顧客も契約後に値切るような慣習を持つ会社だった。
当時、イケていないエンジニアだった自分は、それでもできることをやり、アプリ共通のパッケージを作ったりしていた。ロクでもないプロジェクトを自分なりに眺めて、システムレベルの相関図がないことに気づき、誰もが担当部分しか手掛けていなかった全体のジョブやDBを網羅した新システムの全体関連図を作ったりしていた。
サービスインをすればシステム運用が始まる。現行システムのシステムはレガシーレベルを超えた神話のようなシステムで運用担当のエンジニアはろくに帰れず、帰ってシャワーを浴びたところに呼び出しされるような代物だったらしい。
その神話なシステムの次世代システムの運用をやってほしいと打診があった。現行システムのひどいシステム運用を知っていたり、顧客のいわゆる客筋を知っていると反射的に『やめておけ』と頭の中で誰かが囁く。
いくら新システムに切り替わったからと言って、筋の悪い顧客の相手をしつつ、全体のシステムデザインをした訳でも、業務知識もろくにないシステムのお守りをするのはやれるイメージを持てない。
とは言え、打診と言いつつもこれは逃げられないものだと勝手に思っていた。今なら瞬殺でお断りしていただろう。
打診を聞いたあと、仲の良い元上司に再構築の案件で入っていたプロジェクトの運用の打診があったことだけを伝えた。
人は期限があればそれを希望にできる。
ただそれが裏切られなければ。
どうしたらこの打診を回避できるか。
考えた。
当時はまだ交渉のスキルは持ち合わせていなかった。
でも考えた。
これはやりたい仕事ではない。
あるところで諦めと覚悟をすることにした。
考えて、どうしたか。
打診をしてきた上役に2つのことを伝えた。
「自分はこれこれというやりたいことがある」
「もし運用の案件をやるなら1年なら受ける。それ以上はやらない」
これこれというのは実は具体性のある名詞が入っている訳ではない。ただ、この方面の仕事をやって行きたい。そう伝えた。
しばらくしてその話は有耶無耶になった。代わりの誰かにシステム運用のお鉢が回ったのだろう。
後から耳に入ったのは『あいつはやりたいことがあると言ってた』という割と好意的なトーンの物言いだった。
直接は聞いていないのだが、仲の良い元上司は動いてくれていたかもしれない。マネージャ同士は割と繋がっている組織だったからそう言ったこともあっても不思議ではない。
そのあとのプロジェクトは仲の良い元上司から案件を紹介された。それを考えると裏で手を回してくれていたのだろうと思う。単に仲が良いだけではなく、厳しいアドバイスをしてくれる元上司はそういうところがあるマネージャだった。
次の案件がエンジニアのキャリアにとって、大きなピボットになるとは当時思いもしなかった。
運用設計の教科書 ~現場で困らないITサービスマネジメントの実践ノウハウ
- 作者:日本ビジネスシステムズ株式会社,近藤 誠司
- 出版社/メーカー: 技術評論社
- 発売日: 2019/08/23
- メディア: 単行本（ソフトカバー）
自分のアップサイドを作る
このブログでも、これまでずっとスキルを上げよう、伸ばそうと言い続けていた。実際、エンジニアのスキルは価値＝できることに繋がり、結果としてやりたい仕事につけたり、評価されたり、報酬として返ってきたりする。
見方を変えれば、スキルはエンジニアの価値であり、それを増やさないと競合するエンジニアに追いつかれ、抜かれ、追い抜かれる。
市場は時価であるから、市場に自分を売りに出すとそのときに需要のあるエンジニアは高く売れ（採用され）、需要のないエンジニアは売れない。
市場を所属する組織としている場合、その組織で時価評価をしていなければ売値が下がることはないが、仕事があるかどうかはまた別な話ではある。
市場のニーズとして、労働集約的なビジネスを主流としていたときは、技術を使えればよかったが、知的生産的なビジネスニーズに転換をはじめたいま、どの技術を、どんな方法で使えば目的を達成できるかという技術の見識眼と適用にシフトしていると感じている。
これは技術を使えるというときの、使えるの中身が問われているのと同じだ。使ったことがある、ではこの先、生き抜けない。
肝心だと勝手に思っているのは、
- 調べる力
- 技術の身につけ方
- ロジックの建て付け方
- 汎用できるパターンを見つける
ではないか。1-3までは若手の頃に身につけておきたい。4は経験が多くなるにつれアーキテクチャや概念で話す必要が出てくるため、必要となると思っている。
これを仕事の中ばかりで意識してやっていると、とても疲れてやって続かない。正直、無理と思うのももっともだと思う。
少し、横道に逸れるのだが、今年、仕事とは全く関係のない分野に首を突っ込んで、ある資格の前提講習を受けた。これは全くもって仕事に紐づかないし、関連しない。
そこにリソースを掛けてそれをしていること自体がおかしいといえばおかしいし、自分でもバカなんじゃないかと思う。本来であれば、関連する方でエンハンスしているところにリソースを割くべきで、そっちは半ばお留守番になっている。
ただ、その仕事とは関係のない分野で、前述の1-4がとても役に立っている。関連のない分野であるから知識を得なければならないし、情報をなければならない。首を突っ込んでいる分野での技術的な好奇心が疼き、一定のパフォーマンスを得られるように改善を行い、技術を育てる。そこには再現できるような考えの軸を育て、パターンにデザインしていく。
何が言いたいかというと、仕事と関係ないところで仕事で必要な振る舞い方や思考を整理する訓練できるということである。
自分のアップサイドを作るのを楽しくやるにはこうした間接的なやり方もある。
![[ポーター]PORTER アップサイド UPSIDE 3WAY OVERNIGHT BRIEFCASE S 532-17901 ベージュ/40](https://images-fe.ssl-images-amazon.com/images/I/51JK2cT8YDL._SL160_.jpg "[ポーター]PORTER アップサイド UPSIDE 3WAY OVERNIGHT BRIEFCASE S 532-17901 ベージュ/40")
やばいエンジニア
カジュアル面談をしたとき、このエンジニアはやばいな、と思った。やばいというよりは、猛烈な違和感というか、危機感というか。
カジュアル面談をするとき、面談をしている候補者と働くことをイメージしながら会話をしている。もちろん、採用したいポストのスキルセットを持っているかや、価値観など、幾つかの観点で見ているのであるが、同じように、目の前で会話しているエンジニアと一緒に働くことをイメージできるか想像しながら会話を交わしている。
実は、候補者が送ってきたレジュメを見たときのファーストインプレッションは、書類選考でお見送りでいいかと思っていた。エンジニアのリーダに候補者に興味があるかを聞いてみたら『会えばいいじゃないですか』という。なぜかを尋ねると『現職は○○社だから』という。
基本的に、どちらかが会いたいと言えば会うことにしている。自分が会いたいと思うから会うことに疑問の余地はないが、自分は興味はなくてももう1人が会いたいという感覚は自分にはないものだから、それを尊重しているのである。
それで実際会ってみたわけだが。
最初は、候補者も手探りしているようだったが、こちらの説明でいくつか興味を引いたようで、次第にガードが下がり、ズバズバと（という感じで）本音で質問やご本人の考え方を話出してくれた。
次第に、ヤバさというか、焦りというか、危機感を感じた。そのヤバさとは、排除した方が良いのではないかというものだ。
ではどうして排除した方が良いとちょっとでも感じたのか。
それは、自分より優秀だと本能的に察したからだろう。
誰でも自分以外のエンジニアは自分の専門とは違うスキルを持っているから、敬意を持っている。その上で、これはすごいなと感じるとき優秀だと思う。
この候補者と一緒に働いたら、どれだけ自分が冷や汗を書くかもしれないと思った。
この候補者と働くと自分も成長をまた違う面で求められると思った。
それを理解したとき、採らなければいけないと思った。
1つだけ、採用の優先事項と違う点があるが、それは次のステップの中で聞いてみたらいいだろう。
