Webアプリを創る

AdSense と個人事業税

2016年8月17日

自分の所にも個人事業税の納税通知書が届きました。自分の場合は Webサイト等を運営して収入は Google AdSense から得ていますが、その場合は個人事業税は非課税と思うので、ネットで少し調べて県税事務所に行ってきました。

ネットを調べていると、税理士の方がブログで次のように書いています。こういうことを書かかれると職務熱心な公務員諸氏としては課税せざるを得なくなりますよね。

そこでアフィリエイトなのですが、都道府県によって課税されている地域と課税されていない地域があるようです。

中略

以前、課税で統一している東京都に問い合わせたところ、「具体的な業務内容を確認して」と前置きした上で、「電気通信事業、仲立業、広告業、請負業などに該当するものとして課税を行っています。」という回答でした。

難しいところではありますが、同じことをしているのに、○○県から東京都に引っ越すと課税されて、東京都から△△県に引っ越すと課税されなくなるというのは、やはり問題じゃないかと思います。

全国の都道府県で統一した見解を出して、同様の処理をしてほしいものです。

そのブログの税理士は、同じアフェリエイトをしているから、同じ業種になると思っているのだろうけど、東京都の担当者がいうように業務内容によって違う業種になるので、統一した見解は出しようがないというのが事実だと思います。同様の処理をしてほしいというのは最もらしい意見のように見えるけど実際は暴論です。

業務内容によって判断する必要があるので、グレーゾーンがかなりあるというのが現実なので、都道府県によって差がで出てくるのもやむを得ないところです。税理士として差が大きすぎると思うのだったら当局の見解を聞くだけではなく課税される側に立って当局と真剣に交渉して実例を作っていくべきで、そうやって都道府県間の差を少なくしていくべきものです。

東京に住んでいる人で課税されたときに、「電気通信事業、仲立業、広告業、請負業等」だと言われることに納得できないのであれば、都税事務所に交渉にいった方がいいと思うし、税理士はそれを助けるのが仕事です。

自分の場合まだ結論は出ていませんが、個人事業税は、下の業種に該当した場合のみ課税になります。

ソフトウェア関係は該当業種には全く含まれていません。個人事業税は道路等の公共サービスの経費の一部負担という性格を持っているようで、ソフトウェア関係は公共サービスを全く使わないので非課税というのは自然なことだと思います。

ソフトウェア関係は非課税なのに、当局が勝手に自分の業種を「電気通信事業、仲立業、広告業、請負業等」の該当業種に決めてしまうというのは納得できないです。

第1種事業(37業種) 物品販売業、運送取扱業、料理店業、遊覧所業、保険業、船舶ていけい場業、飲食店業、商品取引業、金銭貸付業、倉庫業、周旋業、不動産売買業、物品貸付業、駐車場業、代理業、広告業、不動産貸付業 請負業、仲立業、興信所業、製造業、印刷業、問屋業、案内業、電気供給業、出版業、両替業、冠婚葬祭業、土石採取業、写真業、公衆浴場業(むし風呂等)、電気通信事業、席貸業、演劇興行業、運送業、旅館業、遊技場業
第2種事業(3業種) 畜産業、水産業、薪炭製造業
第3種事業(30業種)医業、公証人業、設計監督者業、公衆浴場業(銭湯)、歯科医業、弁理士業、不動産鑑定業、歯科衛生士業、薬剤師業、税理士業、デザイン業、歯科技工士業、獣医業、公認会計士業、諸芸師匠業、測量士業、弁護士業、計理士業、理容業、土地家屋調査士業、司法書士業、社会保険労務士業、美容業、海事代理士業、行政書士業、コンサルタント業、クリーニング業、印刷製版業、あんま・マッサージ又は指圧・はり・きゅう・柔道整復、装蹄師業、その他の医業に類する事業
なお、デザイン業は対価を得てデザインする場合のみが対象です。

アメリカではプロジェクトマネージャーの割合が37.8%?

2016年7月22日

経産省の「IT人材の最新動向と将来推計に関する調査結果」の 「IT人材に関する各国比較調査報告書(PDF形式)」の20ページを見て笑ってしまいました。

「IT企業の回答者の職種」で、日本は「SE・プログラマ」が36.6%で一番多く、アメリカでは「プロジェクトマネージャ」が37.8%と一番多くなっています。いくら何でも、プロジェクトマネージャーがそんなに多くいる訳はないですよね。

それで、アメリカの労働省が後援している「O*NET」で調べてみました。

IT 関係の職種は、「コンピュータと数学」に分類されています。職種別に平均年収と従業者数を拾ってみました。

職種平均年収
(ドル)
従業者数
(人)
15-1111.00 コンピューター及び情報科学者
Computer and Information Research Scientists
110,620 26,000
15-1121.00 システムアナリスト
Computer Systems Analysts
85,800 191,600
15-1121.01 運用スペシャリスト
Informatics Nurse Specialists
85,800 568,000
15-1122.00 情報セキュリティアナリスト
Information Security Analysts
90,120 83.000
15-1131.00 プログラマー
Computer Programmers
79,530 329,000
15-1132.00 ソフトウェア開発者(アプリケーション)
Software Developers, Applications
98,260 718,000
15-1133.00 ソフトウェア開発者(システムソフト)
Software Developers, Systems Software
105,570 396,000
15-1134.00 Web開発者
Web Developers
64,970 149,000
15-1141.00 データベース管理者
Database Administrators
81,710 120,000
15-1142.00 ネットワーク及びコンピュータシステム管理者
Network and Computer Systems Administrators
77,810 383,000
15-1143.00 コンピュータネットワークアーキテクト
Computer Network Architects
100,240 146,000
15-1143.01 通信技術スペシャリスト
Telecommunications Engineering Specialists
100,240 146,000
15-1151.00 ユーザーサポートスペシャリスト
Computer User Support Specialists
48,620 586,000
15-1152.00 ネットワークサポートスペシャリスト
Computer Network Support Specialists
62,250 181,000
15-1199.00 その他のコンピュータ関係職
Computer Occupations, All Other
85,240 233,000
11-3021.00 コンピューター及び情報システム経営者
Computer and Information Systems Managers
131,600 349,000

これを見るとソフトウェア開発者とWeb開発者が「プロジェクトマネージャ」に入っているようです。ソフトウェア開発者の給料は高いですが開発メインでマネージャ職ではないから、プロジェクトマネージャーに分類するのはあっていないと思いますが、どういう発想からそうしたのか考えると面白いかもしれません。

これに関連して、最近話題になっているちょまどさんの「あるSIerに、システムエンジニアとして新卒入社。Excel(表計算機能を使わない)を使うお仕事が続く」という話が思い浮かびました。

報告書の14ページには「ITスキル標準レベル」の比較表があるのですが、やはり最低レベルです。エンジニアにプログラムをさせないでスクショをさせていたのでは技術レベルはあがらないのは無理ないです。

ちょまどさんは、3ヶ月でその SIer を退職して、今ではマイクロソフトのエバンジェリストになっているのでさすがです。でも、ちょまどさんのケースは例外ではないようで、O'Reilly の「ソフトウェア開発者の収入調査」では、日本のソフトウェア開発者の年収は高いという結果が出ています。

日本のIT業界は労働環境が劣悪なので若い人がIT業界離れをしているようですが、能力があればちょまどさんのように好待遇の仕事に就くことは難しいことではありません。そのためには、待っていたのではダメで、自分のキャリアは自分でマネジメントするという姿勢が大切になってくると思います。

統計メモ帳のアクセス数が月10万PVを超えました

2016年3月1日

統計メモ帳の2016年2月のPV数がやっと10万PVを超えました。まだまだアクセス数は少ないですが、10万PVを超えたというのは一つの区切りだと思うし、Webサイトのひよこの仲間入りはできたように思います。それで、このサイトは作りかけの部分が結構あるので手間暇をかけて改善していこうと思っています。 アナリティクス

Webサイトの場合は、有名人や資金力のある企業でなければ一気にアクセス数を稼ぐのは難しいと思います。個人でWebサイトを運営しようと思う場合は、粘り強くサイトを改善していくのがいいように思います。

このサイトは、表やグラフが多いので、スマートフォン対応をどうしようかと思っていたのですが、先日、MicrosoftがXamarinを買収したというニュースが流れました。それだったら、スマートフォン対応に Xamarin.Forms を使ってみるのも一つの手だと思いつきました。これから Xamarin.Forms でどれぐらいのことができるかテストしてみようと思っています。

サイトを ASP.NET Core + .NET Core で作り直しました

2016年2月23日

この Webサイトは、Umbracoで作っていましたが、ASP.NET Core(ASP.NET 5)+ .NET Core で作成し直してみました。Umbracoも拡張性が高くて悪くはないのですが、自分でプログラムを書きたい場合には自由度が小さくなるのとデバックの時には重くなるのが欠点でした。それで思い切って、作り直すことにしました。選択肢としては、ASP.NET MVC 5、ASP.NET Core + .NET Framework 4.6、ASP.NET Core + .NET Core の三つでしたが、思い切って NET Core + .NET Core にしてみました。

ASP.NET 5 については、スケジュールが変更され、名称も ASP.NET Core に変更になるということで、RC2 が出る直前になってドタバタしているようですが、実際使っていると問題点があることはわかります。でも、基本的なところはそれほど変わっていないし安定しているので使えないことはないです。

運用を始めたばかりで、切り替えの時に少し失敗してサーバーを止めてしまったこともありましたが、取りあえずは普通に動いています。Ubuntuサーバーの方でもテストしていますが、そちらも大きな問題はなく動作しています。

ASP.NET Core、.NET Core については、最近マイクロソフトから以下のブログが出て、方向性がよくわかるようになったと思います。

ASP.NET 5 is dead - Introducing ASP.NET Core 1.0 and .NET Core 1.0

An Update on ASP.NET Core and .NET Core

Porting to .NET Core

ASP.NET Community Standup – February 16, 2016

Porting MSBuild to .NET Core

コンパイラーが DNX から CLI に変更になるというのは賛成です。このサイトの発行時のファイルサイズは、約300MBぐらいで、その内runtimesが106MB、packagesが190MBです。runtimesの分は、ホストのOSにインストールされたランタイムを使う必要がなくなった代わりに必要になるもので、どんな小さなアプリにでも必要になります。packagesの分が大きくなっているのは、.NET Core だけでなく下の図のように Windows Phone 8 や Xamarin のものまで含まれているためです。Webサーバに関していえば、これぐらいのファイルサイズでも我慢できなくはないのですが、コンソールアプリケーションで 100MBというのはちょっと大きすぎだと思います。AOT(事前コンパイラ)をしてファイルサイズも減らして欲しいし、最初の起動時間も短縮して欲しいと思うし、コンソールアプリケーションだと、ネイティブコードにコンパイルして欲しいところです。 packages

.NET Core を使う上での支障は、ライブラリーの対応があまり進んでいないことです。「Porting to .NET Core」に書いてあるように、.NET Core でも System.Data、System.DirectoryServices、System.Drawing、System.Transactions、System.Xml.Xsl、System.Xml.Schema、System.Net.Mail、System.IO.Ports、System.Workflow、System.Xaml で、時間がなくて移行があまりできていないそうです。 そういう状況なので、サードパーティ製のライブラリーの対応状況は悪いです。

現状では、ASP.NET だと、ASP.NET Core + .NET Framework 4.6 という選択肢が現実的だし、UWP の方も windows 10 mobile が殆ど普及していないことや、デスクトップPCでも依然として主力は Windows 7 であることを考えれば、.NET Core を急ぐ必要はないと思います。

しかし、5年後を考えると .NET Core が必要というのは間違いないと思います。また、下の図は、Azure の VM の Linux と Windows の価格です。個人だとこれだけ価格に差が出てくると Linux の方を使いたいと思ってしまいます。それで、これからは、 Linux のことも書いていきたいと思っています。 azure

Web をするなら PHP だけでなく JavaScript を使ってみよう

2016年2月5日

JavaScript は、Webデザイナーのための簡易言語だと言われたり、まつもとゆきひろ氏には「人類のためにJavaScriptは何とかしたほうがいい(出典:エンジニアライフ)」と言われたりしたプログラム言語ですが、ECMAScript 2015 が承認されたことでモダンな言語に変身しつつあります。

2ヶ月ほど前の話ですが、PHP Advent Calendar 2015 の「PHPを使いもせずDISってる君達へ」という記事をみて、JavaScript は、PHP より遙かにモダンな言語になると思ったのでメモしておきます。

その記事では例を、Ruby で書いてありますが、JavaScript の場合はどうなるかというと、ECMAScript 5.1(ES5)では以下のように記述できます。IE8 は対応していませんが、それ以外の普通に使っているブラウザーは対応しています。

var a = [2,4,6,8,10]
    .filter(function(num){return num <= 8})
    .map(function(num){return num * num})
    .filter(function(num){return num >= 20})  
    .reduce(function(previous, current, index, array){return previous * current});  

また、ECMAScript 2015(ES6)では、アロー関数式が使えるので、Ruby と同様に以下のように簡潔に記述できます。

var a = [2,4,6,8,10]
    .filter((num) => num <= 8)    
    .map((num) => num * num)    
    .filter((num) => num >= 20)    
    .reduce((previous, current) => previous * current);      

やはり、PHP の配列処理はやはり不便です。PHP も配列などのコレクションの処理をするときには、高階関数を使って処理できるようになってほしいと思います。

JavaScript の ECMAScript 2015 への対応状況ですが、ECMAScript Compatibility Tableというサイトで調べると、Edge13 83%、Firefox45 85%、Chrome49 91%、Safari9 54% という状況で対応が進んできていますす。

ECMAScript Compatibility Table

ブラウザーではIE11が全く対応していないので、直接使うことは厳しい状況ですが、TypeScript を使えば、ソースコードとして使えるし、Node.jsだと、近いうちに直接書くことができるようになると思います。

JavaScript は Node.js を使えばサーバー側でも動くし、PHP では動かないブラウザー上でも動作します。これからは、Webをしたいのであれば、PHP だけでなく JavaScript を使った方がいいと思っています。

参考までに、C#の場合は、LINQを使って以下のように書けます。C#は、以前は Ruby の方が効率的にプログラムが書けると思っていましたが、C# 3.0 で LINQが使えるようになり、C# 5.0では async/await で非同期処理ができるようになって Ruby に追いついたと思います。配列処理のことについては、C# やるなら LINQ を使おうに詳しい解説があるので、ここでは説明を省略します。

var a = new int[] { 2, 4, 6, 8, 10 }
    .Where((num) => num <= 8)    
    .Select((num) => num * num)    
    .Where((num) => num >= 20)    
    .Aggregate((previous, current) => previous * current);