こんにちは。askenでエンジニアリング戦略や組織づくりを担当しているやすにしです。 マネジメントを中心にしておりまして、せっかくなのでブログでもマネジメントについて書いてみますね。 私はこれまでVPoEとしてエンジニア組織のマネジメントや、様々な会社でマネージャー向けにコーチング 1 をやってきました。そこで接してきたエンジニアリングマネージャーに共通しているのは「キャリアに悩んでいる」ということです。 例えばこのようなことです。 コーディングをしなくなり、技術的に取り残されて、エンジニアとしてやっていけなくなる感じがする 自分でやらないから成果が見えない。やっている感じがしない。 マネジメントをどうやればいいか、どう学べばいいかわからない。 マネージャーのキャリアで自分は定年（？）まで生きていけるのか？ 共通点は、色々理由を言葉にしているものの、どれもしっくりきている感じではなく、「な

Summary. When misunderstandings arise among members of global teams, it’s often because managers conflate attitudes toward authority and attitudes toward decision-making. However, the two are different dimensions of leadership culture, says the author, who has extensive research and consulting experience with global companies. Attitudes toward authority range from strongly hierarchical to strongly

中野 仁 (AnityA) @Jin_AnityA リーダーシップと意思決定の分布が日本が独特という話。 階層主義で合意形成を重んじるとなると、上下左右全部に話を通して凄まじいコミュニケーションコストがかかる上に、上と左右からはとりあえず意見だけは言えるのでリーダーに対して投げられる石がだいたい当たるという事では…。 pic.twitter.com/bqHxAufImN

以前から何故CTOに代表される技術系の役員という役割が必要なのだろうか？と考えていた。技術が重要なだけなら昔ながらの製造業や通信産業の組織でも似たような役割が設定されていたはずだ。みんなバカじゃないので。CIOはいたがCTOはあまり聞かなかった。その違いはなんだろう？ スタートアップとして投資を受ける時にVCから「あなたのチームは技術者採用できますよね？」というのを証明するためにCTOの設置が求められたりするなど、特にWeb系企業においてはあたりまえの役割として設置されている。つまり技術者のキャリアパスとして、役員クラスまで登れるんですよ、という道筋の提示という役割はまああるのだろう。 ただ、それだと客寄せパンダにしか見えなくもなく、ビジネス的な役割が適切に存在しないのであれば長くは続かない。やはり技術部長やテックリードではなく、役員クラスとしての責任をどう果たすから技術系役員が必要だとい

エンジニアの成長段階ごとに期待される行動を明文化

こんにちは。このブログでは初めまして。2020年の2月にNewsPicksに入社した高山です。 今回は僕がNewsPicksのCTOになってからの1年でやったお仕事について書いていきます。 CTO最初のミッション DX Criteriaについて 「デプロイ回数」を定点観測 やってきたチャレンジ 1年経ってみて CTO最初のミッション NewsPicksは2013年に誕生し、5年ほどの壮大な創業期の間にたくさんの新しい領域に挑戦しており、僕が入社したときには既に事業面でもシステム面でも「それなりの複雑さ」という感じでした。 前任CTOの杉浦さん（今はグループ内でアメリカでの新規サービスの立ち上げをしています）からバトンを受け取って最初のミッションが「DX Criteriaを上げること」だと聞いたときにそのあたりの事情を全て察しました。😅 結論から先に書くと、1年で大幅改善を達成することがで

最近色々な方と話していて、組織運営上戦略が必要という話をしているんだが、私の説明力が足らずなかなか伝わりづらく、言葉だけで話すのは難しいなと思い、整理する必要性を感じた。ということで、まずは主に全体像であり概要をアウトプットしてみた。やってみると、自分の頭の中の整理にもなり、足りないこともわかった。アウトプット重要。今後はこの図と説明があれば、話をするときにはどの話をしているかがわかりやすくなりそう。 なお、番号をつけたが、この順番で考えればいいとは限らない。もちろんレイヤーが大きいところから決めていったほうが変更のコストは低いが、物事はそんなに簡単ではない。常にすべてのレイヤーで考え続け、それぞれにフィードバックをかけ続け、変更し続けなければ組織は成長しない。 今回書いたのはあくまで枠組みの話なので、この中に取り入れる何かは組織や人によって違うべきであると考えている。ただ、私なりにこの方

Learn moreHow creators are energizing their communities, and what’s coming next

Square’s Growth Framework for Engineers and Engineering ManagersA system for leveling up at Square At Square, we’re building products and services that help consumers and businesses participate and thrive in the economy. To accomplish this, we need to cultivate an environment where engineers can challenge themselves, achieve their goals for professional growth, and do their best work for our custo

ざっくり年収1,000万円のエンジニアが10名いる会社では、年間1億円の技術投資がなされているわけですが（地代家賃、ライセンスフィー、PC代など含めるともっと）、年間1億円を正しく詳細に把握して、投資をコントロールできている会社は少ないと思います。会社が創業期であれば、最低限作らなければならない機能などは分かりやすく見えていたりするのでまだしも、そのプロダクトでしっかりとした収益が成り立ち、上場企業となるようなレベル感のプロダクトに対する技術投資となると、一部の大きなプロジェクトは把握していても、細かな投資ポートフォリオを常に把握することは難しいのではないでしょうか？今回はこの部分に一石を投じてみたいと思います。 技術投資量を見える化する 投資の最適化とは言いますが、最適化というのは「To Be」の話ですので、まずは「As Is」を知らなければ話になりません。その、まず「As Is」を知る

「ヒト・モノ・カネ・情報」とひとくくりにされる経営資源のうち、「モノ・カネ・情報」の多くはすでにコモディティと化した。市場が短期間に大きく変化し、先行きが見通せなくなるなかで、戦略の有効期限は短くなった。（中略）そうした環境下で、すぐれた才能をもつ「人材（Talent）」を新たな価値の創造と差別化の源泉とすべきなのは自明である。それにもかかわらず、多くの経営者が実際には人材を最優先にできていないでいるのはなぜなのか。 という序文からはじまる 「TALENT WINS」。コーン・フェリー、マッキンゼーのエグゼクティブたちによって書かれた本で、「人材ファースト」をいかに実現していくか試行錯誤中の企業には参考になりそうな良書だった。 個人的にも取り組んでいる方向性と近い内容だったので引用ベースでまとめてみた。 人材ファーストの企業戦略へ変革するためのステップ本書に書かれているステップは大きく3つ

LINEで一生懸命働いている青田努（@AotaTsutomu）と申します。ベンチャー採用 Advent Calendar 2018のトップバッターを務めます。よろしくお願いします。 まず簡単に自己紹介させてください。 ざっくり書くと ↓ こんな感じ ↓ です。紆余曲折ありつつ、今は楽しく暮らしています。 リクナビの学生向けプロモーションや、求人広告の制作ディレクターを経て、人事になったのが29歳の時のこと。 以来、リクルートグループやアマゾンなど「圧が強め」「怒涛の採用」「あの会社の人たちエキセントリックですよね」な会社を中心に、採用系のキャリアを歩んできました。今はLINEでおもに採用・育成系の領域を中心に、なんだか大変だけどバタバタがんばっています。えらいぞ自分。 ちなみにプライベートでは こんな感じでバズったり

ども、LAPRASで働く中島（@nakashimayugo）です。 エンジニア採用において、採用背景や採用要件を深堀りするためは、プロダクトと開発チームについても理解を深める必要があります。 以前公開したこちらのスライドが好評だったので、少し細かい内容を記事にまとめました。かなりボリュームのある内容ですが、よかったら読んでみてください。 ■なぜプロダクト・開発チームについて理解を深めるべきか 採用背景や採用要件は、事業やサービスの課題から、プロダクトの課題、そして開発するチームの課題へと段階的におちてきて、「なぜ採用したいのか」という採用背景や、「どんな人を採用したいか」という採用要件が発生します。 一方で、これをすっ飛ばし、「事業成長に伴い」「人が足りないから」と曖昧な表現になりがちです。曖昧な表現では訴求力も弱く、ターゲットの設定も大雑把になってしまいます。 エンジニアが協力してくれる

エンジニアリングマネジメントトライアングル エンジニアリングの話をする前に、プロダクトマネジメントトライアングルという言葉と聞いたことはありますか？ それは、プロダクトマネジメントという言葉の定義、責任をまとめたグラフィックモデルのことです。これはプロダクトマネジメントを探求するために作られました。 かたやエンジニアリングマネジメントも組織やフェーズによって役割が違う、責任もさまざまということから、プロダクトマネジメントトライアングルと同じように思考を整理できるのではないかと考えました。*1 では、このトライアングルをエンジニアリングマネジメントで作るとどうなるのか。Engineering Manager Meetup の有志が作ったので紹介します。 エンジニアリングマネジメントトライアングル 中心にエンジニアリングを置いて、テクノロジー、プロダクト、チームでトライアングルを構成しています

こんにちは。ミクシィでスポーツやライブエンタメ関連の技術部長を担当している石井です。社内向けに書いている記事を少しづつ外部公開していきます。 大規模なサービス開発組織で働いていると、技術職スタッフにおいても、視座の高さを求められることが増えます。「視座の高さ」という単語は、曖昧で、入社していきなり「視座！視座！」と言われても、「えらい人がなんか言うとる」「わいには、まだ早い」くらいで、腹落ちしないと思います。しかし、給与体系にも紐づいていたりするので、給与が上がってくると、「視座をもうちょっとあげてもらわないとね…」と上長から言われれて「えー」となるかもしれません。私の考える「視座の高さ」と、なぜ専門職にも必要になるのかを説明しつつ、サービス開発と組織の関係について考えてもらう機会になればと思います。 私は、エンジニアリングを、単にプログラミングを書いたりすることで技術課題解決するというこ