「はじめてのAWS設計でやりがちな失敗パターンまとめ」について発表しました #devio2020 | DevelopersIO
西澤です。クラスメソッドに入社してからおよそ5年間クラウドの推進やAWS技術に関する支援をさせていただいております。この経験を何か形にしたいと思い、少し遅れてしまったのですが、Developers.IOイベントに乗じてまとめさせていただきました。 発表資料 資料はこちらにアップロードしております。 夜間に録音したので覇気が無い感じになってしまいましたが、動画はこちらです。 まとめ 「AWS設計でやりがちな失敗パターン」というタイトルで考え始めたのですが、もっともお伝えしたい点は、AWSを利用されるお客さまのマインドセットを変え、クラウドを活用できる組織に変わって欲しい、というところに集約できるかなと思います。技術的な問題以上に、考え方を変えられないこと、組織を変えられないことが、クラウド活用を阻害するアンチパターンになっていると思いました。 どこかの誰かのお役に経てば嬉しいです。
AWS クラウドサービス活用資料集 | AWS 公式
アマゾン ウェブ サービスの公式イベントのアーカイブおよびオンデマンドコンテンツの動画や資料がご利用いただけます。
オレの理想の組織
2015/08/27 22:00 「 サービスがある程度完成してるクッ○○○○にエンジニアが居ついている理由も興味ある 」 サービスの大まかな形ができあがるとエンジニアは新しい何かを求めて辞めてしまうことがあると思っているので、ふと不思議に思いました。 ※念のため言っておくと今自分が属しているエンジニアチームはサービス立ち上げ前から1人も辞めていません（もっといえばその前の動画共有サービスを旅する元AWSエバンジェリスト？から 押しつけられて もとい、引き継いで以来6年間誰も辞めていません。あくまでも現時点では…だけれども）。 理由も とあるのはもう一つ興味のあることが同時にあって、 「 あれ？D○N○ってフラット組織なの？あの規模でどうなってるのか興味ある 」 上意下達というか、上司がいて部下へ仕事を振っていく組織は、上司がふたになってしまって良くないと思っています。とは言っても、各プレ
スケールする開発組織の作り方 #jawsug
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
