プロジェクト・サービスマネジメント

基本の仕組み

Aが2日、Aの後にBが3日とCが5日、両方の完了後にDが1日なら、全体は2＋5＋1＝8日です。Bを1日短縮しても全体の8日は変わりません。

WBSで成果物を作業へ分解し、依存関係を結んだ最長経路をクリティカルパスとして見ます。並行できる作業を単純に全部足さないのがポイントです。

期間短縮は品質や費用に影響することがあります。担当を増やせばいつでも比例して早く終わるわけではなく、分担や調整の時間も生まれます。

プロジェクトのリスクは、発生確率と起きた場合の影響を見て優先順位を付けます。事前に避ける、影響を減らす、保険等で移転（転嫁）する、対応費用との比較で受容するなどの判断をします。追加機能を無審査で受け入れると、当初の費用や納期の前提が崩れるため、変更の影響を合意します。

余裕日数と日程短縮

各作業について、前から積み上げた最早開始日と、全体の完了日から逆算した最遅開始日を求め、その差を余裕日数とします。余裕が0の作業を結んだ経路がクリティカルパスです。例では、Bは2日目の終了後に始められ、Dの開始（7日目の終了後）から逆算すると4日目の終了後までに始めればよいので、2日の余裕があります。

日程を短縮する方法には、クリティカルパス上の作業に要員などの資源を追加するクラッシング（費用が増える）と、本来は順番に行う作業を一部並行させるファストトラッキング（手戻りのリスクが増える）があります。クリティカルパス以外の作業を短縮しても全体は縮みません。

短縮すると、別の経路が新しいクリティカルパスになることがあります。例でCを5日から2日に縮めると、A→C→Dは5日になり、A→B→Dの6日が最長になるため、全体は6日です。

EVMで進捗とコストを測る

EVM（アーンドバリューマネジメント）は、進捗と費用を同じ金額の尺度で比べる方法です。PV（計画価値）は現時点までに終える予定だった作業の予算、EV（出来高、アーンドバリュー）は実際に終えた作業の予算、AC（実コスト）は実際に使った費用です。

スケジュール差異SV＝EV−PV、コスト差異CV＝EV−ACで、負ならそれぞれ遅れ・超過です。比率で見るときは、SPI＝EV÷PV、CPI＝EV÷ACが1未満なら遅れ・超過です。例えばPV100万円、EV80万円、AC90万円なら、SV＝−20万円、CV＝−10万円で、遅れと予算超過が同時に起きています。

完成時の総予算（BAC）をCPIで割ると、現在のコスト効率が続いた場合の完成時総コストの見積り（EAC）になります。EVだけ、ACだけを見ても判断できず、必ず比べる相手を確認します。

見積り手法

ファンクションポイント法は、外部入力・外部出力・外部照会・内部論理ファイル・外部インタフェースファイルの数を、それぞれの複雑さで重み付けして合計し、ソフトウェアの規模を求めます。利用者から見える機能を数えるため、開発言語に依存せず、要件が固まった早い段階から使えます。

ほかに、過去の似たプロジェクトを基にする類推見積り、WBSの作業ごとに見積もって積み上げるボトムアップ見積り、規模などの変数と統計的な式から求めるパラメトリック見積り（COCOMOなど）、ソースコードの行数を基にするLOC法があります。三点見積り（PERT）では、期待値を（楽観値＋4×最可能値＋悲観値）÷6で求めます。

リスク対応と変更管理

マイナスのリスクへの対応は、回避・転嫁（移転）・軽減・受容に分けられます。不慣れな技術を使わない設計へ変えるのが回避、保険や契約で損失の負担を他者へ移すのが転嫁、試作で問題を早めに見つけて影響を小さくするのが軽減、影響が小さいものを予備費などで受け止めるのが受容です。

進捗の遅れや追加要求による変更は、スコープ・スケジュール・費用・品質への影響を評価し、決められた承認者（変更管理委員会など）の承認を得てから計画に反映します。承認前に作業を進めると、費用や納期の前提が崩れたまま管理できなくなります。

基本の仕組み

予備機へ切り替えてサービスを復旧するのがインシデント管理の例です。繰り返す停止の根本原因を調べ、恒久対策を行う活動は問題管理として考えます。

SLAはサービス提供者と顧客の間で合意する、サービスの内容と品質目標の文書です。目標復旧時間などを定め、実績を測ることで、期待と実際のずれを把握します。

復旧と原因解決は同じではありません。暫定対応で動いていても再発のおそれは残るため、変更を管理しながら恒久対策を進めます。

事業継続計画では、止められない業務を選び、許容する停止時間や失ってよいデータ量から復旧を設計します。RTOは復旧までの目標時間、RPOはどの時点のデータまで戻せるようにするかの目標です。前日夜のバックアップだけなら、当日昼の障害で午前中の更新を失う場合があります。

復旧と再発防止

インシデントは、サービスの計画外の中断や品質の低下のことです。インシデント管理では、回避策（ワークアラウンド）も使って、合意した時間内にサービスを回復させることを優先します。根本原因は分かっているが恒久対策がまだの状態は「既知の誤り」として記録し、問題管理で再発防止を進めます。

恒久対策としてシステムを直すときは、変更管理で変更要求（RFC）の影響とリスクを評価して承認し、リリース及び展開管理で本番環境へ展開します。構成管理は、どの機器やソフトウェアがどの版で動いているかを記録し、影響範囲の特定を支えます。利用者からの問合せは、単一の窓口であるサービスデスクが受け付けます。

SLAと可用性の計算

SLA（サービスレベル合意書）には、サービス時間、可用性、応答時間、障害時の回復時間などの目標（サービスレベル目標）を数値で定めます。サービスレベル管理では、実績を定期的に測って目標と比べ、顧客とレビューします。

可用性は、サービスを提供する時間のうち実際に利用できた時間の割合です。例えば毎日8時から20時まで（12時間）、月30日提供するサービスで可用性99%を約束すると、月の提供時間360時間の1%、つまり3.6時間まで停止が許されます。計画停止を提供時間に含めるかどうかは、SLAの定義で決まります。

基本の仕組み

入力者と承認者を分け、変更履歴を残せば、誤入力を発見したり後から経緯を確認したりできます。監査人は、その仕組みが設計どおり動いているか証拠を集めます。

システム監査では、監査対象から独立した立場で評価し、改善につながる指摘を行います。実際の改善を決め実施する責任は、対象の経営者や管理者にあります。

監査人が対象業務を自ら運用し、その成果を自分で監査すると独立性が損なわれます。監査があるだけで全ての不正を防げるとも限りません。

監査と運用責任

経済産業省のシステム監査基準では、システム監査人が独立かつ客観的な立場で、監査証拠に基づいて情報システムを検証・評価し、保証や助言を行うとしています。監査対象の業務から離れた立場にあること（外観上の独立性）と、偏らずに判断すること（精神上の独立性）の両方が求められます。

内部統制を整備・運用する最終的な責任は経営者にあり、業務部門は日々の統制を運用します。監査人は指摘事項と改善提案を監査報告書で報告し、その後、改善が適切に実施されているかをフォローアップで確かめます。改善を実施するのは監査対象側です。

監査の流れと技法

システム監査は、リスクの大きい領域に重点を置いて監査計画を立て（リスクアプローチ）、予備調査で対象の概要をつかみ、本調査で監査手続を適用して監査証拠を集めます。その後、評価・結論をまとめて報告し、フォローアップします。実施した手続と結論の根拠は監査調書に記録します。

監査技法には、関係者に質問するインタビュー（ヒアリング）、文書や記録の閲覧・突合、現場の観察、コンピュータを利用するCAAT（コンピュータ支援監査技法）などがあります。インタビューで得た回答は、それを裏付ける文書や記録を入手して確かめてから監査証拠として使います。

内部統制とITへの対応

金融庁の内部統制の基準では、内部統制の目的を業務の有効性及び効率性、報告の信頼性、事業活動に関わる法令等の遵守、資産の保全の四つとし、基本的要素を統制環境、リスクの評価と対応、統制活動、情報と伝達、モニタリング、ITへの対応の六つとしています。

ITに関する統制には、システムの開発・運用やアクセス管理などシステム全体を対象とするIT全般統制と、個々の業務処理で入力・処理・出力の正確性を確保するIT業務処理統制があります。内部統制にも限界があり、判断の誤り、複数人の共謀、経営者による無視などがあれば有効に機能しないことがあります。