■導入段階
●立上げ
□プロジェクトは開始時期が一番心配。それをいかに安心できるものにしていくかが大事。
□プロジェクトマネジメントの真髄は、小さな火種を察知して消すこと。
□プロジェクト管理は予防注射である
□プロジェクトの最初に具体的な完成形を一枚の図にして全員で共有する
□チームメンバ・お客様と作業内容について必ず合意し、自分の土俵に持ち込む。
□初期段階で後工程の担当者などもあらかじめ決めてしまう
□プロジェクト計画書・受託条件明細は業務担当者にも説明する
□作業範囲は受託条件明細に記載されている範囲。内容は全員に周知しておく。
□体制図で役割と権限を明確にする！
□脆弱な社内のSE体制は放置しない。
□組織と組織の役割分担をきっちりする！できてないのに条件付検収などしない！
□検証期間中の仕様変更手順も明確化する
□問題はプロジェクトが進む前に可能な限り洗い出す！以下は顧客にも意識してもらう。
・要求定義段階でのコスト…1
・コーディング段階…………5～10倍
・保守段階……………………200倍！
□予防保守が大切。予防する方がずっとラクということ
□品質保証活動を重視すること。手戻りはムダ！
□友好関係を大切に（信頼関係がなければ、いちいち説明しなければならないなど、足を引っ張る元となる。）
□外注発注の適正化 ⇒ 漫然と発注せず、内容を精査する
□「顧客の顧客」に目に見えるメリットを
□業務フローの固定化、ワークシートによるコード、パラメタ設計が可能になるような導入パターンの作成およびマニュアル作成
□今回のプロジェクトの進め方が、自分たちの今までのやり方から何がどの程度違っていて、どんな影響を及ぼしそうになるのかをリスクとして認識する。
□何がリスクとなるか、影響、考えられる対策などについて、経験者から話を聞くこと。
□事前にパッケージ製品の内容をを知ること、今のお客様の運用（とリプレースでやりたいこと）を知ること、そのギャップを知ること。
□プロジェクト計画書、受託条件明細等は、周囲に文句を言わせないよう、専門家の意見を取り入れたものにする
□全体構成を確定
→全体作業を確定
→顧客との役割分担
→スケジュール確定
→それから見積
□発生工程の半数が本稼動後のトラブル。主原因は作業品質、体制。→作業計画・準備・確認に問題があったのでは？
□運用・保守プロセスの強化が必要（作業標準の使用）
□多くのプロジェクトで指摘される問題点
・規模の見積に根拠がない
・過去の実績が反映されていない
・マスタスケジュールが不十分（お客様のイベントが明確でない）
・プロジェクト全体の体制
・変更管理についてのルールがない
・運用・保守プロセスの改善(ITIL)
・周りの人間に自分の役割をわかってもらうことが大事
・方針を揺らがせない
・メンバ全員が同じ方向を向くこと
□作業完了時期に残課題がある場合、検収条件を顧客と認識合わせをしておく。
□UI仕様を検討した人がその内容に応じたシステムテスト内容を考え、テストする（品質保証のV字ラインに合わせて）
●設計
□顧客の要望の裏の裏を読む
□頑張ってもできないものはできないとはっきり言うことが大事。パッケージなのでできません、というのも一つ。
□「本稼働時になかったらガマンできるかできないか」は、顧客目標を達成できるのかという視点の表れ。
□先入観がある場合は、「頭を真っ白にしてください。」と依頼。
□設計品質の確認ポイント
-要求事項と合致していること、どのように動くかがわかること
-予想できる限りの変更に対応できること(1つの変更の修正は1か所であること)
□品質指標はあらかじめ決定しておき、後から動かさくてもよいようにしておくことが必要。後から指標をとるのは至難の業。プロジェクトメンバに余計な作業と受け取られかねない。
□バグは見えないもの。バグは仕込まれるもの。バグはあぶりだすもの。
□レビューでは、設計書にいかに問題を作りこまないようにするか、を検討する。(ここでも先読み力が重要)
□レビューで設計書を作らない。レビューは確認するのが目的。
□レビュー結果がシステム設計書に反映されているか確認する。設計書の更新まで終えて初めてレビューが完了する。
□プログラムを作るときはラク。後からのチェックが断然つらい。
→仕様はきちんと仕様書にまとめる。テストは事前にしっかりやっておく。
一見、手間のようなことにも必ず意味がある。
□詳細設計仕様書のレビュー観点
-メソッド呼び出し間の不整合…返却値に応じた処理がない
-機能実現方法の未定義…UIにあるのにSSにない
-処理内容の未定義…SSにあるがその内容が未
-アプリケーション処理方式違反
□プログラムテスト仕様書のレビュー観点
(ホワイトボックスの観点で以下が網羅されているかをチェック)
-画面チェック処理での分岐(エラー処理)
-画面遷移(補助画面も)
-メソッド呼び出し
-メソッド内分岐(エラー有無)
-共通部品呼び出し分岐
□システムが停止してしまったら何が実際の運用上問題となるのか知っておく。
→運用で回避できるようにするための措置も準備しておく（オフライン操作機能など）
□プログラムの気持ちになる。→手動で行うのであればどうすればよいのか。
□ワークシートを作るときは、お客様が入力しやすいか、SEがそれを見て設定ファイルを作成できるかを考えて作成すべき。
□帳票に関する仕様書内には、コード内容の変更に対応するため、どのテーブルのどの項目が出力されているのかの一覧が必要。
●構築
●テスト
□共通
○テスト項目書においては、正常系は当然として、異常系（想定外データ）のテストについても必ず実施すること。
○テストは絶対にバグを見つけてやるという気持ちで探す。
○どのようなテストをしたか、後でも再現できることが必要。テスト仕様書に基づいてテストをするか、テスト内容を記録する。
□社内テスト
○テスト項目書の内容は、自分の経験に基づく。失敗事例も自分で失敗した例が一番自分の身になる。
□顧客テスト
○データ評価のために、業務サーバとは別のサーバを顧客先へ持っていくことも可能。
○テスト期間においても、お客様に何を見てもらうかを具体的に明示する。（機能なのか、単純な画面の内容なのか）
○パッケージ適用においてはUIができていることが肝心。抜き出したデータだけを見てもらうことは無理。実際の画面で詳細まで見てもらう。(実機、業務フロー、UI資料)
□操作教育
○本来はヘルプ作成・操作教育などない方がよい。見たらわかるシステムにするのがベスト。
○見もしないドキュメントを作成する必要はない。
○顧客には以下を意識してもらう。
・新システム稼働後は、新しい会社に勤める意識で。
・前のシステムのいいところと今のシステムの悪いところを比べない。
最終更新：2011年08月16日 01:37
