信頼されるITスペシャリストへの道！ [まぐまぐ！]

2009/04/07

【信頼されるITスペシャリスト第45号】ITアーキテクトサミット 2009

■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□
┌───────────────────────────── 2009.04.07
│
│ 信頼されるITスペシャリストへの道！第45号
│
│ http://blog.livedoor.jp/brave33/
│
│ メルマガインデックス−過去のメルマガ一覧
│ ⇒ http://blog.livedoor.jp/brave33/archives/50529551.html
└──────────────────────────────────
■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□■□

　こんにちは MICK です。

　2月18日「ITアーキテクトサミット2009」に参加してきました。

　もう１ヶ月以上経ってしまっていますが、最近のITアーキテクトが考える、
　実践に移しているIT動向などを簡単にまとめておきたいと思います。

　今回のキーワードは「企業のアジリティ向上」です。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　<PR>　転職希望、自分の市場価値を知りたい方に朗報です！！
　　　「信頼されるSEへの道」が自信をもって、エージェントを推薦します
　　　⇒　http://blog.mag2.com/m/log/0000208094/107875439.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【信頼されるITスペシャリスト第45号】ITアーキテクトサミット 2009

●「アジリティ」とは？

　「アジャイル」という言葉は以前からよく目にしますが、これは「俊敏な、
　すばやい」などという意味合いの言葉から「アジャイルプログラミング」を
　さすイメージが固まってきたようです。

　Wiki:アジャイルソフトウェア開発
　=>http://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA

　もともと米国でもこの「アジャイル」という言葉はあまり使わないように
　思いますが、すでに「アジャイル」＝「アジャイルプログラミング」をさす
　というのが一般的になってきたこともあり、

　区別する意味で「アジリティ(軽快さ、機敏)」としたとなっています。

　簡単にいうと、形容詞と名詞の違いだけで意味は同じです。
　イメージの問題だけで、言い回しを変えたということのようです。

●「企業のアジリティ向上」に向け

　企業の業務は俊敏さを求められます。

　ただし、現状は相反する作業も求められるため、システム担当者は
　その解決策を試行錯誤している状態です。

　まず、コンプライアンスや監査、個人情報保護などの制約なしで作った
　ものや企画したものを次々に繰り出し、現場判断で突き進むことが
　できない状態にもなっています。

　IT部門でも、ほんとうにちょっとしたシステム変更なのに、リリース
　タイミングが２週間も先、というようなことがよく見受けられます。

　たとえば、画面や帳票の項目追加、キャンペーン用に簡単な改修を
　求められたとします。

　開発自体は10分程度だとしても、リリースまでの道のりが長いのです。

　まず、案件リクエスト、ユーザ要件精査、関連項目/影響度調査、
　開発（DBレイアウト更新、バッチ処理更新、仕様書アップデートなど）、
　テスト環境の使用可能時期の確認、システムテスト、ユーザテスト、
　バージョン管理、リリース管理、オペレーションマニュアル更新、
　関連システムの調整、監査書類チェック、本番アップ前レビュー、
　本番アップ可能時期の確認、本番停止の必要があればその調整、、、
　などなど。

　簡単に思いつくだけでも、これだけの作業が出てきます。

　変更10分、リリース関連や調整タスクが10人日かかってしまう、
　というのもこうした作業内容から見えてきます。

●個人の能力に依存したくない

　今までの開発や設計は個人のスキルや経験値の高さで補われるものだと
　考える風潮がありました。

　ただし、実際にドキュメント化や仕様の策定、要件の洗い出しなどで
　大量のあいまいさと戦う必要があったわけです。

　だが、個人のスキル依存をなくし、ビジネス要件やルールをシステムと
　整合性を取りながら仕様バグをなくし、変更管理も容易にしていきたい。

　今はそれらをUML、ツールやリポジトリなどを使ってあいまいさを排除し、
　ユーザだけでなく、開発者との意思疎通などを迅速、正確に行うことを
　目標としています。

　すでにいくつかのプロジェクトや会社単位、ベンダー単位では正確な
　仕様策定や標準化が進んでいるようですが、迅速な開発と本番への反映
　といった部分では、いくつものチャレンジが続いている印象です。

　これらの仕様リポジトリの一元管理という意味でもIBMをはじめ、仕様
　リポジトリをつかった影響範囲、関連機能の洗い出しといった作業を
　自動的に行えるようなツールも出てきています。

　属人的な仕様管理を避け、品質を一定レベルに保ちたい、という思惑が
　ベンダー全体に働いているようです。

●チューニングも属人的にしたくない

　ここで出た話の中で、データベースやアプリケーション自体も属人的な
　チューニングを避けたい、というものです。

　つまり、デフォルトでインストールして、そのままの性能で使い、パワーが
　足りなければ、ハードウェアで補えばよい、という考え方です。

　アプリケーションやデータベースですから、ある程度のパラメータ調整が
　必要になるのは当然ですが、特殊な設定やカリカリのチューニングを避け、
　一般的な性能で運用していこう、という考えです。

　ハードウェア自体が安くなってパワーアップしてきたことも背景にあると
　思いますが、チューニングの手間とリスクを避け、ハードウェアのコスト
　見積りなども簡素化され、ここでも属人的な差が少なくなるというものです。

　最終的にはプログラム自体も属人化をやめ、GUIでクリックするだけで、
　自動でコードジェネレートし、誰がやっても同じ状態になり、変更内容が
　すぐに分かり、バージョン管理や依存関係の洗い出しもすぐにできると
　いう優れものを目指しているというものです。

　一部では非現実的であるという意見もある一方、トライ＆エラーを繰り返し
　ながら、これに近い管理が行われている例もあるようです。

　残念ながら、今すぐだれでもどのベンダーでも使えるというわけでは
　ありませんが、現在のアプリの進歩を見ていると、確実にそのレベルに
　近付きつつあると感じます。

●終わりに

　もちろんこうした変更はユーザを一歩ITに近づける必要があり、究極は
　ユーザと開発者がイコールになることと力説するセッションもありました。

　ITアーキテクト目線から見ると、SEの仕事やプログラマの仕事内容が少しづつ
　変わるのではなく、ある日突然、劇的に変化を遂げる可能性を感じます。

　厳しいようですが、今までプログラミングだけでやっていけると思っていた
　エンジニアたちはもう一度、自分のスキルやキャリアの見直しを行っておいた
　方がよいかもしれません。

　単純作業や力仕事に近いと思うもの、誰がやってもできそうなもの、などは
　要注意と考えておいた方がよさそうです。

　また、プロマネや要件定義、ビジネスアナリストなど差別化されている仕事や
　インド、中国オフショアに取って代わりにくい仕事やスキルなどを再考して
　おいた方がいいかもしれません。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

　ご感想やご希望などありましたら、以下までメールください。
　なにぶん忙しいので、全てに返信はできないかもしれませんが、
　全てのメールに目を通すようにします。

　また、ブログを準備しましたので気軽にコメントをお寄せください。

　※セミナー講師、新人研修の講師、コンサルティング依頼などについても、
　　以下までメールでお願いします。

　 ⇒ メールアドレス： vjyscre@yahoo.co.jp

　 ⇒ ブログ： 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
　【第37号】食料品不足なのにバイオ燃料？ 2008.1.15
　【第38号】HD-DVD、ブルーレイ・ディスクもまけ？ 2008.1.27
　【第39号】進化するコールセンター 2008.2.21
　【第40号】共感力 2008.6.24

　【第41号】当たり前の順番？ 2008.7.13
　【第42号】家電のガラパゴス化とIT 2008.10.25
　【第43号】自分から動く 2009.1.14
　【第44号】正しい決断 2009.1.20
　【第45号】ITアーキテクトサミット 2009 2009.4.7
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

＜お薦め書籍＞

　マッキンゼー流図解の技術
　→http://www.amazon.co.jp/gp/product/4492555226/000jp-22

　マッキンゼー流プレゼンテーションの技術
　→http://www.amazon.co.jp/gp/product/4492555277/000jp-22

　ITアーキテクト x コンサルタント未来を築くキャリアパスの歩き方
　→http://www.amazon.co.jp/gp/product/4797334533/000jp-22

　最新会議運営の基本と実践がよ〜くわかる本
　―ファシリテーションのテクニック満載!−
　→http://www.amazon.co.jp/gp/product/4798016004/000jp-22

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
日本一キーストロークの短いアドレス！！
↓アドレスを短く簡単にします。↓
⇒ http://000.jp/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

.