ITアーキテクト養成講座【第13期】＜開催中止＞

セミナー紹介

全体を俯瞰し、将来も見通し、強くてしなやかなシステムを作る。
IT現場でいまもっとも求められる人材をめざす

　広範な技術や開発方法論に精通し、業務の分析スキルも兼ね備えるITアーキテクト。全社システム基盤の刷新やデジタルビジネスを支えるシステムの構築など、難しい案件が増えている今、その価値は高まる一方です。今まで優秀なエンジニアはプロマネへのキャリアを歩むのが一般的だった日本では、ITアーキテクトと呼べる人材の数も圧倒的に不足しており、その育成はITベンダーはもちろんの事、ユーザー企業のシステム部門にとっても喫緊の課題と言えます。

　しかし、ITアーキテクトの役割や立場については定義が曖昧で、求められるスキルも明確ではありません。ベテランエンジニアや技術に強いエンジニアが、結果的にアーキテクトの役割を担っている現場やプロジェクトも多いのではないでしょうか。既存のシステムの焼き直しといった案件であれば、それでも何とか対応可能かもしれません。しかし、最新の技術を駆使して新しいビジネスを生み出していくようなプロジェクトでは、その役割を理解し、必要なスキルも身につけた真のITアーキテクトの存在が不可欠です。

　本講座では、システム開発で一般的な「V字開発モデル」に沿って、上流工程から順を追ってITアーキテクトのタスクやスキルを体系的に学んでいきます。少人数のグループワークで実際に成果物をまとめていく、演習中心の実践的なカリキュラムです。

　第2回の講座の終了後に、名刺交換や意見交換などのためのプログラム外の交流の時間を設ける予定です。他社のトップエンジニアとの交流が深まり、その人脈は、アーキテクトに不可欠な広範な知識の拠りどころとなるでしょう。

　2011年にスタートしたこの講座は、他にはないプログラムが多くのエンジニアから高い評価をいただき、今回で第13期を迎えます。ITアーキテクト講座の決定版と言える本講座をぜひ今こそ、御社のトップエンジニアのスキルアップにお役立てください。

　皆さまのご参加を心よりお待ちしています。

◆なぜ今「ITアーキテクト」が求められるのか？

　「技術や開発方法論の選択肢が増加」「全社システム基盤再構築の必要性が高まる」「ITエンジニアへの新たな業務の提案の要請」という3つの要因から、いままさにITアーキテクトの価値が高まっています。

◆「V字開発モデル」に沿って、ITアーキテクトのタスクを理解

　本講座では、システム開発で一般的な「V字開発モデル」に沿って、ITアーキテクトのタスクや課題を解説し、各フェーズで求められるスキルを、グループワークを通じて習得します。

◆こんな方におススメです

・システムのアーキテクチャーについて体系的な知識を身に付けたいITエンジニア、プロジェクトマネジャー
・自社システムのアーキテクチャーの現状や、あるべき姿について理解を深めたい情報システム担当者

開催概要

セミナー名	ITアーキテクト養成講座【第13期】＜開催中止＞
日時	＜全4回＞ 2021年6月23日（水）・6月30日（水）・7月7日（水）・7月13日（火） 各回10:00～17:00 （開場 9:30予定） ※第2回（6月30日）講座の終了後に、名刺交換や意見交換などのためのプログラム外の交流の時間を設ける予定です。
会場	東京・神谷町 日経BP（日経虎ノ門別館）5階セミナールーム ●東京メトロ日比谷線「神谷町駅」虎ノ門方面改札より徒歩5分 ●東京メトロ南北線「六本木一丁目駅」泉ガーデン出口より徒歩7分
受講料	198,000円（税込み）
定員	32名 ※最少開催人数（16名）に満たない場合は、開催を中止させていただくことがあります。
備考	＜受講特典＞ ●書籍 ITアーキテクトの教科書［改訂版］ 石田 裕三 著、定価2,750円（10％税込） をもれなく進呈いたします。 （当日会場にてお渡しいたします）
主催	日経クロステック　日経コンピュータ

講師紹介

プログラム ※各回とも昼食をご用意します

6月23日	第1回　要件定義 フェーズ 1-1　システム化対象のドメイン分析 ～関係者の間で対立する利害の認識～ システムを取り巻く様々な視点／制約の洗い出し／利用者視点でシステムへの期待・要望・要求を聞出／利害対立の認識／業務（サービス）で使う言葉の統一／静的モデリング／Quality Attribute Workshop／品質特性（Quality Attribute）間のトレードオフ分析 等 システムを取り巻く利害関係や要求を、 ビジネス視点で可視化する。 　 1-2　クリティカルなユースケースの要求仕様と、定量評価可能な非機能要件の定義 SOW（Statement of Work）／ 動的モデリング／ SRS（Software Requirement Specification）／Utility Tree／ATAM（Architecture Tradeoff Analysis Method） 等 システムが満たすべき要求（スペック）を 仕様として切り出す。 　 演習１　品質特性シナリオの作成 TPC-Hモデルを題材に、OLTPとOLAPを統合し、定量評価可能な品質特性シナリオ（Quality Attribute Scenario）を作成します。 　 1-3　初期アーキテクチャーの構築 ADD（Attribute Driven Development） 等 様々な品質特性要件を満たす アーキテクチャーのグランドデザインを描く。
6月30日	第2回　基本設計 フェーズ 2-1　個別設計間の整合性確保 ～移り変わる要求仕様への対応戦略～ 異なる要求の間に矛盾がないことを担保／内部仕様／Open‐Closed Principle（OCP）／関心事の分離と重複の排除／機能モデリングとデータモデリング／レイヤ分割とスコープ分割 等 依存関係を整理し、設計作業の並列性を高め、 アーキテクチャーのグランドデザインを描く。 　 2-2　アーキテクチャー設計 ～スケーラビリティ戦略～ シンプルな解（“足し算”か“引き算”か）／同期と非同期、集中と分散、直列と並列／スケールアップとスケールアウト 等 非機能要件と主要なユースケースを実現する アーキテクチャーを設計する。 　 演習2　アーキテクチャーの設計 演習１であげた品質特性シナリオを満たす、アーキテクチャーを設計します。 　 2-3　アーキテクチャー評価 ～トレードオフ分析とリスク認識～ アーキテクチャーの静的（机上）評価／システム全体としてデータの整合性～データ鮮度・不一致・遡及時間～／データ管理～Pull型とPush型～ ／ACID 特性／CAP 定理／BASEアーキテクチャー／Architecture Tradeoff Analysis Method（ATAM） 等 様々な品質特性要件を満たす アーキテクチャーのグランドデザインを描く。 　 演習３　アーキテクチャーの分析 ATAM記載のテンプレートを利用して、演習２のアーキテクチャーを分析します。 　 ◆ 第2回の講座の終了後に、名刺交換や意見交換などのためのプログラム外の交流の時間を設ける予定です。
7月7日	第3回　詳細設計／実装フェーズ 3-1 【詳細設計】“正の仕様”管理とモジュール分割 機能（ユースケース）横断的な関心事／“暗黙の仕様”（詳細を検討することで認識する未確定な要求仕様）／動的モデリング／“指向”の統一（プロセス、オブジェクト、データ中心、サービス、…）／分割統治／依存関係／UML Components（ユースケース駆動＋データモデル駆動） 等 どう実装するか（How）ではなく、何を実装するか（What）を明らかにし、十分な粒度まで機能要件をモジュール分割する。 　 3-2 【詳細設計】テーブルとクラスの粒度 リソース（マスタ）とイベント（トランザクション）の分離／マスタの履歴（適用開始／終了日）管理／Data Base Normalization（正規化）／O/Rマッピング・Impedance Mismatch／関数型とImmutability（不変性） 等 インピーダンス・ミスマッチの 解決する術を規定する。 　 演習４　ER図の作成 TPC-Hモデルを基にER図を作成します。 　 3-3 【詳細設計】インデックスとデータ保全 副作用を考慮したインデックス設計基準／排他制御（ロック粒度）／バックアップ／断片化解消／統計情報 等 運用リスクを排除する。 　 演習５　DB運用設計書の作成 定常運用と臨時運用に分けてデータ運用設計書を作成します。 　 3-4 【実装】アプリ構造維持に必要な道具立て RISC（限られた単機能）かCISC（複雑で高機能）か／制御の反転（Inversion of Control）／Late Binding（動的リンク）／開発環境の整備／COTS （Commercial Off The Shelf）／OSS（Open Source Software）／Software Configuration Management 等 アプリケーションの 実装負荷を軽減する。
7月13日	第4回　テスト／保守フェーズ 4-1 【テスト】機能横断的な関心事への品質確認と動的・静的検証、性能評価 機能横断的なテストシナリオ／Continuous Integration（継続的インテグレーション）／テストプログラム資産化（自動テスト）／テスト・フレームワーク（選定、整備）、検証基準（静的・動的）／性能ボトルネック調査と要監視ポイントの把握／Performance Testing Tool 等 連結テストケースの妥当性を検証、 テスト自動化の費用対効果を最大化する。 　 演習６　状態遷移図の作成とテストケースの洗い出し 演習４のER図から状態遷移図を起こし、必要十分なテストケースを洗い出します。 　 4-2 【保守】機能追加と機能改修のすみ分け 仕様と実装のトレーサビリティ／“ゴッド・クラス”発生の抑止／共通性と可変性の管理／平行開発（複数Version管理） 等 アプリケーションの 新陳代謝を維持する。 　 演習７　要求仕様と実装のトレーサビリティを維持 コンポーネントの追加／改修で影響範囲を示し、要求仕様と実装のトレーサビリティを保つ為に必要な「基準」を規定します。 　 4-3 【保守】アプリ構造／アーキテクチャーの維持 変化し続ける開発要件、求められる運用の継続性／遇有的（Accidental）複雑さ／Application Portfolio Management（APM）／パフォーマンス・モニタリング／パフォーマンス・プロファイリング／崩れるアプリ構造／繰り返される性能遅延 等 システムに内在する リスクを監視する。 　 4-4 【保守】アーキテクチャー改善 機能要件の多次元空間の認知（機能軸、データ／エンティティ軸、時間軸）／機能要件と非機能要件の分離の必要性／移り変わる実装技術と進化するハードウェア／改善するリスクと改善しないリスク／ペナルティコスト（ビジネスの継続性) 等 リスク分析と費用対効果分析に基づく アーキテクチャー改善策を検討する。