1年近く更新してなかった
なんか緊張するし、一段とまともな文章が書けないし、いろいろ疲れた。
公開する以上甘えるのはよくないが、多少はお手柔らかに ＞読者（未来の自分含む）
P-oneカードの1%「割引」について
今回は敬体で。
先日、高還元カードスレを見ていた所、悲しいお知らせに出くわしました。青ぽねカード発行されてまだ1回も引き落とし日が来てないのに(;´Д｀)
上記変更日以降は、ご利用代金明細書のご利用計上月ごとに、「1回払い」「2回払い」「ボーナス一括払い」を合計したご利用金額が150,000円を越える分につきましては、１％OFF適用外とさせていただきます。
上記変更日というのは「2009年3月1日 ご利用分より」になります。単なるサービスの改悪はよくあることですが、ここまでわかりやすく利用額を抑える方向に利用者を誘導するなんて、まさに「なに かんがえてんだ！」って感じです。意味不明なので、上限金利が下がったからというまっとうな理由は脇へ置いて、別な理由を推測してみることにしました。
以下、間違ったことを書かないよう努力を行っていますが、会計や財務については素人なので精度は読む人側で判断して、突っ込んだりしてみて下さい。話のネタ元？は最近よく拝見している、「雄牛と熊と欲豚と」さんの記事です。
特に3つ目のが重要で、そこまで読めばすでに修了です。実は、私は「単純年率換算だと12%」ってところがよくわかってなかったりします。
今回の「改悪」は平成21年2月期中間決算説明会資料（PDF）の23枚目「業務効率・コスト構造の改善に向けた取組み」に、「「１％割引」上限金額の設定による収益・費用バランスの適正化」とあるのでこれが実行されたということなのでしょう。
まず結論ですが、「1%割引」にかかるコストが大きかったため、「改悪」されたと考えています。これが「1%割引」ではなく良くある「1%ポイント」だったら、いずれ「改悪」対象になっていたかもしれませんが、今回の対象にはならなかったかもしれません。（ここでは1%割引とは別に0.3%程度付くポケットポイントの方は除外します。）
「1%割引」と「1%ポイント」では性質が異なるのではないかと思うのですが、日経トレンディで定期的に行われるカード特集をみても、他の高還元カードと比較される際にあまりその辺が考慮されていないようです。これに着目します。ポイントと（引き落とし時の）割引、利用者から見たメリット・デメリットは次のとおりです。
- ポイント（ポイント貯めてキャッシュバックするカードも基本はこっち）
- 貯めて交換すると現金換算でお得な場合がある（マイルでの特典航空券等）
- 貯まるまで使えない。貯めている間は無利子と失効の恐れあり。
- 割引
- 貯まるまで待たなくて良い。割引分は利用者の銀行口座に残るので利息が付く。
- 割引分を気づかないうちに浪費してしまう。利息しか付かない。
会計に詳しい方ならもっと明確な違いを示せれるのではないかと思います。
利用者の「お得」はカード発行企業側の「コスト」と考えられます。つまり、現金・商品に交換するために必要な最低ポイント数やポイントの有効期限によって取得から交換までの期間や未使用率が変わる（うまくやれば現金化のタイミングを操作できる）ポイントと、毎月確実に利用者から入ってくる金が減る（現金化されてしまう）割引とでは、後者の方がカード発行企業側のコストが相対的に大きいのではないでしょうか。
（あくまでも、ポイントと割引とを比較したときのコストです。また、ポイントに関する会計制度も変わってきているようなので、そのうち（すでに？）、ポイントならコスト小とは言えなくなるかもしれません）
その結果、ポイント還元ではよくある「1%」ですが、ぽねでは割引であるためより大きな負担となり、「カイゼン」対象となってしまったのだと推察されます。このコストは、1ヶ月に15万以上使ってくれる優良利用者が減るデメリットと比較しても、ポケカにとっては大きかったのでしょう（実際は、一月当たりでは15万円を超えない利用者が多いのかもしれませんが）。
今後の流れですが、楽観的に見ても上限金額以上の利用額については「1%割引」の復活はなくせいぜい「1%ポイント」の形で復活するという方向を予想しています……ちょっと残念ですが。また、大規模なポイントのデフォルトでも起こらない限り、今後も割引のお得さは広まらない気がします。
蛇足。昨今の短期金融市場とやらの荒れ模様から、利用額が大きくなっても「1%割引」の影響で資金ショート？する危険が増すなら元も子もないので、わざと利用額を小さくする方針を取ったのかと思ったりもしたのですが、実施日が少し先なので、その考えは却下しました。
蛇足2。青カードを手に入れるのにあわせ、優待でポイントをもらってカードで貯めたポイントの失効を少しでも防ぐことを目指し、優待権利日が過ぎてから（笑）、100株買ったりしてます。絶賛評価損。
10/16追記。記事をアップ後にJaneの未読を消化していたところ、クレジット板のスレッド「P-one/ポケットカード66」にて、ある勇者が15万円制限の理由についてポケカから得たという回答を読みました。利用者もポケカも持続可能でお得な関係が続くとよいな、とわざわざ書くまでもない感想を持ちました。
いっそのことパブコメでは「キャッシュ」という言葉を使わない方がよいのではないでしょうか？
要旨。「キャッシュ」という言葉は、広い意味を持つ言葉になってしまっているので、議論が混乱したり誤読されることを避けるために、今回のパブコメでは使わないことを推奨したい。
実際のところパブコメ関連の話題はほとんど追っかけてない上、とどめに本題である「キャッシュ」という言葉に関する論争もウォッチしていた当時の記憶がさっぱりないので勉強中……したがいまして、こういうことを書く資格はないのですが。
以下本文。
はてブ経由で「僕があまり歓迎しないパブリックコメントの類型(1)「キャッシュは複製だ」 - ものがたり」を読んで、ちょっと混乱しました。（以下、意見そのものに対して賛成反対とかいうのではありませんことをご了承ください）
だがまあ、僕が個人的に思うことは書いておきたい。最初の例（まあ最後になるかもしれないけど）は、「YouTubeみたいなキャッシュは複製だが、そこまで違法化するというのには反対」みたいに主張してしまうことだ。
YouTubeみたいなキャッシュ？ YouTubeのキャッシュっていうと負荷分散か何か？ どっかの検索エンジンが動画までキャッシュするようになったのか？ …という具合に。
結局、リンク先の9月27日の日記「キャッシュをTemporary Internet Filesから」という言葉を見て、「ブラウザ（IE）のキャッシュ」を意味するのだとわかりました。
こんな混乱をする人は少ないかもしれませんが、これを機会に考えてみました。私の思いつく限りでは、「キャッシュ」という言葉は下記のように複数のものに対して使われ、その意味もさまざまです。
- CPUの「キャッシュ」メモリ
- HDDその他に対して、PC本体やドライブ側で持っているディスク「キャッシュ」
- DNSにおける「キャッシュ」サーバ
- Squidなどプロキシサーバ・ウェブキャッシュサーバの持つ「キャッシュ」
- ブラウザの「キャッシュ」
- Googleなど検索エンジンが用意している「キャッシュ」
- ウェブ魚拓などが生成する「キャッシュ」
- Internet Archiveに保存されている「キャッシュ」
ウェブ魚拓は最近はQ&Aにあるように「引用」と「キャッシュ」を明確に分けて扱っているようです（かつてはここまで明確にしていなかった記憶があります）。また、Internet Archiveにあるサイトのスナップショットを「キャッシュ」と呼ぶ人もそれなりにいるようです。
文中では「一時的蓄積」を「キャッシュ」として話を進めているように読めます。ですが、Internet Archiveにあるものを「キャッシュ」と呼ぶ人々にとっては、その前提は成り立ちません。Internet Archiveはサイトのスナップショットを一時的でなく恒久的に保存するからです。ウェブ魚拓についても関連するはてブやそのコメントを見ると「キャッシュ」という言葉に、恒久的な保存という意味を込めている人が散見されます。
したがって、「キャッシュ」とは結構面倒な言葉なのです。文脈から意味が定まるのならいいのですが、個人的には既に言葉だけが飛び回って、都合よく解釈されてしまってるように思います。ま、「文脈から意味なんて判断できるだろ。そんなのてめえの杞憂だよ。m9（＾Д＾）ﾌﾟｷﾞｬｰ」と誰かが言って下さればそれでよいのですが。
次に、「キャッシュ」という言葉については結構前に話題になっていたことを思い出したので、ぐぐってみました。高木浩光＠自宅の日記さんの記事ですので皆さん一度は読んだことがあるはずです。
これに関連して児童小銃さんが下記の記事を書かれました。
- 2004-09-13 - 児童小銃（「Google の「キャッシュ」:意図的な誤用か?」と「Google の「キャッシュ」:透過性は合法キャッシュの要件か?」）
- キャッシュとミラーの公益性
さらにトラックバックをたどればまだまだあるのですが、日記を書く体力が切れてきたのでこの辺で止めます（ごめんなさい）。当時の記憶が薄れてるので、わたしはもう一度読み直そうと思います。
今の段階では、表題を見るだけでこの問題は根が深いように感じられます。
なんだか発散してきたのでまとめてしまいます。
（既に決着済みだったりすると恥ずかしいのだけれど）いずれ、「キャッシュ」について白黒をつけるときが来るのかもしれないけれど、今回やる予定でないなら、「キャッシュ」という言葉を使わないことで、「キャッシュ」論争に力を奪われずにすむではないかと思いました。
それに、やっぱり「キャッシュ」という言葉は話す人聞く人によって異なる意味を持つ言葉になってしまったので、それを使わずに説明を書いたほうが、誰が読むのかわからないパブコメでは誤解を生むことが少なくなるはずです。
Firefox高速化記事と、混乱する批判
かつて、私も批判記事を書いた側だったりするので、反省しながら書いてみる。
- 元記事
- オンライン快適仕事術 - 重くなった Firefox 2.0 を劇的にスピードアップする13の方法
追記。続編があった。 - ぶくま
- はてなブックマーク - オンライン快適仕事術 - 重くなった Firefox 2.0 を劇的にスピードアップする13の方法
- めたぶくま
- はてなブックマーク - はてなブックマーク - オンライン快適仕事術 - 重くなった Firefox 2.0 を劇的にスピードアップする13の方法
- 参考文献類まとめ
- makogaの日記 - HTTPのパイプラインについてのメモ
元記事にあるオリジナル記事は読んでない。
元記事コメント欄もぶくまコメント欄も、何が問題なのかということに対して混乱しているように思う。
とりあえずぶくまで目立つところとして取り上げれば、
2007-04-15現在、他人に迷惑をかけるので禁じられている設定を推奨しているので、このページの情報を用いてはいけない。
「他人に迷惑をかけるので禁じられている設定を推奨している」とあるけれど、それはどの設定の事なのか？
外していたら申し訳ないが、元記事の1.Pipeliningで、「一度のパイプライン処理で送信する最大要求数」（network.http.pipelining.maxrequests）を大きくする事を紹介した事に対して批判が出ているように読める。自分の知っている限りでは、この項目に対して批判が出たのは初めてのことのように思われる。
「はてなブックマーク - タグ HTTP同時接続数」のタグ名で明らかなように、かつての批判はFirefoxで言うなら"network.http.max-persistent-connections-per-server"や"network.http.max-persistent-connections-per-proxy"などを変更し、HTTP同時接続数をRFC2616で「すべきでは無い」とされている値をこえて増やす事やそれを安易に推奨することに対して行われ、代替案としてパイプラインを有効化することを推奨していたはず。
有効にすることと、有効にしてかつ最大要求数を増やす事の間には差があることはわかるけど、批判コメントを残す人たちが論点ついてどこまで混乱せずに意識しているのか、コメント欄をぱっと見しただけではわからない。
（……と思ったら、ブクマからたどれる2006年12月のP O P * P O Pの記事では、Firefoxでは一度のパイプライン処理で送信する最大要求数（network.http.pipelining.maxrequests）を増やすこと、Internet ExplorerではHTTP同時接続数（MaxConnections PerServer）を増やすこと、と別のことを推奨しているのに気付いた。当時書かれた、「◆F99a.q8oVEの日記 - network.http.pipelining.maxrequests は8より大きくしても無視されます」のコメント欄を見ると、「Firefoxのほうは別にいいんですよ。IEのほうが問題。」とある。分けて考える人のコメントをまとめて考えてしまうことで混乱がはじまったのだろうか？）
（さらに余談として、パイプライン（network.http.pipelining）を有効にすると一部サイトへの接続が酷く遅くなることがある。例えば、「クレジットカード会員の方TOP、Vpassサービス：三井住友VISAカード」など。材料不足なので強くは主張しないけど、お金関係でパイプライン非対応っぽいサイトが残っている現状では、パイプラインも「保守的観点からは設定しない方がいい」項目なのかもしれない。今さらながら、デフォルトで無効化されていることに納得できてしまったので、私も結局無効にした。同時に、かつて安易に勧めたことを、間違いとして訂正します。）
話を戻して、「HTTP同時接続数」を増やす事が批判される理由（RFC2616とか）は理解できるのだけど（自分も増やすのは反対派なので）、今回の元記事で推奨されている、「一度のパイプライン処理で送信する最大要求数」を増やす事を批判するだけの理由は見つからない。今回の元記事を批判する人々はどの辺りを根拠にしているのか？
network.http.pipelining.maxrequests=32はやりすぎのように個人的には思うし、8より多くしても無効らしいけど、32がやりすぎだと主張するだけの材料は見つからない。
以上かな。
その他のレンダリング関連の設定と思われる項目の是非についてはシラネ。
そろそろ、「ブラウザ高速化」タグで過去からの記事をまとめてぶくま、または、リスク面にも過不足なく触れた「ブラウザ高速化」まとめサイト作成をしてくれる勇者が欲しい。チューニング - Mozilla Firefox まとめサイト辺りを使って上手くまとめてくれないかな？ 手軽な方法でWebアクセスを高速化したい気持ちはあたりまえの感情だと思うので、鯖管・ユーザー・開発者他関係者が上手く折り合いをつけて高速化できるなら、それに越した事は無い。
