タグ

managementに関するlepton9のブックマーク (775)

  • Google re:Work - マネージャー

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

    Google re:Work - マネージャー
  • エンジニアリングマネージャーが手懐けるべき荒ぶる四天王 - STORES Product Blog

    この記事は「STORES Advent Calendar 2022」 12/17の記事です。また、「Engineering Manager Advent Calendar 2022」 カレンダー2の12/17の記事でもあります。 こんにちは!STORES エンジニアリング室の塩谷(@kwappa)です。この記事では、エンジニアリングマネージャーの中に棲んでいる「荒ぶる四天王」について考え、うまくつきあい、あわよくば手懐けてしまおう、という試みについてお伝えします。 エンジニアリングマネージャーのしごと この記事をご覧の方でしたら、今年8月にオライリーから発売された『エンジニアリングマネージャーのしごと』という書籍に興味がある、もしくはもう読んだのではないでしょうか。エンジニアリングマネージャー(以下EM)という重要だが定義がふわっとした仕事にどう取り組んだらいいかのガイドとなる、とてもいい

    エンジニアリングマネージャーが手懐けるべき荒ぶる四天王 - STORES Product Blog
  • エンジニアのスキルマップ・テックリードへの途 - 電通総研 テックブログ

    みなさんこんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の水野です。 これは電通国際情報サービス Advent Calendar 2022の16日目の記事です。 今回は、ISID金融事業部で運用しているスキルマップについてご紹介します。 テックリードとは 実は、ISIDの少なくとも金融事業部にテックリードと言うポジションはありません。 実在するのはチーフアーキテクトと言う職種のみで、各プロジェクトでリードエンジニアやテックリードという仮想的なロールがあるのが実態です。 一時期はフルスタックエンジニアと呼んでいる時期もありましたが、近年このワーディングが好まれない印象なので、大々的に使っていません。 主観ですが、フルスタックエンジニアはインフラ知識/運用系の知識のウェイトが高いエンジニアで、テックリードはソフトウェアアーキテクチャ、Webアプリケーション実装技術寄りのエ

    エンジニアのスキルマップ・テックリードへの途 - 電通総研 テックブログ
  • 「技術的には可能です」と発声するその前に - Qiita

    技術者はよく、実装可否の問い合わせに対して当はやりたくない・すべきでないと思っているのにやればできることだからと「技術的には可能です」と答えてしまいハマる⋯って当ですか? 私は最低でもここ10年は「技術的には可能です」と発言した記憶がありません。なぜそう言うことがないかというと、可否の問い合わせを受けた時点で次のようなことを考えてしまうからです。 運用は回る? 人力操作が絡むフローがあるけど利用数が増えたときにちゃんとスケールする? 休日深夜対応が必要になりそうだけど要員と人件費コストは確保できてる? カスタマーサポート対応激増しそうだけど(以下同文 誤操作があったりしてデータの修正依頼が来たときに訂正しようがない要件っぽいけど大丈夫? エンジニアDB直操作対応するサービスメニューが存在するけど事故リスク、工数コスト、今後の開発停滞リスクは織り込み済み? 事故の際の責任はエンジニア

    「技術的には可能です」と発声するその前に - Qiita
  • 素晴らしいふりかえりの手法3選 - Qiita

    こんにちは、ログラスで業務委託としてエンジニアをしております、やの(yamyanu)です。 記事は株式会社ログラス Productチーム Advent Calendar 2022の9日目の記事になります。 はじめに みなさん、チームでふりかえりは実施していますか?ふりかえりはチームの開発プロセスを改善し、心理的安全性を確保することにも役立つとても良い活動だなと感じます。 しかし、同じ手法だけを行うと類似した観点での議論になってしまい効果が低下することもあります。そういった場合は、様々な手法を試し、自分のチームに合ったふりかえりにカスタマイズすることが重要です。 そこで今回は、3つの素晴らしいふりかえりに関する手法をご紹介します。それぞれの手法にお手軽度とうまくいった時の効果の度合いを載せていますので、ぜひ参考にしてみてください。 「Good Bad Fact Feel」: 気持ちもメンバ

    素晴らしいふりかえりの手法3選 - Qiita
  • チーム仲は悪くないのに「何となく一体感がない」時に試してもらいたい3つのこと|こがねん / 組織開発するマン

    こんにちは。こがねんです。ファッションテック企業で「組織開発」をしています。 「組織開発」とは何でしょう。これにはいろいろな定義がありますが、僕は「人の集まりが同じ目的に向かって協働するチームになるためのあれやこれやの働きかけ」くらいに考えています。 会社全体・特定部門・特定チーム・特定個人と、人・組織の課題はあらゆるレベルで起こります。その課題発見や解決を自分や自分のチームがリードして行ったり、他の人が行うのをサポートしたりする仕事。それが「組織開発」です。 そんな仕事をしている関係で、現場マネジャーからもよく人・組織に関する相談を受けます。先日も現場のマネジャーからこんな相談を受けました。 「チームの一体感が低下していて困っています。別に仲が悪いわけではないですが、リモートワークになった頃からメンバー同士の関わり合いが減ったこともあり、横のつながりが薄くなってしまったように思います。業

    チーム仲は悪くないのに「何となく一体感がない」時に試してもらいたい3つのこと|こがねん / 組織開発するマン
  • 「マネジメントの型」がある会社にEMとして入社しました - Paytner Tech Blog

    Engineering Manager Advent Calendar 2022 15日目の記事です。 はじめに こんにちは!ペイトナー株式会社で1人目エンジニアリングマネージャーをやっている脇田(@shimpeee_)です。2022年5月にペイトナーに入社しました。マネージャー歴2年目の、新米マネージャーです。 ペイトナーでは、会社として「マネジメントの型化」に取り組んでおり、そのおかげで新米マネージャーの自分も経営陣と共通認識を持ちながらスピード感を持って日々の業務と向き合うことができています。 記事では、ペイトナーでマネジメントの教科書としている「EVeMのベンチャーマネジメント理論(自分が勝手にそう呼んでいる)」の素晴らしさについて熱く語ってみようと思います。 マネジメントの目的とは この章では、これまで持っていた自分なりのマネジメントに対する解釈や思いについて触れたいと思います

    「マネジメントの型」がある会社にEMとして入社しました - Paytner Tech Blog
  • Engineering Managerを廃止して1年経ちました - Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

    こんにちは、ゆのん(id:yunon_phys)です。このエントリーはAkatsuki Games Advent Calendar 2022の14日目の記事です。昨日はMaxBaconPowerさんの「巨大数でわかる Elixir の魅力」でした。Elixirが再帰が得意とはいえ、良くこんな題材を思いついたなと感心しました。早くふぃっしゅ数を見てみたいものです。 さて題に入るわけですが、昨年、Engineering Manager(EM)を廃止して3つに分割したという話を書きました。そこから1年経ち、どのような状態になったのか、ふりかえりも含めて書いていきます。記事は前回の記事を読まなくても読めるようにしていますが、更に背景理解したい方は前回の記事も読んでみてください。 hackerslab.aktsk.jp ずばりEMを無くして良かったのか これはマクロに見ると明確に良かったと思って

    Engineering Managerを廃止して1年経ちました - Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)
  • 作業ではなく、仕事をせよ - arclamp

    この記事はグロースエクスパートナーズ Advent Calendar 2022の11日目です。 (補足追記:この記事は、一緒に働いている/働くことになる若い後輩たちへのメッセージです) 毎年、メンバーからお題をもらっているのですが「一緒に仕事する相手がこうだったら教えがいがある・やりやすいなと思う言動について書いてほしい」ということなので、僕のキャリア(もうちょっとで四半世紀...)の中で学んできたことも含めて、整理してみます。 心構え:作業ではなく、仕事をせよ まず、一緒に仕事をする上でお願いしたいのは「作業ではなく、仕事をしてほしい」ということです。ここでいう仕事と作業の定義は以下の通りです。 仕事というのは「ある目的を達成するための行動」 作業というのは「ある計画や手順のもとにおこなう行動」 仕事は作業を含んでいます。目的を達成する行動全般が「仕事」であり、仕事の中で具体的な手順を実

    作業ではなく、仕事をせよ - arclamp
  • EMキャリアを切り拓く「最強の現場リーダー」という働き方 - yigarashiのブログ

    このエントリはEngineering Manager Advent Calendar 202213日目の記事です。 まえがき このエントリは、以下のPodcastで話した内容を掘り下げて整理したものです。Podcastの方ではエントリで触れていないチームの具体的な様子等についても話しているので、ぜひ合わせてお楽しみください! はじめに 以前、エンジニアリングマネージャーを目指す若者の戦略というエントリを書きました。その時点でのエンジニアリングマネージャー(以下EM)というロールへの理解や、実際にEMを目指していくための戦略を整理したものです。 素晴らしいことに、このエントリの投稿からおよそ1年3ヶ月たった今も戦略は機能しており、ロールへの理解を深めつつキャリアを前進させることが出来ています。エントリでは、EMというロールへの理解の変化や、EMを志向する過程で目指している「最強の現場リー

    EMキャリアを切り拓く「最強の現場リーダー」という働き方 - yigarashiのブログ
  • 不確実な状況に耐える力を学ぶ - 「ネガティブ・ケイパビリティ」を読んだ - $shibayu36->blog;

    自分は問題解決は得意な方だと思っている。しかし逆に不確実な状況・不安な状況・課題がある状況をそのままにして耐える力をもっと付けたいなと思っている。そこで最近目にした「どうにも答えの出ない、どうにも対処しようのない事態に耐える能力」であるネガティブ・ケイパビリティについて学ぶためを読んでみた。 ネガティブ・ケイパビリティ 答えの出ない事態に耐える力 (朝日選書) 作者:帚木 蓬生朝日新聞出版Amazon 正直、この歴史的な話とか雑談も多く、少し頭に入りにくかったが、一方で示唆のあることを学べた。例えば どうにも対処が難しい課題を見つけた時に、拙速に解決策を見出すのではなく、興味を抱いてその宙吊りの状態を耐えると良い。それによって深い理解に行き着く 問題解決があまりに強調されると、まず問題設定の時に、問題そのものを平易化してしまう傾向が生まれる。この時、複雑さを削ぎ落としているので、現実

    不確実な状況に耐える力を学ぶ - 「ネガティブ・ケイパビリティ」を読んだ - $shibayu36->blog;
  • 【資料公開】マネージャーのしごと

    みなさんこんにちは。@ryuzeeです。 2022年12月9日に行われたイベント「Developers CAREER Boost」の登壇資料を公開します。 今回は、「マネージャー」と名のつく職種を分類して、それぞれの職務や定義を確認した上で、有効なマネージャーであるにはどうしたらよいかを整理してみました。 資料を作るにあたって、過去の日記を読み返したり記憶を思い起こしたりして、当時の活動や出来事、悩みを整理してみたのですが、自分はやっぱりマネージャーに向いていないし志向していないことを再確認できました(笑)。 全員がマネージャーにならなければいけないなんてことはなく、自分が日々楽しく過ごせるキャリアを選択すればいいと思いますが、資料が少しでも役に立てばうれしい限りです。 セッションで紹介した書籍は以下のとおりです。 エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーに

    【資料公開】マネージャーのしごと
  • 令和最新版エンジニアのリーダーシップ論 - エムスリーテックブログ

    エムスリーエンジニアリンググループ製薬企業向けプラットフォームチーム(「Unit1」)の三浦 (@yuba)です。乗り物大好き男の子ですので好きなテレビ番組は銀河鉄道999とナイトライダーです。 さて「フラットな組織」だとよく言われるエムスリー、特にわがエンジニアリンググループなのですが、そのフラットってどういう感じなんでしょう? 上意下達の体制でない中では、人々はどう組織としての目標を共有して一緒に動いているんでしょう? この疑問への、(管理職でない)一般エンジニアとして5年半やってきた私なりに得た答えをご紹介したいというのが今回のお題になります。これは エムスリー Advent Calendar 2022 の5日目の記事です。前日は id:hsasakawa による グローバルサービスの開発における技術的な意思決定 - エムスリーテックブログ でした。 そしていきなり最初に結論から言っ

    令和最新版エンジニアのリーダーシップ論 - エムスリーテックブログ
  • 要件定義に関わる人は3億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」

    nori @00oichan お気軽にフォローいただけると嬉しいです。 神奈川県在住/運用設計が得意/外資系企業のSaaSエンジニアです。 好き: servicenow,生成AI,UiPath,Power Automate Desktop,PowerBI … Amazon.co.jp アソシエイトを利用中です

    要件定義に関わる人は3億回くらい読んでほしい−−−−−−−−−−「IPA 独立行政法人 情報処理推進機構 超上流から攻める IT 化の原理原則 17ヶ条」
  • セキュリティーチェックシートという闇への防衛術 - Qiita

    といった感じです。(この例、下で問題例として取り上げるため、実はおかしなチェック内容にしています。) "No.~基準"までがシートに記載されていてます。回答する発注先企業は"Yes,No,N/A"を3択で✅をつけ、備考欄にNoやN/Aの理由のほか、注記を記載できます。こういう項目が20~500項目あるExcelのシートに、発注先企業の回答担当は自社の状況、対応を確認しながら、ひたすら記載してゆくわけです。 知ってる人は知っているが、知らない人はぜんぜん知らない 最近参加したエンジニアがぞろぞろいらしたカンファレンスで、私が 「……あの セキュリティーチェックシート ってあるじゃないですが、あの 面倒なアレ です。アレにこの規格を採用するよう書いてあったら、各企業に規格の採用が広がるかもですね。あはは。」 と話したことがありました。その瞬間、 嫌なことを思い出したのか顔を曇らせたり苦笑いをす

    セキュリティーチェックシートという闇への防衛術 - Qiita
  • 「プロジェクトマネジメントの基本が全部わかる本」は序盤から『交渉』について書いてるところが良いと思った - フジイユウジ::ドットネット

    プロジェクトマネジメントの基が全部わかる」を買ったら、注文ミスして2冊頼んでしまったんだけど、結果的にはむしろ2冊買ってよかった、という話を書きます。 「プロジェクトマネジメントの基が全部わかる」 ( @paradisemaker 著)が届いたー。 なんか注文ミスって2冊届いたけど、1冊は誰かに読ませるとき用にしようw pic.twitter.com/evnrXtssm8 — フジイユウジ (@fujii_yuji) 2022年11月10日 制作/開発をするメンバーはいるけどプロジェクトマネジメントは得意ではなくて雑になってしまっているという制作/開発会社も多いと思うのですが、僕もそういう会社からどうしたらいいのか相談されたり、PMの育成の話をすることがあります。 (肩書としてPMだったことはないんだけど、僕も20年くらいPdM的な仕事をやってるんで相談されることがそれなりにある

    「プロジェクトマネジメントの基本が全部わかる本」は序盤から『交渉』について書いてるところが良いと思った - フジイユウジ::ドットネット
  • 始めるのをやめよう。終わらせることを始めよう。

    あなたのチームがいくつも未着手の仕事を抱えているとき、どのようにそれらに着手し、そして完了させていったら良いでしょうか? アジャイルには「始めるのをやめよう。終わらせることを始めよう。」という言葉があります。Tebiki株式会社では、この考え方を基として、 デスクレスワーカーのための現場教育SaaS「tebiki」を開発しています。 この記事では、新しい仕事を「始める」ことを優先する場合と、仕掛り中の仕事を「終わらせる」ことを優先する場合の比較をしながら、かつては「始める」ことを優先していた Tebiki社が「終わらせる」ことを重視するように変わっていった事例を紹介したいと思います。 仕事が「終わる」とはまず前提として、仕事が「終わる」とは、どういうことでしょうか?たいていの仕事では、まず必要な作業を計画し、それを実行することでその仕事を進めるはずです。 それでは、計画していた作業をひと

    始めるのをやめよう。終わらせることを始めよう。
  • 約束すると開発が遅れる - 西尾泰和のScrapbox

    Bが分散の大小に無自覚な場合、分散が大きくて良いところでも小さい分散を求めて無駄に保険金を支払うことになる @golden_lucky: 約束すると開発が遅れる、まじで実感を伴うんだけど、そう明言してしまうと単なるジンクスかもしれんとも感じられるくらいの微妙な実感で、でもこの文章を読むとやっぱりジンクスじゃないんだと思える。いい文章だ

    約束すると開発が遅れる - 西尾泰和のScrapbox
  • 約束は開発を遅らせる - Mitsuyuki.Shiiba

    観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな?」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない?もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは

    約束は開発を遅らせる - Mitsuyuki.Shiiba
  • 無計画に見える計画・チーム感の欠如・とりあえずがんばる文化  “ふりかえりエバンジェリスト”が異動先で直面した組織の課題

    スクラムフェス仙台」は初心者からエキスパートまでさまざまな参加者が集い、学び、楽しむことができるアジャイルコミュニティの祭典です。ここで登壇したのは、森一樹氏。ふりかえりを日常とするチームができるまでを「プロダクトオーナー」という観点でふりかえり、それを再現するために必要だった要素について話しました。全4回。1回目は、異動から見えた、内情と課題について。 ふりかえりのエバンジェリスト・森一樹氏 森一樹氏:よろしくお願いします。みなさんこんにちは。 (会場拍手) 現地の方もオンラインの方も、よろしくお願いします。オンラインの方はすみません、私はだいぶ久々に現地登壇をするので、Discordのコメントを拾う余裕がなさそうです。とはいえ、コメントをもらえるとあとから見返した時にすごくうれしいので、ぜひよろしくお願いします。 今日は「プロダクトオーナーのための、ふりかえりが日常に溶けるチームの作

    無計画に見える計画・チーム感の欠如・とりあえずがんばる文化  “ふりかえりエバンジェリスト”が異動先で直面した組織の課題