高凝集性と低結合性で、スケールする組織をつくる
こんにちは！ このトピックスは、「組織と経営のデザイン」を取り扱います。 前回は、もっともベーシックな組織デザインのテーマ、 「ピラミッド型か？サークル型か？どちらの組織形態を選ぶべきか？」 について考察し、「ピラミッド型が良い」が現状の回答になることを見てきました。 前回の記事にたくさんのコメントをいただきました。ありがとうございます！みなさんのコメントを通じて学ぶのがとても楽しいです。 今回は、「凝集性と結合性」という組織をスケールさせる上でもっとも重要な概念を解説していきます！ なんか、名前だけだと難しそうですが、かなりシンプルな概念です。 この2つを抑えておかないと、スケールする組織はつくれないと断言できますし、Amazonなどのビッグテック企業は、この2つの要素を抑えたスケーリングがとても秀逸であると思います。 「企業が成長して大企業になり、調整に忙殺されるようになり、働くよろこ
ITエンジニアのアウトプット（情報発信）に関する対談記事が公開されました - give IT a try
お知らせ NewsPicksさんに「なぜエンジニアは、惜しみなく知見をシェアするのか？」という対談記事を掲載していただきました。 ちょまどさんとの対談記事が公開されました。ITエンジニアのアウトプットについて、ざっくばらんにお話しています。ぜひ読んでみてください〜！ なぜエンジニアは、惜しみなく知見をシェアするのか？ https://t.co/OWJjQYBzSQ— Junichi Ito (伊藤淳一) (@jnchito) 2022年6月30日 対談のお相手はITエンジニア兼マンガ家のちょまどさんです。 このご時世にしては珍しく、オンライン対談ではなく、リアル対談を行いました（コロナ禍以来、外で人と会ったのは数年ぶりかもしれない・・・）。 どんなテーマで対談したの？ 対談のテーマはずばり「ITエンジニアのアウトプット（情報発信）」でした。 記事の見出しはこんなふうになってます。 情報発信
全員野球からPagerDutyまで。NewsPicksのオンコール体制はどう進化してきたか。 - Uzabase for Engineers
こんにちは！NewsPicksエンジニアの森川です。今回はNewsPicksのオンコール(=障害対応)体制の変遷と試行錯誤をご紹介したいと思います。 オンコール1.0 ~ 全員野球時代 ~ オンコール2.0 ~ 当番制時代 ~ 1. 専門外のアラートに対応できない 2. 対応するエラーの数が多すぎる 3. 勤務時間の自由度が減る 4. slackに気づけない オンコール3.0 ~ PagerDuty時代 ~ 1. アラートを緊急度で仕分け 2. 当番ローテーションの変更 3. PagerDutyの導入 おわりに オンコール1.0 ~ 全員野球時代 ~ NewsPicksにはエンジニア全員が入るslackチャンネルがあり、ここで周知事項の共有や雑談、問い合わせがされています。昔はこれに加え不具合の報告や監視システムからのアラート通知もこのチャンネルに流れるようになっており、アラート通知は気づ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜエンジニアは、惜しみなく知見をシェアするのか？
