🦉 Episode 3: 見えない壁 --- IS部門の役割と職務分離

入社3日目の朝。カイロウがデスクに着くと、先輩の鷹山さんが珍しく険しい顔をしていた。

💼「今朝、内部監査部からレポートが上がってきた。経理部の佐藤さんが、自分で仕訳を入力して、自分で承認して、自分で元帳に転記していた」

🦉「それの何がまずいんですか？ 佐藤さんは仕事が早いということでは……」

💼「逆だ。それは職務分離（Segregation of Duties）が全くできていないということ。1人が入力・承認・記録の全てをできる状態は、不正や誤りが検出されない最も危険な状態だ」

カイロウは翼を小さく震わせた。森で食料を管理する時、1羽のフクロウだけが食料庫の鍵を持ち、食料の出し入れも記録もしていたら、食料が減っても誰も気づけない。

---

職務分離 --- 「1人に全てを任せるな」

先輩はホワイトボードに3つの円を描いた。

💼「IS部門の職務分離は、大きく3つの機能を分けることが基本だ。開発、運用、セキュリティ管理」

🦉「開発と運用を分ける理由は何ですか？」

💼「開発者が本番環境にアクセスできたら、テストを通さずにプログラムを変更できる。運用担当者がプログラムを変更できたら、不正な処理を仕込める。だから開発者は本番環境にアクセスできない、運用担当者はプログラムを変更できないようにする」

🦉「なるほど……。でも、小さな会社だと1人で両方やらざるを得ないこともありませんか？」

💼「その通り。人数が少ない場合は補完的統制（Compensating Controls）を導入する。例えば、独立した第三者によるレビュー、詳細なログの記録と監視、定期的な監査。完璧な分離ができなくても、リスクを軽減する手段はある」

カイロウはメモを取りながら、IS部門の中に見えない壁が引かれている理由を理解し始めた。壁は人を信用していないから建てるのではない。人が誤りを犯す可能性を前提に、組織として安全を守るために建てるのだ。

---

システム開発ライフサイクル --- 「設計図なしに家は建てない」

午前の後半、先輩はシステム開発の話に移った。

💼「新しいシステムを作る時、いきなりプログラミングを始めると思うか？」

🦉「……設計が先ですか？」

💼「その前にもっと大事なことがある。要件定義だ。何を解決したいのか、どんな機能が必要なのか、利用者の要求を明確にする。そこからSDLC（Systems Development Life Cycle：システム開発ライフサイクル）が始まる」

先輩はホワイトボードに流れを描いた。

この章の試験での位置づけ

CPA Exam Blueprint（試験設計図） とは、AICPAが公式に公表している「試験で何が、どのくらいの比率で、どのレベルで問われるか」を定めた文書です。 全ての出題はこのBlueprintに基づいて作成されます。つまり Blueprintを知ることは、試験の設計者の意図を知ること です。

Key points of this Chapter: IS部門の組織構造は、IT内部統制の出発点。職務の分離（Segregation of Duties: SoD） ―特に開発（Programmer）・運用（Operator）・DBAの三者の独立性―が最頻出。CIO/CISO/CTOの報告ライン、SoD確保が困難な小規模組織での補完的統制（Compensating Controls）も頻出。MCでは役職名と職務内容のマッチング、TBSではSoD違反シナリオの是正統制を問う問題が定番。

前提知識 --- この章に入る前に、分かっているとラクなこと

---

1. なぜこの論点が必要か（Why）

ISC科目の全体像 --- 今どこにいるか

【ISC科目の全体構造】