- プロジェクトマネージャ試験のステークホルダのの午後Ⅱ演習
- IPA公表の出題趣旨
- 問 システム開発プロジェクトにおける非機能的要件に関する関係部門との連携について
- 設問ア あなたが携わったシステム開発プロジェクトの特徴、代表的な非機能的要件の概要、並びにその非機能的要件に関して関係部門と連携を図る際に注意を払う必要があった点及びその理由について、800字以内で述べよ。
- 設問イ 設問アで述べた代表的な非機能要件に関し、関係部門と十分な連携を図るために検討して実施した取組みについて、主なタスクの内容と関係部門、及び関係部門との役割とともに、800字以上1600字以内で具体的に述べよ。
- 設問ウ 設問イで述べた取組みに対する実施結果の評価、今後の改善点について、600字以上1200字以内で具体的に述べよ。
プロジェクトマネージャ試験のステークホルダのの午後Ⅱ演習
を読んでインプットした内容を、要点を引用したり、重要だと思った点を要約したり、
私の感想や考察することで、このブログでアウトプットしようと思います。
の「午後Ⅱ演習 」の紹介された平成30年度 問１の問題を紹介します。
の回答内容は、から、より具体的な内容になるように修正しています。
IPA公表の出題趣旨
まず、演習問題の前に、IPA （独立行政法人 情報処理推進機構）公表の出題趣旨をを紹介します。
プロジェクトマネージャ（PM）は、機能要件に加えて、
非機能要件についても確実に要件が満たされるようにマネジメントしなければならない。
そのためにPMは、非機能要件に関して、利用部門や運用部門など関係部門との連携に注意を払った上で、
関係部門と協議しながら、関係部門を巻き込みながら一体となってプロジェクトを推進しなければならない。
本問は、非機能要件に関して、WBSの各タスクの内容を関係部門と定め、関係部門と役割を明確にして、
関係部門と十分な連携を図るためのと取組みを検討することなどについて、
具体的な論述することが求めている。
論述を通じて、PMとして有すべき、非機能要件に関して、関係部門と十分に連携を図りながら推進することについての知識、経験、実務能力などを評価する。
問 システム開発プロジェクトにおける非機能的要件に関する関係部門との連携について
システム開発プロジェクトにおいて、プロジェクトマネージャ（PM）は業務そのものに関わる機能要件に加えて、可用性、性能などに関わる非機能的要件についても、確実に要件が満たされるようにマネジメントしなければならない。
特に非機能的要件については、利用部門や運用部門など（以下、関係部門という）と連携を図り、
その際、例えば、次のような点に注意を払う必要がある。
・非機能的要件が関係部門にとってどのような意義を持つのかについて関係部門と認識を合わせる。
・非機能要件に対して関係部門が関わることの重要性について関係部門と認識を合わせる。このような点に注意を十分に払われないと、関係部門との連携が不十分となり、システム受入れテストの段階で
不満が続出するなどして、場合によっては納期などに大きく影響する問題になることがある。関係部門と連携を図るにあたって、PMはまずプロジェクト計画の段階で、要件定義を始めとする各工程について、非機能要件に関するWBSを設定し、WBSの各タスクの内容と関係部門を定め、関係部門との役割を明確にする。
次に、関係部門と十分な連携を図るための取組みについて検討する。
それらの内容をプロジェクトに反映した上で、関係部門を巻き込みながら
一体となったプロジェクトを推進する。
あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。
設問ア あなたが携わったシステム開発プロジェクトの特徴、代表的な非機能的要件の概要、並びにその非機能的要件に関して関係部門と連携を図る際に注意を払う必要があった点及びその理由について、800字以内で述べよ。
プロジェクトの特徴と代表的な非機能要件
1.プロジェクトの特徴
私は、SIベンダに勤務するプロジェクトマネージャである。今回、自動車部品メーカA社の「生産管理システムの再構築プロジェクト」を担当することになった。
これは、工場の中枢である基幹システムをメインフレームからオープン系へ全面再構築するという
大規模プロジェクトであった。開発期間は４月から翌３月末の12か月、経営者からは
年度が替わる4月1日本稼働必達を強く要求されていた。
プロジェクト全体を通じてスケジュールに余裕（バッファ）がなく、納期必達のために、A社の情報システム部とユーザー部門である
生産管理部が一致団結し、総力を挙げて、開発に邁進する必要があった。
2.代表的な非機能要件
納期遵守に加えて、ユーザーからは、現在、毎日、業務停止して、深夜に実行している
資材所要量計画（ＭＲＰ）実行のバッチ処理を、労働時間削減のために業務時間中に実施したいと要望を受けている。
もちろん、入力業務のレスポンスに影響がないことも要件である。
メンバが現状の性能、処理時間を整理して、利用部門と協議、合意したのはMRP実行のバッチ処理を
3時間以内に終了させること、その間の入力業務、特に作業量が多い受発注の入力業務に影響がないことを
担保することであった。
3.関係部門との連携
MRPのバッチ処理は、これまで通りA社の情報システム部門だが、業務の影響を受けるのは生産管理部、営業部になる。
バッチ処理を実施ししている間、一部のデータ更新ができなくなるなど、
運用が変わる部分があり、そういった制約、その理由を生産管理部、営業部に説明し、
業務時間中の入力スケジュールを決めて、そういった制約が問題にならないようにした。
設問イ 設問アで述べた代表的な非機能要件に関し、関係部門と十分な連携を図るために検討して実施した取組みについて、主なタスクの内容と関係部門、及び関係部門との役割とともに、800字以上1600字以内で具体的に述べよ。
2.関係部門と十分な連携を図るために検討して実施した取組み
(1)先行開発（６月１日～７月３１日）
まず最初に私が考えたのは、経営トップの意向でもある労働時間短縮に寄与するための業務時間内に行うＭＲＰバッチ処理の性能確保である。
性能要件として、生産管理部と話しあって決めたのは３時間だ。
昼の１時から４時まで、生産管理部では一部の業務をストップさせることで、この処理を実現する。
したがって、この３時間以内に実行できる設計にしなければならない。
バッチ処理の性能確保は、ＤＢ設計次第の部分が大きい。にもかかわらず、
全てのテーブル設計を終えて、内部設計、プログラミングと進めていく流れでは、
単体テストベースでこの処理の性能テストを行うのは、早くてプログラミング工程に入る９月以降になる。
そこで、ＭＲＰの部分だけアジャイル開発を取り入れて先行開発することにした。要件定義が完了する6月1日から、MRPの部分のテーブル設計とプログラミングを、単体テストを独立して実施する。2か月間で性能試験とチューニングを行いながら繰り返す。
その場合、必要なテストデータを情報システム部に準備してもらう必要がある。また、生産管理部に関しても性能確保のために譲歩してもらう必要がある。そこで、６月からの２カ月間は、毎週金曜日の夕方に定例会を開催し、そこに参加してもらうことで合意した。
(2)データベース設計（６月１日～６月３０日）
生産管理システムのうち、ＭＲＰ以外の部分のデータベース設計は、６月の１月で実施する予定にしている。そこでは先行開発しているＭＲＰの部分と整合性を取りながら進めていく必要がある。そこで、この間、毎週１回、ＭＲＰ先行開発チームと生産管理システムとで連絡協議を実施して、整合性を図ることにした。
この時に、トレードオフになる部分が発生する可能性があるので、現行システムに詳しい情報システム部の方に参加してもらうことになった。
(3)システム適格性確認テスト（１月初旬から２月末）
ＭＲＰ単体で稼働させた時に性能が確保されることが確認できれば、続いて、他の入力処理に影響があるかどうかを確認する必要がある。
単体テスト段階で、疑似的に負荷をかけて確認し、結合テスト段階でも、デッドロック等の不具合を確認するので、机上の計算では問題ないことをある程度は確認中できている。
しかし、最後の負荷試験はシステムが一通り完成してから、
より、日常に近い運用で試験を実施し、問題ないことを最終確認する。
幸い、今回はオープンシステムへ移行するので、ハードウェアは全面入替になる。したがって、システム適格性確認テストでは本番環境を利用して試験ができる。
そこで、Ａ社社長に事情を説明して、12月からハードウェアの搬入と環境設定をはじめ、1月のシステム適合性確認テストで本番環境を利用するために、約3カ月早めのハードウェア導入を許可してもらった。
その上で、１月の毎週土曜日（Ａ社の休日）に、前日分のデータを入力してもらいながら、バッチ処理を実施する試験を行うことにした。そのためには営業部門の協力が欲しいと考えた。
そこで、休日出勤が必要になることから、その意義や効果を説明し、許可してもらった。
設問ウ 設問イで述べた取組みに対する実施結果の評価、今後の改善点について、600字以上1200字以内で具体的に述べよ。
実施結果の評価、及び今後の改善点
プロジェクトは予定通り4月1日から開始された。先行開発の部分は、データベースに強いエンジニア２名が常に情報交換しながら最適な設計を進めて、想定している最大のデータ量の時でも３時間以内にバッチ処理が完了することを確認できた。
また、６月からの本流との連携会議でもうまく連携しながら進めることができた。
特に良かったのは、A社の関連部門の方々との会議を週１回と決めていたことだ。実際に、生産管理部門や情報システムの関連業務の担当への依頼事項もあり、質問もあった。
もしも予め会議の場を設定しない場合、依頼、質問のタイミングが遅れ、その内容の説明や情報量が、十分でなかった可能性が高く、回答のタイミング、その情報量も十分でなかった可能性が高い。その結果、アジャイル開発の進行や最終的には納期に影響が出てきた可能性がある。
また、システム適格性確認テストでは、本番環境を前倒しで導入してくれたA社社長の英断と、１月の休日に協力してくれた営業部門と方々とのおかげで、十分な試験をすることができた。
そうしたことで、本番稼働も予定通り、4月から開始でき、日常の入力業務にも影響がなく、無事、バッチ処理も業務時間中にできるようになった。結果、このプロジェクトの最大の目的である労働時間短縮にも成功している。
今後の改善点
今回、必要だといえ、現場の方々に休日出勤をはじめ、この１年間大きな負担を強いることになった。毎週１回何かしらの連携を取っていたが、中には、特に問題も無く、順調で集まる必要も無かった時もあった。
また、週１回の会議があったから、それ以外の連絡インタフェースを持たなかったら、会議で初めて議題が上がり、その会議中に考えることも多く、効率が悪い点もあった。
今後は、掲示板等を活用して、問題や質問が発生した時点でそこでアップし、会議よりも効率よく会議を開催したいと考えている。
以上
以下は第１章のステークホルダです。
第１章 ステークホルダ
1. ステークホルダ
1.1 基礎知識の確認
1.2 午後Ⅱ 章別の対策
1.3 午後Ⅰ 章別の対策
1.4 午後Ⅱ 章別の対策
午後Ⅰ演習
午後Ⅱ演習
