どのような時に恒久的施設(PE)があると認定されるか その昔の話ですが、PEが日本にあるのではないかと税務当局より指摘があったことがありました。 私のそのお客様は日本とヨーロッパの両方に会社(それぞれJ社とE社)を持っていて、日本で機械を仕入れて、ヨーロッパのお客様に販売していました。私は当時知らなかったのですが、お客様は日本の会社の社長であるばかりでなく、ヨーロッパの会社の社長も兼ねていました。 ビジネスの仕組みはいたって簡単で、日本で購入した特殊な機械を、ヨーロッパで販売すると言うものでした。まずJ社がE社に商品を販売し、E社はそれなりのマージンを抜いて、E社のお客様に売ると言う仕組みです。 緑の線が形式上の取引の流れで、赤線が実際の物の流れです。 ここに税務調査が入りました。そこで問題になったのが、E社が何者かと言うことでした。J社とE社は名前が似ていたので、関係があるらしいことは伺い知れました。税務調査では、この会社がどんな会社であるのかが調べられました。どこに所在するのか、社員は何人くらい居るか、資本規模はどれくらいか、売り上げはどれくらいで、つまり実体はあるのか。また、E社ではどれくらいのマージンが形状されて、その先のヨーロッパのお客様に売られているのかが調べられました。 その過程で、E社は社長が保有して居る会社で、他にあまり(もしくはほどんど)ビジネスはしていないこと、従業員はいないこと、J社の社長はE社の社長でもあること、本社はとある会計事務所に登録されて居ることがわかりました。 一連の取引は仮装ではないかとの主張も当局からされましたが、E社が金融機関からJ社のための資金調達をして居ることや、J社のウェブサイトを運用して居ることから、ファナンスとマーケティングの機能は少なくともやって居るとの納税者側からの主張はなんとか認めていただく事ができました。 ただ、J社の社長がE社の恒久的施設(PE)になるのではないかとの指摘があり、これは受け入れざるを得ませんでした。 PEは、租税条約によって異なるので、外国会社の日本の拠点がPEに該当するかは、相手国によって異なる可能性があります。ただ大枠は国際的にコンセンサスが取れていて、情報収集を目的とする駐在事務所や、外国にある本社のために仕入れをするための商品倉庫などは該当しないことになっています。他方、登記の有無関わらず支店はもちろん、自社の製品やサービスを契約できる代理人もほとんどの租税条約でPEに該当することになっています。 国税局などの実際の税務調査での確認事項を見ると、実務上では、契約を締結できる権限があるかどうかの判定として、見積もりは誰が作成して居るか、契約の受注は誰が受けて居るかが重要視されて居るように思います。つまり、本社が日本に人(本社の社員ではなく、業務委託料をもらって居る場合で)が置くのは、最終的には本社の製品を日本人のお客様に売るためですが、その人が実際に見積もりを本国に依頼して作ってもらって、日本のお客様に渡して居るのか、それとも実はその人が作ってしまって居るのか、メールなどの証拠の提出を求められる事がほとんどです。 メールなどで、日本の担当者が見積もりや契約を締結していて、本社にはその報告して居るだけのようなメールが出てきてしまうと、PE認定一直線になってしまうので注意が必要です。 その他に、外国会社がインターネットを通して日本に物品を販売する場合に、日本にインターネット・サービス・プロバイダーのサーバーにホストされてイるウェブサイトを通じて、物品を販売しても、日本にPEがあるとは通常認定されません。日本で自前で場所を借りてサーバーを設置して居るような場合は、恒久的サービスがあることになります。 PEと認定された場合にどのように所得を計算するか この話は、本社のPEが日本にあるかどうかの話なので、PEの所得をどのように計算するかと言う話とは別なので注意が必要です。 PEで課税される所得は通常、そのPEに帰属する帰属主義に基づいて計算されます。つまり、外国の本社が直接にやって居る取引は、日本のPEに帰属しないので、日本での所得ではありますが、PEに納税義務は発生しないと言う事です。さっきの例でいうと、日本のPEとは別に本社が直接にインターネットサイトかなんかで販売している商品の利益はPEに帰属しないので、日本で法人税の納付は必要がないことになります。 ただし消費税については、PEの有無に関係なく納税義務が発生するので注意が必要です。
Month: May 2017
Herokuを使ってサービスを作ると、どうしてもストーレッジの問題にぶつかります。Herokuはいいと思うのですが、ストーレッジがないのです。実は知られているようで、結構な数の人が知らなかった落とし穴でもあるようなのですが、Herokuでは画像が保存できません。OSとPythonやRubyなどの言語とデータベースは提供してくれるのですが、画像は保存できないのです。私はこれを知らなかったので、かなりびっくりしてしまいました。。 そこで仕方がなくAWSを始めることにしたのですが、このAWSのs3というサービスがかなり良いので、かえってよかったと思っているところです。 ご存知の方も多いと思いますが、HerokuはPaaSと呼ばれるWebサービスの一種で、ハードディスクのサーバーと、UbuntuなどのOS、それにデータベースやPythonなdの言語、各種のライブラリをまとめて提供してくれます。 私は開発環境がMacなので、自分のところのサーバーもMacでやれば、本番と開発環境が一緒なのでやりやすいのではないかと、色々迷っていました。パーミッションなどの扱いやすさは、手元で実際にいじれる実機のサーバーの方がわかりやすいですし、コストも実際にサーバー機を買ってしまってもそれほどのものではありません。ですが、Herokuなどのクラウドを使うと、12factor.netなどに書いてある設計上のデザインパターンに自動的に従うことになると言うのに惹かれてHerokuでやってみることにしました。やはりサービスが段々大きくなっていった時にメンテナンスが楽な方がいいですものね。それとやっぱり自己流でやるよりは、信頼性と実績の面からもで世の中で通用しているものでやってみる方が良いのかなと思いました。 s3の良いところは、まず、値段です。1GBあたりの料金は一月で約3円。データが100GBでも月300円です。私の事務所では領収書の画像データを仕訳データに翻訳して、画像と仕訳を一緒に整理して保存するサービスを提供しようと思っていますが、iPhoneで撮影した写真だとデータのサイズは約3MBです。ですので300枚保存してこれでやっと1GBで、これで、3円です。100GB使おうと思ったら、30,000枚の写真データを保存することが出来ますが、これで小さい会社なら20社分は行けるのではないでしょうか? 次に、信頼性。これは、Amazonの説明によると99.999999999%の信頼性があるのだそうです。 小数点以下に、9が9個つくので、データが消失する可能性は、1000万分の1と言うことでしょうか。自分のところでサーバーを持ってデータを保存するより、よほど高い信頼性です。使わない手はないですね。 その他、Pythonのboto3をはじめ、RubyやJava、.NETなどの他、おそらく、ほとんどの言語でファイルや閲覧権限等を簡単に操作できるモジュールが用意されています。プログラムの側から簡単にファイルをアップしたりダウンロードできたりするのです。ここだけ見ても、自分でファイルの保存や権限の設定をプログラム的に作るよりよほど簡単で確実です。ソフトウェアの世界に限りませんが、「巨人の肩に乗る」と言う言葉があります。 こう言う新しいもの(全然新しくないけど)はお金を出してもどんどんやってみる方がいいですね。
PyCharmは買う価値があるでしょうか。 使って1ヶ月くらいが経ちますが、私は買ってよかったです。多分、この1ヶ月でも十分に元は取れています。その前は、3−4ヶ月はAtomを使っていたのでよくわかります。やっぱり効率性が劇的に上昇しています。もう、PythonをやるのにAtomには戻れません。どうせプログラミングをするなら、良いツールを使うほうがいいです。効率性が素晴らしい。 Atomとは色々違うのですが、まず、デバッグが出来るようになるのが大きいです。Atomで作った場合は、Atomはエディタですから、直接実行することは出来ません。ターミナルから実行して、エラーが出たら、エラーのログをみて何が悪かったかを解析しなくてはいけません。 PyCharmならブレークポイントを設定できます。エラーが出る場所で、ブレークポイントで実行を停止して、各変数にどのような値が入っているかを確認できます。私が知っている範囲では、Atomのプラグインでは逆立ちしてもそんなことは出来ません。 PythonやRubyなどのスクリプト言語は静的型付け言語に比べて、文法チェックが事前にないところが弱点だと思っているのですが、PyCharmはインスタンスが割り当てられていない変数などに赤の波線を引いてくれます。これで実行する前にある程度のバグの元は潰してくれるんですね。 名前をまとめて変えてくれるリファクタリングの機能もあります。個人的に気に入っているのは、ある変数にマウスのポインタをあてると、同じスペルの変数が全部ハイライトされます。これが、コードの流れを追う時にとても楽になるので助かります。 この他にもテストなど、まだわかっていない機能が色々ある様です。 確かに、最初は有料のツールは躊躇すると思います。なので、最初の数ヶ月をAtomでやって、PythonやらDjangoなどのフレームワークをやっぱり自分ががちゃんと使うと言うことがわかってから買うのでも遅くはないと思います。それに、Atomなどのエディタで開発すると、その手作り感で、どの様に動くのかわかリます。それからPyCharmなどのIDEに移行するのでも遅くはないと思います。 ちなみに私は、もう、Atomに戻ることはなさそうです。
Herokuを使ってWebサービスを作るのは手軽にできると宣伝されていますが、実はかなり高度な知識が必要です。Herokuのアカウント自体は簡単に開けられるかもしれないけど、実際にサービスを公開するには、Linuxやデータベース、RubyやPythoなどの言語で一通りのコードがかけること、HTMLやCSS,JavaScripなど、広範囲の知識が必要です。これをさらに、iPhoneやAndroidなどの端末で使えるようにしようとすると、SwiftやAndroidなどの端末側のプログラミング言語の知識も必要になります。 さらに、Herokuの場合は、解説がほとんど英語なので、英語が結構得意でないと、解説を読むこと自体が億劫になってしまいます。もしくは、それを上回る熱意とか根性が必要でしょう。 最近、Herokuでは画像ファイルが保存できないことを発見したと書きましたが、Herokuでやることで、ソフトウェアが他の環境にデプロイしやすくなるなど、設計上のメリットがあることがわかったので、最近の定番っぽいAWSのS3(Amazon Web Serviceの中のストーレッジの機能)ではどうやるのかを調べてみました。 ジャジャーン。 A file is selected for upload by the user in their web browser; JavaScript is then responsible for making a request to your web application on Heroku, which produces a temporary signature with which to sign the upload request; The temporary signed request is returned to the browser in … Read More “HerokuとAWSのS3を使ってWebサービスを作るには” »
Djangoでアプリを作りましたが、これを公開するのにローカルのマシンを使うか、クラウドを使うかで迷いました。 そこで、どちらが良いのかメリットとデメリットをそれぞれあげて、有利不利を検討してみようと思います。 まず、コスト ローカルでやる場合には、開発と同じ環境の方が楽です。私はmacのノートで開発しているので、Mac Miniサーバーを考えています。ツールを入れる手順などが、開発環境と全部一緒にできるので、かなり楽だと思うのです。値段も、一番安いもので5万円くらい、CPUがいいものでも7万円ちょっとです。他のことにも使えますから、それほど高い買い物とは言えないと思います。 次に、クラウドです。今回のアプリは領収書の画像を保存するのでデータの保存量がだんだん大きくなっていきます。一枚の領収書のデータサイズを1MBとして、1000枚で1Gです。1年に1,000枚として、お客様1件で1GBという計算になります。 簡単な計算ですが、100件のお客様に使用していただくとすると、100ギガですが、アマゾンのS3の料金表を見ると最初の 最初の50TBまでは、1GBあたり月$0.025ドルだそうです。つまり、1件につき月3円、100件で300円、年間でも3,600円です。べらぼうに安いですね。 ソフトウェアの設計の良さ 次にソフトウェア自体の作り方ですが、クラウドを使うことによる大きなメリットがあります。このメリットはある文章を読むまで私も意識していませんでした。 Herokuでサービスを公開する場合、色々面倒くさい設定が必要になります。例えば、まず本番環境に展開する場合には、Githubを通してpushする必要があります。また、依存関係のあるモジュールをあらかじめリストアップして置く必要があります。また、Hrokuでは画像ファイルを保存することができないので、AmazonのS3などの外部ストーレッジを利用する必要があります。 かなり面倒くさいのですが、Herokuで展開する過程で、Herokuの提唱するソフトウェアを効率的に開発するための12の提言に自動的に準拠することになります。この12提言は12factors.netとサイトで公開されています。この12提言がいいのです。 例えばですが、以下の通りです。 1.) セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 2.) 下層のOSへの 依存関係を明確化し、実行環境間での 移植性を最大化する。 3.) モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 4.) 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイを可能にする。 5.) ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップできる。 この観点からはクラウドでやる方が圧倒的によさそうです。 簡単さ 短期的にはローカルの方が簡単かもしれません。ディレクトリ構造は自由に変更できるし、DBなどのインストールも自由です。開発と本番環境も、例えばサーバーでmac miniを使えば同じになります。使い慣れている環境の方が、学習コストも少ないのでツールなどは使いこなしやすいです。 上記の比較からは、クラウドの方がよほど有利に見えます。私は、新しいサービスは、とりあえずローカルではなく、クラウドで始めてみようと思いました。
ヤマト運輸の中興の祖である小倉昌男の「経営学」という本を本棚から取り出して、久しぶりにパラパラとめくってみました。その中で、小倉昌男が牛丼の吉野家の経営で、商品を牛丼一本に絞り込んだ話に感銘を受けたことが書いてありました。 商品を一本に絞り込むことで、仕入れ単価も下がるしバイトでも簡単にメニューが作れるようになり、吉野家は利益が出る体質になったというのです。 そこで、ヤマトもそれまでの企業向けの大口の物流から一般消費者向けなどの小口の宅配に大きく舵を切り事業を。そして、事業が大きく成長したと言います。 ですが、世の中みんなが知っている通り、実際には、今日の吉野家もヤマトも事業を一本に絞っていないように見えます。吉野家には牛丼だけではなく、牛鍋定食も豚丼もあリます。一体、事業を一つに絞るのがいいのでしょうか、それとも、関連する範囲で、または、関連しなくても、利益が出るのであれば色々やる方がいいのでしょうか? 私の思うこの問いに対する解答は、一人なら1種類に絞るべき。複数人でやっていて、既存のお客さんからのニーズで自分の本業以外の問い合わせがあった時に、誰かにお願いできるなら、それを受けてもいいということでしょうか。 やはり、一般論としては、事業規模が少人数の場合、特に自分一人とアシスタントと二人のような場合には色々と手を出すべきではないということでしょう。自分や自分の会社があえてやらなくても、世の中には自分たちよりその事をうんと上手に出来る人達がいます。他の誰かがより上手く出来ることは、その他人の会社に任せてしまって良いのです。世の中は広いので、自分が得意でないことは、あえて自分がやる必要性は世の中の道理としてもありません。 例えば、私どもの事務所でビザの事をよく聞かれるので、自分たちでやってもいいのではないかとも思ってしまったりもします。でも、待てよ。よく考えると、ビザのことは自分たちより上手に出来るところは沢山あります。そこが儲かってて、それをみて参入するならともかく、そうでないなら、経験が足りなくて、効率も知識も足りない自分たちがやる必要はないのではないか、と思うに至りました。
PythonでWebサービスを作るために色々な事に遭遇したり、調べたりしたので、それをシェアするためのポストです。色々とやってみないとわからない事があり、知ってれば無駄な時間を大量に使う必要のなかった落とし穴があるので、それをシェアしようという趣旨です。 貴重な時間を浪費するのを避けるためにも、次にやる人のかたの参考になれば幸いです。 どの言語を使うか まず言語選びです。ウェブサービスを作る場合には、言語を選ぶ必要があります。可能性としては、C#、Java、Ruby、PHP、Pythonなどがあると思います。最近はサーバーサイドのJavaScriptやLinuxで走るSwiftなどもあります。色々ありますし、どれを使っても一緒と思いそうですが、ライセンスや言語の性質でその後に大きく影響するので、実はとても重要です。 まず、C#はLINQもあり非常に使いやすいのですが、WEBサービスとして公開する際にはライセンスの問題が発生するので注意が必要です。最初からユーザーにライセンスのコストを転嫁できる立場の強いWEBサービスなら別ですが、最初は無料でユーザー数の獲得に力点を置いているような場合には(特に最初は)コスト割れになると思われるので、使わない方が無難です。ちなみに私は簡単便利なLINQは大好きです。社内システムなどで使うようでしたら問題なさそうです。 Javaは開発が重たすぎるので、やめた方がいいという意見も多いです。また、世の中で活躍している有名なWEBサービスはスクリプト言語またはライトウェイト言語と呼ばれているRubyやPHPを使っているところが多いようです。Moneyforwardとかfreeeとか。実際に調べてみると、良いフレームワークやデータベースとの接続を楽にするOR Mappingは随分改良されているようで、Javaも選択肢の一つなのではないかと思いました。 C#やJavaなどは静的型付け言語と呼ばれていますが、静的型付け言語の良いところは、コンパイルする時に型に関するエラーを見つけてくれるので、バグが入りにくいというのがあると思います。実際にiPhoneなどの開発に使われる言語はSwiftですが、これは静的型付け言語です。AppleがSwiftを静的型付け言語にしたのは(統計的にバグが少なくなるなどの)理由があるはずです。 ライトウェイト言語(LL)では、RubyやPython、PHPなどがあります。私は一応全部試してみて、今回はPythonで行こうと決めました。Rubyは日本では大手のWebサービスにも使われておりメジャーなのですが、Googleの検索件数などから逆算した割合だと、世界ではPythonの方が圧倒的に使われています。私の調べた範囲なだけですが、使っているプログラマーの数が多いからかライブラリーの数も豊富です。画像を使ったWebサービスでは必ず必要なPILLOWや、CSVの読み込みや書き出しの処理をするcsv、エクセルやPDFの処理など多数のライブラリーが存在します。きっとRubyやPHPにもあるのでしょうが、海外でのシェアはPythonの方が圧倒的です。 PHPも多くのサイトで使われているし候補ではあったのですが、他の言語では関数やプロパティをA.Bというふうに書きますが、PHPではA->Bという風に書きます。2文字で打ちづらいキーで書かなくてはいけないのと、見た目が何となく好きになれなかったのでやめました。ちょっと本質的な理由ではないですね。 動的型付け言語はバグが多くなり、メンテが大変か? 静的型付け言語の方がバグが発生しにくいと思われるので、システムが大きくなる予定だったら、メンテナンスのことを考えてJavaを使った方が結局効率がいいのではとは思いました。RubyやPythonなどの動的型付け言語は最初は楽ですが、あとでバグ取り地獄に入ってしまうのだったら、開発の後半でシステムが大きくなっていくほど長い時間がかかりそうに思えました。最初が急坂でだんだん傾斜が緩くなっていくか、最初がゆるいけど、あとで段々きつくなっていくかのどちらにするかのイメージです。 ただ、現状を見回すと急成長しているWebサービスは動的型付け言語でやっているっぽいです。私の見えていない何かがあるのかもしれないと思い、とりあえずその流れに合わせてみることにしました。 エディタ、IDE、開発ツール 最初はATOMを使っていたのですが、開発が本格的になってからPycharmに変えました。 ATOMは無料ですし、入力補助のモジュールもあるのでテキストエディタとしては大変優秀です。ですが、変数のスペルミスなどは事前に見つけてくれないので、実際に走らせてみるまでわかりません。 ATOMに限りませんが、テキストエディタで開発すると、なんでもテキストエディタとターミナルからコマンドを使ってやらなくてはいけないので、プログラムが走るまでの環境をどうやって作るかとか、ツールのインストールの仕方とかとてもよくわかるようになります。私も、ATOMで開発を始めたおかげで、Linux(やMaxOS)がどうなっているかだいぶ勉強になりました。 最初は無料でいいのですが、本格的にやることがわかったら無料でも有料でもIDEを使った方がいいと思います。私の場合はPycharmを個人ライセンスで買ったので89ドルでしたが、スペルチェックのミスを見つけるのやリファクタリングはエディタではできないので、それだけでも十分に元が取れます。 まだ試していない機能がたくさんあるのですが、デバッグでブレークポイントも設定できるようですし、IDEにお金を出す価値は十分すぎるほどあります。 フレームワーク フレームワークはPythonでは一番機能が充実していると言われるDjangoにしました。PythonではそのほかにもFlaskやPyramidなど色々なフレームワークがあるようですが、Djangoが一番機能が充実しているようです。実際、ORMや画面遷移など、とても便利です。 ORMは何を使ったらよいか。 ただ、DjangoのデフォルトのORMは書き方も直感的で便利ではあるのですが、データベースを動的に複数作りたい場合に、構造的にうまくできなさそうなのでやめました。DjangoではDBへの接続を設定ファイルに書いておかなくてはいけないのですが、私が作ろうとしているのは、新しいユーザーがウェブサイトから登録した場合に、個別に新しいDBを作る設計にしたかったので、接続文字列をログインのたびに動的に変更できない(ように少なくともOfficialのTutorialではそう見えた)Django ORMはやめて、sqlalchemyというものを使いました。 sqlalchemyはFlaskやPyramidなどのPyrhonの他のフレームワークで使われているORMなのですが、Djangoでもインポートして使えます。 データベースは何を使うか。 Djangoのデフォルトはsqlite3なのですが、使おうと思ったプラットホームのサービスのHerokuでは、sqlite3は使えなくて、Postgresqlです。その他にMySQLという選択肢もありますが、私にはMySQLでもPostgresqlでもどちらを使っても得られる機能は同じに見えました。sqlite3はデータがファイルなので管理するにしてもわかりやすいのですが、パスワードをつけることができないのでユーザー認証ができず、やめました。 プラットフォームは何を使うか Windowsサーバーはライセンス料が発生するので論外でしょう。 次に、Linuxを使うかMacを使うかですが、普通はLinuxのどれかのバージョンを使うのでしょうが、私は開発をMacでやっているので、WebサーバーもMacにしました。やっぱり環境の構築とか色々覚えるより、使い慣れている環境を使った方が一々調べる手間も減ると思ったので、ハード代くらいは浮くと思ったのです。ハード代といってもmac miniなら5万円くらいで買えるので、Linuxのハードを買ってもそれくらは普通にかかりそうです。 サーバーをローカルで立てるか、クラウドにするかも考えたのですが、今の所は、事務所に実際のサーバーを置いて運用する予定です。最初はHerokuを使おうと思っていたのですが、色々試したところで、動的にアップロードした画像ファイルをHerokuには保存できないということがわかったのでやめました。画像ファイルが保存できないなんて、領収書の保管が必要な私のサービスでは致命的でした。 ちなみにアップロードした画像ファイルはAWSに保存するようにするのが一般的なようなのですが、それだったら最初からAWSを使った方がよくないですか? 以上、色々と言語の選定から、フレームワーク、データベース、環境構築などに渡りつらつらと書きました。新しくWebサービスを立ち上げる際に沢山の選択肢がありますが、その中からどれを選ぶかなどの参考になれば幸いです。