https://www.ap-siken.com/kakomon/06_haru/pm06.html

確かに模範解答「退職表を共有用スキーマに配置する」で退職分析は実現できますが、この内容を実施することに法的な問題は無いんでしょうか？
共有用スキーマに配置する退職表には会社番号、従業員番号、在籍期間および退職理由が含まれています。従業員番号は通常、社内システムのログインIDにもなっており他社公開すべきものではありませんし、退職者の転職先人事部社員であれば、自社と同業種であること、在籍期間および退職理由の情報を用いて退職者表から個人を識別できるように思われます。
模範解答からは統計処理や匿名加工処理をしているようには見えないので、記載されていること実施した場合、情報漏洩に該当したりしないのでしょうか？

問題文中に特に記載はありませんが、退職者本人の
同意があることを前提にしているのではないでしょうか。
自分は、試験問題の中だけの世界と割り切って気にしていませんが。
どうしても納得できなければ、IPAに問い合わせてみては？

応用情報 令和6年 春期 午後 問6
https://www.ap-siken.com/kakomon/06_haru/pm06.html

> 共有用スキーマに配置する退職表には
> 会社番号、従業員番号、在籍期間および退職理由が含まれています。
> 従業員番号は通常、社内システムのログインIDにもなっており
> 他社公開すべきものではありません

この点は間違っています。
共有用スキーマに配置したからといって、このSaaS事業者と契約しているすべての中小企業にデータが公開されるわけではありません。

具体的には、問題文の〔単一データベース・個別スキーマ方式の検討〕で登場するビュー(VIEW)という仕組みを使います。ビューの出題例を挙げておきます。

ソフトウェア開発 平成17年 春期 午前65
https://www.ap-siken.com/kakomon/17_haru/q65.html

この午前問題に登場する 注文 と 商品 という実表(TABLE)が共有用スキーマに配置されていると想像してください。実表(TABLE)が共有用スキーマにあっても、利用者から直接アクセスできない適切なアクセス許可を設定すれば、この実表(TABLE)のデータを自由に読み取ることはできません。

次に、この午前問題の選択肢ア～エに登場するビュー(VIEW)が個別会社用のスキーマに配置されていると想像してください。そして上記の実表(TABLE)に対して、これらのビュー(VIEW)からのアクセスだけを認めるアクセス許可を設定します。

すると、個別会社用の利用者は、実表(TABLE)の存在を知らないまま、実表の部分集合であるビュー（仮想表、一時表）があたかも実表であるかのようにアクセスできます。

今回の午後問題も同様で、
次の実表を共有用スキーマに配置したからといって、これが契約中のすべての中小企業にデータ公開されるわけではありません。
    退職（会社番号，従業員番号，在籍期間，退職理由）

次のようなビューを介したアクセスのみを個別会社の利用者に認めることで、会社番号と従業員番号の存在を隠すことができます。
    退職ビュー（在籍期間，退職理由）…特定の業種のみでフィルタ済

返信ありがとうございます。
退職者の同意は取れても、(元)社員の従業員番号を不特定多数の他社が知ることができる状態は何か気持ち悪い気がしますね。設問2で情報漏洩の対策についてわざわざ触れていますし…
時間が出来たら問い合わせてみようと思います。

>jjon-comさん
回答ありがとうございます。
共有用という名前から全利用者に共有されるものだと思っていましたが、そうではないということですね。
PUB.退職へのアクセスを各スキーマに配置されたビューのみからに制限することで、
ユーザ企業に会社番号や従業員番号を見せない仕組みとなることは分かりました。
ただ、新たに退職者が発生した場合にはPUB.退職にデータ追加する必要があるので、
結局、ユーザ企業はPUB.退職にアクセスしないといけない気がします。
Saas事業者がユーザ企業の代わりにPUB.退職にレコード追加する運用が想定されているのでしょうか。

（追記）
事前にINSERT権限だけ付与すれば、ユーザ企業による退職表へのデータ追加はできそうですね。
GRANT INSERT ON PUB.退職 TO Cxxx;

> 事前にINSERT権限だけ付与すれば、
> ユーザ企業による退職表へのデータ追加はできそうですね。
> GRANT INSERT ON PUB.退職 TO Cxxx;

いいえ、ダメです。それだと、会社番号 123（スキーマ名 C123）の企業が、会社番号 456 のレコードを追加できてしまいます。

人事評価システムを中小企業に提供するSaaS事業者であるこのK社は、
（例えば）会社番号が 123 であるユーザ企業に対して、
PUB.退職 実表の中の、会社番号が 123 のレコードだけを CRUD(Create, Read, Update, Delete) できるビューを C123.退職 として提供します。
ユーザ企業は PUB.退職 実表の存在は知らず、C123.退職 というビュー（仮想表、一時表）をあたかも実表だと思って、C123.退職 に対してレコードをCRUDします。（更新可能なビューについては No.3 に登場しました）
この場合、C123.退職 に存在する列は（従業員番号，在籍期間，退職理由）の3列になるでしょう。会社番号は 123 で全レコード固定値なので、その列の存在を知らせる必要がありません。

ちなみに、SaaS契約している各ユーザ企業は、
> ビュー（仮想表、一時表）をあたかも【自社専用の】実表だと思って
利用しますけれど、実体は共有用スキーマに配置された1つの実表であり、在籍期間と退職理由は同業他社から参照可能になるわけですから、
退職分析機能を利用するユーザ企業に対しては、その仕組みについて注意をうながし、契約書によってあらかじめ承諾を得ておくことになるでしょう。

詳細に解説いただき、ありがとうございます。
No.3の回答と合わせると、実表PUB.退職に加えて２つのビュー
 C123.退職ビュー（在籍期間，退職理由）…特定の業種のみでフィルタ済
 C123.退職ビュー２（従業員番号，在籍期間，退職理由）…実表の会社番号=123のレコードだけをCRUDできる
を配置することにより、退職分析機能と情報漏洩対策を両立させると理解しました。