デブサミ2019夏【A-4】ソフトウェアアーキテクチャの組織力学 #devsumiA #devsumi

0
かつひささん @katsuhisa__

社会をとりまく目に見えない力を生み出す構造がアーキテクチャ よくすることができるというのは、交換可能ということ 選択肢を持つほうが強く、持たないほうが弱い #devsumi #devsumiA

2019-07-02 13:28:26
seiga(林 星河) @seiga_hayashi

プロジェクト、ビジネスモデル、組織構造といったパースペクティブがアーキテクチャを構成する。技術要件に詳しいだけとか、ビジネスにフォーカスない視点でアーキテクチャを決定すべきでない #devsumi #devsumiA

2019-07-02 13:28:35
yasaichi @_yasaichi

アーキテクチャとは、何かをしにくくする代わりに、何かをしやすくする構造。Webアプリケーション開発のフレームワークもこれに当てはまる。この講演では、社会に取りまく目に見えない力をアーキテクチャと定義して話を進めていく #devsumi #devsumiA

2019-07-02 13:28:37
諏訪真一 @suwa_sh

アーキテクチャとは 何かをしやすく/何かをしにくくするもの 社会をとりまく目に見えない力を働かせるもの #devsumiA #devsumi

2019-07-02 13:29:35
諏訪真一 @suwa_sh

良くすることができる = 交換可能 選択肢を持つ側 権力 選択肢を持たない側 依存 この依存による理不尽がアーキテクチャ #devsumiA #devsumi

2019-07-02 13:29:41
MiuraKatsu @MiuraKatsu

#devsumiA #devsumi 選択肢を持つほうが強く、持たないほうが弱い ・モテる異性との恋愛 ・属人化した業務 ・エンジニア求人

2019-07-02 13:29:43
いくお/IkuOODA @dora_e_m

選択肢をもつほうが強く、もたないほうが弱い。→弱いほうに生まれる理不尽が技術的負債の正体 #devsumi #devsumia pic.twitter.com/MFnRf0JH2T

2019-07-02 13:30:05
拡大
諏訪真一 @suwa_sh

選択肢を持つほうが強く、持たないほうが弱い モテる異性との恋愛 かぐや姫 属人化した業務 エンジニア求人 tweetしたらランチに誘われたり #devsumiA #devsumi

2019-07-02 13:30:08
02 @cocoeyes02

よくすることができる=交換可能 依存すること(交換しにくくなり)で理不尽が生まれる。 この依存による理不尽が技術的負債の正体で、交換可能であるというメリットがアーキテクチャの正体 理不尽はいつも選択肢の少ない方にかかる #devsumiA

2019-07-02 13:32:20
MiuraKatsu @MiuraKatsu

#devsumiA #devsumi ソフトウェアアーキテクチャにおいて交換可能性が重要 ・自動テストとデリバリパイプライン  →コードを修正するハードルを下げる ・Infra as Code / Disposable Component  →再構築や廃棄が簡単 交換可能性という補助線を引くと、良いアーキテクトが見えてくる

2019-07-02 13:32:28
かつひささん @katsuhisa__

ソフトウェアアーキテクチャにおいても交換可能性が重要 めちゃわかる。 #devsumi #devsumiA

2019-07-02 13:32:42
Niwa Takeru|アセンド取締役CTO @niwa_takeru

広木大地さんの話を聞くと、すごく哲学的だなと思う。 物事を汎化してエンジニアリング・組織論に結びつける力がすごくあると思う。 #devsumiA

2019-07-02 13:33:50
MiuraKatsu @MiuraKatsu

#devsumiA #devsumi プロジェクトマネジメントの本質的複雑性 2つの依存関係によりクリティカルパスが存在する ・前後の依存性:前の仕事が終わらないと次に進めない ・リソース依存性:この人じゃないとこの仕事ができない

2019-07-02 13:34:13
かつひささん @katsuhisa__

ソフトウェアプロジェクトの依存関係は自明ではない ・前後依存性 ・リソース依存性 ・見積り不確実性 ソフトウェアプロジェクトにおいては、同じものをつくることはほとんどないし、依存関係が建築ほど自明ではない。 #devsumi #devsumiA

2019-07-02 13:34:37
諏訪真一 @suwa_sh

ソフトウェアアーキテクチャにおいて交換可能性が重要 自動テスト、デリバリパイプライン、Infra as Code 失敗してもすぐにもとに戻せる ユニットテスト、API仕様を満たしている限り交換可能 #devsumiA #devsumi

2019-07-02 13:34:49
MiuraKatsu @MiuraKatsu

#devsumiA #devsumi ・同じものをほとんど作ることはない ・依存関係が建築等ほど自明ではない ・見積もりの分散が大きい 依存性や困難性に対して、常に選択肢を持ち続けるように アーキテクティングするのがプロジェクトマネジメント

2019-07-02 13:35:40
seiga(林 星河) @seiga_hayashi

依存性や困難性に対して、常に選択肢を持ち続けるようにアーキテクティングするのがプロジェクトマネジメントのお仕事 #devsumi #devsumiA

2019-07-02 13:36:21
かつひささん @katsuhisa__

プロジェクトの依存関係:タスク同士の依存関係を持ち、かつ時系列。 プロダクトの依存関係:抽象と具体の間に依存関係がある #devsumi #devsumiA

2019-07-02 13:36:29
MiuraKatsu @MiuraKatsu

#devsumiA #devsumi ・プロジェクトの依存関係  →時間 ・プロダクトの依存関係  →抽象から具体 これらはゆるやかな相関関係がある

2019-07-02 13:36:45
おーしろ @notakaos

A-4: 広木さんのセッションを聴講。話がおもしろい(`・ω・´) #devsumiA #devsumi

2019-07-02 13:36:51
yasaichi @_yasaichi

前後依存性、リソース依存性、見積もり不確実性がソフトウェアプロジェクトの依存関係を構成する。これを覆すためにモックサーバーやインターフェイスの設計、教育による属人性の排除、プランBの用意などの様々な手段によって選択肢を確保し続けるのが良いプロジェクトマネジメント #devsumi #devsumiA

2019-07-02 13:37:07
Niwa Takeru|アセンド取締役CTO @niwa_takeru

・自明性が高い状態では計画主義的プロセスが適している=WF ・自明性が低い状態では漸進的プロセスが適している=スプリント #devsumiA

2019-07-02 13:38:51
yasaichi @_yasaichi

計画主義的プロセスと漸進的プロセスは依存関係をどのタイミングで発見できる|するか、という点が異なる。前者は最初に自明な場合に有効で、後から並列度を上げることができる可能性がある。後者は後から抽象構造を発見するためのものなので、継続的なリファクタリングが前提となる #devsumi #devsumiA

2019-07-02 13:40:15
MiuraKatsu @MiuraKatsu

#devsumiA #devsumi プロジェクトの変化に連動して、抽象構造のパラダイムも変化している ・再利用性から交換可能性に ドメイン駆動設計などはそういった設計論

2019-07-02 13:41:36
かつひささん @katsuhisa__

オントロジ的な抽象の話、聞きながら頭で考えていたら置いていかれたw あとで資料読み返しながらハラ落ちさせるw #devsumi #devsumiA

2019-07-02 13:42:01