2023年メタ記事ピックアップ
テック系の中でも非技術的な記事（組織、プロセス、採用など）の中から、自分的に刺さったフレーズがある記事とその感想をつらつらと書き記しておきます。
「“良くないコード”に腹を立てても意味はない」新しい事業・新しいプロダクト・新しいコードに触れる時に意識したいこと
事業をやっていると、常にあらゆる状況でベストなコードは書けない
すごく上手な人がベストなコードをその時々で書いていても、事業の状況は絶対に変わるんですよね。状況が変わった時に過去ベストだったものが現在のベストじゃなくなることはメチャクチャある
良くないコードに腹を立てても意味がない
いやほんとにね...めちゃくちゃわかる。
既存コードとの整合性やスケジュールの関係上、政治的判断などなどベストなコードを書けないシチュエーションはたくさんある。意味不明なコードを見た時に、昔は「なんだこのクソコードは!!」と憤ることもあったけど、最近は「このコード書いた時よっぽど忙しかったんだろうなあ...」と思うようにしている。そのコードのおかげで今がある。尊い。
「判断をする」とポンッと言ったんですが、意思決定をして実行するのはソフトウェアエンジニアしかできない
毎日少しずつ改善をしていると、コードは必ず良くなる
しゃがんで内部品質を改善したほうがこのループが早く回る。事業としても中長期的に良くなるという判断ができるのであれば、その判断をして関係者の理解を取り付けて実際に内部品質の改善をするのがいい
いやほんとにね...。
スクラムとかやってるとまとまったリファクタとかの品質改善タスクの優先度が上がりづらかったりするから、日々のタスクの中でちょっとずつでも改善を回していくのが大切。（もちろん、品質改善タスクの優先度が下がらない意識作りも大切ではある）
エンジニア採用・組織づくりのトレンド予測2023〜開発生産性がエンジニア採用の鍵に。DX内製化や外国人採用なども〜
転職するエンジニアにとっても、開発者体験・環境づくりがどうなっているかは非常に気になる基準となってきており、面接時に「Four Keys」を測っているかが問われる機会も増えてきました
そうなのか、自分は面接官やってて今のところ面接時の質問で Four Keys について質問されたことはないかなあ...。
でも大事だよね、 Four Keys 測るの。
将来EMになりたい人の数がコロナ渦中以降、徐々に減ってきています。2021年7月の調査では19%の方がEM志望だったに対して、約1年後に13%台まで減少しています
リモートは働き手にとっては良い選択肢である一方で、マネージャーには一定の負担を強いる傾向になっているかもしれません
なるほど、まあ確かにフルリモート下でのマネージング業務はより難易度が上がってそう。なりたい人が減ってるってことは、はたから見ててなんか大変そうだなって感じる人が増えたということだろうか。
働いてみたい企業の多様化
業界トップレベルの環境、人材、最先端技術がある
会社としてエンジニア目線
海外エンジニアと働ける
勢いがあるスタートアップ、アウトプットが盛んで技術力が高い
給与、待遇の良さ
うちにはどの要素があるだろうか
この中でうちがカバーできているのはいくつあるだろうか。
改めてうちの企業のストロングポイントみたいなのを整理して言語化しないとどんどん応募者に刺さらなくなっていくのかも。
受託開発とか自社開発とか言うけれど、会社のカルチャー違いや個人差の方が大きい。
会社のカルチャー違いや個人差の方が大きい
わかる。
自社サービスの方が企画段階から関われるとか納期のコントロールができる、みたいなのは傾向としてはそうなのかもしれないけど、全部が全部そうではないし、その組織の形態にもかなり依存するなあというのはあるので、選社軸としては広すぎるよなあとは思う。
若い方だと転職の理由で、「直近は技術力をもっと伸ばして...」というモチベーションの人も多いが、それなら受託会社の方が開発フェーズに携わる時間が比較的多い可能性があり、技術スキル伸ばしやすいような気もするけどなあ。
あと「企画やりたい」人多すぎ問題があって、それを聞くたびに企画ってなんだろうって思ったりなどする。企画の指すイメージの幅がありすぎるので、あなたの言う企画とはなんですか？と忘れずに確認しないとミスマッチが起きる。事業開発からやりたいのか、仕様は誰かが決めてくれてその提示された仕様に対してただ文句疑問点を挙げて議論したいだけなのか、でかなり変わる、と思う。
テックリードはキャリアの分岐点。取材でわかった6系統の役割と市場価値のリアル
テックリードの役割を、開発者のリーダー、立ち上げ役、プロダクトマネージャー、ピープルマネージャー、プロジェクトマネージャー、ミニCTOと分類
テックリードと言ってもそれぞれタイプがある。脳死して1チームに1人置いてとかではなく、その人の嗜好性にあったタスクが発生するように流動的にアサインしないと、なんかチームを引っ張る人、で終わってしまいそう。
エンジニア同士であってもスキルの評価は難しいです。社内の評価基準はありますが、AさんとBさんを比較したり、納得感のある評価をフィードバックすることに苦労しました。
メンバーそれぞれが目指すことが違うため、導く難しさを感じます。
評価基準はあってもガチガチの定量的な表現になってることは少なくて、エンジニア同士でも比較が難しいのはわかる。伸ばしたいスキルのベクトルも人によって違うし。
立ち上げ時期のテックリードは、一人に負荷が集中するという懸念
役割を集中させたままテックリードを採用しようとしてもうまくいきません。6系統でいう「ミニCTO」のような求人票は、開発者のリーダーを目指したい方からも、PdM/PjMからも、EMからも避けられる求人票となりやすく、採用のボトルネックとなるでしょう。
1個小隊を引っ張れる人、みたいな曖昧な感じではなく、それぞれのベクトルをちゃんと定義する。チームによってリードに求められる内容って実は結構違うんじゃないか、というのを社内のチームを眺めながら考えてみようと思った。
テックリードは職位か、職種か？
書籍「エンジニアのためのマネジメントキャリアパス」では、テックリードは職位ではなく職種だと定義されています。しかし、日本の実態としては、職位が連動しているケースがかなりありました。これは、「この役割を担う人をテックリードと呼ぶ」という考え方ではなく「上位の人をテックリードと呼ぶ。何をしてもらうかはその時による」という考え方の企業が多いためです。こうして組織が期待する役割が変化し続けた結果、職種としてのテックリードよりも広い、ピープルマネジメントのような役割を担うテックリードが現れるのでしょう。
そもそもテックリードってなんなんだろう話。
「意識を変えると行動が変わる」は、組織変革では順序が逆 会社に活力を取り戻す「チェンジマネジメント」のやり方
目的や意義に共感できない社員は、何か新しい仕組みが入っても、残念ながら行動変える理由がありません。
営業さんとかマーケターにも、「モノではなくてコトだ」と掛け声が掛かっているとしましょう。
ところがその営業さん、あるいはマーケターの年度末の成績、業績評価は、相変わらず売った箱の大きさ。売った箱の売上で評価される。これ、典型的な掛け声倒れのパターンですね。
マインドと行動を変えるにはインセンティブ設計も同時に変える必要がある。
みなさんのなかにも、こう思っている方もいらっしゃるんじゃないでしょうか。1つ目は、組織を変えるには、「まず社員の意識変革から」だ。つまり社員の意識をまず変えなければ、変化は起きない。これを好んで言う経営者の方って多い
チェンジマネジメントのさまざまな研究から、この順番ではないという結論が出ています
「同じこと」は、少なくとも6回いう必要がある
全社員を一気に変えるアプローチは、ほぼうまくいかない
「意識を変えると行動が変わる」は、実は逆
内発的動機付けか、外発的動機付けか、みたいな話にも通ずるところがあるけど、組織としての人間の集団に置いて性善説でもった内発的動機付けに頼るのはかなり無理がある、というのは色んなところで言われている気がする。全員が全員聡明かつ、行動のインセンティブが一致しているというのは幻想だと思って。まずは外からの力で行動を変えさせて、行動するうちにマインドが醸成されていく、という明確なアクションを取らないと組織の方向性を変えるのは難しいように思える。
行動指針とかビジョンとか策定するのはいいんだけど、それをしっかり布教していくというのが大事。それが重要なことであればあるほど、ある種宗教的な領域まで昇華させて浸透させていかないと意味がないと思う。その考えの強制に反発するような人はうちの組織合わないね、去ってもらって結構です、というレベルでやっちゃってもいいんじゃないだろうか。
新卒で入った会社はこの辺本当に熱量持ってやっていて、ボード陣が率先して布教し、何かしらのレビューの際は必ずと言っていいほど行動指針に沿ったフィードバックを行なっていたし、評価制度にも行動指針をどれだけ意識してアクションを起こしたかが評価項目として組み込まれていた。その結果どの社員にも行動指針が DNA のように刻まれていた気がする。
「変革のツボ」がまず1個目。次に、問題意識の高い人。これを「ダイナモ」、日本語で言うと「発電機人材」みたいな意味合いなんですけれども、私たちは「ダイナモ」と呼んでいます。彼らを集めて、権限・自由を与える
その組織のフィロソフィーやカルチャーを体現するエヴァンジェリスト、布教者、宣教師のような人はどの組織にもいる。そういう人たちの布教活動あるいはその行動を他の社員が目にして行動を変えるような構造を作れると良いと思う。
今の会社では年末の全社イベントで、行動指針賞というのが表彰される機会があって、そういうのいいなあと思うのであった。
チェンジマネジメントだとこの資料もよかった。
一体いつから――――カケハシの開発組織がフラットだと錯覚していた?
「組織の規模が拡大してもフラットな組織を維持できるんですか」
はい出た。特に最近非常によく聞かれるようになった質問
「フラットな組織」が意味するのが組織のグルーピングやそのネスト、グループごとのリーダーシップが存在していないことを意味するならそもそも既にカケハシはもうずいぶん前からそういう状況ではない。「フラット」的な何かはそういう形式や構造の話ではなく、合意形成の際の考え方やリーダーシップを担うもののメンタリティに関するスタンスの問題である。
「フラット的な何か」によって何が得たいのか?
自分も面接の際になんとなく、「うちの会社は役職が少なく比較的フラットな組織構造です」的なニュアンスのことを話すことがあるんだけど、かなり適当なこと言ってるなというのに気付かされた（文脈的には、意思決定のフローがボトムアップで無駄な承認フロートかが少ないよ、という流れで話すことが多いのだけど）。
そもそも、フラットとはどういうことか、フラットであることで誰にとって何が嬉しいか、をちゃんと考えたことがなかった。実際、組織のフラットさというのはどうやって測ったらいいんだろう。
その人がフラットだと思うならそれはフラットである、みたいな哲学的なものなのかな。いや、フラットかどうかは状態であって、それによって何が起こっているかにもっとちゃんと目を向けたほうがいいのか。
「うちの会社は〇〇だ」と語る人は、実は組織の話はしていない 就活生に伝授する、企業の「口コミ」の見極め方
結局1,000人社員がいたら、1,000人とも見えている現実が違うんですよ。みんな、自分が見えている現実をすべてだと思って話すんですね。人事の世界でよく言うのが、マネジメントの世界でよく言うんですけど、「うちの会社はこう」って言っている人がよくいます。みんな「うちの会社はこうなんだ」って悪い意味でもいい意味でも言っている。これは「うちの会社」って何かというと、その人が関わっているその会社の人のことなんですよ。
会社って、僕はよく「組織は幻想だ」と思っているんですけど、組織ってみなさんの頭の中にあるものでしかないです。ちょっと抽象的な話ですね。組織ってその人が見えている世界の範囲でしか認識できないんです。組織の実態は。
本当にそうで、今自分がいる会社も200人ほどの規模だけど、それでも全体をも渡せている感覚は全くないので、就活生と話すときは
- 少なくとも自分が感じてる範囲内では〜
- 部署やマネージャーによっても全然違ったりするけど〜
- 会社が掲げている方針としては〜
- そういう傾向はあるかもしれない
- 最終的には入ってみないとわからないのでギャンブル
みたいな話を必ずするように 気をつけている。過度な断定で変にミスマッチを誘発するのも嫌だし。
経営者の考えに自分が賛同できるか否かというのは、経営者の人の話を聞けば、経営メッセージとかこの会社のビジョンとか、そういうところから経営者の考え方というのが出てくるので、そこで合致していなかったら、たぶん会社に入ってどの部署に配属されてどんな上司がついても、合わないと思います。
この辺は企業調査する時には調べておきたい。
経営陣がどういうことを大事にしていて、それを浸透させる仕組みがあるか、とか。
遊びの部分なくずっと技術的負債解消は、モチベ管理が難しい CTO・VPoEが語る「技術選定の自由度とガバナンス」
負債解消チームはかなり限定的にやっていて、全体的に負債を解消しましょうという感じではないんですよね。最初にお話ししたとおり、従業員の履歴管理機能がけっこうやばいです。なので「そこを集中して直そう」と言っていて、そこを直すことでどれぐらいの事業インパクトがあるのかみたいな話も、PMを立ててやっているので、ある種の機能開発に近いモチベーションでやれる
返済業務に追われまくるとプロダクトエンジニアとしてはキツいよなあとは思うので、アドホックに作って事業インパクトを意識しながら解消していくのはモチベーション的にも良さそう。
ここを解消すると、変更容易性によってユーザーにメリットがあるよねとか、本当にわりと全社的に注目を集めている負債なので、そんなにモチベーション管理に困ってはいないはずです。逆に本当に「何でもやります！」みたいな感じだと、モチベーション管理にすごく苦労するだろうなとは思います。
それね。ミッションがぼやけるほどモチベーションは維持しづらい。
スタックがばらけると「学んでいけばいいじゃん」みたいな話がありますが、例えば、やっていた人が辞めちゃって保守しなきゃいけない場合、やったことがない人がやるとなると大変かなと思います
仮に新しい技術をやるのであれば、CI/CDをきちんと組んでもらうのは絶対に言っています
まあですよね...（実際に出くわしてどうにもならなかった苦い記憶）。
自分が新しいスタックを取り入れる時は（当たり前ではあるかもしれないけど）テスト細かく書いて色々自動化してドキュメントも残してというのは気をつけている。
新しい技術を取り入れるハードルを高くしすぎて技術スタックが固定されてしまうと、それはそれで組織として探索的知見が得られずバッドな状況、環境になってしまうので攻守の塩梅が難しいところではあるなあとも思う。
マネーフォワード CTO が考えていること（2023 年 6 月）
私たちは、テックジャイアントを目指しています。
どう技術的な挑戦をつくるか？
事業が拡大するにつれて、大量のデータや高いトラフィックに対応するため、そして複数のサービスを連携させるために、より大規模な分散システムを構築する必要が出てきました。
事業がスケールするとシステムもスケールを迫られ、そうすると解決しないといけない技術的課題の質や難易度も変わるので、どうやってその挑戦を作っていくのか、という視点大事。技術部門のトップがしっかりこういうことを発信しているのも組織としては良いなと思った。
評価制度上はグレードが上がるほど技術的な挑戦やスケールの大きいアウトプットを求めらがちだけど、事業がスケールして保守運用するものが増えると単純作業の絶対量も増えるわけで、意識しないとそういう成果を出すチャンスの数が減っていってしまったりする。
なぜ Four Keys を改善するのか？
小さいリリースの回数が多いだけかも
単に分割してマージしただけかも
という問いかけができるのが良い。
「Lean と DevOps の科学」の功罪で、4keys が高いならハイパフォーマンスだというわかりやすい図式ができたけど、数字だけに気を取られるとやっぱ上手くいかないねという話。
「Lean と DevOps の科学」でも因果の導出はどちらかというと逆で、ハイパフォーマーなチームは結果としてそういう部分に気を遣え、その結果数値が高くなる的なニュアンスのことが書いてあったようななかったような。
Freeeks＆Ubieの代表が「エンジニア向けの制度・待遇」にこだわる理由。環境を味方につけて成長できる技術者の特徴とは？
エンジニアが在籍するプロダクト開発組織では、職位を設けず、ロール（役割）を明確化するホラクラシー組織にしています。
マネジメント業務よりも開発に専念したい人や、技術について上から命令されるのを嫌う人にとっては、評価をするのもされるのも時間がかかって「煩わしいもの」と感じてしまいかねません。
かつ、プロダクト開発は不確実性が高く、本人の頑張りが成果には直結しないケースが多いので、フェアに評価をするのが難しいですよね。なので、給与テーブルを設けず、評価も行わない仕組みにしています。
前職の年収や市場価値を見て、入社時に決めます。その後は会社の業績と連動して昇給する
評価を行わないの、かなり振り切った感じがしててすごい。
評価期になると評価制度の表現に沿うような振り返りとかに無駄に時間がかかって本当にこれ意味があるのかと思うことはある。特にマネージャー陣やボードの時間をこんなに使ってまでやる意味があることなんだろうか、と。
それにしても、これ人数と売上の規模がどの程度まで上手く回るのかな。
確かネトフリもそんな感じで言い値で報酬が決まる的なことが、以下の本に書いてあった気がする。
常に右肩上がりで上昇する前提の強い気持ちなら成立しそうだけど中々クレイジーな気もする。
(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎
この記事は全体的に読み応えがあって面白かった。
苦戦しているチームは、方法論とはあまり関係がないことが多い。 うまくいかなかった理由として、ビジョンの欠如、優秀なエンジニアの離職、透明性の欠如、ツールの不備などが挙げられている。このようなチームにとって方法論を変えても問題は解決しない
“標準” の方法論はあるか？
→ いいえ。チームが選択できる
方法論は関係なくて、マインドだったり環境不備だったりの方が要因としては大きい。なんか上手くいってないような気がするからスクラム導入してみようとか、モブプロやってみようとか、そういうのやりがちだけどそうじゃないんだという話。
ビッグテックとその他の企業とのもうひとつの不思議な違いは、プロダクトマネージャーの役割であり、チームに専任のプロジェクトマネージャーやプロダクトオーナーがいないことです。
多くの場合、大企業ではプロダクトマネージャーはプロジェクトマネジメントを担当しません。チームが遂行に責任を持ち、チームのリーダー (通常はエンジニアリングマネージャー) がこれを実現する責任を負います。
Facebook の PM として1年以上働いているが、チケットやタスクを作成したことはない。スプリントもやりません。
ここの PM はビジョン、戦略、パートナーシップにフォーカスしている。プロジェクトマネジメントやタスクはあまりやらない。
エンジニアはプロジェクトマネジメントのほとんどの責任を担い、自分たちでタスクを作成する。
素晴らしいことだ。
面白い。会社に PdM がいないわけではないけど開発チーム内には不要というか、役割としているのがおかしいという。アメリカの方が PdM というものに求める役割というか、出してほしいアウトカムへの定義がしっかりしている気がする。単なる役割分担の話で終わらせられるかどうか。
スクラムが日々のリリースの邪魔になったのでした。 スクラムの全体的な考え方は、スプリントを中心に展開され、スプリントの最初にタスクにコミットし、スプリント中にそれらに取り組み、最後にやったことをデモするというものです。
このプロセスは不自然で、動きの速いウェブチームからは押し付けられたかのように感じられました。
プロダクトオーナーへのデモ、作業の承認、そしてリリースといったスクラムのセレモニーは、いくつかのことを前提としています。
プロダクトオーナーは、作業が仕様通りに行われたことを確実に検証できる人であること
プロダクトオーナーが仕様書を書いていること
承認を行わずに成果物が本番環境にリリースされることありません
一回スクラムとか始めると、それをやめると言い出すの結構ハードル高い気がする。なんとなくスプリント回ってベロシティとか見えてきて上手くいっているようにも見えると、これやめていいんだっけ、みたいな。スクラムイベントは儀式で、削れない制約、みたいな。
スクラムがマッチする類のタスクやフェーズと、そうでないタスクがあると思うので、柔軟にやっていけると良さそう。
Facebook、Whatsapp、Google、Netflix や同様の組織のエンジニアと話すと、彼らのほとんどはスクラムを実践したことがありません。なぜか？それにはいくつかの理由があります。
有能で自律的な人材は、信頼できる質の高いアウトプットを生み出すために、より少ない構造しか必要としません。 大手テック企業は、このような人材を惹きつけ、余裕をもたせ、雇用できます。
有能なチームを活用するには、彼らに働き方を選択する自由を与えることが必要です。
自分もチームの仕事を構造化するよりも「全員が全速力で走るのが一番速い」と思う派閥ではあるけど、それは全員がプロフェッショナルであり、阿吽の呼吸で動けるという前提が必要なので、そういう状況じゃないならやっぱある程度の構造化は必要かなあ。ビッグテックに入ってくるような人はみんなプロフェッショナルなんだろうけど。
Working Out Loud 大声作業（しなさい）、チームメンバー同士でのトレーニング文化の醸成
作業が途中であってもチームメンバーの目の触れる場所にガンガンアウトプットする
作業で詰まったらとにかく尋ねる
リモートワークになってからさらに Working Out Loud の重要性に拍車がかかったような気がする。
自分も社内の times によくポストするようにしている。times 文化の良し悪しはあるけど、そもそも slack に頻繁に投稿する人と全く投稿しない人で二分化されがちなので、その辺は
「それは単なる思考様式ではなくスキルだから、言って3秒で即実践はできない。実践を繰り返して習熟する必要がある」
と、文化の醸成が大事なんだろうなあと。
技術の洪水に立ち向かう: 開発者の心を軽くするプラットフォームエンジニアリングの話
クラウドの浸透、エンジニアの責任範囲の拡大
↓
覚えること、管理することの増加
↓
認知負荷の増大による生産性の低下
↓
全部頑張るは無理だから、その道のプロにお願いしたい
↓
プロ=プラットフォームチーム
↓
じゃあプラットフォームチームの定義と関わり方とは？
↓
プラットフォームチームも4つに分解
チームトポロジー
情報の整理と標準化
4割の共通プラットフォームは生まれながらに死んでいる
4割の共通プラットフォームはうまく運用できずに死んでいく
プラットフォームにもプロダクトマネジメントが必要。難しい。
誰に、何を、どうやって、価値を届けるか。
認知負荷が多いか少ないかは相対的なものだから定義が難しいけど、全部をプロの水準でこなす、はやっぱ現実問題難しいというか非効率だから分業が必要になっていくんだけど、どこでその舵を切るか、どうやって分担していくか、が難しい。
開発要望タスクの優先度が「高」ばかりで悩んでませんか？
優先度決定において大事なのは、それを 「複数人が見たときに同軸で判断できる情報」 です。 多くの場合は「タスクが生まれた理由」のみが残されており、個々人が思いをぶつけ合うと空中戦を生む理由になります。
空中戦あるある。
書いた人以外の誰かが見たときに「このタスクのほうが先にやったほうがいいよね」というのがわかるような情報を共有しましょう。
例えば以下3つがおすすめです。
売上へのインパクト
他社との差別化
コスト削減
こんなん無理やろと思うかもしれないが、このレベルで明文化しないと一生空中戦のままということなんだろうなきっと。特にユーザーベネフィットと直接結びつかないようなタスクだとより一層。
管理や報酬と結びついた目標は“チート”を誘発する モラルを崩壊させない「目的ベースの目標設定」のやり方
「企業の目的が顧客の創造だということはわかりました」ということで、じゃあそれを自分の部門とか、部とか、課とか、チームとかにどうやって反映させるのかというと、これはまた難しい話
それぞれの目標、個人とか組織とかの目標が、その価値交換システムにどう関係あるのかを説明できないといけないわけです
SMARTのSはSpecific（具体的）です。Measurable（計測可能）。これがやたらとフォーカスされている。3つ目がAchievable（達成可能）です。夢物語じゃなくて現実的に達成可能じゃないといけない。次がRelated（関連性がある）。ここですよ
ここですよ。
Measurable（計測可能）ばかり強調されますが、大事なのはRelatedです。関連性があるほうが重要で、上位の目的、部門とかチームの目的とどう関連性があるかが切れているとまずいということになります
個人の目標も会社、部門、チームの目標とのアライメントが取れていることが大事。
アウトプットがどう事業インパクトを生み出したかというアウトカムをしっかり計測していきたい。けどこの導出どうやるのがいいんだろうなあは結構模索中というか全然わからんって感じがしたりもする。難しい。
目標を管理や報酬と結びつけるとモラルが崩壊する
関連性がないとどうなるかという話をしたいんですが、関連性がないとビルドトラップと呼ばれるものに陥ります。
そもそもの個人的な感覚として、目標管理と評価制度は、利益の再分配と個人の成長という二つの目的を一つのツールで同時に満たそうとしているので難しいんじゃないかと思う。
pmconf 2023 プロダクトと事業を無限にスケールするための最強のロードマップの作り方
これはだいぶ刺さった。pmconf の中で一番沸いていたんじゃなかろうか。
ロードマップ欲しくなるんだよな...
目標管理と評価制度の考え方
ここで重要なのは、非連続な成長を期待しているということは不確実性の高い挑戦を行うことでもあり、つまり、必ずしもうまくいくかどうかはわからないということ
だから成果を評価するような評価制度だとチャレンジが少なくなってしまう。失敗を許容する文化、みたいなのは口で言うのは簡単なんだけど制度上もしっかりそこが組み込まれていないと誰もチャレンジしなくなっちゃうだろうなとは思う。
新卒で入った会社は新人に難しい仕事をこれでもかというほど振って、どれだけチャレンジできたかをしっかり評価する風土があったので、そういう環境が合う合わないはもちろんあるけど、合う人には成長できる環境が整っていたなと思う。
従って、評価面談で目標設定のときにこれを立てていましたが・・・のようなコミュニケーションは不要です。目標設定のときに立てたことをやれていないときは、普段の1on1で話せていれば良いですが、逆に頻度が多いと話すタイミングを失ってしまうというパターンが多い気がします。そういうときは、月1回の頻度で目標を見直す場を1on1とは別に設けてみるというのも良いです。こうやって予め目標をメンテ出来ていれば、堂々と評価面談に望めるようになります。
この辺も大事だなあ。不確実性の高い環境であればあるほど、期初と期末で全然状況が違うなんてことは往々にして起こりうるし。
上にも書いたけど目標管理と評価制度を密結合させて二兎を追うのではなく、個人の成長は目標管理で、利益の再分配は評価制度で、と棲み分けつつも、それをいい感じに結合していくのが良さそう。
「キャリアラダー」に合わせるか、「生み出した価値」で評価するか プロダクトマネージャーの評価のやり方
エムスリーはグレード制を導入していないので、基本的にキャリアラダーという考え方は使っていません
なるほど。グレード制を取ってないとこって結構あるのかな、あんまり聞いたことない気もする。
私がグレード制を導入していない一番の理由が、中途採用でメチャクチャ困るんですよ。中途採用はどうしても前職給与の考慮が必要
これは確かにそう思う。グレード間のオーバーラップがある程度あればいいんだろうけど、ない場合は給与に合わせてグレード決めると整合性取れなくなっちゃうパターンは起こりがち。降格がしやすい環境なら深く考えなくてもいいような気もするけど、日本だと降格の人事考課は中々難しそう...。
これから学ぶ人のための ソフトウェアアーキテクチャ入門
大変よくまとまっていてソフトウェアアーキテクチャという曖昧なものを改めて復習できた。
自分が年度初めに書いた技術ブログの稚拙な内容と似通っている部分もあり、自分の理解が大枠そこまで外してなかったかなというのが再確認できてよかった。
キャリアの明文化から3年間、どんな変化が？ Engineering Ladderの活用と改善
こういうふうに定期的にしっかりと効果測定と振り返りができてるのが強い組織という感じがする。
開発プロジェクトはギャルマインドで乗り切ろ🤟💫
ギャル「いや暗くね？」
「めっちゃいいことしてるはずなのにめっちゃ暗くね？」
「改善活動まじ尊くね？学んだことで昨日のうちらより強くなるくね？最強じゃね？」
「うちら最強！」
メチャいいマインド。ついついネガティブになりがちだから意識していきたい。ギャルネス、ギャルマインド。
Discussion