私が、プロジェクトマネージャ試験に合格したときの論文です。
思い出しながら書いたので、まったく同じではありませんが、参考になればと思います。
内容はフィクションですのでご安心ください。
合格したときの記事はこちらです。
https://hazukei.com/zakki/1559/
問題文
未経験の技術やサービスを利用するシステム開発プロジェクトについて
設問ア：あなたがかかわった新技術を利用したシステム開発プロジェクトにおけるプロジェクトとしての特徴、システム要件、及びプロジェクトへの要求事項について、800時以内で述べよ。
設問イ：設問アで述べたシステム要件とプロジェクトへの要求事項について、検証フェーズで実現性をどのように検証したか。検証フェーズで得た情報を開発フェーズの計画の更新にどの様に活用したか。また、ステークホルダの理解を得るために行ったことは何か。800字以上、1,600字以内で具体的に述べよ。
設問ウ：設問イで述べた検証フェーズで検証した内容、及び得た情報の活用について、それぞれの評価及び今後の改善点を、600字以上、1,200字以内で具体的に述べよ。
回答
１．私が関わった新技術を利用したシステム開発プロジェクトに関して
１．１．プロジェクトの特徴
私が関わったプロジェクトは、衣料品を販売するA社の商品管理システムの再構築である。A社は全国に100店舗以上を展開する衣料品小売り事業を展開しており、近年ではECサイトでの販売にも力を入れている。
A社では商品をメーカーから仕入れているが、その情報はエクセルファイルでメーカーからＡ社の商品担当者に連携され、Ａ社の商品管理システムに取込み、追加入力を行っている。システムは10年以上前に構築されたレガシーなものであり、この度、ECシステムへの登録情報も含めて再構築することとなった。
プロジェクトの規模は30人月で私はPMとして参画した。
１．２．システム要件、及び、プロジェクトの要求事項
システム要件としてはA社担当者の手間を減らすため、メーカーが直接システムに商品情報を登録できるWebシステムであること、商品情報登録画面に加え、それに付随する色や種別など十数個のマスタの管理機能を作成することなどがあった。
A社の情報システム部がプロジェクトを主導していたが、要求事項として主に下記の3つがあった。
①商品情報は機密性が高いためセキュリティには注意が必要である。
②商品担当者は現在の商品画面に慣れ親しんでおり、変更することに抵抗がある。使いやすくするための要望や、仕様がFIXするまでに、何度も修正をお願いする可能性がある。
③開発コストをなるべく安く抑えたい。
２．検証フェーズでの実現性検証と開発フェーズ計画への利用、及び、ステークホルダの理解を得るために行った事
２．１．新技術活用の概要
今回の要求事項を達成するための、新技術としてプログラム自動生成ツールを利用することを検討した。ツールはリレーショナルデータベースのDB定義書をインプット情報として、対象となるデータの登録画面、検索画面を自動生成するというものである。
プログラムを自動生成することで、スクラッチ開発に比べ大幅にコストを削減することができ、プロジェクト初期の段階で動く画面を提供できるので、利用者と仕様の認識合わせをする際に有効であると考えた。
２．２．検証フェーズでの実現性検証
検証フェーズでは、ツールの資料を参照し、プロジェクトで利用できそうかを確認したのち、ツール開発元から、エンジニアを派遣してもらい、実際に動作するサンプル画面を出力してもらい、それを元に検証を行った。
検証のポイントは下記3つとした。
①機能要件を満たすか
ログイン機能を利用できるか等、デフォルトの出力で機能要件をどこまで満たせるかを検証した。
②非機能要件を満たすか
サンプルで作成したテーブルに実際に顧客が想定している件数のデータを登録して、検索、登録にかかる時間がどれくらいになるかを確認した。
③セキュリティ要件を満たすか
出力されたソースコードを、自社でもともと利用しているセキュリティチェックシートと照らし合わせて、どの程度基準をクリアしているかを確認した。
２．３．開発フェーズ計画への利用
検証の結果から、ツールの自動出力後にどの程度の追加開発が必要であるかを確認し、開発工数の見積もりを行った。また、セキュリティ要件に関して、満たせていないものの対応が追加開発で実施できることを確認した。
非機能要件に関してはおおむね問題ないことを確認できたが、商品登録画面では、登録項目が膨大になることに加え、検索条件も複雑になることが予想されたため、開発フェーズの初期段階でツール出力した画面を利用して確認する計画とした。
２．４．ステークホルダの理解を得るために行った事
ツールを利用した際の工数見積もりを、実際にスクラッチ開発を行ったときと比較してコストメリットを具体的に理解いただいた。また、早めに動作する画面が出力できることで利用部門との仕様決めをスムーズにし、認識違いを減らせる事、非機能要件の確認が初期段階で行えるなど開発を進めるうえでのメリットをまとめて連携した。
セキュリティに関しては、検証で見つかったセキュリティの問題を追加開発で対応するとしたうえで、必要であれば外部のセキュリティテスト専門の企業にテストを依頼することとし、テストの対応範囲と、あらかじめ取得しておいたテストの工数見積もりを提示した。
３．検証フェーズ検証内容、得た情報の活用に関する評価と今後の改善点
３．１．検証内容と得た情報の活用に関する評価
機能要件の確認に関しては、必要となる開発内容を明確に確認できたことで、正確な見積もりを行うことができ、実際の開発工数とほとんど差異が発生しなかった。また、出力した画面をユーザーに使ってもらうことでユーザーの要望を効率よく吸い上げることができ、認識違いもほとんど発生しなかった。顧客とやり取りした画面デザインをそのまま開発に利用することで工数を削減できたことも良かった。
非機能要件の確認では、画面を出力した段階で、本番利用と同程度のデータを投入してテストする計画を承認いただき、実施した。結果として複数の問題が見つかったが、開発初期の段階であった為、十分に対応することができた。
セキュリティテストに関しては、自社基準のセキュリティチェックシートと比較して、必要な対応を明確化することができ、有効であった。外部のセキュリティテストサービスもあらかじめ調査、見積もり作成を依頼し、顧客に提供することで、スムーズにプロジェクトを進めることができたと評価いただいた。
３．２．今後の改善点
ツール検証の段階で、プログラム出力作業を実施した為で、他のプロジェクトと比較して要件定義フェーズの工数が膨らんでしまった。ツールの利用が有効であることが分かったので、今回のナレッジをまとめ社内に展開することで、後発プロジェクトの利用促進につなげていきたい。
ツールで出力したプログラムは、若干複雑な部分があり、機能改修を行う際に通常よりも多く工数がかかるという事があった。次回以降に新技術を検証する際は、開発が完了した後の、保守、運用工数にも着目して検証を行う必要がある。
