プロジェクトマネージャ 2016年 春期 午後I 問題

共通の文章

プロジェクトのリスク管理に関する次の記述を読んで,設問1ユー3に答えよ。 J社は,プラントで石油化学製品を製造する企業である。J社製品に対する需要は 伸び悩み,プラントの運転に係る業務の効率向上と費用の削減が求められている。 また,ベテラン作業員の退職に伴う若手作業員への技術継承が課題となっている。 一方で,プラントは重要な社会基盤であり,安全で安定的な運転が求められている。 具体的には,プラントを運転しながら行う日常の設備の点検や補修作業(以下,日 常点検という)は,多くの作業を手際よく進める必要があるが,点検を行う設備に 対する作業手順を間違えるとプラントの停止につながりかねないので,決められた 手順に沿った確実な作業実施が求められる。 このような状況に対応するために,J社は,これまで使用してきた設備管理システ ム(以下,現システムという)に代えて,通信機能を搭載したタブレット端末を活 用して,日常点検を支援する,新たな設備管理システム(以下,新システムという) を開発するプロジェクトを立ち上げることにした。開発期間は1年で,年末年始の プラントの停止期間中にシステムを切り替えるので,スケジュールの遅延は許され ない。プロジェクトマネージャ(PM)はシステム部のK氏である。 【現システムにおける作業の問題点と新システムの機能] ]社のプラントは,様々な種類の数多くの設備から構成されている。これらの一連 の設備は広大な土地の中に分散して設置されている。現システムは,10年以上前に 開発され,書類を使うことを前提に作業を実施しているので,最近では次のような 問題点が顕在化している。 ・作業指示に基づき日常点検を行う場合,事前に作業員が現場に行き,対象となる 機器の位置や状態を確認した上で,必要となる点検のチェックリスト(以下,A 検球という),マニュアルや設計図面などの書類を事務所に取りに戻らなければな らない。 ・日常点検の作業では,現場で点検款に結果を記録し,点検作業終了後に事務所に 戻って現システムに入力し,作業報告書にまとめる。これらの一連の処理は,日 中に点検作業を続けて行い,全ての検作業終了後にまとめて現システムへの入 力と作業報告書の作成という手順で行われることが多い。その結果,現システム =Bee への入力は夜間にまで及ぶことが多く,入力間違いや入力の漏れが発生する原因 どなつている。 ・若手作業員が日常点検を行う際,作業内容の不明な点を,書類を一緒に見ながら |ベテラン作業員に確認したい場合には,事務所に戻る必要があり,作業が非効率 となっている。 これらの問題点を解消するために,新システムでは,現システムの機能に加え, 次の機能を実現する。 ・点検款や日常点検時に必要なマニュアルや設計図面などの情報を,現場で必要に 応じてタブレット端末で参照できるようにする。 ・日常点検の履歴から,次回の日常点検の対象設備や点検項目を抽出し,適切な手 順に沿ってリスト化した点検球としてタブレット端末に表示できるようにする。 ・点検款の手順に従って日常点検の作業を確実に実施しながら,作業の結果をタブ レット端末でチェックするだけで入力できるようにする。 ・現場の作業員と事務所の作業員が,タブレット端末の通信機能を利用して,同じ 情報を一緒に見ながら確認,質問アドバイスなどの協働作業を行えるようにす る。 K氏は,今回のプロジェクトにおいては,通信機能を搭載したタブレット端末を活 用した新たな日常点検の業務プロセスを導入する必要があると考えた。そこで,こ のことに起因する開発スケジュール面のリスクを軽減するために,早い段階からス テークホルダの協力を得て,協働して開発を進めることにした。 [プロジェクトに対する要求事項] K氏は,今回のプロジェクトでは,業務の特性から次のような要求事項を実現す る必要があると考えた。 ・機能要件への高い適合性の確保 機能要件への不適合が,点検を行う設備に対する作業手順の間違いにつながる 可能性もあるので,機能要件を明確にした上で,徹底した適合性の検証が求めら れる。 ・日常点検作業を阻害しない操作性の確保 作業員が日常点検を行う場合,様々な器具を使ったり,設備の操作を行ったり sc 8 oes する。そのような状況でも利用できるように,作業員の作業を阻害しない操作性 が求められる。 ・現場と事務所間の協働作業の効率向上 現場と事務所間で通信機能を活用した協働作業を実現することによって作業の 効率向上を図るために,現場の作業環境で確実に通信機能による協働作業が可能 かどうかを検証する必要がある。現場と事務所の作業員の通信手順を設計段階で 確立し,試用期間の中で検証する。 ・情報セキュリティの確保 可搬性を確保おするために,通信機能を搭載したタブレット端末を導入するが, 情報セキュリティの確保が必要となる。 ・データの整理・検証 現システムのデータの完全性についての問題を解決するために,データの整 理・検証を行う必要がある。 K氏は,プロジェクト計画の策定に当たっては,これらの要求事項を十分に考慮す る必要があると考え,図1のスケジュールを策定した。 月||2|sl 4l5s le|?|s|9 liolillizl il aerate TP 要件|外部設計内部設計|製造・単体テスト|結合総合試用稼働 切替え \Z MM プロトタイプブ検証 移行1移行2 図1スケジュール 〔要求事項への対応〕 K氏は,それぞれの要求事項に対し,次の対応策を講じることにした。 ・機能要件への高い適合性の確保 機能要件への高い適合性を確保し,最終的なビジネス上のリスクを回避するた めに,①総合テスト後に新システムの試用期間を設定して,改善した業務プロセ スによる新たな実務の内容や業務フローに則した確認項目を充実させることにし た。試用期間においては,日常点検の際に従来の書類を使用した作業と並行して, タブレット端末も利用し,新システムで新しい実務に則した作業が確実に実施可 能かどうかを確認してもらうことにした。 ・日常点検作業を阻害しない操作性の確保 日常点検作業を阻害しない操作性を確保するために,設計段階でプロトタイプ による検証を行うことにした。タブレット端末に,従来及び新しい点検球のフォ ームを順番に表示し,つ日常点検の現場で,作業員にあることを確認してもらう SOEs ・現場と事務所間の協働作業の効率向上 ③新しい機能が現場作業の効率向上に確実に貢献することを確認するために, 試用期間の中で,試行目的で移行したデータを用いて,実際の日常点検の作業環 境において,タブレット端末を使ってもらうことにした。 ・情報セキュリティの確保 ④情報セキュリティ面のリスクを回避するために,タブレット端末にデータを 保存させない機能を追加することにした。さらに,タブレット端末にICタグを貼 付して,管理を徹底することにした。 ・データの整理・検証 現システムのデータの完全性についての問題によって,新システムで発生する 可能性があるリスクを回避するために,⑤現システムのデータの整理・検証を徹 底して行うことにした。 [機能の追加要求] プロジェクト開始後2か月が経過し,プロトタイプでの検証を進める中で,“より 効率よく作業が行えるように,GPS機能を利用し,作業員の現在地と目的の設備の 位置をプラントの図面上で確認できるようにしてほしい。”という追加要求が挙がっ てきた。GPS機能自体はタブレット端末の機能として装備されているが,位置情報 をプラントの図面上に正確に表示させるためには,GPS機能を活用したZ社のソフ トウェアパッケージを利用し,ソフトウェアパッケージ上の追加開発をZ社に委託 しなければ対応できない。Z社のソフトウェアパッケージは市場での導入実績が多い が,]社としては,Z社との取引実績はない。 ー5ーー K氏は,この追加要求に対応することは,単純に開発工数が増えるというだけでな く,別のリスク要因を抱え込むことになると考えた。今回のプロジェクトは後半の FAD LAB,試用期間を十分に確保することが最優先だと考え,現時点ではこの追 加要求を開発範囲には含めず,次回の開発事項として対応を検討することにした。

共通の文章

プロジェクトにおけるコミュニケーションに関する次の記述を読んで,設問1~3 に答えよ。 システム開発会社のP社は,10年前に開発した放送事業者A社の放送番組編成支 援システムの追加開発を担当している。追加開発は,A社との間で請負契約を結んで, 半年サイクルで継続的に実施している。このシステムの特徴は,他の複数のシステ ムと連携していることから,A社の現場部門や他システムの担当者ながなど,ステークホ ルダが多いことである。 長期にわたってこのシステムを担当してきたP社のプロジェクトマネージャ(PM) が退職することになり,後任のQ BRM PMとして追加開発を担当することになっ た。開発チームはこれまでどおり,リーダであるR主任を含むメンバ8人から成る 体制を継続する。 Q課長は,着任に当たって過去のプロジェクトの実績を確認するとともに,開発チ ームやステークホルダにヒアリングを行ってこれまでの状況を把握し,次のように 整理した。 ・前回の追加開発(以下,前回開発という)をはじめ過去の追加開発でも,何回か 大きな手戻りが発生しており,Att,P社とも,何らかの対策の必要性を認識して いる。 ・A社のステークホルダは,P社に対して不満をもっている。 ・P社の開発チームは,十分ながチームワークを発揮できていない。 Q課長は,これらの状況を生んだ根底にはコミュニケーションに関する問題がある と考え,改善を検討することにした。 (前回開発の問題を踏まえた改善| Q課長は,前回開発の問題を次のように整理した。 ・A社システム部は,現場部門から提示された要求事項を,そのまま一覧にしてP 社に提示していた。そこに記載された要求事項は,“何をどのように追加・変更す るか"は書かれているものの,断片的な情報であることが多く,業務上の目的や, 背景,意図などはほとんど書かれていなかった。また,要求事項の漏れや考慮不 足が後工程で見つかることもあった。 ー8一 ・P社は,A社システム部から一覧にして提示された要求事項を,そのまま追加開発 のインプットとしており,要求事項のレビューをほとんど実施していなかった。 ・要求事項一覧で使用されていた業務用語は,用語の定義が不明確で,複数の解釈 が可能なものもあった。そのような場合に,A社とP社の解釈が違っていると, その違いは現場部門による受入テストまで検出できず,大きな手戻りとなった。 ・現場部門が,複数の要求事項から自明なので当然対応されるはず,CHAT,B 求事項一覧に明示されていない要求事項もあった。しかし,その認識はA社シス テム部にもP社にもなかったので,現場部門による受入テストで,“このままでは 業務には適さない”と評価され,大きな手戻りとなった。 ・要求事項からP社としては他システムへの影響が容易に想定できるはずだと思わ れた事項が,連携先の他システム担当者の想定から漏れていて,他システムとの 連携確認テストで問題が判明し,大きな手戻りとなった。 ヒアリングによると,過去の追加開発でも上記の前回開発の問題と同様な事象が 発生しているとのことだった。 Q課長は,図1に示す前回開発における要求事項の解釈に関わる過程で,⑪と⑮⑪ の過程に問題がある,と考えた。 実現したい要求事項要求事項一覧 図1前回開発における要求事項の解釈に関わる過程 Q課長はまず,①A社システム部が提示する要求事項一覧に関する基本的な責任の 所在について,A社システム部と話し合い,合意を得た。その上で,次の1①)~て(5)の プロセスで要求事項のレビューを行うことを提案した。 (1)P社は,要求事項一覧に記載された内容について,A社システム部に別の観点や 表現で問い返したり,疑問点を質問したりして,要求事項の解釈にA社と違いが ないことを確認する。 (2)P社は,解釈した要求事項について,“なぜ追加・変更するのか",“何のために 追加・変更するのか"という質問を励行する。A社システム部はその質問を契機と 2 fil して,提示した要求事項が実現したい内容と合っているかどうかを現場部門に確 RL,必要であれば実現したい内容に合わせて要求事項の見直しを行う。 (3)P社は,解釈した要求事項を図表に整理して,要求事項としての漏れや考慮不 足がないかどうかを整理する。また,要求事項から導かれる,利用者や他システ ムへの影響について整理する。A社システム部はその情報を基に,必要であれば実 現したい内容と合わせて要求事項の見直しを行う。 (4)上記のプロセスを経て完成度を高めた要求事項一覧に対し,P社はその要求事 項をブプレークダウンした要件定義書を作成する。A社システム部は,要件定義書を レビューし,要求事項一覧の内容が正しくP社に解釈されていることを確認する。 (5)A社システム部は,要求事項一覧と要件定義書の必要な範囲について,現場部 門や他システム担当者とレビューし,要求事項が実現したい内容と合っているこ と,他システムへの影響が想定されていることを確認する。 A社システム部はこの提案を受け入れた。 [顧客報告の改善 Q課長は,P社の顧客報告に対するA社システム部の要望をヒアリングした結果 に基づいて,R主任に顧客報告についての改善案を検討するように指示した。R主任 が検討した改善案は,表1のとおりである。 表1顧客報告についてのR主任の改善案 相互の認識の違いから,進捗や品質の問題が発生|認識の違いを発生させないために,文章中心の開発 している。誰識の違いをできるだけ早期に検出]ドキュメントに関して,図表を活用して認識誤り し,影響を最小限にしたい。の発生を予防するとともに,主に[b]TB *でのコミュニケーションの質と景を向上させる。 要|問題が発生した際に,その間題に対してP社がど|問題の報告に当たっては,P社の対応方針を明確に ||のように対応するつもりなのか,不明確なことが|して報告する。対応方針が明確にできない場合に 2|あるので,改善してほしい。も,複数の選択肢を提示する。 問題解決のために,システム部やステークホルダ|P社だけでは解決できない問題については,A社シ 要|の対応が必要になるケースで,その依頼が後手に|ステム部及びステークホルダへの依頼事項を検討 2)回ることが多い。早めに相談をしてくれれば,取|LT,できるだけ速やかに報告する。 3|り得る選択肢も広がるので,善処してほしい。 Q課長は,要望3に対する改善案について,この内容ではA社システム部及びス テークホルダの時間を有効に使う観点からは不十分なので,②つ見直しを行うように 指示した。R主任は改善案の見直しを行い,Q課長はこれを承認した。 〔開発チーム内部の改善〕 Q課長は,開発チームへのヒアリングで,次のような意見を収集していた。 (1)R主任の意見 ‘RIED PMは,進捗会議で進捗や品質の問題が報告されると,報告者に対して “原因は何か",“対策は考えたか"と問い詰め,全員の前で叱次することが多 かった。そのためにメンバは,原因分析や対策立案ができていない段階では, 問題の発生を報告しにくいと感じていると思う。 ・連絡や相談を頻繁にしてくるメンバがいる一方で,ほとんどしてこないメンバ もいる。ミーティングでも発言をするメンバとしないメンバに分かれている。 意見を言わかないメンバともコミュニケーションを取る必要があるが,そのため の時間を確保できていない。 (2)メンバの意見 ・進捗や品質の問題を発生させたくないので,自分の担当作業を間題なく進める ことを最優先にしている。過去に他のメンバの作業が遅れていた時,早めに助 言,.レビューをしてあげていれば,影響小さくできていたかもしれない。 ・前任のPMもR主任も,いつも忙しい様子だったので,明らかに問題であると 判断したときは相談したが,予兆や“いやな感じ”"といった程度では,相談し づらかった。結果として問題になったケースが多く,早めに相談しておくべき だった。 Q課長は,これらの意見をまとめてメンバに配布した。その際に,“チームとして 活動する強みを生かすことが最も大切であり,今後は,問題を起こした個人に着目 するのではなく,問題に対して|c|で向き合う姿勢で臨みたい。そのために は,チーム内部の状況を的確に共有することが重要である。その第一歩として,1週間 後にミーティングを開き,全員で改善方針を検討したいので,それぞれの見解や対策 を事前に考えてきてほしい"と伝えた。また,Q課長は,これまでの開発チームのコ ミュニケーションの状況を踏まえて,各自の事前の検討結果をミーティングの前日ま ーロー でに提出するように指示した。 ミーティングでQ課長は,前日までに集めた意見を整理した資料を配布した上で, まず③全員に自分の意見を述べさせ,議論を経て,朝夕の短時間ミーティングの開催 や,困っているメンバに対する相互支援などの改善方釘をまとめた。次にQ課長は, “これからは,過去の事例に学んで,悪い話ほど早のに,ミーティングなどの場を 通じて共有してほしい。問題として明らかになる前でも構わかい。そのことが@③開 発チームの活動を改善することにつながると思う。”と述べて,ミーティングを終え た。

共通の文章

プロジェクトの進捗管理及びテスト計画に関する次の記述を読んで,設問ユン3に 答えよ。 不動産会社のD社は,H社のソフトウェアパッケージ(以下,H社パッケージと いう)に一部機能を追加開発した人事給与システム(以下,現行人事給与システム という)を10年前から利用している。H社パッケージの現行バージョンは保守期限 が括っつている。また.,現行人事給与システムが対応しじていない出退勤管理業務,休 暇・残業申請業務などに対する社員のシステム化ニーズは強い。これらの点を考慮 UT,D社経営陣は現行人事給与システムを刷新することにした。 人事部が中心となって要件定義を行い,RFPを提示して複数のベンダから提案を 受けたところ,S社のソフトウェアパッケージ(以下,S社パッケージという)が要 件への適合度が最も高く,他社で多くの導入実績及び類似の追加開発実績を有して いた。経営陣は,S社パッケージに一部機能を追加開発する人事給与システム(以下, 新人事給与システムという)の外部設計,移行ツールの設計・製造・テスト,デー タ移行及び総合テストを準委任契約で,内部設計,追加開発の製造・単体テスト MATA,S社パッケージの設定・テストを請負契約でS社に委託することを決定 LK.EK,現行人事給与システムの利用者は人事部だけであったが,新人事給与 システムでは出退勤管理業務,休暇・残業申請業務などのシステム化によって人金社 員が利用者となる。そこで,操作マニュアルの作成,及び全社員を対象とする操作 説明会を行う利用者トレーニングもS社に準委任契約で委託することにした。 S社は,新人事給与システム設計・開発プロジェクトのプロジェクトマネージャ (PM)に課長を任命した。T課長は新人事給与システム設計・開発プロジェクト 計画を立案し,D社経営陣の承認を得た。スケジュールは図1に示すとおりである。 ー13一 月数|1|2|3|4|5|6|7|8|9|10| 人/frm有H社パッケージ保守期限 e外部設計内部設計追加開発の結合総合|受入 Ls||アル作成int 4 S社パッケージの設定・テスト操作マニュ|利用者 M1スケジュール 本プロジェクトは,H社パッケージの保守期限までに確実に新人事給与システム を稼働させる必要があること,及びH社パッケージからの切替えであり,利用者ト レーニングを十分に行う必要があることから,遅延は許されない。そこで,T課長は EVM(Earned Value Management)手法を用いて進捗を定量的に可視化して管理する ことで遅延りスクへの対応を行うことにした。また,D社の経営陣に少なくとも月1 回開催するプロジェクト全体会議で進捗状況,リスク及び課題を報告し,対応策を 確定させることにした。 [外部設計の進捗状況] 外部設計は人事外部設計チーム,給与外部設計チームの2チーム体制とし,8週間 で実施して,工程完了時点で仕様を凍結する。S社は外部設計書として,D社の要件 定義を踏まえS社パッケージの標準画面及び標準帳票を参考にして,処理フロー図, 画面仕様,帳票仕様,利用者別処理権限表などを作成する。その上で,D社との仕様 検討の際に,S社パツッケージによって実現する機能については,外部設計書による説 明に加え,S社パッケージの標準画面のデモンストレーションや標準帳票の記入例の 提示を行う。一方,追加開発で実現する機能こついては,外部設計書だけで設計内 容を説明する。 各チームは機能単位でAC(Actual Cost),EV(Earned Value)を整理しており,T 課長は各チームから週次でAC,EVのチーム集計結果,リスク・課題状況と翌週の 作業予定の報告を受け,進捗状況などを確認している。外部設計を開始してから3 週間経過時の進捗報告で,人事外部設計チームのリーダから,クリティカルパス上 an eh uz の作業ではないが一部機能の設計が遅れているので,この機能を含めて各機能の作 業に投入する工数を調整し,遅延を回復させたいという相談があり,T課長はこれを 承認した。3週間経過時及び4週間経過時における,EVMの実績に基づく進捗報告 は表1に示すとおりである。 表1進捗報告(外部設計全体) 単位FY | 注”BAC:Budget At Completion PV:Planned Value T課長は,表1からプロジェクト全体としてはおおむね計画どおりに進んでいると 判断できるが,3週間経過時及び4週間経過時の報告内容を勘案すると,人事外部設 計チームに関しては,各機能の作業状況を具体的に把握した上で,状況によっては 課題を特定して対応策を検討し,プロジェクト全体会議でD社と対応策を確定させ る必要があると考えた。人事外部設計チームは,機能1から機能4に分けて設計し ていることから,T課長は,人事外部設計チームのリーダに,それぞれの機能の作業 状況について報告を求めた。 〔人事外部設計チームの進捗状況 T課長が確認した,人事外部設計チームの各機能の作業状況は次のとおりであった。 機能1から機能3まではS社パッケージによって実現する機能である。機能Id, 最も作業工数を要する機能であり,プロジェクト計画においてクリティカルパス上 の作業であるが,現時点では計画どおりに進んでいる。機能2はS社パッケージの 標準画面及び標準帳票をそのまま利用する仕様となったこともあり,作業は当初計 画よりも進んでいる。機能3はS社パッケージの標準画面及び標準帳票からの変更 内容が明確であり,計画どおりに仕様検討が行われ,作業が進捗している。 機能4は現行人事給与システムでは未対応であり,全社員が利用者となる休暇・ ー15一 残業申請業務のシステム化をS社パッケージに対する追加開発で実現するものであ Be S社は他社で本機能に関する類似の追加開発実績を有しており,その知見を生か して設計を行っている。現時点ではクリティカルパス上の作業ではない。D社人事部 の仕様検討担当者(以下,D社担当者という)は,本業務について現行の紙を用いた _処理方法は具体的に理解しているが,システム化した処理方法のイメージが十分に もてておらず,詳細作業手順,作業条件,例外作業の処理方法などの理解が不十分 である。このため,S社外部設計案に対するD社担当者の意見は,紙を前提とした 処理方法に基づくものでありS社外部設計案と比較してシステム化する上で優位性 がない仕様であったり,仕様内容に不明瞭な点や整合性に欠けるところが残るもの であったりする。D社担当者の意見を生かしつつ当該機能の仕様を確定させるには時 間が掛かる。仕様確定の迅速化に向け,作業に投入する工数を計画よりも増加させ たが,遅延の解消に至っていない。 なお,外部設計工程では,品質・コスト・スケジュールに影響を与える事象を課 題管理対象として扱っており,仕様確定に手間取った箇所もその都度,課題管理表 に記録している。さらに,課題管理表を週次で整理して未決事項一覧表を作成し, 未決事項の検討内容や仕様の確定状況そモニタリングしている。 作業状況を確認したT課長は,人事外部設計チームの進捗状況を適切に管理する ために,機能単位でEVMの実績及びクリティカルパスを明示した進捗状況の報告を 受けることにした。報告を受けた機能単位のEVMの実績に基づく進捗報告は表2に 示すとおりである。 表2進捗報告(人事外部設計チームの機能単位) 単位千円 Os|S ae ee Oa Fg|O|swl YY kgm|aem ratte||umm|ao|iaw|ime|il rl re Paar||0|asso]asso]45|6050|soso|seel =- 機能4の4週間経過時のSPI(Schedule Performance Index)は|saとなっ THY,T課長は各機能の作業に投入する工数の調整だけでは対応策として不十分で あると判断した。そこで,プロジェクト全体会議において,T課長は|b|を 用いて仕様の確定が進んでいないことを報告し,D He S社は,D社のある状況が 仕様確定に時間が掛かっている原因であるという共通認識をもった。その上で, EVMの実績の推移及びEAC(Estimate At Completion)を用いて進捗遅れの問題が顕 在化していることを報告し,マイルストーンである仕様凍結日の遵守に向けてD社 にも対応を要請することにした。 さらに,課長は,仕様確定を迅速に進めるためには,D社担当者がS社の外部設 計内容を,システム化した処理方法として適切かものであると容易に判断できるよ うにすることが重要であると考えた。そこで,T課長は,人事外部設計チームに対し て,現行人事給与システムで対応していない機能を追加開発する際の外部設計書に 関しては,他社での類似の追加開発実績を活用して,ある補足資料を作成し,それ も用いて外部設計内容の説明を行うように指示した。そして,引き続き機能単位の EVMの実績などを用いた進捗管理を行い,今後の外部設計期間中に,もし週次の進 捗報告からゆある状況になったことが判明した場合は,S社の設計要員を追加投入し て遅延の回復を図る対応策の検討や調整も行うことにした。 〔テストに関する施策の追加] T課長は,人事外部設計チームの作業状況から,本プロジェクトに潜在する品質リ スクを勘案し,次に示す二つの施策をテストエ程で実施することをD社に提案した。 ①総合テストのテストケース作成に,外部設計時に用いた課題管理表を活用する。 ②利用者トレーニングにおいて,操作説明会に加え,全社員を対象にトレーニン グ用のデータを使って一連の業務を実行する試行運用を追加する。さらに,試行 運用結果を踏まえて| c|の記述を充実させ,本稼働後に,利用者が業務・ システムについての不明点を自身で解消できるようにする。