午前Ⅱ（論文）対策。過去問題を使って、解法の流れを確認していくシリーズ、行きましょう。今回は令和２年（20220年）の秋試験から、プロマネ午後Ⅱの問１です。
こんにちは！セイジュン＠エンジニア応援隊(@39Seijun)です。論文の解法については、こちら午後Ⅱ対策でまとめました。今回は、ちょっとさかのぼります、令和２年（２０２０年）の問題でプロット作成をやってみます。今回も、「皆さんの学習の参考（半面教師）」になりましたら。
タイトルは「未経験の技術やサービスを利用するシステム開発について」です。使ったことのない技術・サービスの利用、しかも個人（わたし・あなた）ではなくてプロジェクト全体にとって、という問題です。技術は日進月歩であると同時に、どんどん細分化されていていきます。なかなか枯れた技術だけではサービスを組み立てられない昨今では、この問題も実際に「あるある」ですね。
では、いつも通り、先に設問ア~ウを抜粋、確認していきましょう。
設問イ 設問アで述べたシステム要件とプロジェクトへの要求事項について、検証フェーズで実現性をどのように検証したか。検証フェーズで得た情報を開発フェーズの計画の更新にどのように活用したか。また、ステークホルダの理解を得るためにおこなったことは何か。８００字以上、１，６００字以内で具体的に述べよ。
設問ウ 設問イで述べた検証フェーズで検証した内容、及び得た情報の活用について、それぞれの評価及び今後の改善点を、６００字以上１，２００字以内で具体的に述べよ。
さて、問の本文を読む前に、論文の骨組み（プロット）を、設問ア~ウに沿って作成してみましょう。設問での文字数指示から凡その文字数も補記してみます。
１．私が携わった新技術を活用したシステム開発プロジェクト・・・設問ア（８００字以内の指示に応える）
１．１．プロジェクトの特徴（２５０字）
１．２．システム要件（２５０字）
１．３．プロジェクトの要求事項（２５０字）
２．検証フェーズでの実現性評価・・・設問イ（８００字以上１，６００字以内の指示に対して、１，２００字を想定）
２．１．検証フェーズでの実現性評価（４００字）
２．２．開発フェーズへのフィードバック(４００字）
２．３．ステークホルダへの対応（４００字）
３．検証内容と情報の活用についての評価と改善点・・・設問ウ（６００字以上１，２００字以内の指示に対して、８００字）
３．１．評価（４００字）
３．２．改善点（４００字）
どうでしょう。凡そのバランス、こんな感じではないでしょうか。
ポイントとして、「新技術・サービス」をどこで触れるか、です。設問ア～ウの中で「新技術」について記載されているのは、設問アの冒頭にあるだけ。やっぱり１．１の「プロジェクトの特徴」に、その特徴の関連として「だから〇〇という新技術を活用した」と書くのが自然なのでしょうね。
では設問とプロットの仮設定はこのくらいで、問い本文をざっと見ていきましょう。
本問は冒頭、結論・出題の主張ではなく、単なる事象の説明でさらっとスタートしています。曰く「PMは、システム化の目的を実現するために、組織にとって未経験の技術やサービスを利用するPJをマネジメントすることがある」。
次のパラグラフで、未経験の技術に対する対応について、その方法論を語っています。
・実現性を評価することが必要
・そのために、開発フェーズに先立って検証フェーズを設ける
・検証内容はステークホルダと合意
・検証フェーズのアウトプットは、品質目標の設定・開発フェーズの期間やコストの見積
・結果によって、開発フェーズの計画を見直し
そして、最終パラグラフでは、
・検証結果の評価
・システム要件やPJへの要求事項の見直しも、ステークホルダとの協議如何によってアリ
ざっくりまとめると以上が問いの本文の論旨展開です。
未経験の新技術に対する対応方法が、丁寧にまとめられています。また、設問ア~ウに従って作成したプロットとも対応していますね。
では、本問のポイントを２点、考えてみましょう。
①新技術・サービスを（論文の書きやすさを考慮しながら）何に設定するか？
②実現性の評価の内容をパッと3~５個、浮かぶか？
まずは①新技術・サービスを何にするか？です。
インフラ、クラウド、ネットワーク、開発言語、開発ツール、データベース、プラグイン、、、。挙げたらきりがないほど多種多様です。ご自身が携わったプロジェクトで、実際に取り扱った新技術・サービスで、苦労した／工夫したものがあれば、まさに地となり肉となっている経験なのでそれを書いていくのが無難でしょう。そうでない場合は、②実現性の評価の内容を思い浮かべて、さかのぼって①を決めるというのもアリかと思った次第です。
あと、もう一点。具体的な商品名・固有名詞は書かないほうが無難です。商品名を書いたから一発アウトで評価Dとなるか否かは分かりません。とはいえ、論文の中で、具体的な商品名を褒めたり着にディスったりしてもいいことはないと思います。
「データベースでオラクルを使っていたのだが、ライセンス料が高いのでポスグレにした。ただし、開発者にとっては未知のデータベースであった。」
と書いても、誰も得しませんよね。せめて、
「商用データベースを利用していたが、コスト圧縮ためフリーライセンスのDBを活用した」と書いたほうが無難だと思います。
では、②実現性の評価の内容
パッと思いつくのをランダムに。
・性能問題：DBやネットワークの速度が利用に耐えられるか
・開発効率：未知のツールを活用して生産性が担保できるか
・製品間の相性問題：採用した新技術と既存技術の相性は大丈夫か。導入事例・実績があるか
・保守性：稼働後の改変時、技術者を確保できるか
・契約面等：海外製・サードパーティーなど、国内から撤退するリスクはないか
このあたりが、割とスッと出てきて、そのなかで実際に検証すべき事と導入実績のヒアリングを行う事など、対処方法をうまく腑分けできるようになっているといいですね。
こういうのは経験がモノをいうあたりですが、そこを補うとしたら学術的な参考書ではなく、日経コンにある実例記事のほうだと思います。ご参考まで。
では、実際にプロットにマッピングしてみましょう。
１．私が携わった新技術を活用したシステム開発プロジェクト
１．１．プロジェクトの特徴
・公共システムで、マルチベンダで構築する
１．２．システム要件
・入札仕様でクラウドの活用が明示されている
１．３．プロジェクトの要求事項
・クラウドで構築する新システムと既存システム間で連携があり、既存システム側から利用すべきAPIが指定されている
２．検証フェーズでの実現性評価
２．１．検証フェーズでの実現性評価
・クラウドの性能の確認
・APIの実装の実検証（実際に使えるか。生産性も担保できるか）
２．２．開発フェーズへのフィードバック
・開発計画を一部見直し
・実装検証でのノウハウを継承
２．３．ステークホルダへの対応
・以上の検証フェーズで行うことは事前に顧客ステークホルダ、他ベンダと合意
３．検証内容と情報の活用についての評価と改善点
３．１．評価
・検証内容の評価についてレポーティング
・実装内容については他ベンダ間にも共有
３．２．改善点
・性能評価で行ったボリューム検証を開発フェーズ終盤でも行うことをスケジュールに組み入れ
いかがでしょうか。論文の記載にあたっては、問題文を読んですぐ書き始めるのではなく、この粒度程度でいいのでプロットを問題用紙のメモ欄に書く習慣をつけておいたほうがいいと考えています。事前の練習・勉強ではマストですし、実際の試験では最低でもアタマの中で練ってから書き始めましょう。
これについては、試験時間の使い方でも触れてますのでご参考になりましたら。では、また次回、宜しくお願いします。
