応用情報技術者 試験情報＆徹底解説

そして，その監査目的を"個々のプロジェクトにおいて，プロジェクト管理が適切に行われているかどうかを確認し，予算及び，スケジュールの遵守，並びに品質の確保に寄与すること"にした。

[経営]プロジェクトの後半であり、監査回数が1回になるから

主な発見事項の①の内容について
〔監査計画の立案〕の(3)に記述されている監査項目①の観点から
T君が指摘事項として監査報告書に記載すべき事項

インターネット販売システムの再構築プロジェクトの目的は"システム性能，稼働率，安全対策の向上"とあったが，利用部門の担当者にインタビューを行ったところ，操作性の改善など機能の向上についても多くの要望があることが分かった。
  また，経理部門の複数の担当者にインタビューを行ったところ，財務会計システムの再構築プロジェクトの目的である決算早期化を実現するためには，システム対応に加えて業務の大幅な見直しが必要であることが判明した。しかし，プロジェクト計画書には，その内容やスケジュールについて記載がなかった。

プロジェクト体制は適切か。

プロジェクトメンバと利用部門の間で意思疎通が足りず、改善の余地がある

プロジェクトの炎上を防ぐためにSEが「要件定義」で気をつけたい4つのこと（paizaブログ）


受託開発では業界特有の常識もあるので、ユーザーは当たり前だと思っているけど一般的には知られてないこと（開発側は知っておかないといけないこと）も要件定義で引き出しておく必要があります。

また、ヒアリングさせていただくユーザー側のメンバーのスケジュールや場所の確保も欠かせません。実際始まってみたら忙しすぎて誰も要件定義のための打ち合わせに出席してくれない…なんてことになったら大変です。契約時に「要件定義にご協力いただけない場合は成果物は保証できない」とはっきり決めておきます。

もう1つよくあるのが、要件定義はIT部門とだけ合意してもうまくいかないということです。実際にシステムを使うユーザーとの食い違いは最後の最後に大幅な手戻りを発生させる危険性があります。

「誰が使うシステムか？」をはじめに確認しておき、できる限り実際の利用ユーザーにも要件定義の内容について合意をとるように（直接打ち合わせの場に出てもらうことが難しくても、利用ユーザーの責任者には随時内容を確認してもらう約束する、など）しましょう。

物流システムの改修のプロジェクトについて，最新スケジュールを確認したところ，要件定義は終了している予定であるにもかかわらず，実際にはほとんど進んでいなかった。プロジェクトリーダに理由を確認したところ，利用部門の担当者が多忙であり，ほとんど打合せに出席できていないとのことであった。また，プロジェクトリーダによれば，当初のスケジュールどおりにプロジェクトを完了するのは難しいとのことであった。

atmarkit.itmedia.co.jp/ait/spv/1906/03/news007.html
「訴えてやる！」の前に読む IT訴訟 徹底解説（66）
繁忙期に打ち合わせを設定するなんて非常識じゃないですか！

平成2年12月、あるシステム開発ベンダー（以下、ベンダー）と図書教材販売会社（以下、ユーザー企業）が入金照合処理のシステムを売り渡す契約を結んだ。納期は平成3年3月とされた。

しかしベンダーは平成3年3月までにユーザー企業とプログラム開発の打ち合わせをせず、当初スケジュールを変えて平成3年4月に打ち合わせを行い6月末までに開発する旨の提案をしたが、ユーザー企業はこれを拒絶した。

（・・・）

ここで、ユーザー企業の業種に注目してほしい。教材販売会社は4月が繁忙期である。

  「本業の忙しい中、システムに関する打ち合わせになど出ていられない」というのが本音だ。だからこそ当初スケジュールでは「3月をベンダーの開発期間に充て、同月末にリリースしてもらおう」という考えだった。

  「3月の納期が守れず、自分達の都合も考慮してくれずに4月に打ち合わせを入れたスケジュールを提示し、最終的にはそれすら守れず納期が8月まで遅れたのは、ベンダーの債務不履行だ」とするユーザー企業。

  それに対し、「4月の打ち合わせを実施しないというユーザー企業の非協力的な態度こそが大幅な遅延につながった」とするベンダー。

（・・・）

ここで注目したいのは、「専門家であるベンダーはユーザー企業の業種、業態などを考慮して、スケジュールなどを策定する義務がある」という点だ。

  示された要件に従ってただモノを作ればよいのではなく、「プロジェクトを成功させる」という管理義務を全うするためには、ユーザー側の事情もよく考慮して、プロジェクト計画を立てたり見直したりすべきであり、ユーザーの繁忙期に打ち合わせを設定することは、そうしたプロジェクト管理義務を果たしてはいないという判断をしている。

  平たく言えば、ベンダーの身勝手で自己中心的な考えが紛争の一因となっていると述べている。

（・・・）

実はユーザー企業は、「翌年にシステムの切り替えを行う」ことを経営方針として決めていた。
そのため、本件システムの開発は一刻の猶予もない状態であり、「4月は忙しいから打ち合わせなどできない」とベンダーの要求をはねつけるのは、あまりに非協力的であった。

  自分たちの経営方針を守るためには「ベンダーの協力要請に応え、何とかして4月の打ち合わせに出席する」か、そうでないならば「明確なスケジュールの変更をすべき」ところを、そのどちらもしないでベンダーにばかり責任を押し付けるのはどうなのか、これはユーザーの協力義務違反ではないか、と裁判所はいっている。