CaFeterria

私はグループ各社に対し、共通会計システムの導入と業務プロセスの標準化を行う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.】

『IFRS18号の概要と企業会計への影響』　執筆者：大野
https://www.crossfields.co.jp/cms/wp-content/uploads/2024/12/magazine_vol46.pdf

IFRS第18号「財務諸表における表示及び開示」が2024年4月に公表され、2027年1月1日以後に開始する事業年度から適用される予定です。財務諸表の比較可能性と透明性を目的とした基準です。

財務諸表の表示に係る要求だけでなく、経営者が定義した業績指標に関する開示も要求しており、開示に大きな影響を与えることが予想されます。

本稿では、弊社の会計エキスパートがIFRS18号の概要について要点を絞って解説し、また、企業にどのような影響があるのかを論じます。

皆様、是非ご一読ください。