SaaSと自社内運用、本当に得なのはどっち?
という記事があって、かつてはASPという提供側にいる立場から、また、利用を検討する立場になって、改めて、お互いの認識に「ずれ」というか「違和感」というものを感じたので、ちょっと、その違和感を書いてみることにした。
この記事の冒頭にも書いてあるのだが、
「情報処理システムの活用において、「所有から利用へ」といった流れが着実に進んでいることは確かなようである。情報処理システムも今後、電気・ガス・水道などといった社会インフラと同じような道筋をたどり、ユーザー企業は自社で情報処理システムをまったく所有しなくなるという見解さえある。だが一方で、ある程度長い目でトータルコストを見ると、「所有」の方が負担は少ないのではないかという声もある。「レンタカーは便利だが、毎日車に乗るのであれば自家用車を購入した方が安上がりである」という例えを耳にした方も少なくないだろう。」
しかし、私は「レンタカー」と「自家用車」よりも、まだ「電車」か「自家用車」か?の方がたとえにあっている気がする。
ASP/SaaSとも、IT系企業が利用者となる場合には、ある程度、外部から見てもその内部の制約、できること、などが想像でき、「レンタカー」と「自家用車」ぐらいの違いにとらえられるかもしれないが、まだまだ、一般的な視点からしてみれば「電車」か「自家用車」くらいの違いがあるのではないか?
しかしながら、この記事にもあるように、「レンタカー」と「自家用車」が例にも挙がっているように、そのような視点でしか違いがないととらえる人が多いような気がする。特に「コスト」「コスト」といっているうちには・・・
「レンタカー」と「自家用車」では、たとえば「ヴィッツ」に乗ったとしても、同じ車なのでそのファンクションは変わらない。
変わるのは、コストと思ってしまっても当然だろう。しかし、「電車」と「自家用車」であればどうであろうか?
基本的に「移動できる」という概念は変わらないが、好きなところから好きなところへ移動するという視点で見れば、全然違う。
「SaaS」と「自社運用」は、この位には素人感覚でも違うと思う。
そうなってくると、単純な「コスト」として比べられるだろうか?
もっと、大切なのは「目的」と「成長戦略」ではなかろうか?
「電車」で生活するということを考えれば、当然、駅前に住むことを前提に生活が成立する。
また、都市部の方が電車での生活はしやすいだろう。
そうなると家賃が高いが、これを、移動というコストに完全に転嫁できると思うだろうか?
移動というコスト以外にも、都市部にいるということは、それ以外にもメリットもたくさんあるのだ。
また、「自家用車」で生活すると決めてしまえば、必ずしも、「都市部」で生活することを前提に考えなくてもよい。
いつでも、気ままに好きな場所に自分で決めて移動したいと考えれば、「電車」での移動はあり得ない。
とここまでは、要するに、契約者側のたちばのみを考慮したが、今度は提供元の都合も入れて考えてみよう。
純粋に、自社の管理コストを「SaaS」か「自社運用」かといえば、「SaaS」がいい!となるのが今の風潮だろう。
でも、それは、「SaaS」を提供している側がより正論を言えるための有利なベンチマークなのだ。
たとえば、自社のサービスの一部をIT化してそれを提供しよう。その際に、「SaaS」の利用がいいのか?「自社運用」がいいのか?
というケースの場合だ。
この時に、「SaaS」の利用は、コストを低く抑えられ、お客により低コストで提供できるかも知れない。
しかし、みんなが「SaaS」を使えば、同じなのだ。そうなれば、それ以外に「付加価値」を求められる。
もちろん、そこで、「SaaS」に頼らない場所で「付加価値」を提供できれば問題ないが、よりITに密着し始めると、
「自社運用」で踏ん張ってきたゆえに、できる「付加価値」というものが注目される可能性もある。
そうなると、いきなり競争のための「初期投資」を求められてしまうこともある。
そして、もうひとつの盲点がある。
「SaaS」を提供している会社がサービスを行いだせば、「競合」になる。
ということだ。
「SaaS」を行っている会社だって、順風満帆でそのインフラ事業だけでとどまっていなければならない理由はない。
より、その業界に特化し、実績もつめれば、そこに参入だってしてくる。
とくに、業界No1などが使ってくれ、そして、実績を積んでくれれば、その信用とノウハウをもとに、その顧客の周辺、隙間を狙ってくる。
すでにブランドを確立した業界No1の会社はそんなに影響はないが、あなたの会社はどうだろうか?
「あの、××と同じサービスが、低コストで提供できます。」
当然、ITを駆使することを考える会社はコストとファンクションで勝負をかけてくる。
そんなときに、それと同じステージで勝負しては勝てなくなるだろう。
これは「SaaS」は使うなというわけではない。
「SaaS」というのを単純に「コスト」という一面だけを見てると、ついつい、「コスト」にいろいろな視点が集中してしまい、
結果として「コスト」戦争に敗れるのではないか?という気がするのだ。
あることをしたいが、そこのコストを捻出するために、「SaaS」を利用してコストを浮かしてそちらに回すくらいの気持ちが必要なのではなかろうか・・・・
つまり、コストワールドからの脱却を余儀なくされる時がやってくるのだ。
たとえば、テキストエリア(TextArea)などを入力しているときに、今から入力しようとする文字の候補などを表示したい場合があるのではないだろうか?
コードを書いていれば、よく使うあれだ。
これをFlexなどのTextAreaでも使いたい。こんな感じだ。

さて、そのためには、現在のキャレットの位置、つまり、文字の何番目という位置情報から、
その位置が、x座標、y座標でどこにあたるのかを求める必要がある。
このためには、TextFieldの
getCharBoundaries(charIndex:int):Rectangle
を使用する。
これを使って、x,y座標を求めて、そこにListのPopupを表示すればOKというわけだ。
ただ、TextAreaなどで使用したい場合には、内部で使っているTextFieldを触るすべがない。
したがって、継承クラスなどを作って、
textField
のプロパティ(getter)としてアクセスすることになる。
これはちょっと、面白い話だなーとおもったので・・・・たまには・・・
なぜか、新しいものを取得しようと思えば思うほど、古きにたどり着く。という事を最近実感しており、
そのためか、C言語も真面目に始めたのだが、何かC言語関連でおもしろい本がないかなーと探していたら・・・・
という本を読んでいました。
ただし、今回はプログラムとも、技術とも全く関係がありません。
この本の中で、余談として、赤ちゃんが「ンマ、ンマ」と声にしているのを聞いて、
ほんとどの国がそれを「お母さん」としたと。
ママ、ママン、マーマと、
しかし、日本だけ(たぶん)は、それを「ご飯(マンマ)」ととらえたと・・・・
日本文化は携帯などでも「ガラパゴス」って特殊扱いされているけど、
単なる置かれている環境の違いじゃないんじゃないかなー
と、この話を聞いて思ったりする。
ある意味、国際社会でKYとしての素質を日本人はDNAレベルで持っているということじゃないかな。
ただ、こんな、ちょっとした視点の違いってグローバル化されていけば、いくほど、面白いんじゃないかなー。と・・・
右向け右の社会で、左を向きましょうということだ。
それが、「ガラパゴス島を立派な観光ビジネス」に仕上げることになるんじゃないかな。
以前、「指定したドメインのメールを受け取る」という話で、
個別に指定したドメインは自分で受け取ってしまうということをやったが、
これの応用版として、「指定したドメイン以外はすべて自分で受け取る」
これは、よく大量メールの配信テストなどをしているときに、適当にメールアドレスを作って、
仮に、本当にそのドメインがあったとしても、外にメールが飛ばないということができる。
このような完全一致ではなく、あるパターンに一致したときには・・・となると、
設定に正規表現を使う方がよりスムーズだ。
そのために、Postfixで正規表現が使えるかを確認しよう。
確認方法
#postconf -m btree cidr environ hash ldap nis pcre proxy regexp static unix
のように、regexpやpcreが表示されれば問題ない。
(これからの例はregexpなので、pcreを使う場合の正規表現は別の形になるかもしれない。)
では、具体的に、あるメールアドレスがPostfixはどのように処理されるのだろうか?
http://www.postfix-jp.info/trans-2.2/jhtml/transport.5.html
を見ると、どのようにメールの配信方法が決定されるかがわかる。
以前は、このmydestinationを使ってしまったので、
非常に簡単にまた、直観的に設定できた。
今回は、virtual_mailbox_domainsを使って、
その設定に正規表現を使うようにする。
まず、正規表現を使う場所を決める。
つまり、どの処理から分岐をするか?ということだ。
そこには、そのまま、virtual_mailbox_domains に、 virtual_mailbox_mapsを使うことにした。
まず、以下のファイルを作成する。
/etc/postfix/virtual_mailbox_maps.regexp
/(.*)/!/(coltware.com)$/ /dummy/Maildir/
(ファイル名にルールはありません。)
これで、coltware.comというサーバ以外のサーバは、/dummy/Maildir/というディレクトリにMaildir形式で保存される。
自分サーバ向けは、mydestinationで指定されているので、このように、すべてに一致(.*)で、
かつ(coltware.com)以外ということにした。
本当に設定する前に、正しく正規表現が動くのかテストしましょう。
postmap -q "テストする文字列" regexp:/etc/postfix/virtual_mailbox_maps.regexp
で、結果(/dummy/Maildir/の文字列)が返ってきます。
もちろん、coltware.comのドメインの場合には、何も帰ってきません。
では実際の設定です。
virtual_mailbox_base = / virtual_mailbox_maps = regexp:/etc/postfix/virtual_mailbox_maps.regexp virtual_mailbox_domains = $virtual_mailbox_maps virtual_uid_maps = static:89 virtual_gid_maps = static:89
ここで、virtual_mailbox_baseは、先ほど、/dummy/Maildir/と指定したときに前に、このパスがつくのだが、
私は設定時に今後も完全にパスを指定したかったので"/"としました。
また、
virtual_uid_maps = static:89 virtual_gid_maps = static:89
は、メールファイルが保存されるときの、uidとgidなので、好きなuid,gidを設定してください。
で、この後に、postfixを再起動してください。
とこのようにすることで、自宅内にたてたテストメール配信サーバも、間違っても自分のサーバにしか飛ばないというわけです。
また、いろいろと正規表現をカスタマイズしていくことで、いろいろと出来てきます。
また、今回は、virtual_mailbox_domainsを使いましたが、あるドメインの配信先をsmtpからlocalに変えるという概念のほうが、よりわかりやすいので、transport_mapsを使ってもいいのですが、自分宛にメールが送られてから、そのメールをどのようにするか?
という設定を含めると、自分的には面倒なので使いませんでした。
余談:
これは本文とはまったく関係がないのですが、クラウドなどでよりサーバの設計はアプリケーションエンジニアのほうに仕事が移ってくるでしょう。
それに、このような要件は、サーバ構築で発生するわけではなく、機能定義で出てきます。
したがって、アプリケーションエンジニアがミドルウェアがどの程度までできるか?ということを把握することは非常に大切です。
また、これらの要件がまっさらから作ろうとすると非常に多くのコストがかかってしまいます。
クラウド時代の到達とともに、アプリケーションエンジニアが、サーバ構成・システム構成から設計できることは、スピードとコストを最大限にするためにも、今後ますます重要になってくるのではないでしょうか?
airxmailを使っていただいている方からのご協力もあり、いくつか修正することにしました。
http://code.google.com/p/airxmail/downloads/listの
r44が最新になっています。
1.送信が成功したときにSMTPEvent.SMTP_SENT_OKのイベントを発行するようにしました。
これを使えば、現在、x/n送信中なんて感じのだせるようになると思います。
2.Socket周りのエラーイベントはもともとあったイベントを使用するようにしました。
これは、おもに原因の切り分けのためです。SMTPやPOP3で通信していると、TCP/IPレベルでのエラーなのか、
SMTP/POP3のプロトコルレベルのエラーなのか、エラーイベントで揺れがありましたが、これらを統一するようにしました。
3.TLS/SSLが必要にも関わらず、Plainな通信を使ってしまうと固まってしまう問題の修正。
これは、ステータスがかえってくるのをずーとまってしまうという問題がありましたが、接続時にTCP/IPで接続ができた後に、
プロトコル上でのサービスの準備完了になるまでのタイムアウト値(現在5秒)を設けました。
4.接続のときに何か間違い(ID・パスワードの間違いとか・・・)、再接続したときに、以前のコマンドがクリアされずにいたために、
再度、処理が進まなかった問題を修正しました。
とこんな感じで、修正しました。
エラー周りなどは、もともと、あるアプリケーションのためにライブラリ化したので、その使い方をこえると、
考慮されていなかったり、ポリシーがぶれていたりするのですが、やはり、第三者の目が入るのはいいです。

