特に誰向けでもないが、自分が書きたくなったので書く。

私は経理に関連した仕事をいろいろやった後プログラマーに転職してもうすぐ 1 年経つのだが、将来的には会計に関する仕事をやっていきたいと考えている。

プログラマーに転職してそれが今のところ続いている理由としては、個人的な興味関心とキャリアとしての可能性の 2 つがある。

個人的な興味関心

まずプログラミングは単純に楽しい。

まだまだ初心者レベルだが何が楽しいかというと、とにかく自分の行動に対するフィードバックが多いという理由があるかもしれない。自分が書いたプログラムを動かしたり他人のレビューを受けたり、ログやインスペクタ、 Stack trace を眺めたりなど。フィードバックから機構や制約を理解していく過程がよくできたゲームみたいで楽しい。

それから、自分が経理の仕事をやってきた中で自分が認識していた課題を解決するためにプログラミングが役に立ちそうだという印象が強まっている。

複式簿記は会計主体に生じる債権債務関係の変化を記録するための技術で、現代の財務会計では複式簿記の基礎の上に様々な概念や体系、制約¹ が積み重なって最終的な財務諸表や開示書類が生まれている。

日常的な実務としては、事業で起きる膨大な数のイベントを一つ一つその制約や性質を根拠に原因と結果という二つの面に切り分けて借方と貸方に記録していく。それが積み重なり一定の体系の下で集約されて財務諸表が生まれる。言い換えると、財務会計の日常的な仕事の多くは膨大な数のイベントを分類していく作業になる。

会計処理が必要なイベントは日々様々な場所で発生していて（給与や賞与、取引先への売上や仕入、固定資産の償却、借入の返済、社員が立替払いした経費…）、経理の仕事ではそれらを手で入力したり、受け取ったデータを Excel で加工したり、会計ソフトに直接流し込んだりしている。

そのような仕事に取り組む中で、自分で業務を効率化するぞ！と意気込んで Google スプレッドシートのマクロや GAS、それから Zapier のような RPA を使ったこともあった。しかしながら、非常に便利ではあるものの限界があるという印象を受けた。

それらはデータを A 地点から B 地点に移すような仕事は得意だけど、元々のデータが十分でなかったり使いづらい形だったりして結局手で隙間を埋める作業することが多かった。自動化のツールというよりは、それを使う以前の問題や自分の能力不足で思ったような結果を出せなかった。

その後いろいろあって、会計処理のデータを生み出すイベントのデータ構造やそのデータを会計に入力するワークフローとインターフェースに会計ソフト側から一定の制約を設けることで全体がより効率的に仕事できるようになるんじゃないかな〜と考えるようになった。

しかしながら、自分はただただ漠然とアイデアを考えるだけで自分の思考を具現化する能力が無かった。そこでプログラミングとかソフトウェア開発の技法とかそういうやつを自分にインストールしたかった、というのが仕事でプログラムを書きたいと考えたきっかけだったかもしれない。

ちなみに今の仕事では会計のプログラミングをしているわけではないけど、当たらずしも遠からずということをしているのでそこそこ楽しくやっている。

キャリアとしての可能性

会計 x プログラミングというのは面白いキャリアだと思う。

何らかの活動を行う上で会計を一切やらなくていい組織は無いし、自分が働くこれから 20 ~ 30 年（…短ければ短いほどいい…）の間に会計の仕事でプログラミング的思考が必要になる場合が増えることはあっても減ることはないだろうから。

Netscape の創業者 Marc Andreessen が “Why Software Is Eating the World” という有名なエッセイを発表したのが 10 年前だが、まさに彼が書いた通りソフトウェアは世界を喰い続けている。それと並行してソフトウェアを通じて生み出される債権債務も増え続けている。

付加価値の高いソフトウェアのインターフェースやアーキテクチャは外部環境の変化に応じて変わっていくけれども、会計の側ではその影響を人の脳と腕力で吸収することがある（時と場合と組織の判断による）。こういう状態は長続きしないので、環境の変化に適応しやすいよう会計データの保守性、拡張性、信頼性をソフトウェアを通じて維持・向上する能力の需要が高まる時代が近い内に来るのではないだろうか。会計で必要なデータの構造や要件は一般的なソフトウェアのそれと異なることが多い。

ところで、仕事を取り巻く環境が次第に変わっていく中で会計に限らず「何かの仕事 x プログラミング」をやることで得られる知識や経験は付加価値が高い。そういった横断的な知識や経験は「システムと現実世界のインターフェースをどう設計するか」や「ビジネスのルールからシステムが解決するユースケースをどう抽出するか」という設計上の課題を理解するのに生きてくるはずなので。

例えば医者がデータサイエンスや Web アプリケーションの開発を学んで遠隔医療のシステム開発に参加するとか、飲食店経営者がプログラミングを学んで店舗の管理に役立つアプリを開発するとか、そういう事例がたくさん出てくると予想している。というか、既にそういう例はたくさんあるのかもしれない。

これは自分の仕事の話なので他人のキャリアを否定する気は一切無い。それぞれ自分自身が可能な範囲で環境に適応する努力をすればいいし、しなくてもいいと思う。

当面の目標

一言でいうと会計ソフトを作りたくて、その過程で財務会計のワークフローを少しずつ抽象化していきたい。

ERP の会計部分の核だけを切り出して、状況に応じて様々な業務システムや SaaS から送られる会計処理データを受け取る（もしくは取得しにいく）ようなものをイメージしている。

日本では freee やマネーフォワードのような主として銀行の入出金明細から会計の仕訳を生成する SaaS の成長によって、中小企業の会計業務が大きく変わった。自分はもともと経理をやっていたので、ユーザーの 1 人としてその中にいた。外国でも状況は似ていて、会計の仕事は大きく変わりつつある。主に仕訳を作るところで自動化が進んでいる。

一方で、事業上のイベントから仕訳の生成を自動化することが進むと、それが意図通りに行われることを保証したくなる。そこで、イベントと仕訳の間にもう一つ層が欲しい。イベントと会計処理の関係を定義して仕訳を生成するような層。

私は将来的に会計ソフトの主たる関心事は以下の 5 つになると考えている。

1. 事業に関連して増減する債権債務や収益費用のデータ構造を定義する
2. 事業が会計システムに送るべきデータの構造を定義する
3. 事業が生み出す会計処理イベントを受け取る
4. 受け取ったデータが事前の定義に沿っているかを検証する
5. 検証済みのデータを保存、集計、出力する

会計処理の根拠となるイベントは、事業運営上の課題を解決するユースケースに特化したソフトウェアが提供する。例えば給与計算ソフト、飲食店や小売店の POS レジ、請求書の発行や受取、固定資産の管理、銀行の入出金明細など。いわゆる基幹システム的なものもあるかもしれない。

それが進むと、経理に関連する仕事の多くはそれらのイベントを受け渡す API や Pub/Sub と財務モデルの運用になるはず。

• イベントによって記録する会計上の分類項目を定義したり
• イベントが発火するタイミングを定義したり
• 事前の定義通りに運用されているか監視したり
• 保存したデータを使って何かしたり

そこで、まず自分の当面の目標としては会計処理イベントを定義したりそれを解析して財務諸表を組み立てるソフトウェアとイベントを発行する SDK のそれぞれ簡単なやつを作りたい。

最後に

書いたら満足した。御託はいいからやれよっていう話ですね、これは。

会計とプログラミングでお金を稼いで労働から引退し、自分の好奇心を満たすだけの怠惰な生活を長く続けることが今の人生の目標です。

Footnotes

1. 会社法、金商法、租税法、各種の会計基準、証券取引所の規則、経営上の都合など、会社の状態や活動に応じて様々な制約が生まれる ↩