圧縮記帳と将来支払う法人税額について再考

Finance

圧縮記帳という会計処理があります。これは国などから補助金を得て設備を購入した場合に、実際には補助金のうち4割位は法人税の増加により消えてしまって効果が薄くなるので、それを防ぐために補助金と同額を圧縮損という形で費用計上する（直接減額方式）ものです。これについては、「あくまでも税金の繰り延べであり、節税になるわけではない」と様々なテキストに書かれていますが、サラッとそのように説明しているだけであり、私が調べた限りでは数学的な証明がされていません（具体的な数値を例示して計算するだけでは、証明にはならない）。

以前、定額法については簡単な証明を与えたのですが、今回はもう少し一般化して考えてみます。

前提：第1期の期首に国庫補助金{H}を取得して、それを充当して簿価{A}の備品（耐用年数{N}年, 残存価額{C}）を購入。
この備品の購入が無かったとした場合の、第{i}期の利益を{p_i}とします。また第{i}期における、この備品と同じ償却方法を取得価額{x}のものに適用した場合の減価償却費を{f_i(x)}とします。
また法人税率は{\alpha}で一定とします。

圧縮記帳を行わない場合、第1期の利益は{p_1 + H - d_i(A)}になり、第{i, i = 2, 3, \ldots, N}期の利益は{p_i}となるため、第1期から第{N}期まで支払う法人税の累計額は{\alpha\left(\sum_{i=1}^N p_i + H - \sum_{i=1}^N f_i(A)\right)}となります。…(1)
圧縮記帳を行う場合、第{i, i = 1, 2, \ldots, N}期の利益は{p_i - f_i(A-H)}なので、第1期から第{N}期まで支払う法人税の累計額は{\alpha\left(\sum_{i=1}^Np_i - \sum_{i=1}^N f_i(A-H)\right)}となります。…(2)

ここで、(1) = (2)となっていれば、圧縮記帳を行っても支払う法人税の累計額は変わらないことになります。実際に使われている減価償却法でこれを確認してみましょう。なお、圧縮記帳を行う場合と行わない場合で残存価額は変わらない前提*1です。

  • 定額法の場合

{f_i(x) = \frac{x - C}{N}}となります。
{(1) = \alpha\left(\sum_{i=1}^Np_i + H - \sum_{i=1}^N\frac{A-C}{N}\right)} = \alpha\left(\sum_{i=1}^Np_i + H - A + C\right).
{(2) = \alpha\left(\sum_{i=1}^Np_i - \sum_{i=1}^N \frac{A - H - C}{N}\right)} = \alpha\left(\sum_{i=1}-Np_i -A+H+C\right).
ということで(1) = (2)となります。

  • 定率法の場合

償却率を{r}とすると、{f_i(x) = xr(1-r)^{i-1}}となります。
圧縮記帳を行わない場合の償却率を{r_A}とすると、
{(1) = \alpha\left(\sum_{i=1}^Np_i + H - \sum_{i=1}^N Ar_A(1-r_1)^{i-A}\right) = \alpha\left(\sum_{i=1}^Np_i + H - \frac{Ar_A\left(1 - (1-r_A)^N\right)}{1 - \left(1-r_A\right)}\right)}
{= \alpha\left(\sum_{i=1}^Np_i + H -A + A(1-r_A)^N\right)}.
圧縮記帳を行う場合の償却率を{r_B}とすると、
{(2) = \alpha\left(\sum_{i=1}^Np_i - \sum_{i=1}^N (A-H)r_B(1-r_B)^{i-1}\right) = \alpha\left(\sum_{i=1}^Np_i - \frac{(A-H)r_B\left(1-(1-r_B)^N\right)}{1-(1-r_B)}\right)}
{= \alpha\left(\sum_{i=1}^Np_i -A+H - (A-H)(1-r_B)^N\right)}…(*)
ここで、N期後には圧縮記帳を行うかどうかに関わらず、残存価額が{C}になるため、
{A(1-r_A)^N = (A-H)(1-r_B)^N = C}.
そのため
{(*) = \alpha\left(\sum_{i=1}^Np_i -A + H - A(1-r_A)^N\right)}
ということで(1) = (2)となります。

生産高比例法や200%定率法については、真に驚くべき証明を見つけたが、この余白はそれを書くには狭すぎる面倒（笑）なので割愛します。どなたか証明しておいて下さい。

さて、上記のような関係が満たされないような減価償却法を考えだすことも恐らく可能で、その場合は圧縮記帳を行うかどうかによって節税（脱税）が可能ということになります。ただ、一般に公正妥当と認められた会計原則に沿った減価償却法ではないはずなので、間違いなく監査で引っかかりますが。

*1:これについての記述も見つからなかったのですが、記帳方法で価値は変わることはないはずなので、きっと妥当な前提のはず…

kintoneをエンジニア目線で使ってみた

tech

サイボウズ社がkintoneというプロダクトをリリースしているので、最近はそれを試用して簡単なシステムを作っていました。確かに簡単に画面等を作ることができる（イメージとしてはAccessでフォームを作ったり、Crystal Reports*1でレポートを作るのと同じ要領）のですが、暗にいくつかの前提があることにも気づきました。Webエンジニア職の経験がある*2方が使用する際には、次のことを念頭に置いておくと話が早いです。

kintoneでは「アプリ」という単位で機能を作っていきます。1つのアプリには、1つのデータセット（←一般的なRDBMSのテーブルにあたるもの。公式の呼び方ではないが、kintoneでは「テーブル」は別の意味で使われているので、本記事ではこう表現しておく）が関連付けられており、それのレコード一覧(list)・表示(show)・作成(create)・編集(edit)を行うための画面が1つずつ含まれています*3。基本的にはこれだけで、それ以上の画面追加や複数テーブルの同時更新はしない前提です。
業務アプリは、極論を言ってしまえばDB内のデータセットのCRUDを様々な方法（単一または複数の画面、外部システム連携等）で行うだけのものなのですが、ある意味でこれの基本形（単一データセットのCRUD*4）を強制するものとなっています。複数データセットの同時更新を行うシステムをkintone上に移植する場合は、データセットの再設計や画面の構成変更が必要です。なおそのアプリで扱うデータセットとリレーションがある他のデータセット（CRUDは他のアプリで行う前提）を表示することは可能で、そのようなフォームパーツが存在します。さらに、1つのアプリ内の1レコードに対して複数の子データを格納したい場合は、子データセット（kintoneではこちらを表（テーブル）と呼ぶようです）を複数用意することも可能です。
扱うデータが、マスタデータであってもトランザクションデータであっても扱いは同じです。

  • JavaScriptによる柔軟なカスタマイズが可能

料金プランによりますが、自分で書いたJavaScriptやCSSを読み込ませることができます。このJS用に、kintoneのデータ（当該アプリのデータだけではなく、他のアプリのものも！）のCRUDが可能なREST APIが提供されている他、アプリ内の画面のDOM操作も可能（kintoneのバージョンが変わると構造が変わる可能性があるが、バージョンに関係なく指定した要素を取得するAPIが用意されている）なので、前述の1アプリ1データセットという前提を破ることが実は可能です。読み込むJSファイルは複数指定することが可能なので、複数のアプリ間で共通のJSファイルと、当該アプリ用のJSファイルを分離する、ということもできます。
また、書いている通り使う言語はJSであり、（当然ながら）日々進化しているWebブラウザ上で動作するので、VBAなどと比べると柔軟な書き方が可能*5です。

  • 複合キーは設定不可

「必須項目にする」（= Not Null制約）や「重複登録できないようにする」（= Unique制約）を各フィールドに設定することが可能ですが、残念ながら複合キーを設定することはできないようです。複合キーを設定することを諦めるか、JSでレコード追加/更新時に無理矢理制約を付けるかする必要がありそうです。

  • kintoneのバージョンにより細部が変わる可能性がある

kintone自体は月1〜2回アップデートしている模様で、地味に機能改修・拡張が行われています。このアップデートは強制であり、日時はこちらからは制御不可です。機能改善自体は嬉しいのですが、JSやCSSで特定のDOM構造やURL形式などに依存したカスタマイズを行う場合は、アップデートにより影響を受ける可能性があります。可能な限り、提供されているAPIだけを使用するようにしましょう。まぁ本格的にカスタマイズしようとすると難しい場合もありますが…。

  • 非エンジニアが改修する可能性を考慮する必要がある

kintoneの画面上で、アプリのフォームやデータの変更が誰でも簡単に行うことができます。そのため、非エンジニアが変更を行うことも十分考えられます。強烈なカスタマイズを行っている場合は、それにより大幅な影響を受ける可能性があるため、特定のデータ等に依存するカスタマイズを行うのは避ける必要があります。通常のシステムであれば、開発者がそのシステムの担当から外れる場合は後任のエンジニア向けにドキュメントなりコード コメントなりを用意するものですが、それらを一切読むことができない非エンジニアに引き継ぐという事態も起こり得るので、注意が必要です。
（あれ？そこまで考えるとカスタマイズは実質的に不可能な気が…）



上記のような前提が暗黙的に存在しているので、既存システムの置き換えの場合は、それなりの知識及びセンスが必要です。しかしながら、基本的な画面群がコーディング無し＆簡単操作で作成できて、さらに必要に応じてカスタマイズ可能なので、（ゼロから自分で実装したり、他の担当者or他社に外注するのに比べると）慣れるとかなり便利でしょう。
Windowsのアプリケーションとしては、画面を簡単に作ったり…というのは、前述のAccess等、昔からあったように思いますが、

  • PCにもスマフォにも対応したWebシステムであること（それにより、従来型システムでは地味に悩みの種であったデプロイやバージョン管理に苦労する必要がなくなる！）
  • 標準的なJSを使えること（kintone専用の言語を修得する必要がない）
  • ユーザ認証やユーザ間コミュニケーション等の機能は（kintoneの機能として）別途利用可能なこと
  • アプリ自体はサイボウズ社の管理下にあるサーバ上で動作するため、システム基盤の構築や運用が不要なこと（セキュリティ対応のことを考えると、アプリ自体の変更は無かったとしても基盤運用のリソースは少なからず必要で、しかも一定以上のスキルが必要。）

などがkintoneの利点だと思います。

*1:かつてはSeagate Software社のプロダクトだった記憶があるのだが、いつの間にかSAP社の製品になっていた…。

*2:以前の私はそうでしたが、今は財務経理担当者であり非エンジニアです。

*3:他にもインポート/エクスポート用画面があります

*4:この機能を作らせることで一通りの学習や実力の判断ができるので、新人エンジニアに与える仕事として適している。

*5:Webエンジニア職の経験がある人は今までの経験を活かせる

Excel VBAの密かな変化

tech

最近、仕事でExcel 2013のVBAを使ってマクロを組むことがあります。VBAは久々に触りましたが、最近のプログラミング言語ではサポートされていることの多い無名関数やらジェネリック型はおろか、変数の宣言と同時の初期化や、ハッシュテーブル*1や、コードブロックごとの変数スコープすらサポートされておらず、10年以上前に第一線からは退いたVB6の時代から、VBAの言語自体は進化していないことに気づきました…。*2

ここでふとVBAのバージョン番号を見てみると、7.0になっていました。確かExcel 2000では6.0だったと思うので、いつの間にかメジャーバージョン番号が上がったことになります。そこで、VBA 6.xとVBA 7.0の違いについて調べてみました。

  • 新しい型

64ビット整数を扱う型として、LongLong型が新設されています。同時にCLngLng関数も新設されています。

VBAのバージョンが7か6.x以前か, および64ビット環境か32ビット環境かどうかを表す定数として、VBA7およびWin64というコンパイル定数が新設されています。

#If VBA7 Then
	' VBA7用のコード
#Else
	' VBA6.x用のコード
#End If
  • 64ビット環境サポート及びそれに伴うWindows APIコールの変更

最近のWindowsは64ビット版があるため、それに伴いWin32 APIを呼ぶときに使用するポインタのサイズも32ビットから64ビットに変わっています。
両方の環境で実行できるようにするため、LongPtrという型が新設されています。Declareステートメントで外部のAPIを呼ぶ箇所は、それを使うように変える等が必要になります（他にPtrSafe属性も必要）。

ここでVB.NET経験のある方は注意が必要です。VB6→VB.NETになった時（2002年頃）にInteger型が16→32ビット, Long型は32→64ビットに変わったのですが、VBA 7では未だにInteger型: 16ビット, Long型: 32ビットです。VB.NETと同じ感覚で変換するとExcelが落ちると思います。

  • 32ビット版Active XコントロールおよびCOMアドインとの非互換

（VBA7というより64ビット環境の問題ですが）32ビット版のActive Xコントロール等はサポートしていないようです。MSComCtl*3やMSComCtl2など結構使われていそうなものも、使えなくなってしまいます…。


こうして見ると、VBAの言語自体はほとんど変わっていないということが分かりました*4。VB6やVB.NETと違ってVBAは非エンジニア向けのものと言えるので、バージョン間の互換性を保つ必要が高い*5のは確かです。ただ変数の宣言と同時の初期化くらいはサポートしていると嬉しかったのですが…。

参考URL:
http://msdn.microsoft.com/en-us/library/ee691831(v=office.11).aspx
http://stackoverflow.com/questions/3072356/what-are-the-differences-between-vba-6-0-and-vba-7-0

*1:CreateObject("Scripting.Dictionary")で使うことはできますが、言語の標準機能というわけではない

*2:新しい言語に慣れている人がVBAを触ると、回りくどい書き方をする必要があるため、手枷をはめられた気分になりそうです。

*3:プログレスバーなど、標準のフォームには入っていないが使いたいコントロールが収録されている

*4:そもそもWindows APIをマクロから呼びまくるのはどうかと思いますが…。

*5:言語仕様変更による書き換えは、開発をメインでやっている人以外が行うには重い仕事です。VB6→VB.NETの書き換えはかなり大変でした（可能ならば1から作り直す方が良いくらいの勢いだった）。

Uberを使ってみた

雑記

渋谷から六本木一丁目に行く個人的な用事があったので、偶然にも利用クーポンを持っていたUberを初めて使ってみました。知人が以前使っていたのを見て気になっていたサービス。

手持ちの携帯端末のアプリから乗車場所を指定してしばらくすると、到着までの予想時間が表示されます。このとき、車の情報（車種やナンバー）や位置がリアルタイムで分かるので面白い。ちなみに車はセダンかワゴンか指定することが可能。

10分ほどして車が見えました。この時、私は渋谷マークシティのオフィス車寄せに居たのですが、渋谷マークシティのホテル車寄せに車は行ってしまいました。乗車場所として「渋谷マークシティ」とだけ指定していたため、運転手には詳しい情報は伝わっていなかったのです（運転手は悪くない）。この際、運転手に直接アプリ内でメッセージを送ったり、電話をかけることで、詳しい乗車位置を伝えることが可能です。
乗車後15分ほどで目的地に到着。支払いはアプリに登録しているカードで自動的に行われるため、到着後すぐに降車できます。

その他分かったこと・思ったことは次の通り。

  • 渋谷・六本木エリアの他、今は東京・新橋あたりにもuberでリクエストできる車がいるらしい。
  • ハイヤーと異なり車庫からの料金は不要。純粋に高級なタクシーとして使える。
  • 今のところ乗車時刻を指定することは不可能。今は台数が少ないので、このオペレーションを回しきれないのが理由？
  • 地図またはスポット名で乗車位置を指定できるが、乗車位置として考えられる場所が複数ある場合、スポット名だけだと前述のようなことが起こり得る（例えば大きな駅などは要注意かと）。乗車位置を指定した後に、詳しい乗車位置についてのメッセージを送ったほうが良さそう。できれば、アプリ側で（有名なビルなどの場合）詳しい乗車位置まで指定できるようになると、なお良い。

京のバス

雑記

私は学生時代は京都市内に住んでいました。
京都のバスで運賃（220 230円）を現金で支払う場合、料金投入口の近くにある両替機に1,000円札や500円玉を入れて、出てきた小銭群から220 230円をピックアップして投入口に入れる必要があります。

今は東京都内に住んでいます。
東京のバスで運賃（220円）を現金で支払う場合、料金投入口の近くにある両替機に1,000円札や500円玉を入れて、出てきた小銭群は運賃を支払ったお釣りになっており、改めて220円を投入口に入れる必要はありません！両替機に入れた時点で支払も同時に行っているということです。（←もはや両替機とは言えない気が…）

片方のバスの支払いシステムに慣れている状態でもう片方のバスに乗ると、料金の2重支払いor無賃乗車となるため注意が必要です。



さて、京都市内にお住まいの方（特に左京区）なら分かると思いますが、観光シーズンのバス（特に清水や祇園などの観光地を通る206系統）は大渋滞に巻き込まれて、歩いた方が速いということもあります。実はその渋滞の要因はバス自体という説もあります。路駐の多さやそもそもの車線数の関係で、実質的に使用できる車線数が1車線ずつという状況下で、停留所で停まって車の流れを止めてしまうため、このような説があります。
そして乗客が運賃を支払う時間が長いほど、より車の流れを止めてしまいます。特に両替を必要とする人が居ると、長時間の停車になってしまいます。
緩和方法として、東京のバスのように両替と支払いを同時に行う機械を導入する手もあるでしょう。
別の方法として、運賃を220 230円という中途半端な額ではなく、250円や300円という比較的キリの良い額にしても良いかと思います。硬貨が1 2枚減った分、支払いのスピードが僅かに上がります。どうせ観光客はバスの運賃が少々値上がりしようが関係なく払ってくれる（地理的な利便性や料金帯で、他の交通機関と直接は競合しない）ので、ついでに収益も上げてしまいましょう。定期代や回数券の料金だけ据え置いておけば、地元からの反発はそこまで大きくないかと。


支払いのスピード向上が渋滞にどれだけ影響するか、数理モデルを作って計算で出す方法を大学で学習したのですが、もはや忘れてしまいました。

失敗することに慣れる

雑記

昨夜あったとある会で、若いうちは（何もしないでいるよりは）失敗をどんどんした方が良いという話題になった。
若いうちに失敗した方が良い理由として出たもの等を書いていくと、

  • 若いうちは、負っている責任は組織全体から見ると微々たるものなので、失敗してもリカバーは十分可能。
  • 何もしないでいるよりも、何かをやって失敗をした方が、自己の存在を周りに知ってもらえる点でメリットがある。
  • 失敗をした方が良い\Leftarrow\Rightarrow失敗を恐れずに何かをした方が良い ということが正しい解釈であり、とにかく色々なことを経験した方が後々になって良いことが多い。

私は20代後半だが、現時点で失敗を恐れる気持ちが十分にあり、些細な失敗を恐れて何もしないことによる問題のほうが大きいというケースもたまに見受けられるため、（もうそんなことを言ってられる年齢ではないかもしれないが）上記のことは留意しなければならない。


よく考えると、失敗を恐れずに様々なことにチャレンジして経験を積むということは、様々な意思決定をこなしていくということであるとも言える。CxO層は日々重要な意思決定を行っているが、それができるのは若いうちの失敗の経験があってこそなのかな、とも思った。

三角関係を解こうとしたが…

雑記

とある清涼飲料水の広告を電車で見かけて、気になってしまったので考察してみる。画像（3名とも制服を着ている方）に書かれている問題文は次の通り。
【問】AC間を{x}, BC間を{y}として三角関係A, B, Cの最適な距離感を求めよ。
（ただし、画像からAB間を{y \sin \theta}, {\angle C = \theta}という条件もあることが分かる。）

ただ、最適な距離感の定義が分からないため、この3人の関係について分かる限り考えてみる。

{\angle A}や{\angle B}が直角ではないため、三角比の公式を表している訳ではないが、いずれにせよ束縛条件として働いている。まず、{0 \lt \theta \lt \pi}と見なしても一般性を失わない。そうすると{0 \le \sin\theta \le 1}となることから、BC間の距離はAB間の距離より縮まることがないことが分かる。つまり、Cの人がAの人よりBの人に近づくことはできないことが、この時点で明らかになる。

ここで、{\angle C}について余弦定理（←この言葉を使ったのは何年ぶりだろうか…）を使うと
{(y \sin \theta)^2 = x^2 + y^2 - 2xy \cos \theta},
{y^2(1-\cos ^2 \theta) = x^2 + y^2 - 2xy \cos \theta},
{y^2\cos^2 \theta - 2xy\cos\theta + x^2 = 0}.
{y^2}で両辺を割って
{\cos^2\theta - 2\frac{x}{y}cos\theta + (\frac{x}{y})^2 = 0},
{\left(\cos\theta - \frac{x}{y}\right)^2 = 0},
{\cos\theta = \frac{x}{y}}
となる。もちろん{0 \le |\cos\theta| \le 1}だから{x \le y}であり、BC間の距離はAC間の距離より縮まることもない、つまりCの人にとっては恋愛が友情に勝つことはないことも分かる。

以上より、BC間の距離はAB間の距離やAC間の距離より短くなることはない。恐らくCの人はBの人を通じてAの人を知ったのでしょう。また、この三角関係においてCの人にとって良い結果にはならないことも示された。今後の話の流れも程度読めてしまえたではないか…。



改めて考えるとAB間の距離が{y \sin \theta}というのは、何気に強力な条件となっているので、制作者が意図的にこのような条件を設定したとすれば、密かにではあるが入念に作りこまれていると言える。なお現実の三角関係を解く方法は分かりません。