キャリアコンサルタントに1on1のコツを学ぶ

キャリアコンサルタントは国家資格

前口上

物事を学ぶにはいくつかやり方があります。本を読むもよし、動画を見るもよし、講習に行くのもよいでしょう。体を動かすような能力を学ぶ場合、作業研修をする場合もあると思います。

ただ対人スキルを身につけたい場合、このやり方は適していないことも多いです。物に対する場合と違って、人は人それぞれ変わるからです。

営業だとロールプレイングをすることもありますね。会話の問答をパターン分けしてシミュレーションを行うわけです。

マネジメントも同様で座学だけだと習得が厳しい部分があります。キャリアコンサルタントという資格があるのですが、キャリアコンサルの形式が1on1のそれに近いものがあり、学べるところがありそうなので今回見ていきます。

キャリアコンサルタントとは

キャリアに関する職業といえばキャリアアドバイザー、キャリアカウンセラーの方が馴染みがあるかもしれません。それもそのはずでキャリアコンサルタントは2016年4月から国家資格になった比較的新しい資格です。業務独占でなく名称独占なので箔付けの一つですかね。

令和４年版　労働経済の分析の中で、キャリアコンサルティングを受けた人と受けていない人の差について分析されています。概ねキャリアコンサルを受けたことのある人の方が、仕事に満足していることが多いようです。他にもいくつか利点が述べられています。

物価高によって賃上げが岸田内閣の1テーマですが、リスクなしに何かを得るうまい話は世の中そんなにない気もしています。

人はゆるふわ大手の就職を求めがちですが、既存大手企業は人数も多い分賃上げが渋く、人数の少ないぽっとでの成長産業の企業の方が倒産リスクは高いですが賃上げに積極的な印象です。

アメリカだと社会人になってから大学に通うというのもよくありそうですが、日本だと少数派ですね。実際産業をまたぐ労働者の移動は数%です。

コンサルされただけでスキルがつくわけではないですが、キャリアコンサルタントの国家資格化もリスキリング拡充の文脈の中で、転職支援策の一環として成立したというのが自分の理解です。

キャリアコンサルタントの受験資格

キャリアコンサルタントの受験資格を得るための方法は3つあるようです。

• 厚生労働大臣が認定する講習の課程を修了した方
• 労働者の職業の選択、職業生活設計又は職業能力開発及び向上のいずれかに関する相談に関し3年以上の経験を有する方
• 技能検定キャリアコンサルティング職種の学科試験又は実技試験に合格した方

キャリアコンサルタント技能試験はキャリアコンサルタントの上位資格とされるようなので一旦無視すると、パスは講習を受けるか３年の実務経験をするかのどちらかですかね。

講習は認定講習の業者によるのですが、160時間、35万円程度かかるようです。

試験内容

試験内容は以下です。

• 学科4択マークシート: 100分
• 実技記述式: 50分
• 実技ロールプレイ/口頭試問: 20分

受験料が学科8,900円+実技29,900円。

学科は統計や心理学のような問題が多いようです。過去問から抜粋すると「令和3年度能力開発基本調査 調査結果の概要」(厚生労働省)で示された、キャリア コンサルタントに相談したい内容に関する次の記述のうち、最も適切なものはどれか。」、「キャリアの各理論に関する次の記述のうち、不適切なものはどれか。」などが問題です。

論述は会話の内容を元に議論する問題です。同じく過去問から抜粋すると「事例Iの CCt10 と事例IIの CCt10 のキャリアコンサルタントの応答が、相応しいか、相応しくない かを考え、「相応しい」あるいは「相応しくない」のいずれかに○をつけ、その理由も解答欄に記述せ よ。(10 点)」など。

ロールプレイはYouTubeに動画がいくつか上がっているので見ていきましょう。

キャリコンのロープレを学べるチャンネル

キャリコンシーオーが一番動画が上がっています。少し相談者が女性のパターンが多いかもしれません。

ただ物量は魅力的ですね。実際の人間はいつもの二人なのですが、キャラクターを動画ごとに演じ分けています。

リベラルコンサルティング協議会は動画は少ししかないのですが、OKパターンとNGパターンの動画が比較されているのがよかったです。

OKパターン

NGパターン

キャリコンから学べる1on1のコツ

• 傾聴

傾聴! 傾聴! 傾聴! というくらいカウンセリングのコツとしてあげられている動画が多いですね。キャリコンの主張や思い込みで話を誘導しない、決めつけないというのが大事なようです。

単に話を聞いているのは傾聴ではなく、相談者の気持ちの整理や考えをまとめる手助けをするのがポイントのようです。

• 間

相槌やキャリコンの意見を言うタイミングの間がロープレから学べることの醍醐味ですね。意見を言ってもいいですか？今までの話をまとめていいですか？と丁寧に切り込むやり方がノウハウ

• 悩んでいることが本当の問題、解決策でないことがある

PMでも顧客が欲しいと言うものと本当に必要なものが違うということがありますね。2択で悩んでいる場合は副業で両方取れないか、第3の選択はないか、将来のイメージはどんなか聞いてきて、最初に相談してきたことにとらわれすぎない方がよいようです。

所感

技術系特化というわけではないので、参考になる部分と参考にならない部分がありますね。世の中にはいろんな職業があると勉強になりました。

一つの知見として視野が広がったのはよかったですが、キャリコンはコンサルのスキルの枠組みの中で戦うので、もう少しデータを元にそのキャリアを選ぶリスクとリターンをうまく説明できるとよいかもしれない。

SIerだと違うかもしれないですが、Web業界は比較的若い人が多く、レファレンスがないため定年まで技術者をやっている人のイメージが湧いていない人も多いようには感じます。しなくていい苦労だった説はありますが、伝統的日本企業で定年のエンジニアの送迎だったりを経験した分、そこらへんのイメージの解像度は純粋培養Web系エンジニアより自分は高い気もしています。

HIGH OUTPUT PLAYER - 評価されるプレイヤーはどういう人か

独自理論を提唱してみる

前口上

HIGH OUTPUT MANAGEMENTというマネジメントについて書かれた本があり、そのなかでマネージャーの評価の公式が出てきます。

マネジャーのアウトプット＝自分の組織のアウトプット＋影響力が及ぶ隣接組織のアウトプット というやつですね。

さてこの公式、マネージャーの評価方法の一つとして的を得ている部分はあるのですが、これを少し拡張するとプレイヤーにも使えるより汎化された公式になるのでは？とふと思ったので提案してみます。

TLDR

さっそくですが新公式です。

職業人の評価 = 自身の能力 + 自身の専門性組織への影響力 + 専門外の組織への影響力

以下細かく見ていきます。

マネージャーの評価はHIGH OUTPUT MANAGEMENT + 他マネージャーへの影響力 で決まる

マネージャーの専門性がマネジメントだとすると上に上げた公式は以下のようになります。

マネージャーの評価 = マネージャー自身の能力 + 他のマネージャーへの影響力 + 隣接組織への影響力

概ねHIGH OUTPUT MANAGEMENTの通りなのですが、他のマネージャーへの影響力の部分が増えています。

マネージャーが例えば課長レベルとして、課長と部長の違いはどこにあるかと言えば、課長を育成できるかという部分だと思うんですよね。HIGH OUTPUT MANAGEMENTの公式は課長の評価制度としては的を得ている部分はあるのですが、どういう人が部長になりうるかという観点が欠けています。

マネージャー自身の能力はマネジメントもそうですし、課長レベルなら一定のプレイヤーとしての能力もいるでしょう。

マネジメントが集団を率いる能力だとすればマネージャーのマネージャーのマネージャーくらいになると純粋なマネジメント力だけで戦える可能性もありますが、せいぜい課長レベルなら現場よりなので普通にプレイヤーとしての能力も一定程度必要な気はしています。

隣接組織への影響力はそのままです。

プレイヤーの評価はマネージャー評価をチャプター視点で見たもの

次にプレイヤーは公式を適用すると以下のようになると思います。

プレイヤーの評価 = プレイヤー自身の能力 + 同じ専門性のプレイヤーへの影響力 + 隣接専門性への影響力

おおむねSpotifyモデルでマネージャーがSquad軸で見ていたものをプレイヤーではChapter方向で見ています。

プレイヤー自身の能力はわかりやすいですね。ソフトウェアエンジニアならテックリードとしての自身の能力の部分。

同じ専門性のプレイヤーへの影響力はChapterを率いれるかでここが今回のHIGH OUTPUT PLAYER理論の肝の部分です。ソフトウェアエンジニアでIndividual Contributorの方のインタビューなんか見てもただコードを書くというよりは結構コミュニケーションは必要とされている印象です。

コンサルのような業態やフリーランスの場合はいらない場合もあるかもしれないですが、組織内でサラリーマン的働き方をしていると、単に専門性があるだけではだめで、組織内でエバンジェリスト的役割を期待されることが多いようには思います。〇〇専門委員会を率いて専門組織の底上げができるかが大事かなと。

隣接専門性への影響力は従来コンピテンシーの中にあったようなソフトスキルの部分と、これはプレイヤー自身の能力といえば自身の能力なのですが、複数専門性がある場合に橋渡しできているかがここのポイントになる気がします。

例えばプロダクトデザイナーをおいている企業だとデザイナーがPMの役割を少し兼務している場合があります。同様にデザイナー+フロントエンド=デザインエンジニア、エンジニア+PM=テクニカルプログラムマネージャだったり、２つ専門性があると強みは増えますね。

ジョブ型雇用時代ではコンピテンシーの分解が必要

今回提案したHIGH OUTPUT PLAYER理論はメンバーシップ型雇用であいまいだったコンピテンシー評価の部分がより分解された形だとも思っています。

つまり、従来のコンピテンシー評価 = 自身の専門性組織への影響力 + 専門外の組織への影響力 に分けられるのではないかと。

メンバーシップ雇用でジョブローテがあるとその組織のカルチャーにどれだけどっぷりつかっているか、社内に知り合いがいるか、いいやつかあたりがぼやっとコンピテンシーにのっていた気がします。自身の能力+コンピテンシーで評価だと自身の専門性組織への影響力が軽視されていたのではないかと。

メンバーシップ雇用からジョブ型雇用に移行しようとしている企業は、組織の専門性をあげるために社内エバンジェリスト能力の高さを明示的に別の項とすることでよりうまくいくのではないかというのがひとつの仮説です。

所感

読めていないのですが、エンジニアのためのマネジメントキャリアパスの対極の本でThe Staff Engineer's Pathという本も出版されているようです。読んだらレビュー書きたいと思います。

日本のWeb開発にスクラムは本来不要かもしれない

専任のスクラムマスターは必要か

前口上

最近スクラムの源流である論文『The New New Product Development Game』を読みました。概ね日本企業を良い開発手法を採用している企業として、米国企業はどうやったら日本企業のようなよい企業になれるかを論じたものです。スクラムガイドのスクラムも影響を受けているようです。

スクラムはアジャイル開発の中では採用件数が多い手法ではありますが、専任のスクラムマスターは置いていないという企業もままあり、どういう時にスクラムガイドのスクラムが有用で、専任のスクラムマスターを置くことの合理性が高いのか整理してみます。

The New New Product Development Gameの概要

さてこの論文、いくつかの企業の製品を例に比較しています。製品は

• 富士ゼロックスの中規模コピー機
• キヤノンの家庭用コピー機
• ホンダの乗用車
• NECのパソコン
• キヤノンの一眼レフ
• キヤノンのレンズシャッターカメラ

で、それらの開発手法を分析しています。分類すると各工程が独立しているウォーターフォール的タイプA、隣接工程がオーバーラップするタイプB、全工程が影響し合うアジャイル的タイプCになるようです。

リードしている企業は以下の特徴を持つとされています。

• 不安定性の内在
• 自己組織チーム
• 開発フェーズのオーバーラップ
• マルチ学習
• わずかなコントロール
• 組織的学習の伝達

概ねボトムアップの強さ、強いトップダウンがなくても改善のサイクルを回せていることを日本的企業良さとしているようです。

日本企業はスクラムがやりたかったことを元からできている

こうしてみると、日本企業の少なくともトップ企業では元々スクラムの要素は元からできていた言えます。

スクラムガイドのスクラムは米国企業に日本企業的開発手法を取り入れるためのマニュアルとも捉えられて、日本企業は何もする必要がない可能性もあるわけです。

シリコンバレーだとエンジニアは1〜2年で転職してしまうとも聞きます。アメリカは移民にも積極的で人も多様ですね。文化的コンテキストの共有が困難で専任の調整役がいる合理性があるわけです。

一方、伝統的日本企業はほぼ全員日本人で終身雇用です。もっと言うならほとんど男性だけだったかもしれません。同僚は長年一緒に働いた見知った顔。専任の調整役がいなくてもよしなにやってくれることも多いでしょう。多様性のないチームほど専任のスクラムマスターは不要です。

日本企業に必要なのはマネージャーレベルの底上げ

一方で今後も日本が同じ手法が使えるかは疑問が残ります。OpenWorkの統計によると、直近10年間で残業時間は月46時間から24時間に減っています。働き方改革の影響ですね。

日本企業はマネージャーがプレーヤーの能力にフリーライドしていた部分がもあったとも言えて、管理者が方向性を少し失敗しても残業ありきでプレーヤーが勝手にカバーしてくれていたからです。今後も人手不足がより進んでくるとそういったマネージャーの能力のなさが今までよりどんどん可視化されていきます。

今強いものをより強くしてももちろん良いのですが、スクラムは暴論を言えばプレーヤーもっと頑張れのフレームワークであり、日本ではもうできている可能性はあります。むしろ逆側のフレームワーク、管理者研修だったり、サラリーマン社長をどう創業社長に近づけるかだったり、米国のいいところを日本企業にどう取り入れらるかを考える方が大事かもしれません。

メンバーの従業員エンゲージメントを管理職の人事評価に使っている企業もありますね。

開発チーム内の職種が多くないとスクラムマスターは不要

他にも専任のスクラムマスターが必要かの視点はあって、例えば開発チーム内のコミュニケーションパスが多いかは一つの指標です。

ソシャゲ全盛期の方がスクラムスクラム言っていたと思うんですよね。それはある種当たり前のことで、本質的にゲーム開発はWebサービス開発と比べてアセットヘビー。プログラミングが必ずしも花形でなくグラフィックや音声も必要で、当然開発内でのコミュニケーションパスが増えます。専任の調整役を置く蓋然性があるわけです。

一方toB SaaSなんかだと導入役のカスタマーサクセスが事業構造上必要と言われており、コミュニケーションパスがソシャゲと比べると開発内から外に移転したトポロジーです。開発内の調整需要は相対的に低いですね。逆に間に入るPMは忙しいになりやすく、複数PMの企業もちらほらみます。

スクラムに限らずIT企業というざっくりとしたカテゴリーわけだと事業構造を捉えることは困難で、Webサービス開発、ゲーム開発、システムインテグレーションはそれぞれ必要な要素が変わってくるので、異なる業態のチームトポロジーはあまり参考にならないことも多いです。

モジュール化が簡単な領域ほどスクラムマスターは不要

IT企業にはもう一つ専任のスクラムマスターの必要性が低い要因があって、それはプログラミングがチームスポーツの中では比較的個人競技だからです。

The New New Product Development Gameに出てくる企業はメーカーなんですよね。それこそ自動車の部品点数はとにかくたくさんあり、相互に作用していることも多いです。機械設計は物理空間に存在がある関係で疎結合しにくいです。ワイヤレスイヤホンの音質向上のためにモジュールをよくしたら重量が目標をオーバーしてしまったりそういうことが起きやすいです。

IT企業でも決して連携が不要なわけではないのですが、プログラマーの生産性が人によって何倍も違うと言う話の根源に何があるかと言えば野球のピッチャー的存在というか個人性の高い部分だと思うんですよね。

以前資本集約的ビジネスと労働集約的ビジネスの違いについて書いたのですが、労働集約的ビジネスの中にもチーム性の高いものと個人性の高いものがあり、メーカーがカメラを作るよりはプログラミングというのは(ちゃんと設計すれば)モジュール間が密結合になるのを避けられます。

DXコンサルの仕事はいずれなくなるのでスクラムマスターは不要

最後にDXコンサルトとしてのスクラムマスターについても書いてきます。スクラムマスターがスクラムというDX手法の伝導者なら教えを布教し終わったら不要になるのではという意見です。実際そうだと思います。

専任のスクラムマスターがスタートアップの実ロール名で言えば何かと言えばCOOだと思うんですよね。PMでもなければテックリードでもない人なので。ボードメンバーが厚い会社の方が投資家目線だと投資したい会社ではあるのでCOOが不要かというとそうではないのですが、ストックオプションの付与率なんかをみてもCFOやCTOなんかと比べるとCOOは貰えていないことが多いです。

技術もわからずプロダクトの方向性も示せない人がいて助かるか?と言えば必要な場合もあると思います。ただ全てではないです。

エンジニアをざっくり分けると技術が好きな人とプロダクト開発の好きな人に分けられると思っているのですが、任意の領域Aについて最初にそれを開発できるのが誰かといえば技術が好きな人のことの方が多いです。機械学習ブームの時に社会人より学生Kagglerの方が強い瞬間もありましたし、ブロックチェーン起業家が若いという話もあります。

Googleの例なんかをみてもギークな若者技術者+大人で会社を成立させる例はあるのですが、スクラムマスターはこの大人を成立させるためのある種方便の可能性もあります。ただ、時間が経ってギークな若者技術者がキャリアを積んでくると確率的にマネジメントができる人も出てきます。時間が経つにつれてCOO、スクラムマスターはいなくても成立するようになるわけです。

CEOの代わりが務まるCOOならウェルカムですが、COO的キャリアは何ができるのかよくわからない人になってしまう可能性もあると思って、上手く立ち振る舞わないとキャリア上不利になることもある認識です。

まとめ

ダイバーシティーの低い日本企業で、プログラミング自体が比較的花形の業態で、ぽっと出の技術がメインではないWeb開発企業ではスクラム、とりわけ専任のスクラムマスターは不要かもしれません。

スクラムガイドでもスクラムマスターは概念と書いてはあるのですが、これだけスクラムマスターは兼業でやっているという企業が多いのを見ると、もっと上手く必要なチームトポロジーを説明したモデルを発明したいものです。

[Qiita投稿] Twitterを支えるインフラ: スケール

Twitterの技術ブログを訳してみる

TLDR

Qiitaに「Twitterを支えるインフラ: スケール」を投稿しました。Twitterの技術ブログの非公式訳です。

qiita.com

所感

イーロンマスクがTwitterの構成図をTwitter上にあげたのが先日話題になりました。

Twitterの公式ブログをさらった限り、アーキテクチャーを全体的に解説したものはこれが最新のようです。

Twitterの技術ブログ、10年以上前から運営されているのですが、途中からデザインが変わったようで5年以上前あたりからリストビューからうまくたどれませんでした。サイトマップもないようなので昔の記事を拾いにくいのが難しいところ。

[Qiita投稿] 職務範囲が増え続けるのを防ぐジョブディスクリプション・ポーカー

デリゲーション・ポーカーを改造してみる

TLDR

Qiitaに「職務範囲が増え続けるのを防ぐジョブディスクリプション・ポーカー」を投稿しました。闇の魔術に対する防衛術 Advent Calendar 2022 Day8の記事です。

qiita.com

所感

3人の間でボールも整理するかも考えたのですが、FigmaやMiroで同心円を描けばいいんですかね？

2023年夏にとしまえん跡地にハリーポッターのテーマパークが開園予定です。楽しみ。

かつてソニーはどうやって社員をリストラしたか

切り捨てSONYを読んだメモ

前口上

アメリカのテック企業ではレイオフがブームですね。layoffs.fyiに情報がまとまっていますが、とりわけTwitterは社員の半数以上が解雇・自主退職により辞めたと報道されています。

よく日本人の給料が上がらないのはアメリカ比で解雇規制が強すぎるからという意見を言う人もいるのですが、OECDの調査によるとむしろ中央値から外れているのはアメリカで、世界で見るとむしろアメリカの規制がなさすぎるというデータがあります。

https://www.dir.co.jp/report/research/economics/europe/20140318_008337.pdf

よって日系企業で同じようなことが急に起きるかというとそういうわけではないのですが、ソニーでのリストラの事例をまとめた本「切り捨てSONY」を見つけたので後学のために読んでみます。

本の概要

目次は以下です。

• 1章　ソニーの変貌　2006-2007
• ２章　ターニング・ポイント　1946-2006
• ３章　技術者たちの矜持　2008-2009
• ４章　リストラ志願　2012-2013
• ５章　元には戻れない・戻らない　2012
• ６章　ヒト切りＳＯＮＹ　2012-2014
• ７章　終わらない苦しみ　1954-2014
• 終章　奮闘する「辞めソニー」たち

本自体は2015年の本です。

1章がソニーの社内制度や周辺環境の紹介、2、3、5章が社歴や過去のリストラの紹介、4、7章がリストラ部屋、6章がリストラ担当の話。

ソニーの退職制度

事業構造の変化に伴い、ソニー内部でいくつか施策を行なったことが書かれています。

• イントラ内のセカンドキャリア支援サイト

ソニー卒業生の事例紹介

• Sony University

幹部候補生養成所

• キャリアデザイン室

通称リストラ部屋。退職願を出して会社費用で転職斡旋会社のサポートを得るか、決めあぐねて研修などを受けるか。

施策としては凡庸なことを粛々とやっている印象です。部署ごとに低パフォーマーを一つの部署に集約させて、教育して社内の別部署の募集を受けさせるか、早期退職金を与えて転職を支援するか。

統計的比較

ソニーグループの社員数は2022年3月末で108,900人。時期によるのですが、3,000〜1,0000人/年程度が削減数のようです。20年で8万人といったところでしょうか。結構多いですね。

アメリカ企業比で人を切れないのが日本企業の難しさと思ったのですが結構リストラしていますね。。。ソニーは平均年収も高めなので日系企業の中では外資系に近いというか、より周辺環境に変化があったときに社内調整で融通がきく部分が少ないのかもしれません。

一方でキャリアデザイン室に入った人は毎年100~300人程度のようです。思ったより少ないですね。普通の人は諦めて、削減人数の5%程度の人のみが決めあぐねるといった感じでしょうか。

ソニーは割合複数事業あり、メーカーとしてはポートフォリオ経営に近い業態ではあると思うのですが、それでもリストラの判断になるのを見るとメーカービジネスは難しいですね。

最近の解雇の事例、判例

関連で解雇に関する事例や判例についても調べてみました。

日本の解雇規制は強く、例えば契約書上で雇用期間を定めた社員でも無効になることがあります。2019年にDMMがその件でもめていたりしました。契約社員の雇い止めが違法になるケースも多いです。

一方で、最近の外資系のジョブ型雇用だと解雇もある程度正当化される判例もあるようです。条件は厳しめですが。

• クレディ・スイス証券 東京地裁

ポスト消滅による解雇を不服として訴えたが解雇を有効と判断。部署廃止後に5つの社内公募を提示、解雇回避努力を尽くしたと評価。

• ユナイテッド航空　最高裁 解雇有効

高裁時の言い分だと、契約で職種を限定している中で、年収水準を維持した配転の提示や早期退職に伴う退職金の加算など解雇の不利益を緩和する可能な限りの回避措置を講じたと評価

所感

日本における解雇の嫌なところは就職が新卒一括採用に特化して、解雇されると就職先が限定される点です。今までの経験を元に他社でも同待遇で採用されるなら嫌解雇性は減るわけですし。

最近知ったのですが、アメリカのワシントン州では2023/01から15人以上の会社では募集する際の給与レンジの公開が義務化されMicrosoftも含まれます。

思えば日本の求人票は経験に応じるとして、給与レンジ非公開、または新卒から引退まで含んだざっくりレンジのみしかないことが多いようには思います。給料が上がらない、解雇された際の受け皿が少ないのは、他社に移った際の透明性が低いからなのではないか。

解雇規制を緩めるのは割合骨の折れる改正なのと、日本は世界比で極端に悪すぎるわけではありません。むしろワシントン州と同様に、日本も求人における評価制度と給与レンジの公開義務化を進めた方がより社会として健全な気はしました。

AssessOpsを提唱してみる

組織構造は評価の運用も考慮して

前口上

DevOpsという用語があります。ソフトウェア開発を開発担当(Development)、運用担当(Operations)と完全に分けるような構成をとるより、開発と運用はより協調して、時には兼任した方が変化に素早く対応できるという考え方です。

ソフトウェア開発(直訳だとDevだがここでは日々の業務でOps)と人事評価'(Assessment)もしばしば独立したものとされることが多いですが、極力一緒になった方がいいのではということでAssessOpsを提唱してみます。

ジョブ型雇用には評価制度の設計・運用がより必要

伝統的に日本はメンバーシップ型の雇用と言われています。終身雇用で一つの会社に属し、数年ごとにジョブローテーションでやることが変わります。

一方で最近はジョブ型に近い雇用も増えています。専門性は気軽にスイッチできるものではないとして、専門性に応じたグレードで待遇が変わります。

背景には統計的に日本の生産性が低いことがわかってきたからというのもあると思います。生産性は必ずしも効率の低さだけが原因でなく、市場規模の大きい海外で売り上げをだせていなかったり、地政学的要因もあるのですが、とはいえメンバーシップ型は会社視点で見るとコスパが必ずしもいいわけではないということが分かってきたわけです。

ジョブ型はメンバーシップ型より評価制度の設計・運用にノウハウが必要になります。勤続何年だからこの評価といったような機械的割り当てができず、専門性を評価できる能力が評価者により求められるからです。

評価者が日々の仕事ぶりをちゃんと見れているか

日本の低賃金もしばしば話題になりますが、高賃金をだすためには労働者間格差をつけ、メリハリのある評価をすることも重要です。給料の上がらない会社はそもそも評価制度がない、弱いことも多い。

評価制度は作ることも大事なのですがそれ以上に運用に乗せるのも重要です。

日本は他国比で派遣が多く、ソフトウェア開発でも事業会社が内製開発チームを持っていることは少なく、開発会社が別枠になっていることが多いのがユニークな部分です。コロナのあおりを受けた会社でも解雇はせず他社へ出向となったケースもありますね。

解雇規制の強さとビジネスの変化への対応を最適化した結果ではあるのですが、評価制度自体の良しあし以前に評価者が日々の仕事ぶりをちゃんと見れているかというと見れていないことが多いのが日本社会ではないかと。

出向している会社で人事評価をしないといけないのに、出向元の会社では日々の働きぶりをそれほど見れていないというのは普通にありそうですよね。

チーム構成を決めるときはアセスもセットで

AccelerateやTeam Topologiesの日本語訳がでたせいかFour Keysだったり、開発生産性を最適化するノウハウ自体は少しコモディティ化した印象があります。

一方で評価制度は？と言うとそれほどノウハウはたまっていない印象を受けます。

Zennの記事からの引用ですが、例えば以下のような組織構造があったとします。一番左のチームの評価者はだれでしょうか？

組織のEMをベースに複数人が文殊の知恵形式で決めていれば及第点、追加で技術力評価会なんてあるとなおよいかもしれないですね。

一方で、なぜか隣のチームのマネージャーが評価することになっていたり、たいして話したことがないVPoE(大企業なら部長など)が評価する組織も往々にしてある気もします。業務と評価がねじれているというか

評価結果も大事だがちゃんと見られている感はもっと大事

例えば年収が一定水準に達すると幸福度はさほどかわらないという話もあります。孤独で幸福度が下がるという話もありますね。

年収のトップラインをあげるためには評価制度の運用、正しく評価することが大事なわけですが、そもそも評価者がいない、いうほど日々の働きぶりを見れていない組織も案外多い印象があります。

人事評価は評価の結果がいいことも大事ですが、それ以上に日々の働きぶりを元に評価されている感が大事なのではないかと

Gitのログなどから開発生産性もある程度だせるようになると、人間はそれを最適化しようとしがちです。ただ、それは結構短期なものの見方をしている可能性もあって、組織構造を考える際は評価の運用もセットで考慮するAssessOpsが重要なのではないかと

CTO/VPoEが人事によりすぎると黄色信号化かも

そういう意味で技術組織においてCTO/VPoEが人事によりすぎると黄色信号な可能性はあります。Your CTO Should Actually Be Technicalという記事もありました。

blog.southparkcommons.com

人事評価は行動特性だったり技術だけが評価軸ではないのですが、技術は日々移り変わっていきますし、現場から離れた時間が増えるにつれて、とりわけVPoEの技術力が下がると評価を外す率が増えるようにも思います。

結局専門性を評価できるのはその専門がある人で評価者の技術力が一番である必要はないですが、人事専任化する抵抗感はもっとあった方がいい。

役員なら業務がなくても自力で育つのは当然ではあるのですが、例えば大きめのレビュー会には参加したり、組織構造上評価者の技術力が下がりすぎないよう何らかの工夫があると系として完成しているようには思います。

NTTの人事制度の変遷について

老舗IT企業の内部事情

前口上

33万人を抱えるNTTグループが人事制度の改革に取り組んでいます。富士通で13万人、トヨタで36万人なので規模の大きさがわかります。

YouTubeに執行役員の方自ら内容を解説した動画があったので、メモがてら要旨をまとめておきます。

グループ概要

• 総合ICT事業(docomo, NTT Communications、NTTコムウェア): 5万人
• 地域通信事業(NTT東日本、NTT西日本): 7万人
• グローバル・ソリューション事業(NTTデータ、NTT): 19万人
• 不動産・エネルギー等: 3万人

通信のイメージが強かったのですがNTTデータグループで15万人いるのでそこのウェイトが大きいですね。ただ、稼ぎ頭は総合ICT事業みたいです。

NTTグループのうち、14万人が海外でここが直近の10年程度で伸びた部分。

管理職へのジョブ型人事制度の導入

VUCAの時代なのでジョブ型へ。ただし雇用は守っているので日本型のジョブ型で管理職12,000人に適用。

主にジョブグレード制の導入と会社業績KPIのボーナスへの連動を高めた。ジョブグレードは6段階。

専門性を高める制度への見直し(一般社員)

一般社員はジョブ型でない。スペシャリストグレード2つと普通のグレード6つ

業績評価、行動評価、専門性判定で昇給・昇格を決める。普通のグレードの後にマネージャーになるかスペシャリスト(グレード)になるか決めるイメージ。

採用の6~7割が新卒採用

多様性の確保

サステナビリティ憲章を作成。2025年度までに女性役員比率25~30%が目標。スーパーフレックスの導入で女性の時短勤務が減った。

男性の育休を促進するためパターン化している。

リモートワーク

リモートワークも推進しており、オフィスワーカーは7割程度実施。リモートハンドブックではカメラONを推奨。

居住地の制限なしのリモートスタンダード制度も2022年から導入(対象3万人)。単身赴任者が減。

所感

令和まで年功序列の影響が濃い制度をキープしていたのは遅すぎる気もしますね。マネージャーになる以外のキャリアパスを設けるというのもより規模の小さい企業なら既に導入ずみの会社も多い印象を受けました。

他の部分ではいいところもあったので人事制度を決める立場になったら真似してみたいです。

リモートワーク時代こそOJTでペアプロをしよう

新人含めてリモートワーク体制にする方法

前口上

内定式のシーズンですね。本記事執筆時点で日本はまた感染者数が谷に入り、ちょうど入国規制が緩和されました。とは言え、リモートワークを部分的にしろ全部にしろ実施しているIT企業がまだ多いです。おそらく元に戻ることはないと思います。

実際、一つの統計では年収800万円以上のITエンジニアの8割がフルリモート勤務となっており、シニアエンジニアになるほどフルリモートワークを選択しています。

一方で新人はリモートワークはつらいという声もちらほら聞きます。メンターはリモート勤務希望なのに、新人は出社の方がいいという声がある、ねじれの構造があるわけです。

今回ねじれ解消の一つの方法論としてペアプロを提案してみます。

ペアプログラミング

最初に簡単にペアプログラミングについて説明します。

ペアプロ、ペアプログラミングは一つのプログラムを二人で同時に共同開発する手法です。出社時なら同じディスプレイを見ながら横に並んで、リモートワークなら画面をZoomなどで共有しながらコードを書きます。

二人の場合ペアプロと呼ばれますが、三人以上でやる場合はモブプロ、モブプログラミングと呼ばれます。

通常プログラミングは一人で行うことが多いと思います。プログラミングを覚えた際に一人だった、自分のペースでコードを書きたい、せっかくプログラマーを雇ったのに二人で一つのコードを書いていたらコスパが悪いように見えるなど意見は様々です。

個人的にはコンパイル待ちがあるような言語の方が不利に感じています。アイドルタイムが2倍になってしまうのでスクリプト言語の方が向いているのではないか。

ユタ大学の研究

ペアプロについての論文もあって、例えばユタ大学のThe Costs and Benefits of Pair Programmingが有名です。

論文では

• 経済性
• 満足度
• 設計品質
• 継続的レビュー
• 問題解決
• 学習
• チームビルディングとコミュニケーション
• メンバーとプロジェクトマネジメント

の観点について論じています。

経済性で言えば、ペアプログラミングにかかる時間は2倍にはならず高々15%増で、バグを15%減らすことが語られています。コスパが思ったほど悪くないですよね。

他にもコードが綺麗になったりするのですが、今回大事なのは学習の部分ですね。7~8割の人がペアプロの方が理解度が上がったと答えています。

マネジメントのレベル感

以上を踏まえつつ、マネジメントのレベル感を整理するとこんな感じでしょうか。

• Lv. 0: メンターなし
• Lv. 1: メンターがいつでも聞いていいよと言っている
• Lv. 2: 定期的に聞ける場がある
• Lv. 3: 定期的にペアプログラミングを行なっている。

Lv. 0はメンターがない状態です。ベンチャーで各担当ひとりかもしれません。会社に余力がないので自力で育ってと言いたいところですが、例えばフルスタックなCTOがレビューだけやったりで一定の受け皿を作ることができます。

Lv. 1はメンター指名性にした状態、Lv. 2はプラスで定例も設けたもの。単に聞いていいよと言っているのと定期的に聞ける場があるのとではマネジメントのレベルが違います。

ここまではよくある話。今回提案したいのはLv. 3: 定期的にペアプログラミングを行なうです。

前述の通り、ペアプロはベテランエンジニアでも効果があるのですが、よりジュニアなケースの方がいきる感覚があります。質問をするには一定の知識や理解が必要なんですよね。いつでも聞いていいに対して聞けるのは2年目以降かなと。

オフィスで新人が気軽にメンターに声をかけたり、メンターが新人のはまり具合を横目で見るのをリモートワークで再現するならペアプロが近い。

むしろOJTで出社前提でうまくいっていた部分はマネジメントが稚拙な部分を善意でカバーしているともとれて、善意がなくても回るような仕組みを作るのがマネージャーの仕事とすれば、ペアプロの仕組み化がよいのではないかと。

ドキュメントがない企業ほどリモート勤務が苦手という話もありますが、リモートで成立する手法は多くの場合、仮に出社時でも生産性を改善するやり方です。

所感

他にも例えば傾向としてジュニアの方が独身で、シニアエンジニアの方が結婚率上がるので、出社には話す相手がいる効果もあったかもしれないですね。

それには雑談時間を設けるなども大事になってくるのですが、長くなってきたのでまた次回

IT企業の評価制度を設計してみる

評価制度設計の一例

前口上

仕事の報酬を考えた時、個人としてはもちろん5000兆円欲しい訳ですが、経営者視点で見ると投資効率へのプレッシャーを投資家から受けたり、事業が上手くいかなくなった際の倒産確率を低めるためにも、全ての従業員を5000兆円で雇うわけにはいきません。

一方で少子化やIT化の流れの中で、IT系の人材は需給上労働者側有利なのも事実で、伝統的日本企業モデルで新人から定年退職までにゆっくりと昇給するような賃金カーブは乖離が生じがちです。

海外や他社の事例を踏まえつつ、いいところを本記事では狙ってみます。

自分の得意な職種だけ厳しくしない

まず評価制度を作る上で一番しがちなミスは自分の得意な職種だけ厳しくしてしまうだと思います。

エンジニア出身の人ならエンジニアの評価はわかるけれど、デザイナーやPMとなるとさっぱりだったり、営業出身の人なら営業目標は立てられるけれど人事や広報だとさっぱりだったりするのはよくある話だと思います。

そういった際にしばしば創業者出身の職種だけ評価制度が厳しくなりがちな傾向はある気がして全体のバランスは大事です。

ITスキル標準(V3 2011)では人材のレベルを7つに分け、以下のように定義しています。まずはこれをベンチマークにして各専門性のレベルがどこにいるかを評価するようにすれば、評価が苦手な職種でも実態とのずれを減らせると思います。各社自由に評価グレードを設定しても良いのですが、せっかくIPAが時間をかけて検討したものですし、独自要件を追加するにしてもリファレンスがあるとよいかと。

人事評価で一番有名な手法は期の頭に目標を立てて期末に評価する目標管理制度だと思うのですが、とりわけ0=>1に近いスタートアップだと1年後には大目標が変わっていたということもままありあまり向いていないと感じることもあります。

成熟期のサービスでも他業界比で変化が速いと言われるのがIT業界ではあるのでとりわけWeb系の企業だと目標管理をするにしても、ベースの部分にミッショングレード制に近い指標を持つとブレが減らせるように思います。

海外企業の評価制度を職種のレファレンスにとってみる

評価指標自体の大枠が決まったので、次は各職種ごとの待遇を決めていきましょう。levels.fyiは海外の企業の評価制度がまとまったサイトで一つの参考になります。

エンジニアだけでなく営業などのBiz系の職種も載っています。試しにGoogleを見てみましょう。

開発系で一番人数が多そうなEM、エンジニア、(テクニカルでない)PM、デザイナーでみると以下でした。各社違いはあるのですが、概ねEM・エンジニアが一番強いですね。(2022/09/06追記: 集計ミスを修正)

同じL5のグレードでBiz系のメジャーな職種も並べるとこうです。

職種の相対待遇はGAFAでも結構会社ごとに違い、色が出ます。Googleは意外と営業が強くデザイナーが弱い会社ですね。思い返すとGoogleのサービスは控えめにいってすごくシンプルなデザインが多かったように思います。

ざっくりBizDevを1として

• EM: 1.44
• エンジニア: 1.44
• PM: 1.32
• デザイナー: 1.24
• データサイエンティスト: 1.24
• 営業: 1.16
• 人事: 1.08

といった感じでしょうか。あくまでGoogleではなので自社と近い業態をベンチマークにとった方がいいかもしれないです。

また、日本ではまだ職種間ギャップがアメリカより少ない感覚があります。BizDev比でエンジニアの待遇が足りていないのならそこは人材不足というより待遇不足ですかね。

日本のIT産業給与実態調査

日本のデータも見てみましょう。経済産業省のIT関連産業の給与等に関する実態調査結果だと以下のようになっています。

報告の中でレベル1からレベル3までの給与上昇が緩やかと報告されています。

データが少なくてレベル6と7が一緒になっていますが企業サイズ的に妥当かもしれないですね。ラーメン屋より多いという日本のIT企業だと世界的な専門性を持っていても持て余してしまうというか。研究部署やコミッターを雇っている企業はありますが。

GoogleやFacebookのエンジニアの数が3万人程度。一般的な日本のメガベンチャーは全体で3,000人程度の企業が多いようには思います。エンジニア比率半分なら1,500人ですね。

5.6^6=30,840で5.6^4=983です。Googleの6段階を日本の6段階と比較すると規模が違いすぎて、ざっくりGoogleのグレード4つ分がITスキル標準の6段階に当てはまるとすると合っている気がします。

実際GoogleのエンジニアはL3=>L6で2.6倍昇給しているのですが、実態調査だとレベル1からレベル6で2.6倍昇級しています。

Future Works

前職給与ベースで採用しまくってしまった会社の是正アイディアなどもあるのですが、力尽きたのでまた時間見つけて記事を書きたいと思います。