マネージャーが持つべき究極のミッション | ベイジの日報
評価を高めて給与を上げよ マネージャーの仕事は、部下の仕事のレベルを高め、評価と給与を上げること。 他の人の考えは分からないが、私はそう考えている。年初の1on1では自分のミッションをそう伝えたし、アドバイスをしつつも問題定義や解決方法はセルフマネジメント型で自分で考えてもらうようにしている。時には「これやってみて」と具体的な課題を出すこともある。 相手がある程度成熟したビジネスパーソンだからこそ出来たことだと思うが、細かなアクションまでは追わないようにしている。自己管理は重要なスキルであり、自発的に変わる努力なしに成長は難しいと考えるからだ。マネージャー自身の仕事時間を確保するためにも、この方針は重要である。 マネジメントの基本的な考え方 上記指針の裏には、こんな考えがある。 成長意欲がない人を成長させることはできない できることは人が勝手に育つのを近くでサポートするくらい そのために相
マネージャー向けガイド: バーンアウトに立ち向かう方法 - The Asana Blog
この記事は英語、フランス語、ドイツ語、ポルトガル語、スペイン語でもお読みいただけます。 編集メモ: この記事は Quartz に掲載されたものです。 過酷なストレスは、今や仕事において身近な存在となってしまいました。去年、ナレッジワーカー (知識労働者) の 71% が一度はバーンアウト (燃え尽き症候群) を経験しています。さらに、メンタルヘルスの状態を「悪い」または「非常に悪い」と回答した労働者の割合が、5% から 18% に急増しました。ストレスレベルが「高い」または「非常に高い」と回答した割合は、42% に上ります。このようなストレスやプレッシャーの高まりは、明らかに時代の流れを感じさせます。 これは Asana「仕事の解剖学」インデックス 2021 報告書に基づいています。この調査では、回答者のほぼ半分が、バーンアウトの主な要因として過労を挙げています。つまり、問題の要因はオフィ
多様なメンバーが気持ちよく効果的に働けるチームにしていきたい
チームのパフォーマンスを高めるために、日々試行錯誤している方も多いと思います。私自身も、プロセス改善にこだわり続け、うまくいった部分もあれば、失敗を経験した部分もあります。今回は私のチームリーダーとしての失敗談と学びを共有したいと思います。 チームリーダーとしての責任Tebiki株式会社 エンジニアの二瓶と申します。私は Tebiki株式会社の Web アプリケーションエンジニアとして入社し、現在は tebiki現場分析 の開発を担当しています。また、チーム内では「チームリーダー」という役割 を担っています。弊社のチームリーダーのミッションはざっくりいうと「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。ここでいうチームとはプロダクトマネージャー、デザイナー、エンジニアを含む開発チームことです。これまで一人の開発者として手
書籍「スタッフエンジニアの道」の好きなところ、面白く感じたところ - 大好き！にちようび
原書と兄弟で肩を並べて 島田浩二@snoozer05さん訳の、8月26日発売「スタッフエンジニアの道―優れた技術専門職になるためのガイド」の感想のような記事を書きます。 スタッフエンジニアの道 ―優れた技術専門職になるためのガイド 作者:Tanya Reillyオライリー・ジャパンAmazon 翻訳レビューに参加した流れと、簡単な感想 今回、個人的には初めてとなる翻訳レビューに参加させてもらった関係で、物理本をご恵贈いただいた流れです。 まず圧倒的に信頼している技術書翻訳者*1であること、自分としても一応「VPoE」というタイトルで働いていたし領域的にも興味があること、翻訳レビューってやってみたいな〜！という憧れ の100点+100点+100点の合計1000000点！！！って感じの参加動機です。 snoozer05.hatenablog.jp で、しかも、参加が決定して書籍名を聞いたら「も
なぜ僕たちは 開発生産性指標を見ていないのか / Our Strategy for Development Productivity Metrics
開発の生産性を高める新たな視点〜開発生産性フレームワークSPACE〜 での登壇資料です
「失敗できる」を作り出すと開発組織は加速する
事業の成長においても、エンジニアの成長においても「何も学習できなかった失敗」ほど、無駄なことはありません。 組織として、どのように「失敗するか」を考え、どうやって「失敗できる」環境を作り出せるかは、事業・エンジニア双方の成長において欠かすことはできません。実現のためには、事業戦略・アーキテクチャ・組織文化といった幅広い部分に適応する視野を持っていなければならず、さらにビジネスサイド、エンジニアサイドともに密に連携しなければいけません。 失敗許容性の担保は、事業成長に効果的事業の成長（グロース）を思考のトップに失敗許容性を考えていきます。流れとしては以下の流れを踏んでいきます。 事業の可観測性を担保すると1ユーザーの行動まで可視化できるようにすることで事業のモデリング（構造化）ができるようになる。そうするとデータドリブンな開発ができるようになる。A/Bテストなどで細かいセグメントレイヤーに向
こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから
日本にアジャイルが普及しづらい本当の理由〜不確実性に向き合うマネジメント論〜 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。 アジャイルって何だ？ 「ウォーターフォールよりもアジャイルのほうがいいのか？」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日本国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。 ところが、世界各国に比べて日本のアジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと
スクラムを失敗させる51のアンチパターン - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? スクラムは基本的にはスクラムガイドに背くことで失敗しやすくなります。 そんな中でもよくあるアンチパターンと一言解説をまとめました。 スクラムマスター(SM)の失敗 SMがDevを兼任する スクラムマスターの仕事はそうなくならない どちらかの作業が片方の作業のボトルネックになる Devとしての作業量が不安定でベロシティを計画のために利用しづらくなる SMがPOを兼任する POとSMはそれぞれの責任に関する作業のみでボトルネックになりやすい 時にはPOの立場（プロダクト寄りの視点）とSMの立場（チーム寄りの視点）がコンフリクトを起こすことも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
