ITやシステム、業務設計の仕事では、「何から整理すればよいのか分からない」と感じる場面がよくあります。
新しい業務システムを作るときは、要件定義が必要です。業務改善を進めるときは、業務プロセスの可視化が必要です。データ活用を進めるときは、データの流れや構造を整理する必要があります。さらに、ITサービスを安定運用するにはITIL、ITを経営目線で管理するにはCOBIT、セキュリティを考えるにはZero TrustやSTRIDE、DXの方向性を考えるにはSWOT for DXのような考え方も役立ちます。
つまり、IT・システム・業務設計の分野では、目的によって使うべきフレームワークが変わります。
すべてを一度に覚える必要はありません。まずは、「自分はいま何を整理したいのか」を明確にし、その目的に合ったフレームワークを選ぶことが大切です。
この記事では、IT・システム・業務設計で使う代表的なフレームワークを、初心者にもわかりやすく整理します。要件定義、業務プロセス、データ設計、エンタープライズアーキテクチャ、IT運用、ガバナンス、DevOps、セキュリティ、DX推進まで、実務で使いやすい形で全体像を解説します。
この記事でわかること
・IT・システム・業務設計で使うフレームワークの全体像
・要件定義、業務設計、データ設計、IT運用、セキュリティ、DX推進の違い
・初心者が最初に学ぶべきフレームワーク
・目的別にどのフレームワークを選べばよいか
・各フレームワークの基本的な使い方
・複数のフレームワークを組み合わせる考え方
最初から完璧に使いこなす必要はありません。まずは「フレームワークは、複雑なIT・業務課題を整理するための型だ」とつかめれば十分です。
IT・システム・業務設計で使うフレームワークとは？
IT・システム・業務設計で使うフレームワークとは、システム開発、業務改善、データ設計、IT運用、セキュリティ、DX推進などを整理するための考え方です。
ITの仕事では、単にシステムを作るだけでは不十分です。
たとえば、業務システムを開発する場合でも、次のような論点があります。
・何のためにシステムを作るのか
・どの業務を改善するのか
・誰が使うのか
・どのような機能が必要なのか
・どのデータを扱うのか
・どのように運用するのか
・セキュリティ上のリスクは何か
・将来のDXやデータ活用につながるのか
これらを思いつきで整理しようとすると、抜け漏れや認識ズレが起きやすくなります。
そこで、要件定義フレーム、UML、BPMN、DFD、ER図、ITIL、COBIT、DevOps、Zero Trust、STRIDEなどのフレームワークを使います。
一言でいうと、IT・システム・業務設計で使うフレームワークは、業務とITを正しく結びつけ、実務で使える仕組みに落とし込むための整理法です。
IT・システム・業務設計フレームワークは何に使うのか
IT・システム・業務設計フレームワークは、主に次のような目的で使います。
・システム開発の要件を整理する
・業務プロセスを可視化する
・データの流れや構造を整理する
・開発者と業務部門の認識を合わせる
・ITサービスの運用を安定させる
・IT投資やリスクを経営目線で管理する
・セキュリティ脅威を洗い出す
・DX推進の方向性を考える
・レガシーシステム刷新の全体像を描く
・システム改善や自動化の優先順位を決める
重要なのは、フレームワークを「知識として覚える」だけでなく、「何を整理したいときに使うのか」を理解することです。
たとえば、業務の流れを整理したいならBPMNが向いています。データの流れを整理したいならDFDが向いています。データベースの構造を整理したいならER図が向いています。
一方で、ITサービスの運用改善ならITIL、ITガバナンスならCOBIT、全社システム構想ならTOGAFやZachman Frameworkが役立ちます。
どんな人に向いているか
IT・システム・業務設計フレームワークは、次のような人に向いています。
・業務改善を担当している人
・DX推進に関わっている人
・システム導入を検討している人
・要件定義に参加する業務部門の人
・情報システム部門の担当者
・プロジェクトマネージャーやリーダー
・外部ベンダーとシステム仕様を打ち合わせる人
・IT運用やヘルプデスクを改善したい人
・セキュリティや内部統制を強化したい人
・経営企画や事業企画でIT投資を考える人
特に、IT部門と業務部門の橋渡しをする人には有効です。
システム開発では、業務を知っている人と、技術を知っている人の認識がずれることがあります。業務部門は「便利な仕組みがほしい」と考え、開発者は「具体的な仕様が必要」と考えます。
フレームワークを使うことで、業務課題、機能、データ、プロセス、運用、セキュリティを整理し、関係者の会話を進めやすくなります。
IT・システム・業務設計フレームワークの全体像
IT・システム・業務設計で使うフレームワークは、大きく分けると次の7つの領域に整理できます。
・要件定義
・業務プロセス設計
・データ設計
・エンタープライズアーキテクチャ
・ITサービス管理とITガバナンス
・開発運用連携
・セキュリティとDX推進
この分類で見ると、それぞれのフレームワークの役割が分かりやすくなります。
要件定義に使うフレームワーク
要件定義では、何を作るのか、なぜ作るのか、どのような条件が必要なのかを整理します。
代表的なフレームワークは、要件定義フレームです。
要件定義フレームでは、業務要件、機能要件、非機能要件を分けて考えます。
業務要件は、業務として実現したいことです。機能要件は、システムに必要な機能です。非機能要件は、性能、セキュリティ、運用、可用性など、機能以外の条件です。
要件定義が曖昧なまま開発を進めると、完成後に「思っていたものと違う」という問題が起きやすくなります。
業務プロセス設計に使うフレームワーク
業務プロセス設計では、誰が、どの順番で、どの作業を行うのかを整理します。
代表的なフレームワークはBPMNです。
BPMNは、業務プロセスを図で表現するための記法です。作業、判断、担当者、分岐、承認、差し戻しなどを見える化できます。
業務改善やDXでは、システムを導入する前に、現在の業務フローを整理することが重要です。
現状業務を正しく理解しないままシステム化すると、非効率な業務をそのままデジタル化してしまうことがあります。
データ設計に使うフレームワーク
データ設計では、業務やシステムで扱うデータを整理します。
代表的なフレームワークは、DFD、CRUDマトリクス、ER図です。
DFDは、データの流れを整理する図です。どこからデータが入り、どこで処理され、どこへ保存・出力されるのかを見える化します。
CRUDマトリクスは、データに対して作成、参照、更新、削除のどの操作が必要かを整理します。
ER図は、データ同士の関係を整理する図です。顧客、商品、注文、社員、部門などの関係を明確にできます。
データ設計が不十分だと、二重入力、データ不整合、集計ミス、システム改修時の混乱が起きやすくなります。
エンタープライズアーキテクチャに使うフレームワーク
エンタープライズアーキテクチャとは、企業全体の業務、データ、システム、技術基盤を整理する考え方です。
代表的なフレームワークは、TOGAFとZachman Frameworkです。
TOGAFは、企業全体の業務とITを設計し、現状から将来像へ移行するための方法論です。
Zachman Frameworkは、企業構造を複数の視点と問いで整理する分類フレームワークです。
全社DX、基幹システム刷新、グループ会社のIT統合、データ基盤整備などでは、個別システムだけを見るのではなく、全社の業務・データ・IT構造を整理する必要があります。
ITサービス管理とITガバナンスに使うフレームワーク
ITサービス管理やITガバナンスでは、ITを安定して運用し、経営に貢献する形で管理します。
代表的なフレームワークは、ITILとCOBITです。
ITILは、ITサービス管理のフレームワークです。インシデント管理、問題管理、変更管理、サービスデスクなどを整理します。
COBITは、ITガバナンスとITマネジメントのフレームワークです。IT投資、リスク管理、統制、責任、価値創出を経営目線で整理します。
システムは導入して終わりではありません。安定して運用し、改善し、経営価値につなげる必要があります。
開発運用連携に使うフレームワーク
開発運用連携では、システムを素早く安全に改善し続けることを目指します。
代表的なフレームワークは、DevOpsとCI/CDです。
DevOpsは、開発と運用が連携して、継続的に価値を届けるための考え方です。
CI/CDは、コード変更からテスト、ビルド、リリースまでの流れを自動化・標準化する仕組みです。
変化の速いシステムやWebサービスでは、作って終わりではなく、利用者の反応を見ながら継続的に改善することが重要です。
セキュリティとDX推進に使うフレームワーク
セキュリティとDX推進では、リスクを管理しながらデジタル活用を進めます。
代表的なフレームワークは、Zero Trust、STRIDE、SWOT for DXです。
Zero Trustは、すべてのアクセスを確認し、無条件に信頼しないセキュリティの考え方です。
STRIDEは、セキュリティ脅威を6つに分類して分析するフレームワークです。
SWOT for DXは、SWOT分析をDX推進に応用し、強み、弱み、機会、脅威からDXテーマを整理する考え方です。
DXを進めるほど、セキュリティ、データ管理、外部連携、クラウド利用の重要性は高まります。
目的別に選ぶIT・システム・業務設計フレームワーク
初心者が迷いやすいのは、「どのフレームワークをいつ使えばよいのか」です。
ここでは、目的別におすすめのフレームワークを整理します。
システム開発の最初に何を作るか整理したい場合
この場合は、要件定義フレームを使います。
要件定義フレームは、業務要件、機能要件、非機能要件を分けて整理するための考え方です。
たとえば、営業管理システムを作る場合、いきなり「顧客登録機能がほしい」と考えるのではなく、まず「営業案件を見える化したい」「売上見込みを把握したい」「商談履歴を共有したい」といった業務要件を整理します。
そのうえで、必要な機能や性能、セキュリティ条件を考えます。
業務の流れを見える化したい場合
この場合は、BPMNを使います。
BPMNは、業務プロセスを図で整理するためのフレームワークです。
申請業務、受注処理、問い合わせ対応、経費精算、研修申込など、複数の担当者や部門が関わる業務で役立ちます。
業務改善やシステム導入の前には、まずBPMNで現状業務を見える化すると、ムダや重複、待ち時間、責任の曖昧さを見つけやすくなります。
データの流れを整理したい場合
この場合は、DFDを使います。
DFDは、業務やシステムの中でデータがどこから来て、どこで処理され、どこへ行くのかを整理する図です。
たとえば、注文データ、在庫データ、請求データ、顧客データがどのように流れるのかを見える化できます。
二重入力や転記作業を減らしたい場合、システム間連携を考える場合、RPAや自動化を検討する場合にも役立ちます。
データ操作や権限を整理したい場合
この場合は、CRUDマトリクスを使います。
CRUDマトリクスでは、データに対して作成、参照、更新、削除のどの操作が必要かを整理します。
たとえば、営業担当者は顧客情報を登録・参照・更新できるが削除はできない。管理者は権限管理を行えるが、承認履歴は削除できない。このような整理ができます。
権限設計、内部統制、個人情報管理にも役立つフレームワークです。
データベース構造を整理したい場合
この場合は、ER図を使います。
ER図は、データ同士の関係を整理する図です。
顧客、注文、商品、請求、配送、社員、部門、研修、申込などの関係を整理できます。
システム開発やデータベース設計だけでなく、Excel管理を見直す場合や、データ分析基盤を作る前段階でも役立ちます。
システムの構造や動きを図で表したい場合
この場合は、UMLを使います。
UMLは、システムの構造や動きを図で表現するための記法です。
ユースケース図では、誰が何をするのかを整理できます。クラス図では、データや概念の関係を整理できます。シーケンス図では、処理の流れややり取りの順番を整理できます。
開発者と業務部門の認識合わせにも役立ちます。
全社DXや基幹システム刷新を考えたい場合
この場合は、TOGAFやZachman Frameworkを使います。
TOGAFは、企業全体の業務、データ、アプリケーション、技術基盤を整理し、現状から将来像へ移行するための方法論です。
Zachman Frameworkは、企業構造をWhat、How、Where、Who、When、Whyなどの問いで整理するフレームワークです。
全社DX、レガシーシステム刷新、グループ会社統合、データ基盤整備など、大きなテーマで役立ちます。
IT運用を改善したい場合
この場合は、ITILを使います。
ITILは、ITサービスを安定して提供し、継続的に改善するためのフレームワークです。
サービスデスク、インシデント管理、問題管理、変更管理などを整理できます。
問い合わせ対応が属人化している、障害対応が毎回場当たり的、システム変更でトラブルが多い場合に役立ちます。
ITを経営目線で管理したい場合
この場合は、COBITを使います。
COBITは、ITガバナンスとITマネジメントのフレームワークです。
IT投資が経営目標に合っているか、ITリスクが管理されているか、責任や統制が明確かを整理できます。
DX推進、内部統制、情報セキュリティ、監査対応、IT投資評価に役立ちます。
開発と運用を連携させたい場合
この場合は、DevOpsを使います。
DevOpsは、開発と運用が協力し、システムやサービスを継続的に改善するための考え方です。
開発チームは新機能を早く届けたい。運用チームは安定稼働を守りたい。この両方を両立させるために使います。
リリース後の監視、障害対応、利用者フィードバックを開発改善につなげることが重要です。
リリース作業を自動化・標準化したい場合
この場合は、CI/CDを使います。
CI/CDは、コード変更、テスト、ビルド、リリースまでの流れを自動化・標準化する仕組みです。
リリース作業の手作業ミスを減らしたい、不具合を早く見つけたい、小さな改善を継続的に届けたい場合に役立ちます。
DevOpsを実現するための実務的な仕組みの一つです。
セキュリティ設計を強化したい場合
この場合は、Zero TrustとSTRIDEを使います。
Zero Trustは、社内外を問わず、すべてのアクセスを確認するセキュリティの考え方です。
リモートワーク、クラウド利用、外部委託先との連携、重要情報管理に役立ちます。
STRIDEは、セキュリティ脅威を6つに分類して洗い出すフレームワークです。システム設計や要件定義の段階で、なりすまし、改ざん、否認、情報漏えい、サービス妨害、権限昇格を確認できます。
DXテーマを整理したい場合
この場合は、SWOT for DXを使います。
SWOT for DXは、強み、弱み、機会、脅威をDXの文脈で整理するフレームワークです。
自社の強みをデジタル技術と組み合わせる、弱みを改善テーマにする、外部環境の機会を取り込む、競合や市場変化の脅威に備える、といった整理ができます。
DXの初期構想やロードマップ作成の前段階で役立ちます。
代表的なフレームワークの概要
ここからは、今回の記事シリーズで扱った各フレームワークを簡単に整理します。
要件定義フレーム
要件定義フレームは、システム開発や業務改善を始める前に、必要な条件を整理するためのフレームワークです。
業務要件、機能要件、非機能要件を分けて考えるのが基本です。
業務要件は、業務として何を実現したいかです。機能要件は、システムに必要な機能です。非機能要件は、性能、セキュリティ、運用、保守などの条件です。
初心者が最初に学ぶべき重要なフレームワークです。
UML
UMLは、システムの構造や動きを図で表現するための記法です。
ユースケース図、クラス図、シーケンス図、アクティビティ図、状態遷移図などがあります。
すべてを覚える必要はありません。まずは、誰が何をするかを整理するユースケース図、処理の流れを整理するシーケンス図、データや概念の関係を整理するクラス図から理解するとよいでしょう。
BPMN
BPMNは、業務プロセスを図で表現するためのフレームワークです。
作業、担当者、分岐、承認、差し戻し、例外処理などを整理できます。
業務改善、DX、ワークフローシステム導入、RPA導入の前段階で特に役立ちます。
DFD
DFDは、データフロー図とも呼ばれ、データの流れを整理するための図です。
外部実体、プロセス、データストア、データフローを使って、データがどこから来て、どこで処理され、どこへ行くかを表します。
データ連携、帳票設計、RPA、自動化、システム化の検討で役立ちます。
CRUDマトリクス
CRUDマトリクスは、データに対する作成、参照、更新、削除の操作を整理するフレームワークです。
誰がどのデータを作成できるのか、誰が閲覧できるのか、誰が更新できるのか、誰が削除できるのかを明確にできます。
権限設計や内部統制、監査対応にも役立ちます。
ER図
ER図は、データ同士の関係を整理する図です。
顧客、商品、注文、社員、部門、研修、申込などの関係を表します。
データベース設計、Excel管理の見直し、データ分析基盤の整備などで役立ちます。
TOGAF
TOGAFは、エンタープライズアーキテクチャを設計・管理するためのフレームワークです。
ビジネス、データ、アプリケーション、テクノロジーの4つの視点で企業全体の業務とITを整理します。
全社DX、レガシーシステム刷新、グループ会社統合など、大きなテーマで役立ちます。
Zachman Framework
Zachman Frameworkは、企業アーキテクチャを複数の視点と問いで整理するフレームワークです。
What、How、Where、Who、When、Whyといった問いを使って、企業構造を多面的に整理します。
TOGAFが進め方に近いのに対し、Zachman Frameworkは分類表、整理表として使いやすい考え方です。
ITIL
ITILは、ITサービス管理のフレームワークです。
サービスデスク、インシデント管理、問題管理、変更管理などを整理し、ITサービスを安定して提供するために使います。
社内ヘルプデスク、障害対応、運用改善、外部ベンダー管理で役立ちます。
COBIT
COBITは、ITガバナンスとITマネジメントのフレームワークです。
IT投資、ITリスク、内部統制、情報セキュリティ、責任、成果指標を経営目線で整理します。
ITを単なるコストではなく、価値とリスクを持つ経営資源として管理するために使います。
DevOps
DevOpsは、開発と運用が連携して、システムやサービスを継続的に改善するための考え方です。
開発スピードと運用安定性を両立させることが目的です。
リリース後の監視、障害対応、利用者フィードバックを改善につなげることが重要です。
CI/CD
CI/CDは、コード変更からテスト、ビルド、リリースまでの流れを自動化・標準化する仕組みです。
継続的インテグレーション、継続的デリバリー、継続的デプロイの考え方があります。
DevOpsやアジャイル開発を支える実務的な仕組みです。
Zero Trust
Zero Trustは、「何も無条件には信頼しない」という考え方を基本にしたセキュリティアーキテクチャです。
社内か社外かではなく、ユーザー、端末、アクセス先、行動、データの重要度を確認しながらアクセスを制御します。
リモートワーク、クラウド利用、重要情報管理で役立ちます。
STRIDE
STRIDEは、セキュリティ脅威を6つに分類して分析するフレームワークです。
なりすまし、改ざん、否認、情報漏えい、サービス妨害、権限昇格を整理します。
システム設計や要件定義の段階で、セキュリティ要件を洗い出すときに役立ちます。
SWOT for DX
SWOT for DXは、SWOT分析をDX推進に応用したフレームワークです。
自社の強み、弱み、外部の機会、脅威をDXの文脈で整理し、DXテーマや優先順位を考えるために使います。
DXの初期構想、部門別DX、IT投資の方向性整理で役立ちます。
初心者はどの順番で学べばよいか
IT・システム・業務設計のフレームワークは数が多いため、初心者は学ぶ順番を決めると理解しやすくなります。
おすすめの順番は次のとおりです。
まずは要件定義フレームから学ぶ
最初に学ぶべきなのは、要件定義フレームです。
なぜなら、システム開発や業務改善の出発点になるからです。
何を実現したいのか、どんな機能が必要なのか、どんな非機能要件が必要なのかを整理できるようになると、IT部門や外部ベンダーとの会話がしやすくなります。
次にBPMNで業務の流れを学ぶ
次に、BPMNを学ぶとよいでしょう。
業務システムは、業務の流れを支えるものです。そのため、業務プロセスを理解しないままシステムを考えると、現場に合わない仕組みになりがちです。
BPMNを使うと、誰が、何を、どの順番で行っているのかを整理できます。
その次にDFD、CRUDマトリクス、ER図を学ぶ
業務の流れが見えたら、次はデータを整理します。
DFDでデータの流れを見ます。CRUDマトリクスでデータ操作を確認します。ER図でデータ同士の関係を整理します。
この3つを理解すると、業務システムの裏側にあるデータ構造が見えるようになります。
開発や運用に関わるならUML、DevOps、CI/CDを学ぶ
システム開発に深く関わるなら、UML、DevOps、CI/CDも学ぶとよいでしょう。
UMLは設計内容を図で表すために役立ちます。
DevOpsは開発と運用の連携を考えるために役立ちます。
CI/CDはリリース作業を安全に効率化するために役立ちます。
IT管理や経営視点が必要ならITIL、COBIT、TOGAFを学ぶ
情報システム部門、管理職、DX推進担当、経営企画に関わる人は、ITIL、COBIT、TOGAFも学ぶ価値があります。
ITILはITサービス運用、COBITはITガバナンス、TOGAFは全社アーキテクチャに強いフレームワークです。
セキュリティとDXを考えるならZero Trust、STRIDE、SWOT for DXを学ぶ
クラウド利用、リモートワーク、DX推進、重要情報管理に関わるなら、Zero Trust、STRIDE、SWOT for DXも重要です。
Zero Trustはアクセス制御、STRIDEは脅威分析、SWOT for DXはDXテーマ整理に役立ちます。
フレームワークを組み合わせて使う実務パターン
実務では、1つのフレームワークだけで完結することは多くありません。
目的に応じて複数のフレームワークを組み合わせると、より実務的に整理できます。
新しい業務システムを開発する場合
新しい業務システムを開発する場合は、次のような組み合わせが有効です。
・要件定義フレーム
・BPMN
・DFD
・ER図
・CRUDマトリクス
・UML
・STRIDE
まず、要件定義フレームで業務要件、機能要件、非機能要件を整理します。
次に、BPMNで業務フローを可視化します。
DFDでデータの流れを整理し、ER図でデータ構造を考え、CRUDマトリクスで操作権限を確認します。
UMLでシステムの構造や処理の流れを表し、STRIDEでセキュリティ脅威を確認します。
社内業務改善を進める場合
社内業務改善では、次のような組み合わせが有効です。
・BPMN
・DFD
・CRUDマトリクス
・要件定義フレーム
・SWOT for DX
まずBPMNで現状業務を見える化します。
次にDFDでデータの流れを確認し、二重入力や転記作業を見つけます。
CRUDマトリクスで、誰がどのデータを扱っているかを確認します。
改善後にシステム化する場合は、要件定義フレームで要件を整理します。
DXテーマとして経営に説明する場合は、SWOT for DXを使うと方向性を整理しやすくなります。
全社DXを進める場合
全社DXでは、次のような組み合わせが有効です。
・SWOT for DX
・TOGAF
・Zachman Framework
・BPMN
・ER図
・COBIT
・Zero Trust
まずSWOT for DXで、自社の強み、弱み、機会、脅威を整理します。
次にTOGAFやZachman Frameworkで、企業全体の業務、データ、アプリケーション、技術基盤を整理します。
個別業務はBPMNで深掘りし、データ構造はER図で整理します。
IT投資やリスク管理はCOBITで考え、セキュリティはZero Trustの考え方を取り入れます。
IT運用を改善する場合
IT運用改善では、次のような組み合わせが有効です。
・ITIL
・COBIT
・DevOps
・CI/CD
・Zero Trust
ITILでサービスデスク、インシデント管理、問題管理、変更管理を整理します。
COBITでIT運用が経営目標やリスク管理とつながっているかを確認します。
開発と運用の連携が必要な場合はDevOpsを使います。
リリース作業の効率化にはCI/CDを使います。
アクセス管理やセキュリティ強化にはZero Trustを組み合わせます。
セキュリティを強化する場合
セキュリティ強化では、次のような組み合わせが有効です。
・STRIDE
・Zero Trust
・COBIT
・ITIL
・CRUDマトリクス
STRIDEでセキュリティ脅威を洗い出します。
Zero Trustでアクセス制御や本人確認、端末管理を強化します。
COBITでセキュリティをITガバナンスの観点から管理します。
ITILでセキュリティインシデント発生時の対応を整理します。
CRUDマトリクスで、重要データへの操作権限を確認します。
実務で使うときの注意点
IT・システム・業務設計フレームワークは便利ですが、使い方を間違えると、形式的な資料作成になってしまいます。
フレームワークを埋めることを目的にしない
よくある失敗は、フレームワークの項目を埋めること自体が目的になることです。
BPMNを描くこと、ER図を作ること、CRUDマトリクスを埋めることが目的ではありません。
目的は、業務やシステムを分かりやすく整理し、良い意思決定につなげることです。
現場の業務を確認する
ITや業務設計では、現場の実態を確認することが重要です。
ルール上はこうなっているはず、という前提だけで整理すると、実際の業務とずれることがあります。
現場では、Excelで補助管理している、メールで非公式に確認している、ベテランが暗黙知で判断している、といったことがよくあります。
現状を正しく把握したうえで、改善後の姿を考えることが大切です。
業務部門とIT部門の両方を巻き込む
システム開発やDXは、IT部門だけでは成功しません。
業務を知っているのは業務部門です。一方、システムやデータ、セキュリティ、運用を考えるのはIT部門です。
両者が一緒に整理することで、現場に合い、運用しやすく、将来の拡張にも耐えやすい仕組みになります。
粒度を細かくしすぎない
フレームワークを使うと、細かく整理したくなることがあります。
しかし、最初から詳細に作り込みすぎると、時間がかかりすぎます。読み手にとっても分かりにくくなります。
最初は大きな流れを整理し、必要に応じて詳細化するのがおすすめです。
作った資料を更新する
ITや業務は変化します。
業務フロー、データ構造、権限、システム構成、セキュリティ要件は、時間とともに変わります。
一度作ったBPMN、ER図、CRUDマトリクス、要件定義書を更新しないまま放置すると、実態とずれてしまいます。
重要な資料は、変更時に更新する運用ルールも決めておくことが大切です。
まとめ
IT・システム・業務設計で使うフレームワークは、複雑な業務やIT課題を整理するための実務的な道具です。
要件定義フレームは、何を作るのかを整理するために使います。UMLは、システムの構造や動きを図で表すために使います。BPMNは、業務プロセスを可視化するために使います。DFDは、データの流れを整理するために使います。CRUDマトリクスは、データ操作や権限を整理するために使います。ER図は、データ同士の関係を整理するために使います。
TOGAFやZachman Frameworkは、全社的な業務とITの構造を整理するために使います。ITILはITサービス管理、COBITはITガバナンスに役立ちます。DevOpsとCI/CDは、開発と運用を連携させ、継続的に改善するために使います。Zero TrustとSTRIDEは、セキュリティを強化するために使います。SWOT for DXは、DX推進の方向性や優先テーマを考えるために使います。
初心者は、まず要件定義フレーム、BPMN、DFD、ER図、CRUDマトリクスから学ぶとよいでしょう。これらは、業務システムや業務改善の基礎になるからです。
そのうえで、IT運用、ITガバナンス、セキュリティ、DX推進へと学びを広げると、仕事で使える範囲が大きく広がります。
まずは、自分が今抱えている課題が「要件」「業務プロセス」「データ」「運用」「ガバナンス」「セキュリティ」「DX」のどれに近いのかを考え、目的に合うフレームワークを1つ選んで使ってみましょう。
次に読みたい関連記事
要件定義から学びたい方へ
要件定義フレームとは？初心者向けに意味・使い方・具体例をやさしく解説
UMLとは？初心者向けに意味・使い方・具体例をやさしく解説
業務プロセスを整理したい方へ
BPMNとは？初心者向けに意味・使い方・具体例をやさしく解説
DFDとは？初心者向けに意味・使い方・具体例をやさしく解説
データ設計を学びたい方へ
CRUDマトリクスとは？初心者向けに意味・使い方・具体例をやさしく解説
ER図とは？初心者向けに意味・使い方・具体例をやさしく解説
IT戦略・IT運用を学びたい方へ
TOGAFとは？初心者向けに意味・使い方・具体例をやさしく解説
Zachman Frameworkとは？初心者向けに意味・使い方・具体例をやさしく解説
ITILとは？初心者向けに意味・使い方・具体例をやさしく解説
COBITとは？初心者向けに意味・使い方・具体例をやさしく解説
開発運用連携を学びたい方へ
DevOpsとは？初心者向けに意味・使い方・具体例をやさしく解説
CI/CDとは？初心者向けに意味・使い方・具体例をやさしく解説
セキュリティとDXを学びたい方へ
Zero Trustとは？初心者向けに意味・使い方・具体例をやさしく解説
STRIDEとは？初心者向けに意味・使い方・具体例をやさしく解説
SWOT for DXとは？初心者向けに意味・使い方・具体例をやさしく解説
