【2021年空総監受験】出題パターン1ー実務実績問題の解き方

9月25日の試験日まであと1ヶ月、皆さんの学習は進んでいますか?

前回の記事では、空総監試験の過去問を以下の7つの出題パターンに分類しました。

  1. 実務実績問題  <<== 今回はココ
  2. コラム問題
  3. アカデミック系の問題あああ
  4. 知識系の問題
  5. 行政課題解決問題(パワポ)
  6. タイムリーな課題解決問題(パワポ)
  7. その他の問題(パワポ)

今回は、前回の記事で分析した7つの出題パターンのうちの”実務実績問題”について解説しようと思います。

目次

出題例

以下は実務実績問題の出題例(H22年度問1)です。

空総監試験H22年度問1より引用

この問題では、ワードで3〜4ページ(1ページ36行・40文字、合計約3,000〜4,000文字)の答案を作成します。

実務実績問題で問われていること

この問題で問われていることは、空総監として相応しい経験や能力といったこととなりますが、もう少し噛み砕くと以下のようなると思われます。

  • 一段高い観点(空総監の立場で)で業務を説明、評価できる
  • 受験者が本当にその業務を経験しているのか確認する
  • 課題設定と解決能力の確認

設問としては、”失敗例”、”成功例”という形になりますが、本質的には業務を様々な観点で評価することができるか、課題設定と問題解決能力はあるか、そしてそれはリアルな経験かということが問われていると思います。

答案例

答案例は以下のようになります。

1.受験番号、氏名
 21−006、高本 啓司

2.業務名称、実施時期および場所
 業務名称:○○警察向け通信指令システム再構築業務
 実施時期:2016年7月〜2019年3月(2年8ヶ月)
 実施場所:自社および○○警察本部庁舎

3.業務の目的と内容(概要)
 本業務の目的は、5年の賃貸借契約満了に伴う○○警察向け110番通信指令システムの更改で、約○○台のサーバー、○○台の端末、関連するネットワーク等のITインフラおよびアプリケーションの更改である。
 私は、地理情報サブシステム(GIS)再構築の責任者として、通信指令システムの地図を使った110番の発生場所特定や無線指令のためのパトカーや警察官の現在位置の地図表示、緊急配備の発令に関するGISアプリケーションの再構築を行った。
 システム更改における主な改修内容を以下に示す。
 ・GISは自社製であるが、描画処理を高速化するため描画APIを変更(GDIからDirect2Dへ変更)
 ・地図上にアニメーション表示
 ・地図データをY社製からZ社製へ変更
 ・地図データの取り扱い範囲を○○圏のみから全国へ変更
 ・上記に伴い地図の投影方法を平面直角▲系からWebメルカトル(EPSG 3857)へ変更
 ・経路探索エンジンを自社製からX社製へ変更
 ・端末アプリケーションの操作性向上を目的に全面変更(約200KL)

4.失敗の内容と原因
 本業務は、3年度に渡る開発プロジェクトであったが、その内訳は2016年度に基本設計、2017年度に詳細設計と製造、2018年度に総合試験とシステム移行を実施するスケジュールだった。失敗は特に2017年度に実施した製造工程で発生した。以降に失敗の内容を示す。
①製造工程での大幅な工数超過
 システムは、大きくサーバーとクライアント、地図データ変換部分の3つに分かれる。大幅な工数超過が発生したのは、クライアント部分の開発で発生した。具体的には、当初見積工数が約○○人月だったのに対して、実際に開発工程で投入した工数は約△△人月となってしまった。
 この原因はいくつかあるが、第一にイテレーション開発と呼ばれる開発手法を採用し、3ヶ月ごとにユースケース(業務観点の機能)を実現したモジュールをリリースしていく工程となっていたが、現実的にはユースケースの機能が全て実現できないために徐々に機能の積み残しが増え、最終的に大幅な増員を行なってスケジュールを守らざるを得なくなったことが一つ目の原因である。
 二つ目の原因は、見積が過少だったことが挙げられる。これは、お客様の予算が限られていることや今回ほどの大幅改修を行わなかった前回の更改の実績値をもとに見積工数を算出したために発生している。具体的には、従来のクライアント画面はWindowsのMFC(Microsoft Foundation Class)と呼ばれるかなり古い画面ライブラリを使って構築されていたが、今回の更改にて、最新のWPF(Windows Presentation Foundation)と呼ばれるWebベースかつ画面とプログラムロジックが完全に分離された開発環境を採用したため、この技術に開発要員が習熟するまでの工数やMFCとの実装方法の違いにより規模が増大してしまった。
 三つ目の原因は要員のスキルの問題である。これは、過少な当初見積に連鎖する形で発生した。具体的には、開発規模の○○人月から△名の開発者を投入し、作業を進めたが、作業着手から6ヶ月後には大幅な残作業が明らかとなり、熟練作業者が管理や報告資料作成に時間を割かれ、不足する工数のために要員を大幅に増員せざるを得なくなった。前述のWPFは2010年に発表された新しい技術で開発経験者はほぼおらず、未経験者を大量に抱えて習熟を待ちながら作業をすることとなった。当然ながら、生産性が低くなってしまい工数はさらに増大した。
②操作性の悪化
 次の問題は、完成したクライアントの操作性の悪化である。画面のレイアウトや操作性は、2016年度の基本設計時に画面遷移や画面提議書を提示して合意を取っていたが、基本設計書では画面のリストの並び順や、ボタンをクリックした時の動作が完全には表現できていなかった。例えば、パトカーのリアルタイム車両一覧を所属を指定して絞り込んだ場合、新システムでは地図の表示範囲内で絞り込みを行なっていたが、旧システムでは表示範囲を無視して所属のみで表示していた。結果として、所属の絞り込みをしても存在するはずの車両が表示されないといったクレームにつながった。
 このような操作性悪化の原因は、旧システムが仕様変更を繰り返した結果達成している仕様をドキュメント化していなかったことや仕様を熟知していない技術者による仕様の策定があったこと、更には完成した画面仕様書がGISだけで厚さが15センチ以上あるような大作で私もお客様もチェックが不十分だったことが挙げられる。
③品質問題の発生
 これらの状況から当然の帰結ともいえるが、品質問題が発生した。具体的には、メモリーの解放漏れやCPU高負荷の継続、実運用の負荷に画面表示がついていけないなどの性能問題などの不具合が多発し、お客様に定期的に端末再起動をお願いしたり、私を含む技術者が24時間体制で現場に当直しなければならない事態となった。この事態を解消するため何度かアプリケーションの改修版をリリースし、約3ヶ月でこの状況を解消した。
 この原因は、2017年度の開発作業の遅れから、本来は総合試験を実施する2018年度も開発を継続したために、システムを結合した状態での総合テストの不足や総合テストの項目に、メモリやCPUといったコンピュータリソース面や実運用の負荷を想定した性能面での試験が不足していたことが挙げられる。

5.解決策
 前述のように、製造段階における大きな失敗をした開発案件であったが、これらの問題の解決策を、以下に示す。
①製造工程での大幅な工数超過
 当初見積が過少だった問題は、予算に合わせて工数を積むのではなく、適用する技術への習熟度も見積の条件(パラメータ)に追加して工数を算出する。
 更に、イテレーション開発の適用については、システムの基本的な動作がフレームワークなどで決まっている場合には実施可能であるが、フルスクラッチかつ完全オーダーメイドの通信指令システムに適用すること自体に高いリスクがあったと考えている。よって、設計時にモックアップを作成する程度であれば工程への影響はほとんどないが、実際のユースケース(=機能)を短期間で繰り返し開発していくことは、避けるべきであると考える。
 要員のスキルの問題は、技術の新しさと生産性は反比例の関係となるが、お客様の予算見合いで新技術の適用を諦めるといった判断も必要だと考える。
②操作性の悪化
 操作性の悪化については、旧システムの改修内容をドキュメント化しなかったことに問題がある。システムを改修した場合は、必ず画面仕様書やマニュアルなどの外部仕様の修正を行う必要がある。システムを改修した場合、基本設計書やマニュアルに遡って修正することは稀である。これらの外部仕様は、使用中のシステムのドキュメントとしてだけでなく、未来に設計する次期システムの基礎資料となることも忘れてはいけない。
③品質問題の発生
 品質問題については、性能やリソース面での試験が不足していたことが問題であるので、以下のような対策を行う必要がある。
 ・画面操作やサーバーAPIを連続的に発行するツールを使った試験の実施
 ・OSにて提供されるリソースモニターを使って長時間運転時のCPUやメモリの使用状況を監視・統計を取る
 ・ソースコードの静的解析ツールを使用してリソースリークなどの誤りを摘出する

以上

上記答案は、約3,200文字、ページ数は3ページとなります。

答案作成のポイント

答案作成のポイントは以下の3つです。

  • 設問に忠実な章立てとする
  • 課題は徹底的に深掘りする
  • 数字で表現する

以降、個別に説明します。

設問に忠実な章立てとする

1つ目のポイントは、設問に忠実な章立てとすることです。

これは、採点者が読みやすいように配慮することで、採点の入り口をスムーズにする(ストレスをなくす)効果があります。
採点者に無駄な労力を割かせてしまうと、場合によっては減点要素になるでしょうし、採点者も人間ですから答案の印象の低下は防いでおくべきでしょう。

答案例の文章構成は以下のようになっています。

  1. 受験番号、氏名
  2. 業務名称、実施時期および場所
  3. 業務の目的と内容(概要)
  4. 失敗の内容と原因
    • 製造工程での大幅な工数超過     5.と同じ節構成
    • 操作性の悪化
    • 品質問題の発生
  5. 解決策
    • 製造工程での大幅な工数超過     4.と同じ節構成
    • 操作性の悪化
    • 品質問題の発生

解答例では、章構成を設問と一致させて文章の骨組みを作ったうえで、以下のような工夫をしています。

  • 4章(原因)と5章(解決策)の節立てを一致させ、原因と対策の対応を明確化
  • 文の流れを作るため3章には4、5章の伏線を記載
  • ”3.業務の目的と内容(概要)”では、自身の立場を明記

まとめると、設問に対して素直な章立てとすることで、採点者が”得点源となる記述”をすぐに見つけられる構成となり、確実に得点できる答案に仕上げます。

課題は徹底的に深掘りする

2つ目のポイントは、課題を徹底的に深掘りすることです。

課題を深掘りすることで、現場で起こっているドロドロしたことが表現されてリアリティが増します。
採点者は、そういったドロドロしたリアリティな文章を読むことで、”本当に経験したんだ”とか、”面白いなあ”と感じて答案の内容に引き込まれていきます。

答案例の文章構成は以下のようになっています。

  1. 慣れない開発手法による問題
    • 3ヶ月ごとにユースケースを具現化する慣れない開発手法
      • 徐々に開発の積み残しが増加
        • 最終的に大幅な増員を実施
  2. 過小な見積もり
    • 前回の更改の実績値をもとに見積工数を算出
      • 適用技術を変更(MFCから慣れないWPFに変更)
      • この技術に開発要員が習熟するまでの工数などが発生
  3. 要員のスキルの問題
    • 作業着手から6ヶ月後には大幅な残作業が明らかとなる
      • 遅れ原因を説明する資料作りに熟練作業者が時間を割かれた
        • 不足する工数を補うために要員を大幅に増員
          • 生産性が低くなり投入工数はさらに増大

答案例では、工数超過という課題の原因を3つに分類し、その原因を深掘りして行っています。

3つの原因それぞれに、”なぜ?”を3回くらい繰り返すことで現場で起こったドロドロした事象が出てきますので、その内容を書いていきます。

数字で表現する

3つ目のポイントは、数字で表現することです。

空総監は、”監理技術者”ですので、お客様や関係者などの第三者に対して業務の状況を説明して調整する役割を担っています。第三者への状況説明は、月日や工数、費用などの数字を使って正確に説明する必要があります。

業務実績問題の答案も第三者への業務説明ですから、数字を盛り込むことで状況が正確に伝わったりリアリティが増したりします。

  • 約○○台のサーバー、○○台の端末、関連するネットワーク等のITインフラおよびアプリケーションの更改である。
  • 端末アプリケーションの操作性向上を目的に全面変更(約200KL)
  • 当初見積工数が約○○人月だったのに対して、実際に開発工程で投入した工数は約△△人月となってしまった。


開発ライン数、投入工数、進捗率、テスト項目数、バグ数、費用、日程など、把握すべき数字を挙げるときりがないくらいありますので、事前の情報整理が重要となってきます。

まとめ

今回は、業務実績問題の答案例を解説しました。

試験テクニック的に業務実績問題は、事前準備が問われる問題ですし準備も容易です。

具体的な準備としては、事前にご自身の業務実績を文章化し、成功点や失敗点を整理して考察を加えておけば、試験当日は若干アレンジするだけで答案が完成します。

また、業務実績問題は出題頻度の高い”鉄板”的な問題でもありますので、事前準備の優先度は相当高いと言っていいでしょう。

次回は、”コラム問題”を解説します。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次