タグ

組織に関するJGEEMのブックマーク (19)

  • エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか / Elegant Puzzle

    https://forkwell.connpass.com/event/319444/ の登壇資料です。

    エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか / Elegant Puzzle
  • 兼務による体制構築はプロジェクトの効率を損なわせる|mtx2s

    ソフトウェア開発プロジェクトは、「兼務」を用いるチーム編成が多用されやすい対象ではないでしょうか。エンジニアであれば誰もが経験したことがあるでしょう。1人で複数のプロジェクトやチームを掛け持ちするあれです。マネージャーであれば、組織の人的リソース配置を考える時の手段の1つとして用いたことが何度かあるはずです。 しかし、兼務が引き起こす様々な弊害や問題については、あまり意識されないまま多用されているように感じます。 たとえば、兼務者人にとってプロジェクトの掛け持ちは、仕事のマルチタスク化やミーティングの増加に苦しむ原因になります。組織の観点からも、兼務への依存は、知識の偏りや負荷の偏りという弊害をもたらすことに繋がりかねません。プロジェクトの観点から見ると、兼務という形での「人的リソースの共有」は、プロジェクト間での「リソースの競合」を引き起こしやすく、それが市場投入までの時間を長くする要

    兼務による体制構築はプロジェクトの効率を損なわせる|mtx2s
  • マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB/Developers Summit 2024 TiDB Sponsor Session

    マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB/Developers Summit 2024 TiDB Sponsor Session

    マイクロサービス導入により生まれた組織課題に対するソリューションとしてのTiDB/Developers Summit 2024 TiDB Sponsor Session
    JGEEM
    JGEEM 2024/02/18
    本論ではないが"MSAとは究極組織論である(諸説ある)"わかる。ドメイン見極めで複数の組織に散ってしまっている集約をどうにかしたいんだけど、対応するscrumチームも組織横断で自己決定力に欠けちゃう問題
  • 経営・意思・エンジニアリング

    YAP::Hiroshima 2024にて登壇 #yapcjapan

    経営・意思・エンジニアリング
    JGEEM
    JGEEM 2024/02/10
    熱量の高い良いスライド。組織開発とシステム設計って構造化する点で似てる?とぼんやり考えることはあったが見事に言語化されてる。"根幹は意思"も同意。精神論と言われることもあるが、意思がなければ前に進めない
  • ソフトウェア開発におけるクリエイティビティの最小化、認知負荷 - Runner in the High

    前提としてクリエイティブな仕事は再現性が低い。しかし逆に言えば再現性があってはいけないものがクリエイティブであり、再現性がないからこそクリエイティブであると言える。アートのように非再現的なものはクリエイティブであり、再現性が低く刹那的な成果物であることに意味がある。 ソフトウェア開発にもまたアート的なクリエイティビティが求められつつも、ビジネスとしての利益追求では再現性が同時に求められることが多い。従って、多くの現場ではソフトウェア開発を再現性の高い労働集約的な仕事に転換しようとする。むしろ、そうしなければ開発組織の規模をスケールさせることができない。 ここで言うクリエイティビティの有無とは質的に技術力とイコールであり、その具体性の表出はフレームワークやプログラミング言語を使うことではなく、逆にそれらを生み出す側にある。このレベルの技術力を持つ人材を集め続けるのは無理があるが、一方で技術

    ソフトウェア開発におけるクリエイティビティの最小化、認知負荷 - Runner in the High
    JGEEM
    JGEEM 2024/01/27
    概ね同意するところではあるんだけど、クリエイティビティの有無でチームを分けてしまうと受け手(ストリームアラインド)は「やらされ感」が強くなり、保守・現状維持vs改善・成長という対立にならないか不安
  • LayerX松本勇気×KADOKAWA Connected塚本圭一郎 トップランナーによる組織変革論

    「ビジネス・ソフトウェア・ヒト」の3要素を設計する 塚圭一郎氏(以下、塚):松さんとお話しするのは初めてですね。私は新卒でドワンゴに入社し、ビッグデータ分析基盤の構築と運用、特にニコニコ事業向けの基盤構築に従事しました。その後、KADOKAWAにもこのノウハウを輸出するようオーダーを受け、KADOKAWA Connectedに参加。現在はKADOKAWA ConnectedのCDOとして、KADOKAWAグループのデータ基盤と戦略の策定に携わっています。 松勇気氏(以下、松):私は東京大学在学中にGunosyに参画し、ソフトウェア開発を担当しました。Gunosy上場後はCTOとして全社統括、採用、組織作り、新規事業開発を経験しています。その後、DMM.com(以下、DMM)へ移り、約3,000名規模のテックカンパニー化に向けた組織改革に2年半携わりました。現在はLayerXの代表

    LayerX松本勇気×KADOKAWA Connected塚本圭一郎 トップランナーによる組織変革論
    JGEEM
    JGEEM 2024/01/27
    面白かった。抜粋&要約:コミュニケに頼らないと仕事ができんて非効率。メンタルモデルを共有したら指示など不要。はその通りだが実現できるだろうか、、解の一つが「出力を学習したLLM」!?!?
  • 「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号|mtx2s

    リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層

    「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号|mtx2s
    JGEEM
    JGEEM 2024/01/23
    心当たりがありすぎて胸が痛い。その状況を指摘して、改善の道を示してもなお内部品質を無視して「今はスピードを優先して」とのたまうマネージャーとそれを容認する組織に何をか言わんや
  • 正直であることから始める / Start by being honest.

    RSGT 2024 Day 2 スポンサーセッション

    正直であることから始める / Start by being honest.
    JGEEM
    JGEEM 2024/01/22
    やっと読んだ。心理的安全性の話として読んだ。とても良いスライド。"正直に話さないのではなく話せない" 自身の現状に即していたので尚。ポジティブフィードバック/失敗は成長のきっかけ/MVVの浸透
  • 【虎の穴ラボ】根っから小売文化の組織がエンジニアファーストに生まれ変わるまでの一部始終

    虎の穴ラボ株式会社 CEO 野田純一 大学卒業後、受託開発の会社に入社。その後DeNAにてゲーム開発に関わったのち、GMOへ入社。アドテク開発や研究に取り組む。2016年に虎の穴ラボの前身であるユメノソラHDに入社し、当時新規事業だったFantiaの開発の傍ら、開発組織の環境整備やエンジニア採用に取り組む。2019年10月、ユメノソラHDのエンジニア組織が「虎の穴ラボ株式会社」として分社化し、CTOに就任。2023年9月より現職。 美少女のイラストに「エンジニア採用!」「今後もずっとフルリモート!」の文字が踊る。一度は目にしたであろう、あの個性的な採用広告の広告主は「虎の穴ラボ」。同人誌通販「とらのあな」を運営するユメノソラホールディングス株式会社から分社したエンジニア・クリエイター組織です。 現CEOの野田純一さんは元GMOのシニアエンジニア。ユメノソラにはエンジニア組織の立ち上げ・拡大

    【虎の穴ラボ】根っから小売文化の組織がエンジニアファーストに生まれ変わるまでの一部始終
    JGEEM
    JGEEM 2024/01/14
    「根っからの小売文化」の経験あるけど、結構つらかったな。平成だったし、エンジニアファーストも今ほど定着してなかったんで「そういうもんだ」と諦めてたような。そして虎の穴ラボ、興味あるな、、
  • チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog

    近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。 そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。 初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。 なお、記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機

    チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog
    JGEEM
    JGEEM 2024/01/14
    これは本当にその通りだと思う。特に「アトミック」と「非兼務」。人が足りないと兼務が増えていきがちだけど、それこそアトミックな単位をより小さくしてチーム単位で兼務にできないものかな
  • 6-1 ファクトを整理する① 課題ヒアリングと分析 前編 #ソフトウェアと経営|Matsumoto Yuki

    ソフトウェアと経営マガジン第75回です。組織改革に取り組むにはまず正しい現状認識から、ということで今回と次回は課題のヒアリングと整理についての考え方を書いていこうと思います。前編では、まずヒアリングを重ねようということで、どのようにして課題をかき集めるか、それによって生み出すべきアウトプットとはなにか書いていこうと思います。 記事に対する疑問や感想、意見などXでのポストや記事へのコメントをいただければ、今後のコンテンツの改善に役立てさせていただきます、よろしくおねがいします。 前回の記事はこちら。 課題ヒアリングと分析改革の第一歩は自分自身の組織を正しく知ることだ。自身の組織を知る上では①課題②KPI構造③人を私は重視している。その上でまず知るべきは自身の組織の課題構造である。課題は点ではなく線、構造的なものであるという前提に立って、まずはこれらを収集・整理してみよう。 課題ヒアリングで求

    6-1 ファクトを整理する① 課題ヒアリングと分析 前編 #ソフトウェアと経営|Matsumoto Yuki
    JGEEM
    JGEEM 2023/12/30
    課題の多くは組織構造に起因するの納得。そもそもビジネスがどのような組織構造で成り立っているか気にしない人すらいるし、完全にに自動化された業務の管掌部門がないなんてことも、、ともあれ続きが楽しみ
  • CTOのいない会社にEMとして入社するあなたに 

    私は今までのキャリアの中で、CTOのいない会社に3回入社してきました。うち2社はEMとして入社してVPoEになりました。そこでの反省はもちろんありますが、成果を出すことができました。そして1社は、なんと3週間で退職しました…。 OPENLOGI Advent Calendar 2023で今年は何を書くか考える中で、私のようにCTOがいない会社に何度も入社した経験があるEMはそうそういないのではないかと思いました。将来CTOのいない会社に入社するCTO・VPoE・EMといったマネジメント層の方に、私の経験から学んだことを参考にしていただければと思います。 ※OPENLOGIには現在CTOは在籍しております。 CTOのいない会社とは CTOのいない会社とは、エンジニア組織のトップであるCTO・VPoE・開発部長といった立場の人がいない、もしくは、トップはいるけれど何らかの理由(トップがエンジニ

    CTOのいない会社にEMとして入社するあなたに 
  • 結局のところ、エンジニアリングマネージャーとは何者なのか|dora_e_m

    はじめにこれはEngineering Manager Advent Calendar 2023 25日目の記事です。 毎日良質な記事がアップされて、完全に俺得な一ヶ月でした。ご参加いただいたみなさんありがとうございます。 最終日の記事では、EM Advent Calendarを俯瞰しながら執筆している私のEMキャリアをふりかえり、結局のところEMとは何なのか、ということを考えてみます。 Advent CalendarにおけるEMの多様性と共通点LLM時代におけるEMという、実に2023年的な切り口から始まったこのAdvent Calendarには、実に多様なコンテンツが集まってきました。 新任EMの方の奮闘の記録、手を動かしてなんぼという考え方、スクラムとの接近、プロジェクトマネジメント的アプローチ、オブザーバビリティのEM業への援用、キャリア論・・・。 共通しているのは「マネジメント対象

    結局のところ、エンジニアリングマネージャーとは何者なのか|dora_e_m
    JGEEM
    JGEEM 2023/12/25
    高解像度なEM像に触れられる良いエントリでした。現職はEMでないけど、またEMしたいな、、と思っちゃう。思うにEMって、不確実な世の中にチームをアラインさせるために、その先頭で不確実性と向き合う人だと思うの
  • 「 心理的安全性 」に関する誤解 Vol.1:チームのパフォーマンスを下げる理由 | DIGIDAY[日本版]

    記事のポイント 多くの組織が心理的安全性を「思いやり」や「いい人であること」と誤解しており、これがビジネスに悪影響を及ぼしている。 従業員が報復を恐れずに問題を指摘できる環境を作ること。これにより最高の業績とパフォーマン […] 記事のポイント 多くの組織が心理的安全性を「思いやり」や「いい人であること」と誤解しており、これがビジネスに悪影響を及ぼしている。 従業員が報復を恐れずに問題を指摘できる環境を作ること。これにより最高の業績とパフォーマンスが生まれる。 心理的安全性の概念を長年研究してきたエイミー・エドモンソン教授は、心理的安全性が「弱み」ではなく「武器」になると強調し、正しい理解と適用が必要であると説く。 雇用主は従業員の心理的安全性(psychological safety)を十分に理解できていない。そしてそれはビジネス上、極めて良くないことであると、専門家は警鐘を鳴らしている

    「 心理的安全性 」に関する誤解 Vol.1:チームのパフォーマンスを下げる理由 | DIGIDAY[日本版]
    JGEEM
    JGEEM 2023/12/14
    "互いに相手にきつく当たれというわけではないが、思いやりはここでは関係がない。率直に、正直にふるまえることが大切" 心理的安全性の目指すところが正しく広まってほしい。率直さこそが価値よ
  • 開発だけアジャイルな状況を越えて顧客のアウトカムにつなげる一歩/next step in agile development agile japan 2023

    「めちゃくちゃ勉強してソフトウェア開発も、アジャイルな開発もできるようになってきた! ところがせっかくうまくできるようになったけど、顧客への貢献にはなかなか繋がらない…」こんな悩みををよく聞きます。 この10年間でスクラムなどのアジャイルに関する情報やノウハウは増え、社会的な理解も広がり、その結果アジャイルははじめやすく、習熟もしやすくなっています。開発チームは急速に学習し、能力が高められやすい状況にあります。 ところがプロダクト価値の観点から見ると、開発チームも社内の他部署も、そして顧客も不満を持っていることがあります。せっかくアジャイルな活動ができるようになっても、プロダクト価値に繋げるまでにいたっていないことが多々あります。 セッションでは、プロダクトという観点からアジャイルを捉え直し、開発チームや社内の他部署、顧客も満足するためのお話をします。 プロダクトマネジメントなど過去の登

    開発だけアジャイルな状況を越えて顧客のアウトカムにつなげる一歩/next step in agile development agile japan 2023
    JGEEM
    JGEEM 2023/11/19
    可観測性の担保かな。アジャイルだ!価値創出だ!って盛り上がってる横で冷静に指標を決めて、採取できる仕組みを整えて、自ら継続的にフィードバックを得られるようにプラットフォームを整える役が必要なのかな
  • 徹底解説マイクロサービス 〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜 /why do you choose microservices architecture

    JAWS UG 函館勉強会 Vol12 徹底解説マイクロサービス 〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜

    徹底解説マイクロサービス 〜マイクロサービスのメリット、デメリット、なぜマイクロサービスを選択するのか〜 /why do you choose microservices architecture
    JGEEM
    JGEEM 2023/10/04
    マイクロサービスにフックして組織やDDDに言及されてる。マイクロサービスは統廃合が難しいと言われる中でドメイン理解をしっかりしよう!は正論だが、モノリスからいかに切り出すか?の事例が欲しい
  • アジャイルについてマネージャーが知るべき97のこと

    1. アジャイルについて マネージャーが知るべき 97 のこと 株式会社アトラクタ 取締役CTOアジャイルコーチ 吉羽龍太郎 (@ryuzee) 2. イントロダクション 吉羽龍太郎 / YOSHIBA RYUTARO ▸ アジャイル開発、DevOps、クラウドコンピューティング、 インフラ構築自動化、、組織改革を中心にオンサイトでの コンサルティングとトレーニングを提供。著書訳書多数 2

    アジャイルについてマネージャーが知るべき97のこと
    JGEEM
    JGEEM 2023/09/27
    書いてあることは素晴らしい。その通り。ただ継続的開発を始めるにあたって、プロダクトをどうしたいかぐらいは突き詰めて考えてほしい。手段や問題を試行錯誤するのは良いけれど、ビジョンすらないのは迷子になる
  • 組織のコード品質を向上させる “レビューシステム”の取り組み

    dmm.go #6 の登壇資料です。 https://dmm.connpass.com/event/295065/

    組織のコード品質を向上させる “レビューシステム”の取り組み
    JGEEM
    JGEEM 2023/09/20
    開発言語の習熟度を底上げすることを目的にコードレビューのルールを決めて運用。ただしレビューへの対応は義務化せずmergeを許可。その後、対応すべき指摘に限りトラッキングできるようにして返済遅延のけん制も
  • 組織が拡大しても質の高いDDDを守れるか?ログラス松岡氏・村本氏に聞くDDD浸透の切り札

    組織が拡大しても質の高いDDDを守れるか?ログラス松岡氏・村氏に聞くDDD浸透の切り札 2023年9月19日 株式会社ログラス EM 松岡 幸一郎 新卒で日アイ・ビー・エムに入社し、大手銀行向け業務アプリケーション開発に携わる。4年後にビズリーチに転職。社外サービスや社内業務システムの企画・開発を担う一方で、「ドメイン駆動設計」についてブログなどで発信し、勉強会も数多く主宰。DDD普及活動を通じて知り合ったログラスに転職し、EMを務める 株式会社ログラス エンジニア 雄太 新卒で人材系ベンチャーに入社し、インフラ責任者やテックリード、新規事業開発などの業務を担う。 2021年11月、ログラスに入社。スクラムチームのリーダーとして、チーム改善の推進や開発のリードを担う アジャイル開発の普及により、その関連手法であるドメイン駆動設計(Domain-Driven Design:以下、D

    組織が拡大しても質の高いDDDを守れるか?ログラス松岡氏・村本氏に聞くDDD浸透の切り札
    JGEEM
    JGEEM 2023/09/19
    目指すべきは"DDDのプラクティスを活用したら、困っていることを解決できた"という体験の伝播。そのために伝道師は率先垂範する必要があるけれど、、
  • 1