この記事は クラウドワークス Advent Calendar 2021 の4日目の記事です。
過去にちょっとだけバズった以下の記事の続編です。
第六期（再掲）
- ポインタおじさんですらなくなる
- プログラミングもマネジメントも本質は同じだと思えるようになる、、、予定
第七期
- 色々あって管理部門の担当になる
- 会計と日常的に触れ合う日々を通して、PL/BSというものを知識ではなく、経験として理解し、自分が作っていたシステムの問題の根源がなんだったのかをようやく理解する（気づき1）
- 「会社」というものが、「会社法」という「フレームワーク」の上に「規程」や各種制度を使って作られるソフトウェアであるという実感を得る（気づき2）
第八期
- 色々あって仕事としてのプログラミングを再開する
- 色々あってプロダクト開発部門に戻ってくる
気づき1: 自分が作っていたシステムの問題の根源は何か
それは、「自分が会計を理解していなかった」ということです。
会計とは、「起きた取引を記録すること」であり、商取引を扱うシステムは、それを正確に記録しなければいけません。
例えば、クラウドワークス上で起きる代表的な取引の流れは以下のようなものです。
- 発注者と受注者が契約を締結する
- 発注者が銀行振込で仮払いをする
- 受注者が納品をする
- 発注者が検収をし、受注者に報酬が支払われる
- クラウドワークス社が受注者からシステム利用料をいただく
- 受注者が報酬を出金する
1-6まで、会計の記録方法を正確に言えるでしょうか？ 正確に言えなければ、おそらく最適なシステムは作れません（偉そうに言っていますが、かつての自分は全く正確には言えなかったので、後々自分以外の関係者も含めてかなり辛い思いをし、いまだに完全には解決していません）。
上記の取引における会計処理は以下の通りです（一例であり、この通りでない場合もあります）。
| 取引内容 | 会計処理 |
|---|---|
| 1. 発注者と受注者が契約を締結する | 会計上の動きなし |
| 2. 発注者が銀行振込で仮払いをする | 預金が増え、発注者に対する同額の預り金が計上される |
| 3. 受注者が納品をする | 会計上の動きなし |
| 4. 発注者が検収をし、受注者に報酬が支払われる | 発注者に対する預り金が、受注者に対する未払金に振り替えられる |
| 5. クラウドワークス社が受注者からシステム利用料をいただく | システム利用料額が売上として計上され、同額が4の未払金から取り崩される |
| 6. 受注者が報酬を出金する | 預金が減り、未払金の残りが消える |
ちなみに、2の仮払い手段が「クレジットカード与信決済」で、実売上処理は4のタイミングだったケースはどうでしょうか？
この場合の会計処理は以下の通りです。
| 取引内容 | 会計処理 |
|---|---|
| 1. 発注者と受注者が契約を締結する | 会計上の動きなし |
| 2. 発注者がクレジットカード与信決済で仮払いをする | 会計上の動きなし |
| 3. 受注者が納品をする | 会計上の動きなし |
| 4. 発注者が検収をし、受注者に報酬が支払われる | 受注者に対する未払金と、クレジットカード決済代行会社に対する未収入金が計上される |
| 5. クラウドワークス社が受注者からシステム利用料をいただく | システム利用料額が売上として計上され、同額が4の未払金から取り崩される |
| 6. 受注者が報酬を出金する | 預金が減り、未払金の残りが消える |
| 7. クレジットカード決済代行会社から入金がある | 預金が増え、未収入金が消える |
最初の例とは大きく異なる処理になっていることがわかるかと思います。
ちなみに、クラウドワークスでは、
- 2が仮払いではなく後払い（請求書払い）のケース
- 割引クーポンを使って2の仮払い金額が契約金額から割り引かれるケース
など、ほかにも数多くの取引パターンがあります。
これらに対応する多種多様な会計処理を、システムを開発するエンジニアが理解していない場合、そのシステムは将来的に高い確率で問題を引き起こすことになります。
一方、会計をキチンと理解しているエンジニアは非常に限られているように思います。あらゆるものがソフトウェア化されていく現代において、会計を理解しているエンジニアは、今後その価値を増していくであろうと考えます。
Let's study accounting!
気づき2: 会社とはソフトウェアである
ソフトウェアエンジニアとしてのキャリアを持つ自分が、管理部門を経験してみて得た実感は、
会社とは、「会社法」という「フレームワーク」の上に「規程」や各種制度を使って作られるソフトウェアである
というものです。
会社法
会社法というのは文字通り、会社に関する決まり事を定めた法律です。
自分は会社法に関してはまだまだ限定的かつ浅薄な知識しか持ち合わせていませんが、知れば知るほど、よくできたフレームワークであると感じます。この、「会社法」というフレームワークを使って営利組織を作ることで、株主・経営者・取引先が**「いい感じのパワーバランス」**になるようにできています。
例えば、会社が株主に利益を還元する、「配当」。
ただし、ある年に利益が出たからと言って、配当を出せるわけではありません。
※ 以下はわかりやすさを優先してかなり簡略化した表現なので、厳密な説明ではないことをご了承ください
株主Aさんが100万円を出資して会社を設立し、銀行から100万円を借り入れました。
1年目は初期投資が嵩み110万円の赤字、2年目は初期投資の甲斐あって10万円の黒字だったとします。
ここで、会社に対して株主として支配的な権利を持つAさんが10万円を全て配当として自分に還元してしまうと、何が起きるでしょうか。
この時会社に残っているお金は、100万円+100万円-110万円+10万円-10万円=90万円となり、銀行から借りた100万円を返せるだけのお金が残っていません。このようなことが起きてしまうようでは、銀行はお金を貸しにくくなります。銀行がお金を貸しにくくなるということは、会社にとってのビジネスチャンスも減ることになり、ひいては株主が利益を得られるチャンスも減ることになります。せっかくお金を出して会社を設立したのに、これでは困ります。
このような状態に陥らないように、会社法では、その会社が生み出した利益の累計がプラスになっていない場合、配当を出すことはできず、またそのプラスの金額の範囲内でしか配当を出すことはできないように定められています。
株主は会社の経営に対して銀行よりも大きな力を持っているため、会社法では株主がその力を濫用して銀行の利益を侵害することができないようになっているのです。それが結果として銀行が会社に対してお金を貸しやすくすることにつながり、会社としてもビジネスチャンスを逃すことなく、結果として株主の利益にもつながるといった仕組みになっています。
これはあくまでも一例で、このような「会社」がうまく回るための仕組みの集合体、すなわちフレームワークが「会社法」です。
規程
規程というのは、それぞれの会社が独自に定める、その会社の中をスコープとする法律のようなものです1。
どの会社にもたくさんの規程があるかと思いますが、ソフトウェアエンジニアにとって最も関係の深い規程は、ずばり「職務分掌規程」です。
インターネット上で配布されているサンプルから、冒頭部分を引用してみます。
この規程は、株式会社○○（以下「会社」という）の組織規程第4条に基づき、各組織単位が分掌する業務の範囲を明確にし、組織的かつ能率的な会社運営を計ることを目的とする
上記の一文の中の表現は、ソフトウェア開発者としては以下のように解釈することできます。
各組織単位が分掌する業務の範囲 = 各クラスの責務
組織的かつ能率的な会社運営 = 高凝集疎結合なソフトウェア
上記の条文の続きには、各組織単位が分掌する業務の範囲（＝各クラスの責務）が記載されます。
このほかにも様々な規程があり、その一つ一つが会社という「ソフトウェア」の動作を決めています。
まとめ
「プログラミングもマネジメントも本質は同じだと思えるようになる、、、予定」と記載しましたが、実際にわかったことは、「プログラミングも会社作りも本質は同じ」でした。
第8期に記載したように、今はまたソフトウェアを開発する部署に戻ってきました。
管理部門を経験したことで、自分は「ソフトウェア」に限らず、「会社」そのものも含めた広義の「システム」作りが好きなんだということがわかりました。
-
余談ですが、エンジニアは比較的規程類に関心を持つ人が多いような気がします。これは、自分が感じている、会社とはソフトウェアのようなものであるという感覚と、無関係ではないと思います。 ↩