CaFeterria

最近、ホールディングスと名の付く会社が増えてきました。

子会社を複数持ち、それぞれで異なる事業を運営しています。

子会社毎ではなくグループ全体の業績を把握する時に重要となるのが連結会計です。

一方で、連結会計は専門性が相当に高く、とっつきにくいというイメージを持たれている方が多いのではないでしょうか。

どのように短期間で体系的に学習を進めればよいか迷われる方が多いと思います。

そのような方に、私自身が連結の知見向上に役に立った書籍をご紹介します。

「図解でざっくり会計シリーズ5 連結会計のしくみ(第2版)」

新日本有限責任監査法人(2014年)、中央経済社

→図とイラスト付き、原則1ページで解説されており、最初に手に取る本としておすすめ

「図解＆設例　連結会計の基本と実務がわかる本」

飯塚幸子(2014年)、中央経済社

→連結会計業務の内容と、具体的にどのような仕訳を行う必要があるのかを理解したい方におすすめ

「新セグメント会計基準対応　連結経営管理の実務　予算の立て方から円滑な導入まで」

中田清穂、三浦直樹(2008年)、中央経済グループパブリッシング

→少し古いですが、連結による経営管理の考え方を学べます。

制度連結だけでなく管理連結、予算連結までも網羅しています

【投稿担当：K.N.】

最近、十数年ぶりに要件定義フェーズの重要性を再認識する状況に遭遇しました。

（詳細は割愛しますが、クロージングフェーズで要件の認識相違が発覚）

要件定義フェーズは、操作マニュアルやイメージ図等を使った所謂「紙芝居」で議論が進むケースが多く、認識相違が発生しやすいフェーズと考えています。

紙芝居を見ながら実際に動作しているシステムをイメージできるようにコミュニケーション頻度・密度を上げつつ、様々なモノを活用しながら進めたつもりでしたが、少しだけ足りていなかったなと反省しています。

「準備8割・実行2割」という言葉がありますが、PJの”準備”にあたる要件定義フェーズが非常に重要であることを改めて肝に銘じていきたいと思います。

【投稿担当：C.I.】

特殊な業界のプロジェクトが始まりました。

業務プロセスの理解にかなりの時間がかかるのではないかと心配していましたが、意外にもスムーズに理解できました。

おそらく、最初から「業務の目的」がなんとなく見えていたからだと思います。

「業務のやり方」（業務フロー）は業界によって大きく異なりますが、「業務の目的」はそれほど変わりません。

たとえば、購入・販売・在庫管理・資金の記録（不正やミスの防止）といった基本的な目的は、どの業界でも共通しています。

そのため、「業務の目的」が分かれば、業務のあるべき姿やよくある問題、それに対する解決策も自然と見えてくるのです。

これまで業界や業務を限定せずにさまざまなプロジェクトを経験してきたことに感謝しました。

【投稿担当：K.G.】

『Excelがデジタルサーバントになる日』　執筆者：遠藤
https://test.crossfields.co.jp/cms/wp-content/uploads/2024/07/magazine_vol45.pdf

MicoroSoftのExcelといえば、学生から社会人まで広く利用され、ビジネスツールとしても馴染み深いものかと思います。
DXとしてマクロによる半自動化やRPAとの連携等、拡張しての利用も目にする機会が多くなりました。

本稿では、長くシステムの設計・運用に関わってきた弊社エキスパートが、

表計算ソフトの起源、Excelが台頭するまでの歴史を振り返りつつ、

近年Excelに拡張された機能から見る、AIと絡めた更なる活用の道、

次世代の「自動化」を担うツールとしての展望について論じます。

例えばデータ連携テストをする際、連携元システム、EAI、連携先システムと、システムごとに担当者を配置する体制がセオリーかなと思います。

しかし、セオリー通りでは上手くいかないこともあります。

私もセオリー通りの体制でデータ連携テストを実施し、なかなか解消されないエラーに四苦八苦する経験をしました。
EAI内のマッピングが複雑化・ブラックボックス化する中、連携元システム担当としてEAIの仕様を深く理解しないままテストを進めた結果、EAI側でエラー発生時に主体的に原因究明できず、EAIチーム任せとなり解決に時間を要してしまったのです。

もし体制として、システムを跨いで横断的な確認を行う担当者がいれば、上記のような苦労は無かったかと思います。

しかし実際はそのような担当者は不在でした。
テストをスムーズに進めるためには、担当システムを飛び越えて仕様理解を深める等、こうした体制の不備を姿勢でカバーしていくことが大切だなと感じました。

※EAI：複数の異なるシステムを連携させ、データやプロセスを統合する仕組み、またはそのツールのこと

【投稿担当：T.O.】

近年グローバル化が進む中、世間では外国人とコミュニケーションをとるときには、

何か特別な技術を身に着けないといけないかのように語られる印象がある。

しかし、グローバルプロジェクトに1年間携わった実感としては、

必ずしもそうではないと感じている。

というのも、コミュニケーションの本質は漏れなく論理的に簡潔に伝えることであり、

それは相手が誰であれ変わらないと考えるからだ。

実際、私が参加したグローバルプロジェクトでは、

多くのメンバーが相手と丁寧に交流しようとしていた。

もちろん日本人と外国人で対話に対する意識の違いは存在すると思う。

例えば外国人は発言に対するハードルが低くフランクに話す傾向があるが、

日本人は必ずしもそうではない。

日本人として、普段より発言量を増やしたり、

明確な意思表示をするといった心がけは必要だと思うが、

それらも漏れなく論理的に、簡潔に伝えるという本質があってのことで、

一番重要なのはそこだと思う。

【投稿担当：C.W.】

皆さんはユーザが安心して利用できるシステムを構築するには、何が重要だと思いますか。

導入実績、要件定義、セキュリティ・・・色々な観点が挙げられると思いますが、システム開発の最後の砦として、テスト工程が非常に重要であると考えます。

特に10～20年以上利用されている、いわゆるレガシーシステムとの連携が必要となる場合は、仕様がブラックボックス化していることが多く、改修した機能が他の機能に思わぬ影響を及ぼすことや、未知の仕様によって想定外の挙動になることもあります。

そのため、本番同様の検証環境を用意し、開発者の思い込みを排除した網羅的なテストを行うことが最低限必要です。

具体的には、第三者によるテスト仕様書レビューやツールを用いたテスト自動化、また、過去の失敗事例などナレッジの共有を図ることで、テストおよびプロジェクト全体の品質向上に寄与すると考えます。

【投稿担当：T.N.】

近年はITリソースの逼迫に伴い、

システムベンダに提案を依頼しても辞退されるケースが増えています。

私自身、プロジェクトの中でベンダの提案辞退を受け、

候補が限定された状況で選定を行った経験があります。

その経験からベンダに提案を依頼する際は、

「要件を具体化する」

「要件に優先度を付け、優先度が低い要件は代替案を提示する」

「提案前に直接重要な要件とその実装イメージのすり合わせを行う」など

ベンダが正しくプロジェクトのリスクを評価できる情報を伝えることが、

重要だと身をもって認識しました。

【投稿担当：S.K.】

業務フローを何度読んでも腑に落ちた理解が得られない日々が続いていました。

その中で、上司から「ヒト・モノ・カネの観点から実業務がどのように流れていくかを頭で考えなければ理解することはできない」とアドバイスをいただきました。

業務フローには記載されていないが、

『実業務として必要な処理を頭の中で補完して、業務のつながりを理解すること』

これが足りていなかったことを、その時認識することができました。

今後もコンサルタントとして業務を理解することだけに留まらず、その理解がクライアントへの提案・改善活動につながるよう行動していきたいと思います。

【投稿担当：Y.N.】

新システムの導入や業務プロセスの再設計を行ううえで、

「現状分析」は不可欠であるとはよく言われることではありますが、

私自身、コンサルティングを通じて、日々その重要性を痛感させられています。

現状分析によって問題点・改善点を網羅的に明確化することは勿論重要です。

しかし、現状分析を通じて組織風土や業界の慣例、業務の複雑性・特異性に繋がる背景を理解することも、また、重要な一面であり、変革への現場の抵抗感など、取り組みの難易度を左右する要素の見極めに繋がります。

こういった側面にも注力しておけば、

より実現性の高いアプローチを選択できたはずだと省みることも少なからずあり、

その度に「未来の成功のために、現在に向き合う時間を惜しむべきではない」と、

自身に言い聞かせています。

【投稿担当：K.T.】