Vsug architect academy_sakakibara_20101016
2. 自己紹介 1986年日本アイ・ビー・エム株式会社入社。以来，主にサービス部門にて， SEとして銀行，新聞社，電子部品メーカー，自動車メーカーなど多数のプロ ジェクトに参画。専門はアーキテクチャ設計技術。2006年から同社東京基 礎研究所にてサービス・ソフトウェア・エンジニアリングの研究に従事した後， 2008年1月よりグローバル・ビジネス・サービス（GBS)事業に帰任。 現在全世界のエンタープライズ・アーキテクチャ＆テクノロジー部門の責任者兼， GBS事業技術統括CTO。IBMディスティングイッシュト・エンジニア（技術理事）。 著書：「SEの基礎知識 アプリケーション開発技術」（共著，リックテレコム），「ソフトウェ ア品質知識体系（SQuBOK）ガイド」（共著，オーム社），「ITアーキテクトになる方法」 （翔泳社 予定） 訳書：「MDAモデル駆動アーキテクチャ」（共訳，エスアイビー・
2008-02-15 - ひがやすを blog - アーキテクト以外は「限定されたことだけやっとけ」
> 私の個人的な意見としては、一部の人(例えばアーキテクト)だけ、 > フレームワーク全体を把握していて、残りのメンバーは >「限定されたことだけやっとけ」みたいなことは好きではありません。 大規模だと好き嫌いに関わらずこういったアプローチになるのでは？ アーキテクト以外の学習コストはむしろ減ると思いますが… きっとこのコメントを書いてくれた人は、本気でこう考えているんだと思いますが、私は、このようなアプローチが嫌いというだけではなく、効率が悪いと思っています。 一番の理由は、開発者のモチベーション。「限定されたことだけやっとけ」という状況で、開発者のモチベーションが上がるとは思えません。実際、モチベーションは下がるでしょうから、それにあわせて、生産性も落ちるでしょう。 二番目の理由は、開発者が成長しないこと。開発者というのは、いろんなプロジェクトに参加し、いろんな経験をつみながら成長して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://coin.nikkeibp.co.jp/coin/itpro-s/seminar/sys/1105/
