LegalOn Technologies のエンジニアグレード評価基準を公開します - LegalOn Technologies Engineering Blog
こんにちは。LegalOn TechnologiesでCTOを務めている深川といいます。 もし私がどういう人なのか気になる方がいましたら、私のことは以下の弊社オープン社内報でも記載していますので、よかったらこちらの記事をご覧いただければと思います。 https://now.legalontech.jp/n/n36b23e19f7b0 エンジニア組織の運営は人数が増えていくにつれて加速度的に難易度があがります。その中でも、エンジニアリングマネージャーにとって常に頭を悩ませるものが人事評価制度です。特に、評価基準については、公正かつ納得感があり、それでいて属人化しない評価基準を作り上げるのは至難の業です。 弊社も例に漏れずエンジニアのグレード評価基準に課題を感じていたため、2022年10月にエンジニアグレード評価基準の刷新を行いました。そこから約10か月が経過し、徐々に刷新の効果や課題が見えて
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
BASEのCTOがエンジニアリングマネージャーに求めていること - BASEプロダクトチームブログ
はじめに この記事はBASE Advent Calendar 2022の25日目の記事です。 CTOの川口 (id:dmnlk) です。 毎年技術ブログチームに勝手に組み込まれています。 タイトルと画像が一致してないのはデザインテンプレに合わせづらかっただけなので気にしないでください。 BASEでのエンジニアリングマネージャーについて エンジニアリングマネージャー(以下EM)は各社によって定義が分かれていることと思います。 どこに責任を持ってもらうか、という点が異なっており下記エントリーがまとまっていてわかりやすいです。 yigarashi.hatenablog.com BASEにおいてはEMは主にピープルマネジメントとデリバリマネジメントに責任を持ってもらっています。 ピープルマネジメントには採用も含んでいたりするのではないでしょうか。自分のチームの補強はEM自らが主体で採用していくとい
納得感のある決定事項の共有方法 - Konifar's ZATSU
意思決定の場にいない人に対して決定事項を共有する際、いくつか気をつけておくといいなぁと考えていたことを雑にまとめておきたい。 決定する前から進捗をちょっとずつ共有しておく 決定前の話なので後の祭りかもしれないが、いきなり結果をドーンだと相手を戸惑わせることがあるので事前に議事録を共有したり中間で説明する機会を作ったりするとよい 背景と前提条件を伝える なぜやるのかわからないまま結果だけ共有すると納得してもらいにくい。決定する上での前提条件を知らないと余計な反発をうむこともあるので注意が必要。それまでずっと考えてきた当事者は気づきにくいが、びっくりするくらい前提知識が違うことがある。相手は何も知らないものとして、イチから説明した方がよい 決定までの経緯を伝える 結論より経緯の伝え方が重要。どのような議論があってそんな決定になったか、完結に伝えましょう 捨ててきた選択肢も伝える 結果に至るまで
エンジニアや研究者からマネージャーや経営者になる時の不安について - 人間とウェブの未来
自分は元々とにかく技術志向のエンジニアであり研究者であった。とにかくコードを書いたり論文を書いたりすることが生き甲斐であった。 そんな自分が数年前に色々考えた結果、マネージャーや経営者の道を志すようになったのだが、その際によく聞かれることがある。「技術を中心にやれなくなる不安や葛藤はなかったんですか？」と。 その答えとしては「その不安や葛藤はない」である。なぜかというと、マネージャーや経営者に強烈な専門性を感じているからだ。勉強すればするほど、あれ、これはエンジニアや研究者の時にやっていた学び方とほとんど変わらないのではないか、と思えているからである。 おそらく僕自身も、かつてはマネージャーや経営者に専門性を見出せておらず、エンジニアからそうなることは考えてもいなかった。むしろ、技術者としての諦めのような風に捉えていたかもしれない。しかし、自分がそこに身を置くにつれて、全くもって雰囲気で適
急成長がもたらすハードシングス
資金調達に成功し、スタートアップとして飛躍的に成長を遂げる「最もエキサイティングな時期」こそ、経営者として一番つらかった。今回は私にとってのハードシングスについて話します。
プロダクトの目的・目標・指標をチームで考えていくために可視化した話 - SmartHR Tech Blog
こんにちは、プロダクトマネージャー（以下PM）の adachi です。（ToDo: ここになにか面白い文章を入れる） 先日、プロダクトの目的・目標・指標をまとめた図をTwitterに投稿したところ、わりと反響があったのでこちらで解説したいと思います。 開発メンバーから「会社の戦略とプロダクトの目標がどう紐付いてるかわからない」という声をもらって作った図。 改めて整理する中で自分のなかでも気付きがあり、もっと早くやっておけばよかったなと思いました。 pic.twitter.com/tuedZhaZG2— Takashi Adachi (@asanebo_) 2022年6月1日 この記事でお伝えしたいこと 会社のミッションや戦略とプロダクトの目的・目標・指標は、構造的に整合していることが重要である PMにとって自明に思えることでも、アウトプットしなければチームで共有できない 目的・目標・指標の
ビジョン・ミッション・バリューをすごく真面目に作ったのでプロセスを全公開します。1/3-ビジョン編-｜たんげ/mento COO
はじめにはじめましてこんにちは！ コーチングサービスmentoで取締役COOをしております、たんげです。 💡記事の内容まとめ ・mentoのビジョン・ミッション・バリュー新しくしました ・策定までのプロセス、ワークショップのアジェンダ、使用した資料・議事録を全公開します ・これからビジョン・ミッション・バリューを決める方はぜひ参考にしてみてくださいmentoのビジョン・ミッション・バリューを決めました 弊社は4/6の資金調達リリースに伴い、社名を株式会社mentoに変更し、コーポレートブランドの一新、それに合わせて、ビジョン・ミッション・バリューを決め直すこととしました。 正確に言えば、「ビジョン・ミッションはあるけどもっと良い言葉を探したいな〜」「バリューも決めたいけどもう少しメンバーが増えてきてからのほうが良いかな〜」と、少しあとまわしにしながら全力疾走してきたシード期でした。 しか
チーム内でも目標設定と振り返りをやってみよう！から1年が経ちました - STORES Product Blog
テクノロジー部門、STORES ECでフロントエンドエンジニアをしている @daitasuです。 私たちのチームでは、会社全体での人事制度で設定する目標とは別に、チーム内で独自にクオーターごとの目標設定と振り返りをしています。 チーム内での目標設定と振り返りを1年ほど続けてきたので、なぜこの取組を始めたのか、実際やってみてどうだったかを書いていこうと思います。 チームの位置づけ UI改善チームとは hey内では、全プロダクト横断的なテクノロジー部門という棲み分けがあり、その中にSTORES ECの開発を進めるECの部隊があります。 私たちフロントエンドチームは、ECのエンジニアチームの中の1つとなっています。 hey社のEC本部では、フロントエンドチームはUI改善チームと呼ばれています。 フロントエンドチームの構成 フロントエンドチームは、大きくプロダクト開発のチームと基盤改善のチームに分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
