役員の思考って何が必要？｜Akira Uehori｜LayerX
こんにちは、LayerX バクラク事業部の上堀（うえほり）と申します。 2024/4/1付にて、セールス担当の部門執行役員に選任いただきました。 選任とは直接的には関係がないものの、「部長から役員になるための考え方」を理解するということで、代表の福島さんから直接全8回のプログラムを去年から行なってもらっており、その内容についての概略を共有します。 一般的に新しく入社した方や新任マネージャー向けの研修はありますが、「役員ってそもそもどういう考え方をするの？」ということをプログラムとして用意しているスタートアップは多くはないのではと思っております。 かつ2on1での少人数の実施だったので、リアルなことや率直な悩みをぶつけることができたので非常にいい機会でした。 なぜやるのか？LayerXではマネジメントを下記に区分しています。 戦略マネジメント 組織戦略策定・浸透支援と、戦略実現に向けた自組織
理想のプロダクトマネジメントとは、まつもとゆきひろがオープンソース流を解説
出典：日経Linux、2022年9月号 pp.135-141 「まつもとゆきひろのプログラミング質問箱」を改題、編集 （記事は執筆時の情報に基づいており、現在では異なる場合があります） Rubyの創造者、まつもとゆきひろがプログラミングに関係あったり、なかったりする質問に独自の視点で回答します。 ［ソフトウエア開発］ Q.まつもとさんの経験から考える理想のプロダクトマネジメントはどのようなものですか。 オープンソース流？ 最初にお断りしなければならないことがあります。キャッチーさを狙って、今回のタイトルを「オープンソース流」と付けましたが、実際には「オープンソース」の定義と今回解説するプロダクトマネジメントとは直接的な関係はありません。 「オープンソース」の定義とは特定条件を満たすライセンスが付与されて配布されているかどうかだけです＊1。開発者の意図や、開発体制は「オープンソースの定義」に
Engineering Managerという役割がなぜわかりづらいのか - KAKEHASHI Tech Blog
カケハシでVP of Engineeringをやっています、ゆのん(id:yunon_phys)です。僕はEngineering Manager(EM)とは何かについて、かれこれ5年ぐらいEM.FMというPodcastや、ブログを通じていろんな発信をしてきました。そうすると色んな質問を各所から受けるわけなんですが、一番聞かれる質問第一位は、「結局EMって何する人なんですか？」 です。一口にEMって言っても、なんか人によって得意な領域が違っていたり、大事だと思うポイントがバラバラなので、この疑問を持つのはそりゃそうだよなあ、とは思います。というわけで、このエントリーではEMは何する人なのかを明らかに・・・と思ったのですが、一言で語るのはやっぱり難しいなと思っています。なので、なぜ僕がEMという役割を説明するのが難しいと思っているのか、を書いていきます。 マネージャーの本質はチームの足りてない
育休前に振り返る、私がEMとして大切にしている考え方 - STORES Product Blog
はじめに こんにちは、テクノロジー部門プロダクト基盤本部基盤グループでEM（エンジニアリングマネージャー）をやっている松本 (@upinetree) です。普段はID基盤などを作ってます。この度子供が生まれ、6ヶ月間の育休を取得させてもらうことになりました*1。育休に入るにあたって、ありがたくもチームメンバーの池田さん (@yusuiked) が私の育休中のEM業務の代打を引き受けてくれました。大感謝です。ここ数ヶ月かけて引き継ぎを進めてきて、無事バトンタッチできました。 引き継ぎは職種問わず難しい仕事のひとつですが、EMの引き継ぎは関わっている人や仕事、抱えている情報が多い点において難しく、悩みながらやってきました。最初はざっと業務内容を洗い出し、池田さんと一緒にEM業務を行いながら引き継ぎを進めるプランを考えましたが、それだけでは表面上の引き継ぎに留まってしまいます。また、上司の大橋さ
「納期コミットのオーダーは結果的に納期を遅らせること」を逆手にとる - @i2key のBlog
これは Recruit Engineers Advent Calendar 2022 - Adventarの13日のエントリーです。（書いているのは21日です。） 1. 納期コミットのオーダーは結果的に納期を遅らせる 先日、興味深いエントリーを読んだ。 bufferings.hatenablog.com これにつてはほぼ同じようなことを社内のtimesチャネルでも会話しており、スケジュールへの向き合い方についてメタ的理解に昇華させたい。 我々が納期をコミットしなさい、確実に守れる日を教えてと言われたときにやることは、、、 確実に納期を守れるように、余裕をみる。である。 ------------------------------------------------------------ ■：実作業日（問題なければできそうな工数） □：バッファ日（例えば50％の確率で問題おきたときに使う予
7年の体験から書く技術組織のマネジメント（前編） - エス・エム・エス エンジニア テックブログ
技術組織のマネジメント @sunaot です。エス・エム・エスで技術組織のマネージャーをしています。入社時点から技術組織全体のマネジメントを担う役割でスタートし、今年で７年が過ぎました。 「エンジニアリングマネージャー (以下、EM) の仕事とはなんですか？」と聞かれたときにその定義を答えられるでしょうか？ 「1on1をすること」「メンバーの育成をすること」など、これは EM の仕事だという要素は挙げられても、全体像を言える人は中々いないのではないかと思います。そうしたときに頼りになるのは書籍ですが、EM に特化して仕事の全体像を語った書籍というのは日本語ではなかなかありませんでした*1。 EM の仕事単体でその全体像を説明するのが難しいのにはそれなりの理由があります。この記事では、全体像を語りにくい EM の仕事というものについて、技術組織のマネジメントという視点から全体を説明し、その中
組織のサイロ化を前提としたチーム構成、育成の仕組みとは？はてなとChatworkのエンジニアマネージャーがリモートワーク下のマネジメントを語る
組織のサイロ化を前提としたチーム構成、育成の仕組みとは？はてなとChatworkのエンジニアマネージャーがリモートワーク下のマネジメントを語る 近年、メガベンチャーの増加やスタートアップの大規模調達などによって、エンジニア組織の規模も増大、組織も複雑化するなか、エンジニアマネージャーやテックリードなどの重要性がますます高まっています。 2022年3月24日に開催した『onkさんとだいくしーさんに聞くエンジニア組織づくり最前線vol.5』では、株式会社はてなの大仲能史さん、Chatwork株式会社の粕谷大輔さんをお招きし、マネージャーとしてのミッションやリモートワークにおける「サイロ化」との向き合い方、マネジメントの面白さと難しさ、プレイヤーとの両立など多岐にわたるトピックを語っていただきました。 モデレーターはファインディの取締役CTO佐藤が務めます。 パネリスト 大仲 能史さん/ @on
調整の心得 - クックパッド開発者ブログ
会員事業部の森田です。 対象と内容 この記事は、クックパッドと同じような200～300名規模の組織で働く、「最近調整が多くてコードを書く時間がないなぁ」と思い始めた30代エンジニアを対象として、日々の調整の負担を減らすための「考え」と「行動」を整理し、まとめたものです。 組織における分業と調整 組織に所属する人たちは協力して組織目標の達成を目指します。みんなで同じことをしてもしょうがないので、必然的に役割を分担(分業)をします。分担した仕事はなんらかのタイミングで統合する必要があります。その統合が調整です。つまり分業と調整はセットです。じゃどういう分業があるのかといえばそれは組織構造によります。今回は私達が採用している事業部別組織下*1 での調整の話をします。 分業の種類 事業部別組織では垂直と水平の2つの分業が存在します。それぞれに少し毛色の違う調整が発生するわけですが、いくつかのことを
【後編】開発内製化の5年の軌跡。「消耗戦の悪魔のループ」をどう乗り越えたのか - エス・エム・エス エンジニア テックブログ
エンジニア組織の内製化を進めるには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。エス・エム・エスは2015年よりエンジニア組織の内製化に取り組んできました。そのプロセスとそこで得られた反省や学びを技術責任者の田辺に聞いたインタビューの後編です。 tech.bm-sms.co.jp 前編では、2015年の入社から1年半くらいの間にやったことを話しました。リサーチから始めて会社の特性を理解しにいくということと、小さく始めて検証をするというスタートをきり、小さな新規サービスの立ち上げに上流からかかわって、アジャイルな開発がうまくいったということでした。 エス・エム・エスは当時40近い数のサービスを展開していたのですが、最初の1年半で内製化を進める主要なサービスと注力をせず終了するサービスや CMS 化で開発能力
予測型マインドセットと適応型マインドセットの違い、アジャイル思考の本質 | Social Change!
多くのマネージャや経営者に会ってきた中で、マネジメントの手法や組織のあり方の背景には、大きく二つの流派があるのではないか感じています。 一つは、未来の目標を決めて突き進もうとする考え方。もう一つは、将来は予測しきれない前提に立ち、変化に対して柔軟であろうとする考え方。 この本質的な部分で考え方（マインドセット）が合っていないと、世の中にある多くの手法や制度を真似てもうまくいかない。これは、どちらが正しいといった話ではなく、違いを認識することが重要ではないかと考えて整理してみました。 本稿では、この２つのマインドセットを「予測型マインドセット」と「適応型マインドセット」と定義して、その違いについて深掘りをしてみましょう。 未来の想像を先にするか、現在が続く先に未来があるか 「未来の働き方はどんな風になっていると思いますか？」 先日、とある大企業のイノベーションを担う部門の人たちから、リモート
体制を考えるときに意識していること - id:onk のはてなブログ
1on1 で伝えたので外にも書いておく。 プロダクトやチーム、メンバーのフェーズ まず現状分析。 自プロダクトは PPM で言う花形、金のなる木、問題児、負け犬のいずれに当たるのか 勢い MAX でめっちゃ盛り上げるのか、地味に役割を達成するのか。自チーム全集中なのか他チームのフォローに回るのかみたいな方針が変わる 自チームは エラスティックリーダーシップ で言うサバイバルモード、学習モード、自己組織化モードのいずれに当たるのか チームを改善しなければいけないのか、プロダクトだけを見ていて良いのか。チームで改善できるのか、リーダーや外部の強い意志が必要なのか 各メンバーは、期待される役割において SL理論 で言うとどのフェーズなのか 指示的行動が必要だとマイクロマネジメントすることになり、マネージャ/メンター的な人/行動を増やす必要がある 役割を網羅しているか こういう軸で考えていることが
「無人化システム」を駆逐する組織マネジメントとエンジニアリング
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
私が仕事をしてきた中で「最も合理的」と感じたリーダーの話。 | Books&Apps
もうずいぶん前のことになる。 あるIT業の業務改善プロジェクトに、私はいちメンバーとして参加した。 その会社のプロジェクトメンバーは全部で8名。期間は約9ヶ月だった。 経営陣肝いりの、それなりに大きいプロジェクトである。 そのため、プロジェクトマネジャーは、掛け値なしに優秀であった。 指示は的確で、果敢に新しいことにチャレンジするが、無用なリスクは取らず、守りが堅い。 メンバーとの関係も付かず離れずとバランスが良く、理想的な人物だった。 だが経験的に、プロジェクトメンバー全員が優秀であることはほぼない。 政治的な理由からか、教育効果を期待してなのか、リストラ予備軍だからなのか、それとも単なる人手不足なのか。 理由は様々だろうが、プロジェクトメンバーの中に、必ず２，３名はボンクラが含まれているのである。 そして、プロジェクトは一定の期間内に成果を出す、という厳しい制約があるため、無能の扱いを
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
失敗したエンジニア組織施策としくじりの反省｜nottegra@在宅勤務
前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ
「88点の仕事を、88点って言っちゃダメ」つんく♂が語り尽くす“伸びる若手”の共通項｜新R25 - シゴトも人生も、もっと楽しもう。
社会人になって数年たったR25世代のビジネスマン。後輩ができたり、ちょっとしたチームのリーダーを任せられたりする機会も増えてきます。 でも、いわゆる「マネジメント」なんてしたことないから、どうしたらいいのかわからない！ 今回は、そんな悩みを、この超大物に相談する機会に恵まれました。 【つんく♂】1968年生まれ。大阪府出身。1992年、「シャ乱Q」でデビュー。「シングルベッド」「ズルい女」「いいわけ」などのヒット曲を発表する。1997年より「モーニング娘。」のプロデューサーとして活動。その後、「ハロー！プロジェクト」にて多くのグループのプロデュースを務める。2020年には絵本『ねぇ、ママ？僕のお願い！』（双葉社）をプロデュース。また、オンラインサロン「つんく♂エンタメ♪サロン」を主宰するなど、さまざまな活動を続ける プロデューサーとして、モーニング娘。をはじめとする、数多くの才能を見出して
プロフェッショナルチームのマネジメントについて｜Nakamura Hiroki / 中村 浩樹
LINEには多面評価的な制度があって、半年に一度、一緒に働いている同僚やメンバーの方からフィードバックをもらいます。その中に、”独特なマネジメントスタイルで頑張っておられる”みたいなコメントがちらほらありました。直接話ししている時にも、”(マネジメントの)やり方にオリジナリティありますよねー”というフィードバックもたまに頂きます。 今、私がいるLINEのAI事業にいる人たちは、スペシャリストでかつ主体性の塊みたいな人ばかりなので、リーダーやマネージャーがいなくても、それぞれの方が持つ最大限の力(100%)のアウトプットは自然に出ると思います。 そんな中、LINEのAI事業のリーダー、マネージャーのミッションは、それぞれの人が持つ100%の力を、どうやって組織の力で200%、300%、それ以上にあげるか、です。一方で、LINEのAIプロダクトの構造は複雑で、それが故にそれに関わる人達の専門性
日本CTO協会、「DX Criteria(基準)」第一弾を公開！2つのDX推進に向けて各社が無料で自己診断できるように
TOP > プレスリリース一覧 > 「ビジネス全般」のプレスリリース > 日本CTO協会、「DX Criteria(基準)」第一弾を公開！ 2つのDX推進に向けて各社が無... 日本CTO協会、「DX Criteria(基準)」第一弾を公開！ 2つのDX推進に向けて各社が無料で自己診断できるように デジタル時代の「働き方改革」を加速化し、日本を世界最高水準の技術力国家へ 一般社団法人日本CTO協会(本社：東京都渋谷区／代表理事：松岡剛志、以下：日本CTO協会)は、2019年12月11日(水)、国内企業のDX推進に向けた基準「DX Criteria」第一弾を公開いたしました。DX Criteriaは誰でも無料で活用することができ、各社が自己診断を通して現状を把握し、指針を立てたり、ベンチマークした企業との違いを数値で把握したりすることが可能です。日本CTO協会はDX Criteriaの普及を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.amazon.co.jp/dp/4047914290?_encoding=UTF8&psc=1&ref_=cm_sw_r_cp_ud_dp_K2DFT6S3HV88YF9ZX4QC
「問題から目を背けず取り組む」 �一休の開発チームが6年間で学んだこと
