失敗したエンジニア組織施策としくじりの反省｜nottegra@在宅勤務
前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ
VPoE handbook | エンジニア組織のマネジメントに悩んでいた三年前に戻れるなら渡したい。VPoE handbookを書き終えました (目次&サマリ付)｜Takayuki Shimizu
（この記事はVPoE handbookの目次＆サマリパートです） 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 （この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。） VPoE handbookを書こうと思った理由まずはなぜ書こうと思った？の問題意識から。 この記事にあるように、三
どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング
Platform チームの@deeeeeeeetです． Platform チームは2年前にMercariがMicroservicesの移行を始めたときに一緒に立ち上げられたチームです．Platform チームはMicroservicesを動かすための基盤や開発や運用のためのツールセットなど提供しています．立ち上げ時は自分を含めて2-3人で始まったチームですが2年が経ち10人を超えるチームにまで成長しました． チームのメンバーが増えるほど1チームとして動くには限界がきており，またMicroservices化が進めば進むほどチームの負う責任範囲も広くなりCognitive load (認知負荷) も高くなっていました．これらの課題を解決するために組織変更を行い，Platform チームを複数の専門性に特化したチームに分割しました． 本記事ではチームのデザイン，チームが分離しても独立性を保ちつつ
マネージャのための意思決定ツールセット 3 選
学生の進路の相談やスタートアップするべきかどうかなど、意思決定に関する相談を時折受けます。そんなとき質問に対する答えとしては What ではなく How、つまり「どういう風に考えれば良い意思決定ができるか（あるいは悪い意思決定を避けることができるか）」を答えることが多いです。もちろん私個人の意見を求められてるときは別ですが…。 理由としては、私よりも相談相手の方が持っている情報量が多いときには、どちらかというと方法論的なサポートのほうが効果的だと思われるためです。特に人には様々な認知バイアスがある割に、認知心理学等の知見を使った意思決定の方法論はあまり広く認識されているわけではありません。 そんなとき学生に紹介する意思決定のためのツールセットは、経営者やマネージャの仕事にも使えるものではないかと思います。というのもマネージャの仕事の多くは意思決定だからです。特にスタートアップの経営者やマネ
視座の可視化｜kgmyshin
視座が高いってそもそもなんやねん問題 1on1で「視座を上げてほしい」って言われたり、マネージャー陣の集まりで「視座高い人がいいよね」って会話をしたりするけど、じゃぁ「視座の高いってなんぞ？」「どう見極めればええのん？」ってなりますよね。 自分も前職でエンジニアリングマネージャーしてた頃から、現職にて横断組織の一環として採用にかかわるようになって良くそれらのセリフを聞いております。 で、これが正解ってわけじゃないんですけど、自分はいつもこんな感じで可視化してますよってのを紹介してみます。 「視座が高い」を端的に言うと 自分は「視座」ってのは一言でいうと「どのレベルの課題まで、当事者でいられるか」っていうスタンスの度合いだと解釈しています。 ここで言っているレベルというのは難易度ではなく対象のスコープのことです。個人の課題なのか、チームの課題なのか、はたまた所属する会社の課題なのか。 で、「
専門職と視座
こんにちは。ミクシィでスポーツやライブエンタメ関連の技術部長を担当している石井です。社内向けに書いている記事を少しづつ外部公開していきます。 大規模なサービス開発組織で働いていると、技術職スタッフにおいても、視座の高さを求められることが増えます。「視座の高さ」という単語は、曖昧で、入社していきなり「視座！視座！」と言われても、「えらい人がなんか言うとる」「わいには、まだ早い」くらいで、腹落ちしないと思います。しかし、給与体系にも紐づいていたりするので、給与が上がってくると、「視座をもうちょっとあげてもらわないとね…」と上長から言われれて「えー」となるかもしれません。私の考える「視座の高さ」と、なぜ専門職にも必要になるのかを説明しつつ、サービス開発と組織の関係について考えてもらう機会になればと思います。 私は、エンジニアリングを、単にプログラミングを書いたりすることで技術課題解決するというこ
【CTO・エンジニアマネージャーに聞いた】企業成長フェーズ5段階別に発生するエンジニア組織の課題と取り組み事例まとめ | Findyブログ
【CTO・エンジニアマネージャーに聞いた】企業成長フェーズ5段階別に発生するエンジニア組織の課題と取り組み事例まとめ 2020.02.13 Findyの石川（@HRBizDev1）と申します。 2019年3月にFindyへジョインし、昨年まではFindy Freelanceの立ち上げ、今年からは先日、事前登録を開始したFindy Teamsの事業開発を担当しています。 （前職ではエムスリーグループの企業で医療機関の採用支援や新規事業を担当していました） Findy Teamsではβ版リリースに向けて、上場企業から創業初期のスタートアップまで、様々なフェーズの企業数十社へヒアリングを進めている段階ですが、その過程でエンジニア組織において発生する組織課題は事業成長フェーズによって、異なることが段々と見えてきました。 そこで、今回はヒアリングを通じて見えてきた課題と取り組み事例をまとめてみました
Engineering Manager とはやっぱりコマンダーバトルなのではないか - make clean; make
Engineering Manager (以下 EM) を始めて二ヶ月くらい経った。依然として EM というものはいったい何なのかを考え続けている。 引き続きもやもやしている弊社 (Quipper) において EM が最低限こなさなければならない「義務」のようなものは概ね把握してきた。 それは第一には「メンバーの評価」であり、第二には「採用活動」である。これらは将来変わるかもしれないが、いま時点においてはこれらが EM の仕事といって差し支えないように見えている。実際、業務時間のだいたいはこれらに関する何かで時間を使っている。 さて、4 月に EM になってから 5 月末に至るまでずっと「もやもやした不安」を感じていた。 それは「EM になったはいいけど、EM ってどういう仕事する人なんだっけ」っていうのをよく分かっていなかったからだと思っていたのだけど、先述のようにそのへんが概ね明らかに
フラットな組織も崩壊、「ビジネスの定説」過信で起きた4つの失敗 LayerX・福島良典社長
スタートアップをはじめとした新産業領域を担当。IT系メディア「CNET Japan」（朝日インタラクティブ）の編集記者、米国スタートアップメディア「TechCrunch」の日本版である「TechCrunch Japan」（Boundless）の副編集長などを経て、2019年にダイヤモンド社に入社。ダイヤモンド編集部 副編集長、DIAMOND SIGNAL編集部 編集長を務める。2024年1月より現職。 From DIAMOND SIGNAL スタートアップやDX（デジタルトランスフォーメーション）を進める大企業など、テクノロジーを武器に新たな産業を生み出さんとする「挑戦者」。彼ら・彼女にフォーカスして情報を届ける媒体「DIAMOND SIGNAL」から、オススメの記事を転載します。※DIAMOND SIGNALは2024年1月をもって、ダイヤモンド・オンラインと統合いたしました。すべての記
Spotify’s Failed #SquadGoals
Failed #SquadGoals Spotify doesn’t use “the Spotify model” and neither should you. By Jeremiah Lee Sunday, April 19, 2020 • Listen • Watch • En français • 日本語で • Português (Brasil) About the cover illustration Of all the allures of startup culture, few are more desireable than the speed and nimbleness of a small team. Maintaining that feeling as a company grows is a challenge. In 2012, Spotify sha
エンジニア評価制度の取り組みを振り返ってみた - Retty Tech Blog
はじめに Rettyでは2018年から組織的な改善活動を数多く始めており、その一つにエンジニアフィードバック（以下、フィードバックはFBと省略します）制度があります。 本記事はRettyのエンジニアFB制度への取り組みの紹介を兼ねた、これまでの改善活動の振り返り記事となっています。 （2018, 2019年のアドベントカレンダーの小迫の記事に組織的な改善活動についての紹介がありますので興味がありましたらご参照ください） engineer.retty.me engineer.retty.me エンジニアFBは今なお半年の評価ごとに継続的に改善を繰り返していて、今は4回目の改善サイクルとなる2020年上期のエンジニアFBが終わった頃となります。 対象としたい読者 下記のような項目にピンと来る方に読んでいただけると嬉しいです。 会社のエンジニアが評価に対して不満を抱えており、他社の評価制度の取り
タイミーのEMとしてどのようにマネジメントしているか - Sionの技術ブログ
はじめに 16歳からゲーマーとしてずっとチームマネジメントをやっており、 自身の強みなので本腰入れてやりたいという思いで1月にタイミーに入社しました。 結果、今はSREマネージャー(2人) + BI基盤チームマネージャー(3人) + コーポレートエンジニア(3人)として働いてます。 そんなにメンバーはいませんがマネージャーはやれてると思ってるので、色々と書いてみたいと思います。 そんなに掛け持ちして大丈夫なの？ スタートアップは仕方ないです。ぜひ強い方募集してます。 自分の脳内の長期計画は全てアウトプットしてチームと精査してるので出来る人がやればいい状態です。 私自身マネジメントしながら、業務でコードも書いてレビューもしてるので、自身の時間を作るために自走できるチームを作り上げるためのマネジメントでもあります。 マネージャーとしてどういう動きしてるの？ - ローテーション可能のものとする
退職の作法、あるいはオフボーディング実践入門 - スタディサプリ Product Team Blog
-0b10日後に最終出社を迎える@ohbaryeです。 最終出社を迎えるにあたって後任の任命や業務の引き継ぎといった退職・離職までの一連の流れを経験したわけですが、なにぶん人生でそうそうあることではないのでしばらくは暗中模索の様相を呈しました。人生において数度あるとはいえ慣れるほど数をこなすわけでもなく、同じ会社ですでに退職を経験された方々、あってほしい"先達"はすでになく。 会社としての事務手続きは整備されていても、どのような振る舞いがより効率的であるのか、退職後も良い信頼関係を築けるのかといった点についてはさほど多く語られていないと気付きました。 この記事では退職・離職までの一連の流れを"オフボーディング"と呼称し、退職が決まってからの効果的な過ごし方を目指してやってきたことについて記述します。 ありふれたビジネスマナー記事にならないように留意したつもりです。 対象読者 退職する人 同
エンジニアが成果アピールで意識すると良い4つの観点 | Recruit Tech Blog
はじめに結論 自身やチームの取り組みをアピールする際、以下4つの観点 (Issue度・解の質・革新性・主体性) を意識すると、成果アピールの説得力を高めることができます。 成果 (創出した物事の価値・意義) Issue度: どういった／どのくらいの問題に取り組んだか？ (重要度・規模感・難易度) 解の質: やったこと／結果は、どういった／どのくらいの変化・貢献をもたらしたか？ (価値・意義) プロセス (成果を生み出した理由・背景) 革新性: アプローチ手法の着眼の良さ／工夫点はあるか？ (アプローチ方法) 主体性: アプローチをどのような立場で／どのくらい主体的に推進したか？ (進め方) これらの観点を意識して適切に成果アピールできるようになると、成果面談などの社内イベントのみならず、社内外のプレゼンや転職活動 (レジュメ作成・面接・交渉) など様々な場面で役に立ちます。 そもそもこれは
エンジニアリングスキルで捉えるチームマネジメント - mtx2s’s blog
チームのマネージャーが、自らの責務をジョブディスクリプションとして明文化することは難しい。職務内容や権限を、断片的にしか書けないかもしれない。もしそうなるなら、実務も断片的になっている可能性がある。 チームマネジメント（組織マネジメント）という活動は、個々のマネージャーの経験や関心によって、断片的になりやすいように感じている。断片的とは、マネジメント活動が、責務の一部の領域に偏ってしまっていたり、問題を検知してはじめてその領域がマネジメント範囲であることを知る、といった様子を指している。 このような状態になる背景は、マネージャーにとって、マネジメントが、日々の実務を通して蓄積された経験に基づく活動になっているからではないか。マネージャーは孤独だ。ひとりでその責務を担う。エンジニアとは違い、チームで協働するわけではない。だから、形式知として言語化されず、個人の経験として暗黙知にとどまる。その
「やる人がいてへんかったら必要ないんちゃう？」PTAなしで始まった大空小 初代校長・木村泰子先生の話（大塚玲子） - 個人 - Yahoo!ニュース
PTAで苦しむ人をなくすべく、取材や執筆を続けてきました。しかし、それは実現可能なことなのでしょうか。 そもそもPTAという団体は、何をするために存在しているのか？ 現在、多くのPTAが行っている活動から逆算すると、PTAの存在目的は「学校のお手伝い」「保護者の学び」「保護者同士の交流」「地域との橋渡し」などといえそうですが、果たしてそれらは皆「本来の目的」といえるものなのか？ 本当はその名称のように、P（Parent）とT（Teacher）、すなわち保護者と学校が、対等に協力する場ではないのか？ そんな疑問もありました。 そこでいったん、ゼロベースで考えてみたいのです。PTAのことはいったん脇において、P（Parent）とT（Teacher）、すなわち保護者と学校の間に必要なものは何なのか？ どんな関係性が必要で、それはどのように実現できるのか？ ということを。 そのため、学校現場をよく
組織の壁みたいなもの
こんにちは、Reluxの篠塚です。35歳の最終日、超大作の1.4万字のNoteができあがりました。書いてみたは良いですが、長すぎてニーズあるのかが実は不安です。頑張ったので、Twitterをフォローしてくれたり、シェアしてくれたらすごく喜び… 経営者ではないけど、自分は5年以上、とあるプロダクト開発組織の初期のメンバーとして関わってきている。 その組織内のエンジニアリングマネージャーであるのと同時に、なんとなく、組織全体の空気感だったりとか慣習を作ってきたうちのひとりだと今振り返ると思う。多分、在籍期間が長いのと、組織のほぼ半分がエンジニアで、それをマネジメントする立場だから自然とそういう立場も引き受け続けてきたのかなーと思う。 そういう中で、やっぱり組織の壁は存在していたし、今もかなりソレと戦っている。5人くらいで開発を始めた当初はしばらくは、非常に良い意味で本当に好き勝手にプロダクト開
スタートアップの組織設計図の5類型と、その失敗率 | Coral Capital
最近でこそ「MVV」（ミッション・ビジョン・バリュー）ということが話題になることが増えて、スタートアップにおいて、比較的早期に組織のレーゾン・デートル（存在意義）を考えたり、言語化することが増えてきましたが、これは日本では比較的最近のトレンドのように思われます。 まだメルカリが社員10名程度だった頃、現在同社の取締役会長を務める小泉文明さんが経営陣4人とともに合宿をして、今では有名なメルカリのバリュー、「Go Bold」（大胆にやろう）、All for One （全ては成功のために）、Be Professional （プロフェッショナルであれ）を定めたのは日本のスタートアップ業界では良く知られた話です。2013年末から2014年にかけてのことで、当時、アーリーステージのスタートアップが、こうした言語化をするのは極めて珍しいことでした。すでにメルカリは最初の5か月で100万ダウンロードと成長
開発者の年功レベル
Kamran Ahmedのブログより。 ジュニア、中堅レベル、またはシニア開発者としてステップアップするには? カムラン・アーメッド (Kamran Ahmed) 私はロードマップのやり直しに取り組んでいます —— 年功レベルに基づいてスキル一式を分割し、新しい開発者に理解しやすくし、怖がらせないようにします。ロードマップは技術的な知識についてだけになるので、私が繰り返し、様々な年功の役割について考えていることについて記事を書くのは良い考えだと思いました。 私は、多くの組織が長年の経験を本来あるべきものよりも重要視することで開発者の年功を決定しているのを目にしてきました。私は、「ジュニア」とラベル付けされた開発者がシニア開発者の仕事をしており、「シニア」と呼ばれる資格さえない「主任(lead)」開発者を見てきました。開発者の年功は、彼らの年齢、経験年数、または彼らが持っている技術的知識だけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
