タグ

組織に関するjuve534のブックマーク (30)

  • 吉祥寺.pm32_なぜ人は組織から去っていくのか?

    吉祥寺.pm32におけるトークパート「なぜ人は組織から去っていくのか?」の登壇資料です。 ■イベント情報 https://yumenosora.connpass.com/event/241175/ ■今後のイベントについてはこちら https://yumenosora.connpass.com/ ■虎の穴ラボ 採用サイト https://yumenosora.co.jp/tora-lab/

    吉祥寺.pm32_なぜ人は組織から去っていくのか?
    juve534
    juve534 2023/03/17
    ご自身の件をベースに「マズローの五段階欲求」を説明しており、自分の経験と照らし合わせやすいから、内容が入ってきやすい。
  • Platform Engineeringへの招待

    第1回 Platform Engineering Meetupで発表した資料です。 #PFEM

    Platform Engineeringへの招待
    juve534
    juve534 2023/03/13
    Platform Engineering チームにいるので参考になる内容だ。DevOps の Ops が指しているものが気になっていたので、P14 でそこへ記載があるのは嬉しかった。
  • 組織のチームワークを最大化するためにスクラムマスター職能を作りました - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは。シニアスクラムマスターの天野 @ama_ch です。 サイボウズ開発部では、2022年5月に大規模な組織変更を実施しました。詳細は下記の記事をご覧ください。 blog.cybozu.io 今回の組織変更では、職能ラインと人材マネージャーを整備した結果、新たにスクラムマスター職能が誕生しました。 記事では、スクラムマスター職能を作った背景や、現在の取り組みを紹介します。 サイボウズ開発部におけるスクラムマスター職能の定義 サイボウズ開発部におけるスクラムマスターの責務は、「チームを健全に保つことに責任を持つ役割」と定義しました。2020年版スクラムガイドには、スクラムマスターは「スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ」と書かれていますが、組織のすべての人がスクラムチームに所属しているわけではないため、チームがスクラムをしているかどうかは職責に

    組織のチームワークを最大化するためにスクラムマスター職能を作りました - Cybozu Inside Out | サイボウズエンジニアのブログ
    juve534
    juve534 2023/02/28
    職能として設ける動きは好感が持てる。"タスクに関する成果(高い顧客満足度、予算・納期の順守、高い品質など)と人に関する成果(メンバーの満足度、学習など)を両立します。" 確かにこれは大事だな。
  • アジャイルと通過点とベクトル - Mitsuyuki.Shiiba

    昨日と比べて今日一歩前進してる? もう10年以上前になるけど、計画とリソース効率を重視していた大きな組織の中で、より良いサービスづくりをしたいと、アジャイルなプラクティスやスクラムを取り入れてやり方を変えたことがある それは、うえから「アジャイルな開発をするように」とふってきたトップダウンな指示ではなくて、自分がそういうものづくりをしたいなと思ったというボトムアップな始まり(幸運なことに、少し進めていたところでトップダウンでも話が出てきたので、ボトムアップとトップダウンの両方から取り組むことになってとても良かった) そのボトムアップな改善のときに考えていたのは、その瞬間にやっていることが理想的かどうかというスナップショットじゃなくて、昨日と比べて今日一歩前進してるかというベクトルだったなと思う。まぁ、あんまり深く考えるタイプじゃないので、結果的にそうだったという側面が大きいかもしれない 計

    アジャイルと通過点とベクトル - Mitsuyuki.Shiiba
    juve534
    juve534 2023/01/19
    最後の "ずっと通過点" に書かれている内容がとても良い。必要なステップならそれで良いよね。
  • 1 年を通して理解した CTO としての職務|めもりー

    はじめにみなさん,こんにちは。めもりーです。株式会社トラーナで執行役員 CTO になってから 1 年が経過しようとしているので,来年の所作も踏まえて,そろそろ記事にしようかなと思っています。 1年間 CTO としてどうだったか正直,CTO という職務が何をするべきか,常々悩んでいます。 上記の記事のように私の中では CTO の職務というのは "技術資産を常にフル活用できる状態にすること(意訳)" だと定義しました。 もちろん,会社によっては CTO は「技術のプロフェッショナルでテックリードの上に起つ存在である」であったり「ボードメンバーの一人として,経営に携わり技術的な意思決定をする」であったり「課題を洗い出し,技術的にどのように解決できるかのリードをする」といったり,十人十色だと思っています。 その中で,私自身の答えとしては,上記の技術資産の活用であると導きだしているものです。 CTO

    1 年を通して理解した CTO としての職務|めもりー
    juve534
    juve534 2022/11/21
    納得できる内容が多いなー。言語化すごい。
  • 「EMやること多すぎ問題」が組織にもたらす弊害は?Chatworkの失敗事例に学ぶパフォーマンス最大化の秘訣【田中佑樹✖️岩瀬義昌】 - エンジニアtype | 転職type

    転職・求人情報サイトのtype エンジニアtype 働き方 「EMやること多すぎ問題」が組織にもたらす弊害は?Chatworkの失敗事例に学ぶパフォーマンス最大化の秘訣【田中佑樹✖️岩瀬義昌】 【PR】 2022.10.21 働き方 ChatworkEMチームプロダクト テクニカルマネジメントをはじめ、採用、育成、組織開発など、エンジニアリング組織のあらゆる仕事をカバーするエンジニアリングマネージャー(EM)。 その業務範囲の広さから、「やること多すぎ問題」が“EMあるある”として話題にのぼることも…。 ロールの多いEMが業務を円滑に、かつ最大パフォーマンスで進められるようになるためには、一体何から手を付ければいいのだろうか。注力すべき課題を見極める方法はあるのか。 国内利用者数No.1(※)の中小企業向けビジネスチャット『Chatwork』を提供するChatwork株式会社のプロダクト

    「EMやること多すぎ問題」が組織にもたらす弊害は?Chatworkの失敗事例に学ぶパフォーマンス最大化の秘訣【田中佑樹✖️岩瀬義昌】 - エンジニアtype | 転職type
    juve534
    juve534 2022/11/04
    頷ける良い話。横のつながりを持つのは良いアプローチそうだな。
  • 「不安に怯える普通の人」を統率するための「大本営」と「大本営発表」

    全てはこのツイートから始まった tokorotenさんのツイートの「大営」という部分。 「我々は勝っている、我々は価値がある」という常勝の発表を社内向けに繰り返す上層部というニュアンスで大営が使われているように見えます。 そもそもなぜ「大営」なる組織が必要になるのでしょうか? 体感では40人程度の組織までは、大営なしでも組織は機能します。 ところが100人を超えたあたりで抽象的な問題を扱い、非抽象的な問題に転換するための組織である「大営」が設立されます。 この記事で書きたいこと なぜ大企業で「大営」が必要とされるのか? また「大営」が「大営」であるがゆえになぜ途中でつまづくのか? という話を書いていきたいと思います。 そもそもなぜ「大営」が存在するのか? はいここから私の仮説。 大体こちらの通り、一般の人は抽象度が高い問題を抽象度が高いまま扱うことができません。 ではどう

    「不安に怯える普通の人」を統率するための「大本営」と「大本営発表」
    juve534
    juve534 2022/10/11
    デメリットばっかり目についていたけど、メリットもそれなりにあるって難しい話だな。
  • 技術選定で失敗しない、正解にする力 - クックパッド開発者ブログ

    プログラミングが好きなエンジニアの渡辺です。 先日 TechMTG という社内のエンジニアミーティングの場でお話させて頂いたことを書いてみようと思います。 表題の「正解にする力」というのは様々な意思決定に適用出来るものとして考えていますが、今回は技術選定という観点でお話します。 技術選定というと、世の中のデファクトだとか、新しい技術だとか、社内で実績のある枯れた技術とか色々な理由や基準で選ぶのが良いと、至るところで言われていると思います。 選定時に議論が平行線にならないように、判断基準を設けるべきというのもあるでしょう。 これらは重要であり、検討、準備することは必要ですが、それに加えて「正解にする力」というのも重要なのではないか?という提案です。 まず、組織における技術選定とは「正解を選ぶ」ことではないと思っています。 これはその技術選定結果はその人個人についてまわるのではなく、組織として

    技術選定で失敗しない、正解にする力 - クックパッド開発者ブログ
    juve534
    juve534 2022/08/22
    「正解にし続ける」に共感する。継続の部分が特に大事だなと思う。
  • 「職能横断チーム」の実践におけるアンチパターンと対策 - yigarashiのブログ

    近年のアジャイルムーブメントにおいて「職能横断チーム」は当たり前の概念になっています。ユーザーに価値を届けるのに必要なあらゆる機能をチームが備え自律的にコントロールすることで、リードタイムを短縮するとともに、イノベーションが起こりやすい環境を作ることができます。しかしながら、7〜8人を超える大きめの集団になってくると、開発の効率を著しく下げるアンチパターンを踏んでしまうことがあります。 「職能横断チーム」の実践におけるアンチパターン そのアンチパターンとは「いつも全員一緒」です。バックエンドエンジニアだろうとアプリエンジニアだろうと、デザイナーだろうとプランナーだろうと関係なくとにかく全員です。サイロ化のカウンターとしての「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態です。その結果、10人もいる会を開いて細かい相談で時間が伸びたり、そも

    「職能横断チーム」の実践におけるアンチパターンと対策 - yigarashiのブログ
    juve534
    juve534 2022/05/17
    "「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態" あるある。極端に振りすぎないようにしないといけない。
  • 高すぎる認知負荷が生むサービスの袋小路とエンジニアリングマネージャーの役割 - yigarashiのブログ

    最近流行りの「チームトポロジー」では、フローが改善するようにチームの認知負荷をコントロールすることが述べられています。そのためには組織とアーキテクチャをうまく変化させていく必要があり、いくつか主要な考え方やパターンが紹介されています。詳しく知りたい方は以下の資料を読むと良いです。 【資料公開】30分で分かった気になるチームトポロジー | Ryuzee.com この資料は2022年3月16日の「チームトポロジーを成功させる実践方法の探求」というイベントの発表資料です。このイベントでは、上記の解説に加えて、イベント共催企業で実際にチームトポロジーを適用した様子も紹介されました。それが以下です。 チームトポロジーを成功させる実践方法の探求 - Team Topologies Study、登壇資料 課題の言語化が上手く、しかも実際に素早く変化しており、「とても敵わないな」というのが率直な感想でした

    高すぎる認知負荷が生むサービスの袋小路とエンジニアリングマネージャーの役割 - yigarashiのブログ
    juve534
    juve534 2022/03/28
    "いわゆる「服を買いに行く服がない」というやつです。一度システムが複雑化して組織や事業がそれに追いつかない状態になってしまうと、あらゆるアクションが高コストになります。" ほんこれ
  • PHPの改善 !== PHPのバージョンアップ | PR TIMES 開発者ブログ

    <? include("abc.php"); include("def.php"); include("conf.php"); include("db.php"); include("some.php"); include("what.php"); Define("NUM", 100); class super_calc extends great_calc { /* * * * コンストラクタ * * * * */ public function super_calc($initial_num){ $this->db = DB::getDb(DSN); $this->initial_num = $initial_num; } /* * * * チェック * * * * */ public add_ok($add_num){ $res = $this->addable($add_num);

    PHPの改善 !== PHPのバージョンアップ | PR TIMES 開発者ブログ
    juve534
    juve534 2022/03/11
    "それ!PHP5で!できるよ!"「確かに」という心境。安易に「リプレイスすればいいっしょ」って考えてしまうけど、今のコードをバージョンアップできるように書き換えるのも手段として覚えておきたいよね。
  • メルカリShopsでのDesign Docs運用について | メルカリエンジニアリング

    こんにちは! ソウゾウのSoftware Engineerの@ogataka50です。連載:メルカリShops 開発の裏側 Vol.2の9日目を担当させていただきます。 9日目はメルカリShopsを開発する中でのDesign Docsの運用について紹介させて頂きます。 Design Docsとは Design DocsとはGoogleなどで取り入れられているシステム設計ドキュメント手法です。開発をする前にプロジェクトの背景や目的、設計、検討した代案などをdocument化します。そしてそれを持って関係者との共有、議論を行うことによって事前に全体を考察し、精度を高め開発後の手戻りを減らすなどが主な目的になります。 例として、GoogleでのDesign Docsについては下記にまとめられています。 Design Docs at Google メルカリShopsでのDesign Docsのte

    メルカリShopsでのDesign Docs運用について | メルカリエンジニアリング
    juve534
    juve534 2022/02/25
    記載にある通り、どのレベルになったらDesign Docsにするか迷う。本能に従う。
  • マイクロサービスの失敗は技術だけの問題か――Amazonに学ぶ開発・運用組織の理想形とは

    開発と運用の理想的な関係とはどんな姿か。すでに「DevOps」という言葉は浸透しているものの、理想的な形で実践できているかとなると、話は別だ。現場ではどんな障壁があり、DevとOpsが分断されているのか。打開していくにはどうしたらいいのか。DevOpsという言葉が生まれる前から、その質を実践してきたAmazonのカルチャーにヒントがありそうだ。AWSジャパン 塚田朗弘氏に聞いた。 今回お話を伺った、アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 塚田朗弘氏 ペアで語られてしまいがちな「マイクロサービス」と「コンテナ」 Amazonには「DevOps」や「マイクロサービス」という言葉が生まれる前から、DevとOpsを統合し、システムはAPIでやりとりするという原則がある。それを長年追求するなかで、開発カルチャーを育んできた。そんなAmazonから開発と運用の理想の

    マイクロサービスの失敗は技術だけの問題か――Amazonに学ぶ開発・運用組織の理想形とは
    juve534
    juve534 2022/02/08
    "開発チームが柔軟に動けなくなるとか、自分の責任から運用を外してしまうことになります。自分が書いたコードがサーバーにどんな負荷を与えているか分からないと、いい開発はできなくなります" ほんこれ。
  • はてなの技術組織2021 - Hatena Developer Blog

    これは、はてなアドベントカレンダーの25日目の記事です。昨日は id:nabeop による Hatena Developer Blog 編集部の活動の紹介 でした。 こんにちは。CTO の id:motemen です。CTO としては、はてなにおけるエンジニア組織全体を見ています。この機会に、はてな技術組織が現在どのようであるか、について概観を書いてみます。 はてなのプロダクトたち はじめにこの話の前提として、はてなの事業やこれまでの組織について軽く触れておきます。 会社情報ページにあるように、はてなは「コンテンツプラットフォーム」「コンテンツマーケティング」「テクノロジーソリューション」という3つの分野でサービスを展開しています。それぞれ、 はてなブログやはてなブックマーク はてなブログMedia GigaViewerやカクヨム、Mackerel が代表的なプロダクトです。これらを70

    はてなの技術組織2021 - Hatena Developer Blog
    juve534
    juve534 2022/02/07
    意外と人数が少ない!オーナーシップを移譲するのは大事だよね。
  • 【松本勇気×芹澤雅人対談】SmartHR新CEO抜擢の決め手は「経営層プレゼンで語ったカルチャーへの思い」 - エンジニアtype | 転職type

    2022.01.19 働き方 芹澤雅人SmartHR勇気LayerXCTO クラウド人事労務ソフト『SmartHR』を開発運営するSmartHRの創業者で代表取締役の宮田昇始さんが1月1日付で退任。後任には取締役CTOだった芹澤雅人さんが就いた。 CEO交代を告げた宮田さんのツイートは多くの注目を集めた。中には「今回のようなCTOからCEO(代表)のキャリアが今後のトレンドになっていくのでは」と指摘する声もあった。 この度、SmartHRの社長を退任することに決めました!来年1月1日で交代します。 新CEOは現CTOの芹澤さんです! @masato_serizawa 私は取締役として残り、SmartHR 100%子会社をつくって、新規事業やります。 次は SaaS + FinTech をやるぞ〜!1人目のエンジニア募集中です!https://t.co/NmASulCwNC — Shoj

    【松本勇気×芹澤雅人対談】SmartHR新CEO抜擢の決め手は「経営層プレゼンで語ったカルチャーへの思い」 - エンジニアtype | 転職type
    juve534
    juve534 2022/01/31
    "特にここ数年は心理的安全性とか、Googleの考え方みたいなのが一般に浸透してきているので、みんなが意識していることだと感じます。" チームでワークすることが少ないと、あんまりピンとこないのかもしれないか。
  • 頼りにするのと依存するのは違うという話 - Innovator Japan Engineers’ Blog

    こんにちは、CTOの山岡(@hiro_y)です。このエントリーは「イノベーター・ジャパンAdvent Calendar 2021」の24日目の記事です。 あなたの会社に「頼りにできるエンジニア」はいるでしょうか。業務に必要なドメイン知識を持っていて、技術的にも複数領域携われる力があるような、そういう存在。 非常にありがたい存在なのですが、彼らに対して私たちはどうしても依存しがちです。この人に聞けば答えてくれる、安心感。それはいつしか依存に変わります。いつの間にか、その人なしではプロジェクトがまわらないようになっていたりしないでしょうか。その人がいるから他にエンジニアを入れなくていい、と判断してしまうこともあるかもしれません。 プロジェクトが小さいうちは、それでもシステム開発が成り立ちます。しかしプロジェクトが大きくなったり、継続性を考えなければならなくなったときに個人の力に頼りすぎてしまう

    頼りにするのと依存するのは違うという話 - Innovator Japan Engineers’ Blog
    juve534
    juve534 2021/12/24
    わかりみが深い
  • 技術選定とアーキテクトの育成について - NRIネットコムBlog

    こんにちは佐々木です。NRIネットコム Advent Calendar 2021 開催中です。しかし、内部で検討した結果、私は枠外になりました。ということで、Japan APN Ambassador Advent Calendar 2021として書かせていただきます。どちらも宜しくおねがいします。 今日のテーマは技術選定とアーキテクトの育成についてです。ITエンジニアの間には、定期的にどう技術選定するのかといった議論が出てきます。いろいろな観点があるとは思いますが、私が重要であると考えている所を簡単に述べてみます。 技術選定に銀の弾丸はない まず最初に言っておきたいのが、『技術選定に銀の弾丸はない』ということです。銀の弾丸とはIT業界でもよく利用される比喩で、英語で“silver bullet”とは「狼男を倒せる武器」が元々の意味です。それが転じて「困難を解決する決め手」という意味で使われ

    技術選定とアーキテクトの育成について - NRIネットコムBlog
    juve534
    juve534 2021/12/07
    "小さな失敗を繰り返す" ・ "次世代につなげる" どちらも最近考えていたことなのでとてもよくわかる。
  • Engineering Managerをやめた - Konifar's WIP

    この記事は Kyash Advent Calendar 2021 2日目の記事です。 2020年1月から2021年6月まで、1年半ほどKyashでEngineering Managerをやっていました。2021年7月からはロールを変えて、QAチームのいちメンバーとしてAPIのテストやテストの効率化に取り組んでいます。 EMをやめた経緯とやめた後の所感を備忘として残しておきます。 EMとしてやっていたこと 2020年にやってきたことは去年まとめました。 konifar.hatenablog.com 2021年は、共有口座やイマすぐ入金、セブン銀行出金などのリリースに向けてMobile / サーバーサイド / QAのチームでプロジェクトを進めたり、プロダクト開発フローを整えたり、エンジニア採用のリードをしたりしていました。 EMをやめるきっかけ そんな中で、3月くらいに「なんだか最近仕事が面白

    Engineering Managerをやめた - Konifar's WIP
    juve534
    juve534 2021/12/02
    一回やってみて戻ることができるの良いよね。
  • 全社員がリモートワークで働くGitLabが今日、米NASDAQ市場に上場。時価総額は約1兆2000億円に

    全社員がリモートワークで働くGitLabが今日、米NASDAQ市場に上場。時価総額は約1兆2000億円に GitLab社が米NASDAQ市場に上場を果たし、14日午前9時半(現地時間)にニューヨークにあるNASDAQ市場のオープニングベルを鳴らすセレモニーを同社共同創業者兼CEOのSid Sijbrandij氏と同社共同創業者でエンジニアリングフェローのDmitriy Zaporozhets氏が行いました。 売り出し価格は77ドルで、同社の時価総額は110億ドル、日円で約1兆2000億円となりました。 同社がサービスを提供しているソースコード管理の分野やDevOpsの分野には、マイクロソフトに買収されたGitHubという強力な競合企業がすでに存在し、それ以外にもDevOpsのためのソフトウェアやサービスを提供する企業が多数存在しています。 そうした中で、創業当初からオフィスを持たず、世界

    全社員がリモートワークで働くGitLabが今日、米NASDAQ市場に上場。時価総額は約1兆2000億円に
    juve534
    juve534 2021/10/18
    "オンザジョブトレーニング(OJT)よりも、やり方を書面に" へえー、面白い。
  • オープンでフラットな組織が突然「閉鎖的」と言われるとき|柴田史郎

    柴田(@4bata)です。「それぐらいわかるだろ・・・」が通じなくなるタイミングがあるんだなという発見です! 考えたきっかけ:「オープンでフラットだと思ってたけど、結構閉鎖的なところもある」というセリフを聞いたその人に情報が伝わってなかったのかな。私の最初の感想は「前からそうだった気がするけどな・・・」。以前から整った形で情報はちゃんと流れてない。私にとっては、今働いている会社が閉鎖的には見えてない。実際には閉鎖的な部分があるのだろう。その差を理解してみたくなった。 情報の伝わり方を単純化して考える近くにいる人には自分の活動内容や背景にある意図が勝手に届くとする。携帯の電波が届く範囲、みたいなイメージ。 接触頻度が高い人同士は、いろいろ理解できている。 人数が少ないときは、何もしなくても相互に活動内容や意図が伝わっている・自分が理解できない情報も、一緒に仕事してる隣の人に聞けば情報の背景が

    オープンでフラットな組織が突然「閉鎖的」と言われるとき|柴田史郎
    juve534
    juve534 2021/07/18
    社歴によるギャップが言語化されていて良いな。