抽象度の高い仕事の進め方 - Konifar's ZATSU
仕事をしていると、だんだんと抽象度の高いことを任されるようになる。 たとえば、方針も明確な小さな修正タスク => 修正方法がいくつか考えられるタスク => そもそも何をやるかから明確にしないといけないタスク といった感じで次第にふわっとした依頼になってくる。いわゆるグレード制を採用している会社において、"どれだけ抽象度の高い仕事を任せられるか" がグレードの違いの要素のひとつと言ってもいい。 抽象度の高い仕事を安心して任せられる人は何が違うのか自分もよくわからないので、自分のまわりの人がどういう動きをしているかを雑にまとめてみる。 1. なぜやるかを明確にしている わからないときはドキュメントやチャットのやりとりを探し、直接聞いたほうがよい人には自分でコミュニケーションを取っている やる理由がないと判断したら依頼者に話をして、実際にやらないこともある あとで「自分はこう言われただけなので」
こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから
チームにポジティブなコミュニケーションを増やす スキルマップの使い方 - MonotaRO Tech Blog
こんにちは、モノタロウのUIUXグループの澤井です。 主にサービス開発や商品開発のためのリサーチ・体験設計、これらのための仕組みづくり・運用に携わっています。 この記事では、チームにポジティブなコミュニケーションを増やすために、メンバー同士の自己開示のためのツールとしてスキルマップを利用したこと、利用にあたって工夫したことについてお話していきます。 目次 スキルマップってどんなツール？ スキルマップを利用しようと思った背景 スキルマップの利用にあたって工夫したこと スキルマップを利用してどうだったか おわりに スキルマップってどんなツール？ そもそもスキルマップはどんなものかといいますと、縦軸と横軸を中心で交差させて分けた4つのセグメントにスキルをマッピングして傾向や状態を可視化するものです。自己紹介や自己分析に使ったり、目的によって様々に利用できる便利なツールです。 詳しくは、宇野さんの
テキストコミュニケーションで意識していること｜ymdkit
リモートワークで仕事をしていると、Slack や Teams といった何かしらのチャットツールでコミュニケーションを取ることが多い。そうやって仕事を続けていく中で「こう伝えたらよりスムーズに話が進んだかな...」という後悔は多々あり、日々試行錯誤を続けている。 そうやって試行錯誤を続けていく中である程度テキストコミュニケーションを取る上でのフォーマットが定まってきた気がするので、箇条書きでまとめてみようと思う。（随時更新予定） prefix （接頭辞）をつける文章の先頭にその文章の目的がわかるような prefix をつけて、何のためにポストしたかを一目で分かりやすくする。例えば以下のような prefix をつけることがある。 【質問】→ 相手の返信が欲しい時 【共有】→ 返信は不要だが、内容は把握しておいてほしい時 【メモ】→ 返信不要で、後から検索できるよう残しておきたい時 箇条書きする
開発チームのマネージャーとして意識しているチームのCapability - LayerX エンジニアブログ
こんにちは。バクラク申請・経費精算チームでエンジニアリングマネージャーをしているsh_komineです。 7月はLayerXエンジニアブログを活発にしよう月間 ということで、今日は最近自分が「開発チームのマネージャーとして意識しているチームのCapability 」について話をしようと思います。LayerXのテックブログでは数少ないマネジメント系の話です。 私自身、エンジニアリングマネージャー歴自体は1年ほどなので、まだまだ足りない面もあると思いますが、誰かの参考になればと思います。 開発チームとCapabilityの定義 開発チームの単位もいろいろとありますが、基本的にはチームとして意思決定し、開発活動を続ける最小単位のチームを想定しています。開発エンジニアにプロダクトマネージャー、チームによってはデザイナーやQAなども含みます。自分の場合は職能横断型のプロダクト・顧客に向き合うチームを
マネージャー＆リーダー向け 社内トレーニング / Training of management and leadership for Stockmark
ストックマークの社内研修の公開版※資料です。 （※実際に研修で利用したものとは異なります）
マネジャーとは「管理する人」ではなく「なんとかする人」 今の時代のマネジメントに必要なたった3つの要素
Sansan株式会社が提供するキャリアプロフィール「Eight」、朝日インタラクティブ株式会社が運営する中小企業向けウェブメディア「ツギノジダイ」の共催イベント「日本を変える 中小企業リーダーズサミット2023」より、「VUCAの時代のリーダーシップとマネジメント、そして人材育成」をテーマに語られた伊藤羊一氏の講演の模様をお届けします。変化が激しく、1つの正解のないVUCAの時代は、どのようなマネジメントやリーダーシップが求められるのか、同氏の考えが語られました。 VUCAの時代のリーダーシップとマネジメント 伊藤羊一氏：伊藤でございます。どうぞよろしくお願いいたします。今日は「VUCAの時代のリーダーシップとマネジメント、そして人材育成」ということで、やたらてんこ盛りでございますけれども、30分お時間をいただきまして、いろんなことをお話ししたいと思います。ちょっと早口でいきますが、ものす
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
ミーティング・ファシリテーション入門 / Introduction To Meeting And Facilitation
Stockmark ( https://stockmark.co.jp ) 社内勉強会の資料公開です。
育休前に振り返る、私がEMとして大切にしている考え方 - STORES Product Blog
はじめに こんにちは、テクノロジー部門プロダクト基盤本部基盤グループでEM（エンジニアリングマネージャー）をやっている松本 (@upinetree) です。普段はID基盤などを作ってます。この度子供が生まれ、6ヶ月間の育休を取得させてもらうことになりました*1。育休に入るにあたって、ありがたくもチームメンバーの池田さん (@yusuiked) が私の育休中のEM業務の代打を引き受けてくれました。大感謝です。ここ数ヶ月かけて引き継ぎを進めてきて、無事バトンタッチできました。 引き継ぎは職種問わず難しい仕事のひとつですが、EMの引き継ぎは関わっている人や仕事、抱えている情報が多い点において難しく、悩みながらやってきました。最初はざっと業務内容を洗い出し、池田さんと一緒にEM業務を行いながら引き継ぎを進めるプランを考えましたが、それだけでは表面上の引き継ぎに留まってしまいます。また、上司の大橋さ
人材マネジメント🤯 | POSTD
初めて会社を起業する人のほとんどは、集団をマネジメントする方法を学ぶ間に、創業当初の従業員を燃え尽き症候群にさせてしまうと思います。 筆者のアドバイスがそのようなケースを減らせるなら、ここに書いておく価値があるでしょう。 筆者は小規模なチームやスタートアップ企業のマネージャーのためにこの記事を書きました。 ほとんどのアドバイスは、大規模な企業のマネジメントには当てはまらないのではないかと思います。 なお、急成長している企業に入社する人への全般的なアドバイスについてはこちらをご覧ください。 筆者について 中・小規模のエンジニアリングチームを数チーム管理した経験あり On DeckのCTO CoinListの元エンジニアリング担当VP AngelListの元リモート責任者 Product Huntの元CTO それでは始めましょう。 マネージャーはすべての失敗に責任を負う 分かります……とても前
GitLab CEOによるフルリモート経営アドバイス
これは何 これの雑な書き起こし。 会社文化の作り方 プロセスの整理。コミュニケーションの取り方、slackの会話方法などを統一した カルチャーバリューを書き出した。transparencyとiterationがメイン。 iteration: スコープを減らして、より早く出荷する方法をグループで考える会を設定している バリューとは誰を昇格させるか バリューに関する歌を作った。カラオケパーティでも歌う カラオケパーティはCEOの自宅で開いてる 「コーヒーチャット」文化を作ってみた。25分でなんとなく雑談する バリューを維持するのが本当にたいへん。大体のバリューは口伝で伝えられるためリモートだと維持しづらい。handbookを使うことで対抗してる フルリモートの良いとこ 幅広いタレントと働ける かっこいいキャンパスあると過剰な到達感が生まれる。立ち止まってしまう 自宅で働く必要はない。社員がオフ
自律駆動型組織をつくるためのオープンな情報共有の方法｜tebiki ブログ
弊社では、顧客情報や個人情報にはもちろん配慮しつつ、給与関連を除く全ての情報を社内共有しています。たとえば銀行残高も公開していて、新入社員によく驚かれたりします。この記事では、どういう意図と設計で情報公開しているのかを解説していきます。 貴山敬 (@tkiyama) ※Tebiki社のカルチャーや各種社内制度はこちらもご覧ください。 情報を隠すコストは大きく、たいてい運用で失敗する情報を隠すためには、議事録を含む様々なドキュメント／フォルダ／社内SNSのチャネル等で、細かく公開設定する必要があります。 実際に公開設定を真面目に管理したことある人はよくわかると思いますが、かんたんそうに見えて、実際はかなり難しい。以下のような例外パターンがたくさん生まれるので、正しい状態を維持するのはすごく手間がかかります。 部門単位で公開設定するが、個人単位で設定することもあり、部門と個人が混在する。 Xフ
Engineering Manager になってから身に沁みた12のアイデアと言葉 part3 - これはただの日記
今年も書きます。 kths.hatenablog.com kths.hatenablog.com 能力主義のパラドックス 自分が客観的で公正な人だと信じてしまうことで、偏向した行動をとってしまう現象を「能力主義のパラドックス」というそうです。 韓国で16万部超のベストセラーとなった『差別はたいてい悪意のない人がする』では、全員に同一の基準を適用することが、だれかを不利にさせてしまう間接差別の例について紹介されています。 だれに対しても同じ基準を適用することのほうが公正だと思われるかもしれないが、実際は、結果的に差別になる。司法書士試験で、問題用紙・答案用紙と試験時間をすべての人に同一に設定すれば、視覚障害者には不利になる。製菓・製パンの実技試験において、すべての参加者に同じように手話通訳を提供しない場合、聴覚障害者に不利である。公務員試験の筆記試験で、他の受験生と同様、代筆を許可しない場合
事業で勝つためのマネジメントとは。エンジニア組織づくりの裏側を一休伊藤氏とスタフェス柄沢氏に聞いてみた
青山学院大学大学院博士課程前期修了後、新卒でニフティ株式会社に入社し、ブログサービス「ココログ」を開発。その後、株式会社はてなの取締役CTOに就き、はてなブックマークの開発などを主導した。フリーランスでの活動などを経て、2016年4月、一休の執行役員CTOに就任。 スターフェスティバル株式会社 柄沢 聡太郎[@sotarok] 中央大学大学院卒業後、ソフトウェアエンジニアとしてグリー株式会社に入社。その後2011年株式会社クロコスを共同創業、2012年にヤフー株式会社へ売却。2015年より株式会社メルカリで執行役員CTO及びVP of Engineeringとして技術領域全般を統括し、エンジニア組織20人規模から数百人規模、そしてプロダクトの急成長に貢献。2020年2月よりスターフェスティバル株式会社に執行役員CTOとして参画、同年9月より取締役就任。 登壇者の自己紹介からスタート。3人の
エンジニアや上司が"有害な振る舞い"を改善するコツ - Qiita
※追記: 「難しい人」は概念として用い説明するのに便利な言葉でしたが、誤解を生じたり、本記事のポリシーに沿わない使用（難しい人というラベリングを特定個人に適用する使い方）が容易にされてしまいそうだと分かりました。そのような誤用を防ぐことを最優先とするため、代わりに「有害な振る舞い」という表現を使用し、人ではなく振る舞いに着目するタイトル及び文章に変更致しました。 はじめに 前回の記事「エンジニアの"有害な振る舞い"への対処法」では多くの反応を頂きました。 はてなブックマークのコメントやTwitterを見ると、多種多様な反応がある中で、有害な振る舞いが多くの方によって実際に観測されていること、そしてそれによって実際に心理的ダメージを受けていたり困っているというコメントがいくつもあることが印象的でした。 ただ、その一方でこれだけ有害な振る舞いに対する反発があると、自分の有害な振る舞いによってチ
GitLabで学んだ最高の働き方。気持ちよく働くための組織と個人のテクニック（前編）。デブサミ2022
今日は「GitLabで学んだ最高の働き方」ということで発表していきたいと思います。 私、伊藤と佐々木はGitLabでソリューションアーキテクトをやっている者です。 GitLabは、オンプレミス用のソフトウェアと、GitLab.comも長年やっておりますのでぜひ使ってください。去年めでたく上場しましたので、さらにいろんな機能を追加して強力なDevOpsプラットフォームとして展開していきたいと思っています。 このセッションで共有したい内容の背景、これは個人的にGitLab社に参画した理由のひとつでもあるのですが、製品が魅力的であることともうひとつ、GitLabはご存じの通り、ご存じない方もいるかもしれませんが、従業員全員がリモートワークをしている企業です。 そこなら最先端のやり方での働きができるのではないか、という仮説が私の中にありまして、入社しました。 で、実際どうだったかというと、はい、最
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアリングマネージャーの理想と現実
こうしてふりかえりは終わってしまった / A Demise of a retrospective
リモートワークにおけるファシリテーションの方法論[増補版]_COPILOT![リモートワークにおけるファシリテーションの方法論[増補版]_COPILOT](https://cdn-ak-scissors.b.st-hatena.com/image/square/0b5d2f3bd255efef3c2c9bbfeed073d400e628c5/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F372179d31405454b9d047426e018ff19%2Fslide_0.jpg%3F27620682)
