ES試験 午後Ⅱ論述の書き方ガイド【構成から高評価を得るコツまで】

2023年から論述式に変更

令和5年度（2023年）秋期試験より、エンベデッドシステムスペシャリスト試験の午後Ⅱが事例解析（長文読解）形式から論述式に変更されました。これはITストラテジストやシステムアーキテクストなど他の高度試験と同じ形式です。

論述式では、受験者自身が経験したまたは関与した組込みシステム開発プロジェクトを題材として、出題テーマに沿った論文を記述します。

設問	字数	内容
設問ア	200字程度	対象システムの概要説明
設問イ	800〜1,600字	テーマに関する取り組みの詳細
設問ウ	600〜1,200字	評価・改善点・今後の課題

論文の構成パターン

ES試験の論文は、以下の基本構成で書きましょう。

1. 設問ア（200字）：システム概要：何のシステムを、どのような環境で、どの役割で開発したかを簡潔に述べます。（例：「自動車のABSブレーキ制御ECUの開発において、組込みソフトウェアの設計・実装担当として…」）
2. 設問イ（1,200字前後）：本論：出題テーマに沿って、自分が取り組んだ内容・採用した手法・その理由を具体的に論じます。
3. 設問ウ（900字前後）：評価・課題：取り組みの結果・効果・残った課題・改善点を客観的に評価します。

💡 1つの「ネタ」を複数テーマで使い回す 自分が経験した1つの開発プロジェクトを「信頼性確保」「リアルタイム設計」「安全性設計」など複数テーマに対応できるよう深掘りしておくと、出題に柔軟に対応できます。

出題テーマ別の論点

出題テーマ（想定）	設問イで論じる主なポイント
リアルタイム性の確保	タスク優先度設計・スケジューリング方針・デッドライン検証方法
信頼性・フォールトトレランス	障害検出方法・フェールセーフ設計・冗長化の採用理由と効果
機能安全への対応	ASIL/SILレベルの判定・安全要求の実装・検証・FMEA実施
SW/HW協調設計	HW/SW分担の決定プロセス・インタフェース設計・検証方法
組込みシステムの再利用性	ソフトウェアアーキテクチャ・HAL設計・移植性向上の施策

論文を書く際のコツ

• 具体的な数値・固有名詞を使う：「適切な周期に設定した」より「5msの制御周期を設定した」のように具体的に書くと説得力が増します。
• 「なぜそうしたか」の理由を必ず書く：採用した手法だけでなく「なぜその手法を選んだか」の理由まで書くことが評価のポイントです。
• 問題→対策→効果の流れで書く：「課題があった→対策を実施した→効果があった」という論理の流れを作ると読みやすい論文になります。
• 設問ウで反省点を書く：完璧なプロジェクトは存在しません。改善できた点・課題が残った点を正直に書くと評価者に誠実さが伝わります。

⚠️ 丸暗記論文は危険！ 他人の論文をそのまま暗記して書くと、設問の変化に対応できなくなります。自分の言葉で、自分のシステムに即して書く練習をしましょう。

論文練習の方法

1. ネタ（シナリオ）を1つ作る：自分が開発に関わった（または教科書で学んだ）組込みシステムを1つ選び、設問ア〜ウのドラフトを作ります。
2. 過去問・想定テーマで書く練習をする：作ったシナリオを使って、異なるテーマ（リアルタイム性、信頼性、安全性など）で論文を書く練習をします。
3. 字数を計って書く：実際に時間を計って手書きまたはタイピングで2,400〜3,200字を書けるか確認します。
4. 論文をレビューしてもらう：社内の先輩・受験仲間・添削サービスなどを活用して、自分では気づかない改善点を把握します。

論文作成の実践的チェックリスト

論文を書いた後、以下のリストで自己採点すると、高評価を得られる論文に近づきます：

設問ア（システム概要）チェック

• システムの具体名・機能・規模（例：「自動車のECU」「100万行のC言語」）が明記されているか
• 自分の役割が具体的に書かれているか（「ソフトウェア設計・実装担当」くらいまで詳細に）
• 開発期間・チーム規模・開発環境が記載されているか
• 200字程度のボリュームを確保しているか（100字以下は減点の可能性）

設問イ（テーマに関する取り組み）チェック

• 出題テーマ（リアルタイム性、信頼性など）に直接答えているか
• 「なぜそのような設計にしたのか」という根拠が述べられているか
• 具体的なツール・規格名が記載されているか（例：「AUTOSAR」「ISO 26262」）
• 図や表で補足する必要がないか（手書き試験なので図は不要だが、読者が想像しやすい記述になっているか）
• 800～1,600字のボリュームを確保しているか

設問ウ（評価・改善点）チェック

• 取り組みの成果・効果が数値で示されているか（例：「制御誤差を5%削減」「開発期間を3か月短縮」）
• 課題や制限事項も正直に書かれているか（完璧な論文より、課題を自覚した論文の方が高評価）
• 今後の改善方向が提示されているか
• 600～1,200字のボリュームを確保しているか

論文テーマ別の「ネタ作り」例

実務経験がない場合、教科書の事例シナリオを参考に論文を作成します。以下は例です：

テーマ：「リアルタイム性の確保」

想定システム：組込みマイコン（Cortex-M系）による温度制御システム

• 設問ア：「工業用オーブンの温度管理ECU。目標温度±2度に制御」
• 設問イ：「優先度ベースのプリエンプティブスケジューリング。温度センサー周期10ms、ヒーター制御5msの優先度設定。デッドライン検証を実施」
• 設問ウ：「温度安定化時間を従来の50msから20msに短縮。ただし割り込み遅延が問題化したため、ISR短縮化に取り組む予定」

テーマ：「信頼性・フォールトトレランス」

想定システム：自動車のABSブレーキ制御

• 設問ア：「自動車のECU。60万行のC言語＋RTOSで実装」
• 設問イ：「センサー異常検出のため、複数センサーの値を相互検証。異常時はフェールセーフモード（ブレーキ制御を機械式に切り替え）を実装」
• 設問ウ：「テスト段階で検出されない故障率を1/1000に削減。ただし制御時間の増加がネック」

よくある論文の失敗パターン

失敗パターン	理由	改善方法
設問イが1,000字以上（指定800～1,600字）	冗長・不必要な説明が多い。採点者が必要な情報を探すのに時間がかかる	「○○を採用した。理由は△△。効果は□□」の3点セットに絞る
全体が1,500字以下（指定2,400～3,200字）	内容が不十分。設問ウで特に不足しやすい	設問ウで「改善方向」「今後の課題」を追加記述
一般的な論述で、自分の具体的な関与が不明確	「システムでは信頼性対策を実施した」と受動的な表現	「私は○○を実装し」「私たちのチームが採用した」と能動的に
開発経験のない方が、実務っぽい嘘を書いている	採点者（実務経験者）に見破られることがある	「教科書の事例を参考に」「想定シナリオとして」と前置きする。嘘より「経験に基づかない仮想シナリオ」の方が評価が良い

合格者の論文練習パターン

実際の合格者に見られた効果的な論文学習：

1. 初期段階（試験3か月前～）：1つのシナリオを決め、複数テーマで論文案を作成。各テーマ3～4枚程度の下書き
2. 精緻化段階（試験2か月前～）：下書きを推敲。字数調整。キーワード・数値の追加
3. 実戦段階（試験1か月前～）：実際の筆記時間（120分）で1～2本の完成版を作成
4. 添削・フィードバック（試験1か月前～前日）：合格者・講師・受験仲間に読んでもらい、読みやすさ・説得力をチェック

まとめ

📝 この記事のまとめ 午後Ⅱは2023年度から論述式。設問ア（200字）＋設問イ（1,200字前後）＋設問ウ（900字前後）。 1つの開発ネタを複数テーマに対応できるよう深掘りしておく。 具体的な数値・理由・問題→対策→効果の流れを意識して書く。 丸暗記は禁物。自分の言葉で書く練習を繰り返す。 実務経験がない場合、教科書の事例シナリオを参考にして論文作成も有効。 チェックリスト・失敗パターンを意識して推敲することで高評価に近づく。

午後Ⅱ論述は「あなた自身の組込みシステム開発経験・知識をどう論理的に説明できるか」を問う試験です。完璧な経験談より、自分の言葉で誠実に書かれた論文の方が高く評価されます。

論文採点基準（推測される観点）

IPA公式には採点基準が完全には開示されていませんが、採点講評から推測される評価ポイントです：

設問ア（概要説明）の評価ポイント

• 明確性：「何のシステムを、どの環境で、どの役割で開発したか」が一目瞭然か
• 具体性：「プロジェクト規模・人数・期間・使用技術」が記載されているか
• 信憑性：「実在性のあるシステムか、それとも仮想シナリオか」が判断できるか

採点例：

✓ 高評価：「自動車のABS制御ECU開発。50名規模、3年間、C言語＋RTOSで実装。センサー入力～制御出力まで一貫して担当」
△ 中評価：「ブレーキ制御システムの開発に関わった」（規模・期間が不明）
✗ 低評価：「ある会社でシステムを開発した」（何のシステムか全く不明）

設問イ（詳細説明）の評価ポイント

• テーマとの関連性：出題テーマ（リアルタイム性・信頼性など）に直接答えているか
• 技術的深さ：単なる「やったこと」ではなく「なぜそうしたのか」が述べられているか
• 論理性：「問題→対策→効果」の流れが明確か
• 具体性：「詳細な設計・実装方法」が述べられているか。例えば「テスト」と書くだけでなく「ブラックボックステストで△△のテストケースを実施」くらいまで具体化

設問ウ（評価・改善）の評価ポイント

• 客観性：「良かった点」「課題が残った点」がバランスよく述べられているか
• 学習性：「次回改善する方向」が述べられているか
• 誠実さ：完璧な報告より「課題を認識している」という姿勢が見える方が評価される可能性

高評価を得た論文の共通特性

実際の合格者の論文を複数見ると、以下の共通点があります：

1. 「技術用語」と「一般用語」のバランスが良い

   • 「優先度継承プロトコル」など必要な技術用語は正確に
   • しかし全文が技術用語で埋まると読みづらい
   • 例：「複雑なタスク間同期を優先度継承プロトコルで解決し、リアルタイム性を確保した」

2. 「数値」が具体的に入っている

   • 「制御周期5ms」「割り込みレイテンシ100μs」など、数値があると信憑性が高まる
   • 試験なので「正確性100%」を求めない（多少のズレはOK）。重要は「数値で具体化する癖」

3. 「図解」が記述に紛れている

   • 手書き試験なので図は描けませんが、「状態遷移は以下の通り」と文章で図を説明する方法がある
   • 例：「アイドル→スタンバイ→実行→完了という4段階」のように

4. 「改善できなかった点」も正直に書く

   • 「完璧な設計」より「課題を認識している」という誠実さが評価される

実務経験がない場合の「シナリオ構築の秘訣」

組込み実務経験がない場合、以下の方法でリアルな論文を作成できます：

方法1：教科書の事例を自分の言葉で深掘りする

教科書に載っている「自動車ECU」「医療機器」などの事例を選び、その事例について「もし自分が設計したら」という視点で設問ア～ウを書く。

利点：教科書知識が充実しているため、細かい技術的誤りが少ない 注意：「教科書の例を丸写し」は禁物。自分の言葉で再構成し、新たな視点を加える

方法2：学生時代の卒論・実験をベースにする

組込みシステムのマイコンボード（Arduino・Raspberry Pi など）を使った自分の実験を題材にする。

利点：実際の経験なので、細部が自然で信憑性が高い 注意：学生時代の小規模プロジェクトを「本当はこうするべき」と拡張する方法もある

方法3：複数の経験をミックスさせる

「プロジェクトAの設計方法」＋「プロジェクトBの実装手法」＋「プロジェクトCの信頼性対策」のように、複数の経験から要素を抽出して「仮想プロジェクト」を構築する方法もあります。

利点：複数分野の知識が統合される 注意：矛盾がないように気をつける（例：50年前の技術と最新技術を混ぜない）