デブサミ2011【18-C-1】なぜソフトウェアアーキテクトが必要なのか ~未知なるソフトウェアに形を与えよ~ 鈴木雄介 氏

Developers Summit 2011 セッション【17-C-1】に関するつぶやきをまとめました。 セッションを紹介したタイムテーブルは以下にあります。 http://www.seshop.com/se/timetable/2 他セッションと混ざっている可能性がありますので、参加された方は自分のツイートを追加してくださると助かります。
5
@nsiena

「アーキテクチャが安定ならマネジメント主導はやりやすい。トヨタの自動車設計の事例から。しかし、ソフトウェア開発では新しいアーキテクチャによる効率化が、繰返しによる効率化を上回ることがある。どちらで主導するかは要求に合わせて判断。 #18C1 #devsumi

2011-02-18 10:34:45
タツヤ @stand_arrow

アーキテクチャを変えない場合、マネジメント主導、ウォーターフォールモデルが合っている。変える場合は、アジャイルで #devsumi

2011-02-18 10:34:50
hiroisojp @hiroisojp

#devsumi 【17-C-1】 ソフトウェアアーキテクトは、アーキテクチャ設計を通じてマネジメントの土台を設計する。

2011-02-18 10:36:41
VM持田 @mike_neck

アーキテクトがないと何をマネージメントしていいかわからない

2011-02-18 10:36:45
タツヤ @stand_arrow

ソフトウェアアーキテクトがいないと自分の仕事がない@青くて大きい会社のPMの一言 #devsumi

2011-02-18 10:36:48
@nsiena

「変化を許容するようなマネジメントには、土台となるアーキテクチャ設計が重要。即ち、アーキテクトがいないと計画を立てられず、何をマネジメントするかを定められない。正しさを見つけるための方法を見つける。アーキテクトとマネジメントとの職能の違い。 #18C1 #devsumi

2011-02-18 10:37:16
トビー @t0v1

アーキテクトは職能としてはリーダーシップより

2011-02-18 10:37:23
猫提督ff@睦月提督 @nekoteitoku

17-C-7 従来型のアーキテクチャでやるなら従来型の管理手法でいい。新しいアーキテクチャならそれに合わせたやり方で。それを選択するのもアーキテクトの仕事かな。そうした計画に従い物事を進めていくのがマネージャー。 #devsumi

2011-02-18 10:37:25
@nsiena

「アーキテクトは PM に WBS 作成のために情報を提供せねばならない。立てられた計画の下で設計をするのは、高々フレームワーク設計が限界。アーキテクトは PM は分業しながらも、相補的である。 #18C1 #devsumi

2011-02-18 10:40:29
タツヤ @stand_arrow

リーダーシップタイプは、プログラマーなど技術出身が多い #devsumi

2011-02-18 10:40:31
hiroisojp @hiroisojp

#devsumi 【17-C-1】 アーキテクチャは、父 マネージャは、母

2011-02-18 10:41:19
猫提督ff@睦月提督 @nekoteitoku

17-C-7 プログラマあがりは交渉能力がない?プログラマのキャリアパスの問題かな。アーキテクトは父、マネージャーは母。アーキテクチャがしっかりしていればマネージャーだけでいいよ。 #devsumi

2011-02-18 10:41:24
hiroisojp @hiroisojp

#devsumi 【17-C-1】 なんか、PMとアーキテクトって呼び方かえた方がいいなぁって思った。 補完関係にあるはずなんだけど、どうしても上下関係があるように聞こえてしまう。

2011-02-18 10:42:46
takano @mtknnktm

再利用の原則: 同じことをやるために複数の手段があると混乱する.ワードのフォント変更とか.#devsumi

2011-02-18 10:42:56
@0x22F1

渦を作る=influence。 #devsumi

2011-02-18 10:43:05
ْ @pepeky

RT @nsiena: 「変化を許容するようなマネジメントには、土台となるアーキテクチャ設計が重要。即ち、アーキテクトがいないと計画を立てられず、何をマネジメントするかを定められない。正しさを見つけるための方法を見つける。アーキテクトとマネジメントとの職能の違い。 #18C1 #devsumi

2011-02-18 10:43:26
@nsiena

「ユーザとアーキテクトの関係。ユーザとビルダの間には越え難い壁がある。使うこと=ビジョン・要求・要件を外圧、作ること=戦術・設計・実装を内圧のせめぎあい。これを繋ぐこと=アーキテクチャ・戦略・バランスを与えよ。中立の立場からバランスを取る。 #18C1 #devsumi

2011-02-18 10:45:04
猫提督ff@睦月提督 @nekoteitoku

17-C-7 ユーザーとビルダーの間の超えられない壁を外圧と内圧に例える。そこにトレードオフがあればアーキテクトが取捨選択する。戦略的なことはアーキテクトが、実践はマネージャーがやる。アーキテクトは一歩引いたところで中立的立場で判断する。ここ重要 #devsumi

2011-02-18 10:45:17
hiroisojp @hiroisojp

#devsumi 【17-C-1】 アーキテクトは、常に中立(中途半端) 他にとらわれず、自身の判断で行動していく必要がある。

2011-02-18 10:45:31
VM持田 @mike_neck

アーキテクトはいろいろ悪口を言われる辛くて中途半端な仕事であるらしい。 #devsumi

2011-02-18 10:46:23
西村 一彦 @kznsmr

ユーザーとアーキテクトの設定。DDDとスクラム に注目。ドメインエキスパートの存在は不可欠。#devsumi

2011-02-18 10:47:04
タツヤ @stand_arrow

使うコトと作るコトをつなぐ手法。アーキテクチャ設計ではDDD(ドメインエキスパートとドメインモデル)。マネジメントでは「スクラム」(プロダクトオーナーとスクラムマスター)。 #devsumi

2011-02-18 10:48:35
猫提督ff@睦月提督 @nekoteitoku

17-C-7 DDD domain driven developmentとscrum、流行ってる、のか?DDってもうバズワードにしてもいいよね?というのは置いといて、ビルダーとユーザーの間を取り持つ、そこがアーキテクトの仕事。 #devsumi

2011-02-18 10:48:52
@nsiena

「繋ぐ手法: アーキテクチャ設計ではDDD。ドメインエキスパートとドメインモデルが大切。何が作られるべきかを考える。/ マネジメントではスクラム。プロダクトオーナとスクラムマスタ。アーキテクチャ主導のアジリティに適応する。 #18C1 #devsumi

2011-02-18 10:50:24
猫提督ff@睦月提督 @nekoteitoku

17-C-7 scrumでやって、と言われても困る。プロダクトオーナーをきちんと決めて差し出してくれないとダメ。そういう覚悟が発注側にもいるよ。うん、そうだといいよね #devsumi

2011-02-18 10:51:31