この記事について
日本公認会計士協会（JICPA）東京会テクノロジー委員会が2024年6月に公表した研究報告書「公認会計士のためのQ&Aで学ぶテクノロジー」（東京C.P.A. 公認会計士業務資料集 No.64）は、全16問のQ&A形式でITの基礎から実務への応用までをカバーしている。
この記事では、同報告書と講義資料から実務で特に役立つテーマを抜粋し、独自の図解と補足を加えて再構成した。
報告書の4章構成:
- 第1章: テクノロジーに関する心構え（Q1〜Q2）
- 第2章: テクノロジーに関する知識（Q3〜Q7）
- 第3章: 監査にも役立つテクノロジーやシステム管理の知識（Q8〜Q13）
- 第4章: 企業のテクノロジー導入時の留意事項（Q14〜Q16）
1. ビジネスを「情報の流れ」で捉える（Q1）
テクノロジーの理解 ≠ 要素技術の暗記
報告書が冒頭で強調しているのは、公認会計士に求められるITの理解とは、プログラミング言語やデータベースの仕組みを覚えることではない、ということだ。
要素技術（Technology）ではなく、ビジネスでの情報（Information）がどのように用いられているか、その情報の取扱いに要素技術がどう貢献しているか理解すること
会計はビジネスの写像だとすれば、その写像が作られるまでの情報の流れを追うことが、会計の信頼性を担保する前提になる。情報は作るだけでなく、組織内外で利活用されて初めて意味をなす。
3つのレイヤーで情報システムを立体的に見る
報告書では、情報システムの使い方の違いを「戦略」「業務プロセス」「手続」の3つのレイヤーに分けて捉えることを提案している。
書店ビジネスで見る戦略レベルの違い
報告書では書店を3類型に分類し、情報システムの使い方の違いを示している。
| 街なかの書店 | 無店舗型ネット書店 | 大型書店チェーン | |
|---|---|---|---|
| 店員の知識 | 店主の知識に依存 | 店員が不在 | スタッフの能力に依存 |
| 品数 | 少ない | 多い | 多い |
| 情報技術の活用 | 活用していない | 口コミ、在庫情報や入庫情報、配送トラッキング | 予約取置サービス、書店在庫状況提供、店内の棚配置情報提供 |
| コアバリュー | 店主の専門性 | 利便性をコアとして、戦略的に情報システムを活用 | 情報を活かしたプロモーションや物流管理 |
同じ「本を売る」ビジネスでも、情報技術の活かし方がまるで違う。この「使い方の違い」を把握することが、情報システムの理解への第一歩になる。
手続レベル: 棚卸業務の例
一つの棚卸業務でも、データの生成方法によってリスクの所在が変わる。
手続レベルでは、情報の発生源が何かを把握することが理解の主眼となる。
公認会計士の強み: 組織横断の俯瞰力
報告書は公認会計士の強みを「内部統制等の検証の過程で、組織横断的視点で業務を俯瞰できること」と述べている。現場の担当者が自部門の最適化に閉じがちなのに対し、会計士は全社的な情報の流れを見渡せる。
ただし注意すべきこととして:
- 部分最適に陥る可能性（手段の目的化）を排除すること
- 特定の統制の有効性に過度に依存・偏重しないこと
2. テクノロジーの波に溺れないための考え方（Q2）
ハイプサイクルを知っておく
テクノロジーには流行り廃りがある。報告書ではGartner社のハイプ・サイクル（2024年7月版）を引用し、各テクノロジーの位置づけを示している。
- 過度な期待のピーク: 検索拡張生成(RAG)、サステナビリティ管理ソリューションなど
- 幻滅期: NFT、Web3、メタバースなど
- 啓発期→安定期: ブロックチェーン、人工知能（全般）
生成AIは「過度な期待のピーク」付近にあり、サクセスストーリーが多く紹介される一方で失敗も少なくない段階にある。
AIの進化を段階で捉える
| 段階 | 概要 | 例 |
|---|---|---|
| 制御プログラム | ハードウェア・ソフトウェアにより単純な振る舞いがあらかじめ決められている | エアコンの温度調整、洗濯機の水量調整 |
| 機械学習 | 探索・推論・知識データを利用して複雑な振る舞いをする技術。多くのサンプルデータを基に入出力関係を統計的に学習 | 検索エンジン、交通渋滞予測 |
| ディープラーニング | 機械学習で重要とされるサンプルデータの特徴量を数学的アプローチにより多階層に深め自動学習する手法 | ChatGPT（大規模言語処理事前学習モデル） |
生成AIは文章を「理解」しているわけではなく、「もしもしかめよ」の次に「かめさんよ」が来る確率が高い、という統計的な予測を精緻化したものだ。
既存の知識に立ち返る
報告書の結論は明快だ:
勃興する個々のテクノロジー、ツールの新規性に振り回されることなく、常に既存の知識に立戻り、応用を加えながら整然として対応する事が重要
新しいツールが出てきたら、「従来の枠組みのどこに位置づけられるか」を考える。「データの品質」「入出力の妥当性」「アクセス管理」といった情報管理の基本は、どの時代のテクノロジーでも変わらない。
3. クラウドサービスを正しく理解する（Q3）
NIST定義による5つの特性
クラウドサービスとは、インターネットなどのネットワーク経由でITリソースを提供するサービスのこと。NISTの定義では以下の5特性を備える:
- オンデマンド・セルフサービス: 必要なリソースを必要な時に必要なだけ、自分で利用できる
- 幅広いネットワークアクセス: インターネット経由でどこからでも利用できる
- リソースの共用: 複数の利用者が同じリソースを共有する
- スピーディな拡張性: 利用状況に応じてリソースを迅速に増減できる
- サービスが計測可能: 利用したリソースの量や使用状況を把握できる
IaaS・PaaS・SaaSの棲み分け
公認会計士の実務で直接触れるのは、ほぼSaaS（freee、マネーフォワード、Gmailなど）だ。ただし、クライアントのIT環境を理解するには、IaaS・PaaSの概念も押さえておきたい。
セキュリティは「タンス預金 vs 銀行の金庫」
「クラウドはインターネット経由だから危険では?」という疑問に対して、タンス預金（オンプレミス）と銀行の金庫（クラウド）のどちらが安全かを考えるとわかりやすい。クラウド事業者は「狙われることを前提に」セキュリティ専門チームと最新の防御技術に投資している。
公認会計士の組織規模別の採用例
| 項目 | 小規模 | 中規模 | 大規模 |
|---|---|---|---|
| 仮想デスクトップ | 仮想PC | 仮想VDIサーバー | 仮想VDIサーバー |
| ID管理 | 必要に応じて検討 | 必要 | 必要 |
| 端末管理 | 必要に応じて検討 | 必要 | 必要 |
| ログの監視 | ー | 必要 | 必要 |
| データ分析 | ー | ー | 必要に応じて検討 |
組織が大きくなるほど、セキュリティや管理のコストは増える。小規模なうちからクラウドベースで設計しておくと、成長に伴うスケーリングが楽になる。
4. システム開発のフローを押さえる（Q8）
システム開発等のルール・体制・環境・業務の全体像
IT全般統制を理解するには、システム開発がどういう要素で構成されているかを把握する必要がある。
ウォーターフォール型の開発フロー
ウォーターフォール型開発は、各段階で承認を経て次のステップに進む。監査では、この承認の証跡が統制の根拠になる。
| 段階 | 主な業務 |
|---|---|
| 企画 | システム構想の策定。目的・範囲・期限・コスト・運用方法を定める |
| 要件定義 | 業務要件定義。ユーザーの要求事項を整理し優先順位を決定 |
| 調達 | 自社開発か購入かの評価、外部委託範囲の決定、RFP作成 |
| 設計 | 基本設計・詳細設計。データ変換計画の策定 |
| 開発 | コーディング基準に沿った実装。プログラム作成、データ変換プログラムの作成 |
| テスト | 単体テスト → サブシステムテスト → システム結合テスト → インターフェーステスト |
| 受け入れ | 受け入れテスト・承認・検収。要件定義通りに作られたかを確認 |
| 本番移行 | 本番移行計画・承認・実施と確認。データ移行の実施と確認 |
| 導入後評価 | 妥当性検証・効果測定。開発プロジェクト評価、改善事項の把握 |
5. 変更管理 — 「最新版はどれ？」問題を解消する（Q9）
ファイル名管理の限界
経理の現場でプログラムVer2_final_更新済みのようなファイル名が並んでいるのを見たことがあるだろう。少人数ならまだ回るが、数十人〜数百人の開発チームではこの方法は破綻する。
Gitを用いたソースコード変更の流れ
現代のソフトウェア開発では、Gitというバージョン管理ツールが標準的に使われている。
この仕組みの肝は、レビューを経ないと本番に反映されないことだ。コンフリクト（同じ箇所を複数人が修正した衝突）が起きた場合は、チーム内で協議してどちらを採用するか決める。この過程もログとして残る。
6. アジャイル開発の本質を見誤らない（Q12）
ウォーターフォール vs アジャイル
アジャイルソフトウェア開発宣言（2001年）
プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
アジャイルが向かないケース
- 顧客ニーズの変化が乏しく、継続的リリースが想定されないソフトウェア
- プログラム間、データ間が密に繋がっているソフトウェア（ERPなど）は、要件を網羅的に把握した上で配布する必要性が高まる
アジャイル開発の目的は素早く継続的なリリースを行い、顧客からのフィードバックを得てプロダクトを改善すること。それに適さないプロジェクトでは効果が薄い。
7. SOCレポートの読み方と落とし穴（Q13）
SOC（System and Organization Controls）とは
米国公認会計士協会の基準に基づく保証サービスのこと。監査法人や公認会計士が、受託会社のシステムの管理状況やセキュリティの状況を評価し、レポートとしてまとめたもの。日本では保証業務実務指針3402が対応する。
SOCレポートの種類
| 種類 | レポートの内容 | 想定利用者 |
|---|---|---|
| SOC 1 | 受託会社が委託されている業務の中で財務報告に係る内部統制を対象に、受託監査人が手続を実施した結果と意見を表明した報告書 | 委託会社の内部監査人、委託会社の会計監査人 |
| SOC 2 | 「セキュリティ、可用性、処理のインテグリティ、機密保持及びプライバシー」に関するTrustサービス基準に従い、関連する内部統制に対して手続を実施した結果と意見を表明した報告書 | 委託会社、委託会社監査人、委託会社に係る規制当局 |
| SOC 3 | SOC 2レポートで評価した内容の簡易版。統制のテストとその結果の詳細な記述は含まれない | 不特定多数に一般公開される |
- Type 1レポート: 整備評価に限定
- Type 2レポート: 整備評価 + 運用評価までカバー
監査ではSOC 1 Type 2の入手を目指すのが基本。
SOC 1レポートを鵜呑みにしない4つのチェックポイント
| 項目 | 内容 |
|---|---|
| 委託会社の担当者が行う統制 | SOC 1は受託会社の統制を評価するもの。委託会社側の担当者の運用は評価項目の対象外。また、SOC 1の発行体のシステム構成や管理手法等に応じて評価対象の内部統制も異なる |
| 例外事項の有無 | 内部統制の評価の結果として例外事項が検出されていることがある。その例外事項が委託会社の内部統制評価にどの程度影響するか留意する必要がある |
| 受託会社監査人の能力等 | 受託会社監査人の職業的専門家としての能力と受託会社からの独立性を評価しなければならない |
| 対象期間 | SOC 1レポートの基準日や対象期間が、委託会社が必要とする基準日や対象期間と一致しているか。一致していない場合はロールフォワード・レター（ブリッジ・レター）の入手を検討 |
8. 会計システム導入で公認会計士ができること（Q14・Q16）
公認会計士がシステム導入支援に期待されること
公認会計士には会計に関するスキルセットはもちろん、IT・内部統制に関する知識・経験が期待されている。販売管理システムの導入を例にすると:
- 受注情報のマーケティングや管理会計への活用を想定した設計
- 仕訳生成・決算に必要な情報の連携方針の立案
考慮すべき5つのポイント
- 会社側の開発受け入れ体制の把握: メンバーのスキルセットやモチベーションを理解する
- 企業の特徴と選定するシステムのマッチング: 目的と手段が入れ替わっていないか確認する
- システム間連携を行う目的の把握: なぜ連携するのか、何の情報が必要なのかを整理する
- 会計システム側から販売管理システム側へ求められる仕様の整理: 上流の使い勝手だけでなく、下流（会計）への連携を考慮する
- 販売管理システムユーザー側のオペレーションの理解・調整: 現場のやりたいことを組んでシステムに反映する
会計ソフト選定の3つの軸
| 軸 | 特徴 | 向いている企業 |
|---|---|---|
| 会社規模にあるプラン | 規模に応じたプランがある。連携機能重視 | 成長中の中小企業、スタートアップ |
| 申告に強みを持つシステム | 税務業務との連携が前提。税理士を中心に活用 | 記帳代行+税務申告をワンセットで行う企業 |
| ERP型の会計システム | ヒト・モノ・カネ・情報を統合管理 | 上場企業、大規模組織 |
導入支援の3ステップ
| 段階 | 内容 |
|---|---|
| 選定 | 紹介地や業界慣行などを把握した上で業務フローも理解し、システムの構築案を検討する |
| 導入支援 | 初期設定、データのインポート、パラメータの設定。大規模ならRFP作成も |
| 運用サポート | 仕訳連携の方法、操作方法の指導。業務フローの全体最適化 |
まとめ
この報告書が繰り返し伝えているメッセージを3点にまとめると:
- テクノロジーそのものを深く知る必要はない。ビジネスにおける情報の使われ方を理解せよ
- 流行のツールに振り回されず、情報管理の基本原則に立ち返れ
- 公認会計士の強みは組織を横断的に俯瞰できる視点にある。その強みを自覚して活かせ
テクノロジーに苦手意識がある会計士も少なくないだろうが、ここに書かれた内容は「エンジニアになれ」という話ではない。ビジネスと情報の関係を、会計の専門家として理解するための入り口だ。
出典: 日本公認会計士協会東京会テクノロジー委員会「公認会計士のためのQ&Aで学ぶテクノロジー」（2024年6月、東京C.P.A. 公認会計士業務資料集 No.64）