答案の一覧＞

この答案についての講評

　試験結果は、BCAでした。今回の試験ではきっちり答案を作成されてよく頑張りました。ただし、技術士の専門性をアウトプットするような練習が不足していたのではないかと想像致します。マンツーマンコーチングでコンピテンシーを高めていけば楽勝で合格できます。次回試験に備えて、再現答案を修正して、まずは真の正解を確認されるようにしてください。音声ガイドのコメントをお聞き願います。。

　内容的には、Ⅰ-1では前置きが長く、本質的な事項があまり述べられていなかったようです。ご自身ではB判定となっていることが、採点理由が不明で、自身の足りない観点が釈然としないとのことでした。こうした点についてコーチングであればしっかり指導を受けられます。Ⅱ-1の手法はウォーターフォールの反意語なので、アジャイルではなくここはプロトタイピングがよいでしょう。Ⅱ-2では時期開発に向けて何をすべきかという本質が見えていなかったようです。実はこうした本質を見抜く力が求められるのです。当たり前の一般論で解答されていましたが、情報工学での対策法が提案できなかったようです。ご自身では誤字をCの判定の原因とお考えのようですが、それは違います。そのような細かいことではＣにはなりません。このようなケースワーク問題では、経験がないと普通は解答が書けません。本講座ではより良い対応をお教えしておりますのでコーチングで学べは合格点が取れるようになります。

　Ⅲでは、前置きはやはり長かったものの、実務的な視点、実力を発揮されて、それが評価されたものと考えます。解決策の①②③ともに実務で有用性の高い手法です。そのようなプロの力、経験力が正しく評価されてよかったです。リスク自体はやや常識的でしたが、しかし、解決策がプロの内容で◎と言えます。

　これまで2回目受験されて、苦労されているご様子なので残念です。しかしこうした弱点があったとしても、コンピテンシーを高めていけば誰でも合格できます。技術士試験では、講師の言うとおりに語句を直しているだけでは合格出来ません。大事なのはご自身で正解を感じ取る、そして行動(提案)することです。この感覚を早く習得されて、合格を勝ち取ってください。ただし1回で合格するには正しく学ぶ必要があります。本講座ではマンツーマンコーチングで技術士コンピテンシーを引き出して一発合格するための指導をしておりますのでご参考にしてください。

　音声ガイドによるコーチング指導内容(25分45秒)がダウンロードされますのでお聞きください＞

問題  　　　Ⅰ―2　近年、日本の行政サービスのデジタル化が推進されている。その一環で、スマートフォンを活用した「事務手続」や「住民への情報提供」が可能となっている。今後、住民が広く継続的に行政サービスを利用すること念頭に置いた場合に、スマートフォンで動作するアプリケーションソフトウェアを開発することがされに増えてくると考えられる。このような状況を踏まえて、以下の問いに答えよ。

（１）技術者としての立場で、多面的な観点から３つの課題を抽出し、それぞれの観点を明記したうえで、課題の内容を示せ。

（２）抽出した課題のうち最も重要と考える課題を１つ挙げ、その課題に対する複数の解決策を示せ。

（３）すべての解決策を実行しても新たに生じうるリスクとそれへの対策について、専門技術を踏まえた考えを示せ。

（４）前問（１）〜（３）の業務遂行において必要な要件を、技術者としての倫理、社会の持続可能性の観点から述べよ。

Ⅰ―２．行政サービスに関するアプリケーション開発の進め方

　行政サービスのアプリケーション開発がさらに増えてくる状況を踏まえ、開発の進め方を以下に示す。

■この↑ような前置き不要です

（１）課題抽出

　必要性、安全性、経済性の観点で課題を抽出する。

１）必要性の観点（要件定義） 

　住民が広く継続的に行政サービスを利用するための業務要件や機能要件／非機能要件の整理を進める課題がある。また同種のアプリケーション開発の増加が予想されるため、コア処理を中心としたソフトウェアの再利用検討が必要である。

■これは前提事項であり、当然必要性ありに決まっています。

２）安全性の観点（ソフトウェア品質）

　行政サービスという公共性の高いシステム開発であり、ソフトウェア品質（機能適合性、性能効率性、有効性、使用性、信頼性、保守性）確保が課題となる。

■あいまいです。特に主要因は↑どれか。

３）経済性の観点（対立する利害調整）

　行政サービスシステムの関係者は、一般的に行政、システム開発ベンダー、エンドユーザーである。関係者間で利害が対立した場合、品質、コスト、納期、生産性、リスクを考慮し、調整する課題がある。

■公共サービスとしては当然。公的システムでどう安くできるかの課題はないのですか。

（２）最重要課題と対策

　必要性を最重要課題とした。なぜなら同種開発が増える傾向であり、近々の対策が必要のためである。課題に対する解決策を以下に示す。

■「必要性」の課題とあまり関係のない対策です。やはり課題を誤ったため正しく解けていません。

解決策①：モジュール結合度の最適化

ソフトウェアの再利用化を進めるため、モジュール結合度を低める。例えば、他モジュール内データの直接参照を止め（内容結合）、必要なデータのみモジュール間連携するよう改善する（データ結合）。

解決策②：モジュール強度の最適化

　次にモジュール強度を高め、モジュール構造のシンプル化を進める。例えば、全く整理されていないモジュール集合から（暗号的強度）、単一機能のモジュールへ改善を進める（機能的強度）。

解決策③：フレームワーク利用

　共通機能が少なく、ソフトウェアの再利用化が困難な場合、より上位概念であるアーキテクチャ（フレームワーク）の再利用を進める。

（３）リスクと対策

　セキュリティと技術者不足がリスクと考える。

リスク①：セキュリティ（機密性・完全性）

　外部への情報漏洩（機密性）、データ改ざん（完全性）のリスクがある。対策を以下に示す。

（対策）

・データへのアクセス権設定（機密性）

・データベース暗号化（機密性）

・ハッシュ値による改ざん検知（完全性）

リスク②：セキュリティ（可用性）

　Ｄｏｓ攻撃等、サイバー攻撃によるシステム停止のリスクがある。対策を以下に示す。

（対策）

・システム二重化（レプリケーション等）

・ＲＰＯ（目標復旧時点）を考慮したバックアップ

・システム復旧手順書の整備

リスク③：技術者不足

　技術の属人化により、技術の喪失や、ソフトの再利用が停滞するリスクがある。

（対策）

・計画的な開発チーム間のローディング

・コア技術資産を管理する組織の設置

・技術情報に関するドキュメント化及び定期的な教育

（４）業務遂行に必要な要件

　技術者倫理、社会持続可能性の観点で以下に示す。

１）技術者倫理の観点

　公益の確保を進める。具体的には、行政、住民といった関係者が利用し易いシステム開発に取り組む。　

■最低限、当然のことです。(技術士に聞くまでもない)

その他、個人情報保護法やサイバーセキュリティ基本法等、関連法規を遵守する。

２）社会持続可能性の観点

　誰一人取り残さないというＳＤＧｓの理念を進めるため、高齢者や子供にも利用し易いＧＵＩ化を進める（ユニバーサルデザイン）。また技術者として、技術革新の拡大に寄与する。

〇です

問題文　 Ⅱ―１―４　　　　ソフトウェア開発を安定的かつ臨機応変に進めるためにはプロジェクト管理が必要不可欠である。プロジェクト管理において、工程管理に関する代表的な手法を３つ挙げ、それぞれの概要、及び特徴を述べよ。

１．ウォーターフォール

ウォーターフォールは、要件定義、設計、製造、試験、運用と、工程毎に品質を確保しながら、逐次的に開発を進める工程管理手法である。

（特徴）

ウォーターフォールは、工程管理がしやすいという特徴がある。反面、仕様変更が発生した場合、大幅な開発の後戻り作業が起こる傾向がある。

２．スパイラルモデル

スパイラルモデルは、要件の確度が高い機能、またはサブシステムから開発に着手する逐次的＋反復的な工程管理手法である。

（特徴）

スパイラルモデルは、要件の確度が高い機能から開発着手するため、後戻り作業の発生が少ないという特徴がある。反面、仕様追加が多くなりがちであり、全体工程の把握が難しい。

３．アジャイル　

■1ウォーターフォールの反意語なので、ここはプロトタイピングがよいでしょう

ユーザーストーリーに従い、スプリントと呼ばれる２週間〜１カ月の周期で、反復的に開発を進める工程管理手法である。

（特徴）

反復的に開発を進めるため、仕様変更に強いという特徴がある。反面、関係者間の利害対立調整は困難であり、大規模開発には不向きである。　

問題文　 　　Ⅱ−２−１　顧客の業務を支援するWebアプリケーション開発のプロジェクトリーダを担当している。業務では、経験年数の浅い複数の技術者が参画している。また、上流工程では、ユーザインタフェース設計に対してレビューを実施していた。一方、顧客が実施する受入テストにおいて、機能に関するバグに比べてユーザビリティに関するバグが多く報告される事態となった。そこで、同一顧客向けの次期開発に対してプロセス改善を遂行するに当たり、以下の問いに答えよ。

（１）調査、検討すべき事項とその内容について説明せよ。

（２）プロセス改善を進める手順と、その際に留意すべき点、工夫を要する点を述べよ。

（３）プロセス改善を効率的かつ効率的に進めるための関係者（ステークホルダ）との調整方策について述べよ。

Ⅱ―２―１．次期開発に対するプロセス改善の進め方

　次期開発プロジェクトリーダ（以下、ＰＪＬ）の立場で、プロセス改善の進め方を以下に示す。

■このような前置き↑は不要です

（１）     調査・検討すべき事項とのその内容

　機能性、安全性、経済性の観点で、調査・検討すべき事項を以下に示す。

■前置き↑不要です

１）機能性（要件定義）

　上流工程でユーザインタフェース等の設計不足の可能性がある。ＰＪＬは、機能要件や非機能要件（可用性、性能、拡張性、移行性、セキュリティ、システム環境）を調査・検討すべきである。

■根拠がわかりません。ユーザインタフェース設計のレビューはあったが、設計不足まではありません。ユーザビリティのバグは、顧客が実施した受入テストです。

２）安全性（ソフトウェア品質）

　ユーザビリティ不具合が多い。ＰＪＬは、ソフトウェア品質（機能適合性、性能効率性、有効性、使用性、信頼性、保守性）を調査・検討すべきである。

３）経済性（作業タスク）

　経験年数の浅い複数の技術者が参画している。ＰＪＬは、当該技術者の担当している作業タスク難易度／コスト／期間の妥当性を調査・検討すべきである。

■経験→コストでは短絡。本質的なことが分析できていません。

（２）プロセス改善を進める手順と留意・工夫点

　以下手順でＰＤＣＡを回す。

■PDCAをわざわざ求めているわけではありません。問いが求める複雑な前提条件に対して何も答えられていないようです。これではクライアントは怒りだします。

・Ｐｌａｎ（計画：品質、コスト、納期、生産性、リ

スク管理）

・Ｄｏ（開発：設計、製造、試験）

・Ｃｈｅｃｋ（測定・評価）

・Ａｃｔ（是正・改善・対策：人的リソース、設備、

コスト、情報共有の最適化）

加えて、留意点、工夫を要する点を以下に示す。

（留意点）

・特に非機能要件の明確化に留意する

・有効性・使用性の確保に留意する

・労働基準法の遵守に留意する

（工夫を要する点）

・非機能要件グレードを用いインタビューを実施する

・プロトタイプを作成しユーザ視点で確認頂く

・作業タスクと担当者の状況を定点観測する

（３）ステークスホルダとの調整方策

　先行開発ではバグを多数出している。ＰＪＬは関係者との信頼関係を一刻も早く回復する必要がある。

■信頼関係は大事だが、失った信頼を回復するのが業務の目的ではありません。ここは解決策をスピード化、効果的に行うための調整です。また調整とは頑張りではありません。意味が正しくとらえられていないのでは。過剰・不足の2つの間で何かを移して、均衡を図ることです。　例　スピード〇〇、年末〇〇、役員のの党内〇〇

１）状況説明

　ＰＪＬは先行開発の問題点・課題を明確にし、施策提示や今後の進め方について誠意を尽くし説明する。

２）要件定義の協力要請

　ＰＪＬは、要件定義の確定のために関係者へ積極的なプロジェクト関与を要請する。具体的には、要件定義書やプロトタイプシステムのレビュー／フィードバックを依頼する。

３）定期的なプロジェクト状況確認

　帳票等を作成し、プロジェクト状況の可視化し、関係者とＰＤＣＡサイクルを回す。

問題文　 Ⅲ−１　近年、企業では、美辞ネル環境の激しい変化に対応するために、デジタル技術を活用して製品やサービスだけではなくビジネスモデルを変革することにより、競争上の優位性を確立しようとしている。これは、デジタルトランスフォーメーション（DX）とよばれている。DXは、経営をはじめ、事業、サービス、システム等の様々な側面における活動、体制、及び資源を統合して実現されているものである。そこで、DXの実現において、システムがすべてを支える重要な役割を担っているいることを踏まえ、以下の問いに答えよ。

（１）          情報システム部門の技術者としての立場で、企業のシステム及びシステム開発状況について想定する前提を明確にしたうえで、多面的な観点から３つの課題を抽出し、それぞれの観点を明記したうえで、課題の内容を示せ。

（２）抽出した課題のうち最も重要と考える課題を１つ挙げ、その課題に対する複数の解決策を示せ。

（３）すべての解決策を実行しても新たに生じうるリスクとそれへの対策について、専門技術を踏まえ考えを示せ。

Ⅲ―１．情報システム部門におけるＤＸ実現の進め方

　ＤＸ実現のため、システムが重要な役割を担っていることを踏まえ、以下に進め方を示す。

■このような前置き↑は不要です

（１）想定する前提条件と課題抽出

（想定する前提条件）

　企業システム、開発状況の前提を以下に示す。

・ビジネス環境の激しい変化（仕様変更が多い）

・ＤＸは資源を統合し実現（現行システムの利用）

・システムがすべてを支える（高い品質要求）

・ＤＸは活動／体制を統合し実現（関係者が多い）

（課題抽出）

　必要性、安全性、経済性の観点で課題抽出する。

■見出しには、観点ではなく、課題そのものを挙げるようにしてください。

１）必要性（仕様変更が多い、現行システムの利用）

　仕様変更に対応するため、業務要件の整理、および開発に必要な機能要件／非機能要件の整理を進める必要がある。特に現行システム等、資源の統合を見据え、非機能要件の拡張性を確保する課題がある。

■必要性ありきで考えているせいか、課題の意味がよくわかりません。

２）安全性（高い品質要求）

　システムがすべてを支える前提条件がある。このためソフトウェア品質（機能適合性、性能効率性、有効性、使用性、信頼性、保守性）確保の課題がある。

３）経済性（関係者が多い）

　経営、事業、サービス、システムと各部門が利用するシステムとなる。発生する利害関係を調整しつつ、開発を進めなければならない課題がある。

（２）最重要課題と解決策

　必要性を最重要課題と選定した。なぜならばＤＸ推進にシステム統合準備（部品化、現行システム再利用）が直ちに必要なためである。以下解決策を示す。

・解決策①：モジュール結合度／強度の最適化

■Ｍ結合とＭ強度の2つの面からの説明で説明が回りくどいです。目的、ねらいを1回で説明できませんか。

　モジュール結合度（データ結合、スタンプ結合、制御結合、外部結合、共通結合、内容結合）を低め、モジュール強度（機能的強度、情報的強度、連絡的強度、手順的強度、時間的強度、論理的強度、暗号的強度）

を高める。具体的には、モジュール間通信を可能な限り必須データの連携のみとし、モジュール内機能の単一化を進めることで、再利用性、拡張性を担保する。

・解決策②：フレームワーク適応

　各機能の要件が固有のため、モジュール部品化が進まない場合、上位概念であるアーキテクチャ（フレームワーク）の再利用を検討する。具体的には、リファクタリングを繰り返することにより設計が洗練され、再利用性の高いフレームワークが整理できる。

・解決策③：ラッパー処理の活用

　現行システムをＤＸシステムに取り込むため、ラッパー処理の活用を検討する。具体的には、現行システムの入出力をラッパー処理に全て担当させ、新規に開発したＤＸシステムと連携する。これにより現行システムを変更することなく、ＤＸシステムに必要な機能を統合することが可能となる。

■解決策の①②③ともに実務で有用性の高い手法です。そのようなプロの力、経験力が評価されたようです。

（３）リスクと対策

　ＤＸ推進で生じうるリスクとして、セキュリティと技術士者不足について、以下に示す。

■リスク自体はやや常識的です。要件「すべての解決策を実行しても新たに生じうるリスク」とはやや異なります。しかし、解決策がプロの内容で◎です。

リスク①：セキュリティ（完全性、機密性）

　データの改ざん（完全性）、なりすまし等による情報漏えい（機密性）がリスクとなる。

（対策）

・ＤＢのハッシュ値による改ざん検知（完全性）

・定期的なデータバックアップ（完全性）

・関係者の役割に応じたアクセス権の設定（機密性）

・ＤＢやネットワークの暗号化（機密性）

リスク②：セキュリティ（可用性）

　Ｄｏｓ攻撃等によりシステムが停止し、ＲＴＯ（目標復旧時間）を守れないリスクがある。

（対策）

・システム２重化を進める。もしＲＰＯ（目標復旧時点）＝０の場合、レプリケーション構成を検討する

・システム復旧手順書の整理および定期訓練実施

リスク③：技術者不足

　全ての資源統合を進めるため、現行システムやフレームワーク等を熟知する技術者離任がリスクとなる。

（対策）

・ＲＰＡ（ソフトウェアロボット）の利用

・設計ドキュメントの最新化および補足資料作成

・計画的なチーム間ローディングの策定　

アジャイル　 

■1ウォーターフォールの反意語なので、ここはプロトタイピングがよいでしょう