遅ればせながら、5月28日に参加したISE Technical Conference 2009の感想を。
自分が参加したのは、「インフラ・アーキテクチャー設計の実践」というセッションでした。
担当は弊社の大津留 史郎 氏。
大津留氏の柔らかい物腰、というか語り口で始まったこのセッション。
会場をさっと見渡してみると、やはりITアーキテクトの方が多いせいか、平均年齢はやや高めでした。
最初のお題目は、"インフラ・アーキテクチャーの設計方法"。
コンテキスト図や非機能要件の位置づけ・考え方についての講義をいただいたが、ここはまあ、なるほどという感想だった。
システムの内部と外部の境界を明確化する、というのは、実業務でも様々な場面で有効かもしれない、と一人反省しました。
一番、面白いと感じたのは大津留氏の経験談を交えた以下の章。
なるほど、生身の感想だな、と共感できました。
■あいまいな要件をどう扱うか
４つの原則を大津留氏は挙げているので、そこに自分の感想も付け足して書いてみました。
原則1：根拠となる業務（経営）上の目標が明確化されるべきである
→実際には、現場の担当者レベルでは、そのような目標が伝えられることがない。または、目標より先に作業が進行させられており、目標が変更されてすべてがひっくり返ることがある。
原則2：検証可能な達成基準が定義されるべきである
→上記のように、あいまいにスタートするものが多く、達成基準は不明確な場合が多い。承認したはずなのに、追加の作業を依頼してくる。
原則3：要件のオーナー（ステークホルダー）が明確にされるべきである
→上記のように、承認した人がステークホルダーではないと、いろいろな前提が覆る。現場担当もステークホルダーから承認を得たいと心底思っているが、日本社会の階層構造が高い壁となり？、そう簡単にはいかない。
原則4：すべての要件と制約は、必ずしも整合性のあるものではなく、対立し得るものである
→何を優先して、何を犠牲にするのか、その理由は？、誰が承認したのかを誰の目からも明らかにする必要がある。でないと、何も決まらないし、進まない。たいていは待っていてもお客様も誰も明確にはしないので、自分で作成する必要がある。
■アーキテクチャーは本当に必要なのか
「アーキテクチャーっているのかな」という疑問から色々と調査したとのことで、生の感想が非常に興味深かったです。確かに、現場においては実際にシステムを構築している側からみると、「ごちゃごちゃ言ってないで、手を動かす」、「担当者が分かってるからいいだろう」と考えてしまいがちです。
しかしながら、アーキテクチャーの設計も明文化もできてない場合、極端に言えば担当者が代わるだけで、混乱を来たすことになってしまいます。
重要であることは誰もが理解してはいるんですが、なかなかスピード感に合わない部分や、個々人の能力・胆力で考え抜かなければいけないところ。
やっぱ頭使わなきゃいかんですよねぇ…＾＾；
とにもかくにも、アーキテクトのいない現場が多いSI業界で、ついつい普段の仕事で俯瞰的なアーキテクチャまで意識した取り組みを自分自身できていないのを痛感しました。
論理的な思考が重要、というのも分かってはいますが、ロジカルシンキングに基づいて、実際の場で発言するに及んでいないのが問題。そろそろ自分で物申していく時期にきているかな、と感じます。
とはいえ、タイムリーに良い議論を持ち込むには、自分自身はもう少し思考速度を上げないと、先回りもできません。そこも今後の課題だな、と。
ITアーキテクトへの道は険しいですね。
セッション概要
ISE Technical Conference 2009
ITアーキテクチャー設計の実践においては、標準化された設計手法を個々のプロジェクトの状況、システムの特性および検討テーマに合わせてカスタマイズして適用する、ITアーキテクトの能力が問われます。当セッションでは、IBMのインフラ・アーキテクチャーの設計手法であるオペレーショナル・モデリングの手法を紹介すると共に、インフラ・アーキテクチャー設計の実践におけるポイントについて解説します。
