[https://www.youtube.com/watch?v=pmpFG8pjjbg:embed:cite]
本動画では、令和３年度 秋期 エンベデッドシステムスペシャリスト試験 午後Ⅰ 問2を取り上げ、デジタルトランスフォーメーション（DX）を用いたレストランシステムを題材に、システム構成の読み取り、制御装置内タスク間のメッセージ通信の整理、そして新機能として配膳ロボットを導入した際に既存ソフトウェアへどのような変更が必要になるかを、出題趣旨と採点講評の観点に沿って一貫した流れで解説します。午後Ⅰは、設計図や表の情報を単に拾い集めるのではなく、状態がどこで更新され、その更新がどのタスクのどの処理を起動し、結果がどのメッセージとして他タスクへ伝搬するのかを、時系列で追跡できるかが得点の中心になります。本問はDXという題材を用いながらも、実質的に問われているのは、イベント駆動型の組込みソフトウェア設計における状態管理とメッセージ連携の理解であり、採点講評でも「タスクとしての動作」を主語を意識して正確に記述することが重要だと示唆されています。結論として、合否を分けるのは、個々の端末の機能説明ではなく、制御装置の内部でタスクがどの情報を保持し、どの条件で更新し、どの通知を送るのかを、文章で破綻なく再現できるかどうかです。 まず設問1では、DXレストランの基本仕様を前提に、通信時間の計算と、情報の反映遅延が引き起こす不整合を扱います。NFCで入店端末からスマホへ20バイトのデータを送るとき、通信速度424kビット毎秒という条件から、20バイトを160ビットへ換算し、160を424,000で割って秒を求め、ミリ秒へ変換して0.38ミリ秒という値に落とします。この小問自体は難解ではありませんが、午後Ⅰで頻出となる「バイトとビット」「秒とミリ秒」の変換を確実に落とし切る姿勢が問われています。採点講評で計算ミスが指摘されがちなタイプの問題であり、単位変換の途中で桁を誤ると、後続の設計議論においても説得力を失います。また、品切れ登録が行われたにもかかわらず注文がキッチンに届く事象の理由は、品切れ情報がテーブル端末へ反映される前に当該料理が注文されてしまうという、更新伝搬のタイムラグに起因します。ここが本問の導入として重要なのは、後段のタスク間通信の設計が、まさにこの「反映遅延」「状態の一貫性」「更新通知のタイミング」を制御するために存在していると理解できるからです。つまり設問1は、単なる現象説明ではなく、システム全体をイベントと状態更新の観点で読むための入口になっています。 設問2では、制御装置のタスク構成と処理概要が問われ、ここが午後Ⅰとしての核心になります。読解ポイントは、図と表に出てくるタスク名を機能で覚えるのではなく、外部機器との境界をどのタスクが担当し、内部状態をどのタスクが更新し、その更新がどの通知として流れるのかを整理することです。サーバ通信タスクと通信を行うタスクが、入店、精算、キッチンの三つである点は、単に図から拾うだけでも答えは出ますが、本質は「サーバ通信が発生する業務イベントは何か」を業務シナリオと対応付けて説明できるかにあります。入店は会員情報照会、精算は決済依頼、キッチンはメニュー情報更新というように、外部サーバと整合を取る必要がある処理だけが通信対象となっており、テーブル端末のローカル操作や表示更新は別系統で処理される、という責務分離が読み取れます。 表2の空欄補充は、午後Ⅰで典型的な「文章の再構成」問題です。注文キャンセル時に注文履歴情報から該当料理を削除する、精算完了後に指示タスクへ片付け指示を通知する、片付け完了後に空席管理情報の自テーブルを空きに設定する、といった流れは、どれも単体で見れば平易ですが、採点講評が意識しているのは、主語を「制御装置」ではなく「タスク」に置いた記述ができているかです。例えば「品切れ情報を受信したのでメニューを更新する」という説明でも、誰が何を更新し、誰へ何を通知するのかが曖昧だと減点されやすくなります。本問のキッチンタスクに関する空欄fは、その典型で、正しくはキッチン端末から品切れ情報を受信したらメニュー情報を更新し、全てのテーブルタスクへメニュー更新を通知する、というタスクとしての動作を明確に書く必要があります。ここで「制御装置が更新する」「画面が変わる」といった結果側だけを書いてしまうと、通知の送信元と送信先が不明確になり、タスク間通信の理解を示せなくなります。午後Ⅰで合否を分けるのは、このレベルの記述精度であり、採点講評が「主語を意識せよ」と示唆するのは、まさにここで多くの受験者が抽象的に書いて失点しているためです。 設問3は配膳ロボットの導入に伴う変更で、午後Ⅰとして最も差がつきやすい仕様追加パートです。ここでの読解ポイントは、追加機能の「やりたいこと」を理解するだけでなく、既存の状態管理のどこへ新しい状態が入り、どの条件で指示が発火し、既存の情報構造である注文履歴情報や空席管理情報にどの属性更新が必要になるかを、矛盾なく追えるかです。ロボット搬送開始の条件が、着座人数が1人以上で、かつロボに料理が格納されている場合であるという点は、本文と指示タスクの注記を根拠に導けますが、重要なのは、開始条件が「注文の発生」だけではなく「着座状態」と「格納状態」という複数の状態の積で決まっている点です。これは、単一イベントで動くのではなく、状態が揃った瞬間に次アクションが起動するというイベント駆動設計の典型であり、ここを意識して読むと、後続の空欄gやhが自然に解けるようになります。 テーブルタスクの変更として、利用者が料理を受け取りボタンを押した後に、注文履歴情報の該当料理を配膳済みに更新する必要があるのは、配膳という業務イベントが「料理提供の完了」として状態情報に反映されなければ、以降の精算や片付け指示の判断が正しく動かないからです。ここで単に「配膳完了を登録する」と書くのではなく、どの情報（注文履歴情報）のどの要素（該当料理の状態）をどの値へ（配膳済み）更新するのかを明示できるかが、採点講評が求める記述精度です。さらに指示タスクの変更として、ロボットが障害物で停止し、店員が代替配膳を行う搬送キャンセルのケースでは、搬送エラーを解除し、指示端末に配膳完了ボタンを表示して、手動配膳の完了報告を可能にするという設計になります。ここが難所なのは、ロボットが止まったという現象に対し、単に「店員が対応する」で終わらせず、システムとして誰が完了を確定するのか、確定操作はどの端末で行い、どのタスクへどのように反映するのかという、制御系としての完結性を要求されるからです。午後Ⅰで強い答案は、エラー状態を解除する処理と、手動完了報告のUI提示という二段階の変更を、指示タスクの責務として一貫して説明できます。 本動画で扱う学習ポイントは、第一に、通信時間計算のような基礎的な数値換算を「単位系の監査」として確実に処理すること、第二に、品切れ反映の遅延のような現象を「更新伝搬と状態整合性」の問題として捉えること、第三に、制御装置内のタスクがどの情報を持ち、どのイベントで更新し、どの通知で他タスクへ伝えるのかを、主語をタスクに置いた文章で再現することです。採点講評に照らすと、本問の難所は、図表から言葉を拾うことではなく、タスク間メッセージの因果を時系列で崩さずに書く点にあります。特にキッチンタスクの記述では、全テーブルタスクへの通知という「拡散通知」の構造を明確にしないと、品切れ情報の反映タイミング問題とも整合しなくなりますし、配膳ロボット追加では、着座人数や格納状態といった状態変数がトリガー条件になっていることを見落とすと、開始条件の根拠が曖昧になり、以降の変更点も説明不能になります。結果として、単語は合っているのに論理がつながらない答案になりやすく、ここが合否を分ける典型的な落とし穴です。 最後に、この動画を見る意義をまとめると、令和３年度 秋期 エンベデッドシステムスペシャリスト試験 午後Ⅰ 問2を通じて、組込みシステムの事例問題で最も重要な「状態とイベントとメッセージ」を一体として扱う読み解き方を身に付けられる点にあります。DXレストランという題材は華やかですが、問われているのは、タスク分割の意図、状態更新のタイミング、通知の送受信、仕様追加時の波及といった、IPA過去問で繰り返し出題される骨格そのものです。本動画を視聴することで、計算と読解を切り離さず、業務シナリオをタスクの動作へ落とし込み、追加要件を既存設計へ矛盾なく組み込む手順が再現できるようになります。初見の午後Ⅰ事例でも安定して得点するための土台を作るという意味で、本動画は極めて実戦的な教材になります。
