さて、今回から、午後１試験のストーリーから、午後2試験で使えるようなモジュールの抜粋をやってみようかと。
＜2015.1.21追加＞
そう考えた理由は・・・例えば、あるストーリーに感情移入し、それなりに自分の頭の中で印象的な感情が芽生えた時、
その人は、そのストーリーを覚えていて、感動などしたらそのストーリーがいかに感動したかを、他の相手に伝えられるような、つまりそれだけそのストーリーが覚えてしまっているという事です。
つまり何が言いたいかというと、一般的な世間に出回ってる有名どころと言われる高度情報処理対策本に書かれていること、過去問を何度もやる。という対策方法の目的は、その問題に書かれている事を覚えるくらい問題をこなし、そして、覚えてしまう事は、その問題に出てくる登場人物ではなく、主人公であるプロジェクトマネージャは、様々な出来事に対してどんなことを考え、そしてどういう事を行ったかをあくまでもプロジェクトマネージャのお仕事としての見地で読み取る、いわゆる、それが出題者の題意というもの、題意を知れば、自ずとそれが解答という事なのかと思うのです。
資格も持っていない複数受験の経験者が各ブログなので説得力薄いかもしれませんが（苦笑）、問題を解ければよいのか？と自問自答してしまうのです。
どうせなら過去問を何回も繰り返し解く、のではなく、過去問を登場人物も意識させながらストーリ仕立てにして、さすがにその内容で感動巨編まで書くことはなかなか、というか恐らくよほどの筆致力が無い限り無理だとは思いますが、それでも、半ばむりやり？に、無茶苦茶な顧客の要求や、仲間の裏切り（笑）など、自分に降りかかる困難を振り払った主人公が、今回のプロジェクトマネージャに任命されて、新たな課題に取り組んでいく・・・っといったように勝手に思い込みながら、デフォルメ気味に、高々情報処理の過去問を壮大な感動巨編ストーリーであるかのように、読んでいくための読み物としたら、恐らく、その題意すら凌駕する過去問の読破を目指すのではないかと誇大妄想したからです（苦笑）
なので、これを少しでも興味を持って暇つぶし的に読んでみようと思った方にはぜひとも、その気持ちで、何度も繰り返し読んでみて頂けると、もしかしたら新たな視野が開けるかも？と淡い期待を抱いております。
そして次に巷に書かれている高度情報処理対策本には、
『午後２試験の例題は過去問を参考にすべし』
『午後2で問われる事例の題材をモジュール化して準備しておくべし』
である。
という事は、、この流れで過去問ストーリーを読んで感動（笑）までいかなくても、
なんとなく主人公が何をしたのかが印象に残り、その域まで達したならば、
その内容を基に午後2での出題観点となるモジュール抜粋ができるのではと考えたからです（笑）。
＜ここまで＞
生意気言うようですが、午後2の試験の経験者であればあるほど楽しめるかもしれないので、
大変申し訳ありませんが、午後2の必勝法を求めているのでしたら、ちょっとご期待には添えないかもです（ふっ）。
まぁそういう必勝法などはもっとすっごいのがあると思いますので、そちらで頑張った方が身のためです。さ～せん（苦笑）
でもです！午後１の過去問を午後2の問題風にしたらどうなるかを考えながらモジュール化できないか？と
いう試みが面白いと思った方が気に入ってくれるとうれしいかもです（笑）。
Sponsored Link
◆モジュール抜粋に際して
通常午後2のはじめてください！的な声とともに受験番号や氏名の後に必ず行わなければいけないのに、これも試験時間内に含まれるというもの、午後2の問題の最初の要と僕が勝手に思ってる、テンプレート、アンケート用紙である”質問書＊”の記述がまずありますが、午後１の試験問題にこれを当てはめるのもやっときます。
また、”特に記載なし”は、ご存知かとは思いますが、決して分からないと回答してはいけなく、一応、その選択肢もありますが、これは罠ですのでご注意を（笑）
という事で、適切な値の任意を選択するが、本問には特に重要でない項目という事になります。
＊（質問書って何なの？という方は、一応、こちらも参照ください）
また上記リンクに書かれてる質問書＝テンプレートについては、ITSMであって、PMではないのですが、
問われている事はまぁ大して変わりませんでしたので、ご参考まで。）
■質問書より
・プロジェクト名称・30字以内
⇒生産管理システムの再構築
・システムが対象とする企業・機関
１．建設業 ２．製造業 ３．電気・ガス・熱供給・水道業 ４．運輸・通信業 ５．卸売・小売業・飲食店 ６．金融・保険・不動産業 ７．サービス業 ８．情報サービス業 ９．調査業・広告業 １０．医療・福祉業 １１．農業・林業・漁業・鉱業 １２．教育（学校・研究機関） １３．官公庁・公益団体 １４．特定業種なし １５．その他（ ）
⇒２．製造業
・企業・機関などの規模
１．100人以上 ２．101-300人 ３．301-1000人 ４．1001-5000人 ５．5001人以上 ６．特定なし ７．分からない
⇒特に記載なし（７以外の任意で。）
・対象業務の領域
１．経営・企画 ２．会計・経理 ３．営業・販売 ４．生産 ５．物流 ６．人事 ７．管理一般 ８．研究・開発 ９．技術・制御 １０．その他（ ）
⇒４．生産
・システムの形態と規模
１．クライアントサーバシステム（ア。サーバ？台、クライアント？台） イ．分からない ２．Ｗｅｂシステム（ア。サーバ？台、クライアント？台） イ．分からない ３．メインフレームまたはオフコン（？台）及び端末 ４．組み込みシステム（ ） ５．その他（ ）
⇒本問では特に記載なし（イ以外の任意で。）
・ネットワークの範囲
１．他企業・他機関との間 ２．同一企業・同一機関などの複数事業所間 ３．単一事業所内 ４．単一部署内 ５．なし ６．その他（ ）
⇒２．同一企業・同一機関などの複数事業所間
・システムの利用者数
１．1-10人 ２．１１－３０人 ３．３１－１００人 ４．１０１－３００人 ５．３０１－１０００人 ６．１００１－３０００人 ７．３００１人以上 ８．分からない
・総工数
１．約？人月 ２．分からない
⇒特に記載なし（２以外の任意で。）
・費用総額
１．約？百万円（ハードウェア費用を ア．含む イ。含まない ２．分からない
⇒特に記載なし（２以外の任意で。）
・期間
１．？年？月～？年？月 ２．分からない
１．？年？月～？年？月 ２．分からない
⇒２０１４年２月～２０１５年１月（年度は記載なしなので任意）
・貴方が所属する企業・機関など
１．ソフトウェア業・情報処理・提供サービス業など ２．コンピュータ製造・販売業など ３．一般企業などのシステム部門 ４．一般企業などのその他の部門 ５．その他（ ）
⇒１．ソフトウェア業・情報処理・提供サービス業など
１．ソフトウェア業・情報処理・提供サービス業など ２．コンピュータ製造・販売業など ３．一般企業などのシステム部門 ４．一般企業などのその他の部門 ５．その他（ ）
⇒１．ソフトウェア業・情報処理・提供サービス業など
・あなたの担当したフェーズ
１．システム企画・計画 ２．システム設計 ３．プログラム開発 ４．システムテスト ５．移行・運用 ６．その他（ ）
１．システム企画・計画 ２．システム設計 ３．プログラム開発 ４．システムテスト ５．移行・運用 ６．その他（ ）
⇒１．システム企画・計画
・あなたの役割
１．プロジェクトの全体責任者 ２．プロジェクト管理スタッフ ３．チームリーダ ４．チームサブリーダ ５．その他（ ）
１．プロジェクトの全体責任者 ２．プロジェクト管理スタッフ ３．チームリーダ ４．チームサブリーダ ５．その他（ ）
⇒１．プロジェクトの全体責任者
・貴方の管理対象人数
約？人～？人
約？人～？人
⇒特に記載なし（任意。文面からだと、Ｂ氏以外にはチームリーダしか記載がないため１人かも？）
・貴方の担当期間
？年？月～？年？月
？年？月～？年？月
⇒計画だけだと２月～３月の１か月ですが、まぁプロジェクトマネージャなので、最後の年明けの1月まで面倒を見る事になると思われるので、現年２月～翌年１月までで計画されているが、文中で、データ移行後の１か月間は現行システムと平行運用すると記載がありますので、もしかしたら、担当期間は翌年の２月までか、もしくはその後の現行システムを廃止し新システム１本に完全切替後しばらくは立ち合い期間として１か月くらい考慮していれば、翌年３月頃位は担当すべきかもしれませんね（ってこれは任意ですが（苦笑））
■設問ア用の『携わったシステム開発プロジェクトの特徴』モジュール
①題材：
⇒Ｈ社の生産管理システムの再構築プロジェクトのスケジュール策定
②体制：
Ａ社 ２名（Ｂ氏、チームリーダ）
Ｈ社 ２名？（契約窓口、現行システムの保守担当者）
③期間：
⇒現年２月～翌年２月（移行後の並行稼働期間1か月分含む）
④規模：
⇒本問での文中に特に記載なし（任意）
⑤背景・目標：
（事実関係のみ記述）
◆背景
・現システムの運用保守担当者が退職に伴い新システムとして再構築となった点
◆新システムの目標（要望）
・現システムの業務機能は変えないでアーキテクチャを刷新して欲しい。
・新システムは、現行に加えて実績言照会システムを拡張機能として追加して欲しい。
⑥特徴：
今回の大きなポイントは、契約上での齟齬によるプロジェクト全体に影響するリスクが生まれたのではと思われます。
◆契約面：
・全工程が請負契約。
→前提条件現：システムの業務機能は変えずに仕様が明確であるという事
◆事実関係：
仕様が明確なのは初期の状態であり、それ以降の改修履歴は仕様に未反映。→
⇒これより全工程請負契約ではなく外部設計開発工程は委任契約となる。
◆リスク面
→また仕様が現行システムと同等かどうかの作成ドキュメント品質が大きく懸念される点→
⇒これより外部設計工程完了後に、再見積もりを実施→
⇒新システムに移行する工程でも、新システムとしての外部設計ドキュメントの漏れが決して無いとは言えない意味で、リスク対応として移行工程も委任契約としている。
■設問における題意ポイント
午後1の題意を、IPAの採点講評や、解答例の出題趣旨を見て考えてみます。
個人的な見解という事ですが、どうも今回は頻繁に出てくるリスクという用語を意識して欲しいようです（笑）特に計画段階でスコープが遵守できない事によるリスク対応策を考えている点かなと思いました。
■設問の『携わったシステム開発プロジェクトの問題解決』モジュール
本問で必要な事は、PMとしてどうあるべきか？を論じることになると思われます。
したがって、以下のようなシナリオが考えられます。
①キーワード
・仕様が明確でない
⇒そもそもこの事実確認が曖昧であったにもかかわらずどうして契約だけされてしまうのか？
まぁこれは問題とは全く関係しないですが、いつも考えてしまうのです。営業が契約を取ってきたと言って中身を空けると結構（いや、かなりといってもいいくらい）依頼元である顧客側と依頼先である開発者側との考え方の齟齬があるのは本当に、なんででしょうかねぇ（苦笑）
っと、話が逸れてしまいましたので本題に戻ります（苦笑）
今回は多分に漏れず、既に全工程が請負という契約のリスクがなんであるかという点でした。
そもそもなぜ請負契約の利点は何なのでしょうか？またその逆の短所は？
今回は請負の短所をリスクとして浮き出させているように思えます。
僕の考えている請負契約とは、そもそも、依頼元から言えば、”おまかせ”という事かなと思うのですが、仕様が明確でないのに現行通りのものが再構築で作れるわけがない。はい！これにつきるわけです（苦笑）
もちろん仕様精度が完璧（というか内容に関して顧客の了承が得られている）であるものが作成できればそれ以降の内部設計工程から移行前の結合テストまでは、”おまかせ”でいいわけです。
ここで本問に出てくるプロジェクトマネージャが凄いと思ったのは、すでに契約してしまってる段階で、現システムの保守担当に話を聞いて、結果的に現行存在している仕様が現行システムの内容にはならないんだという衝撃の事実が発覚し、それがもとで、営業？が取り付けたと思われる契約内容自体を正してしまった事、それよりもプロジェクト全体の計画の練り直しまで遡ってしまうという事はなかなか信頼が無ければできないなと思いました。
しかしながら、”急がば回れ”というのはこういう事かもしれません。
それで、以前、僕もこれによく似た事やったら、顧客側の仕様、要望、それに対する見積の粗さなどが、まさに今回のように衝撃的な事実として部署レベルの大問題として浮き彫りになって、結果的に、依頼元である顧客への不信感までに及び、契約自体の一端見直し保留となった事を思い出してしまいました（苦笑）。
にしても企業側のなんとも浅はかな軽い考えで契約してしまっている会社の体質をこのプロジェクトマネージャはすでに見破っていて、というか、どうせ営業が利益重視で軽い考えでとってきた契約なんだから裏を折らなければ危なくてしょうがないなぁと言わんばかりの所業ですが、プロジェクトマネージャはそういうくらい人を疑って丁度いいのかもしれないなとしみじみ実感しました（苦笑）
っと、話がまた逸れてしまいましたので本題に戻ります（苦笑）
つまり、仕様が明確なんだから、そのとおり再構築してもらうだけ、しかもそれに新規で追加するのだから、追加含めて請負（おまかせ）でいいでしょ。的な考えがリスクと考えて裏を取ったおかげで、予想が当たってしまい、コスト面含めたスコープ面のリスク分析ができて目出度し、めでたし。というのがこの問題のあらすじかなと思われました（笑）。
・スコープ重視
⇒なんだかんだ言っても、スコープ（納期）が守れなければそれはビジネスでないわけで、多分に漏れず、仕様の齟齬を隠していたのではないかもしれないが恐らくスコープどころか、最低な新システムになりそうな状態であったにも関わらず、Ｈ社としては、まぁそれはそれとしておいといて（っておくなよ（苦笑））頑固に納期は譲れまへんなぁ（ってなんで関西弁？）という点がポイントかなと思います（苦笑）。
で、この主人公であるプロジェクトマネージャが行った事です。
１点目。
とにかくＨ社が現システム機能内容を反映できなかった、初期から現在までの追加（差分）改修履歴を仕様書に現行の初期段階しかない仕様書に追加で新たな外部設計書として作成するのだから、外部設計工程が終わってから、再度見積させて貰わない事には信用ならん！もしそれができないなら契約辞めさせてもらうわ（ってなんで関西弁？）という強気の条件ですね（笑）
２点目。
あと、当然、現行の機能をキープするという最初の要望は破綻しました。重要なのは新たに作成した外部設計書の内容が正であり、その内容が承認され、その内容に沿って請負”おまかせ”で次の内部設計工程に安心して新システムに専念できる事が最重要であるという事は、問題としてもなっているくらいなので、この点は題意なのかなぁと思いました。
・人員調達
⇒今回のシステムはただの現行の焼き直しという訳ではない点がポイントです。
拡張機能というものがそれですが、案の定、この開発を現行メンバで回すのは不可能というシナリオです。という事は、他人で不足とぴう事になり、人手が足らないなら補充、つまり調達という流れですね。
題意と思われる点は、人員調達する際の注意すべき観点を抑えているかという点のようです。
つまり、委託先選定ポイントが以下のポイントであるべしという３つの教えがあるようです。
題して！
＜委託先選定ポイント３箇条＞です。（笑）
１、複数候補を出して調達コストが適正にでき、委託先の客観的な評価ができるようにすべし。
１、委託先選定の履歴を明確に文書で残すため提案依頼書（ＲＦＰ）を作成すべし。
１、委託先選定基準は、選定会社と同等の品質管理基準を有し、研修条件を満たすべし。
・移行・運用
⇒今回、移行についても請負（おまかせ）では困る、この工程は自社は支援という事で委任契約を結ぶこととしましたが、支援の趣旨は顧客要望でもある（できるだけ）業務に影響なく切り替えるための方法を考えるという点でした。
プロジェクトマネージャである主人公が考えたのは、いきなり現システム１本に移行して稼動する事のリスクな点を避けたがっています。それは当然、仕様が明確でなくオリジナルな新システムとして、いわばＮｅｏ外部設計書の内容が、たとえ顧客了解の上であったとしても、結果的に、後付けで始めから携わっていないそこまで事情通でない人が作成した仕様にはもしかしたら漏れが全くないとは言い切れない。そのため、移行は、システムとして一巡する、月次処理が終わるまでの1か月は現システムも稼働させて並行で運用してもらった方が、安心できると考えたわけです。
ただそれにしてももし仕様に漏れ・不足があり、それが業務影響を生じてしまった場合、あぁそれ、顧客側で了解してたんでね。などと悠長な事を言えないかもしれない。もしかしたら、あぁ、あの時はそうは言いましたが、この影響はそうも言ってられない・・・などとアンビリーバブルな事を平気で掌裏返してクレームされるかもしれないのです（苦笑）
じゃあどうすればよいのか・・・という事で、プロジェクトマネージャが考えた事は、以下でした。
・平行運用で実装の漏れや処理結果に不一致が生じた場合は、現システムに切戻す体制を作る
・実装の漏れという、漏れにも以下の２通りがあり、その内容での対応方法を後でトラぶらないように瑕疵条件を提示して合意を取っておくべきと考えたのは当然と言えば当然で重要すね。
ようするに、
瑕疵条件事項です。
漏れとなっていた内容が・・・
１、Ｎｅｏ外部設計書に記載通りでなかった場合は瑕疵担保責任の期間内なら無償対応、期間外なら追加有償対応（もしくは応相談かも）
２、Ｎｅｏ外部設計書に記載内容になかった場合は瑕疵担保責任の期間内なら無償対応、期間外なら追加有償対応で別途見積もり
②PMとして実施すべき点
・スコープ遵守
⇒顧客がどんなに無理難題でも（笑）、冷静にスコープが守れるか、守れないなら、その原因は依頼元なのか先に問題があるのか判断しその事に対するリスク分析をする必要があると思われます。
そのため行うべき事は以下かと。
・契約の見直し
・スコープの見直し
・人員調達
・本番移行の配慮
・稼働後の瑕疵担保条件の合意
③汎用的に使える具体例・フレーズ
・現行システムの担当者が退職する事で、現行システムを再構築する
。請負契約と委任契約
・仕様が明確でないために起こるスコープ、品質などのリスク
・スコープ遵守対策としての人員調達
・委託選定
・環境移行時に考慮すべき点
・瑕疵担保条件の提示
以上となります。
最後に・・・今回のキーワード（用語）♪
・契約管理
・ギャップとリスク
・再見積り
・外部設計（依頼元が関わる開発の初期工程）
・人員調達
・委託選定
・品質管理基準
・提案依頼書（ＲＦＰ）
・データ移行
・平行運用
・瑕疵担保
本問で必要な事は、PMとしてどうあるべきか？を論じることになると思われます。
したがって、以下のようなシナリオが考えられます。
①キーワード
・仕様が明確でない
⇒そもそもこの事実確認が曖昧であったにもかかわらずどうして契約だけされてしまうのか？
まぁこれは問題とは全く関係しないですが、いつも考えてしまうのです。営業が契約を取ってきたと言って中身を空けると結構（いや、かなりといってもいいくらい）依頼元である顧客側と依頼先である開発者側との考え方の齟齬があるのは本当に、なんででしょうかねぇ（苦笑）
っと、話が逸れてしまいましたので本題に戻ります（苦笑）
今回は多分に漏れず、既に全工程が請負という契約のリスクがなんであるかという点でした。
そもそもなぜ請負契約の利点は何なのでしょうか？またその逆の短所は？
今回は請負の短所をリスクとして浮き出させているように思えます。
僕の考えている請負契約とは、そもそも、依頼元から言えば、”おまかせ”という事かなと思うのですが、仕様が明確でないのに現行通りのものが再構築で作れるわけがない。はい！これにつきるわけです（苦笑）
もちろん仕様精度が完璧（というか内容に関して顧客の了承が得られている）であるものが作成できればそれ以降の内部設計工程から移行前の結合テストまでは、”おまかせ”でいいわけです。
ここで本問に出てくるプロジェクトマネージャが凄いと思ったのは、すでに契約してしまってる段階で、現システムの保守担当に話を聞いて、結果的に現行存在している仕様が現行システムの内容にはならないんだという衝撃の事実が発覚し、それがもとで、営業？が取り付けたと思われる契約内容自体を正してしまった事、それよりもプロジェクト全体の計画の練り直しまで遡ってしまうという事はなかなか信頼が無ければできないなと思いました。
しかしながら、”急がば回れ”というのはこういう事かもしれません。
それで、以前、僕もこれによく似た事やったら、顧客側の仕様、要望、それに対する見積の粗さなどが、まさに今回のように衝撃的な事実として部署レベルの大問題として浮き彫りになって、結果的に、依頼元である顧客への不信感までに及び、契約自体の一端見直し保留となった事を思い出してしまいました（苦笑）。
にしても企業側のなんとも浅はかな軽い考えで契約してしまっている会社の体質をこのプロジェクトマネージャはすでに見破っていて、というか、どうせ営業が利益重視で軽い考えでとってきた契約なんだから裏を折らなければ危なくてしょうがないなぁと言わんばかりの所業ですが、プロジェクトマネージャはそういうくらい人を疑って丁度いいのかもしれないなとしみじみ実感しました（苦笑）
・スコープ重視
⇒なんだかんだ言っても、スコープ（納期）が守れなければそれはビジネスでないわけで、多分に漏れず、仕様の齟齬を隠していたのではないかもしれないが恐らくスコープどころか、最低な新システムになりそうな状態であったにも関わらず、Ｈ社としては、まぁそれはそれとしておいといて（っておくなよ（苦笑））頑固に納期は譲れまへんなぁ（ってなんで関西弁？）という点がポイントかなと思います（苦笑）。
で、この主人公であるプロジェクトマネージャが行った事です。
１点目。
とにかくＨ社が現システム機能内容を反映できなかった、初期から現在までの追加（差分）改修履歴を仕様書に現行の初期段階しかない仕様書に追加で新たな外部設計書として作成するのだから、外部設計工程が終わってから、再度見積させて貰わない事には信用ならん！もしそれができないなら契約辞めさせてもらうわ（ってなんで関西弁？）という強気の条件ですね（笑）
２点目。
あと、当然、現行の機能をキープするという最初の要望は破綻しました。重要なのは新たに作成した外部設計書の内容が正であり、その内容が承認され、その内容に沿って請負”おまかせ”で次の内部設計工程に安心して新システムに専念できる事が最重要であるという事は、問題としてもなっているくらいなので、この点は題意なのかなぁと思いました。
・人員調達
⇒今回のシステムはただの現行の焼き直しという訳ではない点がポイントです。
拡張機能というものがそれですが、案の定、この開発を現行メンバで回すのは不可能というシナリオです。という事は、他人で不足とぴう事になり、人手が足らないなら補充、つまり調達という流れですね。
題意と思われる点は、人員調達する際の注意すべき観点を抑えているかという点のようです。
つまり、委託先選定ポイントが以下のポイントであるべしという３つの教えがあるようです。
題して！
＜委託先選定ポイント３箇条＞です。（笑）
１、複数候補を出して調達コストが適正にでき、委託先の客観的な評価ができるようにすべし。
１、委託先選定の履歴を明確に文書で残すため提案依頼書（ＲＦＰ）を作成すべし。
１、委託先選定基準は、選定会社と同等の品質管理基準を有し、研修条件を満たすべし。
・移行・運用
⇒今回、移行についても請負（おまかせ）では困る、この工程は自社は支援という事で委任契約を結ぶこととしましたが、支援の趣旨は顧客要望でもある（できるだけ）業務に影響なく切り替えるための方法を考えるという点でした。
プロジェクトマネージャである主人公が考えたのは、いきなり現システム１本に移行して稼動する事のリスクな点を避けたがっています。それは当然、仕様が明確でなくオリジナルな新システムとして、いわばＮｅｏ外部設計書の内容が、たとえ顧客了解の上であったとしても、結果的に、後付けで始めから携わっていないそこまで事情通でない人が作成した仕様にはもしかしたら漏れが全くないとは言い切れない。そのため、移行は、システムとして一巡する、月次処理が終わるまでの1か月は現システムも稼働させて並行で運用してもらった方が、安心できると考えたわけです。
ただそれにしてももし仕様に漏れ・不足があり、それが業務影響を生じてしまった場合、あぁそれ、顧客側で了解してたんでね。などと悠長な事を言えないかもしれない。もしかしたら、あぁ、あの時はそうは言いましたが、この影響はそうも言ってられない・・・などとアンビリーバブルな事を平気で掌裏返してクレームされるかもしれないのです（苦笑）
じゃあどうすればよいのか・・・という事で、プロジェクトマネージャが考えた事は、以下でした。
・平行運用で実装の漏れや処理結果に不一致が生じた場合は、現システムに切戻す体制を作る
・実装の漏れという、漏れにも以下の２通りがあり、その内容での対応方法を後でトラぶらないように瑕疵条件を提示して合意を取っておくべきと考えたのは当然と言えば当然で重要すね。
ようするに、
瑕疵条件事項です。
漏れとなっていた内容が・・・
１、Ｎｅｏ外部設計書に記載通りでなかった場合は瑕疵担保責任の期間内なら無償対応、期間外なら追加有償対応（もしくは応相談かも）
２、Ｎｅｏ外部設計書に記載内容になかった場合は瑕疵担保責任の期間内なら無償対応、期間外なら追加有償対応で別途見積もり
・スコープ遵守
⇒顧客がどんなに無理難題でも（笑）、冷静にスコープが守れるか、守れないなら、その原因は依頼元なのか先に問題があるのか判断しその事に対するリスク分析をする必要があると思われます。
そのため行うべき事は以下かと。
・契約の見直し
・スコープの見直し
・人員調達
・本番移行の配慮
・稼働後の瑕疵担保条件の合意
③汎用的に使える具体例・フレーズ
・現行システムの担当者が退職する事で、現行システムを再構築する
。請負契約と委任契約
・仕様が明確でないために起こるスコープ、品質などのリスク
・スコープ遵守対策としての人員調達
・委託選定
・環境移行時に考慮すべき点
・瑕疵担保条件の提示
以上となります。
最後に・・・今回のキーワード（用語）♪
・契約管理
・ギャップとリスク
・再見積り
・外部設計（依頼元が関わる開発の初期工程）
・人員調達
・委託選定
・品質管理基準
・提案依頼書（ＲＦＰ）
・データ移行
・平行運用
・瑕疵担保
さて、次回はどんな使えるモジュールがあるのでしょうか？
などと勝手に盛り上がってしまってますが、ご容赦を（苦笑）
あ、本ブログは、過去問ストーリーが終わってからの記述となります。
では乞うご期待（って誰が？（笑））
