これは 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 の継続割引後の料金とほぼ同じです。）

これは 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 を使うように修正してみます。

1. Nuget パッケージ の追加 Npgsql.EntityFrameworkCore.PostgreSQL を追加します。

2. 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();
    ------ 以下省略
}

3. 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

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

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

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

• 低価格 Linux 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 対応についてはアルファ版です。

• MongoDB C# Driver
• ServiceStack.Redis

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

• AWS SDK for .NET
• Google API Client Library for .NET
• Azure Storage SDK for .NET

最近（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エンジニアがどんな所で働いているか、その業務がどうなっているか書いてみます。そうすることで、なぜ日本の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エンジニアのように、現状を打開する道は開けつつあります。

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