複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ（前編）。JaSST'23 Tokyo基調講演
複雑なシステムでは、すべての要素が正しくても障害が起きる。カオスエンジニアリングから継続的検証へ（前編）。JaSST'23 Tokyo基調講演 Netflixが始めた「カオスエンジニアリング」は、現在では大規模なシステムにおける可用性向上の手法のひとつとして確立し、広く知られるようになりました。 そのカオスエンジニアリングという手法を定義したのが、元Netflixカオスエンジニアリングチームのエンジニアリングマネージャーを務めていたCasey Rosenthal（ケイシー ローゼンタール）氏です。 そのローゼンタール氏が、ソフトウェアのテストに関わる国内最大のイベント「ソフトウェアテストシンポジウム 2023 東京」（JaSST'23 Tokyo）の基調講演に登壇し、「Chaos Engineering to Continuous Verification」（カオスエンジニアリングから継続
文化からツールまでを扱ったタイトルに違わぬ大著『Googleのソフトウェアエンジニアリング』を読んだ - こまぶろ
昨年11月末に発売された『Googleのソフトウェアエンジニアリング』を読みました。 Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 細かい内容についての感想はTwitterの方に放流しているので、ブログでは簡単に。 とりあえず一周した。17章以降は基本「いやーGoogleさんすごいっす」という感じだったが、ところどころ役立つ話があったし、「エンジニアリングを発展させていった先の一つの形がこうなのか」という面白さは大きかった。逆に前半は実践的にかなり勉強になったのでちゃんと復習しよう…… #swebookjp— こま (@koma_koma_d) 2022年1月3日 全体の構成 書籍全体の構成は、以下のようになっています。 分量としては、「第4部 ツール」が最も大きな部分を占めています。 第2部から第4部に
10年エンジニアリングマネージャーをやって気づいた4つの大事なポイント 【EMはもっと自由でいい】 - MonotaRO Tech Blog
はじめに ※この記事はEngineering Manager Advent Calendar の22日目の記事になります。前日はmtx2sさんの技術的負債に対するマネジメントの記事でした。個人的には「負債上限」「負債ベースライン」の考え方良かったです。 こんにちは。モノタロウでエンジニア組織のマネージャーをしております普川(@taipuka0)です。 自分は前職から通算10年以上してエンジニアリングマネージャーを続けた後、現在モノタロウでは8人のEMのみなさんと日々ソフトウェア・エンジニアリングの現場でマネージャーとして課題解決に向き合っています。これまで色々な壁にあたり、試行錯誤を繰り返して来ました。EMの難しさを痛感したことも多々ありました。 なぜEMが難しいのか？その一つとして、エンジニアからEMにジョブチェンジした際のギャップというのがあると思います。同じチーム、現場にいたとしても
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
開発チームの責務を「エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する」としてみた話 - $shibayu36->blog;
最近開発チームの改善を行う時に、どういう目的で開発チーム改善を行うのかや、開発チームの責務は何なのかについて悩んでいた。色々本を参考にしながら、自分の中でしっくり来た責務があったので、ブログにまとめておく。 まず自分の中で、開発チームの責務は次のものであると言語化した。 エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する なぜこの責務としたか まず現代のソフトウェア開発においては、非常に不確実な状況で、顧客にとって価値があるものが何かを探索しながら、高速に価値を創出・提供しなければならない。これを満たすためには、「正しいものをつくる」ということと、「正しくつくる」ということの両輪を回す必要がある。 この時、プロダクトオーナー側と開発チーム側で分業するとすれば、やはり開発チームは「正しくつくる」ことに焦点を当てて責務を持つと良いと考えた。つまり開発速度(価
エンジニアリング組織の文化ができるまでの3年間の軌跡 - STEAM PLACE
メリークリスマスイヴ！ この記事は Engineering Manager Advent Calendar 2018 の24日目の記事です。 私 (@dskst9) が3年前、アスクルという会社のエンジニアリングチームにJoinしてから、エンジニアリング組織の文化がどのように作られていったのかというお話です。 これは、私自身のアクションと、エンジニアリングチームの一人ひとりがアクションしたことを織り交ぜて書いています。誰かがアクションし続けることで、会社は変わり続けることができるということを感じてもらえると幸いです。 この記事が伝えたいこと どんな会社でも変えることができる 組織を変えたいなら自分自身でアクションする 組織がアクションを続けると習慣となりそれが文化になる この記事が伝えたいこと そもそもどんな会社 むかし いま ふりかえる Forming（形成期） やったこと Stormi
「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
エンジニアが技術力を高めるもう一つの理由 - はてな・ペパボ技術大会を経て - 人間とウェブの未来
はてなさんと共催で行った「はてな・ペパボ技術大会＠京都」と「ペパボ・はてな技術大会＠福岡」が無事終わりました。 http://developer.hatenastaff.com/entry/2016/06/21/131302 ペパボ社内では、はてなサービスとその技術力の高さのファンが多く、はてなさんと一緒にこんな技術イベントできるなんて！！と喜んでいる人たちも沢山いましたし、僕自身もご一緒できてとても嬉しかったです。技術大会後の打ち上げも含めて、すごく盛り上がったしとにかく最高でめちゃくちゃ楽しかったです。 id:y_uukiさんをはじめ、はてなさんの若手エンジニアのスキルは圧倒的に高く、id:ichirin2501さん、id:masayoshiさん、id:taketo957さん、そして、技術大会で諸々沢山調整してくださった、id:wtatsuruさんとid:tomomiiさん、座談会をモ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Stripe Atlas: エンジニアリング組織の規模拡大に関するガイド
最高のITエンジニアリングを支える守りと攻めの「設計技術」と「SRE」 - Speaker Deck
エンジニアリングをちゃんとやる あるいは 人類の平和 について / wsa02-rrreeeyyy