開発の生産性を高める新たな視点〜開発生産性フレームワークSPACE〜 での登壇資料です
なぜ僕たちは 開発生産性指標を見ていないのか / Our Strategy for Development Productivity Metrics
開発の生産性を高める新たな視点〜開発生産性フレームワークSPACE〜 での登壇資料です
「中間管理職の限界」と「マネジメント民主化モデル」について｜Momentor坂井風太
中間管理職は限界なのか？本記事は、本日2024年7月1日21:00にNewsPickで放映される【2Sides:中間管理職は不要か？】という番組に関連した記事となります。 動画については、『罰ゲーム化する管理職』など、数々の名著を生み出していらっしゃる、パーソル総合研究所の小林祐児さんとMCの加藤浩次さんとのセッションであり、最終的には明るい内容でまとまっています。 本記事については、本動画で提唱している「マネジメント民主化モデル」について解説しつつ、坂井の会社でエンジニア採用を開始することに伴い、「なぜ坂井が本事業をやっているのか？」についても触れていきたいと考えています。(※採用情報は末尾となります) 形骸化する管理職研修昨今、小林祐児さんの『罰ゲーム化する管理職』に代表されるように、「管理職の過剰負荷問題」が騒がれるようになりました。 実際に、坂井も企業のマネジメント基盤の支援をする
何が事業貢献なのか分からなくなっていた伊藤直也さんが再認識したユーザーエクスペリエンスへのコミット - Findy Engineer Lab
ソフトウェアエンジニアは、どのように事業に貢献すべきか？ 宿泊施設やレストランの予約サービスを提供する株式会社一休で執行役員CTOを務める伊藤直也さんは、2016年に入社しておよそ2年間、心の奥に抱えた悩みを解消できないまま仕事をしてきました。 伊藤さんは、2000年代から複数のWeb系テックカンパニーで技術部門のリーダーとして活躍し、現在でも利用される個人向けWebサービスのローンチをいくつか手掛けています。一休には入社以前からフリーランスで技術顧問を務めており、会社がヤフーグループ（当時）に入って経営陣が一新されるタイミングで、代表取締役CEOとなった榊淳さんの要請を受けて入社しました。 当時は全て.NETだったというサービス基盤の刷新や技術的負債の解消、開発組織の整備といったエンジニアリングにおいて重要な改善を進めてきましたが、あるとき自身が「事業に貢献していない」ことを明確に意識す
上司と親方の違い、徒弟制度の再発明でプログラマ育成 | Social Change!
多くの仕事が複雑化していくほどに、マネージャの難易度は上がり続けていきます。とりわけ部下がついたら成果を出すことと同時に、人の育成までも求められたりすると、どうしていいかわからなくなります。 しかも、心理的安全性やワークライフバランス、強みを活かす多様性に満ちた自律的な組織と言った言葉が注目される世の中です。当然ですがハラスメントなどもってのほかです。マネージャの悩みは尽きません。 そこでマネージャの仕事を、人を活かす「上司」と、人を育てる「親方」で分けて考えてみました。以下の図でまとめています。ここが互いに認識と期待がずれていると不幸が起こります。 デジタル化やAIが進むことで、現場から容易な仕事は減って、難易度の高い仕事ばかりになりつつあります。一方で、誰もが最初から高度な仕事はできません。どこかで経験を積んで育つ機会がないと、いつまでも初心者のまま何年も過ごすことになってしまいます。
開発組織のOKRの作り方 / OKR in a development division
Mutation Testingを活用して テスト品質を考える /introduction to mutation testing
マネージャーに全てを決められたくない vs マネージャーには答えを持っていてほしい問題について - yo-log
Engineering Manager Advent Calendar 2023 7日目の記事です。 結論ファーストで書きます マネージャーは答えを持っていません。 大事なことなのでもう一度言います。 持っていません。 この問題ってそもそもなに？ 細かくみてみましょう。 マネージャーに全てを決められたくない マネージャーがHowまで決めてくるケースや、現場チームが決めたHowに対して口出ししてくるようなケースにおいて発生する事象です。 ものによってはWhyやWhatまで現場で考えたいんだ、というケースもあるかもしれません。 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023 - Speaker Deck こちらのスライドにあるような「私考える人」的な動きになっているマネー
目標設定とは何か - Konifar's ZATSU
目標設定むずかしいよね。正直嫌いとか意味がわからんと言う人も多いと思う。自分は適切な目標設定は必要なものだという腹落ちはしてるんだけど、なぜむずかしいかとかはうまく説明できなかった。 そんな時に EM.FM Re8. 本当に意味のある目標設定 でMBOの歴史から色々と話していてさすがだなー面白いなーと思ったので、自分もそもそも目標管理とは何なのかﾁｮｯﾄ調べてみることにした。 学術的にきちんと学べたわけではないので少しこわい部分もあるけれど、こういうのは誰かのためになるかもしれないし書いてみる。もし間違いや補足があれば教えてもらえると嬉しい。 目標管理の起源 目標管理の起源は欧米の研究者の中ではよく論じられているテーマらしい 諸説あるが、アリストテレスが 「成功するには目的意識を持て」 と言ったのが最初という説もある この起源とは関係ないが、Googleでは「効果的なチームを可能とする条件
仕事と給与と評価の関係
ベイジで新評価システムの運用を開始するにあたって作った、仕事と給与と評価の関係を説明した社内向けのスライドです。会社や経営者によって考え方は変わると思いますが、できるだけ分かりやすく、一般化してみました。何かの参考になれば幸いです。
品質保証部門の陳腐化。そして陳腐化した品質保証は品質を悪化させる - 千里霧中
※品質保証のエンジニアである筆者が自省・戒めのために書いた記事になります 品質管理（Quality Control）、品質マネジメントは国内では製造業を中心に発展し、プロダクトの競争力向上に貢献してきました。 JTCと呼ばれる旧来からのメーカーでは、その実績・年功の蓄積に応じて、独立性を保った品質管理・品質保証部門が権威を獲得し、今でもソフトウェア開発に強い影響力を保持するようになっています。筆者は複数のメーカーを転職やコンサルで巡って来ましたが、例えば品質保証部門が承認しないとマイルストーンで開発がブロックされる、プロダクトがリリースできないといった権限を持つ体制が、今なお普遍的に見受けられます。 この品質保証部門が権力を持ち、品質ゲートの門番として振る舞う体制は、今であっても、ある面で恩恵を提供しています。例えば次のようなものです： 法規制対応、標準化対応、その他公的なガバナンス要求へ
ティール組織わからん、を掘り下げる - Kengo's blog
組織の話が好物なので色々読んできたのですが、結局ティール組織はよくわからないままでした。最初に本を読んだのが5年も前なんですね。 ティール組織は面白くなかったというか、個人的にはそこまで響かなかった。歴史書読んでるみたいな感覚で……。リーンスタートアップは部署レベルで実践できそうだけど、こっちはそうは思えなかった。— 絶賛異世界転生中 (@Kengo_TODA) July 6, 2018 で、自分なりに考えた結果、大きく2点においてよくわからないのだと思ったのでメモしておきます。 以下、「ティール組織」と書いた場合は書籍「ティール組織」を指します。なお昔読んだ本を読み返しながら書いているので読み飛ばしによる誤解などはあるかもしれませんし、ここ5年で新しい発見があったとしても私はそれをキャッチアップできていないことにご留意ください。 組織に人間の弱みを補う機能を求めたいのに、スキル常時発動を
組織という仕組みで解決することの難しさ、あるいはマネジメントに超人を求めるのは間違っているだろうか - Kengo's blog
そりゃ間違ってるんだけど、ではどうするべきなのかが見えてないなぁという話です。 事業が大きくなると組織という仕組みの重要性が上がる 同僚が何千人といたメガベンチャーから社員数20数人のスタートアップに転職してから1.5年経ちました。ここまでに自分が貢献した内容にはSREや医療情報技師としてのものも当然あるのですが、マネジメント経験のあるIndividual Contributorという立場から組織の成長や組織における連携について補足や関連情報を提供するということも意外とありました。例えば社内ブログや社内勉強会で触れたものには以下のようなものがあります： コーチング紹介 ヒューマンスキル紹介 爆速アウトプットを組織的に支える施策 事業の急成長における表側と裏側 稟議入門 こうした知識や観点を個々人が持つことは、ボトムアップと呼ばれる自発的な行動を支援する意味では大きな意味があります。そして少
純ホラクラシー組織の運用法のすべて - scouty HR TECH LAB
LAPRAS代表の島田です。LAPRASはアメリカで発祥した「ホラクラシー組織」という形態をとって運営されています。今回はLAPRASの実運用例を含めて、ホラクラシー組織とは何か、どのような形で運用されているかをご紹介します。 ホラクラシー組織に関する誤解日本では、一般にホラクラシー組織というと 上下関係の無いフラットな組織自由度が高く、ルールが少ない組織情報がオープンな組織といった特徴をもつ組織として認知されているようですが、これはアメリカで発祥した本来のホラクラシー組織の定義とは異なります。 本来、ホラクラシー組織というのはHolacracy Oneの創設者であるBryan.J.Robertsonがアメリカで提唱した組織体系で、組織のフラットさや情報の透明性などの文化だけで本質づけられるものではありません。 実際に、Bryanも自著「HOLACRACY – 役職をなくし生産性を上げる
100人を超えたプロダクト組織で全員が活躍するための役割可視化の取り組み - asoview! Tech Blog
これはアソビュー！ Advent Calendar 2023の25日目です🎅 今年のアドベントカレンダーは2面公開なので、ぜひそちらも御覧ください！ アソビューでVPoE兼Tech Leadをしているdisc99🐼です！ 今年のアドベントカレンダーは1日に技術的取り組みを紹介させてもらったので、最後の今日は組織的な取り組みの紹介をできればと思います🎁 はじめに 起こる問題 コミュニケーションパスの問題 組織構造の問題 多様性 変化への適応 目的 Holaspirit 期待する効果 可視化による効果 アップデートプロセスによる効果 最後に はじめに 現在アソビューでは、プロダクト開発を行っているプロダクト組織(*1)が110名、会社全体では300名(*2)を超えています。 また、中心事業であるマーケットプレイスやパートナープラットフォーム他、ギフトやふるさと納税などの新規事業を展開して
市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ
エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて？どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗
顧客視点でモノを考えてもらうには
知人のエンジニアリング・リーダーと話していたら、「エンジニアに顧客視点でもっとモノを考えてほしい、そこに芯を持ってほしい」と思い悩んでいた。その人がその短い言葉に込めた思いを全部理解したとも思わないが、僕もそういう気持ちは良く分かる。 現在の事業上の課題とは全然関係ない方向に情熱を燃やす人。そこはそんなに拘るところなの、と思うところに拘りを持つ人。まあ一定数見てきた。もっと全員で同じ方向を向いて同じ問題意識を持って…何とかならないのかなぁ。 わかります。 まさにそういうのを実現するのがエンジニアリング・リーダーの仕事ですよね。 僕も人様に講釈できるほど上手く出来ているとも思わないが、今までの反省からこういう道具が使えるんだな、という考えは幾つかある。 技術者の美意識・情熱というのは、宗教のようなものだから、布教が出来る。会社に望ましい方向に技術者の情熱を誘導してあげるということだ。例えば、
マネージャーとNegative Capability - scrapbox - hotchemi
Negative Capabilityという概念を最近知った。詩人ジョン・キーツが提唱したとされている用語で「事実や理由を性急に求めず、不確実さや不思議さ、懐疑の中にいられる能力」を意味する。対義語はPositive Capabilityで、所謂課題解決能力の事。 我が身に翻ってみると思い当たる事が多く、特にマネージャーをやっているとこの能力の有用性を感じずにはいられない。例えばよく目にするのは以下の様な事象だ。 新しく入ってきたマネージャーが成果を出そうと張り切って色々提案するが、芯を外していたり合意を得られてなかったりで現場でハレーションが起きる ある問題を解決する為に新しいツールを導入するが、新しいツールが更なる問題を引き起こし以前より状況が悪化する 組織内で色々改善活動を試みるが、すぐには効果が出ず反応も芳しくないので心が折れてしまう これらはpositive capability
On Personal Relations As A Manager
I was reminded by a discussion with a friend why, as a manager, you should be cautious about the relations you develop with the people in your team. Since the day I started to have people “reporting to me”, I have felt weird about the hierarchical nature of the relation it creates. This is probably rooted in some form of an imposter/inferiority syndrome, which evolved into the underlying philosoph
キャリアハックの奇行 - Software Transactional Memo
エンジニアの奇行 嚢中の錐という言葉がある。有能な人物は自ずと傑出していくという意味だが、有能さとは例えば学歴の高さとは一致しない。 たとえMIT卒であろうとも大成するとは限らないし、ましてや入試の点数などで見れる人間の側面は限定的である。 企業などで採用する側からしてみたら当然ながら採用後の活躍を期待して雇用するのであり、入社をゴールとしてそれ以降働かなくなる人は望ましくないし、学歴や入試の点数によってそういう人かどうか判定する事はできない。 活躍という観点で言うと長いキャリアにおいてより重要となるのはキャリア開始時での能力の高さよりも、険しく長い道のりを自己メンテナンスしながら歩み続けられる根気の強さが重要とされている。その根気の源泉は執着だったり崇拝だったり妄信だったりトラウマだったり原体験だったり人によって様々だが、ここではひっくるめて「やる気」と簡略化して呼ぶことにする。 さて「
意思決定できる人の手順の型 - Konifar's ZATSU
意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアの心構え
