Hatena::ブログ(Diary)

インターネットのすみっこ このページをアンテナに追加 RSSフィード

2017-03-08 ヤマト残業代未払い精算がもたらす新たな節税手法

ヤマト残業代未払い精算がもたらす新たな節税手法

エラー|NHK NEWS WEB

ヤマトホールディングスは、宅配便を手がけるヤマト運輸のドライバーなど合わせておよそ7万6000人の社員を対象に、未払いの残業代について大規模な調査を進めていることがわかりました。
会社では、今月中にこの調査を終えたいとしており、残業代の未払いを確認したうえでその分を支給するとしています。

ヤマト運輸を展開するヤマトホールディングスが、過去の残業代の未払い代金を大規模に調査し、額が決定すれば支給するという話。労働者の立場でみれば、過去の未払い残業代が支払われることでハッピーな話。しかしコレをよく考えると、新たな節税手法となりうるなというのが今回の話。

なぜ節税手法となりうるのか

会計の観点から言えば、残業代は経費である。つまり利益を圧迫する損益である。これが毎年正しく精算されているならよくある普通の話だが、今回は過去の残業代の未払い代金について当期(ヤマトが言う調査が終わったタイミング)に支払おうという話。つまり、過去損益であったはずの残業代を今期に一気に精算するということ。

ここまでは特に問題がない。しかし問題はその損益の扱いがどうなるか、によっては大きな問題になる可能性がある。

通常の処理であれば、過去の未払い残業代が確定した時点で、対象となる年度毎の会計を修正する。しかしこれが非常に作業量が膨大でかつ、一度決まってしまった決算をあとから書き直すことになり手間が膨れ上がり現実的ではない。その結果、未払い残業代の精算費用について当期の特別損失に計上するということにおそらくなるだろう。

過去の残業代が当期の特別損失になるということは何を意味するかだが、極端に書くとこういうことになる。

  • 過去に発生した損益をもみ消し(残業代の未払いによって、損益隠蔽した)
  • それを当期に特別損失として計上する(過去に発生した損益を合算した上で今期の利益を圧縮する)
  • 過去の未払いの残業代は、調査はすれど完全ではなく必ず何処かでみなしで計算されるだろう(損益根拠となる数字を、任意の金額を後から設定できる)

つまり、金額は後から自由に設定できる過去の未払い残業代損益として未来に対して持ち越せるということになる。この仕組を活用すると何ができるかというと

  • 利益が少ないときや赤字のときは、損益である残業代を未払いにすることで未来に先送りし利益に見せかけることができる => 株価対策になる
  • 利益が出たときに、特別損失として任意期間分を任意の金額を特別損失に計上し、支払うべき法人税を削ることができる => 節税

つまるところ

  • 損益を未払いの残業代を経由させて任意のタイミングで支払い直すことで、赤字の幅や利益の幅を自由にコントロールすることが可能になるということ

あれ、これもはや粉飾決算レベルの話では…?(TOSHIBAのチャレンジと同じじゃね)

もちろん税務署が許可する必要はあるが…

もちろん会社として特別損失として計上したかったとしてもそれが監査法人がOKをだして税務署がOKを出すかどうかにかかっているのは言うまでもない。

しかし、過去の未払い残業代を完全に精査することや、過去n年間に渡って決算書を書き換えたりすることの手間などを考えると、当期の特別損失として計上することに一定の合理性は認められるだろう。

未払い残業代を経由した新たな節税手法の誕生

今回ヤマトの件で、かなり多くの社員を対象とする残業代未払い代の特別損失としての計上が認められてしまったら、これは日本中に広がる節税手法となるだろう。しかも過去の残業代の未払いを精算することは世論的には好ましいと思われていることであるから後押しにもなるだろう。

もちろん乱発は出来ない技であるので、基本的には1回使うとリチャージに時間が掛かるゲージ技では有る。負債ゲージを貯めて任意のタイミングで発射するようなイメージ。


(細かいところは現在検証作業中なので追って追記します)

2017-02-21 公共ギャンブルに於ける乱数の生成について疑問が湧いたので調べてみ

公共ギャンブルに於ける乱数の生成について疑問が湧いたので調べてみた

totoBIGの件は何が問題なのか、なるべく分かりやすく説明してみる: 不倒城

no title

ここ最近話題のtotoBIGの件、上記のBlogにおいて擬似乱数生成の仮定において精度の甘い実装になっていたということが指摘されていた。

自分も概ねそのあたりが原因ではないかと思っていました。テクニカルな面についてはこの記事の通りで不足ないと思います。

では、一方でポリティカル(要するに法律や業界規制、公安委員会や保安通信協会とのやり取りを含めて)の部分はどうかというと、上記のような問題が発生してしまっても仕方ないという状況にあるのではないかと疑問に思ったので、色々調べてみた。

totoBIG同様に乱数を利用するパチンコについて、平成18年に特許庁が取りまとめた資料。項目「2-4 抽選機能」にその言及が有る。

平成18年度 標準技術集 遊技機及びその関連技術 | 経済産業省 特許庁

調査対象技術の技術概要

2-4-2-1 乱数方式

乱数とは 、無秩序でかつ全体として出現頻度が等しい数の系列を指すが、デジパチタイプの遊技機など、図柄表示装置によって当選の可否を表示する遊技機においては、特賞等の役の当選の可否を判断するために、メイン基板内部で常に乱数をカウントしている。

乱数の生成は、ソフトウェアで行う方式(ソフト乱数方式)と、ハードウェアで行う方式(ハード乱数方式)に大別することが

出来る。また、ソフト乱数方式は、乱数のカウントが進行する形態の違いによって、プラスワン方式とプラス乱数方式に分類される。

乱数幅変更機能付き遊技機 - 特開2004−298370 | j-tokkyo

乱数発生手段10aは、例えばカウンタIC等からなり、所定の乱数幅の範囲(例えば1〜16384)でダウンカウントやインクリメントカウントすることにより、一定時間毎に一の乱数を発生させる。そして、この乱数発生手段10aで発生する乱数の上限値が乱数幅変更手段10eによって変更され、これによって抽選処理における各入賞内容の当選確率が変更されることになる(図5参照)。

ここで、乱数発生手段10aとしては、例えば、カウンタICを用いて乱数となる数字をハードで生成して取り出すハード乱数と、CPUのソフトウェアによって乱数となる数字を生成するソフト乱数とがあり、本実施形態の乱数発生手段10aは、いずれの方式であっても良く、両方式を併設することもできる。

no title

また、警察庁生活安全局保からの通達において、遊技機についての規格解釈基準が発行されている。

平成16年5月26日警察庁丁生環発第155号

内部抽せんは、条件装置の作動等、遊技の結果に影響を及ぼすものである。出現する乱数値に偏りが出る仕組みは「当せんする機会を容易に推定することが、できる仕組み」であると解する。よって、内部抽せんが、周期が一回の遊技の結果が得られるまでの間において終了しない仕組みである等出現する乱数値に偏りが出る仕組みである場合には、当該内部抽せんの偏りが出る仕組みは、本規定に抵触する。

当り乱数を現状の初期値更新型乱数とした場合、大当り判定値には素数以外を使用してよい。

基本乱数について、乱数にあるそれぞれの値の発現方式が、乱数の数列に沿って順々に値を発現させる方式(本集で「プラスワン方式」という。)と、乱数の数列の最終値が発現したときの次の値(本集で「初期値」という。)を偶然性のある値によって定める方式(本集で「初期値更新方式」という。)を併用している等、基本乱数値を容易に推測させない方式である場合に、当たり判定データ値が素数以外であること又は複数の連続した数値であることは差し支えない。ただし、基本乱数を構成する値の総量、当たり図柄乱数を構成する値の総量等、内部抽せんに係る乱数を構成する値の総量は互いに素であるか、又は当該乱数における一の値の発現から次の値の発現までの時間間隔が互いに素でなければならない。

ソフトのみで更新する当り乱数(カウンタ)は1割り込み毎に+1更新するカウンタとすること。

基本乱数にあるそれぞれの値の発現方式がプラスワン方式であることは、別表第三(2)ハ(ニ)の規定に適合する方式である限り差し支えない。

当り判定に、プログラムより高速でカウンタを更新するハード乱数を使用してよい。

基本乱数にあるそれぞれの値の発現方式がプラスワン方式であること等、当該基本乱数にあるそれぞれの値の発現が規則的である方式であっても、別表第三(2)ハ(ニ)の規定に適合する方式である限り差し支えない。

技術上の規格解釈基準について - 警察庁

別表第三 不正な改造その他の変更を防止するための遊技機の構造に係る技術上の規格」関係

(2)ハ(ニ)

内部抽せんは、条件装置の作動等、遊技の結果に影響を及ぼすものである。出現する乱数値に偏りが出る仕組みは、「当せんする機会を容易に推定することができる仕組み」であると解する。よって、内部抽せんが、周期が1回の遊技の結果が得られるまでの間において終了しない仕組みである等出現する乱数値に偏りが出る仕組みである場合には、当該内部抽せんの偏りが出る仕組みは、本規定に抵触する。

また、気になってJ-PlatPatで「乱数」をキーワードに含む特許を調べたところ、遊技機もしくはパチンコで登録された乱数に関する特許1994年が初の出願となっていた。

上記のように警察の解釈や特許の状況を見るに、状況証拠での判断となるが(保安通信協会の内規など一部資料には簡単にアクセスできなかったため)、乱数の取り扱いに関しては規定があるものの、乱数そのものの生成方式の制約ついて言及はなく、生成方式固有の偏りについてもまた言及がない(乱数生成後の処理による偏りについての言及は有る)ということがわかった。

このような状況下においてtotoBIGのようなシステムを作る場合(もちろんパチンコとは別の話し合いが有ると考えられるが)、技術仕様を満たしていれば合法であり、たとえ実装上の擬似乱数において今回のような事象が発生したとしても、誰にも否はないと判断せざるを得ない。

ただ、この状況をこのままにしておくかどうかについてはまさに政治的判断が必要で、正しい改善方法としては法律もしくは省庁からの通達において、乱数生成については真性乱数を利用することを明記するしかないと思わる。

(もちろん真性乱数とは何か、真性乱数発生器の検査は誰がやるかなど新たな利権は生まれそうだが…)

話は飛ぶが、真性乱数発生器も昔に比べるとだいぶお手頃になったと思う。一個くらい買って遊んでみたい。

量子物理に基づく真性乱数発生器 RANDOM NUMBER GENERATOR AR-QUANTIS IDQ | 部品・ユニット | 株式会社アルゴ

2017-02-08 読モ化はライターだけではない、もっと広域な作り手側の問題だと思う

読モ化はライターだけではない、もっと広域な作り手側の問題だと思う

no title

「ライター」を名乗り、それを生業にしている筆者は、ライターを取り巻く現状について考えることが多い。といっても、現在では「ライター」の定義自体が揺らいでいて、同業者と話していても共通認識が得られず、議論が空転することもしばしばだ。しかしそこに、「ネットやSNSの出現によって、ライターの仕事が『読モ』みたいなものに近づいている」という補助線を引くと、現状がクリアになる気がする。

このニュースを読んで色々と頭にあったことが筆者と同じく自分自身もだいぶスッキリした。作者も書いているとおりだけれど、この「読モ化」という概念を咀嚼する上でまず整理しよう。

  • 作り手
    • 記事のライターや、クリエイター技術者など
    • 物を作ったり技術を探求する人などが該当
    • コンテンツを供給する側の人
  • 受け手
    • 消費者や読者など、作り手が作ったコンテンツを受給する側の人
  • 読モ
    • 「顔出し」や「本人そのものがコンテンツ化(商品化)」する事
    • 主に作り手側の意識や戦略、身なりに関する表現
    • 読モ化した作りて手には、作品より作者本人に価値があると言う周囲の認識が伴う
    • また読モ化した作り手の特徴として、作品作りは「自身のタレント性を表現する一つの手段」であり、こだわる必要がない(偶然それができるからそれをやっているに過ぎない)
    • 例)「ライターの過度な顔出し(本人が出ることがコンテンツである、彼とか)」「コスプレイヤーの作品再現より本人が前に出た作品など(その作品のキャラになるのは自身に注目を集めるための手段)」「ボカロ曲を作っていたと思ったら本人のニコ生が始まって曲を作らなくなった(曲を作るのは注目を集める手段)」
  • 読モ
    • 作り手側の「読モ化」の度合い。受け手側(読者や消費者など)が感じ取るバロメーター
    • 主に受け手側がその人やその作品を判断するときの基準としている(無意識にしている場合が多い)
    • 例)「あの作者が可愛いから作品を買う(買う動機は、あくまで可愛い作者だから)」「可愛い女の子が登壇するからXamarin勉強会に行く(勉強会に行く動機は可愛い女の子に会えるから)」
    • このように作りて側の「読モ化」が受け手側の行動に作用するエネルギーを「読モ力」として考える

読モ化」が主に作り手側の変化の話なので、その変化に伴うエネルギーを「読モ力」とした。こうすることで理解が進む。

読モ化」はなぜ発生するのか

先程の記事では「読モ化」しているという話だったが、掘り返してみるとなぜ作り手が読モ化するのか、と言う疑問が湧いてくるはず。そこで自分なりに頭を整理してみた答えがこれだ。

  1. 受け手側が作品の善し悪しを判断するときに、作者の人間性を気にする文化はもともとあった(ネット時代よりもさらに前からの前提として)
  2. ネット時代が到来し(概ねWeb2.0到来以降)作品を公開するあらゆるプラットフォームが整備され、ネット上に大量の作品が溢れた
  3. ネット上に大量に作品が溢れた結果、受け手側の自分好みの作品を探し出す手間が膨れ上がった
  4. ネット上に大量に作品が溢れた結果、作り手側の練度は大幅に向上し所謂「うまい作品」が増えた
  5. 3,4のサイクルが何回か回った結果、ネット上に「うまい作品*1」が溢れ、さらに受け手側の手間が膨大になった
  6. そして「うまい作品」は希少性を失っていった(「うまい作品」であるためのハードルが遥か高くに設定されてしまった*2
  7. 作品の希少性が失われると、作り手側に還元される「承認」は不足し、作り手は「承認不足」の状態になる(その作品へのアクセスが増えたとしても、反応は減るため)
  8. 作り手側は「承認不足」の状態を脱却するために、より楽に注目を集める事ができる差別化要因を探し出す
  9. この時並行して受け手側も作品探しに疲弊しており楽な方法を探していった結果、作品とは関係ない作者の人間性を気にするという文化が先鋭化していった
  10. 受け手のそのような変化は、作り手側から楽で効果のある差別化要因として認識される
  11. 結果として本人自体を売りとする手法や考え方が確立され広がっていった

この流れの中で受け手側の疲弊を解消するために生まれたのがキュレーションという考え方です。(悪用されちゃったけど機能としては良い)

また、「読モ化」が進みすぎた結果発生するのが「オタサーの姫」であり、諸問題色々有るけれど根源はここかと。

このように、受け手側と作り手側の変化が双方に影響を与えながらお互いに妥協点を探していった結果が「読モ化」であると考えている。

読モ化」と承認欲求とメリットデメリット

先程の解釈の上では「承認」と「承認不足」という単語を出して説明した。これは単に承認欲求に於ける承認の話。ただし、一般的な承認欲求に於ける承認の解釈に「支払われる報酬も承認である」という解釈を加えた上で、この「読モ化」を咀嚼する必要がある。

というのも、この記事に於いては特に生業としてのライター(Webで記事を書くライターも含めて)の「読モ化」も指摘しているからであり、それ以外の理由としても、今現在生業としての「作り手」が置かれている状況を加味すると、報酬と承認は切り離せない関係にあるからである。

自分自身クリエイターもやっているので報酬はよく意識しているが、生業としての「作り手」にとっては「SNSでもらえるいいねやFav」と同様に「やった仕事でもらえる報酬」や「尊敬する人やすごい人と一緒に仕事ができたこと」についてもその仕事を続ける上、作品作りを続ける上では重要な承認である。

これらの承認の要素に「読モ化」がどのような影響を及ぼすかというと

メリット

  1. 読モ化」することで本人に注目が集まり、アクセスが欲しいクライアント意向とマッチする
  2. 読モ化」することで担当に気に入られることで仕事が増える、結果として報酬も増える(ここで安価な発注をするとご破算になる。女性ほど有利な手法
  3. 読モ化」することでつながりが増えて業界の中で生きているぜっていう感覚が生まれる(自己承認を行う)
  4. 読モ化」することで何となく自分は特別という感覚が芽生えてきて仕事に取り掛かれる(自己暗示に近いけど実際効果はある)

デメリット

  1. 読モ化」すると周りの職人気質な作り手からバカにされたり軽蔑される(しかし本当にデメリットはあるのか?交友範囲でカバーできるのでは?)
  2. アンチが増える(しかし、精神力が強ければ耐えられる、所詮ネットだし)
  3. 読モ化」するとプライベート含めて人生オープンソース化するので、家庭持ちには辛いかも(やまもといちろうみたいな例も有るが、敵を作らなければ良いという話もある)
  4. 女性が「読モ化」すると、アンチに加えてストーカーも発生する(そして実際に事件になる例もあるが極稀である)

色々と考えてみたが「読モ化」はアンチが増えるがそのデメリットを無力化できる一般常識や思考力や精神力があれば、いい事だらけでありむしろなんでやらないのと言い出しそうな人が多分にいるのもよく理解できる。

読モ化」について作り手が取るべきバランス

記事の中で筆者は

筆者が思うのは、おそらく現在、多くの人が「ライター」としてイメージするのは「読モ」としてのライターなんだけど、彼らが物書きとしての「本流」になることはないということだ。

と述べているがこれは本当だろうか?

おそらくこの記事を書かれた胸のうちにあんな奴らとは違う俺は本流だ、というような意識を垣間見えることができる。たしかに一般的に見て「読モ化」していくとチャラく見えるので、実力がないのにちやほやされやがって、と思われるのは仕方がないことだろう。ただし、本流かどうかはその本人の実力や作品自体の練度の高さが物語るのであって、決して「読モ化」と同じに語ってはいけない。

読モ化」すると身の丈にあっていない仕事が来ることはおそらく増えるだろう。ただし、作り手ならば来た仕事に全力で答えて身の丈を伸ばして行けばよいだけの話で有る。ただ、この筆者が指摘したいことは多分、読モ化」することによって、実力を伸ばすような仕事が来なくなり(周りはキャラを売ることを求めるから)、「本流」を伸ばすための実力が付かなくなる(実力をつけるための余力がなくなる)ことを懸念しているのではないかと考えられる。(汲み取り過ぎかもしれんけど)

作り手が「読モ化」という禁断の果実に手を出すときは、そのバランスを見誤ってはならない。より自分におごること無く、実力がつくかどうか、人気が出るかどうか、承認は増えるかどうか、をバランス良く考えていくことが重要となる。

このバランス感覚を鍛えた上で「読モ化」という手段をとれるならば、それはとても強い武器になると思う。

読モ化」の失敗例

失敗から学ぶのは重要である。「読モ化」の失敗例は身の回りに転がっているからよく観察するといいだろう。決してコードをあまり書かないが開発者向けに勉強会と称した事実上の姫集会をやっているような人になってはいけない。

*1:わかりやすくするために、絵に例えてうまい作品というような表現をしている。WEBの記事であればより共感できることや納得がいくこと、深く考察されていることなど、それぞれの分野の尺度で測ったときにこれはうまい(良い)作品だと言えるものとして考えてください

*2:今でもちゃんと本当にうまい作品は評価されるが、その基準が少なくともプロよりもうまい必要が出てきてしまった

2011-11-07

Infinite Storage 220をDS3400にする

概要

自宅ストレージの強化を行うために、ひょんなことからSGI InfiniteStorage 220を手に入れたので色々調査したところ、IBM System Storage DS3400と中身が同じ(OEM供給元一緒?)だったので、FW書き換えとかそのあたりの話。というか、ニッチ過ぎて需要があるかわからないけどとりあえず。

という訳でまずは手順から。だいたいこんな感じで作業していきます。

 SGI IS220 > FW書き換え > IBM DS3400(v06.70.69.00) > FW書き換え > IBM DS3400(7.35.66.00系FW)

ココでこだわりたいところは、FWがversion 7.xx.xx系であること。これはなんでかというと、LUNのサイズ上限が解除されるため。6.xx.xx系FWではLUNのサイズが2TBで強制的に切られるため、単一ボリュームとして大容量なものを用意するときには物足りない。あと7.xx.xx系ではRAID6が使えるのでこのあたりも色々とベンチしてみたいところ。

- Added support for RAID 6 (p+q implementation)
- Support for greater than 2TB Logical Drive. 
- Support for RAID 0 and 1 arrays with more than 30 drives.
- Increase maximum number of partitions to 32.
- Support for IPv6 on the controller management Ethernet ports.  
- Support Telnet protocol on the controller management Ethernet ports.

IPv6対応が面白い。こういうネットワークに繋がるけど本格的にネットワーク使わない感じのHWのIPv6対応はまだ珍しいので、どんどん頑張って欲しいところ。あとTelnetが地味に便利。コンソールケーブルが独自形式なのでケーブル無いときに。

ファームウェア書き換え

という訳でファームウェアの書き換えを行う。今回はIBM System Storage DS Storage Manager version 10.77.35.16を使った。Versionは10.77系以降であること。古いVersionではアップデートに失敗したり、ソフトウェア側がFWに対応しきれていない。

手順としては、Storage ManagerでIS220へ接続し、FWを更新していくだけ、FWのVersionにあわせたNVRAMは適切なタイミングで上書きしていく。

というわけで

View Storage Subsystem Profileの出力が変更されていることを確認。

  • 変更前
   Number of controllers: 1 
      Controller in Enclosure 85, Slot A 
         Status: Online 
         Current configuration                        
            Firmware version:      06.70.41.00        
               Appware version:    06.70.41.00        
               Bootware version:   06.70.41.00        
            NVSRAM version:        N1932-670863-100   

         Board ID:                 1932               
         Submodel ID:              64                 
         Product ID:               IS400              
         Product revision:         0670               
         Serial number:            ##########         
         Vendor:                   SGI                
  • 変更後
   Number of controllers: 1 
      Controller in Enclosure 0, Slot A 
         Status:                      Online                         
         Current configuration                                       
            Firmware version:         07.35.66.00                    
               Appware version:       07.35.66.00                    
               Bootware version:      07.35.66.00                    
            NVSRAM version:           N1726D34LR335V06               

         Board ID:                    1932                           
         Submodel ID:                 64                             
         Product ID:                  1726-4xx  FAStT                
         Revision:                    0617                           
         Replacement part number:     097-0329-001                   
         Part number:                 21201-07                       
         Serial number:               ##########                     
         Vendor:                      IBM                            

VendorがIBMに、Product IDはFAStTとなって、中身がまるっとDS3400化。シリアル番号は同じままでした。後はこのまま運用試験をしてみようかと。

2011-08-29

Macmini(Early 2006) メモ

WindowsXPIEEE1394デバイスを使う必要があったので、転がっていたMacmini(Early 2006)にWindowsXPを突っ込んでました。ドライバ周りで苦戦したのでそのあたりメモ。

デバイス詳細その他
CPUCore solo 1.5GhzCore2DuoMerom)まで換装可能
チップセットIntel GAM 950内蔵VGADriverも同時に入れる
RAMPC2-5300 DDR2 256MB*2MAX 2GB
HDDST96812AS5400.2 SATA 1.5Gb/s 60-GB Hard Drive
LANMarvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller
WLANAtheros AR5006X Wireless Network Adapter802.11a/b/g
SoundSigmaTel High Definition Audio CODECVer 5.10.5185.0 OSX インストールディスクのwindows supportからインストール
DriveMATSHITA CD-RW CW-8124COMBO

ドライバインストール手順としては、http://macxp.furbism.com/ にある「mini.drivers.all.zip」を入れた後に適当なOSXインストールCDからBootCampサポートを入れることで完了。AudioDriverを無線LANDriverがOSXインストールCDに収録されているものでしかインストールできなかったので注意。