ITパスポート資格を2週間で取得するための学習用備忘録(システム開発)

システム戦略

経営資源を整理する手法

エンタープライズサーチ

エンタープライズ検索、企業内検索とも呼ばれる企業向け検索システム。

企業内に点在する様々な様式のデータ(PDFやDB)から横断的に情報を検索する。

EA(エンタープライズ・アーキテクチャ)

将来のあるべき姿を設定して、業務と情報システムを最適な状態に近づけ、効率的な組織を運営する手法。

組織を構成する人的資源、業務やシステム、データなどの要素を整理し、階層化して相互関係を明確にする。

その上で、業務プロセスや取り扱うデータの標準化を行うことで、企業が持つ資源の重複や偏在をなくして、全体最適の観点から資源を効率的に配分することができる。

最適化を行う際に、現状と理想の際を把握するためのギャップ分析という手法を使って課題を洗い出す。

EAは、「ビジネス・アーキテクチャ(どのようにビジネスを行うのか)」「データ・アーキテクチャ(どんなデータをどのように扱うのか)」「アプリケーション・アーキテクチャ(どんな機能を持ったシステムをどのように使うのか)」「テクノロジー・アーキテクチャ(どこでどんな技術を使うのか)」という４つのアーキテクチャで構成される。

業務プロセス

モデリングの手法

E-R図：システムで扱う情報とその関係を表した図。実体(エンティティ)、関連(リレーションシップ)、属性(アトリビューション)の3つの要素で表現する。

DFD：システムで扱うデータの流れを表した図で、システムの設計時などに作成される。源泉(入力・出力)、プロセス(処理)、データストア(ファイルやDB)、データフロー(データの流れ)という4つの記号で表す。

データがどこから入力されてどこで出力されるのかを図にすることで、データの流れやシステムの全体像が明確になる。

業務プロセスを分析するための手法

BPR：業務プロセスから根本を見直し、業務プロセスを再構築することで、企業の体質や構造を抜本的に変革すること

BPM：業務プロセスの問題発見と改善を継続的に実施していく活動

ワークフロー：経費の精算や申請などの事務処理などをルール化・自動化することで円滑に業務が流れるようにする仕組みや、そのためのツール

ソリューション

ソリューションビジネス

業務上の課題を解決するサービスを提供するのがソリューションビジネス。

システム構築などを請け負うサービスをシステムインテグレーション(SI)といい、企業がシステム運用などの業務を外部の事業者に委託することをアウトソーシングといいます。

クラウドコンピューティング

クラウドコンピューティングではインターネットを通じて事業者が提供するサービスを必要な分だけ柔軟に利用できる。

Saas：ハードウェア、アプリケーションを提供するサービス

Paas：ハードウェア、OS、ミドルウェアを提供するサービス

Iaas：ハードウェア、OSを提供するサービス

Daas：コンピュータのデスクトップ環境を提供するサービス

ホスティングサービス

事業者が所有するサーバを借りて利用するサービス。

運用・保守も事業者が行うため、人件費や設備費用などのランニングコストが抑えられる。

ハウジングサービス

事業者が所有する設備に利用者が所有するサーバを預けるサービス。

運用・保守は原則として利用者が行う。ハードウェアの選定や組み合わせは自由にできる。

ASP

インターネット上でアプリケーションを提供する事業者。

オンプレミス

自社でサーバなどの機器を導入・運用する方式で、自社運用とも呼ばれる。

データ活用

BIツール

企業に蓄積された大量のデータを集めて分析し、可視化するツール。

業務や経営の意思決定、マーケティング分析に利用されている。

データウェアハウス

ウェアハウスは「倉庫」。

業務で発生した様々なデータを時系列に保管したもので、DWHと略されることもある。

一般的に使われているDBのデータはデータ量が増えすぎないように不要なデータから削除されるが、データウェアハウスのデータは削除されない。

データマイニング

データウェアハウスなどに蓄積された大量のデータを分析し、新しい情報を発掘すること。

文字データだけでなく、画像、音声、動画といった様々な種類の膨大な情報(ビッグデータ)を企業が収集し、分析できるようになった。

コミュニケーションツール・普及啓発

コミュニケーションツール

Skypeを使ったテレビ会議やChatwork、Slack等のビジネスチャットを活用

ゲーミフィケーション

ゲーム的な要素をゲーム以外の分野に取り入れ、利用者のモチベーションを高めたり、その行動に働きかける取組み。

ディジタル・ディバイド

インターネットなどの情報技術を使いこなせる人と使いこなせない人の格差。

「情報格差」とも呼ばれる。

システム企画

システム化構想

情報戦略システム戦略に基づいて経営上の課題やニーズを把握し、どのような情報システムが必要で、どのように開発・導入するかといったシステム化の構想を作成する作業。

システム化計画

システム化構想を具体化するために、システムで解決する課題、スケジュール、概算コスト、効果などシステム化の全体像を明らかにし、実施計画を作成する作業。

システム化基本方針

システム化構想によって洗い出した事項をシステム化基本方針として策定する。

具体的には、次のような内容。

・システム化の計画

・システムの全体像

・システム化の範囲

・スケジュール

・概算コスト

など

システム化計画の手順

1.スケジュールの検討：情報システム戦略に基づき、システム全体の開発スケジュールを検討する

2.開発体制の検討：システムの開発・運用部分だけでなく、システムを利用する業務部門を含めて必要な体制を検討する

3.運用範囲の検討：システム化の対象となる業務範囲を検討する

4.費用対効果の検討：システムの開発・運用にかかる費用とシステム導入による効果を見積もり、費用対効果が見込めるかどうかを検討する

5.リスク分析：システム化を行う上で、どこにどのようなリスクが存在するかを洗い出し、そのリスクの影響を分析する

要件定義

要求の調査

経営者や直接システムを利用する担当者との打合せやインタビューにより、利用者の要求を収集する

要件の分析

要求の中には、利用者の希望や不満だけでなく、理想なども含まれるため、調査、収集した利用者の要求は整理する必要がある。

利用者と開発者の間で合意が取れ、システム化の対象となった要求は「要件」として、定義される。

要件定義

要件定義の3つの種類

業務要件定義：システム化の対象となる業務に必要な要件を定義する。例「月末の業務フローとして顧客に請求書を一斉に送付する」

機能要件定義：業務要件を実現する上で必要な機能を定義する。例「請求書を送付するためには請求書の印刷機能を定義する」

非機能要件定義：業務要件を実現する上で必要な機能面以外の要件を定義する。性能や可用性などの要件が該当。例「月末のアクセスが集中する月であっても1秒以内に画面遷移する」

非機能要件の例

可用性：システムの稼働時間や停止などの運用スケジュール

性能・拡張性：応答時間、処理件数や業務量増大率の許容範囲

運用・保守性：バックアップや運用監視の方法

移行性：システムの移行時期や移行方法

セキュリティ：アクセス制限、データの暗号化、マルウェア対策

環境対策：耐震・免震、CO2排出量、低騒音

調達計画・実施

調達の流れ

調達の基本的な流れは以下の通り

1.情報提供依頼(RFI)

2.提案依頼書(RFP)の作成と配布

3.選定基準の作成

4.発注先からの提案書および見積書の入手

5.提案内容の比較評価

6.調達先の選定

7.契約締結→受入・検収

RFI(Request For Information:情報提供依頼)

システム化を行う発注元が、開発ベンダなどの発注先への提案依頼書を作成する前に、発注先に対してシステム化の目的や業務概要を明示し、システム化に関する技術動向などを集めるために情報提供を依頼すること。

RFP(Request For Proposal:提案依頼書)

発注元が発注先の候補となる企業に対し、導入システムの要件や提案依頼事項、調達条件などを明示し、具体的な提案書の提出を依頼するための文書。

提案書

発注先が、提案依頼書をもとに検討したシステム構成や開発手法などの内容を、発注元に対して提案するために作成する文書。

見積書

システムの開発、運用、保守などにかかり費用の見積もりを示した発注先が作成する文書。

発注先の選定や発注内容を確認するために重要な文書。

システム開発プロセス

要件定義

利用者の要求を明確にし、システムにどのような機能が必要なのかを要件として定義する。

要件の観点には、品質特性が用いられる。

「漏れている機能がないか？」などと、利用者参加のユーザレビューによって検討し、事前に合意を得ておく必要がある。

品質特性とは、システムの品質を検証する際のポイント。機能性、信頼性、使用性、効率性、保守性、移植性があります。

設計

設計は、次の順序で行う。

1.システム方式設計(非機能要件を実現するためのハードウェアの構成など)

2.ソフトウェア方式設計(機能要件を実現するための画面のレイアウトや印刷物など)

3.ソフトウェア詳細設計(具体的なプログラムの設計)

プログラミング

ソフトウェア詳細設計書にもとづき、プログラム言語の規則にしたがってプログラムを作成(コーディング)する。

作成したプログラムに誤り(バグ)がないかを動作検証するために、個々のプログラムをテストする(単体テスト)。

このように、プログラムの内部構造を元にテストする方法をホワイトボックステストという。

テストが失敗した場合は、プログラムを解析(デバッグ)して、バグの箇所を見つけて修正する。

テスト

単体テスト(プログラム単位の検証)→結合テスト(プログラムを結合した処理の検証)→システムテスト(システムの機能、非機能要件の検証)→運用テスト(実際のデータや業務手順に沿った検証)→受入テスト(要件を満たしているかを利用者が検証)の順序で行う。

単体テスト以降のテストでは、機能の仕様(何を入力すると何が出力されるか)に着目したブラックボックステストが実施される。

見積もり方法

ソフトウェアの開発規模、開発環境などに基づいて、開発工数や開発期間などの見積もりを行うときの基本的な考え、手法

ファンクションポイント(FP)法：利用する画面の数やファイルの数、機能の複雑さなどを数値化してシステムの開発規模や工数を見積もる手法。画面やファイルが多いシステムの見積もりに有効。

類似見積もり法：過去の似たようなシステムの実績を参考に、システムの開発工数や開発費用を算出する。

相対見積：基準となる作業を決めて、その作業を「1」として、その作業との相対的な大きさを見積もる手法。

ソフトウェア開発手法

構造化手法

システムの機能に着目して、大きな単位から小さな単位へとプログラムを分割して開発する手法

オブジェクト指向

システム化の対象そのものに着目した開発手法で、効率的に安全なプログラムを書くための工夫がされている。

オブジェクト指向4つの特徴

クラス：システム化の対象をクラスで表す。クラスはデータとデータに関する処理を持っている。オブジェクト指向ではクラスが連携してシステムを構成する

カプセル化：プログラム内でデータが不正に書き換えられないように、クラス内のデータを他のクラスから直接操作させない仕組み

継承：似たようなクラスが既にある場合、そのクラスをコピーして使うのではなく、そのクラスのデータや処理を引継ぎ、差分だけ記述するという仕組み

UML(Unified Modeling Language)：オブジェクト指向で開発する際の設計図の記法で、システウの構造や振る舞いを表すための図。

ユースケース図はユーザと機能の関係を表した図で、要件定義などで利用されている。

アクティビティ図は業務の流れを表した図。

誰が何をするのか業務の手順を表していて、業務フロー図などで利用されている。

DevOps

開発と運用を組み合わせた造語。

効率的な開発と安定した運用の両方に着目して、システムの開発チームと運用チームがお互いに協力し合うことをいう。

開発モデル

ウォーターフォールモデル

システム開発プロセスについて、要件定義からテストまでを順番に行う開発手法。

前の工程での作業に不備があると前工程から作業をやり直す必要がある。

最初から作るべき機能が明確になっているシステムで採用されている。

スパイラルモデル

要求ごとに要件定義からテストまでを繰り返して最終的にシステムを完成させる手法。

少しずつ開発してはテストを行うため、ユーザのフィードバックを受けて臨機応変な対応ができるのがメリット。

アジャイル開発に似ているが、アジャイルは完成した機能を運用しながら次の機能の要件定義からテストを行う。

プロトタイピングモデル

開発の初期段階でプロトタイプと呼ばれる試作品を作成し、利用者に検証してもらうことで、後戻りを減らすための開発手法。

試作品の確認を行いながら開発を行うため、利用者と開発担当との認識のずれが起こりにくいというメリットがある。

RAD(Rapid Application Development)

Rapidは「迅速」。ソフトウェアの開発を容易にする手法の1つ。

RADツールという、プログラムコードの自動生成などの機能を使い、ソフトウェアの開発を高速化することができる。

リバースエンジニアリング

完成したプログラムから設計書などの仕様やコードを作成する手法。

すでに運用しているシステムの設計書が不十分な場合や、オープンソースのソフトウェアを解析する場合に使う。

開発プロセスに関するフレームワーク

共通フレーム

ソフトウェアの企画、開発、導入、運用、履きに至るまでのソフトウェアプロセス全体のこと。

ソフトウェアプロセス全体に関係する全ての人が「同じ言葉を話せる」ように作成されたフレームワーク(共通の枠組み)、つまり、ガイドラインのようなもの。

発注者と受注者(ベンダ)の間でお互いの役割や責任範囲、具体的な業務内容について認識に差異が生じないことを目的に作られている。

CMMI(能力成熟度モデル統合)

開発と保守のプロセスを評価、改善するための指標のことで、システム開発を行う組織のプロセス成熟度を客観的に評価することを目的にしている。

成熟度は5段階に分かれており、以下のようなレベル分けがされている。

レベル1.初期状態：ソフトウェアプロセスは場当たり的で、個人の力量に依存する

レベル2.管理された状態：コスト、スケジュール、要件などの基本的なプロジェクト管理はできている

レベル3.定義された状態：プロセスは手順書などに文書化され、使用するツールも標準化されている

レベル4.定量的に管理された状態：プロセスの実績を定量的に理解されている

レベル5.最適化されている状態：レベル4の実績の定量的な理解により、継続的なプロセスの改善が可能になっている

プロジェクトマネジメント

PMBOK

プロジェクトマネジメントは、「目標達成のためには、途中のプロセスで何をすべきかを明確にしていく必要がある」というPMBOKの考えが元になっている。

PMBOKとは、プロジェクトマネジメントの知識を体系化した国際的なガイドのことで、プロジェクトを成功させるためのノウハウや手法がまとめられている。

プロジェクトマネジメントのプロセス

1.立ち上げ：プロジェクトを立ち上げ、目的や内容、成果物と作業範囲を明確にし、明確にした内容はプロジェクト憲章という文書に明文化する

2.計画：各作業の進め方の計画を立てる

3.実行：プロジェクトを実行に移す

4.監視・コントロール：プロジェクトの進捗やコスト、品質などを監視・コントロールする

5.集結・評価：システムが完成したら、プロジェクトを終結し、作業実績や成果物を評価する

プロジェクトマネジメントにおける管理対象

総合マネジメント：以下の9つの知識エリアを管理するための知識

スコープマネジメント：作業範囲(スコープ)を管理するための知識

タイムマネジメント：作業の進捗状況などスケジュールを管理する知識

コストマネジメント：開発費用などコストを管理する知識

品質マネジメント：テストで検出した不良数など品質を管理する知識

資源マネジメント：メンバーのスキルやパフォーマンスを管理するための知識

コミュニケーションマネジメント：メンバー間のコミュニケーションを効果的に行うための知識

リスクマネジメント：リスクを管理するための知識

調達マネジメント：サーバなどの物品購入などに関する知識

ステークホルダーマネジメント：ステークホルダー(利害関係者)へプロジェクト状況などを報告するための知識

スコープマネジメント

作業範囲を明確にし、作業の漏れをなくすことがスコープマネジメントの目的。

WBS：プロジェクトの作業範囲から作業項目を洗い出し、細分化、階層化した図。

タイムマネジメント

納期、作業時間、作業手順を管理することがタイムマネジメントの目的。

アローダイアグラム(PERT図)：各作業の関連性や順序関係を、矢印を使って資格的に表現した図。1日でも遅れるとプロジェクト全体に影響を与える経路をクリティカルパスという。

ガントチャート：プロジェクト管理や生産管理などで工程管理に用いられ、縦軸に作業項目、横軸に時間を取り、横棒の長さで作業に必要な期間を表す。

サービスマネジメント

ITIL(Information Technology Infrastructure LIbrary)

ITサービスの効果的な運用方法をまとめたガイドラインで、ベストプラクティス(成功事例)などが体系的にまとめられている。

ITILのカテゴリ

サービス・デザイン(サービスの設計)：サービスの設計や変更の際に安全に効率よく運用し、サービスの品質を維持する仕組み。サービスレベル合意書や可用性管理、サービスレベル管理などがある。

サービス・オペレーション(サービスの運用)：サービス・デザインで合意されたサービスレベルの範囲内で、利用者に対してITサービスを提供する方法。インシデント管理(障害管理)などがある。

サービスレベル合意書(SLA)

ITサービスの利用者と提供者の間で取り交わされるITサービスの品質に関する合意書。

ITサービスが保証する品質の範囲を決め、利用者と提供者の責任範囲を明確にする。

保証する品質を提供できなかった場合、ITサービス提供者はSLAに規定された罰則規定に従う必要がある。

可用性管理

ITサービスが必要なときに必要なだけ利用できるように管理すること。

年間のサービス稼働時間などの指標を設定し、稼働状況を監視し、目標を達成するために運用管理する。

サービスレベル管理

サービスの利用者と提供者の間で合意したサービスレベルを管理するための仕組み。

PDCAサイクルで継続的・定期的にサービスの品質について点検・検証する。

サービスサポート

サービスサポートの類型

インシデント管理(障害管理)：システム障害などのインシデントを解決し、サービスレベルを維持する。ITサービスの停止を最小限に抑えることを目的にインシデントに対し応急処置を行う

問題管理：インシデントを解決して根本的な原因を突き止め、インシデントの再発防止といった恒久的な対策を行う

構成管理：ハードウェアやソフトウェア、仕様書や運用マニュアルなどのドキュメントと、その組合せを最新の状態に保つ

変更管理：サーバの交換やOSのアップデートなど、ITサービス全体に対する変更作業を効率的に行い、変更作業によるインシデントを未然に防ぐ

リリース管理：リリースは本番環境への移行。変更管理のうち本番環境への移行が必要となるものを安全、無事にリリースする

バージョン管理：ファイルの変更履歴をバージョンとして保存し、管理する。複数で共同作業する際に開発や修正を円滑に進めるためによく利用されている手法

サービスデスク

システム利用者からの問合せに対する窓口機能として、問合せやインシデントの対応の記録と管理を行う。

効率的に対応するために、問合せ内容により適切な部署や担当者への引継ぎ(エスカレーション)を行ったり、FAQ(Frequently Asked Questions)として、よくある問合せの内容と回答をまとめておく。

最近では、電話やメールでの応対だけでなく、自動応答機能を使って会話形式での応対をするチャットボットも活用されている。

ファシリティマネジメント

施設や設備の管理。

無停電電源装置(UPS)

停電が起きてもしばらくの間電気を供給できる装置で、落雷などによる電源の瞬断や一時的な電圧低下などの影響を回避することができる。

停電時でもサーバなどを正常にシャットダウンするための時間を稼ぐことが目的。

自家発電装置

発電機などを使用して、長時間電源を供給発電できる装置。

通常は待機や停止状態で、停電時に発電を開始する運用が一般的。

そのため一瞬でも電源供給が断たれるとシステムに影響が出るような場合は、UPSなどとの併用が必要。

サージ防護

落雷などにより瞬間的に3000~4500Vもの高電圧が流れることをサージという。

これが電源線などを通って屋内に侵入すると、「パソコンに電源が入らない」などの故障に繋がる。

サージ防護機能のある機器はサージ吸収素子がサージを吸収するため、接続するパソコンやサーバなどの故障を防ぐことができる。

監査

監査の種類

会計監査：貸借対照表や損益計算書などの企業の財務状況が会計基準と照らし合わせて妥当であるかを判断し、問題点の指摘や改善点の勧告を行う

業務監査：企業の会計業務以外の業務活動が、経営目的と合致しているかどうかを判断し、問題点の指摘や改善策の勧告を行う。取締役が法律に従って業務が行っているかどうかを監査する

情報セキュリティ監査：情報セキュリティを維持・管理する仕組みが企業において適切に整備・運用されているかを点検・評価し、問題点の指摘や改善策の勧告を行う。

保有する全ての情報資産について、リスクアセスメント(リスクを特定するプロセス)が行われ、適切なリスクコントロール(リスクを予防・削減する対策)が実施されているかどうかを判断する

システム監査：情報システム戦略の立案、企画、開発、運用、保守までの情報システムに係るあらゆる業務が監査対象になる。情報システムについてリスクに適切に対応しているかに関して信頼性や安全性、効率性などを点検・評価し、問題点の指摘や改善策の勧告を行う

システム監査人の要件

実施される監査の公平性や客観性が保たれるように、システム監査人となるものにはいくつかの要件がある。

経済産業省が策定したシステム監査基準では、システム監査人に求められる立場として3つの要件を挙げている。

外観上の独立性：システム監査人は、システム監査を客観的に実施するために、監査対象から独立していなければならない。監査の目的によっては、被監査主体と身分上、密接な利害関係を有することがあってはならない

精神上の独立性：システム監査人は、システム監査の実施に当たり、偏向を排し、常に公平かつ客観的に監査判断を行わなければならない

職業倫理と誠実性：システム監査人は、職業倫理に従い、誠実に業務を実施しなければならない

システム監査

システム監査に関する基礎知識

システム監査基準

システム監査を効率的に行うためのもので、具体的な監査項目や、監査した結果をどのように評価するかなどが規定されている。

システム監査人

システム監査を行うシステム監査人については以下の規定がある。

・監査対象の領域または活動から、独立かつ客観的な立場であること

・客観的な視点から公正な判断を行うこと

・倫理観を保持し、誠実に業務を実施しなければならない

システム監査の流れ

1.監査計画：システム監査人が、対象部門、監査項目などをシステム監査計画書に記載する

2.予備調査：システム監査人が、関係者へヒアリングを行い、システムの概要を把握する

3.本調査：システム監査人が、調査・分析を行い、結果は監査証拠として保全する

4.監査報告：システム監査人が、システム監査報告書に監査結果や改善事項などを記載する。システム監査報告書をもとに、システム監査人が経営者に監査結果を報告する

5.フォローアップ：システム監査人は、システム監査報告書の改善事項について、定期的に監査対象に対して改善状況の確認を行う

内部統制

内部統制

内部統制は、以下の4つの目的を達成するために行われる

・業務を有効な方法で、かつ効率的に行う

・財務報告等の信頼性を確保する

・業務に関わる法令等を遵守する

・資産を保全する

上記4つの目的を達成するための基本要素

統制環境：経営者と社員の内部統制に対する価値基準や意識のこと。内部統制に関する全てのベースになる

リスクの評価と対応：内部統制の4つの目的の達成を阻害する要因をリスクとして分析し、評価、対応を行う

統制活動：経営者の命令や指示を適切に実行するための方針や手続きを行う。業務を分担せずに1人に任せると、不正行為やミスが発生する恐れがある。これを防止するために、お互いの仕事をチェックし合うように、複数の人や部門で業務を分担する仕組みを設けることを職業の分掌という

情報と伝達：必要な情報が組織内外と関係者に正しく伝えられること

モニタリング(監査活動)：内部統制が有効に機能していることを継続的に評価する

ICT(情報通信技術)への対応：業務の実施において組織の内外のICTを適切に運用する

ITガバナンス

ガバナンスとは「統治」の意味で、ITガバナンスとはITを効果的に活用して、情報システム戦略の実現を支援し、事業を成功へ導くこと。

情報システム戦略を実施する際には実施状況を監視し、問題点があれば改善を行っていく。