(第１回) アーキテクト・テックリード育成講座

- ITアーキテクト・テックリードとは
- システム全体設計（ビジネスからシステムへ）
- ITアーキテクト・テックリードがカバーするとよい良い領域

Transcript

1. 札幌エンジニア会 第１回 アーキテクト・テックリード講座 ・1回目：アーキテクトとシステム設計の勘所 2024/10/30(水) ・札幌エンジニア会 ゆきうさぎ（Kayahara）
2. 自己紹介 •カヤハラ マサシ（ X : ゆきうさぎ @__snow_rabbit__ 名前 •Terraform/Java/AWS 好きな技術・サービス 自己紹介 中規模のインフラ屋、大手SIとして計10年の実務経験を経 て、フリーランス独立して11年。約20年ほどIT関係に従事 現在は新規プロダクトの立上案件でシステムアーキテクト、 SREとして参画。 中小のIT企業の外部技術顧問・技術アドバイザリーとして活 動中。ビジネスのヒアリング、クラウドを用いたアプリケー ションの開発が得意でクライアントの要望に沿った形でシス テムを提案。 プロジェクトの規模によっては開発工程のリードも実施
3. 対象者と本セッションのゴール  対象者について  システム開発全体に興味のある方  ITアーキテクト・テックリードを目指している方  本日のゴール  ITアーキテクト・テックリードは何をする職種（ロール）か知っていただく  システム全体設計って何をするのか？知っていただく  インフラ・アプリケーションで意識しなくてはならない点を知っていただく※  ※細かな部分は次回以降のセッションにて掘り下げる
4. 本日、お話しないこと （みなさんが聞きたいのはこっちかも…）  システム開発の方針について  技術選定の仕方（言語・フレームワーク・ミドルウェア・DB・クラウド、IaC…etc）  成果物の管理方法（ドキュメント、ソースコード、リポジトリ戦略・レビュー）  デプロイ戦略  ガイドラインの作成  システムの粒度  モノリス／マイクロサービス／モジュラモノリス  アーキテクチャについて  レイヤードアーキテクチャ  クリーンアーキテクチャ  (他…パイプラインアーキテクチャ、イベント駆動アーキテクチャ、インテグレーションアーキテクチャ）
5. アジェンダ ITアーキテクト・テックリードとは システムの全体設計で何をするのか？ 次回予告（インフラ・アプリケーションの勘所の概要）
6. ITアーキテクト・テックリードとは？
7. どんなイメージあります？
8. 結論からいうと “技術だけ”では難しい職種（ロール）です
9. 日本におけるデジタル人材の職種とロール  日本のシステム開発における ITアーキテクト、テックリードの立ち位置とは？
10. スキル標準  IPAが定めるITの利活用し、新しいビジネスを推進する人材の確保・育成ための指針 参考URL：https://www.ipa.go.jp/jinzai/skill-standard/index.html ※DXの定義 企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、 顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、 業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること （経済産業省「デジタルガバナンス・コード2.0」（2022年9月改訂）） デジタルスキル標準(DSS) • DXリテラシー標準(DSS-L) • DX推進スキル標準(DSS-P) ITスキル標準 （ITSS/ITSS+）
11. 引用：https://www.ipa.go.jp/jinzai/skill-standard/dss/about_dss-l.html DXリテラシー標準(DSS-L)
12. DX推進スキル標準（DDS-P） デジタル推進人材とロール ビジネスアーキテク ト •概要：ビジネス（新規事業、既存事業の高度化、社内業務の高度化、効率化）において、目的設定から導入、導入後の効果検証までを、関係者をコーディネートしながら一気通貫して推進する •ロール：新規事業開発、既存事業の高度化、社内業務の高度化・効率化 デザイナー •概要：ビジネスの視点、顧客・ユーザーの視点等を総合的にとらえ、製品・サービスの方針や開発のプロセスを策定し、それらに沿った製品・サービスのありかたのデザインを担当する •ロール：サービスデザイナ、UX/UIデザイナー、グラフィックデザイナ ソフトウェアエンジ ニア •概要：システムやソフトウェアの設計・実装・運用を担当 •ロール：フロントエンドエンジニア、バックエンドエンジニア、クラウドエンジニア、SRE、フィジカルコンピューティングエンジニア データサイエンティ スト •概要：データの活用し、新規ビジネスや既存ビジネスのデータ収集・解析をする仕組みの設計・実装・運用を担当する •ロール：ストラテジスト、プロフェッショナル、エンジニア サイバーセキュリ ティ •概要：ビジネスにおけるセキュリティリスクの影響を抑制する人材 •ロール：マネージャー、エンジニア 引用：https://www.ipa.go.jp/jinzai/skill-standard/dss/about_dss-p.html
13. DX推進スキル標準（DDS-P） デジタル推進人材とロール ビジネスアーキテク ト •概要 ：ビジネス（新規事業、既存事業の高度化、社内業務の高度化、効率化）において、目的設定から導入、導入後の効果検証までを、関係者をコーディネートしながら一気通貫して推進する •ロール：新規事業開発、既存事業の高度化、社内業務の高度化・効率化 デザイナー •概要：ビジネスの視点、顧客・ユーザーの視点等を総合的にとらえ、製品・サービスの方針や開発のプロセスを策定し、それらに沿った製品・サービスのありかたのデザインを担当する •ロール：サービスデザイナ、UX/UIデザイナー、グラフィックデザイナ ソフトウェアエンジ ニア •概要：システムやソフトウェアの設計・実装・運用を担当 •ロール：フロントエンドエンジニア、バックエンドエンジニア、クラウドエンジニア、SRE、フィジカルコンピューティングエンジニア データサイエンティ スト •概要：データの活用し、新規ビジネスや既存ビジネスのデータ収集・解析をする仕組みの設計・実装・運用を担当する •ロール：ストラテジスト、プロフェッショナル、エンジニア サイバーセキュリ ティ •概要：ビジネスにおけるセキュリティリスクの影響を抑制する人材 •ロール：マネージャー、エンジニア 引用：https://www.ipa.go.jp/jinzai/skill-standard/dss/about_dss-p.html 「ITアーキテクト」も「テックリード」 横断的な知識が求められる
14. ITSS（ITスキル標準）  ITSSが分類する11の職種について  IPAでも「SE」、「プログラマ」と言った名称で包括的にくくるのではなく、ビジネスや実状に沿った職種や専門分野を定義する ように明記されております 引用：https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itss/career-framework.html
15. ITSS（ITスキル標準）  ITSSが分類する11の職種について  IPAでも「SE」、「プログラマ」と言った名称で包括的にくくるのではなく、ビジネスや実状に沿った職種や専門分野を定義する ように明記されております 引用：https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itss/career-framework.html ITアーキテクト テックリード
16. ITSS+  ITSSに加えて以下の領域について新たな領域のリスキリングを言及した ものである  データサイエンス領域  アジャイル領域  IoTソリューション領域  セキュリティ領域
17. ITアーキテクトとは ビジネス及びＩＴ上の課題を分析し、ソリューションを構成するシステム化要件として再構成する。 要件定義はITアーキテクトに求められるスキル 分析と再構築 ハードウェア、ソフトウェア関連技術を活用し、顧客のビジネス戦略を実現するために情報システム全体の品質（整合性、一 貫性等）を保ったソリューションの枠組みやアーキテクチャを設計する。 全体の設計 設計したアーキテクチャが課題に対するソリューションを構成することを確認し、 ビジネスの拡大を見越した後続の開発、導入が可能であることを確認する。（拡張性や保守性等※） ※◯◯性…「信頼性」「効率性」「移植性」「機能性」等も念頭もいれる必要がある ◯◯性の導入、確認 実現性に対する技術リスクについて事前に影響を評価する。 ※テックリードと重複する部分 技術リスクの評価 アプリケーション アーキテクチャ インテグレーション アーキテクチャ インフラストラク チャアーキテクチャ 要求 モデリング アーキテク チャ設計 ユーザビリ ティ 機能性 データ モデリング 標準化・再 利用
18. テックリードとは プロジェクトやチームの技術的な方向性を担う戦略的な決定を行う。 また設計や実装の方向性を示すガイドラインを作成し、エンジニアチームの教育も実施する。 技術戦略の立案と推進 顧客の環境に最適なシステム基盤の設計、構築、運用、保守の実施する。 （アプリケーション基盤・プラットフォームの作成） システム基盤の構築 業務課題を深く理解し、専門的な知識を用いてコンポーネントの設計及び実装を行う 専門的な技術による 業務課題の解決 実現性に対する技術リスクについて事前に影響を評価する。 ※テックリードと重複する部分 技術リスクの評価 システム運用 業務システム アプリケーション基盤 セキュリティ ミドルウェア ネットワーク プラットフォーム 専門性 技術 プロセ ス 業務 産業知 識 法律
19. ITアーキテクト・テックリードへの道（１）  ITSSには各職種へのキャリアパスも定義されております。  レベルは英国のSFIA(Skills Framework for the Information Age)等を参考にIPAのが定 めたものです 引用：https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itss/careerpath-model.html ソフトウェア開発部門でのキャリアパス
20. ITアーキテクト・テックリードへの道（２）  ITSSには各職種へのキャリアパスも定義されております。  レベルは英国のSFIA(Skills Framework for the Information Age)等を参考にIPAのが定めた ものです 引用：https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itss/careerpath-model.html アプリケーション開発系のキャリアパス
21. ITアーキテクト・テックリードへの道（注意） 引用：https://sfia-online.org/ja/sfia-9/skills SFIAは 2024年10月30日現在Version 9となっている ITIFが定めたレベルと乖離している可能性があるため、キャ リア設計をする前に見直すことをおすすめする
22. まとめ  ITアーキテクト  IPAのITSSに職種として分類されている  ビジネスとシステムの分析、再構築を実施する  システムの全体的な設計、及びシステムがビジネスのニーズを満たしていること を管理する  システムの拡張性・保守性・利便性等を保証する  エンジニアリングチームと連携し、正しく設計・実装が行われていることを確認 する  テックリード  IPAが定める職種としての定義は無いがあえてITSSで分類するなら「ITスペシャリ スト」「アプリケーションスペシャリスト」となる  プロジェクトやチームの技術的な方向性を担う戦略的な決定を行う  設計・実装のガイドラインを作成し、チームがベストプラクティスを遵守するよ うに推進する  ハードウェア、ソフトウェア関連の専門技術を活用し、顧客の環境に最適なシス テム基盤の設計、構築、導入を実施する  業務コンポーネントの中身を深く理解し、インシデント等がおきた場合の、最終 的な説明責任を負う ITアーキテクト・テックリードともに チームのシステム全体の方向性を決める点では同様である。 組織にあった役割、呼び名で定義すること (RACIチャートなど有用）
23. システムの全体設計ってなにするの？
24. ビジネスからシステム化までのフロー 1. 企画( Vison Planning / System Planning ) 2. システム化（システム要件定義 Requirement Definition） システム化（システム要件定義 Requirement Definition）検討内容 システム要件定義のゴール 各ステークホルダーに以下を合意していること ・予算を合意していること ・納期を合意していること ・対応内容がFixしていること ・システム要件定義は誰がやる？ IPAの定義では「プロジェクトマネジャ」「ITアーキテ クト」「アプリケーションスペシャリスト」を担う人 が対応することとなっている その他「ビジネスアナリスト」という業務分析-シス テム化要件を専門を行うロール（職種）も存在する
25. ビジネスからシステム化までのフロー 1. 企画( Vison Planning / System Planning ) 2. システム化（システム要件定義 Requirement Definition） システム化（システム要件定義 Requirement Definition）検討内容 日本のIT業界あるある • プライムベンダーが「ビジネス要件定義」、「システム 要件定義」の⑧ を行う。２次請けは「基本設計～」 というケースがある。 結果、後続の実装・設計・テスト・運用フェーズではビジネ スの現状や課題を知らずにシステムを開発をすることがある。 一度、立ち止まってAS-IS・課題・To-Beを見直してみよう！
26. ビジネス要件定義のフローと成果物 ステークホルダー •組織図 •ステークホルダ一覧 •ステークホルダ関連図 AS-ISの把握 •業務全体図 •業務一覧 •業務関連図 •業務フロー •用語集 問題・ニーズ •課題一覧 •（ステークホルダーへ のヒアリング） TO-BEの設定 •As-IS To-Be対応表 •施策検討結果 •KPI設定 システ ム化
27. システム化要件定義のフローと成果物 •機能要件：システム機能一覧、システム機能仕様 •データ構造設計：エンティティの抽出と関連の整理 •データフロー設計：業務とデータの流れを定義 •インタフェース設計：インプット、アウトプットを抽出（画面・帳票・外部システム連携） 機能関連：ビジネス・業務をシステムの粒度として細分化し、必要なインプットやアウトプットを抽出する •IPAの非機能要求グレード •ハードウェア・ソフトウェア（サーバー・クライアント）の構成 •インターフェース連携 システム関連：システムを安定して稼働させるための要件を決める •移行計画：並行運用・切り替え・切り戻し・リハーサルなどの方針と計画の立案 •データ移行：既存資産を新システムに移行するかを構成する •運用計画：移行時のテストの実施 導入・運用：システムの導入や運用に関する要件を決める
28. システム化要件定義（機能関連） - 業務フロー図からシステム化要件を整理する場合 - システム化する時の考慮事項 1. 各プロセスには入力・出力が存在する 2. 処理には制約・ルール・順番が存在する • ビジネスルールとして明記するように心がける 例） • 金額の端数の処理 • 処理完了時間 • 法律・産業知識・業界規格 業務フロー図は、BPMN、フローチャート、UML(アクティビティ図)等、表現は自由である。
29. 業務関連まとめ  ステークホルダと課題を明確に！  業務フローとシステム間の関連を明確に！  ルール・仕様・処理順  業務間の関連  インプットとアウトプットを明確に！  システムでの機能仕様を明確に！
30. システム化要件定義（システム関連）  機能ではなく、システムとして必要な部分を定義する。非機能要求グレード（IPA)を用い てクライアントと合意を得る。 大項目 説明 要求例 表現方法例 影響 可用性 継続的にシステムを利用可 能とする ・運用スケジュール ・DR時の稼働目標 ・冗長化やバックアップ ・復旧・回復方法の体制の確立 ・インフラ構成 ・バックアップ （DR戦略） ・コスト 性能・拡張性 性能および、将来のビジネ スの拡大に関する要求 ・事業拡大の見通し ・システム対象業務の特性 （ピーク、通常、縮退時） ・性能目標値に向けたサイジング ・将来性を見越した配置 ・サーバースペック ・インスタンス数 運用・保守性 システムの運用と保守サー ビスに関する要求 ・運用中に求められるシステム稼 働レベル ・問題発生時の対応レベル ・監視手段・バックアップ方式 ・問題発生時の役割分担、体制、訓練、 マニュアル整備 ・インフラ構成 ・バックアップ 移行性 現行システム資産の移行に 関する要求 ・新システムへの移行期間および 移行方法 ・移行対象資産の種類・移行量 ・移行スケジュール、移行ツール ・移行体制、移行リハーサル ※後述の運用設計にて説 明 セキュリティ 情報システムの安全性に関 する要求 ・利用制限 ・不正アクセス防止 ・アクセス制限、データ秘匿 ・不正の追跡、監視、検知 ・セキュリティ教育 ・インフラ構成 ・監査 • インフラ・ソフトウェアの構成・設計に大きく影響を及ぼす部分なので必ず合意を得ること。 • 近年、クラウド化の進んでいるため「ランニングコスト」も意識すること。 • ランニングコストがブレるのはクライアント様（経営上）嫌がる部分のため、この段階でランニングコストの算出も行うと良い
31. システム  ハードウェア・ソフトウェア（サーバー・クライアント）の構成  オンプレ／クラウド／ハイブリッド  他システムとのインタフェースと連携方式の決定 配置図 AWSのアーキテクチャ図
32. システム
34. システム関連まとめ  非機能要求グレードでお客様と合意を！  非機能要求によって月のランニングコストが変わ る。ハードウェア・サーバー・サービス構成図を 作成し、概算のランニングコストの算出と合意 を！ 番外編  ハードウェアに対応したOSやSDKによって後続の 技術選定にも影響するので意識すること！ハード が絡む場合は意識しよう
35. 導入・運用 移行計画 新規 更新 並行運用 可 否 運 用 方 法 即 時 反 映 非 同 期 反 映 切り替え ビ ッ ク バ ン 段 階 的 移 行 切戻 可 ・ 不 可 切戻 判断 方 法 リ ハ ー サ ル テ ス ト 観 点 データ移行 実 施 可 否 ク レ ン ジ ン グ 手順 機 能 SQL 対象 デ ー タ フ ァ イ ル 運用計画 ロ ー ン チ 時 メ ン テ ナ ン ス 時 イ ン シ デ ン ト 時 問 合 せ 発 生 時 契 約 ・ 解 約 時  システムの導入や運用に関する要件を決める
36. 運用関連まとめ  移行要件は計画を組む上なため、忘れないこと！  既存システムとの並行運用は既存システム側にも影響 があるため。先にヒアリングをしよう。  移行・運用要件ではインフラ・アプリへ影響する部分 が散らばっている。  メンテナンス時のソーリー画面への切替・ユーザDBか らの切断  既存データの移行…etc
37. 次回予告 インフラ・アプリケーション基盤の勘所
38. インター ネット DNS CDN ネットワー ク ネット ワーク ロードバ ランサー ストレージ ブロッ ク・スト レージ オブジェ クト・ス トレージ NFS 通知 メール 通知 スマホ チャット ハード機器 データベース RDB NoSQL 列指向DB VDB/GDB NewSQL キャッシュ CDN キャッ シュサー バー メッセージ キュー ストリー ム コンピュート リソース サー バー コンテ ナ ファン クショ ン (FaaS) 運用・分析 ログ メトリ クス アラー ム 分析 データ 移行 セキュリティ ファイ ヤー フォー ル WAF IDS/IPS 暗号化 秘匿情 報管理 認証基 盤 CICD ビルド デプロ イ パイプ ライン AI/ML 機械学 習 生成AI その他 ETL テスト 支援 次回予告(インフラ編)  システム全体を構成する上で必要なインフラの知識
39. 認証 認可 RBAC、 ABAC メッセージ 国際化(i18n) 業務ログ 入力チェック トランザクション 排他制御 例外処理 システム間連携 API / FILE セッション管理 分散アクセス (DB、キャッシュ) システム日付 タイムアウト 同期・非同期・ バッチ キャッシュ ファイル形式 セキュア コーディング 通信 DB共通方針 共通カラム 削除方針 通知 ファイル伝送 次回予告(アプリケーション基盤)  アプリケーションする上で意識したほうがよいコンポーネント
40.  システム開発の方針について  技術選定の仕方（言語・フレームワーク・ミドルウェア・DB・クラウド、IaC…etc）  成果物の管理方法（ドキュメント、ソースコード、リポジトリ戦略・レビュー）  デプロイ戦略  ガイドラインの作成  システムの粒度  モノリス／マイクロサービス／モジュラモノリス  アーキテクチャについて  レイヤードアーキテクチャ  クリーンアーキテクチャ  (他…パイプラインアーキテクチャ、イベント駆動アーキテクチャ、インテグレーションアーキテクチャ） 再掲 次回予告(プロセス編)
41. プロセス アプリケー ション基盤 インフラ 次回予告（順番 - 仮 -）  ボリューム応じて細分化してやってきます！
42. ご清聴ありがとうございました