応用情報技術者 2022年 春期 午後 問09

解答の論理構成

• 【問題文】では外部委託先から派遣労働者を受け入れる際の条件として
  “(a) 作業場所は D 社内であること”、
  “(b) F 君が派遣労働者への作業指示を直接行うこと”、
  “(c) 派遣労働者に衣料品販売業務に関する D 社の社内研修を D 社の費用負担で受講してもらうこと”、
  “(d) F 君が事前に候補者を面接して評価し、派遣労働者を選定すること”
  の4点が提示されています。
• 同じ段落に
  “E 課長から、①これらの条件のうち労働者派遣法に抵触する条件があると指摘”
  とあり、いずれかが法違反であると示唆されています。
• 労働者派遣法では、派遣先が派遣元の労働者を「面接」「試験」等によって個人単位で選抜する行為（いわゆる“事前面接”）を禁止しています。これは「特定行為の禁止」（法第40 条の7）に該当します。
• よって、派遣先が “F 君が事前に候補者を面接して評価し、派遣労働者を選定する” という【問題文】の “(d)” は明確に労働者派遣法に抵触します。
• 以上から、E課長が指摘した条件は “(d)” であり、模範解答とも一致します。

誤りやすいポイント

• (b) を違反と思い込む
  「指揮命令は派遣先が行う」ことは労働者派遣契約の大前提であり、禁止事項ではありません。
• (c) を違反と勘違い
  教育訓練は本来派遣元の責務ですが、派遣先が自社費用で実施すること自体は自由です。
• 条文名を覚えずに「感覚」で判断
  派遣法の“特定行為の禁止”を知らず、(a)～(d)をなんとなく選んでミスするケースが多発します。

FAQ

解答の論理構成

1. 【問題文】には、下線②として
   「②システムが提供する機能と利用者との関係を利用者の視点でシステムの動作や利用例を使って表現した、UMLで記述する際に使用される図法で作成した図」
   とあります。
2. ここで強調されているポイントは
   • 「システムが提供する機能」と「利用者（＝アクター）」の“関係”を示す
   • “利用者の視点”で“利用例”を表現する
   • “UMLで記述する際に使用される図法”
3. UML の各種図のうち、上記 3 点を満たす代表例は「ユースケース図」です。
   • ユースケース図は、アクターとユースケース（システムが提供する機能＝利用例）を関連線で結び、利用者視点でシステム範囲を示すことを目的とします。
4. 以上から、下線②の図を一般的に呼ぶ名称は「ユースケース図」となります。

誤りやすいポイント

• 「システムの動作や利用例」という語から「アクティビティ図」「シーケンス図」を連想してしまう。これらは処理の流れやメッセージ交換を時系列で示す図であり、利用者と機能の対応関係を主眼にしません。
• 「利用者の視点」というキーワードに捉われ過ぎて、画面遷移を示す「ステートマシン図」や「画面遷移図」と混同するケース。ユースケース図は画面遷移を詳細に描くものではありません。
• UML 図法＝全ての UML 図を想起し、具体的名称を答えず「UML 図」とだけ記入してしまう誤答。

FAQ

解答の論理構成

1. 本文の下線③では、開発工程ごとに契約形態を分ける方針が示されています。特に
   “・外部設計は、作業量に応じて報酬を支払う履行割合型の準委任契約を結ぶ。
   　　・ソフトウェア製造は、請負契約を結ぶ。”
   とあり、外部設計とソフトウェア製造で異なる民法上の契約類型が採用されています。
2. 準委任契約は、受託者が善管注意義務を果たして“作業を実施する”ことが目的で、成果物の完成責任（契約不適合責任）は課されません。一方、請負契約は“仕事の完成”が目的であり、受託者は完成責任を負うことが民法で定められています。
3. したがって、外部設計（準委任）についてはＺ社に成果物の完成責任を問えませんが、ソフトウェア製造（請負）については完成責任を問うことが可能です。
4. 解答群を検討すると
   ア：要員のアサインはＺ社の裁量であり、Ｄ社が直接強制できるわけではないため誤り。
   イ：請負契約に基づき“合意した外部設計に基づいたソフトウェア製造”についてＺ社に完成責任を問える——本文と民法の規定に合致して正しい。
   ウ：請負契約なら契約不適合責任を問えるので誤り。
   エ：外部設計は準委任契約であり契約不適合責任を問えないため誤り。
5. よって正解は「イ」となります。

誤りやすいポイント

• 契約形態の違い（請負 vs 準委任）を混同し、すべて請負と誤認する。
• 「契約不適合責任＝完成責任」と短絡し、準委任でも同じ責任を追及できると勘違いする。
• 要員の継続配置を委託元が指示できると誤解（独立した事業者である点を失念）。
• テストフェーズで発見した欠陥通知のタイミングと請負の責任範囲を混同し、通知すれば責任追及できないと思い込む。

FAQ

解答の論理構成

• ①【問題文】には「ソフトウェア製造作業を終了した Z 社からの納品物（設計書、プログラム、テスト報告書など）に対して、D 社は6月最終週に a し、その後、支払手続に入る。」とあります。
  • 納品物を受領して支払手続に進む前に行う正式行為は、成果物の受入れ検査を意味する「検収」です。
  • したがって a には「検収」が入ります。
• ②同じ段落に「開発委託契約の条文中に “ソフトウェアの b は D 社に帰属する” という条項を加える。」とあります。
  • ソフトウェアの帰属先を明示する権利は知的財産権の中でも著作物であるプログラムの「著作権」です。
  • よって b には「著作権」が入ります。

誤りやすいポイント

• 「検収」と「受領」の混同
  • 受領は単なる受け取り、検収は内容確認と受入れ判定という契約上の重要工程です。
• 「著作権」と「所有権」のすり替え
  • ソフトウェアは無体物なので物理的な所有権でなく著作権を移転させる条項が必要です。
• 請負契約＝成果物の品質保証付きという理解不足
  • 検収で合格しなければ支払いが発生しない点まで押さえておく必要があります。

FAQ

解答の論理構成

1. 問題文では、プロトタイピングを採用することによって “営業部門の意見に際限なく耳を傾けると外部設計の完了が遅れる” という新たなリスクが発生すると述べています。
2. このリスクを抑えるために、E 課長は F 君に “追加・変更の要求事項の c 提出件数の上限、及び対応工数の上限を定め” と指示しました。
3. 外部設計の完了遅延を防ぐために必要なのは、要求事項を受け付ける「期限」を設けることです。期限を過ぎた要求は次フェーズへ繰り越すことで、スケジュールを守ることができます。
4. したがって、c に入る語は “提出期限” が最も適切となります。

誤りやすいポイント

• 「提出件数そのものを制限する」と早合点し、「総」「累計」などの語を入れてしまう。
• “上限” という言葉に引きずられ、「最大」「上限値」を入れてしまう。実際には「いつまでに出すか」を定義しないと手戻りは防げません。
• プロトタイピング＝柔軟な変更受付と考え、「制約を設けないのが正解」と誤解する。プロトタイピングでもスコープ管理は不可欠です。

FAQ

解答の論理構成

1. リスクの確認
   • 本文では「二つ目に、Z社の製造したプログラムの品質が悪いというリスクを挙げた」とあり、品質低下が重大リスクです。
2. D社がとれる対策の範囲
   • 下線部④に「ソフトウェア製造は請負契約であるが、D社として実行可能な品質管理のタスクを追加し、このタスクを実施することを契約条件に記載」と記述されています。
   • 請負契約であっても、発注者が途中成果物を確認する“レビュー”は契約違反になりません。
3. 最適な品質管理タスクの導出
   • 検収や受入試験は“納品後”の作業であり「作業の途中」で行うタスクではありません。
   • コード・設計書を順次点検し、欠陥を早期に発見できるレビューが最も適切です。
4. 結論
   • よって、追加すべきタスクは「作業の途中で品質レビューを行う」となります。

誤りやすいポイント

• 「受入検査」や「検収」を答えてしまう
  納品後の工程であり“途中”のタスクではありません。
• 「テスト追加」と回答する
  テストは実装完了後が主で、設計段階の欠陥を早期に発見できません。
• 「進捗会議」を品質管理と混同する
  進捗把握は管理タスクであり、品質を直接高める施策ではありません。

FAQ

解答の論理構成

1. 事実整理
   • 本文では、スマートフォン向けブラウザが「5種類以上」存在し、「上位2種類のブラウザで約95%を占める」と明記されています。
   • しかし「開発スケジュール内では最大2種類のブラウザの動作確認しかできない」と制約が示されています。
2. リスクと対応策
   • 他ブラウザで「文字ずれなどの問題が生じるリスク」が指摘されています。
   • そこでE課長は「8月下旬のサービス開始前に⑤ある情報を公表すること」を条件に、動作確認を「上位2種類のブラウザ」に限定すると営業部門と合意しました。
3. 公表すべき情報の推論
   • 合意の前提は “利用者に対してサポート範囲を明示し、不具合が起こり得るブラウザを事前に知らせる” ことです。
   • よって、公表する内容は「上位2種類以外のブラウザでは問題が生じる可能性」を示す注意喚起になります。
4. 結論
   • 解答は模範解答どおり
     「上位2種類以外のブラウザでは問題が生じる場合があること」

誤りやすいポイント

• 「上位2種類のブラウザを推奨」とだけ書くと、“他ブラウザで問題が起こる” という肝心のリスク開示が欠落します。
• 「動作保証ブラウザ一覧」など製品名を羅列すると、本設問の趣旨（リスクの周知）がぼやけます。
• ブラウザ数や利用シェアなどの数字「5種類以上」「約95%」を解答文に含める必要はありません。公表内容そのものを答える設問です。

FAQ