自分が過去問を解いたときのネタ、要点を記載。
【平成３０年問１】非機能要件に関する関連部門との連携について
プロジェクトの概要と特徴、非機能要件
プロジェクトの概要と特徴
・T社の商品情報登録画面の再構築。
・全システムは10年以上前に構築されたもの。
・商品情報の登録項目は100を超え、複雑である。
・商品情報の一部をベンダーに入力してもらうことで、T社社員の負荷軽減となる。
・複数のシステムで管理していた情報を1つの画面にまとめる。
非機能要件と関連部門との連携で注意する点
・ユーザーの業務効率に直結するため、商品情報登録画面のユーザビリティは非常に重要な非機能要件項目である。
・関連部門は、画面を利用するユーザー部門。長年、旧システムに慣れ親しんだユーザーからは大幅なシステムの変更に抵抗の声もある。
非機能要件に関して、関係部門と連携するために行った取り組みについて
関係部門と業務について
・商品情報登録画面は、T社の全社員が利用するが、中でも商品情報を扱う部署のユーザーが登録を行いやすいようにと考えた。
実施した取り組み
・ユーザー部門の各セクションから代表者を選出してもらい、プロジェクトに協力してもらう。
・現行画面の情報収集。現行の登録項目の仕様と、実際に登録している場面を動画撮影してもらい提供してもらった。入力する順番や、入力にかかる時間を確認する。
・デモ画面の作成。実際に動くデモ画面を作成し、ユーザーにフィードバックをもらいながら改善を行った。週次で改善点の説明と、要望、意見のヒアリングを実施。
・操作レクチャーの実施。ユーザーの業務ごとに操作マニュアルを作成した上で、複数回に分けて操作レクチャーを実施した。
実施結果の評価、今後の改善点
評価
・情報収集を事前に行ったおかげで大きな問題は無し。
・デモ画面でやり取りしたおかげで、後工程で認識の齟齬はほとんど発生しなかった。
・レクチャーを行ったおかげで、本稼働時にも大きな混乱はなかった。
改善
・デモ画面作成に参加しなかったユーザーからは、本稼働後に画面の改善要望が多く寄せられた。これらのユーザーの意見をどのように吸い上げるか検討が必要。
・操作レクチャーはT社社員のみを対象としており、ベンダーには実施しなかった為、一部のベンダーから戸惑いの声もあった。ベンダー向けにデモ画面を開放するなどの改善が必要。
【平成３０年問２】本稼働間近で発見された問題への対応
プロジェクトの特徴と、本番稼働間近で発見された問題について
プロジェクトの特徴
・TS社。
・巨大プロジェクト、リリース日必達。
本番稼働間近で発見された問題について
・システムのデモ環境で、稼働後の業務を確認してもらっていた営業部員複数名から問題提起あり。
・問題点①：業務情報の登録画面で必要な項目が不足している。
・問題点②：収支画面で業務上必要な情報が参照できない。
現状の状況把握と影響の分析、暫定対応について
問題の状況把握と影響の分析
・関係者を集めて打ち合わせを実施。参加者は、プロジェクト全体のPM、PL、プロジェクトメンバーの営業部員、問題提起のあった営業部員（複数名）、開発担当者。
・ミーティングでは、2つの事を明らかにした。問題の具体的な内容と、業務への影響。問題が発生した原因と責任の所在。
・何らかの対応が必要であることと、顧客側の情報連携不備が問題発生の原因ということを確認。
暫定対応の策定
・本稼働までに利用できる時間と工数を確認。
・問題点①の業務上必要な項目が無い問題⇒恒久対応が完了するまでは、自由記入の備考欄を代替として使ってもらう。
・問題点②の収支画面に必要な情報が無い問題⇒月次でデータ抽出を行い提供する。
・関係者を集めて対応の説明を実施。
対応策の実施状況と評価、今後の改善点について
対応策の実施状況と評価
・問題発生の初期段階で、関係者を集めてミーティングを行ったのは良かった。全体PLからも評価いただいた。
・問題点①の暫定対応は問題なし。
・問題点②の暫定対応は、月次でのデータ抽出を想定していたが、リアルタイムの情報が必要とのことで却下。残された期間での機能追加は不可能であったので、データ抽出用のツールを作成することとなった。
今後の改善案
・問題点②で策定した暫定対応では、取得する情報は月次データで問題なかろうという思い込みがあった。要件として確認すべきポイントを事前に整理しておく必要があった。
・今回はたまたま関係者にすぐに集まってもらえたが、毎回対応いただけるとは限らない。状況を正確に伝えられる代理者の参加や、オンラインでの参加など検討の余地あり。
【平成３１年問１】コスト超過の防止について
プロジェクトの特徴とコスト管理について
プロジェクトの概要と特徴
・N社のブックマークサイトリニューアルプロジェクト
・古いソースコードのトレースが必要
・JavaScriptを多用するサイト
コスト管理の概要
・売上高と開発期間から要員計画を作成し、月ごとのコストを設定。
・月次で会社から連携される実コストと計画値の差分を確認。
・計画コストで許容される要因の残業時間を確認し、日時の実績値と大きな差が無いかを注視。
コスト超過の懸念と対策
コスト超過の兆候と、コスト超過につながると懸念した根拠
・懸念①、JavaScriptのスキルがあるS氏がプロジェクトに参画していたが、想定よりもJSの難易度が高く、スケジュール遅延が発生。JSの対応コストが計画値の2倍となっていた。
・懸念②、開発メンバーからブックマーク機能のレスポンスが遅いと報告があった。今回のリニューアルで一度に複数のブックマークを行う機能が追加されており、プロジェクト完了間際での仕様変更が発生した場合、手戻りによる大きなコスト超過につながると考えた。
コスト超過を防止する対策
・①の対策として、JSスキルを有する別プロジェクトのメンバーの稼働を一部借りるように調整。
・②の対策として、ステージング環境での負荷テストを前倒しで実施することを顧客と調整。
対策の実施状況と今後の改善点
対策の実施状況と評価
・F氏はプロジェクト参画ではなく、外部アドバイザーとして協力してもらった。新たなコストを発生させずにスケジュール遅延は回復した。
・ステージング環境での負荷テストの結果、仕様変更が必要であることがわかり対応した。開発段階であったので修正コストは軽微であった。
今後の改善点
・社内でスキルシートを作成し保有するスキルを整理しておく。
・メンバーを追加した場合としない場合で、最終的なコストはどちらが高くなるかという、判断基準、もしくは資料があると良い。
【平成３１年問２】助言やほかのプロジェクトの知見などを活用した問題の迅速な解決について
プロジェクトの特徴、及びプロジェクトの内の取り組みだけでは解決できなかった問題
プロジェクトの特徴
・N社のブックマークサイトリニューアルプロジェクト
・開発されてから時間が経過しており、ソースコードが複雑化している。
・使用しているAPIで資料が残っていないものも多い。
・JSを多用している。
プロジェクト内の取り組みでは解決できなかった問題
・既存のソースコードの読み込みと、複雑なAPIに苦しめられ、スケジュールが遅れ気味となった。
・プロジェクト終盤で、大きな不具合と、速度面の問題が発覚し、スケジュールのリカバリが困難な状態となった。
・サイトリニューアルを告知しているため、スケジュールの後ろ倒しはできないと思われる。
解決に役立つ観点や手段を見出すための参考プロジェクト、有識者特定のための分析と見出した手段を活用しての問題への取り組み
解決に役立つ観点や手段などを見出す参考プロジェクトの特定、及び助言、知見を得るための分析
・対応策①、社内のプロジェクト完了報告書の確認。
・対応策②、プロジェクト定例会での相談。
・①に関して、本プロジェクトと同じような規模のプロジェクトの収支資料を参照し、終盤で残業などのコスト増の為収支が悪化したものをピックアップ。プロジェクト完了報告書を参照し、問題にどのように対処したかを確認。
・②に関して、問題の要点と具体的な数値を整理し、隔週で開かれるプロジェクト定例会議の場で問題を報告し、他のPMから物アドバイスをもらう。
問題解決に役立つ観点、手段を活用しての問題解決への取り組み
・①で得られた解決策として、スキルの高い人員の追加、スコープの変更があった。
・スキルの高い人材は適当な人間が見つからず利用できなかった。スコープの変更は一部機能を2次フェーズとして対応させてもらえるように相談することとした。
・②では、N社と同じようなベンチャー気質のWebサービス提供企業に長年常駐した経験のあるH氏からアドバイスをもらえた。
・H氏の過去の現場では、本番稼働直前にスケジュールが間に合わないといった問題が割とよくあり、対応方法としては、スコープの変更、作業場所を客先に移しての業務効率化を行ったとのことであった。
・作業場所を客先に移すことで、APIはスタブではなく顧客開発環境の実際に動くものを利用でき、不明点はすぐに質問することで、大幅な効率化が期待できるとのことであった。
問題解決の有効性の評価、及び今後の改善点
問題解決の有効性の評価
・スコープの変更と、N社内での開発作業が認められた。
・リニューアル前のサイトに詳しい人物と、API、JSの技術面に詳しい人物がサポートしてくれることとなり、作業効率が劇的に改善した。
・何とか予定通りの日程でリリースすることができた。
今後の改善点
・プロジェクト完了報告書を参照する際に、目的のプロジェクトを見つけるまでに時間がかかったので、サマリ情報を充実させる等、検索しやすくする工夫が必要であると考えた。
・プロジェクト完了報告書では、具体的な解決手段や、問題解決への定量的な記載が少なかった。今後は後発プロジェクトの参考になるような記載方法についても提案していきたいと考えた。
