CaFeterria

入出金に関する会計仕訳の起票は、付加価値を生まないルーティンワークだけに

経理・財務部門にとっては自動化を進めたい作業の一つである。

特に中堅・中小企業では、自動化が進んでいないことが多い。

実現には多様なサービスを活用する必要があるため、

それなりの投資額になってしまい、先送りにしてきた背景がある。

本稿では、比較的安価に導入可能なサービスをご紹介したい。

■入出金データの収集：例）BizHawkEye等
複数の金融機関取引を、同一インターフェースで操作可能とするマルチバンクサービス。

入出金明細データの取得を自動化

■入金内容の把握：例）仮想口座サービス
かなり以前から金融機関が提供する入金内容の特定の容易化を目的としたサービス。

仮想口座番号をキーにして入金内容を把握

■出金内容の把握：例）SMBCパーフェクトクリア等
口座引落の明細特定の容易化を目的とした、支払用仮想口座サービス。

仮想口座番号をキーにして出金内容を把握

上記サービスを組み合わせて会計システムにデータを取り込み、

取引内容に応じた仕訳パターンを会計システムに設定すれば、仕訳生成の自動化が可能となる。

【投稿担当：R.T.】

『ERPグローバル展開と内部統制評価制度への対応』　執筆者：清水

https://www.crossfields.co.jp/cms/wp-content/uploads/2025/08/magazine_vol47.pdf

グローバル化が進む中で、企業におけるERPシステムのグローバル展開は、経営の可視化や業務効率化、ガバナンス強化など、多くの目的をもって進められています。

同時に、財務報告に係る内部統制報告制度への対応は、もはや一部の企業だけの課題ではなく、グローバルで標準化された業務・システムを展開する際にも避けて通れない検討事項となっています。

本稿では、こうした2つのテーマ‐ERPのグローバル展開と内部統制対応‐が交差する領域に焦点を当て、標準テンプレート構築、内部統制への対応、評価体制のあり方といった観点から、具体的な考慮事項を整理しています。

グローバルでのERP導入・展開を計画されている企業、あるいは内部統制への対応を見直したいとお考えのご担当者にとって、今後の取り組みの一助となる内容になっていると思います。

是非ご一読ください。

最近、プロジェクトで「言った言わない」や誰の責任なのかという課題解決に直接関係ない話に時間を使われてしまう場面に遭遇しました。

従来のウォーターフォール型のシステム開発プロジェクトでは、

前工程までの意思決定が重視されるため、過去の経緯を振り返るプロセスが挟まり、

問題解決の意思決定までに時間が掛かっていました。

しかし、昨今のプロジェクトでは物事を迅速に前へ進めるスピード感が求められていると感じています。

特に海外のメンバが主導するグローバルプロジェクトでは、その傾向が強いと感じており、

私が経験したSAPロールインプロジェクトでは、

問題が発生すると海外メンバが即座に関係者と打ち合わせを設け、

取るべき対応を重点的に議論していたことが印象的でした。

基幹システムなど大規模なシステムであれば、

開発手法としてのウォーターフォール型は有効なアプローチではありますが、

長期間のプロジェクトの途中で、状況を一変する出来事が起こることは珍しくないため、

プロジェクトメンバには、そのような事態に柔軟に対応できるアジャイル的思考が必要だと感じています。

【投稿担当：K.Y.】

私はSAPの導入PJに参画しており、FMのチームに所属しています。

FMは「予算管理」の機能です。

『予算管理はCOを利用すればよい』と考える人もいると思います。

FMは予算の管理・執行を担います。

特に使用可能額の上限を定め、その範囲内でのみ支出可能とすることが出来る点は特徴的です。

例えば、上限が100万円の場合、100万円を超過した支出はブロックすることが可能です。

一方、COは組織内部の収益・費用の分析と管理を担います。

「どの部門が利益に貢献しているのか」など、経営分析に焦点を当てています。

FM導入時の大事な点を2つ紹介します。

1つ目は「予算管理ルールの明確化」です。
FMはルールベースで動くため、予算チェックタイミングや予算超過時の動作（エラー/警告/許可）などのルールを定める必要があります。

2つ目は「他モジュールの理解」です。
「予算管理」という特性上、FMは他モジュールと密接に連動するので、FMの担当者がFI,MM等の知識を持っていることで効果的な導入が可能です。

FMとCOと両立させることで、予算管理と経営分析の両方が実現可能であり、「予算統制とコスト管理」や「中長期的な予算計画・経営計画の改善」などに役立てられると思っています。

【投稿担当：R.M.】

私はグループ各社に対し、共通会計システムの導入と業務プロセスの標準化を行うPJで、ユーザ側の各種検討を支援しています。

この“標準化”とは言うは易く行うは難しであり、実現に向けては大小様々な課題や衝突があります。

それらの解決に際し、私が心がけているのは、頭ごなしに方針を押し付けるのではなく、関係者にしっかりと納得してもらうことです。

業務プロセスを標準化することで、とある会社の業務が複雑化してしまうようなケースでは、（当たり前ではありますが） 現場担当者から反発がありました。
その際、“PJ方針だから“と推し進めることもできましたが、今後もPJを円滑に進めるためには、ここでしこりを残さない方が良いと考え、親・子会社双方の役員も交えた検討の場を設けました。
その結果、関係者間でPJ方針を再確認した上で、個社の事情を踏まえた現実的な落としどころ（ToBe業務）を見つけられ、今に至るまで大きな問題無くPJを推進できています。
今後も各社の事情にも配慮しつつ、グループ全体として最適な結論へ導けるよう、支援していきたいと思います。

【投稿担当：H.Y.】

私が参画しているシステム再構築プロジェクトでは、ChatGPTを活用して、現行資産である ABAP プログラムの一部を Java に、運用スクリプト（UNIX シェル）を PowerShell に自動翻訳する取り組みを進めています。

少量のコードなら正確に変換できましたが、コード量が増えると精度が低下する課題に直面し、指示文の調整やコードの分割を工夫しながら試行錯誤を重ねてきました。

しかし、今年 2 月に ChatGPT の新モデル「o3-mini-high」 が登場したことで状況が一変しました。従来の「o4」では 100 ステップ程度 のコード変換が限界でしたが、新モデルでは 300 ステップ以上 のコードも高精度に翻訳できるようになりました。

今後も新たなモデルの登場が期待される中、AI の活用が当たり前になるシステム開発の時代が目前に迫っていると強く感じています。

※ ABAP：SAPという企業向けシステムで使われるプログラミング言語
※ UNIXシェル：サーバー向けのOSであるUNIXのコマンドを自動実行するためのプログラム
※ PowerShell：Windowsの設定変更やファイル操作、ネットワーク管理などのWindowsのシステム管理を自動化するためのスクリプト言語

【投稿担当：A.F.】

発展目覚ましいAI技術ですが、最近プロジェクト内で議事録自動作成ツールに触れる機会があったので、私なりに評価してみたいと思います。

まずAIが作成した議事録の良さは、「読みやすい」の一言です。
AIならではの言葉・文法の怪しさ、会話前後の若干の飛躍は見られるものの、割と細かいキーワードが拾えていたり、発言のトーンを解析してか、会議内で誰がどの部分を強調したのか明確に書かれていたりと、「どんな会議だったか」の全体感がよく伝わってきました。

反面、”議事録”としては非常に「わかりにくい」です。
背景や言外の情報の補完がなく理解度が挙げづらい点や、発言順に囚われない会議目的に準じた体系立った整理がなされていないため、発言の関連性・整合性が読み取りづらい点など、自身が駆け出しの頃に書いてしまっていた”会話録”止まりな印象を受けます。

前提から結論までの論理展開として充分な表現かといった観点での所感なので、実のところ、前者の点が補えれば充分だ、という声も多いとは思いますが、理解度の低い会議で議事録の書き手になった際の、方位磁石的な使い方から始めるのが良いかな、と考えます。

【投稿担当：K.T.】

多くのプロジェクトは複数チームで体制が構築されており、チーム横断の適切なコミュニケーションが重要となります。

チーム横断で検討が必要な事柄について、チーム間のコミュニケーションが不十分な場合、

後々他チームから「その話は認識できていなかった。その検討結果は許容できない。」と

自チームで一度検討が完了したことを再検討しなくてはいけないことがあります。

このような手戻りを防ぐためにも、検討時には「チーム内で検討を留めてよいか」

または「他チームとの認識合わせが必要なのか？またそのチームはどこか？」を都度考える必要があります。

また、チーム横断の課題は管理主体チームが曖昧なことが多いため、対応を漏らさないためにも、

管理主体チームを明確にしたうえで、横断課題としての管理が必要となります。

私はしばしば自身の視野の狭さを痛感することがあります。

そのため、チームを横断した適切なコミュニケーションを常に意識しなければならないと、

強く思っている今日この頃です。

【投稿担当：Y.N.】

私は現在システム導入PJ支援に携わっており、このPJではアジャイル開発手法を取り入れてシステム開発を行っています。

また開発の際は、業務に必要な最低限の機能に絞り込み優先順位を付けてリリースするスモールスタート方式を採用しており、なるべく短サイクルで要件定義～リリースまでできるようにしています。

この開発手法の良いところは、短期リリースかつ毎回リリースする機能範囲が限定的なため、都度ユーザーから具体的なフィードバックをもらえ、迅速に改善要望対応ができることです。

実際に利用後すぐに、「通常業務パターンとは別に、特定のイベント時においては業務担当者が変わる別の業務パターンが発生するため、そのパターンにも対応できる機能を実装して欲しい」と言った要望があり、業務影響が出る前に対応することができました。

特にシステム導入PJの経験が少ないユーザーの場合、要件定義からシステムリリースが短期間である方が業務とシステム機能の紐づきを容易にイメージでき、PJとしての達成感も得られるため、アジャイル開発の方が向いていると感じました。

【投稿担当：K.I.】

私が参画しているプロジェクトでは、基幹システムはアジャイル型とウォーターフォール型を組み合わせたハイブリッド型、周辺システムはウォーターフォール型で開発している。

このように開発手法の異なるシステム間のインターフェース開発を行う場合、基幹システムと周辺システム間の積極的なコミュニケーションによってマイルストーンを同期したうえでスケジュールの調整を図り、自システムの開発を遅延させないよう対応することが重要になると考える。

私が担当する人事システムとの連携では、基幹システム側の要件検討が遅延しており、開発遅延リスクを抱えていた。
そこで、基幹システム側には、人事システムとして要件確定が必要な時期を提示し、その期限内に要件が確定できないか調整しつつ、人事システム側とは、基幹システム側からの要件に依存しない機能を先行して開発する方向で対応した。

両システムの間に立つ調整役として、今後も双方の進め方や作業内容を理解し、密にコミュニケーションを取りながら進めていく所存である。

【投稿担当：G.F.】