1on1の功罪について｜Real SmartHR リアスマこんにちは。SmartHR CEOの芹澤（@masato_serizawa）です。みなさん、1on1やってますか？ SmartHR社でも僕が入社した2016年頃から1on1をやっています。余談ですが、...
サポートとリード｜cba
サポートするときは「考えを聞かせてほしい」って言う。自分がどうしたいかを起点にするより、相手がどういうことに困っているかを起点にしてそこをサポートしたいから。 リードするときは「みんなの考えを聞かせてほしい」とは言いたくない。「僕はこう考えているんだけど、みんなはどう思う？」と聞きたい。自分がどうしたいか、が起点になるから。 サポートなのに「こうするべきですよ」って始めても押しつけになっちゃうし、…
エビデンスベースドマネジメントガイド（EBMガイド） | サーバントワークス株式会社
チームで受講することで、クイックにスタートできる研修メニューをご用意しています。チームの立ち上げ時期や、学び直し、認識合わせとしてご活用ください。
SQUARE ENIX OPEN CONFERENCEゲーム開発プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1 ©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4 ©SQUARE
2024年11月29日｜福島良典 | LayerX
(※ 社内報です。8-9割社内向けに書いています。この半年、LayerXの皆が取り組んでいたことがいかにすさまじいものだったか、困難を乗り越えてきたのかを公開することで、LayerXの皆が外に話しやすくするために公開します。今回やり遂げたことに自信をもってほしいです。) 2024年11月29日。LayerXにとって非常に歴史的な日になりました。私にとっても忘れられない日になりましたし、LayerXの皆にとっても忘れられない日になったのではないでしょうか。 LayerXの皆へこの半年間、すごく厳しいことを言い続けてきたと思います。本当にこんな目標達成できるの?と疑問に思ったことがある社員も少なくないと思います。 そういった困難を超えて、この目標を達成した皆が誇らしいです。 誰か1人が頑張ったという話ではなく、全員が頑張らないと絶対に達成できない目標でした。営業チームだけでなく、プロダクトチー
無自覚にメンバーの心理的安全性を奪っていた経験から得た学び
2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips
DMBOKに基づく「データマネジメント成熟度アセスメント」を実施してみた話 - レバレジーズ データAIブログ
はじめに こんにちは。レバレジーズのデータ戦略室の辰野です。いつの間にか5回目の投稿を迎えました。 今回は、私が2024年度上半期に注力した「DMBOKに基づくデータマネジメント成熟度アセスメントの実施」についてご紹介できればと思います。 レバレジーズでは初めての実施ということもありかなり苦労したので、これからデータマネジメント成熟度アセスメントを実施してみよう！と思われている方にとって、参考になれば幸いです。 ※ベースとなるDMBOKに関する情報は、既に多くの記事が出ているかと思いますので本記事では割愛させていただきます なぜやることになったのか 例えば、皆さまの周りでこんなことは起きていないでしょうか？ 「テーブル定義書はあるけど、実際のテーブルと内容が違う…」 「この指標の定義を知りたいけど、どこを見ればいいのか分からない…」 「このツールの使い方がどこにまとまっているか分からない…
自分のプロジェクトが炎上しない理由について整理する - HIRAエンジニアブログ
私は自慢では無いですがプロジェクトを炎上させたことがありません。 （炎上案件に途中から突っ込まれたことはありますが） 炎上案件の経験や上司からのアドバイス、書籍からの学びによるものが大きいです。 ただ、しっかり言語化して自分のものにしたいと思い、整理しようと考えました。 これを他のPLやメンバーに共有することで炎上プロジェクトが減っていくことを期待したい。 プロジェクトマネジメントする上で、意識していること、大事にしていること 小さな火を消し続ける → 課題管理の徹底、朝会でメンバーと課題を共有し、期日と優先順位を決めて通常タスクより優先して取り組む。 やらないことを決める → 顧客が求めてないこと、成果物に直結しない作業を極力やらない。（とくに過剰な品質管理、プロジェクト管理資料の作成など） 受注前の見積もりの段階で、案件リスクを見極めて、リスクを下げるか受注しない対応をとる → 見積も
エンジニアをプロダクトマネージャーたらしめたものは何か？ - ドワンゴ教育サービス開発者ブログ
みなさま、お疲れ様です！企画開発エンジニア の高瀬 (@Guvalif) です。 "企画開発エンジニア" という職種はあまり耳馴染みがないかもしれませんが、一般的には TechPM：Technical Product Manager として知られるような役割となります。ところで、プロダクトマネージャーってどうやったらなれるのか (なりたいと思えるのか)、どんな人に向くのかって、あまり分からなくないですか？ 本記事では、エンジニア・バックグラウンドからプロダクトマネージャーに 未経験転職 をした自身の事例を紐解きながら、再現性のありそうなファクターを探っていきたいと思います 🔍 ◆ この記事の位置付け 前半は ... プロダクトマネジメント職種への、モチベーションに関する考察 後半は ... あまり表に出ないように思える、プロダクトマネージャーへの未経験転職事例 (N=1) 教育事業本部に
SRE の考えをマネジメントに活かす / applying SRE ideas to management
SRE NEXT 2024 https://sre-next.dev/2024/
フォロワーからリーダーに転身するときに、何を意識するとうまくいきやすいのか - 下林明正のブログ
フォロワーからリーダーに転身するときに、何を意識するとうまくいきやすいのか？ということを考えていた リーダーとかフォロワーという言葉は意味が曖昧だけど、ここでは「自ら課題設定して解く人」と「渡された課題を解く人」くらいの意味 結論としては、まずはロジックツリーで課題を分解する癖を付けてくれ、で良いような気がしてきた。ロジックツリーが以下を満たすからだと思う 一番粒度の大きい課題設定としては「期待を満たし、上回る」で良いと思うので、実際にやって欲しいことはその具体化と解消 扱う課題がフォロワー時代と比べて曖昧で、難しく、正解のないものになっていくので、そのまま扱おうとするのではなく分解して単純化していて欲しい 分解した課題に優先度を付けて対処するときに、なぜその優先度にしたのか他の課題と比較して説明できるようになっていて欲しい どんな比較をしたのか分からないと、どれくらいちゃんと考えたのか分
エンジニアリングマネージャとして入社した最初の取り組みとして、エンジニア全員(およそ100人)と1on1をしました - だいくしー(@daiksy)のはてなブログ
はてなにエンジニアリングマネージャとして入社して2ヶ月と少し経ちました。 マネージャとしての「最初の100日」もいよいよ終盤です。 note.com 入社して最初の取り組みとして、およそ100人のエンジニア全員との1on1を実施しました。 なぜ全員とやろうと思ったか イギリスの人類学者であるロビン・ダンバーによって提唱された「ダンバー数」というものがあります。 これは、人間が安定的な社会関係を維持することができる人数の認知的な上限について提案された数字です。大雑把に説明すると、人間が相互に認識しあって社会関係を築ける人数はおよそ150人程度、というものです。 要するに1つの組織でお互いに顔見知りの状態で活動ができる集団の人数上限が150人前後であるということです。 このエントリを書いている時点で、はてなのエンジニアはおよそ100人ほどいます。つまり、はてなのエンジニア組織は、まだダンバー数
エンジニア運用工数40%削減！Bill One における運用改善のとりくみ - Sansan Tech Blog
Bill One Engineering Unitの田上です。運用改善と題したプロジェクトによって、エンジニアの運用工数を半年で40%削減することに成功したので、今回はその取り組みをご紹介します。 背景 Bill One のエンジニアリング組織では、フルサイクルエンジアリングで開発と運用を行っており、開発者自身が運用対応（本番環境で発生したエラーの調査・対応、ユーザからの依頼・問い合わせの対応など）を行っています。 エンジニアが自身の開発したプロダクトへのフィードバックを迅速かつダイレクトに受け取れる非常に良い方式ではあるのですが、その対応工数があまりにも多くなりすぎて開発工数が逼迫するようになっていました。 その状況をどうにかするため半年の期限付き特命チームとして運用改善チームを立ち上げることにしました。 立ち上げ 組織内のフラストレーションの高まりを背景に、2名のエンジニアが新たなチー
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
正直であることから始める / Start by being honest.
RSGT 2024 Day 2 スポンサーセッション
2023年の振り返り、そして転職
今年も特にアウトプットはできていないですが振り返りをすることにしました。理由はなんとなくタイトルで察するかと思います。 2022年10月にスリーシェイクに転職したわけですが、そこでやると決めていたのは情シス人材の育成でした。 会社として必要な取り組みでもありましたが、自身が今後のキャリアに必要と考え取り組んでいた育成について振り返ってみます。 また、成果について書くとメンティーへのフィードバックのようになりそうだったので自身が何を考え、行動したのかという点にフォーカスして振り返えることにします。 育成の目標 メンティーは年齢も情シスのキャリアもジュニアクラスでした。それを踏まえてどういった育成をすべきかと迷いましたが、漠然と「情シスのマネージャークラスを担える人材に育てる」ということは考えていました。 人材育成のノウハウがまったくない状態からのスタートでしたが、できるかどうかではなく大きな
エンジニアリングマネージャーの4領域はEM以外のメンバーでも濃淡はあれど意識する必要がある - stefafafan の fa は3つです
株式会社はてなでテックリードとして仕事をしている id:stefafafan です。今回は自分が個人的に考えてきたことを記事としてまとめてみます。 エンジニアリングマネージャーの4領域とは EMでなくとも4領域を意識する必要がある テックリードの場合 スクラムマスターの場合 Individual Contributor (IC) の場合 ロールを持たないソフトウェアエンジニアの場合 結局エンジニアリングマネージャーの役割とは 終わりに エンジニアリングマネージャーの4領域とは ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。 テクノロジーマネジメント アーキテクチャやテストなど プロジェクトマネジメント 見積もりやアジャイル開発など プロダクトマネジメント ビジョンや仮説検証など ピープルマネジメント メンバーの成長やメンタリングなど これらの4つの領域は @hiroki
こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
1行のコードから社会課題の解決へ： EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
現代的システム開発概論 2024
