Lesson 3
マネジメント系
Lesson 3
Chapter 1
プロジェクトマネジメント
ここからはマネジメント系について触れていきます。
本チャプターではシステム開発を円滑に進めるために必要なプロジェクトマネジメントについて学んでいきます。
プロジェクトマネジメント
そもそも「プロジェクト」とは、特定の目標達成の為に定められた期間内でモノやサービスを生み出す業務を示します。
特徴としては「独自性」と「有機性」を持つことが挙げられ、独自のモノ・サービス(独自性)を決まった期間(有期性)で作り上げる必要があります。
また比較的規模が大きく、複数人(他社も含む)で進めていくのが一般的です。
具体的には下図のように建設工事や研究開発などもプロジェクトの一種となり、基本的にシステム開発はすべてプロジェクトに該当します。
これらのプロジェクトを円滑に運営し、成功に導くために必要なのが「プロジェクトマネジメント」です。
では具体的にプロジェクトマネジメントではどのような活動を行うのか見ていきましょう。
QCDの管理
まずプロジェクトマネジメントの核となる活動は「QCDの管理」です。
QCDは「品質(Quality)」、「予算(Cost)」、「納期(Delivery)」を示しており、プロジェクトマネジメントにおいて重要な3要素となります。
プロジェクトは顧客が求める製品やサービスを生み出し提供することが目的のため、品質が良くなければ
顧客への信用が下がり会社の売上にマイナスの影響が出ます。また品質が良くてもコストが高い場合は売値も高くなるため顧客が買ってくれません。
納期についても、当然守らなければ会社としての信用を失うことになります。これらの通りQCDをバランスよく管理することが重要であり、
QCDの達成がプロジェクトの成功と言っても過言ではありません。
QCDの重要性を知ったところで、各要素について見ていきます。各要素の説明は以下の通りです。
・品質(Quality)
品質は顧客が求める製品やサービスの達成度合いであり、QCDの中で最も重要な要素とな
ります。
顧客の要求に答えつつ、売上を向上・維持するためには、製品やサービスにおける品質の
高さが重要となります。品質を保つには事前に合格ラインを定め、それに基づいたチェッ
クを行うことが重要です。また高品質を目指すために設備投資や作業追加を行うとコスト
や納品までの作業時間が増加するため注意が必要です。
・コスト(Cost)
コストは製品やサービスを生み出すために必要な材料費や人件費の総称であり、全て計算
に加えて予算を立てる必要があります。
具体的には品質を落とすことなく納期までに制作するためにはどの程度のコストが必要か
という基準のもと検討します。また他の要素とのバランスを保つことも重要で多少価格が
高くなっても納期を優先しなければならないケースではコストの優先度を下げる必要があ
ります。
・納期(Delivery)
納期は顧客へ製品やサービスを納品する期日で、納期が遅れると会社としての信用が下が
ります。従って納期を守るために納品するまでのスケジュールを立てることが重要となり
ます。
具体的にはプロジェクト開始から納品までの各工程を書き出し、それぞれの工数とかかる
時間を試算しスケジュールを立てます。スケジュールの進行中も予定通り進んでいるかこ
まめに確認し、納期に遅れないように調整する必要があります。納期を優先し無理にスピ
ードを上げても、品質低下につながる恐れがあるため注意が必要です。
各要素の説明にもある通り、QCDは各要素が密接に関係しているため、下図の通りバランスよく運営・管理することが大切です。
PDCAサイクル
続いて、これらQCDを管理するための代表的な手法、「PDCAサイクル」を紹介します。
「PDCAサイクル」とはシステム開発の進捗やソフトウェアの品質管理などで用いられる手法であり、
下図の通り、「計画(Plan)」、「実行(Do)」、「評価(Check)」、「改善(Act)」のサイクルを繰り返すことで継続的な業務品質や業務効率の向上を図ることができます。
具体的にはある管理事項に対する実施計画を作成し、その計画に沿って実行します。その後、実行結果を確認・評価し、得られた改善点をもとに次の計画へ生かす、これらのサイクルを繰り返す流れとなります。
従ってこれらのサイクルを品質・コスト・スケジュール管理などに当てはめ実行することで、QCD各要素の改善・向上に繋がり、プロジェクト達成につなげることができます。
PDCAの全体像を理解したところで、各要素についても見ていきます。
・計画(Plan)
実行する計画の立案を行います。
まず目標を定め、それを実現するための手法や評価方法などを取り決めます。ポイントと
しては具体的な実行プランを明確にする、5W1H(誰が・何を・なぜ・どのくらい・いつま
で・どのように)の手法を用いて検討する必要があります。
・実行(Do)
計画に沿った実行を行うプロセスです。
実行後の結果を確認できるよう、情報やデータを記録することがポイントです。
・評価(Check)
実行が計画に沿っているかどうかを検証・確認します。
可能な限り数値を用いて具体的に評価を行う必要があります。
・改善(Act)
評価した結果を元に改善点をまとめます。
これらの改善点を次の計画に盛り込み、継続的な業務管理の改善を図ります。
これらの通り、PDCAサイクルはQCDの管理において必要不可欠な手法となっており、プロジェクトマネジメントの活動においては押さえておくべきものとなります。
PMBOK（ピンボック）
ここまでは製品やサービスに対する評価のQCDの管理について着目してきましたが
近年のシステム開発は、昔と比べて複雑化しており、「QCDを高める」という曖昧な基準では、プロジェクト管理が出来ないことが増えてきています。
そこで近年注目されているのが、プロジェクトのフェーズ毎にプロセスを定義した「PMBOK（ピンボック）」という知識体系です。
QCD管理は製品にフォーカスしていますが、PMBOKではプロジェクトのプロセスを管理し製品やサービスを作っていくものとなります。
ではPMBOKではどのような要素・プロセスを管理するのかみていきましょう。
まずPMBOKではプロジェクトの進み度合いを5つに分けて定義しています。
具体的には「立ち上げ」、「計画」、「実行」、「監視・コントロール」、「終結」の5つのプロセスに分け、管理していきます。
各プロセス説明は以下の通りです。
①立ち上げ
目的、成果物、予算などを定めるスタートフェーズです。
②計画
各タスクの洗い出しや順序を決める計画フェーズです。
③実行
計画に基づき、各プロセス・作業を遂行するフェーズです。
④監視・コントロール
実行結果と計画との差異を監視し、必要であれば日程や予算を調整するフェーズです。
⑤終結
プロジェクトの結果を検証・報告すると共に、成果物を納品しプロジェクトを終了させる
フェーズです。
全体としては下図の通り、立ち上げ、計画、実行、監視・コントロール、集結の順序で進み、必要に応じて計画を練り直すこともあります。
これらはPDCAサイクルの考えを適用でき、実行結果と計画との差異を確認し、日程・予算などに影響があれば必要に応じて調整を行う必要があります。
次にPMBOKでは上記プロセスグループを適用する管理項目が10種類あると定義されています。
具体的には以下の10項目(10個の知識エリア)に適用し、それぞれを管理していくことが重要となります。
①プロジェクトの統合
②プロジェクトのステークホルダ
③プロジェクトのスコープ
④プロジェクトの資源
⑤プロジェクトの時間
⑥プロジェクトのコスト
⑦プロジェクトのリスク
⑧プロジェクトの品質
⑨プロジェクトの調達
⑩プロジェクトのコミュニケーション
上記「①プロジェクトの統合」は残りの9つを統合的にマネジメントする領域となります。QCDにあたる「品質管理」、「コスト管理」、「納期管理」も、10個の知識エリア内に含まれています。 Chapter1ではこれら10の管理項目を1つずつフォーカスして学習を進めていきます。
PMBOK
アメリカの非営利団体PMI(Project Management Institute)が策定したモダンプロジェクトマネジメントの知識体系。 プロジェクトマネジメントの遂行に必要な基本的な知識を汎用的な形で体系立てて整理したものです。
プロジェクトの統合
前述の「PMBOK」で定義されている要素、「プロジェクトの統合」について学習します。
プロジェクトの統合はPMBOKで定義された10の管理項目のうち、自身を除いた9項目を統合して管理する活動です。イメージは下図の通りです。
上記通り、プロジェクトの統合ではそれぞれの管理要素に対し全体的に指揮・管理・調整を行います。
具体例としてプロジェクトのスコープとプロジェクトの時間で考えてみます。
プロジェクトのスコープでは作業範囲を管理し、プロジェクトの時間ではスケジュールを管理しますが、仮に作業範囲が広がった場合は作業期間も延長する必要があるため、
これら2つの項目は連動していることが分かります。
従ってプロジェクトのスコープとプロジェクトの時間は連携して考える必要があり、それぞれバラバラに管理した場合、円滑にプロジェクトを進めることができず、さまざまな問題を起こすことが考えられます。
よってこれらの事態を避けるためにも、各管理項目を統合的に指揮・管理・調整する必要があります。
ではどのように全体を管理していくのか見ていきましょう。
プロジェクト計画
全体管理の方法としては「プロジェクト計画」が挙げられます。
プロジェクト計画とはプロジェクトのスコープ、時間、コストなど、プロジェクト全体に関わる計画をまとめものであり、この計画をベースにプロジェクトの全体を管理していきます。
プロジェクト計画は特に定まったフォーマットがないため、プロジェクトによって様々ですが基本的には、以下の項目が含まれています。
・プロジェクトの達成目標
プロジェクトのおける達成目標を明確にします。
達成目標を明確にすることでプロジェクト計画の根拠を明確にできることや、プロジェク
トメンバー全員が共通認識を持ち、同じベクトルに向かって効率的に業務を進めていくこ
とができます。
・目標達成の評価指標
設定した目標に対して、評価基準を設定し、目標達成を測定できるようにします。
プロジェクト成功の基準も大切ですが、成功に向かって仕事が順調に進んでいるかを示す
評価指標も必要になります。仕事が順調に進んでなければ、立て直しを図る必要があるた
め、基準を設けることは重要となります。
・関係者と役割
プロジェクトの関係者とその役割を明確にします。
各メンバーの業務や各業務における責任者を取り決めることで、関係者間の関わりが明確
にできる他、情報の伝達などにおいても効率に行うことができるため予め明確にすること
が重要です。
・予算の設定
プロジェクト内で必要となる予算を明確にします。
各作業において必要となってくる予算を事前に明確にし、実行時に適切に割り当てられる
ようにします。計画があればどのくらいの費用が必要かを判断することができ、あとで突
然費用が必要になることを防ぐこともできます。
・マイルストーンと成果物
プロジェクト成功までの各節目としてマイルストーンを設定します。
各節目ごとに成果物の達成度合いを設定することで、プロジェクト成功までの現在地がわ
かる他、成果物やマイルストーンを中心にプロジェクトの状況を簡単に整理することがで
きます。
・スケジュール
プロジェクト全体のスケジュールを明確にします。
プロジェクトの目標を達成するには、プロジェクト全体や各作業のスケジュールを定める
ことが重要です。これらスケジュールを定めることで、作業順序の計画が明確になる他、
誰が何をいつまでに担当するかが鮮明になり、各メンバーが効率良く業務に取り組むこと
ができます。
・コミュニケーション計画
プロジェクトの現状や進捗、次の予定を全員が確実に把握できるように、コミュニケーシ
ョン計画を設定します。
具体的にはプロジェクトに関連した会議を定例として週1で実施するか、その会議での議題
や役割などを明確にします。これらの計画を設定することで、障害や問題が起きた際に素
早く情報を共有し対応することも可能となります。
これらの通り、事前にプロジェクト計画を策定することで、プロジェクト全体を統合的に管理することができる他、 プロジェクトの各管理項目についても事前に計画を策定することが可能となります。
プロジェクトのステークホルダ
プロジェクトのステークホルダについて学習します。
「ステークホルダ」は日本語で利害関係者の意味を持ち、プロジェクトメンバ、プロジェクトマネージャ、
顧客、株主、経営者、地域などのように、プロジェクト活動によって利害が生じる可能性があるすべての者を示します。
またプロジェクトに直接的に関わる者だけではなく、間接的に影響を受ける可能性がある者も含まれ、
そのプロジェクトによって利益になる者、損害になる者がいます。
具体的にはプロジェクトが成功し、会社の利益が増加した場合は、その会社の従業員や融資している株主などにとってはプラスとなり給料や配当などが増えるメリットがあります。し
かしプロジェクトにより会社が赤字となった場合は、どちらもマイナスの影響となり、従業
員のモチベーションや株主からの信頼が得られなくなります。よって業務効率が低下したり
、資金融資をしてもらえなくなったりと、プロジェクトにも影響を及ぼす可能性がありま
す。
マイナスの影響だけでなく、プラスの影響も考えられますが、プロジェクトに影響を与えるのは同様のため、プロジェクト開開始前にステークホルダを特定し事前に対策を準備することが大切です。
まずはプロジェクトにおける一般的なステークホルダーを見ていきましょう。
①顧客
プロダクトやサービスの直接的なユーザー。
②プロジェクトマネージャー
プロジェクトのリーダー。
③プロジェクトチームのメンバー
プロジェクトマネージャーの指導のもとプロジェクトを実行するグループ。
④プロジェクトのスポンサー
プロジェクトの出資者。
⑤運営委員会
主な決定事項に関して指導を行う顧問グループ。
⑥幹部社員
プロジェクトを実行する企業の経営陣。
⑦リソースマネージャー
プロジェクトの実行に必要なリソースを管理する他のマネージャー。
以上が、一般的なステークホルダとなります。
これらステークホルダと良好な関係を保つことができれば、プロジェクトも円滑に進むこと
ができます。
良好な関係を保つための方法としては、プロジェクト開始時のキックオフミーティングやコミュニケーションツールを使用などがあります。
キックオフミーティングはプロジェクト開始時にステークホルダに対して開催するミーティングで、プロジェクトはどのような目的で立ち上げられたか、またシステムの概要や体制図、主な作業などを示し、お互いの役割分担を確認する場となります。そして課題の管理方法や進捗の共有方法などのプロ
ジェクト運用ルールの合意を得ることができ、事前にステークホルダとの関係を構築するこ
とができます。
またコミュニケーションツールはチャットやメールなどを示しており、プロジェクトの置か
れている状況や他のメンバーの課題を共有するよう、適切に使用します。状況や課題を共有
することで、メンバーそれぞれにプロジェクトに関心を持ってもらい協力的に関わって貰え
る効果があります。
また重要なのは特定のステークホルダのほうだけ向いて管理するのではなくその他のステークホルダとの関係も良好に保つことが重要となります。
これらの活動を行うことで企業の信頼度も大きくなり、売上増加や利益向上につなげることができます。
その他ステークホルダー
プロジェクトによっては他にも多数のステークホルダーが存在します。
例）売り手・サプライヤー、業者、オーナー、諸官庁、報道機関など
プロジェクトのスコープ
続いてプロジェクトを円滑に進め、成功へ導くために必要不可欠な、プロジェクトのスコープについて学習します。
まずスコープとは一般的に視野、範囲などの意味があります。これらはプロジェクトにおいて作業範囲を示し、やるべき作業とやらない作業を区分けすることができます。
よってプロジェクトのスコープは期限が決まっているプロジェクトに対して不要な作業が発生しないよう、事前に作業範囲を明確にしていく活動となります。
またプロジェクトにおけるスコープには「プロジェクトスコープ」および「プロダクトスコープ」があり、
前者はプロジェクトでやるべき作業の明確な範囲、1つ1つの作業、それらの期限などを意味します。
後者はプロダクトやサービスの特徴を決定づける機能を意味し、どんな成果物を作るか？を定義しています。
それぞれプロジェクトマネジメントにおいては必要な要素となっており、必要な工程や成果物を明確にすることで、プロジェクトの計画を立てることができます。
ではそれぞれのスコープについて具体的に見ていきましょう。
・プロジェクトスコープ
プロジェクトスコープではプロジェクトにおいてどの工程・作業が必要になるのかを明確
にしていきます。
具体的には要件定義、基本設計、詳細設計、コーディング、テストなどの工程を示し、こ
れらの工程の中でもどのような作業が求められるのかを明確にします。
これを怠ると途中で予期せぬ作業・工程が発生し、プロジェクトが計画通りに進まなくな
ります。
システム開発における代表的な工程
要件定義・基本設計・詳細設計・コーディング・テスト
・プロダクトスコープ
プロダクトスコープはプロジェクトで得るべき成果物の管理を示し、何を作るかに焦点を
当てます。
例として基本設計の工程では、仕様書や設計書が成果物となります。 従ってプロジェク
トスコープよりも各工程の達成度合が正確に把握できるのがメリットとなります。
成果物を残すことで各工程の進捗もわかるため、これらは必要な要素となっています。
スコープ管理
また下図のようにこれら２つのスコープを管理することを「スコープ管理」といいます。
スコープの管理はプロジェクト成功に必要な工程や成果物などを明確にするため、重要な活動となります。
では具体的にどのような流れでスコープ管理を実施していくのか見ていきましょう。
定義から検証までの流れは以下の通りです。
①スコープの定義・決定
始めにスコープを定義するため、求められる作業を洗い出します。必要な要件をリストア
ップし、それぞれにかかる工数を見積ります。
その後、コストや納期を踏まえ実際にやるべき作業・工程を定義します。
②スコープの具体化
スコープを定義した後、実際の作業内容を具体化します。
具体化には、「WBS(WorkBreakdown Structure)」という、作業を段階的に分解する(トッ
プダウン方式)手法などを用いて実施します。
下図の通りWBSは上位の作業に対して、必要な成果物やそれに紐づく作業などを段階的に
定義することでプロジェクトにおける作業・工程・成果物を明確にすることができます。
③スコープの検証とコントロール
具体化したスコープが妥当なものであるかを検証し調整を加える必要があります。
作業を進めていく上で、成果物がスコープに準じて作成されていない場合やベースライン
と現状に乖離が生じた場合は、スコープに変更を加える必要があります。
よって計画して終わりではなく、常に状況を監視しながらスコープと作業を調整すること
が重要です。
以上がスコープ管理の流れです。
これらの通り、スコープ管理はプロジェクトの計画や検証に密接に関わっている活動となります。
プロジェクトの資源
プロジェクトにおいて資源はとても重要であり、資源がなければプロジェクトは先に進みません。
ではプロジェクトにおける資源とは何でしょうか。
それは人、モノ、お金などを示すほか、プロジェクト・チームのメンバーが作業する時間、
施設なども含まれます。これら資源はプロジェクトにおいて必須であり、適切に管理することが重要です。よってプロジェクトの資源はこれら資源を適切に管理していく活動となります。
プロジェクトは資源がなければ作業が進まないため、事前にどの資源がどの程度必要かを見積もることが求められます。
例えば、とあるプロジェクトにて開発期間および開発工数から必要人員を算出するケースを考えます。
開発期間10ヵ月、開発工数200人月のプロジェクト計画で下記の配分表を前提とし、ピーク時の要員は何人となるでしょうか。
ここでは各工程の開始から終了までの人数は変わらないものとします。
| 要件定義 | 設計 | 開発・テスト | システムテスト | |
|---|---|---|---|---|
| 工数配分 | 16% | 33% | 42% | 9% |
| 期間配分 | 20% | 30% | 40% | 10% |
まず開発期間10ヵ月に各工程の期間配分、開発工数200人月に各工程の工数配分を掛け合わせます。
[工程ごとの開発期間]
・要件定義 10ヵ月 × 20% = 2ヵ月
・設計 10ヵ月 × 30% = 3ヵ月
・開発・テスト 10ヵ月 × 40% = 4ヵ月
・システムテスト 10ヵ月 × 10% = 1ヵ月
[工程ごとの工数配分]
・要件定義 200人月 × 16% = 32人月
・設計 200人月 × 33% = 66人月
・開発・テスト 200人月 × 42% = 84人月
・開発・テスト 200人月 × 9% = 18人月
あとは工数を開発期間で割れば1ヵ月毎の要員数が算出できます。
・要件定義 32人月 ÷ 2ヵ月 = 16人
・設計 66人月 ÷ 3ヵ月 = 22人
・開発・テスト 84人月 ÷ 4ヵ月 = 21人
・システムテスト 18人月 ÷ 1ヵ月 = 18人
よってピークは設計工程となり、その期間の要員数は22人ということがわかります。
これらのように事前に必要要員を見積もる場合は開発期間や工数を用いて導き出すことができます。
また上記要員算出も含めた資源の選定において、質(レベル)についても考慮する必要があります。
仮に開発工程に画面デザイン作業がある場合、そのデザインは経験20年の大ベテランのデザイナーにお願いするのか、
それとも新人でよいのかなど、選択肢によって価格が変わるため予算なども考慮する必要があります。
したがって必要とされる資源の質も考慮して計画することが重要になります。
プロジェクトの時間
続いてプロジェクトにおける時間について学習します。
プロジェクトは期間が定まっているため、遅れが生じると顧客からの信頼が低下し、会社としての利益低下にもつながる恐れがあります。よって時間管理は重要な管理項目であり、
「プロジェクトの時間」は、定められた期間内にプロジェクトを完了することを目的とし、監視・スケジュール管理を行う活動を示します。
特に時間は有限のため、様々な要素に影響することを理解する必要があります。作業における期間・時間が不足すると、成果物の提出が遅れるだけでなく、品質が低下する恐れがあります。 よってプロジェクトマネジメントでは作業期間を事前に見積り、計画を立てることが重要となります。
PERT(Program Evaluation and Review Technique)
ではどのように見積り、計画を立てていくのでしょうか。
例として日程計画の策定に使われる代表的な手法PERT(Program Evaluation and Review Technique)を紹介します。
PERTは活動同士の関連を表現し計画を立てていきます。
全体日数を計算する際、活動前後の関係に着目すると、前の活動が完了しなければ開始できない活動もあり、 並行して作業ができるとは限りません。 下図のようにPERTでは作業順序を矢印で表したアローダイアグラム(Arrow Diagram)を使って、作業の終了と次の作業の取り決めなどを整理し 全体の作業日数を算出することができます。
上記、結合点に複数の作業がある場合、最も長くかかる経路の日数が、その結合点までの所要日数となります。
例として結合点「あ」はA→B→D＝12日。A→C＝8日なので、所要日数は12日となります。
同様に、結合点「い」はA→B→E＝15日。A→B→D→F＝17日なので、所要日数は17日となります。
また最も所要日数がかかる経路を結んだA→B→D→F→G(20日)を「クリティカルパス」といいます。
クリティカルパス上にある作業が遅れると、作業全体の終了が遅れます。
従って、クリティカルパス上の経路を重点的に管理する必要があります。
逆に全体の所要日数を短縮したい場合はクリティカルパス上の作業を短縮する検討が必要となります。
ガントチャート
また作業の進捗管理を目的とした図法として「ガントチャート」があります。
縦軸に作業項目、横軸を時間として、作業開始から終了までの予定時間を線の長さで表現します。加えて実際の作業期間を示す線を描くことで
計画と実績を比較しながら状況把握することが可能です。
ガントチャートの例は次の通りです。
上記のように、各作業の計画及び実績を可視化することで、状況を把握することができ、早めに計画の練り直し体制を整えることができます。
これまでは作業時間の見積りや進捗管理についての方法を学習してきましたが、もし仮に計画通りに作業が進まず進捗が遅れる場合どのようにリカバリを取れば良いのでしょうか。
作業範囲を変えず、作業時間を短縮する方法について見ていきましょう。
・クラッシング
クラッシングとは作業範囲を変えずにスケジュールを短縮する方法です。
主にコストを追加することでスケジュールを短縮させます。
例としては２ヶ月のスケジュールを１ヶ月に短縮したい場合、新たに人を投入したり、作
業効率が上がるような設備を投資したりすることでスケジュール短縮を図ります。
・ファストトラッキング
ファストトラッキングも作業範囲を変えずにスケジュールを短縮する方法です。
計画上順番に進めていく作業を、先行の作業が完了する前に後作業を進めることでスケジ
ュールを短縮させます。
主に並行して作業を進めることとなるため、前工程に変更が入った場合、後工程の作業に
手戻りが発生する可能性があります。その場合作業時間が余計に増えてしまうため、これ
らのようなリスクを念頭に置く必要があります。
プロジェクトのコスト
定められた予算内でプロジェクトを完了させることが目的の「プロジェクトのコスト」について学習します。
プロジェクトにおけるコストは人件費のほか、開発環境や資材など、資源に含まれるものとなります。これらのコストが大きくなるとプロジェクトは赤字となるため事前にコストを見
積ることが重要となります。
よってプロジェクトのコストの主な活動は以下の2つとなります。
①プロジェクト活動に必要なコストの見積もり
②プロジェクト活動中のコスト管理
コストの見積りにおいては、人件費や工数をどれだけ正確に見積れるかが重要になります。
特にシステム開発ではプログラムの一部を自動生成するツールなども使用されていますが、
エンジニアが直接手をかける作業がまだ多くあるため、より正確に見積もることが肝となります。
仮に見積りよりも実績が大幅に超過してしまった場合はプロジェクトが赤字となってしまい大問題となってしまいます。
よってこれらコストの見積りはプロジェクトマネジメントにおいて必要な要素となり、コストを正確に見積もるために様々な見積手法を知っておく必要があります。
ではどのような見積手法があるのでしょうか。 代表的なコスト見積手法を紹介します。
①類推見積法
過去に開発したシステムの実績を基に、新システムとの相点などを分析し、必要
なコストを見積もる、トップダウン見積もりの代表的な手法。
②標準タスク法
WBSの最小単位であるワークパッケージやアクティビティの1つ1つから工数とコストを予
測。
それらを積み上げ合計することで、新システム全体にかかる工数やコストを見積もるボト
ムアップ見積もりの代表的な手法。
③プログラムステップ法(LOC法)
新システムで開発するプログラムの完成時のステップ数を予測。
すべてのプログラムの総ステップ数から工数やコストを見積もる手法。
LOC(Line Of Code)法ともいいます。
④ファンクションポイント(FP)法
プログラムに含まれる機能の数や、その機能の複雑度を基に、工数やコストを見積もる手
法。
上記のうちシステム開発でよく用いられるFP法について深堀します。
FP法ではプログラムに含まれた機能を種類ごとに分け、機能別個数と複雑度を用いてFP値を計算します。
機能を実現する処理部分の複雑さによってその部分の作成に必要な工数やコストは異なります。
よって複雑さの度合いを重みとして表し、その機能が含まれる個数とかけ合わせることで、FP値を計算します。
加えて、他のプログラムとの関係性などを基に定義されるプログラム全体の複雑度を補正係数と呼びます。この補正係数を算出したFP値と掛け合わせることでプログラム全体のFP値を算出することができます。
例として、あるソフトウェアにおいて機能の個数と機能の複雑度に対する重み付け係数をまとめたのが下記表になります。
| ユーザーファンクションタイプ | 個数 | 重み付け係数 |
|---|---|---|
| 外部入力 | 1 | 4 |
| 外部出力 | 2 | 5 |
| 内部論理ファイル | 1 | 10 |
上記ソフトウェアのファンクションポイントを計算してみましょう。ここで、ソフトウェアの全体的な複雑さの補正係数は0.75とします。
表中の各ファンクションタイプの個数に重み付け係数を掛け合わせたものの総和を求めます。
(1×4)＋(2×5)＋(1×10)＝24
複雑さの補正係数が0.75なので、得られたポイント数に補正係数0.75をかけ合わせます。
24×0.75＝18
以上の計算によって得られた18が、このプログラムの開発規模を表すファンクションポイント値となり、工数やコストの見積りにおいての指標となります。
FP法に限らず、様々な見積り手法があるためプロジェクトや業務に合わせて適切に選んでいくことが重要です。
プロジェクトのリスク
プロジェクトにおけるリスクについて学習します。
プロジェクトには様々なリスクが存在しており、事前に対策することが重要です。
仮にリスク対策ができていない場合、プロジェクトに何かしらの問題が起き、プロジェクトの遅延や品質低下などにつながる可能性があります。
よってプロジェクトのリスクはこれらプロジェクトにおけるリスクを事前に抽出し、適宜管理していく活動となります。
では具体的にどのようなリスクがあるのか見ていきましょう。
プロジェクトのリスクは主に2種類あります。1つは、発生したときにマイナスの影響を与えるリスクで
「脅威」ともいいます。2つ目は発生したときにプラスの影響を与えるリスクで、「好機」と呼ばれます。
発生が予測できるリスクにおいて、脅威はその影響を最小限に抑え、好機は最大限に活かせるよう、
あらかじめ対策を練り、発生時に確実に実行していくことが、リスクマネジメントでは重要です。
リスクマネジメント
リスクマネジメントは以下のような手順で実行することが推奨されています。
①リスクの特定
プロジェクトメンバに限らず、専門家や類似プロジェクトの経験者などからもヒアリン
グを実施し、予測できるリスクを洗い出す。
②リスクの評価
洗い出ししたリスクの発生確率や発生した場合の影響度を分析し、優先度を付ける。
③リスクへの対応
優先度の高いリスクについて、対応戦略と具体的な対応策を検討する。
④リスクの管理
発生したリスクへの対応、新たなリスク発生の監視や特定など、継続的にコントロール活
動を行う。
これらの通りリスクマネジメントでは、リスクをまず特定することからスタートします。 特定したリスクは評価、対策、管理という工程によりコントロールされますが、事前に抽出してなければそれぞれの工程に回すことができないため、 今後起こり得るリスクをできるだけ洗い出すことが重要です。
対応戦略
続いてリスクが発生した時の対応・考え方を示した「対応戦略」について説明します。
対応戦略は下記表の通り、好機と脅威それぞれに4種類ずつ、計8種類の対応戦略が記述されています。
| 対応戦略 | 対応例 | ||
|---|---|---|---|
| 脅威 | 回避 | リスクを避けるための対策を行う | ・プロジェクトそのものを中止 ・リスクを避けられるようプロジェクトの計画を変更 |
| 転嫁 | リスクの発生時に被るマイナスの影響を第三者に移転する | ・地震や火災など災害の発生に備え保険に加入しておく ・開発用機材はメーカー保証のあるものを用意する |
|
| 軽減 | リスクの発生確率や発生した場合のマイナスの影響を許容できるレベルに抑える | ・故障の発生を避けるため古い機材を使用しない ・作業の手戻りを防ぐため、レビューやテストを念入りに実施 |
|
| 受容 | リスクの発生やそこから受ける影響を容認する | ・積極的な対応は行わない | |
| 好機 | 活用 | 好機が確実にくるように対策を行う | ・類似プロジェクトの経験者をプロジェクトマネージャーに迎える ・開発に必要な技術のスペシャリストをプロジェクトメンバに加える |
| 共有 | 好機を得やすいように第三者にプロジェクト活動の一部を割り当てる | ・類似例の実績が豊富なインテグレータに開発を委託 ・外部の専門家にアドバイザーを依頼 |
|
| 強化 | 好機の発生確率を高める要因や、プラスの影響を増大させる要因を最大化させる | ・より高速処理が可能なサーバーを開発用に準備 ・品質向上のため通常よりもプロジェクト期間を長めに設定 |
|
| 受容 | リスクの発生や、そこからうける影響を容認する | ・積極的な対応は行わない | |
上記対応戦略は、マイナスの影響の脅威とプラスの影響の好機に大きく分かれています。
例として、脅威における転嫁について見ていきましょう。
対応戦略としてはリスク発生時に被るマイナスの影響を第三者へ移転するとあります。
具体的には開発用機材が故障した場合などが挙げられます。機材が故障した場合は再購入によるコストがかかったり、より大きなものであればすぐには納品されず作業が止まってしまうなど、マイナスの影響が生じます。
これらマイナスのリスクは機材メーカーの保証や保険などに入っておくことで対策でき、いざ故障した場合でもメーカー側へリスクを移転することができます。
以上のように、それぞれのリスクについての対応が記述されたのが「対応戦略」となります。
リスクマネジメントにおいては、これらの対応戦略を参考に可能な限り事前に対策を練っておくことが重要となります。
プロジェクトの品質
プロジェクトにおける品質について学習します。
まずシステム開発では利用者からの要求を達成するために品質が重要になってきます。
あるシステムができたとしても、品質が悪ければ製品として成り立たないのはもちろん、利用者に多大な迷惑をかける可能性もあります。
よってプロジェクトの品質は会社としての信頼にも直結するため適切に管理する必要があります。プロジェクトの品質では達成すべき成果物の品質目標策定と品質レビュー、品質管理を実施し一定以上の品質を担保する活動を行う必要があります。
では具体的にどのように品質を管理していくのか見ていきましょう。
プロジェクトの品質を管理する上で、必要な手法を示すガイドラインとして「JIS規格」があります。
JIS規格の中でも代表的なものが「ISO9000シリーズ(JIS Q 9000 ファミリー規格)」です。
9000シリーズには複数の規格が含まれ、
利用者を満足させる品質提供のための品質管理・品質保証の方法について規定しています。
9000シリーズの例としてISO9001を紹介します。
ISO9001は会社や組織が提供する商品やサービスの品質向上を目的とした品質マネジメントシステム規格です。また品質だけではなく、価格や納期といった顧客要求事項を満たすことも求められています。
具体的にはQCDのバランスが求められており、品質だけに特化せず、品質・コスト・納期のバランスを重視して顧客対応を行うことが
ISO9001の規定となっています。
またISO9000シリーズは多様な製品全般に対応する品質管理の規格ですが、品質評価に特化した国際規格の「ISO/IEC25010」についても紹介します。
ISO/IEC25010は品質評価に関して8つの特性を定め、品質評価における観点を明示しています。
8つの特性については次の通りです。
| 特性 | 説明 |
|---|---|
| 機能適合性 | システム・ソフトウェア製品への要求に対して、実際に実現された機能の度合いを示す特性 |
| 性能効率性 | 稼働に用いる資源（ハードウェア、ソフトウェア、資材など）に対して得られる性能の効率を示す特性 |
| 互換性 | ハードウェアやソフトウェアの構成が同じ環境でシステムやデータを交換したり共有したりする場合の容易さに関わる特性 |
| 使用性 | 操作性やインタフェースのわかりやすさなど、システムの利用者が感じる使いやすさを示す特性 |
| 信頼性 | 定められた時間、与えられた条件下で必要とされる機能がきちんと稼働することを示す特性 |
| セキュリティ | システムやデータを保護し、なおかつアクセス権を持つ利用者には適切に提供できることを示す特性 |
| 保守性 | システム・ソフトウェア製品の修正・改変の容易さを示す特性 |
| 移植性 | ハードウェアやソフトウェアの構成が異なる別の環境へ移す場合の容易さに関わる特性 |
上記通り、品質評価は様々な観点から見ることが重要であり、品質向上や顧客満足度の向上にもつなげることができます。
品質向上の活動
ここまではプロジェクト全体の目線として品質について触れてきました。
ここからはシステム・ソフトウェア開発における品質向上の活動について触れていきます。
システム・ソフトウェア開発における品質向上のための重要な活動として「レビュー」「テスト」が挙げられます。
レビューは設計やプログラミングの工程で成果物の検証や再検討を行うことを示します。 複数のメンバが参加し、成果物の説明、問題点の指摘、改善策の検討などを実施します。
テストは設計内容や作成されたプログラムが定められた仕様と一致しているかを検証する作業です。 プログラム工程では設計工程で作成したテスト計画書に基づいて作成したプログラムが仕様通りに動作するか、要求されている性能を満たしているかをもれなく計画的に検証します。
続いてより具体的に品質を評価するための考えや方法について触れていきます。
代表的な手法をいくつか紹介します。
・ベンチマーク
ハードウェアやプログラムの処理能力を測るための手法です。
画面上に結果を定量的に表示でき、容易に処理能力を評価できます。
・信頼度成長曲線
テスト時間を横軸、検出したエラーの累積数を縦軸にし、テスト開始からの時間経過とと
もに変化するバグの累積件数の傾きを見ます。
テスト開始時は緩やかな曲線(エラーの検出数が少ない)を描き、テストが進むに従って傾き
が急(エラー検出数が増えていく)になります。終了時に近づくと傾きは穏やかになり、全体
としてS字カーブを描きます。
実際のテスト工程ではグラフの傾きが緩やかになり、バグの発見がごくわずかになれば、
必要な品質を満たしたと判断し、テスト工程を終了することができます。
・パレート図
項目のデータを降順に並べた棒グラフと累積値を表す線グラフを1つのグラフ内に併せて
表現した複合グラフです。
品質管理では不良原因ごとの不具合の発生件数などの度数を棒グラフで折れ線グラフで
全体に対する各項目の度数の比率累計を表すなどの使い方があります。どの項目が重要で
それが全体に占める割合がどの程度なのか一目でわかるため、管理活動では対策の優先
順位の検討などに使われます。
プロジェクトの調達
プロジェクト活動に必要な資源(ヒト・モノ・カネ)を外部から得て管理するプロジェクトの調達について学習します。
例としてはプロジェクトで必要な機材などが挙げられます。システム開発では開発用のPCが必要となるため、必要な機能仕様や費用を満たすPCを外部から調達する必要があります。
また必要に応じて調達先も選定しなければならないため活動の範囲は幅広いものとなります。
加えて調達の活動対象は資源だけでなく、システム開発自体をベンダーに委託する際の、委託先の選定・契約・監視、 進捗管理も活動に該当します。
調達
システムを購入したり、新たに作成(自社開発や外部企業への発注問わず)すること。
これらプロジェクトの調達は事前に考慮すべき項目が多いため、調達の計画が重要になります。 まずは要件定義書を踏まえ、製品やサービスの購入、内部や外部委託によるシステム開発などから調達方法を選択し、 調達の対象、要求事項、条件などを定義します。これらの定義を「調達計画」といいます。
では具体的に調達計画はどのような流れで進むのか紹介します。
流れは下記の通りです。
①システム要求事項の策定
開発対象のシステムにおける要求事項をまとめます。
②調達先選定基準、提案評価基準の作成
ベンダーからの提案書や見積書を検討する際、何を重視して選考を行うか、また提案書の
評価をどのようにするか、考慮する項目と選定の基準をあらかじめ決めておきます。
③調達先候補の選定
事前にベンダーへRFI(情報提供依頼書)を提供し、ベンダーから提供された情報を基に候補
企業を絞り込みます。
④RFP(提案依頼書)の作成と配布・説明
調達を計画しているシステムや調達条件などを明示し、ベンダーに提案書の提出を依頼す
るためにRFP(Request For Proposal)、RFQ(Request For Quotation)を作成します。用意した
RFPやRFQを調達先候補となるベンダーに配布して説明します。
⑤提案書・見積書の作成
ベンダーではRFPの情報を基に、システムの構成・開発手法などを検討し提案書を作成し
ます。RFPに記載された作業範囲に必要な費用を計算した後、見積書を作成します。
⑥提案書・見積書の評価
候補ベンダーから提案された開発手法や機能作成に用いられる技術が適切であるかどうか
を確認します。また見積書から必要な作業項目が過不足なく含まれているか、見積金額は
妥当かなどを確認します。
⑦調達先の選定、調達リスク分析
選定基準に基づいて調達先のベンダーを選定します。
⑧契約締結
選定した調達先ベンダー企業と契約を交わします。金額や作業内容・納期だ
けでなく、守秘義務、完成したシステムの著作権などについても契約に含めておきます。
上記の通り、資源を調達するためには、調達計画を実施する必要があり、これらはシステム要求事項の策定〜契約締結までの各プロセスを通す必要があります。 またこれら調達の活動は、プロジェクト開始後も監視しながら随次実行する必要があり、資源不足によりプロジェクトが停滞しないよう気を付ける必要があります。
プロジェクトのコミュニケーション
プロジェクトにおけるコミュニケーションについて学習します。
プロジェクトのコミュニケーションは、プロジェクトを円滑に進めるための目的として、適切な情報共有を行うことが重要となります。
具体的にはプロジェクトメンバーが作業で必要な情報を入手するための手段でもあり、その情報を共有・発信することも想定できます。またこれらの情報を無くさないよう、サーバー上に保管したり、
必要な時に検索できるようにしたりすることもコミュニケーションの管理に含まれています。
コミュニケーション手段
ではどのようなコミュニケーション手段があるか見ていきましょう。
コミュニケーションにおける情報共有手段はいくつもの方法がありますが、プロジェクトマネジメントにおいては
「プッシュ型」と「プル型」に分けることができます。
イメージ図は以下の通りです。
プッシュ型は特定の受け手に限定して情報を送る1対1の伝達手段です。
例としては電子メールやFAXなどがあります。受け手の数が多いと、手間がかかるデメリットがあります。
プル型は受け手自身が情報の中から必要なものを選んで取り出す、1対多の伝達手段です。
送り手は情報を蓄積する場所に情報を置くだけなので対面での説明などの手間がかかりません。その反面受け手は自ら蓄積場所にアクセスしなければ情報が取れないデメリットがあります。
例としてはイントラネットサイトなどが挙げられ、ユーザーはサイトへアクセスし必要な情報を取得する必要があります。
これらのようにプッシュ型、プル型のメリット、デメリットを把握した上で臨機応変に活用していくことが大切です。
以上でプロジェクトマネジメントの学習は終了となります。続いて演習問題に移ります。
演習
本チャプターの演習を行います。
学んだことを思い出しながら解いてみましょう。
問1 プロジェクトの特性はどれか。
ア 独自性はあるが、有期性がない
イ 独自性はないが、有期性がある
ウ 独自性も有期性もある
エ 独自性も有期性もない
(出典：平成25年秋期 問51)
問2 プロジェクトマネジメントのプロセスのうち計画プロセスグループ内で実施するプロセスはどれか。
ア スコープの定義
イ ステークホルダの特性
ウ 品質保証の実施
エ プロジェクト憲章の作成
(出典：平成28年秋期 問51)
問3 プロジェクトに関わるステークホルダの説明のうち適切なものはどれか。
ア 組織の内部に属しており、組織の外部にいることはない
イ プロジェクトに直接参加し、間接的な関与にとどまることはない
ウ プロジェクトの成果が、自らの利益になる者と不利益になる者がいる
エ プロジェクトマネージャのように、個人として特定できることが必要である
(出典：平成27年春期 問52)
問4 図のようにプロジェクトチームが実行すべき作業を上位の階層から下位の階層へ段階的に分解したものを何と呼ぶか。
ア CPM
イ EVM
ウ PERT
エ WBS
(出典：平成26年春期 問52)
問5 システムを構成するプログラムの本数とプログラム1本当りのコーディング所要工数が表のとおりであるとき、システムを95日間で開発するには少なくとも何人の要員が必要か。ここで、システムの開発にはコーディングのほかに、設計及びテストの 作業が必要であり、それらの作業にはコーディング所要工数の8倍の工数が掛かるものとする。
| プログラムの本数 | プログラム1本当たりの コーディング所要工数(人日) |
|
|---|---|---|
| 入力処理 | 20 | 1 |
| 出力処理 | 10 | 3 |
| 計算処理 | 5 | 9 |
ア 8
イ 9
ウ 12
エ 13
(出典：平成31年春期 問54)
問6 図のプロジェクトの日程計画においてプロジェクトの所要日数は何日か。
ア 40
イ 45
ウ 50
エ 55
(出典：平成30年秋期 問52)
問7 ファンクションポイント法の説明はどれか。
ア 開発するプログラムごとのステップ数を積算し、開発規模を見積もる
イ 開発プロジェクトで必要な作業のWBSを作成し、各作業の工数を見積もる
ウ 外部入出力や内部論理ファイル、外部照会、外部インタフェースなどの個数や特性などから開発規模を見積もる
エ 過去の類似例を探し、その実績や開発するシステムとの差異などを分析・評価して開発規模を見積もる
(出典：平成25年秋期 問55)
問8 プロジェクトのリスクに対応する戦略として、損害発生時のリスクに備え、損害賠償保険に加入することにした。PMBOKに該当する戦略はどれか。
ア 回避
イ 軽減
ウ 受容
エ 転嫁
(出典：平成27年秋期 問54)
問9 プロジェクトで発生した課題の傾向を分析するために、ステークホルダ、コスト、スケジュール、品質などの管理項目別の課題件数を棒グラフとして件数が多い順に
並べこの順で累積した課題件数を折れ線グラフとして重ね合わせた図を作成した。
この図はどれか。
ア 管理図
イ 散布図
ウ 特性要因図
エ パレート図
(出典：平成29年秋期 問54)
問10 10人のメンバで構成されているプロジェクトチームにメンバ2人を増員する。次の条件でメンバ同士が打合せを行う場合、打合せの回数は何回増えるか。
〔条件〕
打合せは1対1で行う。
各メンバが、他の全てのメンバと1回ずつ打合せを行う。
ア 12
イ 21
ウ 22
エ 42
(出典：令和元年秋期 問54)
解説
問1 プロジェクトの特性はどれか。
[正解]
ウ
プロジェクトとは、特定の目的や(大きな)目標を達成するために実行される定常業務ではない一度限りの活動や計画をいいます。
またPMBOKの定義では「プロジェクトとは、独自の製品、サービス、所産を創造するために実施される有期性の業務である。」とされています。
したがってプロジェクトは独自性・有期性のどちらも有します。
問2 プロジェクトマネジメントのプロセスのうち，計画プロセスグループ内で実施するプロセスはどれか。
[正解]
ア
PMBOKではプロジェクトマネジメントのプロセスは、「立ち上げ」「計画」「実行」「監視・コントロール」「終結」の5つのプロセスグループで構成され、各プロセスは10つの知識エリア(サブジェクトグループ)※に分類されています。
・立ち上げ
プロジェクトを開始する必要性の明確化、および組織としてプロジェクトに着手することの宣言を行う。
・計画
要求を満足するための、実行可能な作業の仕組みを確立、およびその仕組みを維持する。
・実行
人及びその他資源を活用し、計画を実行する。
・監視、コントロール
進捗の監視・測定、および予定-実績の相違の検出し是正措置を実行する。
・終結
プロジェクトの結果の文書化、および顧客による検収の確認、プロジェクトの完了手続きを行う。
このうち計画プロセスグループには以下のプロセスが含まれています。
ア：正解。計画プロセスグループに含まれるプロセスです。
イ：立ち上げプロセスグループに含まれるプロセスです。
ウ：実行プロセスグループに含まれるプロセスです。
エ：立ち上げプロセスグループに含まれるプロセスです。
※統合、ステークホルダ、スコープ、資源、タイム、コスト、リスク、品質、調達、コミュニケーションの10つ
問3 プロジェクトに関わるステークホルダの説明のうち、適切なものはどれか。
[正解]
ウ
ステークホルダ(Stakeholder)は、日本語では利害関係者といい、プロジェクトメンバ、プロジェクトマネージャ、顧客、株主、経営者、地域などのように、プロジェクト活動によって利害が生じる可能性のある全ての者です。
そのプロジェクトに直接的にかかわる者だけではなく、間接的に影響を受ける可能性のある者も含まれます。
また、そのプロジェクトが利益になる者、損害になる者の両方が含まれます。
ア：組織外部の利害関係者もステークホルダに含まれます。
イ：ステークホルダには直接的にプロジェクトにかかわる者だけではなく、間接的な利害関係を有する存在も含まれます。
ウ：正解。ステークホルダには、そのプロジェクトが利益になる者、損害になる者の両方が含まれます。
エ：ステークホルダが企業や機関、地域社会などのように個人ではない場合もあります。
問4 図のようにプロジェクトチームが実行すべき作業を上位の階層から下位の階層へ段階的に分解したものを何と呼ぶか。
[正解]
エ
WBS(Work Breakdown Structure)は、プロジェクト目標を達成し、必要な成果物を過不足なく作成するために、プロジェクトチームが実行すべき作業を、成果物を主体に階層的に要素分解したものです。
作業の漏れや抜けを防ぎ、プロジェクトの範囲を明確にすると同時に、作業単位ごとに内容・日程・目標を設定することでコントロールをしやすくする目的があります。
ア：Critical Path Methodの略。クリティカルパスを求めることで、プロジェクト完了までの最短時間を決定したり、遅延が許されないタスクのつながりをはっきりさせることができます。
イ：Earned Value Managementの略。プロジェクトにおける作業を金銭の価値に置き換えて実績管理をする進捗管理手法です。
ウ：Program Evaluation and Review Techniqueの略。アローダイアグラムと同義で対象とするプロジェクトの完遂に必要なタスクを図法で分析する手法です。
エ：正解
システムを構成するプログラムの本数とプログラム1本当りのコーディング所要工数が表のとおりであるとき、システムを95日間で開発するには少なくとも何人の要員が必要か。
ここでシステムの開発にはコーディングのほかに設計及びテストの作業が必要であり、それらの作業にはコーディング所要工数の8倍の工数が掛かるものとする。
[正解]
イ
問題文に「コーディングのほかに、設計やテストの作業が必要であり、それらの作業の遂行にはコーディング所要工数の8倍の工数がかかる」という条件がありますので、実際の所要工数は
コーディングに要する工数＋その他の工数＝コーディングに要する工数＋(コーディングに要する工数×8)
となります。
つまり実際の所要工数は、プログラム1本当たり
入力処理 … 1＋1×8＝9人日
出力処理 … 3＋3×8＝27人日
計算処理 … 9＋9×8＝81人日
であることになります。
これをもとに総工数を求めると
(20×9)＋(10×27)＋(5×81)＝855人日
総工数を95日で割ると、
855人日÷95＝9人
よって、システムを95日間で開発するには少なくとも「9人」の要員が必要となります。
問6 図のプロジェクトの日程計画においてプロジェクトの所要日数は何日か。
[正解]
エ
アローダイアグラムのクリティカルパスを求める超定番問題です。
解き方を覚えるまでは難しく感じますが、一度わかるようになると簡単に解けるようになりますのでマスターしておきましょう。
まずダミー作業も含め、通り得るすべての経路の組合せを考えます。
A→C→E→H
A→D→(上のダミー)→E→H
A→D→F→H
A→(下のダミー)→G→H
B→G→H
この全てについて所要日数を求め、最も長くなる経路がクリティカルパスになります。
※ダミー作業は日数ゼロで計算します。
A→C→E→H
10＋10＋20＋10＝50(日)
A→D→(上のダミー)→E→H
10＋15＋0＋20＋10＝55(日)
A→D→F→H
10＋15＋15＋10＝50(日)
A→(下のダミー)→G→H
10＋0＋25＋10＝45(日)
B→G→H
5＋25＋10＝40(日)
以上より、クリティカルパスは「A→D→(上のダミー)→E→H」、その所要日数は55日とわかります。
したがって「エ」が正解です。
問7 ファンクションポイント法の説明はどれか。
[正解]
ウ
ファンクションポイント法は、ソフトウェアに含まれる機能とその複雑さを基準に論理的に開発工数を見積もる方法です。
ここでいうシステムの機能とは、外部入出力、ファイル、外部インターフェイスなどのことで、これらの数と複雑さ・難度などの因子をもとにファンクションポイント数を算出し、それを基にして開発工数を見積ります。
ア：プログラムステップ法の説明です。
イ：標準タスク法の説明です。
ウ：正解。ファンクションポイント法の説明です。
エ：類推見積法の説明です。
問8 プロジェクトのリスクに対応する戦略として、損害発生時のリスクに備え、損害賠償保険に加入することにした。
PMBOKによれば該当する戦略はどれか。
[正解]
エ
PMBOKにおいて、プロジェクトにマイナスの影響を与えるリスク(脅威)への対応戦略には「回避」「転嫁」「軽減」「受容」があります。
・回避
リスクそのものを取り除いたり、プロジェクトに影響がないようにスコープや目標を縮
小・変更したりする戦略。
・転嫁
リスクによるマイナスの影響を第三者へ移転する戦略。リスクのある業務・作業の
アウトソーシングや、損害保険契約によってリスクの影響を自社から他社に移転する。
・軽減
リスクの影響範囲を狭くしたり、発生確率を低減したりするような戦略。
・受容
リスクが現実化した時の影響が許容可能範囲内である時やリスクの除去が困難である場合
に、特段対策をせずにそのままにしておく戦略。
損害保険をかけることは、金銭的リスクを他社に移転することになるため「転嫁(てんか)」の戦略に該当します。
問9 品質問題を解決するために図を作成して原因の傾向を分析したところ、全体の80%以上が少数の原因で占められていることが判明した。
作成した図はどれか。
[正解]
エ
パレート図は値の大きい順に分析対象の項目を並べた棒グラフと、累積構成比を表す折れ線グラフを組み合わせた複合グラフで、主に複数の分析対象の中から重要である要素を識別するために使用します。
ア：工程の状態や品質を時系列に表した図であり、工程が安定した状態にあるかどうかを判断するために使用します。
イ：二つの特性を横軸と縦軸にとり測定値を打点した図であり、それらの相関を判断するために使用します。
ウ：矢印付き大枝の先端に特性を中枝、小枝に要員を表した図であり、要因同士の因果関係を分析するために使用します。
エ：正解
問10 10人のメンバで構成されているプロジェクトチームにメンバ2人を増員する。次の条件でメンバ同士が打合せを行う場合、打合せの回数は何回増えるか。
[正解]
イ
メンバが増えるのに伴って打合せの回数は次のように増えていきます。
この図を見てわかるように打合せの回数はメンバ同士を結ぶ線の数と同数になります。
よって、N人のメンバが、それぞれ他のすべてのメンバと1対1で1回ずつ打合せを行う必要があるとき、その打合せの数はN人から2人を選ぶ組合せ数を計算することで求められます。
組合せ数は以下の公式を用いて計算します。
【n個のものからr個を選ぶ組合せ数】
nCr＝n!(n－r)!r!
[10人から2人を選ぶ組合せ数]
10C2＝10×92×1＝45通り
[12人から2人を選ぶ組合せ数]
12C2＝12×112×1＝66通り
[2人増員により増える打合せ回数]
66回－45回＝21回
したがって「イ」が正解です。
Lesson 3
Chapter 2
サービスマネジメント
Chapter1ではシステム開発を円滑に進めるために必要なプロジェクトマネジメントついて学習しました。
Chapter2ではITサービス利用者へのサポートや維持管理などを行う、サービスマネジメントについて学習します。
サービスマネジメント
はじめに主題であるサービスマネジメントについて学習しましょう。
「サービスマネジメント」は、顧客へ提供したITサービスの運用及び保守作業を「独立したITサービス」として捉え、これら各業務を効率的に運営していく仕組みです。
例としては顧客に提供した人事管理システムのアップデートやサポート業務などが挙げられ、これらを効率的に運営・管理していく必要があります。
これらサービスマネジメントの実施においてはガイドラインが規定されており、「ITIL」が例として挙げられます。
ITIL(Information Technology Infrastructure Library)
ITサービスを運用管理するためのベストプラクティス(最高の実践方法)を集め、 ITサービスのフレームワーク(枠組み)を示したライブラリです。
ITIL(Information Technology Infrastructure Library)
ガイドラインであるITILは「サービスサポート」と「サービスデリバリ」の2つによって構成されています。
サービスサポートとはシステムの運用上、「日々発生」するユーザーからの問い合わせやシステム障害などの問題を素早く対処することを目的としたものです。
サービスデリバリは一貫したサービスを「中長期」にわたって提供することを目的としたものとなります。
基本的にITシステムの運営においてはユーザーからの問い合わせやシステム障害などがあった際は迅速な対応が必要となります。しかしながら対応が一時的な処置となる場合かえって
根本原因が曖昧なままとなり、再度問題が発生する可能性もあります。従って問題や作業内容によって適切にサポートのプロセスを組み立て実行する必要があります。
では具体的にどのようなプロセスがあるか見ていきましょう。
ここではサービスサポート及びサービスデリバリの各プロセスについて紹介します。
各プロセスの詳細な説明は「サービスマネジメントシステムの計画及び運用」にて行います。
・サービスサポート
①インシデント管理
②問題管理
③変更管理
④リソース管理
⑤構成管理
・サービスデリバリ
①サービスレベル管理
②キャパシティ管理
③可用性管理
④ITサービス継続性管理
⑤ITサービス財務管理
上記の通り、サービスサポートは日々発生するユーザーからの問い合わせや問題に関連するプロセスを含み、サービスデリバリは中長期的なITサービスの提供や運用に関連するプロセスを含みます。
またサービスデリバリにおけるITサービスの提供・運営は高品質を目指すほど多額の費用が必要なため、費用と品質のバランスを考慮しながら運用することが重要となります。
SLA(Service Level Adreement)
これらITサービスの運用において、ITILではサービス提供者とサービス委託者との間で合意に基づくサービスを明確にした「SLA(Service Level Adreement：サービスレベル合意書)」の締結が求められています。
SLAはサービス時間・可用性・信頼性の目標値、応答時間などのサービスレベルを数値によって定量的に明示し、
サービスレベルを達成できなかった場合のルールも定めておく必要があります。
では具体的にどのような項目があるか見ていきましょう。
SLAに含まれる項目は下記の通りです。
・サービス提供の曜日・時間帯
・サービスデスクが提供するサービスの内容
・障害発生時の解決に要する時間の目標値
・目標とするサービスの稼働率
・システム処理に要する時間や応答に要する時間の目標値
上記の通り、項目を定量的に管理することでサービスレベルの向上に繋がり、ITサービスを効率よく運用することができます。
SLM(Service Level Management)
SLA(サービスレベル合意書)の品質基準を実現・維持するために、必要なプロセスを構築・管理すること。
サービスマネジメントシステムの計画及び運用
ここではITサービスを効率的に運用・管理していく活動、「サービスマネジメントシステム(SMS)」について学習します。
SMSは企業が個々に形成していくシステムであり、計画・確立・導入・運用・監視・レビュー・維持および改善のプロセスを実施することで成り立っています。
またSMSとそれに基づくサービスを提供する際、常に改善プロセスなどの見直しが必要になるため、プロジェクトマネジメントで学習したPDCAサイクルの考え方が適用できます。
では具体的にSMSにおけるプロセスを見ていきましょう。
SMSにおける各プロセスの説明は以下の通りです。
・サービスマネジメントシステムの計画と支援
サービスマネジメントシステムを運用するに当たり、必要なプロセスを計画する。
また要求事項に基づいたパフォーマンス基準を設定し、それに従ったプロセスの計画・管
理を実施する。
・サービスの計画
サービスの要求事項を決定し、文書化する。
また要求事項に変更があった場合はサービス変更の提案を行う。
・サービスカタログ管理
顧客に提供するサービスを文書化し、適切な情報を提供する。
・資産管理
サービス提供の為の資産を管理する。
・構成管理
ITサービスを構成するハード、ソフト、ドキュメントなどの構成品目に対し、正確な構成
情報やバージョンを記録し管理する。
・事業関係管理
サービスを提供する組織や顧客や利害関係者との間に良好な関係を確立するため必要な取
り決めを行う。
・サービスレベル管理
ITサービスレベル合意書(SLA)を作成、締結、その内容を実現し、維持・改善するための活
動を行う。
・供給者管理
外部供給者を用いる場合の管理活動を行う。
・サービスの予算業務及び会計業務
ITサービスに関わる予算業務と会計業務を行う。
・需要管理
サービスに対する需要と消費を監視・報告し将来の需要を予測する。
・容量・能力管理
人、技術、情報及び財務に関する資源の容量・能力の要求事項をサービス及びパフォーマ
ンスの要求事項を考慮して決定、維持を行います。
・変更管理
サービスの変更要求を分類し管理する。
・サービスの設計および移行
新サービスやサービス変更について、計画、設計を行い文書化する。
・リリースおよび展開管理
新規および変更管理で試験されたサービスなどを、実際の稼働環境で使える状態にする。
・インシデント管理
障害などの予期せぬサービスの中断に際して、可能な限り迅速に回復させるための対応を
行う。
・サービス要求管理
サービス要求に対し、記録・分類を行い、優先順位や緊急度を含む定められた手順に従っ
て実現する。
・問題管理
問題の根本原因を突き止め、インシデントの発生または再発防止への解決策を決定する。
・サービス可用性管理
利用者が確実にサービスを利用できるよう監視・記録を行い、あらかじめ定めた要求事項
及び目標との比較を行う。
・サービス継続管理
顧客と合意したサービス継続に基づいて、サービス継続計画を作成し、実施・維持を行
う。
・情報セキュリティ管理
情報資産の機密性、完全性、アクセス性を保つため、情報セキュリティ方針、情報セキュ
リティ管理策を作成し、情報セキュリティインシデントに関する事項を実施する。
上記各プロセスはそれぞれ密接に関わっており、統合的にプロセスを見直し考える必要があります。
例えばインシデント管理はITサービスのレベルが低下した場合に、原因追及は後回しにして、迅速に回復するための管理を行います。
実際にパソコンのリセットボタンを押して再起動することで正常に動作すればインシデント管理は完了です。
しかし、原因を追及して取り除かなければ再度問題が発生する恐れがある為、問題管理が重要になります。
これらのように、サービスにおける1つのプロセスだけ注視するのではなく全体を把握した上で、サービスをマネジメントすることが重要になります。
インシデント
「サービスの低下を招く出来事」という意味。システム障害などが含まれる。
パフォーマンス評価および改善
続いてパフォーマンス評価および改善について学習します。
ITサービスを運用する上で、要求に対し正しい動作を実現するのは必然ですが、そんな期待動作を定量的に監視、測定する活動を「パフォーマンス評価」と呼びます。
また「パフォーマンス評価」では監視および測定が必要な対象を決めたうえで、実際にパフォーマンスを測定し、
サービス要求事項と比較して有効性を評価します。
例としてはITサービスの通信速度・システム速度や停止率・安定率などが挙げられます。
そして運用後も取り決めた間隔で内部監査およびトップマネジメントによるマネジメントレビューを行います。
マネジメントレビュー
マネジメントレビューとは組織のサービスマネジメントシステムおよびサービスが適切、妥当かつ有効であるかどうかを確認するレビューです。
マネジメントレビューで受けた指摘や問題を除去することで、全体としてのパフォーマンスが上がり、サービス品質向上につなげることができます。
サービスの運用
「サービスの運用」はITサービスの運用において必要な活動を示します。
具体的には資源管理、運用計画の策定、スケジューリング、運用オペレーション、バックアップ、利用者からの問い合わせ窓口となるサービスデスクの提供など、様々な管理項目が含まれます。
また運用計画や障害発生時の運用を適切に行うための計画、運用負荷低減のための改善計画をそれぞれ作成する活動も含まれます。
運用オペレーション
そしてサービスの運用においてはシステムを安定的に稼働させることが最重要となります。
システムを安定的に稼働させるためには、手順に従って監査、操作、状況連絡を行うことが重要であり、これらを「運用オペレーション」といいます。
では運用オペレーションとは具体的にどういったものなのか見ていきましょう。
以下に運用オペレーションに含まれるプロセスを紹介します。
①スケジュール設計
システムを安定稼働させるための、運用設計・スケジュールを立案します。
②障害時運用設計
データの回復など、障害時の運用方式に関係する設計を行います。
③システム監視
システムの稼働状況やセキュリティ監視を行います。主に以下の2つの運用支援ツールを
使用します。
・監視ツール
システムの運用や情報セキュリティ状況を監視し、異常を発見してレポートするツール
です。監視対象はアプリケーションやOSの稼働状況、CPUやメモリの使用率などが該当
します。
・診断ツール
監視ツールからの情報や運用状況などを統合し、サービスマネジメントとしての意思決
定支援を行うためのツールです。SLAで合意したサービスレベル達成状況を数値として
把握することができます。
④バックアップ
障害時の復旧や再実行に備えて、運用スケジュールに基づいた計画的なバックアップを実
施します。
上記の通り、運用オペレーションでは実際の運用を想定し事前準備することが重要となります。特にデータのバックアップなどは バックアップ元データと同一媒体に置かないようにするなど、分散的に管理することで紛失などのリスクを減らすことができます。
サービスデスク
続いてサービス運用に関連し、その中の1つである「サービスデスク」について説明します。
サービスデスクはシステムの利用者に向けた運用サービスとなり、具体的には利用者からの問合せに対する窓口機能を提供し、適切な部署への引継ぎ、対応結果の記録、管理などを行います。
サービスデスクは以下のような形態があります。
| 形態 | 内容 | 特徴 |
|---|---|---|
| 中央 サービスデスク |
すべての利用者から問合せを受ける、単一の窓口を設ける。 | サービス要員を効率的に配置したり、大量コールに対応することが可能。 |
| ローカル サービスデスク |
利用者に近い拠点(国または地域)ごとに窓口を設ける。 | 言語や文化の異なる利用者への対応、専用要員によるVIP対応などが可能。 |
| バーチャル サービスデスク |
いくつかのサービスデスクをネットワークなどで結び、単一の窓口として機能させる。 | 実際のサービス要員は複数の地域や部門に分散させるが、通信技術に利用で単一のサービスデスクであるかのようにサービスを提供可能。 |
| フォロー・ザ・サン | 分散拠点のサービス要員を含めた全員を中央で統括して管理し、統制のとれたサービスを提供する。 | 世界レベルの地理的に分散した、2つ以上のサービス拠点を結び、24時間途切れないサービスが可能。 |
これらのようにサービスデスクは様々な形態があり、拠点を分散させ通信技術で窓口を単一に見せたりなど、サービスの運用方法によって手法を検討する必要があります。
ファシリティマネジメント
建物・設備が最適な状態となるように、監視・改善する管理活動である「ファシリティマネジメント」について学習します。
まずはファシリティマネジメントのイメージをつけてもらうために活動例を紹介します。活動例は以下の通りです。
・建物に免震装置を備える
・防災防犯設備を整える
・危機の冷却用の通路(コールドアイル)や廃熱用通路(ホットアイル)により故障率を下げる
・停電に備えて「UPS」や「自家発電設備」を備える
・通信設備を整える
これらの活動例の通りファイシリティマネジメントは万が一に備え、設備などを事前に最適な状態へ整える活動となります。
また設備の定期的な監視・メンテナンスも重要であり、これらを行うことで問題を事前に発見し潰すことができます。
続いて停電や瞬断の際に重要となる「UPS」について紹介します。
UPS(Uninterruptible Power Supply)
UPS(Uninterruptible Power Supply)は内部にバッテリを備えた装置であり、停電や瞬断などに備えた予備装置となります。
万が一停電が起きた場合でも10数分間程度の電源が供給されるため、システムを安全に停止させることが可能です。
また災害時等より電力会社からの供給が途絶えた時に、エンジンやタービンを使って発電する設備「自家発電設備」も重要になります。
数十分～数日にわたる発電が可能ですが、供給はすぐに開始できないためUPSなどと組み合わせて利用する必要があります。
通信設備
加えてシステムやITサービスにおいては「通信設備」についても考慮する必要があります。
通信設備の管理としては、ビルやマンションなどには複数の通信回線を収容するMDF(Main Distribution Frame：主配線盤)を設けることで通信配線を一元管理できます。そのほか各階ごとに
IDF(Intermediate Distribution Frame：中間配線盤)を置くことが設備を整える上で重要となります。
これらの通り、事前に設備を整えることは作業や環境上の改善につながるだけでなく問題が起きた際の原因が切り分けやすくなるため、常に改善意識を持って環境整備に取り組むことが重要となります。
以上でサービスマネジメントの学習は終了となります。続いて演習問題に移ります。
演習
本チャプターの演習を行います。
学んだことを思い出しながら解いてみましょう。
問1 次の条件でITサービスを提供している。SLAを満たすための、1か月のサービス時間帯中の停止時間は最大何時間か。ここで、1か月の営業日は30日とし、サービス時間帯中は保守などのサービス計画停止は行わないものとする。
[SLAの条件]
サービス時間帯は、営業日の午前8時から午後10時までとする。
可用性を99.5%以上とする。
ア 0.3
イ 2.1
ウ 3.0
エ 3.6
(出典：平成26年春期 問57)
問2 ITサービスマネジメントの管理プロセスはどれか。
ア サービスレベル管理
イ 品質管理
ウ スケジュール管理
エ リスク管理
(出典：平成24年春期 問55)
問3 ITサービスマネジメントのキャパシティ管理プロセスにおける、オンラインシステムの容量・能力の利用の監視についての注意事項のうち、適切なものはどれか
ア 応答時間やCPU使用率などの複数の測定項目を定常的に監視する
イ オンライン時間帯に性能を測定することはサービスレベルの低下につながるので、測定はオフライン時間帯に行う
ウ キャパシティ及びパフォーマンスに関するインシデントを記録する
エ 性能データのうちの一定期間内の最大値だけに着目し、管理の限界を逸脱しているかどうかを確認する
(出典：平成28年春期 問57)
問4 サービスデスク組織の構造とその特徴のうち、ローカルサービスデスクのものはどれか。
ア サービスデスクを1拠点又は少数の場所に集中することによって、サービス要員を効率的に配置したり、大量のコールに対応したりすることができる
イ サービスデスクを利用者の近くに配置することによって、言語や文化の異なる利用者への対応、専用要員によるVIP対応などができる
ウ サービス要員が複数の地域や部門に分散していても、通信技術を利用によって単一のサービスデスクであるかのようにサービスが提供できる
エ 分散拠点のサービス要員を含めた全員を中央で統括して管理することによって、統制の取れたサービスが提供できる
(出典：平成30年春期 問56)
問5 落雷によって発生する過電圧の被害から情報システムを守るための手段として、有効なものはどれか。
サージ保護デバイス(SPD)を介して通信ケーブルとコンピュータを接続する
イ 自家発電装置を設置する
ウ 通信線を経路の異なる2系統とする
エ 電源設備の制御回路をディジタル化する
(出典：平成29年秋期 問57)
解説
問1 次の条件でITサービスを提供している。SLAを満たすための、1か月のサービス時間帯中の停止時間は最大何時間か。ここで、1か月の営業日は30日とし、サービス時間帯中は保守などのサービス計画停止は行わないものとする。
[正解]
イ
サービス時間帯は営業日の午前8時から午後10時(22時)までなので、1日あたりのサービス提供時間は14時間ということになります。
1カ月の営業日数は30日なので、1カ月間の合計では、
14時間×30日＝420時間
のサービス提供時間になります。
要求されている可用性が99.5%以上なので、停止許容時間を全サービス提供時間中の0.5%以下にとどめなくてはなりません。許容できる停止時間は、全サービス提供時間に0.5％を乗じて、
420時間×0.005＝2.1時間
と計算できます。よって「イ」が適切です。
問2 ITサービスマネジメントの管理プロセスはどれか。
[正解]
ア
サービスレベル管理とは、サービス提供者と利用顧客の間で合意したサービスレベルを維持管理していくためのプロセスです。安定したITサービスを提供するためにSLAやSLMを実施し、それらの運用状況を管理する役割をもっています。
・SLA(Service Level Agreement)
提供者と顧客の間でサービスの品質に関して結ぶ契約のことで、サービスの品目と水準、および水準を達成できなかった場合のペナルティ事項などが盛り込まれる。
・SLM(Service Level Management)
サービスレベル合意書に基づき、顧客要件を満たすITサービスの提供を実現し、その品質の継続的な改善に必要なプロセスを構築するという管理手法や考え方。
問3 ITサービスマネジメントのキャパシティ管理プロセスにおける、オンラインシステムの容量・能力の利用の監視についての注意事項のうち、適切なものはどれか
[正解]
ア
ア：正解。応答時間、CPU使用率、メモリ使用量、ストレージ容量、ネットワークトラフィック量などを常時監視します。
イ：実際の使用状況を収集、記録、分析しなければなりませんので、サービス提供時間帯を含めて継続的に測定を行います。
ウ：容量・能力管理で記録の対象となるのは、インシデントではなく個々のサービスのパフォーマンスや資源の利用状況です。
エ：短期／中期／長期にわたってデータの最小値、最大値、平均値に注意する必要があります。
問4 サービスデスク組織の構造とその特徴のうち、ローカルサービスデスクのものはどれか。
[正解]
イ
ア：中央サービスデスクの説明です。
イ：正解
ウ：バーチャルサービスデスクの説明です。
エ：フォロー･ザ･サンの説明です。
問5 落雷によって発生する過電圧の被害から情報システムを守るための手段として、有効なものはどれか。
[正解]
ア
施設の近くで落雷があると瞬間的に高い電圧(サージ)が発生します。この大きな電流が電話回線や電線を通じてシステムに侵入すると、コンピュータが壊れてしまう恐れがあります。この過電圧の被害から機器を防御するのが、SPD(Surge Protective Device サージ防護機器)やOAタップなどに装備されているサージプロテクト機能です。
ア：正解
イ：自家発電装置は停電時の補助電源として効果を発揮しますが、落雷による過電圧からコンピュータを守ることはできません。
ウ：2系統の両方に大きな電流が流れるため、落雷には効果がありません。
エ：落雷には効果がありません。
システム監査
ここからは情報システムに関する様々なリスクについて、第三者の目から見るシステム監査について学習します。
「システム監査」は情報システムのリスクに対して適切に対処しているかどうかを、システム監査人が点検・評価・検証することを示します。 また監査を通じて、組織の経営活動や営業活動の効果的かつ効率的な遂行を支援し、目標達成に寄与すること、また利害関係者に対する説明責任を果たすことを目的とします。
システム監査における監査人は客観的に評価する者としての立場が必須であると共に以下の要素が必要になります。
・独立性
常に公正で客観的な監査判断を行える「精神上の独立性」と監査対象と利害関係であって
はならない「外観上の独立性」の2つを兼ね備えていること。
・適格性
監査対象の専門職としての知識や技能を保有していたり、コミュニケーション能力や文章
作成能力が長けていること。
・倫理観と誠実性
模範となる倫理観や誠実性を兼ね備えていること。
上記の通り、監査人は監査対象となるシステムとは利害関係があってはならないため、開発や運用に関わっているメンバなどは監査人になることはできません。また監査人は「守秘義務」を負っており、監査で得た情報を外部に漏らしてはなりません。
監査に当たっては「監査証拠」に基づき、公正かつ客観的に監査判断を行う必要があります。
システム監査の対象となるのは情報システムの企画・開発・運用・保守というシステムのライフサイクル全般になります。 これらのシステムは監査を円滑に進める為にも監査対象であることを前提に構築・設備する必要があります。 これを「可監査性」といいます。
では実際にどのように監査が行われるのか確認しましょう。
流れは以下の通りです。
①監査計画
監査手続きの種類、適用する範囲、実施時期など、監査計画を策定する。
②予備調査
監査対象の概要把握のため、資料を集めやアンケート調査などを実施する。
③本調査
関連文書や聞き取り調査などで、監査の結論を裏付けるために十分かつ適切な監査証拠を
入手する。
④監査調書の作成と保管
監査のプロセスを監査調書として記録する。
⑤監査の結論と監査報告書の作成
合理的な根拠に基づき、結論をまとめ、監査報告書としてまとめる。
⑥監査の報告
監査依頼者に対して監査報告を行う。
⑦改善提案のフォローアップ
改善提案を残した場合、改善計画および実施状況に関する情報を収集し、改善状況のモニ
タリングを行う。
上記の通りシステム監査は、計画から始まり、調査などを経て、監査報告書の作成、監査報告を行う流れとなります。
これらの活動を行うことで利害関係者に対する説明責任を果たすことができ、また改善提案のフォローアップを行うことで企業の目標達成に寄与することができます。
内部統制
前述のシステム監査では情報システムを対象とした取り組みでしたが、ここからより上位の企業・組織を対象とした内部統制について学習します。
「内部統制」とは企業内部で不正や違法行為などが行われることなく、健全で効率的な組織運営のための体制を企業自身が構築し、運用する仕組みです。
また企業の経営者はこれらの仕組みを整備・運用する最終責任を負っています。
では企業がどのように内部統制を実現するのか確認していきましょう。
内部統制を実現するためには、「コーポレートガバナンス(企業統治)」の体制構築、「コンプライアンス(法令遵守)」の徹底、リスク管理、社員教育を行うなどが必要となります。
上記コーポレートガバナンスの具体的な取り組みとしては、取締役と執行役の分離、社外取締役の設置、社内ルールの明確化などが挙げられます。またコンプライアンスの徹底については
定期的な落とし込み、社員教育などを行うことで意識を徹底させることができます。
またこれらの中でも特に必要とされる項目は次の通りです。
| 項目 | 説明 |
|---|---|
| 業務プロセスの明確化(可視化) | 業務プロセスをフローチャートなどで表す。業務プロセスが可視化されることでリスクを分析したり改善を行うことができる。 |
| 職務分掌の見直し | 1つの部門や社員が、ある業務の全プロセスを行うことが内容に権限を複数の部門や複数の社員に分離する。 |
| 実施ルールの制定 | 業務プロセスごとに実施ルールを制定する |
| チェック体制の確立 | 内部統制の有効性や効率性を継続的に評価するため、定期的に監査を行いモニタリングしていく。 |
| ITガバナンスの確立 | 情報システム戦略を策定し実行する組織体制を作る。 |
上記の通り内部統制の実現においてはルールを徹底すると共に、それぞれの要素を明確にし管理することが重要になります。
ITガバナンス
企業などが競争力を高めるために、情報システム戦略を策定し、戦略実行を統制する仕組みを確立する為の取り組み
コンプライアンス
法律や規則などの基本的なルールに従って行動すること
以上でシステム監査の学習は終了となります。続いて演習問題に移ります。
演習
本チャプターの演習を行います。
学んだことを思い出しながら解いてみましょう。
問1 情報システム部が開発して経理部が運用している会計システムの運用状況を、経営者からの指示で監査することになった。この場合におけるシステム監査人についての記述のうち、最も適切なものはどれか。
ア 会計システムは企業会計に関する各種基準に準拠すべきなので、システム監査人を公認会計士とする
イ 会計システムは機密性の高い情報を扱うので、システム監査人は経理部長直属とする
ウ システム監査を効率的に行うために、システム監査人は情報システム部長直属とする
エ 独立性を担保するために、システム監査人は情報システム部にも経理部にも所属しない者とする
(出典：令和元年秋期 問59)
問2 我が国の証券取引所に上場している企業において、内部統制の整備及び運用に最終的な責任を負っている者は誰か。
ア 株主
イ 監査役
ウ 業務担当者
エ 経営者
(出典：平成30年秋期 問60)
解説
問1 情報システム部が開発して経理部が運用している会計システムの運用状況を、経営者からの指示で監査することになった。この場合におけるシステム監査人についての記述のうち、最も適切なものはどれか。
[正解]
エ
ア：会計監査ではなく、会計システムの運用状況の監査なので公認会計士とする必要はありません。
イ：経理部長の直属では、経理部が運用しているシステムの監査を公平に行うことができない可能性があります。監査人は客観的な評価者としての立場を堅持しなくてはならないため不適切です。
ウ：情報システム部長の直属では、情報システム部が開発したシステムの監査を公平に行うことができない可能性があります。監査人は監査対象部門から独立していなればなりません。
エ：正解。システム監査人には、監査対象部門と身分的及び精神的に利害関係がない者を任命し、客観的な視点から公平・公正な判断を行えるようにしなくてはなりません。
問2 我が国の証券取引所に上場している企業において、内部統制の整備及び運用に最終的な責任を負っている者は誰か。
[正解]
エ
企業会計審議会"財務報告に係る内部統制の評価及び監査の基準"における内部統制の定義には「内部統制の目的を達成するため、経営者は、内部統制の基本的要素が組み込まれたプロセスを整備し、そのプロセスを適切に運用していく必要がある。」と明記されているため、整備・運用の責任者は経営者が適切です。
以上で、Lesson3の学習は終わりです。
お疲れ様でした。
