2007/12/31
【信頼されるSEへの道 第36号】ITアーキテクトサミット 2007 Winter(2)
■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□ ┌───────────────────────────── 2007.12.31 │ │ 信頼されるSEへの道 〜成長し続けるために〜 第36号 │ │ http://blog.livedoor.jp/brave33/ │ │ メルマガインデックス−過去のメルマガ一覧 │ ⇒ http://blog.livedoor.jp/brave33/archives/50529551.html └────────────────────────────────── ■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□ こんにちは、MICK です。 2007年最後の発行となりました。 年末年始休暇で自宅でご覧になっている方が多いのでしょうね。 今年はいろんな意味で価値観や興味が変わった年でした。 IT関連ですと、システム開発そのものよりも、ビジネス部分、設計部分など、 前段階の比較的手間の掛かる部分にフォーカスが大きく移りました。 ビジネスロジックの要、不要、システム設計前の必要な機能の洗い出し、 パフォーマンス、運用など、システムの肝というところばかり考えてました。 さて、今回も『ITアーキテクトサミット 2007 Winter』の続きで、ITの スペシャリストにビジネスを教え、ビジネスアーキテクトなる企業の求める 人材を育てる、という話をお届けしたいと思います。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ <PR> 転職希望、自分の市場価値を知りたい方に朗報です！！ 「信頼されるSEへの道」が自信をもって、エージェントを推薦します ⇒ http://blog.mag2.com/m/log/0000208094/107875439.html ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【信頼されるSEへの道 第36号】ITアーキテクトサミット 2007 Winter(2) ●システム導入の前段階が大事!! 何年も前からよく指摘されることですが、何をどうしたいか分からないが、 周りがシステム導入しているから、うちも、、、みたいなものはやめた方が よい、と言うものです。 システムが導入されれば、全てハッピーでうまく仕事が流れる、みたいな ことを考えてしまう、というものです。 最近ではここまでひどい話はだいぶ聞かなくなりましたが、実は個別の業務や 大規模なシステム導入案件の初期段階では、程度の差こそあれ、似たような 状況があります。 ●手で回らないものは、システム化しても回らない よくこういう方がいらっしゃいます。 「ちゃんと説明できて、つじつまが合ってるんだから、そのままシステムに すればいいじゃないか。」 ですが、複雑なパズルのような仕組み、分岐の多い仕組みをそのまま システムに取り入れたらどうなるか、、、 この辺りにいくつか誤解が生まれやすいのです。 お客さんがこう言ってるから、、、 業務はお客さんの方が詳しいから、、、 確かに個別の業務やその会社での運用は、担当者の方が詳しいです。 その会社での一つの定型化した答だと思います。 ですが、その当たり前となった運用がシステムに最適か、とは別の話です。 そうここで、お客さんの言うとおりに設計したら、まともに動かなかった、 となるわけです。 ●システム導入には、それにあったビジネスモデルがある つまり、一度手で回して、しっかりその業務が回ること、無理がないこと、 要求に見合った動きができるかどうかを確認する必要があるわけです。 それをたたき台にして、システムに見合うはずのビジネスに見直しを行い、 再度、手で回してみる。 こうして、システム設計の前段階を整理しておく必要があるのです。 ポイントは机上ではなく、実際に回してみることです。 ●実はこうしたマインドをもった人材を求めている なぜ、こうした話になったかというと、ITアーキテクトサミット 2007 Winter 「『ビジネスアーキテクト』のススメ」IBM 渡辺 隆 氏のセッションで、 開発経験のある ITスペシャリストにビジネスを教え込み、こうした ビジネスアーキテクトのような、システムの前段階を含めて提案できる人材を 育てているという話があったからです。 つまり、企業は単なるシステム開発ではなく、ビジネスの再構築を含めての システム導入、リエンジニアリングを求めているのです。 今後、こうした傾向はさらに強くなっていくだろう、と説明されていました。 自分もそうなっていくだろう、と思っています。 つまり、中国やインドなど海外での安価な開発が増えるにつれ、我々の 開発者としての価値は下がっていきます。 設計も特別な設計でもない限り、海外に移行していく可能性が高そうです。 そうなると、我々特有の付加価値が必要になってくるわけです。 その多くの部分がビジネスルールになるだろうというのです。 ただ、やはりここでのポイントは「IT に詳しくて、ビジネスの分かる人」 だと強調されていました。 開発や設計経験は必須だとも、念を押されていました。 皆さんはどう感じていらっしゃいますか？ ●終わりに 今回は「ITアーキテクトサミット 2007 Winter(2)」と題して、現在 求められているビジネスアーキテクトの話をしました。 多くの開発者の方にとっては厳しい現実であり、耳の痛くなる話だと 思います。 現在はまだ、システム開発そのものに付加価値を求められる点で SE、PG ともにそれなりの給与やポジションが得られています。 ただし、以前の汎用機の開発者などと同じ道を辿らないという保証は どこにもありません。 自分自身に新たな付加価値を付け、また日々それらをチェックしていく 習慣がないと、うまくやっていけなくなりそうです。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ご感想やご希望などありましたら、以下までメールください。 なにぶん忙しいので、全てに返信はできないかもしれませんが、 全てのメールに目を通すようにします。 また、ブログを準備しましたので気軽にコメントをお寄せください。 ※セミナー講師、新人研修の講師、コンサルティング依頼などについても、 以下までメールでお願いします。 ⇒ メールアドレス： info@yscre.com ⇒ ブログ： http://blog.livedoor.jp/brave33/ ⇒ メルマガインデックス： http://blog.livedoor.jp/brave33/archives/50529551.html ⇒ 登録・解除はこちら http://www.mag2.com/m/0000208094.html SEの方々にとっても、できるだけ役に立つ情報をお届けします。 ご友人や仕事仲間の方にも、ご紹介いただけたら、と思います。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ メルマガインデックス−過去のメルマガ一覧 ⇒ http://blog.livedoor.jp/brave33/archives/50529551.html 【第1号】技術系SEの勘違い 2006.09.19 【第2号】本当に必要な新人教育 2006.09.26 【第3号】新人のときにおかれる環境 2006.10.03 【第4号】SEの常識？社会人の常識？ 2006.10.10 【第5号】信頼される上司 2006.10.17 【第6号】もう一つの組織 2006.10.24 【第7号】積極的な思考 2006.10.31 【第8号】メンバー同士の行き違い 2006.11.07 【第9号】プロジェクトのチェックポイント(1) 2006.11.14 【第10号】プロジェクトのチェックポイント(2) 2006.11.21 【第11号】プロジェクトのチェックポイント(3) 2006.11.28 【第12号】プロジェクトのチェックポイント(4) 2006.12.05 【第13号】プロジェクトのチェックポイント(5) 2006.12.12 【第14号】デバッグの方法・考え方 2006.12.19 【第15号】一年を振り返る 2006.12.26 【第16号】要件定義の重要性 2007.01.09 【第17号】要件定義から要求開発へ 2007.01.16 【第18号】要求開発−要求の分類方法 2007.01.30 【第19号】要求開発−各要求の関係 2007.02.06 【第20号】アジャイルに見る理想の開発(1) 2007.02.13 【第21号】アジャイルに見る理想の開発(2) 2007.02.20 【第22号】信頼できるパートナー(1) 2007.02.27 【第23号】信頼できるパートナー(2) 2007.03.06 【第24号】Network World Conference 2007 Spring 2007.03.13 【第25号】セキュリティ監査とポリシー(1) 2007.03.20 【第26号】セキュリティ監査とポリシー(2) 2007.03.27 【第27号】セキュリティ監査とポリシー(3) 2007.04.03 【第28号】セキュリティ監査とポリシー(4) 2007.04.10 【第29号】オフショアとSEマインド(1) 2007.04.17 【第30号】オフショアとSEマインド(2) 2007.05.01 【第31号】忙しいときこその仕事術 2007.05.15 【第32号】データ分析とジャッジメント 2007.05.29 【第33号】なぜコンサルタントを雇うのか？ 2007.07.24 【第34号】運用・メンテナンス性を考えた設計 2007.10.2 【第35号】ITアーキテクトサミット 2007 Winter(1) 2007.12.24 【第36号】ITアーキテクトサミット 2007 Winter(2) 2007.12.31 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ＜お薦め書籍＞ できる人のスピード仕事術―即効! これ1冊でスイスイ仕事がこなせる →http://www.amazon.co.jp/gp/product/4822222888/000jp-22 フラット化する世界(上) トーマス・フリードマン (著), 伏見 威蕃 (翻訳) →http://www.amazon.co.jp/gp/product/4532312795/000jp-22 フラット化する世界(下) トーマス・フリードマン (著), 伏見 威蕃 (翻訳) →http://www.amazon.co.jp/gp/product/4532312809/000jp-22 豆蔵セミナーライブオンテキスト(1) わかるオブジェクト指向 (単行本) 山田 隆太 (著) →http://www.amazon.co.jp/gp/product/4774124605/000jp-22 要求開発−価値ある要求を導き出すプロセスとモデリング 山岸 耕二 (著), 安井 昌男 (著), 萩本 順三 (著), 河野 正幸 (著), 野田 伊佐夫 (著), 平鍋 健児 (著), 細川 努 (著), 依田 智夫 (著), ［要求開発アライアンス］ →http://www.amazon.co.jp/gp/product/4822282686/000jp-22 NYPD No.1ネゴシエーター最強の交渉術 ドミニク・J. ミシーノ (著), ジム デフェリス (著), 木下 真裕子 (翻訳) →http://www.amazon.co.jp/gp/product/4894511851/000jp-22 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 日本一キーストロークの短いアドレス！！ ↓アドレスを短く簡単にします。↓ ⇒ http://000.jp/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ .
