開発^3

Web開発、宇宙開発、ゲーム開発の3種類についてつらつらと

maimaiでらっくすの問題点

maimaiでらっくすが出て1か月ちょい。 色々困る点はありつつも、それなりに慣れたので改めて問題点を書いてみます。

書いてる人

  • 無印maimaiからなので7年ぐらい
  • FiNALE 8段 Max 15.58(3470クレ)
  • でらっくす 9段 Max8500(75クレ)

それなりには出来るけど、上位の人たちとは大分差がある、でもmaimaiたのしー。な人です。

達成率(スコアシステム)

5月に公式にメールした時の記事にも書いていますが、1.02を受けて改めて。
マシにはなった、マシにはなったんだけど方向性が変わってないので、問題点も変わっていないです。
前回記事でも書きましたが、今作のスコアシステムの問題点は以下の2点

  • プレイヤーのうまくできた感と達成率がリンクしていない
  • 極端なBreakの精度ゲー

1.02になっても解消はされておらず、「ヒバナ」のMasterを例にするとこんなことになります。

パターンA(色々失敗したがBreakはCritical Perfect)

Great 10 / Good 1 / Miss 2(-100 * 10 - 250 - 500 * 2 = -2250)
Break2つはどちらも2600
(501500 - 2250) / 501500 * 1.005 + 0.5%100.5491%

パターンB(ほぼミス無しだがBreakがPerfect)

1グレのみ(-100)
Break2つはどちらも2500
(501500 - 100) / 501500 * 1.005 + 0%100.4799%

前者を見ればわかりますが、SSS+なんてフルコンすら要らないんですよ。Breakだけ光れば他がボロボロでも乗ります。
逆に、どんだけうまくできてもBreakが光らなければ達成率はボロボロです。

高スコアを出すためには何よりもBreak精度が重要になるわけですが、少なくとも私は、譜面の極一部でCriticalが出るか出ないか(2F)に拘るようなゲームをやりたいわけではありません。

達成率(スコアシステム)その2

maimai FiNALEまでの2600はすごく良かったと思っています。
個人的な難易度は以下のような感じですが

S < FC < 赤FC <<<<< AP <<<< 理論値
※理論値難易度は譜面によって大きく違う

Breakの2600が入ることで数グレの許容ができ、赤FCからAPまでの長い道のりの中で丁度良い中間目標となってくれました。

S < FC < 赤FC << 鳥S <<< AP <<<< 理論値
※鳥S、理論値難易度は譜面によって大きく違う

また、APが取れてもBreakをいくつか落としていることは多々ありましたが、その場合も数百点(数グレ)程度の差だったたため、APには「やり遂げた」という達成感がありました。

さて、でらっくすです。 まず大きな変化として理論値(101.00%)以外の達成感がだいぶ少なく無くなりました。

  • 99.8%: Break光ってれば鳥S乗ったのに……
  • 100.1%: Break光っただけだしなぁ……
  • 100.4%: Break光ってれば鳥S+乗ったのに……
  • 100.5%: 達成感はあるけどBreak光っただけだしなぁ……そもそもFCすらしてないし……
  • AP: やった……って100.80%……0.20%落ちとか達成率的にはボロボロだぁ
  • 理論値: やった!

自分の腕では多数のBreakを安定して取ることは出来ないので、理論値ペースの後半とかBreak来なけりゃ良いのに……とか思ってますorz
FiNALEの頃は99.9%に落ちたスコアを最後のBreakでギリギリ100%に乗せたり、楽しかったなぁ……

レーティングシステム

Recent枠が無くなったのは良し悪しありますが、まぁ直に受け入れられました。
一応書いておくと個人的なメリデメは以下の通り

  • メリット:苦手曲に手を出しやすくなった
  • デメリット:変化が少なくなったのでずっとこの数字と付き合うことになりそう

問題はBest枠のSSS+上限化。スコアシステムの問題がここにも。

まず、1.02で少しマシになったとはいえ、SSS+は割と失敗しまくってもBreakさえ光れば取れます。
そうすると運よくBreakが光ってSSS+に乗ったプレイがBest枠に乗るわけです。
実際自分のスコアでもSSS+済の未FC+、未FCがちらほら。

さて、プレイヤー的にはまだまだ先があるわけですが、レーティング的にはこの曲を詰める理由はもうありません。
実際はFC埋め、FC+埋めをするのでプレイしないわけではないんですが、AP出してもレーティングが微動だにしないのはちょっと凹みますね。

オンゲキならSSS+(1007500)に乗せるにはほぼABFBが必要になるので、SSS+が上限でも良いんですが、maimaiでらっくすのこのスコアシステムでSSS+(100.50%)が上限なのはダメでしょう。
かといって100.75%を上限にするのもダメです。100.75%を上限にしたらBreak精度をさらに求めるゲームになりますし、それがプレイヤーの腕を反映していないのは前述した通りです。

お友達対戦

メインは語ったので後はさっくりと。

  • 相手の名前出ないので対戦感が少ない
  • 負けた時のゲージ、レーティング減少がでかいので確実に勝てる相手が来るのを待つ作業ゲー

タッチノーツ

大分慣れたものの、やっぱり押していて楽しさが薄いのが困り者。
判定が緩すぎるのと、判定抜けを嫌って手のひら全体で取るので、全体的におおざっぱな感が強く、リズムに合わせてノーツを取っている感じが弱いのが原因だろうか?
スライド中のタッチノーツも「これならスライドだけで良いよなぁ」と思ってしまうことがしばしば。
あと、エフェクトが邪魔で次のノーツが見えないことも多々。

100円3曲固定

筐体スペースやら考えると仕方が無いとは思いつつ、ぼっちにはツライ。

maimai でらっくす のスコアシステムについて

maimai でらっくす のスコアシステムについて、どうにも気になる点があったたため、公式にメールしてみました。 以下、内容。


いつも楽しく遊ばせていただいています。 出先でmaimaiでらっくすのロケテが行われていたため、遊ばせて頂きました。

JAEPOで発表された際も懸念点としては感じていましたが、実際に遊んでみた結果、スコアシステムについてあまりにも受け入れがたい点があったため、意見として送らせていただきます。

スコアシステムの問題点について

問題と感じているのは極端なBreak精度ゲーになっており、プレイヤーの「うまくできた感」とスコアが全くリンクしていない所です。

例として「ヒバナ」のMasterを上げますが、(簡略化のため)Hold/SlideはAll Perfectとした場合のスコアは以下のようになるかと思います。

ノーツ数: Tap 483 / Hold 48 / Slide 138 / Break 2
Break加点除く総得点: 483 * 500 + 48 * 1000 + 138 * 1500 + 2 * 2500 = 501500

パターンA(色々失敗したがBreakはCritical Perfect)

Great 10 / Good 1 / Miss 3(-100 * 10 - 250 - 500 * 3 = -2750)
Break2つはどちらも2600
(501500 - 2750) / 501500 + 1%100.45%

パターンB(ほぼミス無しだがBreakがPerfect)

1グレのみ(-100)
Break2つはどちらも2500
(501500 - 100) / 501500 + 0%99.98%

問題点

プレイヤーからすれば、明らかにパターンBの方がうまくできたにも関わらず、スコアとしては0.5%近くも低いボロボロ。
この問題は、Breakが少ない譜面で顕著ではありますが、多かれ少なかれ同じ問題を抱えることになります。

高スコアを出すためには何よりもBreak精度が重要になるわけですが、少なくとも私は、譜面の極一部でCriticalが出るか出ないかに拘るようなゲームをやりたいわけではありません。
CHUNITHM/オンゲキのように全ノーツに+1%を割り当てる形であれば良かったのですが……
(旧データに精度情報が無く、スコア引継ぎのために、この方法は取れなかったのだとは思いますが)

旧スコアシステムであればパターンAが99.49%、パターンBが99.98%とプレイヤーの感覚とも合致したスコアになっていました。
個人的に101%への統一なんて求めていなかった、という事情もありますが、ここまで酷いスコアシステムにしてまで101%へ統一する必要があるんでしょうか?

色々と考えられた上での実装かとは思いますが、なにとぞご再考のほど、よろしくお願いします。

ISUCON8に1人で参加してきました

ISUCON7は3人チームで参加しましたが、今回は1人参加も可能ということで、ぼっち参加してきました。
1人参加は枠数が限られていたので、慌てて申し込んだ結果、実は見たことのない「RE: ゼロから始めるISUCON 」に。

結果は最高スコア32,596、最終スコア26,873で予選落ちではあるものの、去年の反省を活かした動きである程度のスコアが出せたのは良かったです。
ただ、正直手が付けられていない箇所が多すぎて、不完全燃焼感も。
# 後日の検証でLBだけ有効にしたら79,356でましたが、不安定だし、たらればですね。(でも書いちゃう)

やったことと感想

事前に決めていたこと

1人参加、かつアプリ寄りの人間のため、迷ってる暇はなさそう。インフラ側の変更は最低限にして、アプリの改修を優先しよう。
ISUCON7でも使用したkataribe, pt-query-digest, netdataは今回も使いたいな。特に前回の教訓を元にネットワークの帯域には気を付けよう。
1人だと自由に本番環境を使えるから、手元環境で動作させる必要は無いよね。いつも使ってるdotfilesを本番に入れられる準備はしておこう。
前回同様、複数台構成の可能性もあるし、普段のサーバ(tmux入り)からwindow/paneを切ってつなごう。

事前準備

  • 初期設定・計測用スクリプトの準備
  • tmuxのwindow/pane切り分け
  • 最終手順の手順書準備(不要サービス停止、ログ抑制)

チューニング方針

環境を確認した瞬間「出題DeNAじゃん!!」と叫んでしまったのですが……十分考えられる選択だったよね。
nginxに置き換えた人も多かったようですが、設定をみたら割と読みやすかったのと、事前方針を思い出してh2oのまま行くことにしました。
Evernoteからnginxインストール/設定手順を取り出してダウンロードまでは掛けたんですが)

チューニングの手順としてはpt-query-digestで重い部分を洗い出して修正していくという基本的なもの。
一通りコードを読んでget_events/get_eventが重いことは明らかだったんですが、呼んでいる箇所が多すぎて挙動を変えづらいのが難点でしたね。

結局、cancelの扱いがクエリを複雑にしているので、現在の予約状況を示すテーブルを新しく切って対応しました。

current_reservations(
    id,
    event_id,
    sheet_id,
    num, rank,
    user_id,
    reserved_at,
    reservation_id
)

非正規化の極みとばかりに、どんどん必要になったカラムを増やしていきましたが、最終的にはcurrent_reservations自身がボトルネックになってしまっていたのがちょっと残念かな。

(対応した順番としてはこっちが先ですが)残席数管理はredisにしました。
残席自体もredisのsetで管理しようと考えたんですが、何故か残席のsetじゃなくて、予約席のsetを作ろうと考えてしまい、そうするとreserved_atをどこに持とう?とか考えて、結局RDBにしてしまいました。
atomicなpop処理ができれば、redisだけでロックの代替ができたのかな?

後は細かいところをあれこれと弄っていました。 - get_eventは呼び出し元によってはdetailが要らないので、with_detail引数を増やしたり - sheets情報をpython中にハードコーディング - sha256の計算をhashlibでやってみたり - kataribe的にloginが重いと言われたからやってみたけど、ストレッチングも無いのでそもそも重くないかも - テーブルへのindex追加 - get_login_userを呼ぶ必要のない場所があったので削除 - mysqlをserver3に移動

悔やまれる点

  • admin側が全然見られなかった
  • lock問題についてはそこまで悩まされなかったが、理解して回避したというより、運よく回避した、という感じが強い
  • 実際、スコアが不安定で、failすることもあった
  • 明らかにここ変えたい、という場所に手が回らなかった
  • order by rand()
  • h2oのLBが/etc/hostsでできることを知らなかった
  • /etc/hostsに2レコード書いてping飛ばすところまではやったけど、ダメだったのであきらめた。h2o本体で試すべきだった。
  • ISUCON7予選のトラウマから50Mbpsのグローバル帯域を気にしすぎた

課題・環境について

ポータルがすごく便利。ベンチマークも全く待ち時間が無く、とても快適でした。
課題としては面白かったものの、lockが主題になるとスコアが安定しないのが難点か。
修正が役に立ったのかどうかがもひとつ判断できず、ツライ時間が続いたりしました。

サーバについては、終了後にベンチ環境まで含めて1週間公開してくれるというのがすごくありがたいです。
時間切れで試せなかった場所とか、ロックの関連とかいろいろ見てみたいと思います。
サーバ提供のConoHa GMOインターネット株式会社さまと、このはちゃんには足を向けて眠れませんね!

1人参加のメリット・デメリット

さて、せっかくの1人参加ということで、1人参加のメリットとデメリットも書いておこうと思います。
ISUCON9で1人枠が用意されるかはわかりませんが、参加を考えている人は参考にしてください。

メリット

  • 自宅から参加できる(いつものPC、いつものキーボード、移動時間0分)
  • 本番環境を自由にカスタマイズ可能(zsh, vim
  • 本番環境で直接作業ができる(gunicornをフロントで起動)
  • ベンチマーク実行時とかに他の人の確認を取る必要が無い
  • 何をやったか、どこまで終わったかが常に把握できる

デメリット

  • 手が足りない
  • 嵌ったときにグーグル先生にしか頼れない
  • 改修してもスコアが出ない時間が続くと気持ちが折れやすい
  • 知識のカバー範囲が足りない
  • アプリ1人、インフラ1人、計測&方針決定1人のチームが強そう
  • 打ち上げがちょっと寂しい

出遅れたけどBingoカード生成問題書いてみた

blog.jnito.com

RSS整理してたら再発見したので書いてみた。 回答締切どころか既に模範解答まで出てるけどまぁ、それはそれ。

class Bingo
  def self.generate_card
    values = (1..75).each_slice(15).map(&:shuffle).transpose.first(5)
    values[2][2] = ''

    header = %w(B I N G O)
    ([header] + values).each do |row|
      puts row.map { |col| col.to_s.rjust(2) }.join(' | ')
    end
  end
end

Bingo.generate_card

行列を転置することで割ときれいに書けた気がする。満足。

H-IIA 102型のΔVを計算してみた

Twitterを見ていたらH-IIA 102構成なんてのが話に出ていたのでちと計算。

今までこの類の計算したことないのでググりつつ。違ってもご愛嬌。

さて、まずは公式サイトから各種の値を調べてみよう。

http://www.jaxa.jp/projects/rockets/h2a/index_j.html

第一段 SRB-A(2本合算) 第二段 フェアリング(4S)
重量 114トン 151トン 20トン 1.4トン
 推進薬重量 101.1トン 130トン 16.9トン
 構造体重量 12.9トン 21トン 3.1トン 1.4トン
推力 1098kN 5040kN 137kN
燃焼時間 390秒 100秒 530秒
比推力 440秒 283秒 448秒

SRB-Aは数字を見る限り高圧型ですね。

さて計算開始。

SRB-A燃焼終了まで

最初は1段目とSRBが同時燃焼するので比推力がややこしい。

ググったらこんなQAが引っかかったのでそのまま式を使わせてもらおう。

http://okwave.jp/qa/q4133393.html

Isp = (F_B + F_L) / (F_B×Isp_L + F_L×Isp_B)×Isp_B×Isp_L
Isp = (5040 + 1098) / (5040 * 440 + 1098 * 283) * 283 * 440 ≒ 302.3秒

合算した比推力は302.3秒とでた。うん、感覚的にもあってるっぽい。

打ち上げ時質量

さて、質量を求めます。

1段目、SRB2本、フェアリングで114 + 154 + 1.4 = 269.4t。ペイロードは……とりあえず空で。

SRB燃焼終了時質量

打ち上げ100秒後にSRBが燃焼停止するのでこの時点の質量を求めます。

1段目はMECOまで390秒。推進薬101.1トンの25.6%ほどを消費したとみて、残りの推進薬は75.2トンほど。

エンジン、タンク等の構造体含めて88.1トンですね。SRBは全推進薬を消費したので21トン。

合計で88.1 + 21 + 1.4 = 110.5トンですかね。

ΔVの計算

ツィオルコフスキーの公式からΔVを求めると

9.8m/s^2 * 302.3 * ln(269.4 / 110.5) = 2640m/s

SRB-A分離から1段目燃焼終了まで

残りは1段目が頑張る。

初期質量

SRB-Aを分離したので残りの質量は88.1 + 1.4 = 89.5トンほど。

MECO時質量

打ち上げから390秒後にMECO。この時点の質量は12.9 + 1.4 = 14.3トンぐらい。

実際には途中でフェアリングを放棄しますが、まぁ、ペイロード替わりってことで。

ΔVの計算

同じくツィオルコフスキーの公式からΔVを求めると

9.8m/s^2 * 440 * ln(89.5 / 14.3) = 7908m/s

合計で2640 + 7908 = 10548m/sか。

……あれ、思ったより速い。

もっとボロボロの結果がでて、「やっぱりSSTOは無理だったよ(知ってた)」となると思ったんだが……

重力損失とか空気抵抗とか考えるとSSTOは厳しいにしても、ここまで速度が出せるとはびっくり。

何か計算間違いしている可能性もあるけど気にしない。

まぁ、そうは言っても

3トンのペイロード積んだ場合

9.8m/s^2 * 302.3 * ln(272.4 / 113.5) = 2593m/s
9.8m/s^2 * 440 * ln(92.5 / 17.3) = 7229m/s

2593 + 7229 = 9822m/sとなるので、やはり実用的なSSTOはまだ先の様子。

おまけ:通常のH-IIA 202(ペイロード5トン)の場合

初期質量:114 + 151 + 20 + 1.4 + 5 = 291.4
SRB燃焼終了時質量:88.1 + 21 + 20 + 1.4 + 5 = 135.5
ΔV = 9.8m/s^2 * 302 * ln(291.4 / 135.5) = 2266

SRB分離後質量:88.1 + 20 + 1.4 + 5 = 114.5
MECO時質量:12.9 + 20 + 1.4 + 5 = 39.3
ΔV = 9.8m/s^2 * 440 * ln(114.5 / 39.3) = 4611

1段目/フェアリング分離後質量:20 + 5 = 25
SECO時質量:3.1 + 5 = 8.1
ΔV = 9.8m/s^2 * 448 * ln(25 / 8.1) = 4948

2266 + 4611 + 4948 = 11825

流石。

Ctrl + Shift + SpaceでScanSnap Managerのダイアログが開いてしまう場合の対策

2) PfuSsMon32.cfg ファイルを、メモ帳などで開き、以下の項目
 (IsRegist_HotKey=0)を追加してください。

 [CONFIG_C]
 IsRegist_HotKey=0

http://aide-memoire.seesaa.net/article/20699317.html


リンク先は2006年の記事なので、ScanSnap ManagerかSpanSnap本体のバージョンアップに伴って場所が変わっているようだ。
iX500に付属してきたScanSnap Managerの場合、同ディレクトリのSsCommon.cfgに同様の設定を書くことで抑止できた。

例で学ぶ所得税と年末調整(ついでに復興税)

会社によって時期は違うようですが、そろそろ年末調整の書類を提出した人が多いかと思います。でも、年末調整の仕組みや所得税の仕組みをちゃんと知っている人は少ないのではないでしょうか?会社務めをしていると会社側で計算してもらえるため、あまり関わることはありませんが「理由はわからないけど引かれてる」のは、なんとなく気持ち悪いものです。
ということで、とあるサラリーマン「Aさん」を仮定して所得税を計算してみたいと思います。


Aさんの例を使った計算は青文字で書くことにします。

なお、独学で調べただけなので勘違いしている箇所があるかもしれません。あしからず。
あと、全部の分野を1エントリで書くのは無理なので、ほどほどに一般的な「Aさん」を仮定します。

まずは「Aさん」の設定


年収:600万円
年齢:40歳
勤務先:東京都
健康保険組合全国健康保険協会協会けんぽ
家族構成:本人、妻(専業主婦)の2人
生命保険:月額6,000円の生命保険を支払中

そもそも年末調整って?

支払い済みの所得税と、実際の所得税を差し引きして調整するための仕組みです。
住民税は「昨年の収入」に対してかかる税金のため、既に金額が確定していますが、所得税は「今年の収入」に対してかかる税金のため、12月の給与明細が出てこないと税金の額が確定しません。*1

しかし、年末や年度末になってから一括で所得税を徴収すると、国としても収入が読みづらく不安定になりますし、徴収される側としても年末にいきなり大金が持っていかれるのは困ります。そのため、毎月の給料や賞与(ボーナス)の支給時に所得税を引いた額を支給しています。これが源泉徴収です。

では所得税って?

その名の通り「所得」に対してかかる税金です。分かりやすく言えば収入に対してかかる税金ですが、収入全額にかかるわけではなく、様々な「控除」が存在します。

所得税=(収入 − 控除) × 税率

収入の種類や、家族構成などによって控除の種類は異なりますが、大抵のサラリーマンは「給与収入」のみを考えれば良いでしょう。「給与収入」は普段目にする「給与」「賞与(ボーナス)」の合計額になります。(手取り額ではなく、色々引かれる前の金額)
この「給与収入」は幅広く、月の給料、ボーナス、住宅手当、食事手当、職能給などを全て含みます。ただし、通勤手当だけはちょっと取り扱いが特殊です。今回は概算ということでAさんは通勤手当なしで給与収入600万としておきます。


Aさんの場合:
給与収入 = 6,000,000円

それでは、様々な控除について一つずつ見ていきたいと思います。

給与所得控除

まずは給与所得控除です。
自営業者などであれば「収入−仕入原価−経費」で利益(所得)が求まりますが、サラリーマンの場合は「経費」というものがはっきりしません。そのため、給与収入を得ている人の場合は、以下の表に従って計算した金額を「給与所得控除」とすることになっています。

給与収入 給与所得控除額*2
〜1,800,000円 収入金額×40%(650,000円に満たない場合には650,000円)
1,800,000円〜3,600,000円以下 収入金額×30%+180,000円
3,600,000円〜6,600,000円以下 収入金額×20%+540,000円
6,600,000円〜10,000,000円以下 収入金額×10%+1,200,000円
10,000,000円〜 収入金額×5%+1,700,000円

180万や360万といった境目で40%から30%、20%へ一気に変化しますが、その分補正が入っているので下図の青線(給与所得控除額)、赤線(給与所得控除後の金額)共に滑らかに変化していきます。


Aさんの場合:
給与所得控除額 = 6,000,000円 × 20% + 540,000円 = 1,740,000円
給与所得控除後の金額 = 6,000,000円 − 1,740,000円 = 4,260,000円

……と求めておいて何なのですが、660万以下の場合は早見表があります。
しかも、実際には4,000円単位で端数が切り捨てられたりするので、こっちの表の方が正確です。
http://www.nta.go.jp/shiraberu/ippanjoho/pamph/gensen/nencho2012/pdf/79-87.pdf

社会保険料控除

続いては社会保険料控除。月給や賞与からは様々な保険料が引かれていますが、この額は全額控除になります。主な項目は以下の通りです。

健康保険料

健康保険料、介護保険料、厚生年金保険料については、4月〜6月の収入に応じて金額が変わったり、4月と9月に金額の更新があったりとややこしく、これだけで1エントリ書けてしまうため、ここでは概算で求めてみたいと思います。

さて、まずは健康保険組合の話から。健康保険組合には、もともと国が運営していた「全国健康保険協会」通称「協会けんぽ」と、業界団体やグループ企業などが集まって運営する私設の健康保険組合、この二種類が存在します。
勤務先が参加している健康保険組合によって保険料率が異なり、協会けんぽの場合は勤務先の住所によって異なりますが9.85%〜10.16%(平成24年)、それ以外の健康保険組合の場合は協会けんぽより1〜2%程度安く設定されています。
また、大抵の保険組合では会社側と労働者側が半分ずつ払うことになっているため(労使折半)、労働者の負担額は給与の5%前後となります。


Aさんの場合(概算):
給与収入 = 6,000,000円
健康保険料率 = 9.97%(協会けんぽ、東京)、労使折半により4.985%
年間の健康保険料 = 給与収入 × 健康保険料率 = 6,000,000円 × 4.985% = 299,100円

介護保険

40歳以上の場合は介護保険料が発生します。
健康保険料率と同じく、所属している健康保険組合によって異なりますが、協会けんぽの場合は全国一律で1.55%(平成24年)となっています。


Aさんの場合(概算):
給与収入 = 6,000,000円
介護保険料率 = 1.55%(協会けんぽ)、労使折半により0.775%
年間の介護保険料 = 給与収入 × 介護保険料率 = 6,000,000円 × 0.775% = 46,500円

厚生年金保険料

サラリーマンの場合は第2号被保険者という区分になるため、厚生年金保険料の支払いが発生します。
平成24年の保険料率は16.766%ですが、毎年0.354%ずつ引き上げられ、平成29年に18.3%となることが既に決定されています。
これも労使折半のため、労働者の負担額は給与の8.383%となります(平成24年の場合)


Aさんの場合(概算):
給与収入 = 6,000,000円
厚生年金保険料率 = 16.766%、労使折半により8.383%
年間の厚生年金保険料 = 給与収入 × 厚生年金保険料率 = 6,000,000円 × 8.383% = 502,980円

雇用保険

4月に改定されて1.55%→1.35%になりましたが、今回は概算なので1.35%一律で計算してみます。労働者負担が0.5%、会社負担が0.85%と決められているので、労働者の負担額は給与の0.5%となります。少ないように見えますが一年分をまとめるとそれなりの額になります。


Aさんの場合:
給与収入 = 6,000,000円
雇用保険料率 = 0.5%
年間の雇用保険料 = 給与収入 × 雇用保険料率 = 6,000,000円 × 0.5% = 30,000円

生命保険料控除

今年から税制が変わりましたが、平成23年末より前に契約した保険の場合は、旧制度のまま変更無しです。
ここでは旧制度の計算式で行こうと思います。

年間の支払保険料等 控除額
〜25,000円 支払保険料等の全額
25,000円〜50,000円 支払保険料等×1/2 + 12,500円
50,000円〜100,000円 支払保険料等×1/4 + 25,000円
100,000円〜 一律50,000円


Aさんの場合:
月額保険料 = 6,000円
年間の保険料 = 6,000円 × 12ヶ月 = 72,000円
生命保険料控除額 = 72,000円 × 1/4 + 25,000円 = 43,000円

扶養控除

これはよく聞く控除項目だと思います。
生計を共にしている家族の中で収入が103万以下の人がいれば、一人につき38万円の控除が受けられます。
パートに出ている主婦が103万円以下に抑えようとするのは、これが理由ですね。


Aさんの場合:
専業主婦の妻:380,000円

医療費控除

医者にかかった際の費用や、入院費用、通院時の交通費、薬代などを合計して10万円を超えている場合、超えた部分が控除額となります。といっても、健康保険によって三割負担ですむため、大病しない限りはなかなか到達しません。
なお、年末調整の時点ではその年の医療費は確定していないため、翌年三月に確定申告を行うことになります。

基礎控除

みんな共通で38万円です。


Aさんの場合:
共通:380,000円

所得税の計算

他にも控除は存在しますが、サラリーマンに影響の大きい所はだいぶ出そろったので今回はこれぐらいにしておきましょう。さて、Aさんの所得税を計算してみたいと思います。

所得税 =(収入 − 控除) × 税率

まずは収入から控除を引いて「課税対象額」を求めるところまで。


Aさんの場合:
収入:
給与収入 = 6,000,000円

控除:
給与所得控除 = 1,740,000円
健康保険料控除 = 299,100円
介護保険料控除 = 46,500円
厚生年金保険料控除 = 502,980円
雇用保険料控除 = 30,000円
生命保険料控除 = 43,000円
扶養控除 = 380,000円
基礎控除 = 380,000円

                                        • -

控除合計 = 3,421,580円

課税対象額 = 6,000,000円 − 3,421,580円 = 2,578,420円

所得税

所得税累進課税制度になっているため、所得に応じて5%〜40%まで税率が上がる仕組みになっています。

課税対象額 所得税
〜195万円 5%
195万円〜330万円 10% − 97,500円
330万円〜695万円 20% − 427,500円
695万円〜900万円 23% − 636,000円
900万円〜1,800万円 33% − 1,536,000円
1,800万円〜 40% − 2,796,000円

195万円を超えた途端に2倍の税率になるように見えますが、実際には195万を超えた部分だけが10%の税率となるようになっています。


Aさんの場合:
課税対象額 = 2,578,420円
所得税 = 2,578,420円 × 10% − 97,500円 = 160,342円

というわけで、Aさんの所得税は160,342円となりました。100円未満は切り捨てられるので160,300円ですね。
所得税額が分かったので、年末調整で還付される金額も求められます。
還付額 = 源泉徴収で今まで払ってきた所得税額 − 所得税

今回の記事では健康保険料、厚生年金保険料などを概算で求めているため、多少の誤差がありますが、毎月の給与明細を元にじっくり計算すれば返ってくる金額を1円単位で当てることもできるようになります。

おまけ:復興税は幾ら?

平成25年から復興税が導入されます。いくつかの分野に分かれて増税されますが、個人の場合は所得税、住民税が主になるかと思います。

復興税(所得税部分)

所得税への増額分は以下のようになります。

復興特別所得税所得税 × 2.1%


Aさんの場合(平成25年も平成24年と同じ収入とします):
所得税 = 160,300円
復興特別所得税 = 160,300円 × 2.1% = 3366円

復興税(住民税部分)

収入に関係なく年1000円

合計すると、年収400万で年間3000円程度、年収600万で年間4500円程度の負担増となるようです。

復興税は期間が長く所得税は25年、住民税は10年に渡って負担が発生しますが、一年当たりの金額で見るとそう大きくは無いようです。

*1:12月の給与をもらった後に収入があったり、控除が発生したりすることもあるので、差が出た人は翌年3月に確定申告を行います

*2:平成25年からは上限が245万に制限