タグ

managementに関するhs_hachiのブックマーク (34)

  • 組織規模とCTOの求められる役割の変化に関する雑記|Matsumoto Yuki

    CTOA Advent Calendar 1日目のバトンを受け取りましたので、1日目となる今回は、CTOに求められる役割の変化について、自分のこれまでの振り返りを兼ねて記事を書いてみようと思います。ちなみに今週はマガジンの連載をこちらの記事に代えさせていただければと。 普段はこちらのマガジンでソフトウェアと経営についてつらつらと書いています。ご興味ある方、年末の時間のあるときにでもご一読いただければ幸いです。 はじめにこの10年、エンジニアとしてのキャリアをスタートして今に至るまで、一桁人のスタートアップから1000人近い規模の開発組織を抱えた大企業まで様々な規模の組織のCTOを経験してきました。おおよその流れとしては、学生時代に小さなスタートアップを3社、その後Gunosyにて一桁人から60人前後の開発組織、現在はDMMのグループにて合計1000人弱の開発組織にてCTOをしています。 C

    組織規模とCTOの求められる役割の変化に関する雑記|Matsumoto Yuki
  • 社内PlatformチームのProduct Management

    現職においてPlatform チーム(社内基盤チーム)として働き始めて2年近くがたった.このチームにおいて自分はTech Leadをメインに努めてきたが,同時にPlatformの「どのような機能を」「どのような優先度で」作るか? を決めるProduct Manager的な役割も果たしてきた(ちなみにTech Leadに関してはメルカリのテックリードが学んだ、HowよりWhyを重視することが大切なわけ で少し話した).これは何度も失敗しながら悪戦苦闘しつつやってきたが自分たちなりのフレームワークをつくり実際に回すことができている. 未だに試行錯誤しているのでここで書いていることが正解だとは思っていないが,今後同じようにPlatformチーム的なことを始めるひとに向けて現状自分たちがどのようにやっているのかについて簡単にまとめておく(他の会社がどのようにやってるのかも聞きたいのでもし同じような

  • はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog

    こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今回ははてな社内で行っているエンジニアメンター制度について紹介したいと思います。 エンジニアメンター制度概要 はてな技術グループでは、エンジニアメンター制度というものがあります。どのようなものかというと 新卒・中途、入社年数の長さに関わらず、全てのエンジニアには、必ずメンターが一人付く 基的にはチーム外のシニアエンジニアと呼ばれる人たちがメンターとなる シニアエンジニアについては はてな技術組織2016 - Hatena Developer Blog も参照 メンターは、目標設定・毎月の1on1・評価を通じて、メンティーの悩みの早期発見・解決、成長支援をおこなう またメンターは評価時期に、「専門スキル」という観点でメンティーの評価を行う という制度です。 それではこれから、どのような目的でメンター制度を導入してい

    はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog
  • 経営視点から見たPdM、PjMの重要性 / Importance of PdM and PjM in Business Management

    不確実性への対応が求められる昨今、各社競争優位を確保するためにユニークなプロダクトや多様性のある強い組織へのニーズはますます高まっています。それらをリードするPdM、PjMの重要性はますます増すばかりです。キーノートセッションでは、経営視点からみたPdM、PjMの重要性を、事業的側面だけではなく、組織的側面、特に社員のEVP構築や採用まで含めた広い範囲で話せればと思います。

    経営視点から見たPdM、PjMの重要性 / Importance of PdM and PjM in Business Management
  • VPoE handbook | エンジニア組織のマネジメントに悩んでいた三年前に戻れるなら渡したい。VPoE handbookを書き終えました (目次&サマリ付)|Takayuki Shimizu

    (この記事はVPoE handbookの目次&サマリパートです) 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 (この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。) VPoE handbookを書こうと思った理由まずはなぜ書こうと思った?の問題意識から。 この記事にあるように、三

    VPoE handbook | エンジニア組織のマネジメントに悩んでいた三年前に戻れるなら渡したい。VPoE handbookを書き終えました (目次&サマリ付)|Takayuki Shimizu
  • どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング

    Platform チームの@deeeeeeeetです. Platform チームは2年前にMercariがMicroservicesの移行を始めたときに一緒に立ち上げられたチームです.Platform チームはMicroservicesを動かすための基盤や開発や運用のためのツールセットなど提供しています.立ち上げ時は自分を含めて2-3人で始まったチームですが2年が経ち10人を超えるチームにまで成長しました. チームのメンバーが増えるほど1チームとして動くには限界がきており,またMicroservices化が進めば進むほどチームの負う責任範囲も広くなりCognitive load (認知負荷) も高くなっていました.これらの課題を解決するために組織変更を行い,Platform チームを複数の専門性に特化したチームに分割しました. 記事ではチームのデザイン,チームが分離しても独立性を保ちつつ

    どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング
  • 専門職と視座

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

    専門職と視座
  • Google re:Work - マネージャー

    イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。

    Google re:Work - マネージャー
  • 重大事故の時にどうするか?|miyasaka

    ヤフー時代の部下から突然メッセンジャーが。 「以前宮坂さんが緊急対応時に残して頂いた言葉を今度セミナーで使っていいですか?」 と。 リーダーの仕事はいっぱいあるけどなかでも大きな仕事の一つは重大事故の発生の時の陣頭指揮。平時は部下で回せるようにするのがマネジメントだけど、危機の時まで部下にまかせるわけにはいかない。 お恥ずかしながらヤフー在職中の22年で何度か重大事故を起こし関係者の人に多大な迷惑をかけてしまった。その度にその陣頭指揮をとった。 結果的にヤフーのなかでもっとも深刻な事故対策をやった人の一人じゃなかろうか。そのなかからノウハウ的なものがたまってきたものを部下にメモしておくってあげたものを彼は覚えていてくれたらしい。 彼いわく危機対応の時にすっごく役にたって指針になったといってくれて送ってくれた。 ひょっとしたら他の人にも参考になるかとおもって(若干訂正してますが)ここに残して

    重大事故の時にどうするか?|miyasaka
  • 1on1を上達するために

    エンジニアの成長を支える1on1ワークショップ

    1on1を上達するために
  • カルチャー崩壊と再構築。 Goodpatchが取り組んだ組織デザインの2年間 - 前編|Naofumi Tsuchiya / Goodpatch

    会社組織を運営していく上で企業文化の重要性は多くの経営者が理解している事かと思います。僕ももちろん起業前から企業文化が一番の差別化ポイントになると理解し、会社運営をしておりました。 創業期から毎日の朝礼、朝礼ではLTと英語でのカンバセーション、毎週月曜日のプロジェクトレビュー、オープンでフラットなコミュニケーション、グローバルコミュニケーション、チームでデザインする、デザインに対してのディスカッションなど、多くのカルチャー醸成のために多くの取り組みを行ってきました。 しかし、僕の経営するGoodpatchは約2年半ほど前に組織とこれらのカンパニーカルチャーがほぼ全て崩壊するという事態に陥りました。 この2年間は自分にとってGoodpatchの失われたカルチャーを取り戻し、再構築するために奮闘した期間でした。 組織の急成長フェーズに起こる事例だと思うので、起業家やこれから組織を作っていく人達

    カルチャー崩壊と再構築。 Goodpatchが取り組んだ組織デザインの2年間 - 前編|Naofumi Tsuchiya / Goodpatch
  • 2つのDXと技術的負債-YAPC Tokyo 2019

    エンジニアリング組織論への招待」はビジネス書としても技術書としても評価された。これら二つは別のことなのだろうか。それをも同じものなのだろうか。 この講演では技術者体験DXと企業のデジタル化のDXの2つを橋渡ししていく。 「エンジニアリング組織論への招待」の骨子である、不確実性を恐れる人間の能を乗り越えて、それらに向き合える組織を作ることによって生産的なチームができる。 そして、ソフトウェアを作るとは、「認識に齟齬がないほど明晰な言語に書き下すこと」であれば、これは情報の非対称性を減らすというコミュニケーションそのものだろう。 このコミュニケーションのコスト構造をそのまま、システムの構造に当て込んでしまうというのを「コンウェイの法則」と呼ばれている。 組織構造の問題が、システムへと転移して、コントローラビリティを喪失すること。これが技術的負債の真実であるなら、これはありふれた経済現象であ

    2つのDXと技術的負債-YAPC Tokyo 2019
  • エンジニア組織の責任範囲の透明性をRACI図で高めてみた - Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

    こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2018 の22日目の記事です。 前日は@kackytwさんのDQNの学習速度を改善するでした。 Engineering Managerのjob descriptionを共有する流れ 近年、Engineering Manager(EM)業界が賑わってきています。特に2018年は非常に活発化した年でした。書籍としては、エンジニアリング組織論への招待とエンジニアのためのマネジメントキャリアパスという名著が生まれました。また、Engineering Manager Meetupが3回開催され、Slack workspaceでは12/22時点で268人となっています。EMのためのPodcast EM.FMも誕生し、総再生回数が10,000回を突破するなど、多くの方から注目を集めていま

    エンジニア組織の責任範囲の透明性をRACI図で高めてみた - Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)
  • 「階層がないフラットな組織」より「階層があり、社員が自分の役割を越えて動き回る組織」のほうが強い説、を考える。|面白法人カヤック 人事部

    「階層がないフラットな組織」より「階層があり、社員が自分の役割を越えて動き回る組織」のほうが強い説、を考える。 まとめ・階層がない組織にも、非公式な階層はできている。 ・平時は組織の階層を活かして動き、有事は階層を気にせず自分の役割を超えて動くような社員を増やすのが良さそう。 ・「自分の役割を越えて動く」を社員に学習させる方法があるはず。そうしないと、結局組織が硬直化する。 ・「役割を超えて動く方法」を学習してもらうために、新入社員にしってもらうことをまとめてみた。階層がない組織にも、非公式な階層はできているカヤック社外人事部の神谷さんが行った勉強会の資料から抜粋してみよう。 フラット化の課題 ・ 階層は今も基的構造のままであり、マネージャーに権威があり、公式的な階層が無い場合でも隠れた階層が存在すること、階層を受け入れ、それを調整しなければ組織における仕事が進まないことを指摘(Levi

    「階層がないフラットな組織」より「階層があり、社員が自分の役割を越えて動き回る組織」のほうが強い説、を考える。|面白法人カヤック 人事部
  • 心理的安全性ガイドライン(あるいは権威勾配に関する一考察) - Qiita

    はじめに 「心理的安全性」とは、「対人リスクを取っても問題ないという信念がチームで共有されている状態」であるとか、「自分のキャリアやステータス、セルフイメージにネガティブな影響を与える恐れのなく、自分を表現し働くことができること」というような定義がなされています。 心理的安全性という言葉はともすれば、ただ快適で居心地のよい職場という意味にも聞こえます。そのため、ぬるま湯で緊張感のない関係性のことを「心理的安全性が高い」と言うのではないかと考えても不思議はありません。 そのため、友人関係のようにプライベートの時間を長く共有する関係になることが、心理的安全性が高いのだろうと考え、飲み会やバーベキュー、慰安旅行などを企画してみたりとプライベートでも遊ぶ機会を増やそうと考える人もいるでしょう。 いわゆる「アットホームな会社です」とアルバイトの求人記事に書かれているような状態です。こういった求人内容

    心理的安全性ガイドライン(あるいは権威勾配に関する一考察) - Qiita
    hs_hachi
    hs_hachi 2018/12/11
    “権威勾配を小さく” というのは少し気になった。決断・判断するタイミングで勾配を小さくするのはあまり良くないのでは?と思うしある程度あるけど心理的安全性を向上することはできないものだろうか
  • 「最近の若い奴は」と言う管理職は仕事をしていない――『ジャンプ』伝説の編集長が考える組織論 (1/5) - ITmedia ビジネスオンライン

    「最近の若い奴は」と言う管理職は仕事をしていない――『ジャンプ』伝説の編集長が考える組織論:『Dr.スランプ』で「マシリト」と呼ばれた男・鳥嶋和彦の仕事哲学【後編】(1/3 ページ) 『ドラゴンボール』の作者・鳥山明を発掘したのは『週刊少年ジャンプ』の元編集長である鳥嶋和彦さんだ。漫画界で“伝説の編集者”と呼ばれる鳥嶋さん。今回は白泉社の社長としていかなる人材育成をしてきたのかを聞き、鳥嶋さんの組織論に迫った。 『ドラゴンボール』『Dr.スランプ アラレちゃん』――。漫画家・鳥山明さんの名作は今や国内にとどまらず海外の市場を席巻している。その鳥山さんを見いだしたのが2018年創刊50周年を迎える『週刊少年ジャンプ』の元編集長・鳥嶋和彦さんだ。鳥嶋さんは「Dr.マシリト」というキャラクターで『Dr.スランプ』にも登場している。 第3回目の【後編】では、鳥嶋さんが漫画雑誌の現状をどのように見て

    「最近の若い奴は」と言う管理職は仕事をしていない――『ジャンプ』伝説の編集長が考える組織論 (1/5) - ITmedia ビジネスオンライン
    hs_hachi
    hs_hachi 2018/10/30
    ふむ...考えさせられる
  • 成果で評価していくということ - そーだいなるらくがき帳

    最近、この話をすることが多いのでブログに個人的な意見をまとめる。 まず成果主義と結果主義は違う。 勘違いされてる人が多いけど成果主義は成果とそれまでの過程を踏まえて評価する。 結果主義はその言葉の通り、結果のみで評価する。 そのため売上を至上と置いてる営業の評価をする場合などは結果主義はわかりやすい。 個人的な意見では結果主義は嫌いではないし、スポーツなどは完全に結果主義だ。 それは置いといて、多くの会社は成果主義であるし、だからこそちゃんと成果で評価すべきだ。 その点について次のようにまとめる 成果を評価するということ 成果を評価するためには 目標を設定すること と 行動すること が必要だ。 行動した結果、成果が生まれ、そしてその成果が目標を達成したかを評価する。 結果主義であれば目標に対して、成果がどの程度達成したかの差分だけで評価する。 成果主義はその過程も評価するので達成した上で、

    成果で評価していくということ - そーだいなるらくがき帳
    hs_hachi
    hs_hachi 2018/07/17
    同意だなー割り込みタスクと言っていいのかどうかわからないけど、目標にない成果を出してくれたときはどう評価してるんだろう?まぁマネージャがちゃんと目標にいれなよという気はするが。
  • バス因子が自分で バス因子を脱するための方法

    Rails Developers Meetup 2018: Day 2 あなたのプロジェクトには、バスに轢かれたらプロジェクトが破綻する人が何人いますか? 自社サービスを運営している組織において、サービスのスケールのためには開発組織のスケールが必要不可欠です。 急成長中である日初の Ruby on Rails で作られているフリマアプリ フリルを開発するFablicのエンジニア組織において、バス因子である私が、組織のスケールのために脱バス因子するために同僚と行ってきたことを成功失敗両事例お話します。

    バス因子が自分で バス因子を脱するための方法
    hs_hachi
    hs_hachi 2018/03/27
    似たような状態なのでわかる
  • デザイナーを伸ばす過程で大切にしたこと|Nobuo Suzuki

    1年目のデザイナーに教えたほうがいいことや、デザイナーを育てるとはどういうことなのか。 自分のことはどうにかなってきた20代中盤。「デザイナー育ててね」と突然言われても何から始めればいいのかもよく分からなかったですし、どうやってアドバイスしたらいいかも分からなかった当時、デザイナーの育成に関する記事があまりに少ない印象だったので、同じような境遇の方の役にたてば嬉しいです。 ※この記事は、2017年4月にMediumで公開した記事を加筆・転載したものです。*** 人が課題を感じて初めて成長するWe don't know what we don't know. (分からないことが分からない。)突然ですが、他人に言われた時よりも自分で課題を認識できた方時の方が腹落ちしませんか? 教える側は、相手が分かっていないところが分かるのですが、当の人は「分からないことが分からない」状態なのです。でも、

    デザイナーを伸ばす過程で大切にしたこと|Nobuo Suzuki
  • スタートアップのデザイン責任者がやるべきことまとめ|坪田 朋

    最近、相談を受ける事が多いデザインマネージャーの役割を経験をもとに書き出してみました。長いですが、迷った時の辞書代わりに使ってもらえるとありがたいです。 ここでは会社の規模が30名以上、デザイナー5名程度を超えた組織をイメージしてます。ユーザー体験に責任を持つサービスデザイン責任者と組織責任者の話は混同しないほうが良いので、今回は組織責任者にフォーカスしてます。 全体のストーリーはこのスライドで掴めると思いますが、もう少し具体的に実行した事などをリスト化したので参考になればと思います。 デザイン責任者として実行した事まとめデザイン責任者の仕事は何かを学ぶために行動してみた ・実績を上げてる会社へ一週間研修に行かせてもらい、成果をあげてる理由を分析して、100ページ位のレポートを作った。 ・池田さん、土屋さん、深津さんなど有識者に相談して感覚を掴んだ。 ・それらの行動は自分自身の勉強にもなっ

    スタートアップのデザイン責任者がやるべきことまとめ|坪田 朋