Iasa日本支部設立カンファレンス参加メモ - 2014/09/10(水)

更新日：

2014/09/10(水)15:30～17:30に開催された『Iasa日本支部設立カンファレンス』に参加してきました。

Iasa日本支部設立カンファレンス

参加してわかったこと

  1. 海外では、ITABok（ITアーキテクト向けのBOK）や資格、研修を提供している『Iasa(アイサと呼ぶ)』という団体があり、今回日本支部を設立した。
  2. Iasaは、他の資格ビジネスを展開している団体と同様、資格や研修を提供している（ただし、一部英語のまま）。
  3. 団体としての機能、料金体系、料金毎の権限については、海外の団体に準じる。ただし有償会員の値段については、値下げ交渉を行ったので若干安くなっている？
  4. ITABokをダウンロード・閲覧したい場合、個人・法人問わず、有償会員になる必要がある。
    • 個人会員: 年会費 125US$
    • 法人会員: ITユーザー企業、ITベンダー（従業員99名以下）　年会費 25万円
    • 法人会員: ITベンダー（従業員100名以上） 年会費 50万円
  5. 個人会員の申込は、Iasa Globalから直接申し込む（英語サイト）
  6. Iasa日本支部でも研究会を立ち上げる。ただし、Iasaとして提供できるものは限られているので、研究会活動を「コミュニティ活動」と称して、参加者からの知見を集めていく。
  7. Iasaは、IPA（独立行政法人　情報処理推進機構）が整備したITアーキテクトとは無関係。IPAとの調整も行っていない。

以下、講演中に取ったメモをそのまま貼り付けておきます。

イベントの募集概要（募集サイトより引用）

<< Iasa日本支部設立カンファレンスのお知らせ >>

Iasaは北米オースチンに本部を置くビジネスとITのアーキテクチャのプラクティスとナレッジベースに強みを持ち、ＩＴアーキテクトが広く世界で確立された職業として認識されるべく、活動している世界的なNPOです。特にビジネス領域も含むITアーキテクトのスキル体系をまとめたITABoK(IT Architecture Body of Knowledge)により、ビジネス価値を創造するテクノロジー・ストラテジストとしてのビジネス・ITアーキテクトの育成に注力しています。既に世界中に２０か所以上の支部を持っており、この度日本支部の創立と共に2014年度より本格的な活動を開始しました。

Iasa日本支部では、Iasaが提唱する「ITアーキテクチャコンセプト及びITアーキテクトに求められるスキル体系」であるITABoK (IT Architecture Body of Knowledge)に基づくＩＴアーキテクチャの活動の実践を支援し、ＩＴアーキテクトの、あるいはＩＴアーキテクトを目指す方を対象とした教育も提供しています。

企業内でITアーキテクチャ活動に関わる方々やITアーキテクト育成に関心のある方々の多数のご参加をお待ちしております。

◆カンファレンススケジュール
1.開会のご挨拶
2.ビジネスを革新するITアーキテクチャ志向とは
　Iasa日本支部代表理事　塩田宏治
3.ITアーキテクチャー主導による企業変革事例
　Iasa日本支部副代表理事　中山嘉之
4.ITアーキテクトの育成と実践報告
　Iasa日本支部理事　梶川哲生
5.閉会のご挨拶

ビジネスを革新するITアーキテクチャ志向とは

  • [P7] アーキテクチャのアプローチ：戦略的ビジネスバリュー実現のサイクル
    • 『戦略立案』→『EAマネジメント』→『ポートフォリオマネジメント』→『戦略立案』→・・・
  • [P9] 『F-T-S-N』に基づいたITアーキテクチャの展望
    1. 『F』: ITアーキテクチャフレームワーク
    2. 『T』: ITアーキテクチャテクノロジー
    3. 『S』: ITアーキテクチャスキル（IASAによる）とITABOKに基づくITアーキテクチャの知識体系
    4. 『N』: ITアーキテクチャ記法（オープン・グループによる）
    • 一番重要なのはスキル。TOGAFを把握していてもスキルがなければ実践はできない。
  • [P10] フレームワーク（TOGAFとZachman）の違い
    • TOGAF: プロセス中心
    • Zachman: オントロジー（普遍的なビューとモデルの分類）
      1. フレームワークとして、レイヤー毎に考える
      2. どのレイヤーで考えるとしても、5w1hが基本
  • [P11] ITABok: ITアーキテクトスキル
    • 役割
      • エンタープライズ・アーキテクチャ
    • 4つの専門領域
      1. ソフトウェアアーキテクチャ
      2. インフラストラクチャアーキテクチャ
      3. インフォメーションアーキテクチャ
      4. ビジネスアーキテクチャ
    • 基礎的知識体系 5つの柱
      1. デザイン
      2. ヒューマンダイナミクス
      3. 品質特性（非機能要件）
      4. IT環境（アーキテクトが理解したい内容を確認できる環境）
      5. ビジネステクノロジー戦略（Iasaの中で一番強調している部分。ビジネスとITのギャップが何で、どのように埋めていくか）
    • たとえどの専門領域のアーキテクチャを担当したとしても、ビジネスとアーキテクチャの乖離については、一緒に埋める作業をしていく必要がある
    • ITアーキテクトのスキルの中で一番大事なのは『ヒューマンダイナミクス』
      • ビジネスの問題をどのように解決するかの絵を描くことが仕事
  • [P12] 企業におけるITアーキテクトの役割
    • ITアーキテクトとは、ビジネスの問題を解決できなければ意味がない
    • ITアーキテクトの主要な役割とは、組織の『テクノロジーの戦略家』である
      1. ステークホルダーと協業して、組織の戦略、プロセス、情報、『情報技術資産の全体像』を構築する
      2. 『テクノロジー戦略』により事業戦略、およびビジネス・ニーズを支援する
      3. 事業、および技術インフラ全体の技術プロジェクトを適用する
      4. テクノロジーの採用と実行を通じて、事業価値に貢献する
      5. アーキテクチャ瀬計がプロジェクトにおいて遵守されているかを監理・モニタリングする
  • [P13] EAマネジメントプロセスの組み込み
    • EAマネジメントプロセス
      1. EAガイドライン
      2. EAプリンシプル
      3. EAマネジメントプロセス
    • ビジネス＆プロジェクトマネジメントプロセスに、EAプロセスを組み込んでいく
      1. 全体アーキテクチャとポートフォリオ
        • 中期計画→予算策定
      2. プログラム／プロジェクトレベルアーキテクチャ
        • プロジェクト立ち上げ→プロジェクト計画・承認
      3. インプリメンテーション
        • プロジェクト実行→システム運用・保守

ITアーキテクチャー主導による企業変革事例

  • [P2] アーキテクチャ主導がなぜ必要か？
    • 情報システムの課題
      1. 相変わらずITコストが高止まり
      2. 経営のスピードに追従できていない（アジリティに欠ける）
      3. 基幹系システム再構築プロジェクトがしばしば炎上する
      4. 攻めの事業戦略に貢献できていない
      5. 既存システムのデータに関するトラブルがしばしば発生
    • 根本原因の解消
      1. IT部門と経営との距離を縮める
      2. 特定のITベンダーからのロックオンを解除する
      3. ベンダー丸投げを止め、ブラックボックスを可視化する
      4. ERP一色のシステム構築から、事業競争力を支えるシステムへ
    • 情報システムの変革
      1. 経営や業務の特色をシステムに反映できる
      2. 目指すべきシステムの姿と移行計画が自社で描ける
      3. 適材適所にIT技術を選択導入できる
      4. マネジメント力は当然前提だが、マネジメント力だけでは上記問題は解決できない
    • 人材
      1. アーキテクトとマネジメント力の両輪
  • [P3] ITアーキテクチャ設計とは？
    • 経営観点でのROI向上のため、その企業にとって最適なシステム構造（アーキテクチャ）の将来像を、移行計画とともに描く
      1. 経営・業務の将来動向やITの課題に対して、AsISおよびToBeを描いていく
      2. AsIsからToBeへの移行計画を作成

ITアーキテクトの育成と実践報告

  • [P5] 発表者が参加した基本研修で取り扱っていたモジュール
    1. ビジネス＆ITアーキテクチャ基礎
      1. ITアーキテクチャ概念
      2. IT&ビジネスアーキテクチャ概念
      3. BRA(ビジネス要求アーキテクチャ）概念
      4. クライアント訪問（パームオイル企業Felda）
    2. Iasa ITアーキテクチャ・コア
    3. ITフレームワークTOGAF9.1 Level 1, 2
    4. ビジネス・テクノロジー戦略
  • [P9] 研修の内容例
    1. 組織内のITアーキテクトの役割
    2. ビジョンからToBeモデルをデザイン
    3. ITの現状分析
      • 失敗したITプロジェクトの原因を追及する
        1. ビジネスとITのミス・コミュニケーション
        2. メンテナンス予算にウェイトを置いた予算編成（AsIs中心）
        3. 事業部毎、年度毎のサイロ的な発想のプロジェクト要求
    4. ITアーキテクトとしての見方・視点を学ぶ
      • AsIs分析、ToBe作成の演習
  • 「P11] ITアーキテクチャのROI - 5つの視点
    1. Financial Improvement
    2. Constituent Improvement
    3. Reduced Complexity and Redundancy
    4. Economic Development
    5. Fostering Democracy
    • バリューストリーム: ROIとその根拠は、すべて『ビジネス用語』で発表
      • IT用語は使用禁止
  • [P14] 『AMO』と『PMO』の目的と役割の違い
    • プロジェクト実施サイクル内で、アーキテクチャ活動には限界がある
  • [P14] 4種類のITアーキテクト
    1. ビジネス・アーキテクト
    2. ソフトウェア・アーキテクト
    3. インフォメーション・アーキテクト
    4. インフラストラクチャ・アーキテクト
  • [P14] RACI モデル
    1. Rasponsibility
    2. Accountability
    3. Consultation
    4. Informed
  • [P30] Iasaが定義するアーキテクトの種類
    1. ビジネス・アーキテクト
    2. インフォメーション・アーキテクト
    3. インフラストラクチャ・アーキテクト
    4. ソフトウェア・アーキテクト
    5. ソリューション・アーキテクト

Q&A

  1. [Q] IPAが定義しているITアーキテクトと何が違うのか
    • [A] 関連はないし、IPAとは調整もしていない
  2. [Q] ITアーキテクトは、組織の中ではどういう位置づけなのか？
    • [A] （途中何がいいたいのかよくわからなくなってきたので、だいぶ適当なメモになっています） ITアーキテクトの中には、ビジネスアーキテクチャ、アプリケーション、データ等を含んでいる。EAを考えていくには、ビジネスアナリストの役割も一部入ってくる。プロジェクトをマネジメントしていくスキルも必要。組織の中でどういう位置づけになるかは、会社によって個別のケースになる。4つの領域の中のどれかを担当するかもしれないし、複数担当するかもしれない。ITアーキテクトとは呼ばずに、世間の言い方を使っているかもしれない。プロジェクトマネジメント領域との接点もある。プロジェクトマネジメントの中のポートフォリオマネジメント、予算化などの工程ともオーバーラップするケースもある。全体のフレームワークを回す組織を考慮した場合、それぞれの領域にオーバーラップすることが多い。独立したAMO、EA部門を持つ会社もいる。
  3. [Q] 現状の企業の中には、EA部門は現場に介入しないが？
    • [A] 日本の場合、現場と離れたところにEA部門が設置されて、ガバナンス系を担当することが多い。その結果、現場の感覚が失われている問題は出ている。ITアーキテクトがEA部門に入っていくと、ビジネスとEAのギャップが埋まるのではないか。
    • [A] EAというグループを作って、ITアーキテクトがずっとそこにいる、というモデルである必要はない。ユーザー企業のシステム部門は、全員がEAの素養を持っていても良い。

-Blog

Copyright© fullvirtue.com プロダクトオーナー支援スペシャリストのBlog , 2024 All Rights Reserved.