仕様書は契約書のようなもの。詳細に記述し、委託者と受託者が十分な時間を取って確認する。 要件確認リストを使い、可能な限り要件漏れを無くす。 要件定義書をユーザと共にレビューする。 早期の段階でプロトタイプを作り、イメージを確認する。 変更が見…

依頼日 依頼者 システム名 処理名 機能名 変更理由 変更内容 想定リスク リスク対策 適用予定日 適用日 備考

顧客信用情報 契約書（基本・個別） 見積書 注文書・注文請書 RFP プロジェクト名 背景・目的 概要 業務フロー システム構成 規模（期間・費用・工数等） 納期 納品物 マスタースケジュール 体制 機能要件 性能要件 品質要件 ハードウェア ソフトウェア ネッ…

計画は、環境の変化や進捗状況等に応じて日々更新し、精度を上げなければならない。

プロジェクトにおける戦力は、人数だけでは測れない。人数が少なくても、個々が持つ技術力や経験値、知能、モチベーションが高ければ、どんなに困難なプロジェクトでも立派にやり遂げられる。プロジェクトマネージャとしても計算し易い。プロジェクトを任さ…

プロジェクト管理者は何があっても作業をしてはいけない。常に管理に徹する事。作業が進まないのであれば、知恵を絞って作業をメンバーに割り当てる。それでも無理であれば、上司に掛け合って増員する。管理者は常に冷静に余裕を持って全体と細部が見えてな…

プロジェクトが上手く行っているかどうかは、プロジェクトメンバーや顧客に笑顔がどれくらい見られるかで測れる。

プロジェクト管理者は、毎朝その日に予定しているイベントやその日にさせる仕事、達成すべき目標をメンバー全員に通達しなければならない。その日の終わりにそれらがどれだけ完了したのか、進捗状況を確認し、翌日以降の予定を見直さなければならない。

テスト計画を標準化する。 テスト工程を標準化する。 テスト品質を上げるテスト環境を構築する。 テスト効率を上げるテスト環境を構築する。 テスト仕様書をレビューする。 品質指標となる統計情報を収集する。 品質に関する統計情報を分析し、テスト運営の…

品質に対する意識レベルの維持向上が図れる。 品質向上のノウハウの蓄積やスキルの向上が図れる。 テスト工程の運営が効率的に行われる。 品質の良いテストが行われる。 設計メンバーや製造メンバーとは違った観点でテストが行える。 製造メンバーはプログラ…

背景 目的 方針 概要 前提条件 期間 要求内容 成果物 納品物 品質計画 費用計画 進捗計画 組織計画 外注計画

各工程における終了基準を明確に定義しておく事。

複数のプロジェクトが並行している場合、プロジェクト管理者のスキルに関わり無く、一定レベル以上のプロジェクト運営を維持する事が出来る。 プロジェクトが悪い方向に進みかけても、適切な軌道修正が出来る。 品質や生産性の指標となるデータを取ってくれ…

優秀なメンバーを採用する。 プロジェクトの特性に合わせた適切なメンバーを採用する。 メンバーの相性を考慮したチームを構成する。 メンバーのモチベーションを上げる工夫をする。 メンバー間の信頼関係を築き上げる。 メンバーの教育を行い、レベルアップ…

プロジェクト全体の進捗状況の確認 各メンバーの作業状況の確認とメンバーへの指示 課題発生状況の確認と指示 課題解決状況の確認と指示 これからの予定についての確認と周知

各プロジェクトへの支援・指導・助言 各プロジェクトの企画・計画の評価 各プロジェクトのリスク管理・コンティンジェンシープラン策定 リソース調整・調達 技術支援 各プロジェクトのノウハウ蓄積 各プロジェクトの実績蓄積 各プロジェクトの評価

プロジェクトの計画と実績を比較して、進捗状況を分析し、プロジェクト完了までにかかる時間やコストを定量的に予測するための管理方式。

見積書を作る時は、下記前提条件を詳細に明記しておく。 見積もり対象。 見積もり対象外。 納品物。 納期を守るための条件。 料金の変動要素。 不確定要素が発生した時の対応内容。 前提条件が変更になった時の対応内容。 見積書の有効条件。 見積書の有効期…

プロジェクトの目的 費用対効果 予算 期間・納期 対象部門 対象業務 対象システム スコープ 要求事項・要件 成果物 機能・品質・性能目標水準 体制図 マスタースケジュール・マイルストーン

契約前に発注元の与信を確認しておく。 プロジェクトオーナが交代する場合、要件定義書に新しいプロジェクトオーナーの承認印を押してもらう。 メンバーの労務管理、健康管理にも配慮しながらプロジェクトを進める。 重要な役割が個人に依存しないように体制…

プロジェクトの途中で発注元が倒産した。 プロジェクトオーナが交代した。 リーダやキーマン、メンバーが病気になったり、怪我をしたりした。 テストデータで使用している個人情報が漏洩した。 開発で使用しているパソコンがウィルスに感染した。 機器の調達…

ユーザーに当事者意識がなく、開発者に任せ切りである。 ユーザー要求、要件定義がまとめられない。もしくは内容が曖昧である。 ユーザー内で意見の統一ができていない。 役割分担が明確でない。担当が割り当てられていないタスクがある。 プロジェクトマネ…

■直接人件費 システム開発に従事する従業員の人件費 ■間接人件費 システム開発に従事しない従業員の人件費 ■直接経費 システム開発に必要な経費 外注費 ソフトウェアの減価償却費・賃貸料 ハードウェアの減価償却費・賃貸料 施設・設備の減価償却費・賃貸料 …

各開発工程における成果物 要件定義書 各種設計書 プログラム 標準化規定書 標準テストパターン テストデータ テスト結果 開発環境 本番環境

要件は一覧表にする。 一つの項目に一つの要件を書く。複数の要件を書かない。 「〜を〜する」のような表現で統一する。 似た要件はグループ化する。 グループに名前をつけ、分類する。 システム化できることとできないことに分ける。 優先順位を付ける。

本番稼働体制 役割分担 障害時連絡体制 本番稼働通知 ログチェック 障害記録

納入するシステムがユーザーの要求仕様 通りになっているかを確認していただく。 受け入れテストは要件定義書に基づいて行う。 受け入れテストはユーザーが行い、開発者はそれを支援する。 受け入れテストの結果を基に本番稼働判定会議を開く。

導入計画 導入手順 復旧手順 導入前バックアップ 本番環境設定 データベース設定 ネットワーク設定 アプリケーション設定 バッチ運行管理設定 データ移行 導入後バックアップ 稼働確認 導入後バックアップのリストア 最終確認

システム概要 システム構成 システムフロー 機能一覧 画面一覧 帳票一覧 ファイル一覧 テーブル一覧

用語定義 設計フォーム 命名規約(プロジェクト/システム/サブシステム/画面/帳票/プログラム/ディレクトリ/ファイル/データベース/スキーマ/ユーザー/テーブル/ビュー/インデックス/データ項目/変数/定数/関数/エラーコード) コーディング規約(エラー処理/イ…