高度情報処理/中小企業診断士の資格取得ノート

　システムプロジェクト

　基礎知識

　　 1.プロジェクト

　　 2.進捗を管理

　　 3.品質を管理

　　 4.費用を管理

　　 5.組織と要員を管理

　　

１．プロジェクト

１．１　ＰＭの役割

　① プロジェクト計画の策定
　　　経営計画　→　情報化計画　→　システム化計画　（システムアリストの役割）
　　　システム化計画　→　プロジェクト計画　（プロジェクトマネージャの役割）

　② プロジェクトの目標達成
　　　プロジェクトの目標達成できるようにプロジェクト全体の意識統一をする.

　③ 資源の調達
　　　人材、資材（機器、場所）、予算を確保する.
　　　予算超過や納期遅延の対策として、資材の再調達が必要になる.

　④ プロジェクトの管理
　　　納期管理・進捗管理
　　　　遅延の兆候や状況を早期発見して対策を打つ.
　　　　計画と実績の管理
　　　要求品質の確保
　　　　品質の低下の兆候や状況を早期発見して対策を打つ.
　　　　仕様の課題やプログラムバグの発生と解決の状況を管理
　　　予算管理
　　　　予算の超過の兆候や状況を早期発見して対策を打つ.
　　　　予算と費用発生（開発工数）、作業進捗の管理

　⑤ プロジェクトの運営
　　　情報の共有化、作業の標準化・共通化、チーム間の連携を図る.

１．２　プロジェクトを把握する

　① プロジェクトの目的
　　　経営戦略や情報戦略との整合性はとれているか
　　　　経営戦略は何か?
　　　　情報戦略は何か?
　　　　→　整合性のある目的になっているか確認する.

　　　プロジェクトに何を期待しているのか
　　　　経営トップの問題意識は何か?
　　　　大きな経営課題や問題はないか?
　　　　→　ユーザーと課題・問題を共有する.

　②　プロジェクトの範囲
　　　プロジェクトの業務範囲はどこまでか
　　　　対象業務は何と何か?
　　　　→　対象業務を明確にしないと、なしくずしで拡大する.

　　　既存システムや他の関連システムとの関係
　　　　インターフェイスの問題はあるか?
　　　　→　インターフェイスの要件は早めに確定する.

　③　プロジェクトの制約
　　　予算の制約は
　　　　初期投資とランニングコスト
　　　　→　予算は投資対効果（ＲＯＩ）により決める.

　　　期間の制約は
　　　　納期または稼動時期
　　　　→　会計年度や製品の発売時期などが要件になることがある.

　　　要員の制約は
　　　　経験年数、経歴や資格
　　　　→　同業種や同分野での経験は重要

　　　開発条件の制約は
　　　　稼動後の要件との関係で内部の人材の利用
　　　　→　開発プロセスで運用の人材や体制を整備する.

　④　プロジェクトの体制
　　　プロジェクトオーナーは誰か
　　　　経営トップまたは部門の担当役員
　　　　→　大きな問題解決には強力なリーダーシップが必要

　　　プロジェクトマネージャーは誰か
　　　　企画段階からの参画
　　　　→　マネジメント能力だけでなく、企画力や構想力も必要

　　　決定機関は何か
　　　　ステアリングコミッティー
　　　　メンバーはシステムの利用部門の各部門長、情報システム部門長など数名
　　　　→　社内コンセンサスを得るためのメンバー選定

　　　プロジェクトの推進機関は何か
　　　　事務局やプロジェクト会議
　　　　→　形骸化しないように実を取る体制にする.

　　　業務担当者の参画はあるか
　　　　業務の繁忙期の調整
　　　　→　可能な限り専任化する.

　　　情報システム部門の役割は何か
　　　　→　守備範囲にあわせた役割
　　　　　　メインフレーム、システム企画、システム監査、全社インフラ、予算管理など

　⑤　プロジェクト推進の障害
　　　技術的な問題
　　　　→　実現可能か
　　　業務部門の問題
　　　　→　業務改善や改革
　　　関連会社の問題
　　　　→　契約関係やインターフェイス　

　⑥　プロジェクトのルール
　　　仕様などの変更のルール
　　　　変更管理ルールや変更依頼書は作成されているか
　　　　→　ルールを定着・徹底する　

　　　開始・完了の判断ルール
　　　　決定機関は決まっているか
　　　　→　テスアリングコミッティー以上で決定　

　　　納期や予算の変更の決定ルール
　　　　経営トップの決定事項であり、その手続きは決まっているか
　　　　→　費用対効果の説明が必要

　　　重要な課題の決定ルール
　　　　課題の重要性を判断する機関とその決定機関
　　　　→　責任の所在を明確にする.

　⑦　契約関係
　　　契約形態
　　　　委託契約か委任契約か派遣契約か
　　　　→　開発形態との整合

　　　開発の責任範囲
　　　　→　暗黙の了解部分も明確にする.

　　　瑕疵担保責任の範囲と期間
　　　　→　期間は処理サイクルとの関係　

　　　開発費用と追加仕様の処理
　　　　→　グレープ部分の処理

　　　著作権やライセンス使用権
　　　　→　システムの改良を妨げない.

　　　セキュリティの責任
　　　　→　個人情報については別途検討が必要

　⑧　システム開発手法
　　　パッケージの利用とその採用理由
　　　　→　パッケージは比較検討とニーズとのギャップ分析
　　　開発ツールや開発手法の選定とその採用理由

　　　パッケージ利用時の留意点
　　　　カスタマイズの範囲とバージョンアップ時の影響
　　　　→　コア部分の変更は避ける.
　　　　拡張性とオープン性
　　　　→　特定のＯＳやデータベースに依存しない
　　　　デモンストレーションの実施
　　　　→　基本的な機能の概要を把握する.
　　　　プロトタイプの作成
　　　　→　仕様確認に利用

１．３　プロジェクトの問題と対策
　①　要件が確定しない

　　　要件定義はしたがあいまいなものが多い
　　　　あいまいな理由を追求し、何をすればよいか明確にする.
　　　　→　前提条件が未整備の場合が多い

　　　検討課題として残っているものが多い
　　　　責任者を決めて期限を切って解決する。
　　　　→　課題解決も進捗管理が必要

　②　要件を詰めると仕様が膨らんだ

　　　概算見積もりより費用が大幅にアップする.
　　　　優先順位をつけて要件を絞り込む。
　　　　→　プロジェクトの目的に立ち返る.

　　　　可能な範囲で予算を追加する。
　　　　→　費用対効果を明確にする.

　　　　パッケージやツールを利用して開発効率を上げる.
　　　　→　デメリットも明確にする.

　　　過剰な機能要求になっている。
　　　　機能をシンプルにして運用での負荷とのバランスを図る.
　　　　→　ユーザーのニーズの強さを把握する.

　　　　業務担当者に開発の費用対効果を理解させる.
　　　　→　できるできないではなく、するしないの問題とする.

　　　　二次開発などの対応を検討する。
　　　　→　二次開発の具体的な予定が必要

　③　プロジェクト会議の運営がまずい

　　　メンバーに偏りがある
　　　　不足している分野は何か
　　　　→　正式メンバーと協力メンバーに分ける工夫も必要

　　　プロジェクト会議が効果的に運営できていない
　　　　プロジェクト会議の進行役は適切か
　　　　→　全体を把握しているものが進行役をする.

　　　　プロジェクト会議の議事内容は適切で漏れがないか
　　　　→　各参加メンバーに意見の発言を促す.

　　　　議事録は適切に作成され、迅速に配布されているか
　　　　→　議事録のドラフトは参加者全員がチェックする.

　　　プロジェクト会議に判断能力がない.
　　　　課題の対応の責任者と期日を決めているか
　　　　→　確実に課題解決を進める.

　　　　課題解決の実施のフォローをしているか
　　　　→　対策が別の問題を生じていることもある.

　　　　問題・課題の共有化はできているか
　　　　→　プロジェクト会議にすべての情報を報告させる.