開発組織を分散モノリスにしないチーム分割と協働のデザイン - mtx2s’s blog
複数チームに分かれたプロダクト開発スタイルをかえって不自由に感じてはいないだろうか。チーム間に張り巡らされた無数のチェーンが自由を奪い、チームの活動を束縛する。そんな感覚だ。 組織を複数のプロダクト開発チームに分割する組織アーキテクチャは、マイクロサービスアーキテクチャに例えることができる。そこから見いだせる原則は、チームをコンポーネントとして捉え、凝集度を高く、結合度を低く設計することだ。この原則を軽視すると、チーム間の依存関係が互いをチェーンのように繋ぎ、絡み合い、組織全体を「分散されたモノリス」に変えてしまう。その結果として、チームは日々、多大な調整コストや遅延コストを支払い続ける羽目になる。 では、既存のソフトウェアプロダクト開発において、個々のチームが活動しやすい分散型組織の設計とはどういうものだろうか。あくまでも私の経験や考えに基づくものではあるが、本稿はこれをテーマに書いてみ
AWS Well-Architected ドキュメントが読みやすくなりました！！（AWS Well-Architected ドキュメントの歩き方2022） | DevelopersIO
AWS認定トレーニング講師の平野@おんせん県おおいたです。 さて、2021年に下記のような Well-Architected フレームワークのブログを書きました。 最近AWS Well-Architectedのドキュメントがアップデートされましたので、それに伴いブログも新しくリリースしました。 おもな変更点 ドキュメント構成の改善に対応 ドキュメント自体が読みやすくなりました（詳細は後述）。それに対応して、内容を変更しました。 新しい柱への対応 2021年12月に「持続可能性の柱」が追加されましたので、この新しい柱についての記事を追記しています。 尚、2022.1.9時点で日本語化されておりませんので ブログ内の見出しは、私の方で日本語訳したもの 各リンク先は英語ページ となっておりますので、ご了承ください。 はじめに AWS Well-Architected フレームワークとは AWSと
フロントエンドで長持ちするプロダクトを開発するための心構え
こんにちは、クレスウェア株式会社の奥野賢太郎 ( @okunokentaro ) です。今年もよろしくお願いします。 今回は、Reactでのクリーンアーキテクチャの採用の是非についてTwitterにつぶやいたところ、思いの外Likeが集まったため、まとめて閲覧できるようにツイートをまとめつつ、簡単に補足しようかと思います。 リアクションのもととなった記事 Webフロントエンドの開発効率を高く保つための考え方 @adwdさんのこの記事に感銘を受けて、Twitterでちらほら感想をつぶやいたところLikeやRTが予想外に集まりました。それが下記のツイートです。 筆者がツイートしたもの 補足 筆者は、元記事で言及されている『「悪い方が良い」原則と僕の体験談』や『質とスピード（2020秋100分拡大版）』は確認済みであり、『 Clean Architecture 達人に学ぶソフトウェアの構造と設計
Microsoft PowerPoint - システム思考実践B180704（映写用）ro修正
ストック ＆ フロー 追加資料 (c) Change Agent Inc. 1 システムの基本構造をつくる要素を探す • なぜ仕事時間を増やしてしまうのか？ • 「たまっている仕事（量）」に注目 • 「たまっている仕事（量） 」に直接影響を与えるのは、 「引き受けた仕事（量） 」と「やり終えた仕事（量）」 • これらをストック／フローとして構造化できる ストック／フロー 風呂の水の量 蛇口 排水口 風呂の水の量 蛇口から注ぐ水 の量 排水口から流れる水 の量 同 逆 9-1 ストック ＆ フロー 追加資料 (c) Change Agent Inc. 2 ストック／フローの表し方 ストック インフロー アウトフロー 同 逆 ストック インフロー アウトフロー ループ図 ストック／フロー図 9-2 ストック／フローの例 • 例 – 預金残高 • 預入 • 引出 – 借金残高 • 借入 • 返済
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Amazon Builders' Library
