「次」が指す日本語の問題

togetter.com

およそこの問題は仮にDを選んだ人もよくよく聞けば「あ、そうだよねやっぱり」と思う話なんじゃないかと思っていて、新しい用法が出来たとか意味を取り違えているかとかではなく、うっかり問題誤認、だとは思うんですよ。

というのも、「次」「高い」というワードだけでうっかり「カウントアップしていく数字の次」という風に捉えちゃったと思うんですよ。

日本語の「次」、という言葉は何かを評価した結果、～に次ぐもの（次点）という意味で使うことが多いと思いますが、集団があり、向きが発生した場合は必ずしも評価を表すのではなく、並んでいるものの順序を表すことになりますよね。これも厳密に言うとまだ原義から外れてはいないんですが、例えば電車に例えると、（次の電車問題ってのもありましたが）乗ってない人が電車を待っている状態の次の電車というのは「後ろ」のことを指しますし、電車に乗っている人が「次の駅」というと時制的には未来（後ろ）を指す一方で、方向としては前を指す場合がありますよね。プログラムで言うところのリスト構造の「next()」で言えば、リストの次の項目（後ろ）の項目を指す一方で、リスト自体は照準にソートされていたり降順にソートされていたり、ソートされていなかったりするので、プログラムの制御上の「次」と、処理要件としての「次」は必ずしも評価とは合致しないものになりますよね。

言い換えると、ソート順と順列の向きについての誤認、というのが次に高い人問題の本質なのではないかと思います。意味が違ったのではなく。設問が順列づくりに誘導的、というのも要素として大きいんじゃないかと思います。だから、今回Dを選んだ人が日常的に次の意味を転倒して使っているとはあまり思えないし、理由を述べているのを読んでも順列の意識が高いですよね。その事自体はそんなに変な感覚ではないと思っています。

多様性の時代に労働者を糾合するのは容易ではない

例の、労働組合平和活動問題の話です。

ブコメにも色々書いたけど、一昔前だったら「給料上げろ！現場改善しろ！」というのは何をおいても実現すべきことであり、そのために手段を選ばなかったとしてもそれ以外のことはどうなってもよい、という意識があったと思うんですよね。当時の労働者でない自分として確信を持って言える話ではありませんが、高度成長期の中で、労働争議というのは自分の人生にとっても重要な活動であったことは間違いありません。

でも、価値観の多様化が進んだ平成の世の中において、組織に迎合しないこと、他人の価値観を認めること、裏返しで自分の価値観を尊重してもらうこと、が社会にとっての非常に重要なファクターになり、それがインターネットの時代によってより加速することで、「仕事が人生じゃないでしょ家族をもっと顧みよう」みたいなのを始めとした、働くことに対する価値観も多様化してしまったわけです。これは、いわゆるブルーカラーが減ったということにも起因しているでしょう。ホワイトカラーがブルーカラー的な働き方をさせられているとしても、そこは厳然としてホワイトカラーの仕事という意識付けはなされている。ホワイトカラーの仕事って、集団でサボっても単品では損害出にくいし、圧力がかけづらい仕事でもありますね。

そんな世の中で、「自分に関係ないどころか正反対な運動に邁進する労組や労組を支持勢力とする政治勢力」にコミットできる人がどのくらいいるのか、というのがこの問題の重要な点だと思うわけです。かつては「待遇改善」というワンイシューだけコミットできればその他はどうでも良かった。今は、そこで運動することが自分の大事なものを脅かすのであればそれが待遇改善に繋がったとしても意味あるのか、と考える人がかなり増えているんじゃないかと思います。

価値観の多様化ってのがリベラルが集団化するのを拒む性質があるだろうというのは以前も書いていますが、この問題はまさにそこがポイントなんだろうと思うんですよね。そもそも「労働者層」という意識がない。

平和活動にしたって、手段を選ばない感が悪目立ちしているじゃないですか。そういうことをする勢力にコミットすることに躊躇する、というのは平成の価値観においては割と当たり前ですよ。とにかくお賃金のためならそんなこと関係なく運動します！っていう人が少なくなり、教育の成果として理知的な考え方をする人が増えているのであれば、そういう人たちを糾合するのに必要なのは極めて知性的な活動である必要があるし、手段を選ばないとダメだとは思うんですよね。与党も無茶苦茶だがお前らも無茶苦茶、となった時点でダメかもしれない。理屈の通らない活動に筋を通していくためには「いいから労組にはいれ」の旧弊から改めないとダメかも知れないけど、そういう改革を行ったところで非常に弱体化するかもしれないですよね。

もう少し透明なシステムの組織にしていかないとこのまま弱体化し続けるのではないかなあ。労働改善より退職転職支援とかのほうが今風かもしれませんし。

IDお預けとウケトルの問題点について

そもそもマネーフォワードとはなんだったのか、からだと思うんですが、ウェブサービスというのがまだ一対一のBtoCだった頃に流行っていたのはアカウントアグリゲーション「ツール」でしたよね。資産管理の枠でいうと、MSが出していて証券会社や銀行がカスタマイズして提供してたりもした、MoneyLookがそれなりにシェアを持っていたと思います。これはあくまで「ローカルで動いてローカルにデータを保持する」普通のアプリで、ローカルのアプリに保存した各サイトのID/PASSでスクレイピングを仕掛けるものでした。当然ですが、ターゲットのサイトのデザインが変わるたびにアプリのバージョンアップが必要なのがめんどい。

マネーフォワードが最初に登場したときに言われたのが「え？ID/PASSを預けるの？それダメくね？」でしたよね。ぽっと出のベンチャー企業に銀行使うためのIDなんて預けられるかよばーかばーかと思っていた人が多いんじゃないでしょうか。とはいえ利便性とリスクは表裏一体ですから、リスクと利便性を天秤にかけ…るどころかリスクの存在を無視して使っている人は結構いたんじゃないかと思います。なにぶん、スマホの時代になって、ID/PASSの重要さというのが相対的に薄くなっているなかで、飛び抜けて重要な金融機関のID/PASSだからといって特別視しない人が増えたとも言えます。良くない傾向ですね（そもそも金融機関の認証が旧態然としているのが良くないわけですが）。

マネーフォワード自体は世間の評価はさておき、（少なくとも志向において）不真面目な会社ではなくて、懸命のロビー活動によって銀行のオープンAPI提供を決定づけたという功績については素直に讃えたいと思っているんですよね。こういう人たちがいないと腰の重い日本のお役所は動きません。結果として、「ID/PASSを私企業に預ける」などということなく、金融機関のデータをクラウドサービスが集積できるようになった、というのは良いことだったと思います。

API連携の話ですが、オープンAPIと言っても、どこの馬の骨にも自由に使わせる、というわけには行きません。そもそもスクレイピングに関してはどうかというと、アクセスを受けるシステム側からすると、「本来月一回ログインしてくるかどうかだった顧客のアカウントがPFMから定期的にアクセスされる」という状態になりますから、下手すりゃ威力業務妨害に近いわけです。特に地銀以下の銀行なんて「アクセス数による従量課金なベンダーのASPインバンシステム」を使っていることが多いので迷惑千万なわけですね。PFM側のアクセスはおよそ一定のIPアドレスから来ることになるので、場合によってはそのアドレスをシャットアウトすることだって検討しちゃいますよね。ということは、勝手にやってまーす、じゃなくて、やっぱり銀行との間でなんらかの契約なり、協定を結んでいることになると思います。で、API連携になるとそこがもっとフォーマルになりまして、Clientとしての登録のため、正式に契約を結ぶことになりますし、場合によっては使用料の支払いも発生することになります。で、ID/PASSを預けなくてもよいわけです。正しい方向に向かっていると思いますね。

さて。

問題の大本はまとめてくれている人がいるのでリンク。

www.siskw.com

まず「個人情報を保有していない」かどうかの点についてが最大の問題かと思いますが、そもそも「Amazonや楽天で購入した商品をウケトルが勝手に自動追跡をしてくれます」というのが売りというところがポイントですね。
最初に説明したとおり、「ユーザーに代わってウェブサービスの内容を取得」するサービスの実現手段は２通りあり、ローカルアプリとウェブサービスなわけです。スマホであろうとも、ローカルアプリでスクレイピング実装することは当然可能なので、アプリの中だけにデータを持つ（＝情報をサービス事業者に預けない）ということは不可能ではないですね。ただし、ローカルアプリの場合、「アプリが立ち上がってないと動かない」という当たり前の問題があります。ウェブサービスであればユーザーの動きとは関係なくサーバー側で情報収集して、通知（はアプリが立ち上がってなくてもできる）することが可能です。となると、まずもってこのサービスはID/PASSをサーバーが預かってスクレイピングしている、ということになりますよね。ということはですよ？ID/PASSという個人情報の入り口を保有しているわけで、個人情報持ってないとかどの口が言っているんだ（ID/PASS流出したら結果として少なくとも流出先サイトに登録している情報ダダ漏れじゃねーか）という話になりますよね。リンク先では契約の有無の問題が焦点としているけど、そうじゃないです。ただ、個人情報を持っているだ持っていないだの話は実際にはエンドユーザーとサービス事業者の間の問題であり、ことさらヤマト等が言うことではないわけです。だって別にID/PASSが流出したら何でもありなわけじゃないですか。むしろ想定外のシステム利用に対する脆弱性アピールか？とか思っちゃう人いますよね？ID/PASS忘れがコールセンターで口頭で対応みたいになっているらしいし、どっちかというとヤマトの脆弱性のほうが怖いわ。

とはいえですよ、実際にウケトルのアプリを使うと「自動連携」しているのはECサイトのみみたいなんですよね。インストールしてもヘルプが充実していないのでよくわかんないんだけど、少なくとも配送会社のサイトで言うとWebViewでアプリ内表示しているだけで、加工してない（ので別に便利じゃないんだけど…）。だとすると、その点についてはウケトルの言い分が正しいし、WebViewで見せているだけなら「不正なIDの使用」ですらない。仮にIDをアプリが保存しているとしてもそれにいちゃもんをつけるのは「メモ帳に書くな」みたいな話ですよ。

なので、実はこのアプリ自体は（少なくとも運送会社部分については機能が低すぎて）問題ないんじゃないかという疑惑すらあります。でもECサイトのアカウントは登録して自動で通知してくるだしいので、その点に関して言うと黒だけど。クロネコヤマトのクレームがお門違いだからといってアプリの問題ゼロというわけでもないと思いますが、今の所アマゾンや楽天がクレームつけているわけではないですからねえ。

個人的には利用規約第１０条の(5)にあるこの文章だけで使う気はしませんが。

当社は、ユーザーID及びパスワードが他の第三者に使用されたことによって当該利用者が被る存在については、一切責任を負いません。また、当該ユーザーID及び対応するパスワードによりなされた本サービスの利用は、当該利用者によりなされたものとみなします。

ECサイトって金融機関と違ってログインパスワードと取引パスワードの区別ないから無理だわ。