■お仕事情報
カラメルアフィリエイト始めました

July 02, 2009

R25は、あくまでもフリーペーパーを軸とした展開。

メインにフリーペーパーがあって、それに従属する形でモバイルサイトがある。

フリーペーパーとのシナジーが生きなかった、という風に読めるので、これを単体で運営しているモバイルサイトの話に一般化するのはちょっと違うんじゃないかなと思うのだけど、どうなのだろう。

「R25式モバイル」突然終了の「なぜ」（J-CASTニュース） - Yahoo!ニュース

　「R25は、紙媒体・PCサイト・モバイル・リアル広告というクロスメディアとして広告主に提案していたが、モバイルに広告を出稿したいというクライアントのニーズが低かった。モバイルよりもPCサイトに出稿したいという要望が強かったので、今後はPCサイトに資源を集中したほうがよいと判断した」

R25の顧客は、コンビニ動線でモノを買うナショナルクライアントでしたよね。

ナショナルクライアントがそんなにモバイルに力を入れてないというあたりなのかな。
テキストリンクもバナーも地味なモバイル。

やっぱりクライアントの意志決定者の目が、Flashやセカンドライフに目が行くというのは趣向として重要なポイントなんじゃないかと思ったりした。
（そういえば、モバゲーの成功要因にTV CMを流して、意思決定者が名前を知ったなんて話があったけど、モバゲーに出広してるクライアントってどんな会社なんだろう。）

またモバイルの周辺環境が整ってくれば復活するんじゃないでしょうか？
それまでR25本体が頑張ってもらえれば。

PCは、昼休みのサラリーマンがmixiなどを通じて見てるとか、そんなとこじゃないの？！
あとは地方とか。

June 30, 2009

続きは週間朝日で。37ページです。

twitterは理想のインターネットの可能性を示す一つの形と書いてある。素敵。

twitterはボケ、クライアントがツッコミ
ボケとツッコミのプラットフォーム

ニコ動がツッコミのインターフェースになってるのも無縁ではあるまい。

あ、あと関係ないけど、ツイッターでつぶやいたらポメラを譲ってもらえた。

ツイッターと、iPhoneとポメラは互いに補完関係にあると読んでいます。
さっそく明日から持ち運ぶ。モバイルノートは特別な用がなければ持ち運ばない生活。

孫さんがiPhoneを買ったらノートPCを持ち歩かなくなったとおっしゃってたけど、同感です。

p.s. iPhone 3GS上のiMovatwitterが軽くなってすげー快適。つぶやきの入力が楽しい！
（CSS3の角丸ボタンのレンダリングがおかしくなったケド。）
上に貼ってある写真は3GSでの写真です。名刺が撮影できるのが最高。はやくCover Flowでペラペラめくる素敵な名刺管理アプリ出ないかなぁ。
（iMovatwitterは、起動時に一々モバツイに繋げないと、写ツできないのをなんとかしようと思ってます）

June 28, 2009

モバツイ以外にも実運用で回してるEC2な人たちは結構いると思うのですが、参考までに。

モバツイッターがAmazon EC2の人柱をやってくれている

モバツイッターがAmazonEC2に移行しようかなとのこと。 さっそく性能問題にぶち当たったらしいし、ナイス人柱。

前にあるイベントで、EC2を活用されているHeartRailsの方にモバツイの構成をEC2に移転したらどうなるか？みたいな話をお伺いしたら、すぐ8万円/月ぐらいに構成になってしまう、と言われたのですが、大体、どんぴしゃな感じでした。

（追記：なお個人でWebサービスをスモールスタートする場合は、サーバの運用知識がそこそこある前提で、まずは自宅サーバから運用すると良いです。月間600万PVぐらいまでなら、HP ML115G5 + Phenomでこなせるハズなので。その辺についてはまたいずれ書きます。）

■EC2とは？
既にご存じの方もいらっしゃるでしょうから、簡単に。

Amazonが提供する仮想レンタルサーバーです。時間単位で様々なスペックのサーバを借りることができます。

サーバを増やしたり減らしたりの操作は、Amazon EC2の管理画面にコンソールがある他、Javaによるコマンドラインツールが用意されてるので、直接コマンドラインから操作したり、さらにツールで自動処理を行うなどが可能になっています。

■現状のモバツイのEC2側の構成

・Webサーバ　4インスタンス
・DBサーバ　1インスタンス＋バックアップ 1
・ロードバランサー「Elastic Load Balancing」
・固定IPオプション（DBに設定）

でやってます。DNSとか写ツのメールサーバとかは、まだ自宅の環境にあります。また、画像の縮小変換系等は、レンタルサーバーのhetemlを利用させてもらってるので、真性EC2というわけではありません。

この構成で現状の月間PVの見通しは、今月はadsenseが表示されてるページのカウントで月間1,800万PVぐらいですかね。なんか日ごとにPVが増えてるので、重くなるようならさくっとWebサーバを増やすことで対処できます。DBはユーザー情報の永続化とログの保存だけをしてるので、まだ余裕ありまくりです。

外向けに稼働してるサーバ（仮想サーバなので、正しくはインスタンスと呼ぶ）は、すべて「High CPU On-Demand Instances Medium」というものです。

一番安いEC2のインスタンスは、「Standard On-Demand Instances Small」で1時間あたり0.1ドルで、31日計算すると74.4ドルで、これ以外に帯域課金がかかるわけですが、通常の画像とHTMLで構成されたWebサイトであれば、月1万円ぐらいかなと思います。

それに対して、今、モバツイで使っているものは、1時間あたり0.2ドルかかる少しハイスペックなものです。それでも「Medium」とあるとおりスペック的には下から2番目のグレードのインスタンスです。

High-CPU Medium Instance 1.7 GB of memory, 5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each), 350 GB of instance storage, 32-bit platform

メモリが1.7GB
2.5 EC2 Compute Unitsという性能指標のものが2コア入っている。
ストレージが350GBで、32bitのプラットフォーム

サーバの/proc/cpuinfoを見ると、Xeonの2.3GHzと出てきます。
なおOSは、Fedora8を使っています。

OS上ではそういう見せ方をしていますが、本当にXeon 2.3GHz相当の性能が出てるのかは不明です。

感覚的なPhenom 9950BEとの比較では1/3ぐらいの性能というイメージを持っています。（Mediumを3台並べて、１Phenom）
Phenom 9950BEは、AMDのクアッドコアなので、単純にCPUがうまく動いていることを前提にすれば妥当な線ですかね？！

SmallインスタンスとMediumインスタンスは、32bitプラットフォームでOSに互換性があるので、Smallで構築したイメージをMediumで動かすことができます。なので、Smallで足りなければMedium、Mediumで足りなければロードバランサーで横に増やしていくという展開が可能です。

また、DBサーバに共有エリアを儲けて、PHPのセッションファイルの共有を、WebサーバからNFS経由で読み込んでいます。経験上、セッションの共有にNFSを使って、あまり幸せになったことがないので躊躇しましたが、EC2のロードバランサーが、L4レベルのものらしく、Stickyセッションなど同一のWebサーバに振り分けるような処理ができないようなので、モバツイのセッションはシンプルなので、まぁいいか、と。

■モバツイッターの負荷で解決できない問題点
感覚的ですが、前からモバツイの負荷は無駄に重いんじゃないかと思っていました。
PHPで動いているのですが、Facebookで激的にパフォーマンスが改善しました！と言われていたAPCキャッシュというコードキャッシュを有効にしても幸せになってる感がない。

参考： facebookでのAPCの設定 - おぎろぐはてな

現状思ってるのは、僕の何かに問題があるというよりは、ユーザーからのリクエストを受けてから、twitter apiサーバに通信してからもろもろ通信をして、と言うあたりの通信処理の負荷がかなりヘビーなんじゃないかと言う仮説を立てています。
（というかI/O waitでCPU負荷が高くなってる感じなので、そこでしょう）

モバツイは、twitter apiが全然安定しなかった時や、1時間あたりのapi利用数が20ぐらいしか使えなかった時から、ユーザーにはせめてモバツイまではアクセスできるように、と言うことを大前提に作ってきたので、無意味にapiのアクセスをしない貧乏仕様になってるのですが、それでもユーザー1リクエストに対して、必ず1リクエストの外部通信が発生するのは重いんじゃないかと。（更に言うとadsenseへの通信もある。）

要はキャッシュなしのproxyサーバーと考えたら、非効率極まりないのは当然ですね。

ただ、最近ライバルサービスなどの動向や、お使いいただいている方々の声を聞くと、もうちょっとapiへの通信処理を増やして、さまざまな状態を前もって表示していくことが求められつつあるので、よりヘビーになっていくのは免れない状態かも。

ただapiアプリは所詮apiアプリでしかないので、本家と変わらない実装をしてしまうってのは何か違うんじゃないかと思っていて、必要最小限に割り切っていきたいという気持ちはありますけど、何かと比較して使いにくいとか言われるのは、とても不快なのでそこんところは考えていきます。

何故これを書いたかというと、モバツイが必要とするEC2インスタンスの性能要件が、普通のWebサイトよりも不利なんじゃないかなということを言いたかっただけです。

で、次に進む。

■Smallインスタンスの性能が低すぎる。
結論から先に書くと、モバツイ要件換算で、Smallインスタンスは全然、使い物になりません。

運用が始まったらMediumからSmallに性能を落とせるんじゃないかと思って、実際にやってみたら全然ダメでした。

モバツイッターのEC2移転前は、クアッドコアのAMD Phenomを積んだHP ML115のシングル構成だったのですが、昼休み終了前30分と、家に帰る19時台にアクセスが集中してWebサーバよりもルーター(Yamaha RTX1000）が過負荷になって動かないという状態で、要するに人々が移動しそうな時間帯が、いかにもな混雑時間帯だったわけです。

当時3台あったWebサーバの一つをSmallインスタンスにしてみたら、朝7時の段階でもうCPU負荷が高くなって全然反応しない状態になっていました。

Smallインスタンスは、Opteron 1.1GHzぐらいの性能とのことですが、元々、モバツイをOpteron 1.8GHzで動かしていた感覚からすると、もっとショボイんじゃないかという印象すらあります。

ざっくりイメージですが、月間200万PVの動的サイトは、Webのインスタンス1台でこなせるかこなせないかは実験してみないとわからん、という印象です。

サービスの新規構築時はSmallインスタンスで立ち上げて、ある一定のところまで成長したらMediumに移行するなり、ロードバランサーの下にぶらさげるプランを予め立てておくのがよろしいかと思います。

EC2の何が良いって、切り替え時にSmallを落とさないままMedium立ち上げて、Medium側にIPを切り替えても数日分のコストしか発生しないってあたりですね。

そして「今すぐ」それができるってのが何よりもの革命だと思います。実験してみて、やっぱやーめた、もすぐできる。

ビジネスのスピードを落とさないという意味で理想的ですね。
（結構仕事では、その辺苦労してます。）

セミッターみたいな期間限定イベントのサービスを運営したい人も、インフラの維持費がキャッシュフローとほぼ同期して調整できるってのは、かなり理想だと思います。

■データ転送量
モバツイは画像がほとんどないので、転送量は相対的に低いです。

ただ携帯は、HTMLを圧縮して転送することができないみたいなので、HTMLは無駄に帯域を食っているようですね。圧縮転送ができたら1/10ぐらいの帯域転送料金になるんじゃないでしょうか。

今は一日あたり、1GBを超えるぐらいですかね。あんまりよくわかってないです。api側は圧縮してデータ転送できてると思うので、携帯向けは帯域が無駄に食うというのはありそうですね。

ただ、いずれにせよ、サーバインスタンスの料金と比べたら安いもんです。

ヘッダ画像や携帯向けの画像変換のキャッシュデータは、レンタルサーバーのhetemlに置かせてもらっています。また、写ツ画像は、はてなフォトライフと携帯百景と連携して配信されてます。

■EC2のレイテンシ（遅延）の問題
クラウドコンピューティングの問題点の一つに、レイテンシ（通信遅延）の問題があると言われます。これは光ファイバを通じる光の伝搬速度は一定なので、距離が遠ければ遠いほど遅くなり、海の向こうのサーバがある以上は、SSHでのターミナル画面の文字入力は相応に遅延します。

開発者的には、通常のレスポンスにストレスを感じてしまって、EC2遅い、みたいな話になると思うのですが、ただ、Webサーバはどっちにしろそこまでの反応は求められておらず、全体のレスポンスの中で吸収可能なので、全然問題ありません。

というか、そもそもapiのアクセスで海の向こうのtwitter apiサーバへアクセスしていたのですから、モバツイッター自身が海の向こうにあるのは合理的です。

■使い回しIPの問題
EC2は、固定IPオプションをつけなければ、インスタンス起動時に毎度変わるIPアドレスが付与されます。

IPは使い回しなので、こんなことがありました。

アダルトサイト(?)のWebサーバのIPが振られたらしく、その手のサイトを巡回しているクローラーのアクセスがapacheログにあったり、どこぞのロードバランサーの死活監視のアクセスがひたすらapacheログに残っていました。

気持ち悪いのでインスタンスを起動しなおしてIPを変えました。共用IPなので、そんなこともあるので気をつけましょう。

■この構成の問題点
モバツイは、元々はmysqlの全文検索を担うsennaをインストールしたDBを使っていたのですが、現状のEC2環境には置いていません。mediumインスタンスが持つ1.7GBのメモリではsennaのインデックスを持つのはちょっと無理があります。

それなりのデータを全文検索させるのであれば、Largeインスタンス（メモリ7.5GB 0.4ドル/時間）は最低限必要だと思うのでコストの問題が大きくのしかかってきます。

sennaを使うのが、そのサービスのコアコンピタンスになっていないのであれば、利用するのはちょっと難しいですね。

他の全文検索エンジンにおいてもインデックスをオンメモリに持たせるような仕組みであれば多かれ少なかれ同じようなものだと思います。

■EC2の良いところ。
これは既に多くの人が言っていることでもありますし、繰り返しにもなりますが、

１．必要に応じてインスタンスを増やせる気楽さ
２．必要に応じてインスタンスを止められる気楽さ
３．とりあえずサーバを起動して何かやれる柔軟さ
４．例えばストレージが足りない時に、別サーバを立てて落としても時間単位でしか課金されない。
５．サーバ管理がかなり不要になる。

一人でサーバを何台も管理できるし、PVが上がって負荷が高くなったら、コマンドの操作だけでサーバーを増やせるのは素晴らしすぎます。

クラウド時代のネットワーク管理者は、mrtgなど使うツールは変わらずとも仕事の内容は変わってきてしかるべきでしょうね。

とりあえずサーバを1台増やすということが、リモートから操作して10分程度で追加できるってのは革命的だと思います。

例えば期間限定のようなサービスでは力を発揮するでしょう。

セミッターがもしビジネスになったと仮定して、僕がオンラインセミナー運営屋になるとしたら、絶対EC2を活用しますね。

よく広告代理店がキャンペーン用のWebサーバとか用意していて固定IPとかでアクセスするサーバとか持っていたりしますが、固定費を発生することなく、案件に応じてEC2を使い分けた方が良いんじゃないでしょうかね。

Yahoo!ニュースに出たり、TVに仕掛けるような負荷の高い案件であれば、モバツイのような構成でインスタンス増やせば良いんだし。

負荷に応じて、自動的にサーバ台数を調整してくれる、「Amazon CloudWatch」ってのもあるようで。
Amazon EC2で「Elastic Load Balancing」オプションを使って負荷分散/冗長化を実現する詳細手順 - RX-7乗りの適当な日々

■参考文献
参考文献というか、EC2を使うにあたって僕は、ほとんどFDの人のblogしか見てません。
（FDってのは、マツダのRX-7という車の型番の略称。ちなみに僕はアテンザの人）

もう画面開きっぱなしでマニュアルのように使わせてもらってます。

Amazon EC2/S3を使ってみた - まとめ (目次) - RX-7乗りの適当な日々

とりあえずEC2って英語だし、そんなに画面もわかりやすいわけじゃないので、まずは慣れるためにもここから始めるのがオススメです。もしid:rx7のはてなダイヤリーが止まってたら何もできません。

というか自分、マニュアル嫁。

■謝辞
モバツイをEC2に移転するにあたって、相応に初月のイニシャルコストが発生するのと、キャッシュを潤沢に持ってるわけじゃない、ということに対して覚悟をするあたりで、モバツイユーザーの方からいただいた寄付がなかったら、この試みはできませんでした。

移転してしばらくはAdsenseが表示されないなどがあって、一日あたりの運用コストよりadsense収益が下回ると赤字になって、そのまま一ヶ月続いたら、寄付を使い切って、なおかつ、赤字を自分のお給料から補填しなくてはならない。しかも数万単位ともなれば、継続性そのものに影響が出てきてしまいます。

家で運用してるのであれば生活のランニングコストで誤魔化せなくもないのですが、（犬もいるのでエアコンはつけっぱなしだし）、Amazonに支払うお金が毎月、数万円ともなると、そうも言ってられません。

寄付をしていただいた方々には、その辺のリスクを支えていただきました。

特にSixApartの関社長と家入さんには結構な額の寄付をいただきましたが、それでも1ショットの寄付だけで毎月のランニングコストを支えていくのは正直無理で、基本的にはフローに連動した継続的な収益がなければやっていけません。そういう意味で、adsenseの位置を調整させてもらったりして、今のところ、なんとかやっていける流れはできています。

（adsense狩りにあったらモバツイ死亡に直結する脆弱なインフラです。）

■モバツイのミッション
モバツイ始めて、もう止められない感じになっていて、奥さんに言わせれば、サーバ負荷が重いとか、繋がらない状況になると、僕の機嫌が超悪いし、あらゆることをほっぽり出して、こっちに向かってしまうので、改めて思い返すと、今年前半は、いろんなことを犠牲にもしていたような気がします。それなりに金も使ったし。

EC2に移転して、サーバを増やせばPVが増えてもなんとかなると言う流れがようやく見えてきて、なんか安心できました。

安心できたんで、じゃぁ改めてモバツイのミッションって何かな？って考えたんですが、やっぱりモバツイが持つ最大のミッションは、

「いつでもどこからでも、twitterにアクセスしたい時に、必ず繋がること」

かなって思います。

移転する前に日本ダービーと、Java関連のイベントと、WebSigあたりが重なってた日に、土曜の昼間にモバツイが全然動かない状態があったのですが、あれが申し訳なくて。せっかくイベントでtwitterに書きたいと思ってアクセスしてくれたのに繋がらないってのは、ちょっとないな、と。

あれが、EC2移転への決心のきっかけでした。

いずれにせよ、これが個人レベルで実現できたのはEC2様々です。
そういう意味で、クラウドコンピューティング万歳！ってな印象です。

どうせ次の何かがボトルネックになってくるまでのつかの間の休息なんで、iMovatwitter作り直さなきゃとか、モバツイも発展させなきゃとか、気持ちを切り替えて前に進む方向にもリソースを振り向けていきたいです。

##ちょっと宣伝：
一緒にペパボで働きませんか？カラメル開発者募集中です！

June 27, 2009

購入までのステップが少なければ確率論的に購入にいたるケースは高くなるので、LPOが可能性として意味があるのは間違いない。しかし、それがあなたのビジネスに効果をもたらすのか？は別問題で考える。

「ランディングページは1ページ完結が絶対よい」のウソ【ユーザビリティTips】：MarkeZine（マーケジン）

別にLPOに限らず、HTMLメールだとか、blogかもしれないし、リスティングかもしれない。

どこかの誰かが良いよ！と言った、表面的なベストプラクティスと呼ばれる【手法】が、自分たちの目の前のビジネスは当てはまるとは限らない。

人は楽をしたい動物なので、誰かが成功したという手法をすぐ取り入れたくなる癖があるので、世の中には都合の良いように3文字用語が商品として闊歩するわけだ。

3文字用語じゃないけど、アップルがHTMLメールで成功したと言えば、HTMLメールを取り入れ、Dellがtwitterで成功したと言えば、twitterで商品情報を発信したりする。

しかし、よく考えてみると、元々アップルは、ビジュアルに優れたプレゼンテーションをWebサイトで展開してるから、それをそのままHTMLメールに持ってきて効果があるわけだし、Dellだって、もともと、クーポンコードを利用した期間限定値引きのDMマーケティングで成功していたわけ（日本でも２ちゃんねるのDellスレでクーポンコードが出回っていた！）で、それをそのままtwitterに流すことで既存の販売チャネルを流用しただけ、なのではないだろうか。

そもそも、そういうことをやってない会社は、twitterで情報を流すことありきになってしまうかもしれない。もっと基本的な自社のサービスにて、期間限定の商品販売や、今だからこそ大事な情報などを配信するメリットが提供できていないとtwitterでフォローされることは難しいだろう。
（カリスマ美容師の出勤情報とか、キャバ嬢の出勤情報とか、属人的な商売をしてるところは向いてるんじゃないの？）

LPOだって、しかり。

とは言え、じゃぁ批判的な目だけで、目の前のおいしい成功事例に飛びつかないのも、やらない根拠として乏しい可能性も高いので、何かできそうだったら、とりあえずやってみる、というのは大事だろう。

当面の実験としての目標値を置いて、スモールスタートとしてやってみて、うまく行くようなら量的、質的拡大を目指す。そうでなければ、すぐやめて、次のことを考える。

よく言われるPDCAサイクルと言われると大層な話に聞こえるが、

「やってみて、ダメならやめて次を考える」

ということの言い換えで考える。いずれにせよ大事なのは、とりあえずやってみる機動性と目標設定かなとは思う。

もちろん、とりあえずやってみると言っても規模は小さくても質はできるだけ頑張らないと結果でないからそこんとこよろしく。

##ところでここ数日とYahoo!あたりから「iPhone 3GS」ですげーアクセス来てたんだよなぁ。
→この辺から「Yahoo!検索 - iphone 3gs」
iPhone関連の広告出しておけば良かった。何もしてない><

June 26, 2009

久々に興味を持つネタに出会った。（最近、みんな飽きちゃったのか、こういう熱い話、はてブで見かけなくて）

ブログが続かないわけ | クライアントの要望を満たすと、セキュリティ的に問題がある。どうしたらいい？

１．ログインに失敗したときのメッセージ

ログイン失敗時のメッセージに「パスワードが間違っています」と書くと、ログインフォームが、パスワード検証機になってしまうので、そういう表記はやめたいのだけど、お客さんは、利便性を取って、「パスワードが間違っています」と書いてくださいといわれる、という話。

個人的なサービス判断としては、

ログインフォームは、なんとしても「パスワード検証機にはさせない。」

もしパスワードのエラーを出させるなら、５回間違えたら、アカウントロックして、本人にロック解除メールを送るかな。

銀行のサイトほどガチガチじゃないけど、銀行に近いものは実現できる。
これに関しては、そこまでやらないと危険ですと訴えます。

２．パスワードリマインダーに失敗したときのメッセージ

パスワードリマインダーでのエラーで、「メアド登録されてません」て書いたら、メアド登録してることはバレちゃいますね、という話。

僕的には、これはＯＫ

何故登録されてることがバレたらいけないの？

･･･という理由に答えられるサイトか否かで対応が変わるべきだと思います。

それこそソーシャルサイトでメアドバレバレなサイトだったりしたら隠す意味ないし。はてなIDとかもそうですよね。

３． SSL のかかっているフォームの内容をメールで飛ばす

SSLで記入されたフォームの内容をメールのプレーンテキストで送ったら意味ないやん！という話。

個人的感覚ではあまりやりたくないけど、それは感覚的な話でしかなくて、その経路において、何がダメなのかが明確でないならＯＫですかね。

「信用ならない盗聴者がいます」、とかが明確ならば。

僕は、そもそもSSLって何の意味があるんだろう、とか考えたりします。

もちろん商売のコンセンサスとして必要だから、というのがあるので、普通にサーバ証明書にお金出します。

そうではなく実際の重要性としては、情報が暗号化されることよりも、そのサイトが正しいサイトである、ということが保証されることが一番、大事なんじゃないかなぁ。

（こういうのをネットで書くとすげー怒られるかもしれない。）

それであればメールで送ることとは別次元の意味合いなのではないかと。

メールは、信用ならないアーキテクチャである、と言ったところで、メールで送られてる重要情報がいくらでもある昨今、そんなことを言っても通用しないと思うし。

例えば、あれだけ注目され、仕事にメールを使うと公言していた堀江さんのメールが盗聴されましたか？

もちろん事例となる問題があるなら、そんなことしません。もちろんしません。
（教えてください）

いずれにせよ大事なのは、いくら「かくあるべし」を訴えたところで、それが「エンジニアのこだわり」としか相手に捕らえられないなら、いくらこだわっても意味がないし、むしろそういう面でエンジニアは、ビジネスの意思決定者には信用されてないので、もし、本当にマズイんだと思うのであれば、嘆くのではなく、コストも不便も解決する何かを提案することはできないのかな？と思うところです。

ユーザビリティの話はさておき、SSLのメールの話で言うと、ワークフローではなくコストの問題で、メール送信にせざるを得ないのであれば、一旦、入力内容を受ける管理画面をフリーで提供するなり、いくばくかの保守料で提供できるようにするとか、いっそASPサービスにするとかで、メールにログインアドレスが書いたものを送信して、せめてクッキー認証やIP認証で、SSL領域にログインさせる何かを提供するとか、技術で解決したらいいんじゃないかなーと思うわけ。

そこがうまくビジネスになれば、おいしいし。顧客のロックインにも繋がるかもしれないし、と。

ブログが続かないわけ | クライアントの要望を満たすと、セキュリティ的に問題がある。どうしたらいい？

のコメント欄に同じようなことを書いて、解答をいただいているので是非そちらもご覧ください。

なるほど、と、面白いやりとりができて、うれしいです。

ありがとうございます。