クリエイティブWeb

問い合わせフォームは「無料の小機能」ではない — CMSのフォームが抱える構造的な問題

2026-07-10T09:00:00+09:00

7年ぶりのブログ更新です。このサイトは長く ASP.NET Core で動かしていましたが、このたび全ページを静的HTMLに作り直しました。その作業で一番考えさせられたのが「問い合わせフォーム」でした。サイト制作では当たり前のように付ける部品ですが、実はサイトの中で一番危ない場所です。今日はその話を書きます。

フォームはサイトで一番狙われる場所

WordPress サイトへの侵入経路は、本体よりもプラグインが大半を占めます。その中でも問い合わせフォームのプラグインは特別です。ほぼすべてのサイトに入っているからです。定番のフォームプラグインは数百万サイトで使われており、ひとつ脆弱性が見つかると、その数百万サイトが同時に攻撃対象になります。攻撃側から見れば、フォームは「外部の入力を受け取ってサーバーで処理する」機能そのものなので、探す価値が最も高い入口です。

スパム対策は「防御側だけがお金を払う」構造になりがち

フォームを置けばスパムが来ます。長年の定番だった CAPTCHA(画像認証)は、AI が実用レベルで突破できるようになりました。Google の reCAPTCHA は従量課金の Enterprise 版へ誘導が進んでいますが、これは判定(アセスメント)ごとの課金で、防御に成功した判定にも課金されます。つまり攻撃されるほど請求が増える。ボットは無料で殴り続けられるのに、防御側は殴られるたびに支払う——この構造自体がおかしいと思いませんか。

自動返信つきフォームは「踏み台」になる

意外に知られていない問題がもうひとつあります。メールアドレスを入力すると自動返信が飛ぶフォームは、他人のメールアドレスを大量に入力されると、迷惑メールの発信源になります(メールボム)。自分のドメインの送信評価が下がり、本来のメールまで届かなくなる。対策には送信頻度の制限や、制限に達しても攻撃側に悟らせない応答設計が必要ですが、そこまで作り込まれた問い合わせフォームはまれです。

放置されたフォームが一番危ない

そしてサイトは、作ったあとに放置されます。更新が止まった WordPress のフォームは、脆弱性が公表されても直されないまま公開され続けます。この「放置された WordPress に何が起きるか」は、当サイトの漫画の新シリーズ「WordPressの危険性編」で描いていますので、あわせてどうぞ。

それで、どうしたか

このサイトが選んだ答えは、公開サイトから動的な処理をなくすことでした。全ページを静的HTMLにすれば、フォームの脆弱性も、サーバーの侵入も、そもそも実行されるプログラムが無いので起きません。

問い合わせは、メールで受けることにしました。フォームと違って送信者の実アドレスで届くので、本人性の確認にもなります。スパムは受信側のフィルタで防ぎます——これは送信側(フォーム)の防御よりずっと枯れた、実績のある技術です。

静的サイトの配信は Cloudflare Pages の無料枠で足ります。デプロイ用には cf-publish という小さな CLI を作って PyPI に公開しました(pip install cf-publish)。ビルドしたフォルダを1コマンドで公開でき、失敗してもロールバックできます。このサイトも同じ方法で公開しています。

まとめ

問い合わせフォームは「無料の小機能」ではありません。継続的な防御・監視・スパム対策のランニングコストを伴う、サイトで一番危ない機能です。サイトを作る(作り直す)ときには、一度立ち止まって考えてみてください——そのフォーム、本当に必要ですか。メールではだめですか。

Python をメインに使うようになりました

2019-02-13T09:38:00+09:00

久しぶりにブログを書きます。2年近く更新ができていませんでしたが、Web サイトをどうするかで迷っていました。Windows系を中心に書いてきたのですが、現在は、Python、PostgrSQL を中心に使うようになっています。それで、記事の内容と現在の自分のしていることがずれてしまってしまいました。もうこの Web サイトを止めようと思うこともしばしばでしたが、個人ブログなので、メモ帳代わりに気軽に書いた方がいいのではないかと思って再開することにします。本体の記事の方も修正していきたいと思っていますがぼちぼちとした修正になると思います。

最近、5374 の Python 版を作りました。徳島市では、今月から一部の地域で家庭ごみの収集日等が変わることになったので、止めようかと思ったのですが、Python で書くと結構簡単に作れると思ったので作ってみました。ソースコードの方は、GitHub の方に公開されているので、興味があればみてください。

py5374

また、Qiita の方には、昨年末に「ExcelにPythonが搭載？その後 - xlwings を使おう」という記事を書きました。もう既に Python 製の OSS のライブラリー xlwings だと問題なく Excel の操作ができるので便利です。マイクロソフトは、Office を事務職のためのツールとして位置づけていると思うので、マイクロソフトには期待せずに OSS を応援したほうがいいように思います。

こういうことを本体の記事にも少しずつ反映していこうと思います。小さな努力ですが、続けていくことが重要だと思っています。

.NET Core Tools 1.0 が公開されて思うこと

2017-03-10T09:46:00+09:00

3月7日に Visual Studio 2017 が正式リリースされましたが、それと一緒に、やっと .NET Core Tools 1.0 が正式リリースされました。.NET Core RC1 が公開されたのは、2015年11月18日でした。その当時は、ASP.NET 5 のためのフレームワークという色彩が強かったのですが、その後にいろんな経緯があって Tools の部分は1年4ヶ月もかかって正式リリースされました。いろいろあったようですが結果的には良かったよぅな気がします。

ところで、Visual Studio は今年 20 周年を迎えたそうです。自分が始めて Visual Studio を使ったのは、Visual Web Developer 2005 Express Edition でした。ASP.NET Web Form のアプリが作れるのですが、Web Form は、Web アプリを作るツールであるのもかかわらず、HTML、CSS が使いづらく、Microsoft のコンポーネントを使わないといけないという全く不便なツールでした。

それで、もう使うのを止めようと思ったのですが、Express Edition を使っていても Standard Edition のアプウグレード版を購入できるというキャンペーンがあったので、Standard Edition を購入して、ASP.NET Web Form を使わずに Web サイトを作りました。それが、徳島の交通状況 Google Maps API 版で、ソースは GitHub の TKGMapに公開しています。

その後も Web Form には馴染めなかったので、Python を勉強し始めました。その時に丁度 ASP.NET MVC がアナウンスされたので、それを使って見たら結構使いやすかったのでそれをメインに使うようになりました。ASP.NET Core は RC の時から使っていますが、ASP.NET MVC の時も CTP から使っていました。

.NET Core 及び ASP.NET Core については、いろいろな評価がありますが、既存のユーザーをスムーズに移行させられるかということと新しいユーザーを獲得できるかということが重要だと思います。

既存ユーザーの件については、ライブラリーの .NET Core 対応が余り進んでいないという点からみると成功していないように思います。RC から RTM になるまで 1年4ヶ月もかかってしまった原因の一つになっていると思いますが、.NET Core 2.0 に期待したいと思います。.NET Core 2.0 では、.NET Statndard 2.0 対応となり、APIが現在の2倍以上にして.NET Framework や Xamarin との互換性がよくなるということです。過去のバージョンとの互換性はやはり必要だと思います。

新規ユーザーは従来より増えているというのは確かですが、どの程度伸びるかは今後に期待したいと思います。Web Form に馴染めなかった自分に取っては、ASP.NET Core は、以前の ASP.NET MVC よりもわかりやすくなって随分よくなったと感じています。特に、Web Form の影響が大きい System.Web が無くなったのはすっきりしたと思います。

市区町村コード表（履歴付）を作成する .NET Core アプリを公開しました

2017-02-20T12:17:00+09:00

国勢調査等の市区町村別の統計データを過去から集計して比較しようとすると、平成の大合併により過去のデータは合併前の市町村のデータを集計する必要があり、普通に手作業ですると非常に手間のかかる作業になります。

政府統計の総合窓口（e-stat）の統計LODで、1970年以降の標標準地域コードのデータが公開されているので、それを利用して、任意の時点での市区町村コード表の作成や対応表が作成できるデータベースを作成するコンソールアプリケーションを作成しました。

.NET Core で作成したので、Windows だけでなく、Mac や Linux でも動作するし、.NET Core はインストールも手軽で簡単に動作させられるようになったので GitHub で公開してみました。URL は、以下のとおりです。

NAreaCode

このアプリを作っていて気がついた点を2点メモしておきます。

コマンドラインの解析

コマンドラインの解析には、Microsoft.Extensions.CommandLineUtils を使いました。CommandLineUtils は、.NET Core になってやっと組み込まれた機能です。

以前の Microsoft はエンタープライズ向けのことには熱心なのですがシンプルに処理をするということにはあまり力が入っていなかったように思っていましたが、.NET Core、ASP.NET Core になって、シンプルに作りたい場合にも使いやすくなったと思います。コマンドラインの解析は、簡単そうですが実際に自分で作るとなると結構手間がかかるので、.NET Core になって改善された典型的な例だと思います。

コード表の処理速度

作成した市区町村コードのデータは、json形式にしています。例えば、期間付き市区町村コードは以下のような形式になっていて、4588件のレコードがあります。

public class StandardAreaCode
{
    [JsonProperty("id")]
    public int Id { get; set; }
    public string 名称 { get; set; }
    public string ふりがな { get; set; }
    public string 英語名 { get; set; }
    public 自治体種別 種別 { get; set;}
    //北海道、東京都島嶼部、長崎県対馬（旧）は支庁・振興局、その他の町村は郡、区は政令指定都市のコード
    public int 所属 { get; set; }
    //北海道及び旧長崎県対馬支庁の町村のみ
    public string 郡名称 { get; set; }
    public string 郡ふりがな { get; set; }
    public DateTime 施行年月日 { get; set; }
    public DateTime 廃止年月日 { get; set; }
    public List<int> 施行データ { get; set; }
    public List<int> 廃止データ { get; set; }
}

これらのデータを Web アプリケーションの中で使う時に、RDB にインポートするのは面倒なので、メモリーベースで処理をするということで、処理時間を計測してみました。都道府県毎に市区町村コードの一覧を計算する処理で、画面の例は「北海道の市区町村コード一覧」です。また、一覧を計算するコードのメインは以下のようになっていて、LINQ を使うのであれば、リストや配列の場合でも SQL Server を使うのとほぼ同じコードで書くことができます。

public IEnumerable<(int id, string 名称, string ふりがな)> GetAreaCode(int pref, DateTime date) =>
    AreaCodeList
    .Where(x => x.Id / 1000 == pref && x.施行年月日 <= date && x.廃止年月日 > date && x.所属 != 99)
    .Select(x => (id: x.Id, 名称: x.名称, ふりがな: x.ふりがな))
    .OrderBy(x => x.id);

Google Compute Engine の n1-standard-2 （AWS の m4.large とほぼ同性能）を使って処理時間を計測すると以下のようになりました。

ファイルサイズ 1126KB
データの読み込み時間 45ms
計算時間 0.4～0.008ms

結果としては、SQL Server Express を使うよりも遙かに早いです。計算時間の 0.4ミリ秒は初回の計算の時で計算ルーティンやデータが CPU のキャッシュメモリーに入っていない場合の処理時間です。計算の必要なコードとデータが CPU のキャッシュメモリにキャッシュされてしまえば 0.008ms という圧倒的な速さで処理がなされます。こういう処理ではデータのやりとりにばっかり時間を食っていて、本当の計算時間なんてごく僅かのものだなと感じます。

そういうことで、データー量がそれほど大きくないコード関係は RDB を使うのをやめてメモリーに乗せていこうと思っています。管理も、RDB で管理するよりも、テキストベースにして git で管理した方が遙かに管理しやすいし、入力もデータベース用の入力画面を使うよりも、テキストエディターや Excel で編集できた方が楽です。RDB をやめることの欠点ってといえば、コードを修正する毎にアプリをデプロイしなければいけないので、その手間が増えるのですが、昔と違って今はデプロイが楽になっているのでデータの更新の頻度ににもよりますがそれほどの負担にはならないと思います。

AWS vs Azure vs GCP

2017-02-12T17:38:00+09:00

最近、このサイトを運用しているサーバーを Google Cloud Platform の Google Compute Engine に移転しました。その際に調べたことをメモしておきます。

まず、サーバーで価格を重視するのであれば、VPS がいいと思います。メモリ 1G のものが1000円程度、8G のものが数千円程度であります。クラウドの場合 CPU だけであれば同じぐらいの価格ですが、ストレージやデータ転送量が別途必要になるので価格は1.3倍とかになってしまいます。ただし、VPS には以下のような欠点があるので、安定した運用向きです、

初期費用が必要だったり月単位の料金のところが多く、柔軟にサーバーの能力や台数を変更することができない。OSやアプリケーションの大規模なバージョンアップの場合、運用を止めないためには平行運用をする時間が必要であるが、クラウドのようにその時間だけの費用ではなく、初期費用等の料金が発生する。
クラウドの場合は、バックアップが簡単に取れたり、Amazon S3 のようなクラウドストレージが利用できるが、VPS では、そのようなサービスがない。

クラウドで IaaS を選択する場合には以下の記事が参考になると思います。

ZDNet Japan の記事 AWSとMSがIaaS市場で圧倒--ガートナーの「マジック・クアドラント」
Publickeyの記事ガートナーがIaaSクラウド市場のマジッククアドラント2016年版を発表。Amazonクラウドの圧倒的リーダーは変わらず
元資料 Gartner: Magic Quadrant for Cloud Infrastructure as a Service, Worldwide

クラウドの Iaas 分野では、リーダーは AWS（Amazon Web Servise）です。上に紹介した記事で「AWSは多様な顧客ベースを有し、ほとんどのユースケースを網羅している。」とあるように、サービスの豊富さでは他を圧倒しています。

価格的には、AWS、Azure、Google Cloud Platform(GCP) も割引を除いては大きな差はありません。AWS はサービスが豊富です。AWS の典型的なサービスとしては、Amazon Aurora があり、OSS の RDB である MySQL 及び PostgreSQL をクラウド向けに改良してフルマネージドのサービスとして提供しています。AWS は、ビジネスに必要なツールをクラウドに適した形で提供するというのが得意です。

Azure は、企業のニーズを満たすために重要な機能、例えば、セキュリティ、可用性、ユーザー管理などの機能が充実しています。例えば、バックアップであれば下の図のように、毎日定時にバックアップするとかファイルの回復という機能がついています。自分が以前にExcelで事務をして Windows 2013 Server をファイルサーバーにしていた時にこういうことをしていました。

また、料金サービスの面でも以下のように企業向けには便利なものがあります。

エンタープライズ契約をして前払いをすると大幅な割引がある。
他のクラウドがクレジットカード払いになるのに対して、エンタープライズ契約をすると請求書払いが可能。また、リセラーからライセンスキーを購入するという方法もあるのでクレジット払いをしなくてもすむ。
料金が円建てなので為替による変動がない。

このようなことから、Azure の売上高は急増しています。しかし、自分のような個人や零細企業の場合は、割引が全く適用されないこと、AWS であればスポットインスタンス、GCP であればプリエンプティブインスタンスに対応するものがないことから、コスト的に相当高くなるので AWS か GCP を選択した方がいいと思います。

GCP（Google Compute Platform）は、記事に「この業界のリーダーに分類されている企業が有している機能に相当するものすべては備えていないため、大企業や中規模企業を強く魅了することに苦労している」とありますが、自分もそのとおりだと思います。そういうことで、利用者数では AWS や Azure から一歩遅れていることも事実です。

しかし、開発者の立場からすると、快適に使えるクラウドです。昨年の11月に東京リージョンが開設されたことだし、$300ドルで60日間使用できるクレジットが貰えるということなので、実際に使ってみました。GCE は、起動が速く、マシンを1分もかからずに起動できます。また、起動しているマシンを止めることなくスナップショットを1分ぐらいで取れます。そのため、運用しているマシンを増やすのも簡単だし、テスト環境も直ぐに作れます。

また、ダッシュボードは下の図のようになっており、管理画面はかなり使いやすいし、AWS と違って料金を払わなくても 1分間隔の CPU の稼働率が表示されるのが嬉しいところです。管理機能は、Stackdriver が使っており、かなり高機能なことができるようです。

価格的には、AWS とほぼ同じですが、割引の条件が AWS の EC2 場合は1年又は3年縛りになっていて事前に購入が必要等料金設定が複雑です。それに対して、GCE の場合は、1ヶ月単位で長時間使用していれば勝手に割引してくれるのでかなり楽です。

自分なりのクラウドの選択についての結論をいうと以下のようになります。

ビジネスのために使いたいのであれば、AWS がベストです。Amazon はECサイトから発展した会社だけあってユーザーニーズを最もよくつかんでいる会社です。だから、今後もサービスの豊富さではリーダーシップを取っていくと思います。
エンタープライズであれば、Azure がいいと思います。SQL Server、 Windows Server、Microsoft Office のようにエンタープライズ向けの製品を扱ってきた経験と実績があり、エンタープライズが必要な機能が充実しています。
Web、スマートフォンのバックエンド、AI、データサイエンス等の分野で使うのであれば GCP がベストです。GCP は、Google が自社の環境を一般公開しているという側面が強く、基本性能は高いので、このような Google が得意とする分野では優れたものがあります。

自分の場合は、Google Adsense、Analytics、Search Console 等の Google のサービスを以前から使っており、また、以前のブログ「ボットネットの脅威を考えたら Google Cloud を使うのがベストだ」に書いているように、DDoS攻撃に強いものにしていきたいので GCP を選択しました。

Visual Studio 2017 RC を使ってみた

2017-02-02T22:46:00+09:00

Visual Studio 2017 RC のアップデートがあり、「.NET CoreおよびASP.NET Core のワークロードは、もはやプレビュー版ではない。.NET Core およびASP.NET Core の Toolのいくらかのバグを修正し、使いやすさを改善した」ということなので使ってみました。

.NET Core SDK の preview2 までは、プロジェクトファイルが project.json でしたが、Visual Studio 2017 では、MSBuild の .csproj 形式に変更になりました。それがどうなっているか知りたかったためです。

Visual Studio 2017 で project.json 形式のプロジェクトを開こうとすると、以下のように一方向のアップグレードというメッセージがでます。

ここで、「OK」をクリックすると、.csproj 形式に変更されます。それでアップグレードは完了で、動作します。

ただし、このアップグレードは、完全ではないようなので、Project.json と MSBuild の .csproj 形式の対応を調べたい場合は、Hanselman 氏のブログにあったのですが、次の記事が参考になりました。

Project.json to MSBuild conversion guide

Project.json と .csproj のどちらがいいのかという議論はあると思うのですが、.csproj の方もかなり簡単になっているので、.csproj でいいのかなと思います。自分の場合は、今回の変更については問題はなかったです。

このサイトも、アップグレードして Visual Studio 2017 用にしました。Visual Studio 2017 の方は、バグらしきものはまだ残っていますが、Visual Studio 2015 と同じレベルで使えています。

「ASP.NET Core アプリを Linux サーバーで公開」のページの方も.csproj 形式の方に更新しました。

統計LODのバグから見える沖縄の歴史

2017-01-18T13:15:00+09:00

統計LODの「統計に用いる標準地域コード」を使っていて面白いバグを見つけたのでメモしておきます。

沖縄県では、北部が本土に近いので国頭（くにがみ）郡で、南部はシマの尻となるので島尻郡です。それにもかかわらず、沖縄県の最も北に位置し東シナ海上に浮かぶ伊平屋村及び伊是名村は国頭郡ではなくて島尻郡に属しています。

伊平屋島は、琉球王朝の第一尚氏縁の地であり、伊是名島は、第二尚氏縁の地です。そのため琉球王朝の時代には直轄地だったという歴史があり、その後の経過を経て島尻郡に属するようになったようです。

具体的な統計 LOD のバグの内容ですが検索用画面で以下の Query を実行してみてください。

PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
PREFIX org:<http://www.w3.org/ns/org#>
PREFIX dcterms:<http://purl.org/dc/terms/>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX sac:<http://data.e-stat.go.jp/lod/sac/>
PREFIX sace:<http://data.e-stat.go.jp/lod/sace/>
PREFIX sacr:<http://data.e-stat.go.jp/lod/sacr/>

SELECT ?p ?o WHERE { 
  sace:C394 ?p ?o .  
}

Output を Text にすると次のように検索結果が返されます。

-------------------------------------------------------------------------------------------------
| p                         | o                                                                 |
=============================================================================
| rdf:type                  | sacs:CodeChangeEvent                                              |
| org:resultingOrganization | sac:C47361-20020401                                               |
| org:resultingOrganization | sac:C47352-20020401                                               |
| org:resultingOrganization | sac:C47351-20020401                                               |
| dcterms:description       | "Nakazato-son(47351) and Gushikawa-son(47352) are merged, and Kumejima-cho(47361) in Shimajiri-gun is newly established."@en |
| dcterms:description       | "仲里村(47351)、具志川村(47352)が合併し、久米島町(47361)を新設"@ja|
| org:originalOrganization  | sac:C47352-20001222                                               |
| org:originalOrganization  | sac:C47361-19720607                                               |
| org:originalOrganization  | sac:C47351-20001222                                               |
| dcterms:identifier        | "394"                                                             |
| sacs:reasonForChange      | sacr:establishmentOfNewMunicipalityByMmerging                |
| dcterms:date              | "2002-04-01"^^<http://www.w3.org/2001/XMLSchema#date>       |
-------------------------------------------------------------------------------------------------

org:originalOrganization（変更前の期間つき標準地域コードのリソース）に、sac:C47361-19720607 があります。確かに 47361 は現在の久米島町の市町村コードではありますが、1972年には久米島町はなかったはずです。実は C47361-19720607 は、宮古郡城辺町（現宮古市）の昔の市町村コードです。47361 という市町村コードは使い回しされていたのです。

市町村コードは廃止されたコードは欠番とされ、新たなコードとして別の自治体に交付しないという原則に例外があったのです。恐らくそのことを知らないエンジニアが間違ったプログラムを書いたのですが、影響はあまりないのでそのままになっていると思います。

なぜこういうことが発生したのか、まず、1965年（昭和40年）の沖縄県の国勢調査の結果をみてみると、以下の図のように琉球政府の時代には郡は使わずに北部地区という名称を使っていたようです。

1970年（昭和45年）の沖縄県の国勢調査の結果をみると、復帰前ですが本土と同じように市町村コードが振られて郡が復活しています。その際に北部地区をそのまま国頭郡にしてしまったようです。

本土復帰後になって、伊平屋村及び伊是名村が島尻郡に属していることがわかり修正しようとしたのですが、運悪く島尻郡に属する町村が多すぎて伊是名村が47360というコードになり宮古郡のコードと衝突してしまったのです。それで宮古郡のコードを47370に変更し、宮古郡に属する町村のコードも変更せざるを得なくなったようです。そして、合併で久米島町ができたときに 47361 になり城辺町の昔のコードを使い回してしまったということのようです。

統計LODから取得した標準地域コードを利用して、統計メモ帳のページを追加中なので、完成したらそのページの方も紹介したいと思います。

Python を始めました

2017-01-14T22:20:00+09:00

最近 Python を使い始めました。そうはいっても ASP.NET Core の代わりに Python を使うわけではありません。ASP.NET Core は、いいソフトだと思っているので、Web アプリの関係では、これからも使うつもりです。。

自分が .NET Framework ではなくて .NET Core を使う場合に困ることは、System.Drawing がないこと、Excelファイルを読み書きする NPI 等のライブラリーや数値計算用のライブラリーが .NET Core には対応していないことです。

これをどうするか考えていくと、こういう処理は C# ではなくて Python の方が得意なので、C# でライブラリーを探したり自分で作ったりするよりは、Python を使った方がベターだと思ったためです。

ところで、Python の方も Python 3 が出たのは、2008年だからもう8年も経っています。それでも Python 2 系使っているところが多いようです。確かに互換性がないとプログラムの修正は大変です。.NET Core の場合でもサードパーティのライブラリーの対応はなかなか進んでいません。.NET Core の場合は、.NET Core 2 で .NET Standard 2.0 に対応して、従来の .NET Framework と互換性がかなり良くなるようなので、どうなるのか楽しみですが、対応には時間がかかるというのが現実だと思います。

Python 2 と Python 3 のどちらを使うのかという点ですが、やっと殆どのライブラリーが Python 3 に対応したそうで、それに自分の場合は過去のしがらみがないので Python 3 にしました。

Python の環境構築には、miniconda を使いました。Python の環境構築の方法は何種類かありますが、科学計算ライブラリを使う場合は anaconda を使うと管理が楽で、デファクトになっているようです。

Python の IDE は、Visual Studio に Python Tools for Visual Studio をインストールしたものと Jetbrains 社の PyCharm の Commnity Edition を使っていて、どちらが使いやすいかテスト中です。PyCharm は、Web アプリを作らないのであれば、特にPro版を買わなくてもすみそうです。

Excel のファイルを操作するライブラリーには、openpyxl、xlsxwriter、xlrd、xlwt があって、一応 xls と xlsx の両方のファイルを読み書きできるようです。自分が必要なのは取りあえず、xls ファイルのデータを読み込む xlrd なので、それを試してみたら日本語も読むことができました。

現在は、「入門 Python 3」で勉強中です。他の言語が使えるのであれば、Python は1週間あればそれなりには使えるようになります。プログラム言語を複数使うのは、頭がこんがらがってくるので、したくはないのですが、C# はビジネス向けが強くて、科学計算に使っている人はそれほど多くないと思います。プログラム言語が沢山あるということは、その数だけ用途があるということだと思うので、用途によってその分野に強いプログラム言語を使うというのは仕方がないことのように思います。

Bootstrap 4 Alpha 6 を使ってみた

2017-01-11T17:55:00+09:00

Bootstrap 4 Alpha 6 が1月6日に公開されました。今回のバージョンでかなり完成に近づいたと思うので、テスト的に使ってみました。次は、Beta になる予定で、残っている Issues の数もそれほど多くないので、基本的な所での変更はあまりないだろうと思っています。

自分の場合は、Visual Studio 2015 を使っていて ASP.NET Core で Web アプリケーションを作ることが多いので、最初に Visual Studio の ASP.NET Core Web Application のテンプレートを使って試してみました。

Bootstrap 4 に更新するためには、bower.json を以下のように変更します。bootstrap のバージョンを変更し、ツールチップの表示に Tether という JavaScript のライブラリーを利用するため、そのライブラリーを追加するだけです。

{
  "name": "asp.net",
  "private": true,
  "dependencies": {
    "bootstrap": "4.0.0-alpha.6",
    "jquery": "3.1.1",
    "jquery-validation": "1.14.0",
    "jquery-validation-unobtrusive": "3.2.6",
    "tether": "1.4.0"
  }
}

インストールするだけであれば簡単なのですが、実行させてみると完全にレイアウトが崩れてしまいます。Ver3 から Ver4 への変更は影響がかなり大きいことがわかります。

どのような修正が必要になるのかについては、そのテンプレートを、取りあえず動くようにしたものを GitHub の方に公開していますので参考にしてください。Navbar や Carousel にもかなり修正が入っています。

それで、公式ドキュメントを結構真面目に読んでいます。英語がそれほど得意でないので、前回のブログで紹介した「Google ウェブサイト翻訳ツール」プラグインをつけたドキュメントのページが結構役に立っています。

それらの作業をして、公式ドキュメントの Migrating to v4 を読んだところでは、Ver4 の特徴は、HTML5、CSS3 の機能をフルに活用するようになったということのようです。

自分としては、Bootstrap 4 は以前よりかなり良くなっていると思うので、積極的に使っていきたいです。でも、class 名が結構変わっているので、既存のWebサイトを Bootstrap 4 にバージョンアップしようとすると修正箇所が多くなるので、手間を考えると少し憂鬱ですが、時間をかけて更新していくつもりです。

なお、Ver4 の主な変更点は、以下のようなところです。

IE8 と IE9 のサポートの廃止
Flexbox によるレイアウト
Less から Sass へ
標準のフォントサイズは 16px
使う単位を px から rem に変更
ブレークポイントに576pxを追加

Bootstrap 4 のドキュメントに「ウェブサイト翻訳ツール」プラグインをつけてみた

2017-01-04T22:30:00+09:00

Bootstrap 4 Alpha が最初に公開されたのは、昨年の8月19日です。それから1年4ヶ月を経過しましたが、まだ Alpha 5 という状況です。開発に非常に時間がかかっていますが、最近になってやっと開発が加速しているようなので、自分もテストに使い始めました。

Bootstrap 4 Alpha のドキュメントは当然英語しかないのですが、Google翻訳にニューラルネットワークが導入されて精度が大幅に上昇しているので、Bootstrap 4 のドキュメントに「ウェブサイト翻訳ツール」プラグインをつけてみました。Bootstrap のドキュメントは、GutHub で CREATIVE COMMONS で公開されているので、著作権の問題はないので以下の URL で公開していますので興味のある方は見てください。

http://bootstrap.pp22.net/

プラグインを追加するだけで、翻訳ができてしまうのは、素晴らしいです。

Google 翻訳は、まだまだ、おかしなところも多いですが、あれば便利というところまではなっていると思います。以前は使い物にならなかった機械翻訳ですが、やっと少しですが実用的になったようです。

Bootstrap 4 の日本語のドキュメントはBootstrap 4 日本語リファレンスという翻訳中のものがあるのですが、現時点では未翻訳の部分が多いし、Alpha 2 ベースです。ドキュメントの翻訳には時間と手間がかかるので、もう Google 翻訳で我慢してもいいように思います。

Bootstrap 4 の開発状況ですが、9月6日に、現行バージョンである Bootstrap 3 の定期的メンテナンスを終了するという発表（Getting to v4）がありました。この状況については、InfoQの「Bootstrap v3の定期的メンテナンスが終了」という記事が参考になると思います。

現在開発中の Alpha 6 では、Flexbox がデフォルトになり従来の float レイアウトはサポートされなくなります（v4 Alpha 6 ship list）。普通に使っているブラウザーで Flexbox をサポートしていないのは IE9 だけですが、IE9 は今年（2017年）の 4月11日に Windows Vista と共にサポート切れになります。

これらの件は、当初の計画とは違うものですが、開発者の負担の軽減ということでは仕方がないことだと思います。そして、Bootstrap 4 の問題（Issues）が順調に解消され始めています。近いうちに Alpha 6 が公開され、その次は Beta です。完成も見えてきたように思います。

ASP.NET Core でボットネット対策（その１ middlewareを使う）

2016-12-20T15:10:00+09:00

DDoS 攻撃への対応

この記事は「ASP.NET Advent Calendar 2016 - Qiita」の20日目になります。

昨日のブログでは、ボットネットからアクセスがあることを書きましたが、その中で Google Cloud Datastore は自動スケールするので役に立ちそうだということを書きました。自動スケールされると破産するのではと心配する人もいると思いますが、Google Cloud では費用制限を設定するので破産することはないし、1秒間に1万回の読み込みをしても、1時間だと $21.6 とそれほど大したことはありません。

ただし、攻撃を放置しておくと結構な料金になってしまうので、攻撃を止める方法を考えてみました。

まず、DDoS 攻撃の現状がどうなっているかについては、Googleのシンクタンク部門である Google Ideas とセキュリティ企業の Arbor Networks と協力して、DDoS攻撃の状況をリアルタイムで表示するDigital Attack Mapを公開しています。そのサイトの Understanding DDoS によると、1週間小さな組織のシステムをダウンさせる能力があるボットネットを $150 で借りられるそうです。自分の場合は、最初はこの程度でできる攻撃への対応を考えてみようと思っています。

DDoS 攻撃への対応

攻撃を止める基本は、ボットのIPアドレスを特定して、そこからのアクセスを拒否することです。IPアドレスが特定できれば、アクセスの拒否については、ファイアーウォール、リバースプロキシーでも簡単にできます。そのため、DoS攻撃の場合は、比較的簡単に防御できます。

しかし、DDoS 攻撃の場合は、大量のボットから攻撃があるので、そもそも正常なアクセスなのか攻撃なのかを区別するのが容易でないし、攻撃元を特定して遮断していく作業は容易でありません。もし、攻撃元がボットをどんどん変更して攻撃してくれば、対応は本当に困難になります。

HTTP リクエストの場合、接続する URL 以外に IPアドレス、Referer、User-Agent の情報が送られてきます。低価格で借りたボットネットであれば、これらの情報に片寄りが生じるはずなので情報をうまく解析すれば、ボットのIPアドレスは特定できるはずです。

また、Pokémon GO で有名になったコイル警備員、すなわち Google の reCAPTCHA を使うことも有効です。アクセス拒否は、もし間違って拒否をするとそのユーザーを失うことになるので、疑わしいという状況では使いたくありません。でも、コイル警備員だとユーザー側の負担は遙かに軽いので、疑わしIPアドレスに対して使う事ができます。

Middleware を作成して特定のIPアドレスからのアクセスを拒否する

まず最初に、ASP.NET Core アプリケーションで、特定のIPアドレスからのアクセスを拒否するケースを考えてみます。

この場合には、HTTP Request があって、そのリクエストが MVC の処理に入るまでに処理をする必要があるため、Middleware を作成して処理する必要があります。ASP.NET Core の Middleware の Document に、middleware pipelineの図（下図）がありますが、

その図をみれば、どう処理をしたらいいかをイメージできると思います。標準の MVC Middleware コンポーネントの前にカスタム Middleware コンポーネントを作成して処理をすることになります。

Middleware の作成に Visual Studio を使う場合は、「ミドルウェアクラス」のテンプレートがあるのでそれを使うと便利です。それを少し変更して非同期にすると下のようなコードになります。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
namespace MyApp
{
    // You may need to install the Microsoft.AspNetCore.Http.Abstractions package into your project
    public class MyMiddleware
    {
        private readonly RequestDelegate _next;
        public MyMiddleware(RequestDelegate next)
        {
            _next = next;
        }
        public async Task Invoke(HttpContext httpContext)
        {
            await _next(httpContext);
        }
    }
    // Extension method used to add the middleware to the HTTP request pipeline.
    public static class MyMiddlewareExtensions
    {
        public static IApplicationBuilder UseMyMiddleware(this IApplicationBuilder builder)
        {
            return builder.UseMiddleware<MyMiddleware>();
        }
    }
}

このコードと middleware pipeline の図を眺めていると大まかな使い方は理解できました。Invoke メソッドの、await _next(httpContext) が次のパイプラインを呼び出す処理で、その前後にコードを書くことで独自の処理を行わせることができます。

以下は、上のコードを修正して、特定のIPアドレスからのアクセスを拒否するようにしたサンプルです。

    public class AntiBotMiddleware
    {
        private readonly RequestDelegate _next;
        //拒否するアドレスの指定
        private readonly List<string> _blackIpAddress = new List<string> {"192.168.0.1", "192.168.0.2"};
        public AntiBotMiddleware(RequestDelegate next)
        {
            _next = next;
        }
        public async Task Invoke(HttpContext httpContext)
        {
            //IPアドレスの取得
            string remoteIpAddress = httpContext.Connection.RemoteIpAddress.ToString();
            if (_blackIpAddress.Contains(remoteIpAddress))
            {
                //403 を返す                
                httpContext.Response.StatusCode = 403;
                return;
            }
            await _next(httpContext);
        }
    }

_next を呼ばなければ、次のパイプラインに行かずに返ります。それで、ブラウザーでは「サーバーエラー 403アクセスが拒否されました」と表示されるようになります。

この middleware を実行させるためには、Startup.cs の Configure メソッドに登録する必要があります。

        public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        {
            loggerFactory.AddConsole(Configuration.GetSection("Logging"));
            loggerFactory.AddDebug();
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
                app.UseBrowserLink();
            }
            else
            {
                app.UseExceptionHandler("/Home/Error");
            }
            app.UseStaticFiles();
            app.UseAntiBotMiddleware();
            app.UseMvc(routes =>
            {
                routes.MapRoute(
                    name: "default",
                    template: "{controller=Home}/{action=Index}/{id?}");
            });
        }

ここで、注意すべきことは、登録の順番が重要になってくるということです。今回の middleware は、その性格からいって UseMVC より前に置く必要があります。そして、UseStaticFiles の前におけば、静的ファイルもアクセス拒否の対象になり、後ろに置けば静的ファイルを除いたものがアクセス拒否の対象になります。

このサンプルは、プロキシーサーバーを使っている場合はうまく動作しません。httpContext.Connection.RemoteIpAddress が、プロキシーサーバーのアドレスになるためです。以下は、Nginx をプロキシーサーバーに使っている場合のサンプルです。

        public async Task Invoke(HttpContext httpContext)
        {
            //IPアドレスの取得
            string remoteIpAddress = GetRequestIP(httpContext);
            if (_blackIpAddress.Contains(remoteIpAddress))
            {
                //403 を返す                
                httpContext.Response.StatusCode = 403;
                return;
            }
            await _next(httpContext);
        }
        private static string GetRequestIP(HttpContext httpContext)
        {
            string ip = GetHeaderValueAs("X-Forwarded-For", httpContext);
            if (string.IsNullOrWhiteSpace(ip))
                return  httpContext.Connection.RemoteIpAddress.ToString();
            return ip;
        }
        private static string GetHeaderValueAs(string headerName, HttpContext httpContext)
        {
            StringValues values;
            if (httpContext?.Request?.Headers?.TryGetValue(headerName, out values) ?? false)
            {
                return values[0];
            }
            return null;
        }

なお、このサンプルが動作するためには、Nginx側で、X-Forwarded-For の設定をしておく必要があります。

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Dependency Injection を使う

上のサンプルで不便なのは、拒否するアドレスの指定を初期化で行っているところです。拒否するアドレスは画面で検索できたり変更できた方がいいですね。その場合には、Dependency Injection（DI）を使うのが自然です。DI という名前を聞くと難しそうに思うのし、解説を読んでも難しいのですが、以下のように簡単に作って試してみたら動作しました。

まず、普通に Class を作ります。（正式には、最初に Interface を作るようです）

public class AntiBotServise
{
    public List<string> BlackIpAddress { get; set; }
    public AntiBotServise()
    {
        BlackIpAddress = new List<string> {"192.168.0.1", "192.168.0.2"};
    }
}

すべてのリクエストで共通に使用するので、Startup.cs の ConfigureServices で AddSingleton を使って DIサービスコンテナに登録します。

public void ConfigureServices(IServiceCollection services)
{
   services.AddSingleton<AntiBotServise>();
   // Add framework services.
   services.AddMvc();
}

Middleware の方で、次のように Injection します。

public class AntiBotMiddleware
{
    private readonly RequestDelegate _next;
    private readonly AntiBotServise _antiBotServise;
    public AntiBotMiddleware(RequestDelegate next, AntiBotServise antiBotServise)
    {
        _next = next;
        _antiBotServise = antiBotServise;
    }
    public async Task Invoke(HttpContext httpContext)
    {
        //IPアドレスの取得
        string remoteIpAddress = GetRequestIP(httpContext);
        if (_antiBotServise.BlackIpAddress.Contains(remoteIpAddress))
        {
            //403 を返す
            httpContext.Response.StatusCode = 403;
            return;
        }
        await _next(httpContext);
    }
}

Controller や View でも、同様に Injection できるので、画面で検索できたり変更したりできるようになります。

補足

長くなってきたので、middleware で eCAPTCHA を使う話は次回にします。

ASP.NET Advent Calendar では、Azure の話が多いようです。確かにエンタープライズ向けのクラウドでは Azure がベストだと思います。

しかし、DDoS の件を調べていると Google の名前がたびたび出てきます。Google は、公開用 Web サーバーが有力な収益源の一つなので、その関係のサービスは、Google の方がはるかに充実しています。また、.NET Foundation に加盟したことでもわかるように、Google Cloud Platform での .NET サポートはかなり進んできているという印象です。

ボットネットの脅威を考えたら Google Cloud を使うのがベストだ

2016-12-19T00:10:00+09:00

これは Google Cloud Platform(2) Advent Calendar 2016 の19日目の記事です。

今年の11月に「Mirai」ボットネットが、Twitterなどの利用するDNSサービスへDDoS攻撃をしてサービスをダウンさせた事件があって、IoT ボットネットが話題になっています。先日、その IoT ボットネットから自分のWebサイトにもアクセスがありました。もちろん IoT ボットネットからという確証はありませんが、早朝から深夜までアクセスがあったので、常時電源の入っている機器には間違いありません。それだと普通のPCではないし、IP アドレスを調べるとモバイル回線からのアクセスはないのでスマートフォンでもなさそうです。

攻撃者は遊び程度だったようで、50台ぐらいのボットネットで、アクセスの間隔もかなり開いていました。それでもサーバーの CPU 負荷が普段より数倍になったので気がつきました。自分のWebサイトは時々スパイクアクセスがあるので、サーバーにかなり余裕をもたせていたので、今回は無事でした。

でも、もう少し攻撃が激しければ、システムがダウンしたと思います。そういうことを考えれば、サーバーはできるだけ増強したいのですが、その分サーバー料金がかさむのが痛いところです。

スパイクアクセスの場合は、同じページにアクセスが集中するので出力キャッシュが効果的なのですが、DDoS攻撃の場合はどういう攻撃されるか分からないので、現状だと、データベースの部分が弱いので、その能力のアップを急ごうと思っています。

現在、AWS を使っているので、DynamoDB だったら短時間でスループットを上げられるのかと調べてみると、よくある質問に以下のような回答がありました。スループットを増やすのに数分以上かかるようで、それだったらシステムはダウンしてしまいます。

Q: テーブルのプロビジョニングされたスループットレベルを変更するにはどのくらい時間がかかりますか？

通常、スループットを減らす場合は数秒から数分、増やす場合は数分から数時間かかります。

追加スループットが必要になった時点でスループットを増加したり増加のスケジュールを立てたりすることはお勧めできません。スループット容量のプロビジョニングは、必要なときに確実に容量を確保できるようかなり前から行っておくことをお勧めします。

それで Google Cloud Platform を調べたら、さすがに Google です。Cloud Datastore は、完全に自動スケールで、何も考える必要はありません。料金は以下のように完全に使っただけの料金になります。（以下東京リージョンの料金です）

データの保存 $0.18 GB/月
エンティティの読み込み数 $0.06 /10万エンティティ
エンティティの書き込み数 $0.18 /10万エンティティ
エンティティの削除数 $0.02 /10 万エンティティ

一方、AWS の DynamoDB の料金は以下のようになっています。

書き込みスループット: $0.00742 :10 ユニットの書き込み容量あたり/1 時間（1 時間あたり最大 36,000 回の書き込みを実行するために十分な容量）
読み込みスループット: $0.00742 : 50 ユニットの読み込み容量あたり/1 時間（1 時間あたり最大 180,000 回の強力な整合性のある読み込み、または最大 360,000 回の結果整合性のある読み込みを実行するために十分な容量）

こちらは、スループットで料金が決まります。この料金の記載だと、結果整合性のある読み込みだと、50ユニットの設定で、月2億5千万回のアクセスができ $5.34 で済みます。Google Cloud Datastore だったら $155 もかかると言いたいのでしょう。さすがに Amazon は商売上手です。

でも、公開用 Web サーバーの場合は、スパイクアクセスやDDoS攻撃のことを考えるとそんな単純な話ではありません。

価格を比較するため、公開用 Web サーバーで月1千万PVのWebサイトがあるとします。月1千万PVあれば Webサービスだとかなり楽に経営ができます。

Cloud Datastore の料金は、1pv に必要なデータベースへのリクエストを1エンティティとすると、料金は月 $6 になります。仮に 1pv当たり平均 10 エンティティが必要だとしても、月 $60 です。安い言い切るのは難しいかもしれませんがリーズナブルな料金です。

DynamoDB の場合は、容量をあらかじめ確保しておく必要があります。スパイクアクセスやDDos攻撃を考えると予測不可能で必要な容量の計算なんかできないですね。取りあえず1秒間に100pvのアクセスということにして、1pv で必要なデータベースへのアクセスが1ユニットだとすると、50ユニットが必要で月$5.34です。Cloud Datastore とほぼ同じ金額になります。

でも、ここでよく考えてみてください。DynamoDB は、全体のスループットではなくて、テーブル毎にスループットを設定する必要があります。ローカルセカンダリインデックスは、5個まででかつテーブルの作成のときに定義してやる必要がありそれ以降の変更はできないので、一つのテーブルに各種のデータを詰め込むのは無理で、それなりの数のテーブルが必要になると思います。DDos攻撃はどこが狙われるか分からないので、1秒間に100pvのアクセスに耐えるようにしようと思えば、すべてのテーブルにそにアクセスに耐えるだけのユニットを割り当てる必要があります。そしてさらに最悪なのが、1pv 当たりに必要なデータベースへのアクセスが平均では2ユニットであっても、あるページで50ユニット必要であれば、そのページが狙われるとダメなので、そのテーブルには50×50=2500ユニットも割り当てる必要がありそれだけで月$267になってしまいます。

1秒間に100pvというのは、どの程度かというと、今回のボットネットからの自分のサイトへのアクセスは、1台で1秒に15回以上のアクセスがありました。10台あれば150pvになるので100pvの容量だとエラーが多発するようになります。1秒間に100pvというのは、DDoS攻撃対策では、殆ど話にならないレベルです。

こう考えていくと、DynamoDB は、DDoS対策としては最悪でした。そして、通常の利用においても DynamoDB ファーストにするとテーブル数が多くなってコストが嵩みます。このことは、AWS もよく理解しているようで、Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイドという記事から引用します。

NoSQL データベースではなく、最初はSQLデータベースを使用しましょう。

まずはSQLデータベースの使用を推奨します。技術は確立されています。

既存のコードやコミュニティ、サポートグループ、書籍やツールが多く存在します。

最初の1000万ユーザでSQLデータベースが破壊されることはありません。（データベースが大規模でない限り）壊れることはないでしょう。

スケーラビリティの明確なパターンがあります。

NoSQL データベースが必要になるのはいつなのでしょうか。

5TB以上のデータを初年に格納する必要がある場合や信じられないほどのデータベース集中型のワークロードの場合。

アプリケーションの要件が超低遅延である場合。

高いスループットが必要な場合。読み込みや書き込みの際の出入力にかなり手を加える必要があります。

リレーショナルデータがない場合。

要するに DynamoDB は、アプリケーションを高速化するために、ごく少数のテーブルに対して使うべきもののようです。この影響で、業務系の人を中心に、NoSQL ファーストはダメだと思っている人が多いと思いますが、AWS の事情であって、本来はどちらがいいというものではなくて、アプリケーションの性格によって使うべきものです。

クラウドも AWS、Azure、Google Cloud のどれがいいのかという一般的な答えはないと思います。しかし、システムダウンしないWebサーバーにしようと思ったら、Cloud Datastore は殆どコストなしで無制限にスケールできるので Google Cloud を使った方がはるかにいいと思います。Google Cloud のアクセス集中に対する強さは、今年 Pokémon GO で実証されています。一方、AWS で、SQLデータベースをメインに使った場合、エンタープライズ向けの閉じたシステムだと、アクセス数はそれなりの精度で想定できるので問題はあまり生じないと思いますが、公開 Web サーバーで、DDoS攻撃のことまで考えると非常に難しい問題になります。SQLデータベースではスケールさせるのにコストが非常に高くなるし、急激なアクセス増への対応も簡単ではないと思います。この点は、Azure も同じだと思います。

自分の Web サイトは、できれば DDoS攻撃に強いものにしていきたいので、サーバーを AWS から Google Cloud Platform に移そうと思っています。でも、Amazon EC2 のリザーブドインスタンスを買っているので、その期間が終了するまでは待ちます。リザーブドインスタンスは料金の割引は大きいのですが制約は厳しいと思います。google Compute Engine の方は、1ヶ月単位で自動的に継続割引が適用されます。何もしなくてもいいのには気に入りました。（計算してみたら AWSは3年の標準リザーブドインスタンスだとAmazon EC2 の料金が安いですが、3年縛りは厳しいし、値下げが適用されないのでリスクが高いです。コンバーティブルリザーブドインスタンスにすると google Compute Engine の継続割引後の料金とほぼ同じです。）

.NET Core で PostgreSQL を使ってみたら結構いけていたという話

2016-12-15T10:00:00+09:00

これは PostgreSQL Advent Calendar 2016の15日目の記事です。

この Web サイトは、今年の4月から ASP.NET を Core の方に更新して Ubuntu サーバーで運用しています。実際に運用してみて、IIS よりも Nginx を使う方が便利だと思うようになってきたので、サーバーはすべて Linux サーバーにする予定です。

その際の問題は、データベースをどうするかということです。ASP.NET とはなんといっても SQL Server を使うのが定番です。それで、自分も SQL Server Express を使ってアプリを作っていました。しかし、残念なことに SQL Server が Linux に対応するのは来年の半ばということです。

最近、PostGIS を使いたいという思惑もあって、PostgreSQL を使ってみたら、結構いけていると感じたので、この記事を書くことにしました。まだ、使い始めて1ヶ月なので、今後問題が見つかるかもしれないので最終的どうなるかはわかりませんが、PostgreSQL を使っていこうと思っています。

Entity Framework Core で使う

.NET Core や .NET Framework から、PostgreSQL を使う場合は、Npgsql というデータプロバイダーを使用します。Npgsql には、Entity Framework Core（EF Core）用のプロバイダーもあるので、EF Core で使っている範囲では、SQL Server を使うのと違いは殆どありません。

参考 Npgsql の EF Core 用のドキュメント

例として、Visual Studio の ASP.NET Core の Web アプリケーションのテンプレートで認証を「個別のユーザーアカウント」にした場合に、EF Core が使用されているので、それを PostgreSQL を使うように修正してみます。

Nuget パッケージの追加 Npgsql.EntityFrameworkCore.PostgreSQL を追加します。
Startup.cs の修正以下のように、options.UseSqlServer と SQL Server を使う設定になっているので、

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddDbContext<ApplicationDbContext>(options =>
                options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
    services.AddIdentity<ApplicationUser, IdentityRole>()
       .AddEntityFrameworkStores<ApplicationDbContext>()
       .AddDefaultTokenProviders();
    ------ 以下省略
}

options.UseNpgsql に変更して、Npgsql を使うようにします。

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddDbContext<ApplicationDbContext>(options =>
                options.UseNpgsql(Configuration.GetConnectionString("DefaultConnection")));
    services.AddIdentity<ApplicationUser, IdentityRole>()
       .AddEntityFrameworkStores<ApplicationDbContext>()
       .AddDefaultTokenProviders();
    ------ 以下省略
}

appsettings.json に記載してある接続文字列を修正します。

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=test;Username=postgres;Password=password"
  },
------ 以下省略
}

SQL Server から PostgreSQL を使うように変更するのはそれだけです。

接続文字列に設定したユーザーが、データベースを作成できる権限を持っているユーザーであれば、これでデータベースも勝手に作ります。もし、そうでなければ事前にデータベースを作っておきます。

ただし、それで Run して、ユーザーの登録をしようとするとエラーになります。Data ディレクトリに Migration フォルダーが作成されていて、SQL Server 用のものが事前に作られているためです。それで、それらのファイルを削除してからするとちゃんとしたエラーメッセーが出ます。メーセージの通りにマイグレーションをしてやると正常に動くようになります。

A database operation failed while processing the request.
NpgsqlException: Exception while reading from stream 
IOException: Unable to read data from the transport connection: 既存の接続はリモート ホストに強制的に切断されました。. 
SocketException: 既存の接続はリモート ホストに強制的に切断されました。 
Use migrations to create the database for ApplicationDbContext
In Visual Studio, use the Package Manager Console to scaffold a new migration and apply it to the database:
PM> Add-Migration [migration name] 
PM> Update-Database
Alternatively, you can scaffold a new migration and apply it from a command prompt at your project directory:
> dotnet ef migrations add [migration name] 
> dotnet ef database update

コードファーストで開発する場合は、SQL Server なのか PostgreSQL なのかを気にしなくても開発できると思います。

細かい点でいうと作成されたテーブルをみると下の図のようにカラム名が Pascal ケースになっています。

SQL Server では、カラム名の大文字小文字を区別しないのでPascalケースは便利なのですが、PostgreSQL では、列名の大文字小文字を区別し、SQL文の中の列名は小文字に変換されます。それで、カラム名が「AspNetUsers」だと SQL 文の中では、常に二重引用符でくくって "AspNetUsers" としないといけなくなって結構手間になります。そのまま Pascal ケースで使うのか、それとも fluent API か attributes を使ってスネークケースに変換して使うのか悩ましいところです。自分は EF Core で使うのが主で、生の SQL をあまり使わないので、Pascal ケースのままでもいいのではないかと思っています。

データベースファーストの場合も、SQL Server を使うのと殆ど違いはなく、Microsoft.EntityFrameworkCore.SqlServer.Design の代わりに Npgsql.EntityFrameworkCore.PostgreSQL.Design を追加し、

dotnet cli の場合は、

dotnet ef dbcontext scaffold "Host=localhost;Database=mydatabase;Username=myuser;Password=mypassword" Npgsql.EntityFrameworkCore.PostgreSQL

Powershell の場合は、

Scaffold-DbContext "Host=localhost;Database=mydatabase;Username=myuser;Password=mypassword" Npgsql.EntityFrameworkCore.PostgreSQL

というように、Microsoft.EntityFrameworkCore.SqlServer を Npgsql.EntityFrameworkCore.PostgreSQL に置き換えてやれば、EF model を作成できます。

なお、DbContext のプロパティ名はカラム名を Pascal ケースに変換したものになります。

以上のように EF Core で使う限りにおいては、SQL Server を使うのと差はなく、実際に使っても今のところ大きな問題はでていません。

PostgreSQL を使うメリット、デメリット

SQL Server よりも便利な点としては、where 句で下のように正規表現を使うとサーバー側で処理をしてくれるという点です。( 参照ドキュメント)

var customersStartingWithA = context.Customers.Where(c => Regex.IsMatch(c.CompanyName, "^A"));

まだ使っていませんが、circle 等の幾何データ型、配列型、JSONB型のマッピングは可能なようなので、EF Core でも、これらのデータの取得と更新は可能なようです。

ただし、PostgreSQL の独自の機能を本格的に使うためには、EF Core ではなくて、Npgsql を直接使う必要があり少し手間がかかります。

でも、少し調べてみると、.NET で PostgreSQL を Document Db として使うためのソフトとして Marten というソフトが開発されています。まだ使い始めたばかりですが、結構使いやすい感じです。

PostgreSQL のデメリットといえば、慣れの問題かも分かりませんが pgAdmin よりは、Visual Studio Management Studio の方が使いやすいという点です。

PostgreSQL にするか MySQL にするか

Linux で動作するオープンソースの RDB といえば、PostgreSQL よりも MySQL の方が有名です。

まず、.NET Core 対応という点で比較すると、PostgreSQL の方は、Npgsql の .NET Core 対応はアルファ版が出てもう1年以上になります。その後も開発が進められてきており、かなり安定してきていると思います。一方、MySQL の方は .NET Core に Connector/Net 7 で対応予定で現在開発版が公開されています。

最近の状況では、ZDNet Japan の「PostgreSQL」がスタートアップ企業に選ばれる理由という記事が参考になると思います。以下に最近のデータを載せておきます。

Hacker News Hiring Trends 2016年11月

indeed Job Trends

ASP.NET Core を格安 VPS で使う

2016-10-01T14:41:00+09:00

この Web サイトを Ubuntu サーバーで運用を始めて6ヶ月になりました。その間に特に問題はありませんでした。むしろ、Linux サーバーに慣れてきて、テキストベースの設定が結構便利だと思うようになりました。

それで、格安 VPS を使って、ASP.NET Core アプリを動かしてみました。使ったのは、「さくらの VPS」1G 月額972円で、Webサイトは pp22.net です。サイトの中身は、まだ、このサイトのコピーです。

さくらの VPS の設定及び ASP.NET Core アプリを Linux で公開する手順については以下のページにメモをしています。

pp22.net の Web サイトが動作し始めたので、WebPagetest を使ってスピードテストをしてみました。結果は殆ど差がなく、格安 VPS でも、Web アプリの作り方次第では十分使えることが分かりました。

creativeweb.jp

pp22.net

なお、pp22.net の方がロード時間が短いのは、下部に Google アドセンスの「関連コンテンツユニット」が付いていないことが影響していると思います。

格安 VPS を実際に使ってみて、ASP.NET Core を使う上での課題は、データベースをどうするかということです。このサイトは、ファイルベースなので問題なくインストールできたのですが、通常の Web アプリではデータベースが必須になる場合が多いと思います。

ASP.NET Core と親和性が高いのは SQL Sever Express ですが、Linux 版が出るのは来年の中頃です。Linux サーバー以外に Windows サーバーを立てて、そこに SQL Sever Express をインストールすれば動作に問題はないのですが、格安 VPS を使うという趣旨ではどうかと思います。

Linux で一番使われている RDB である MySQL の場合は、公式ドライバー MySQL Connector/NET がまだ開発中で安定性に問題があります。

そういうことで、現時点で格安にしようとすれば PostgreSQL ということになると思って現在テスト中です。PostgreSQL は、.NET Core への対応を積極的に行ってきたこと、また、JSONサポートも積極的に進めているのでスタートアップ向けにはいいのではないかと思っています。

RDB でなくててもいいのであれば、次のようなドライバーが .NET Core に対応しています。ただし、ServiceStack.Redis の方は、.NET Core 対応についてはアルファ版です。

また、クラウドのストレージを利用する場合は、次のようなツールが .NET Core に対応しているので、主なものは使えるようになっています。

企業の人が知っておくべきインターネット広告のこと

2016-09-29T23:01:00+09:00

最近（2016年9月23日）、大手広告代理店電通が、インターネット広告で、虚偽報告など不正な取引があったことを認めたという事件がありました。

インターネット広告の闇とか書いている人がいますが、インターネット広告に闇なんてあるんでしょうか？単に企業の人がインターネット広告に無知なだけでないのでしょうか。日本では、企業が広告を掲載する時には、ネットメディアと直接取引をあまりせずに、電通など広告代理店が双方の中間に立って取引をしまうため、インターネット広告のことを知らなさすぎなだけではないでしょうか。

広告掲載のチェックについて

インターネット広告には、大きく分けてクリック課金タイプ、インプレッション課金タイプ、成果報酬タイプがあります。

成果報酬タイプは、実際に購入や契約など成果が合ったときに課金が発生するタイプです。これは誤魔化しようがありませんが、トヨタのように実店舗で購入する商品の場合は無理で、EC サイトを運営する企業向きです。

インプレッション課金タイプは、Webサイトの広告枠にバナーを掲載しますというようなもので、表示回数に応じて料金を支払います。

電通の不正があったのは、「運用型広告」と呼ばれるもので、その代表的なものが Google AdWords です。ウェブサイトやキーワード、トピック、ユーザー層を指定して、広告を表示させることができます。料金はクリック課金とインプレッション課金を選択できますが、クリック課金タイプの方が8割ぐらいを占めます。クリック課金の場合は、広告がクリックされると料金が発生します。

確認の方法ですが、管理画面を見れば簡単にわかりますが、広告代理店は管理画面を見せようとしない場合が多いと思います。でも、Google AdWords を使うのであれば、Google Analytics に Google AdWords のアカウントをリンクさせましょう。すごく便利です。

なぜ、Google AdWords が使われているのか？細かい分析が容易にできるからです。インターネット広告に闇があるなんてうそです。

Google AdWords 以外の運用型広告でも、Google Analytics を使えば、Google AdWords を使うほどは細かな分析はできなくても、広告掲載のチェックぐらいはできます。

なぜ不正がおこるのか

なぜ不正がおこるのかの前に、Google AdWords に広告を出すのは自分でもできます。なぜ、それを広告代理店に出すのでしょうか。電通の社員は、大ヒットをする広告を作りたくて入社しているわけで、インターネット広告のような手間のかかる作業をしたいとは思わないでしょう。それは、クライアント企業の広告担当者も同じだと思います。

自分が Google Adsense をしていて、気づいたことの一つが、下の図をみてください、3月はクリック単価が高くて、それも下旬になるほど高くなるということです。（注: 下の図はクリック単価ではなくて、RPM（表示回数 1,000 回あたりの見積もり収益額）ですが、クリック単価の影響が大きいです。）

日本では、3月末が決算なので、予算を使い切りたいか売り上げのノルマを達成したためではないでしょうか。3月に売り上げが増加するのならば理解できるのですが、そうとは思えないので、高い単価で広告を出すのは企業にとっては明らかに損をする行為です。それでもしてしまうのが広告マンです。

テレビや新聞の広告であれば、枠で料金が決まっているので予算の使い切りは簡単だし効果の説明も楽です。しかし、「運用型広告」では、クリック単価を決めて入札をする必要があり、相手のある話なので、自分の思い通りにはなりません。相手より単価が低ければ、広告が表示されないので予算が消化できません。広告の期間中はまんべんなく広告を表示したいと思ってもそれほど簡単なことではありません。

しかし、発注側の広告マンとしては格好をつけたいでしょう。広告代理店から細かい資料をもらうと説明が面倒なので、わかっていても単純な資料しか要求しないということもあるのでしょう。

雇用の流動性が必要

Google は、ソフトウェア開発者の会社です。Google AdWords にも Google Analytics にも API があります。コントロールパネルでちまちまと作業をしなくても、プログラムを書いて作業を自動化することができます。

また、インターネット広告からホームページに流入した見込み客が顧客になってくれるようなホームページを作成する必要があります。

こういう仕事を従来の広告マンに要求しても無理です。それよりも IT 系のエンジニアやデザイナーが向いている仕事です。例えば、マイクロソフトのエバンジェリストになったちょまどさんなんかは最適だと思います。彼女は、漫画家兼プログラマーです。

日本の場合は、企業の方は新卒一括採用で個性のある人をあまり雇用しようとしないし、エンジニアやデザイナーの方も新しいことをやりたがらない人が多いように思います。日本の IT 業界の従事者の待遇が世界で最低だという理由はこういう所にあるんだろうと思っています。

インターネット広告の分野でも、まだまだやれることはたくさん残されているので、チャレンジしてみたらいいと思います。

IT業界の労働環境が最悪な理由を知って正しく行動しよう

2016-09-06T11:51:00+09:00

ITエンジニアがどんな所で働いているか、その業務がどうなっているか書いてみます。そうすることで、なぜ日本のIT業界の労働環境が最悪なのかわかるし、若い人には、自分のキャリアーをどうしていったらいいのかを考えるいい契機になると思います。

ITエンジニアが働いている企業ですが、大きく分類すると、IT企業かそれ以外の企業か、IT企業の場合は、自社開発をしている企業か、受託開発（元請け・下請け）をしている企業かに分かれると思います。それぞれの、業務の内容と特徴は以下のようになります。

自社開発系企業のエンジニア

自社でパッケージ・ソフトウェア、SaaS（Software as a Service）、IT サービス、アプリ、ゲーム等を開発・運営している企業です。例を挙げると Google、Microsoft、DeNA、クックパッド等が当たります。これらは、大企業ですが、自社開発の企業にはスタートアップ企業も多く、新しい企業がひっきりなしに起ち上げられています。

自社開発では、ユーザーに高レベルのサービスを提供するため、常に新しい技術を導入する必要があるので、日々自分のスキルを研鑽していく必要があります。若い世代のエンジニアも活躍している業界であり、若くても自分の意思で自由に仕事をすることができます。その一方で、新しいサービスを企画・制作・運営し、ビジネスとして軌道に乗せるというのはかなり大変なことで、高い能力が要求されます。

スタートアップ企業を除いては、比較的収益性が高い企業が多く、社員の待遇がいい企業が多くなっています。

また、スタートアップ企業というと、安定性に欠けると思われるかもしれませんが、ソフトウェア開発者であれば、スタートアップに失敗したとしても、製品をオープンソースで公開し、ソースを GitHubで公開することで、技術力の高さを実証することができるので、有力企業への就職の道が開かれる可能性が高くなります。したがって、技術力に自信がある人には勧めれる道だし、欧米では優秀な人ほど卒業後就職をせずにベンチャー企業を作るケースが多くなっているそうです、

利点：待遇のいい企業が多い。新しい技術にチャレンジできる。

欠点：高い能力が必要。

SIer のエンジニア

企業や官公庁から依頼を受けてシステム開発をするのが SIer（システムインテグレーター）です。

例えば、みずほ銀行では次期システムを開発していますがそういう銀行のシステムやマイナンバーのカードの発行システムは障害で話題になりましたがそのような企業や官公庁のシステムを注文を受けて作るのが SIer の仕事です。

SIer で代表的な企業と言えば、NTTデータ、富士通、日本電機、日立等があります。

日本の企業は、その企業専用に特化したカスタムメイドのソフトウェアの開発を SIer に発注する傾向が強く、特に官公庁においては丸投げは顕著です。そのため、日本でIT企業と言うと、SIer がまだまだ主流となっています。

しかし、SIer は、開発に必要なエンジニアをすべて抱えている訳ではなく、企業から発注があって契約したとき時に、下請けに分割して仕事を発注します。なんでそんなことをするのかというと、SIerは必要なエンジニアをすべて抱えるとその人件費がバカににならないためで、注文があって必要な時だけお金を出して下請けに仕事をさせます。

それで、SIer のエンジニアは、主に大規模開発において開発者全体をまとめるプロジェクトマネージャーとしての役割を務めます。大手の SIer の社員は、入社後早い時期にプログラミングをするよりも、ユーザーとやりとりしたり、下請をマネジメントする業務を任されるような仕事に就く場合が多くなります。

ユーザーとやりとりして設計をすることやスケジュール、人員を管理することが得意な人には向いていますが、自分でプログラミングをし続けたい人、仕事で新しい技術を使いたい人にはあまり向いていないことが多いです。

利点：会社の営業力が強く社会的な評価も高い。新卒であればプログラミング経験がなくても入社しやすい。

欠点：エンジニアとしての仕事よりマネジメントの仕事が多くなる場合が多い。新しい技術を取得することが難しい。

受託開発の下請企業のエンジニア

下請企業は上記のSIerから業務を受注して開発を行います。システムを作る実働部隊ということになります。下請けにも階層があって、SIer が分割して発注する先が二次請けで、二次請けが分割して三次請けへ発注、三次受けがまた下へという多重構造になっています。

下請企業では、二次請け、三次請けと下請けになればなるほど中抜きが発生し、末端のエンジニアの給料は安く、待遇は悪くなります。そのため慢性的にエンジニア不足になっている企業もあり、入社は比較的簡単です。

開発では、プロジェクトの末端として配置されるので、技術力が低くても作れるようなものになるので、その分仕事を通して高い技術力を身につけられることは少なくなります。また、配属されるプロジェクトが炎上したときには、不眠不休の連日の徹夜「デスマーチ」になることもあります。

利点：プログラミング経験が少なくても入社しやすい。

欠点：労働環境が悪い。新しい技術を習得することが難しい。

一般企業の社内エンジニア

いわゆる社内SEと呼ばれていて、企業内の基幹システムの運用を主要な業務にしているエンジニアが多いですが、製造業の組み込み系のような仕事もあって、企業によって仕事の内容にはばらつきがあります。

官公庁の場合は、専門職を採用しているケースは少ないですが、優秀な公務員は、日経コンピュータ等を読んで、いかにもコンピュータの知識があるかのように話をします。しかし、開発者の仕事ができるわけではないので、開発も運用も SIer に丸投げするケースが殆どです。そして、問題が発生したときには、委託先の責任にしてしまいます。

ベネッセで個人情報流出事件が発生したときも、委託先がどうのこうのといって、ベネッセは被害者のような顔をしていましたが、企業でも、社内システムの開発・運用を子会社に放りだし、子会社は実際の開発・運用を下請けに出すという多重下請け構造で運用しているところが多いです。

日本の企業は、情報システムを合理的に考えて開発・運用行せずに、面倒なことは下請けにさせてしまえという傾向があります。これらのことから発生する問題については、ITProの昨日の記事「1人で作れるものを1万人で作る、日本のIT業界の恐るべきムダ」に詳しく書かれているのでそちらをみてください。

一方で、その記事にもあるように、今後は、「第4次産業革命」を担うITエンジニアの採用が増えてくると思われます。企業の IoT の期待は大きいと思います。

また、最近は OSS の進展が著しく、大手の SIer のノウハウよりも OSS を使った方が遙かにいいというケースが多くなってきています。OSS と SaaS を組み合わせることにより少人数でも規模の大きいシステムが効率的に作れる時代になってきています。

利点：企業による。

欠点：企業による。

まとめ

こうやって纏めると、日本の IT エンジニアの待遇がよくない理由がよくわかると思います。一般の企業や官公庁がソフトウェア開発者を直接雇用せずに SIer に丸投げしてしまうということが最も大きい理由だと思います。

こうなった原因として、SIer が過去に成功を収めたいうような歴史的背景や日本の企業の体質の問題もあると思います。特に、ITエンジニアの職業が変化に対応し続けていないいけないという職業なので、日本の企業の「正社員」の制度になじまないという面も大きいと思います。

現状を直ぐに改善できるとは思っていませんが、「第4次産業革命」を担うITエンジニアのように、現状を打開する道は開けつつあります。

それで、自分の個性や能力にあわせて、消耗してないで行動したらいいと思います。受託開発の下請企業にも、よりましな企業はあるわけで、そういう所への転職も一つの手段です。企業にこき使われてばかりしてないで、もう少し企業を上手に利用しましょう。

消耗してないで行動しよう

2016-09-04T14:20:00+09:00

今年（2016年）の6月に経済産業省から「IT人材の最新動向と将来推計に関する調査結果」が出されていますが、その調査の一環として、「IT人材に関する各国比較調査」が実施され、IT人材の属性や実態について他国との比較をしています。

それによると、IT関連職の人気が日本だけ異常に低い数値になっています。

なぜ、こういう結果になるのか自分なりに分析してみました。

自分がシステム開発を始めて経験したのは、1990年のことでした。バブル景気の頃で、日本は半導体分野ではDRAMを始めとして世界を席巻していました。また、メインフレームの分野では富士通やNECが頑張り、パソコンは NEC の PC-9801、ワープロソフトは一太郎という時代で日本のソフトウェア産業もそれなりには元気でした。

自分はその当時は公務員だったので発注者側で、受託したのは「マイナンバー」のシステムを開発した「大手5社連合」のうちの1社でした。SIer の開発担当者は、優秀で勤勉だったのでシステム開発は比較的スムーズに進んで、内部調整の方にかなり苦労しました。その当時にこういう調査をすれば、ここまでIT関連職の人気が低い数値にはならなかったと思います。

その後のシステム開発がどうなっていったかというと、日本では、SIer のエンジニアがあまりにも勤勉過ぎたので、ユーザー企業の情シス（情報システム部門）がSIerに依存してしまったように思います。

その後、パッケージや Salesforce のような SaaS タイプのサービスを利用すればシステム開発経費はかなり抑えられるという状況になってきたのですが、日本では、そういう方向にはあまり進んでいません。パッケージや SaaS の場合、利用するためには設定やカスタマイズをする必要がありそれなりの技術力が必要になります。また、SIer に発注するようにはシステムをカスタマイズできないので、組織のやり方を変える必要がありますが、そのための内部調整は結構疲れる作業なので、そいうことを嫌ったためだと思います。要するに情シスが面倒なことはしたくなくて、SIerに投げてしまっているというのが実態ではないでしょうか。それにもかかわらず経費節約で開発費は下がっているのではないでしょうか。

経産省の調査からのデータですが、日本だけが受託情報システム開発・システムインテグレーションの従事者が極端に多くなっています。

欧米の企業では、重要だと思う業務はシステムも内製するし、そうでない業務だと業務ごとアウトソーシングしてしまいます。同じ処理をするプログラムを各社毎に作るのは非効率的です。例えば、人事・給与をアウトソーシングしている会社は多いと思います。調査結果ではアメリカはその他IT関連サービスに従事する人が多くなっていますのはそういう理由からです。

日本の SE（システムエンジニア）の仕事は、ユーザーとやりとりしたり、下請や部下をマネジメントすることであって、アプリケーションを作ることではありません。こういう仕事を上流工程といって誇らしげにしていますが、現在では開発ツールが進化してそういうツールを使えば不要な工程にもかかわらず、伝言ゲームをしているようなもので非効率です。海外では、SE という言葉自体が死語です。

前回のブログに書いた10年前のシステム開発の事例では、スタンドアローンに近い環境で運用することを想定したシステムを100人以上が同時に使う環境にそのまま持ってきたのが原因です。よく使う重い処理のキャッシュが全くできていませんでした。その PM は、プレゼンは上手でしたが、プログラム能力は全くありませんでした。SIerの中でも面倒なことは下請や部下に投げているようです。

日本の場合は、ユーザー企業の情シスの能力が低いので、SIerが不要になることはないし、SE の必要性も直ぐになくなることはないと思います。だから、現状に満足している人はそのままでいいと思います。

しかし、給与・報酬に対する満足度は世界最低じゃないですか。効率の悪いところに高い給料は払えないし、最近の日本の企業は、経費削減ばかりに熱心なので当然の結果です。

給与に不満がある場合、冷静に自分がその会社で10年後、20年後どうなっているか想像してみてください。人間には自分だけはと楽観的に考えるところがあるので、10歳年上の先輩、20歳年上の先輩の現実の姿をよく調べてください。

そうすれば、多くの場合は黙っていては、待遇がよくなる見込みなんてなくて、逆に使い捨てられる恐れもあるというのがわかるでしょう。そういう場合には、どうしたらいいのかというと、自分の技術レベルを上げて転職するしかないと思います。転職には次のような選択肢があると思います。

転職エージェント等を利用してよりましな企業に転職する。
プログラミングの能力が高ければ、英語の勉強をして、GitHubでOSSのソフトにコミットして自分の能力を認めてもらい、LinkedIn で新しい職場を探す。この方法は、世界的にはオーソドックスな方法です。ただし、日本では、LinkedIn はあまり使われていないので、コミュニティ活動をするのもいいと思います。
独立して自分で稼ぐようにする。独立すると一人で何でもしないといけないのでソフトウェア開発者、Web開発者のタイプが向いていて、チームで開発する SE や PG は向いていません。SE や PG の場合は、設計からプログラムまで一人でできるように事前に訓練する必要がありますが、そうすることで開発効率は少なくとも3倍ぐらいよくなります。
IT関連の職種に向かないと思ったら、早く別の業種に転職する。年がいってからの転職は大変だということを考えてください。

経産省の調査では、2030年にはIT人材が78.9万人不足するという推計結果になっていますが、実際は効率化で十分対応出来ると思います。今後、人工知能が発達してシステム開発がより効率的にできるようになることを考えれば尚更です。今回のブログは、これぐらいで終わりにして次回以降もう少し重要なポイントを詳しく説明していきたいと思っています。

IT業界は現場が劣化している

2016-09-02T16:14:00+09:00

自分が約10年前まだ地方公務員だった時に、システム開発を担当したことがありました。発注側だったのですが、工期も終わりに近づいた頃、実機でテストするとレスポンスが余りにも悪いので、PM(プロジェクトマネージャー)に負荷試験をして改善するように言ったら、試験をした結果問題はありませんでしたと試験結果をつけて持ってきました。その後どうなったかは長い話になるので今回は省略しますが、このシステムを請け負った業者は、地元企業ではなく、東証1部上場の企業でした。

その時は、運が悪かったぐらいに思っていましたが、マイナンバーカードのシステムで同じような障害を起こしているではないですか。1月始めから不具合が発生しているのに、3月の時点では原因不明。そしてサーバーの台数を増やせばいけるとして、サーバーを追加購入させているのは大したものです。マイナンバーという国の重要施策で醜態をさらすようになっては状況の深刻さが思いはかられます。

参考資料

ITPro マイナンバーシステム障害を総括、「住基ネット安定稼働への過信」が背景に

イザマイナンバー　システムが危機に直面！　障害１カ月連続発生

個人事業税の件をFacebookの「40歳以上ですがコード書いてます会」というグループに投稿したときには、18個もAngryがつけられ、コメントに「いい大人」なんだから騒ぐとどうのこうのと書いた人もいました。10年前の時も業者の担当からはそのように言われましたが、最初に嘘をついておいて、それがバレたら圧力をかけてもみ消そうとし、本来は迅速にすべき原因の究明をしないというのはどうにかしています。

こういうことをみていると、「日本は現場が強い」というのはIT業界では間違いなく神話になってしまっているようです。過去は確かに「強い現場」だったかもしれませんが、ここ20年ぐらいで劣化してしまった所が多いと思います。

そういう現場では、部下や下請けに理不尽な対応をして劣悪な労働環境にしてしまうPMは相当数いるように思います。

現状に満足しているなら別ですが、そのような現場にたまたま配属され不満な場合、特にプログラムやデザインやライティングができる人は、我慢しないで早く転職しましょう。若いときの1年間を無駄に過ごすというのは犠牲が大きすぎます。ちょまどさんを見てください。大手SIerにSEとして新卒入社してコードを書かない事務処理のお仕事に回されたら、たった4ヶ月で転職しています。

エンジニアの場合は正社員での転職も可能だし、また、正社員でなくなることを恐れる人は多いですが、フリーランスでも結構いい給料でいくらでも仕事はあるし、自分のように人に雇われるのが嫌だったら、Google AdSenseやアプリの課金で稼ぐという方法もあります。

今回の記事はこれで終わりにしますが、言うだけだと不親切だと思うで、時間ができたら転職事情がどうなっているかを調べてブログに書いてみたいと思っています。

まだIT業界で消耗してるの？

2016-09-01T16:14:00+09:00

個人事業税が誤って課税される件があって、その時は怒っていましたが、落ち着いて考えてみると、Google AdSense だけで事業者と間違えられるだけの収入を上げられるようになったということを素直に喜ぶべきではないのかと思います。

それに人はよく過ちを犯すものだから気持ちよく許してあげた方が精神的はいいはずです。もちろんミスが蔓延している社会は嫌ですが、ミスを許さない社会は非常に窮屈です。

日本の IT 業界の従事者は、デジタル土方とかいわれ劣悪過酷な労働環境に置かれている人が多く、IT業界離れまでおきています。

しかし、ソフトウェア開発者というのは需要に供給が追いついておらず仕事はいくらでもあるので、本来は収入面でも恵まれ精神的にも気楽な職業のはずです。海外では実際にそういう職業です。

業界がどうのこうのは別にして、少し自分で考えて自分で行動すれば、個人としては消耗しなくてもすむと思います。現に、自分はGoogle AdSense で普通の収入を上げて気楽に暮らすことができています。

日本は窮屈なことが多く、そういう経験を何度もしたことがあるので書きたいことは山程あります。それで、このブログのタイトルをイケダハヤトの真似をして「まだIT業界で消耗してるの？」というタイトルにしました。文章を書く能力では明らかに彼に負けますが、どこまでユーザーを集められるか試してみたいと思います。

AdSense と個人事業税 - 取り消されました

2016-08-28T10:16:00+09:00

昨日、個人事業税の課税が取り消されました。正確には、変更後の額が0円の個人事業税減額決定通知書をもらって、審査請求を取り下げてきました。Google AdSense の場合は明らかに広告業でないので本格的な審査をせずに結論が出たようです。

県税事務所の方もあまり実態がよく分かっていないようなので、広告業に当たるかどうかの自分なりの考えかたを書いておきます。

まず、アフィリエイトサイトは、アフィリエイトで報酬をあげることが目的なので広告業に認定されると思います。アフィリエイトサイトがどういうものかは、アフィリエイトサイトで稼ぐ方法。現在の主流と問題点を見ればよくわかると思います。

日本標準産業分類（平成25年10月改定）（平成26年4月1日施行）の広告業の説明（リンク）の広告業の説明の中に次のことが書かれています。

新聞，雑誌，ラジオ，テレビ，インターネットその他の広告媒体のスペース又は時間を当該広告媒体企業と契約し，依頼人のために広告する事業所

Google AdSense のように広告媒体を利用させるだけの形態であれば明らかに広告業ではありません。

次に、自分でバナー広告枠を作っているような場合は、依頼人のために広告する事業所にあたります。また、以前に少しだけバリューコマースをしたことがあるのですが、バリューコマースでは、自分で広告主を選んで広告主の承認をもらって、そこの会社の広告を自分のWebサイトに貼り付けるようになります。この場合も、文章の読み方によっては、依頼人のために広告する事業所に読めなくはないと思います。

このケースでは、広告業に関係する仕事をしてる時間は短時間であるからWeb運営の方が本業で広告業には当たらないと自分は思いますが、広告業の定義に該当するから課税になるという人がいても不思議ではないです。だから、都道府県によって差が出ても仕方ないと思います。

このようなケースで課税されている場合は、審査請求を出した方がいいと思います。行政不服審査会には外部の専門家もいるので、うまく説明できれば判断が覆る可能性もあります。また、Google AdSense も同時にしていて全部の収入に対して課税されているのであれば、少なくとも Google AdSense の収入部分は減額されます。

Facebookの「40歳以上ですがコード書いてます会」に審査請求のことを投稿した時には、そのグループの投稿では異例と言うべき18個のAngryが付きました。Angryを付けた人の多くは県税事務所へのAngryだったようですが、騒ぐと自分まで課税されるとコメントした人もいて自分の投稿にAngryした人もいたと思います。何かミスを極端に嫌う国民性が出ていて、ミスがあった場合の対応が冷静にできないところがあるように思います。ミスをしないことは重要ですが、誰でもミスをするものだから許すという気持ちも大事だと思います

特に、今回のように判断の固まっていない分野では、審査請求や裁判を通して実例や判例を作っていくことは必要なことなので、不服がある人は黙っていないで審査請求をしたらいいと思います。グレーの部分だと担当者が安易に決定している場合もあると思います。でも、一度決定している以上安易に変更はできないので審査会まで行かないとダメなケースが多いと思います。

ソフトウェア関係のエンジニアの待遇は日本が最低です。特に死にそうになるまで奴隷労働をさせられる国は日本だけだと思います。こういうことになるのは、ミスを極端に嫌う国民性が出ていて、現場の方に極端な圧力がかかるのとそれに対する抵抗ができないのが原因の一つではないかと思います。

また、ソフトウェア関係のエンジニアの職種は世界的には「SE」、「PG」というのは死語になりつつあり、ソフトウェア開発者が主流となってきています。ソフトウェア開発者の場合は設計からプログラミングまで一人でしますが、「SE」、「PG」は開発部隊の一員で兵隊みたいなものなのでそうなるのだろうと思います。