とあるIT屋の独白

ITや経営について主に書きます

CRE(Customer Reliability Engineering)について

最近、CRE(Customer Reliability Engineering)という言葉をちょくちょく見かけるので、なんだろうというのを少し調べてみました。雰囲気的には、以前に本ブログで紹介したカスタマーサクセスの考え方に近いものを感じます。

toaruit.hatenablog.com

 

カスタマーサクセスやカスタマーサポートを担当しているのは、エンジニアの人達ばかりではありません。もちろん、システムを扱っているので、システムに関する基礎的な知識は身に付けているに越したことはないのですが、とはいえ内部仕様の詳細を調べたりシステムの改善を行ったりするのはキツくなってくると思います。CREはこういった問い合わせを減らしたりとか、カスタマーサクセスを実現することを、エンジニアの立場から行う取り組みとなってきます。

medium.com


CREって言葉だけ見るとちょっと目新しいと感じてしまいますが、ただちょっと落ち着いて考えるとこういった業務を、前からやってるエンジニアも普通にいるのではと感じます。システム保守を業務としているエンジニアの人は、CREって何が保守と違うのと感じる気がします。私も過去にシステム保守をメインで担当していたことがありますが、特にCREに対して目新しいことはないと考えています。
下記の記事にあるように、ビジネスに深く関わるシステムであればエンジニアが何かあった時にすぐ動ける体制を作るの必要なことです。バグがゼロのシステムなんてほぼないので、途中で改善しなければいけないこともあるでしょう。

axia.co.jp

 

ただ、一点システム保守とCREで目の向先が少し違うかなとは感じました。システム保守はシステムに目が向いている傾向にあるのに対し、CREはユーザに目を向てるという点です。もちろん、システム保守の担当だから顧客に目を向ていないかというとそうではありません。トラブルが起きた時にそれがどれくらい業務インパクトを与えるのか、再発しないためにはどうすれば良いか、問い合わせが多く来ないためにはどうすれば良いか、私が保守を担当していた時の現場はこのような観点も持って仕事に取り組んできました。
だから、保守だろうとCREだろうと呼称はあまり関係なく、いかにビジネスに対してシステムを活用できる状態にするか、というミッションは変わらないと思います。もちろん、トラブルに対峙することが多いので、しんどく感じることも多いでしょう。だから、仕事としてただやるんじゃなくて、そこにビジネスがあるという誇りみたいなのを持つ必要があるし、個人的には非常に価値がある仕事だと思ってます。
保守はけっこう軽い目で見られがちと感じることもたびたびあったのですが、当時の保守の現場で一緒に働いていたメンバーはみんな、ユーザに対してどう接すれば良いかというのを悩んでいたし苦労も多かったです。だからこそ、このCREという新しい呼称により、もっと陽の目を見るようになってくれば良いなとは感じます。

ブラウザでのアプリケーション実行の変遷について書いてみる

私がエンジニアをやってる中で、Webアプリケーションにたずさわってたことが一番多い気がします。今振り返ると、私が実際にWebに関わってきた頃からだいぶブラウザの環境とかも変わってきている感じがします。今回は私が携わってきた内容とかも踏まえて、このWebアプリケーションの主にブラウザに関わる部分を書いてみたいと思います。
まず、どこから話を始めるかというと、私がWebアプリケーションにたずさわり始めた2000年代後半から2010年代初頭くらいのところから。この頃は下記の記事の通りちょうどAjaxが出たての状況でしたが、Webアプリケーションの範疇では基本はサーバサイドでHTML出力し、フロント側のJavaScriptは補助的な役割というのが多かった気がします。

www.kogures.com


ではフロント側でリッチなコンテンツを入れたい時はどうするかというと、FlashであったりJavaアプレットといった、ブラウザで実行できるサードパーティのアプリケーションを組み込むことが多かったです。特にFlashは色々なサイトで使われていましたし、私もFlashとのデータ連携部分の案件などやってたこともあり、苦い思い出もあります。

nlab.itmedia.co.jp


そして、2010年代の初頭から中盤頃にかけて、フロントエンドにおけるWebアプリケーション開発の大きな変化が、個人的には2点あったと考えています。
まず一点目がHTML5です。HTML5が登場したことによって、ブラウザで今までサードパーティのアプリケーションでしか不可だったリッチなコンテンツを、ブラウザで実現ができるようになりました。登場当初は、まさかFlashを駆逐するとは思いもしなかったです。もちろん、スマホ普及の影響も大きいですが、それだけブラウザの機能自体が急速に進化したと感じます。

techblog.yahoo.co.jp


二点目は、JavaScriptフレームワークが登場してきたことです。ブラウザ上でリッチなコンテンツを表現できるようになっても、それを適切に開発できなければいけません。フロントエンドの実装が増えてくる中、jQueryでは開発の限界がやはりある気がします。そんな中でJavaScriptフレームワークが誕生したのは、大きかったと思います。下記の記事にあるフレームワーク「AngularJS」は、今のフロントエンドワークの先駆けのような存在と感じます。

codezine.jp


そして、現在に至りこのHTML5とJavaScriptフレームワークが洗練されてきて、かなり多くのことがブラウザで完結できるようになりました。まだまだネイティブアプリでしか出来ないこともありますが、ブラウザの機能追加も今もかなりの勢いで行われていて、ちょっとしたアプリであればブラウザで十分かなと感じるくらいです。
また、開発スタイルとして、バックエンドとフロントエンドで分けて開発するケースが多くなってきました。これはフロントエンド周りの技術スタックが確立してきた点と、フレームワークもある程度React・Vueあたりに落ち着いてきたという点が要因として挙げられるかなと思います。

d.potato4d.me


さて、すごくざっくりですが現代に至るまでのブラウザ周りのアプリケーションについて書いてみましたが、最後に少し未来の話を書きたいと思います。
ブラウザ界隈で最近、最もホットなトピックの一つがWebAssemblyでしょう。もちろんブラウザでもできることは増えてはいるものの、一方でJavaScriptだけでは処理しきれない処理も存在するわけです。それをカバーする仕組みとして用意されたのが、WebAssemblyです。現状、エンコード処理であったり機械学習の処理なんかを、ブラウザで実行することに活用を見出したりしています。今後OSの機能呼び出しとかもできるようになるらしく、機能がより洗練されてくれば、ブラウザでできることがより増えるものと期待しています。

www.publickey1.jp

諦めることと若者の考え方の変化

私はスラムダンクを読んでた世代なので、安西先生の「あきらめたらそこで試合終了ですよ」という言葉が、まぁ染み付いてるわけです。諦めることより諦めずにがんばったほうがそりゃいいよね、と大体のスラムダンク世代の人は考えるでしょう。ただ、漫画ではなく現実世界では果たしてそうなのでしょうか。今回はこの諦めることについて、書いてみたいと思います。
最近話題のAdoという歌手による「うっせぇわ」という楽曲。下記の記事ではこの曲は、若者と大人との断絶ということを表現しているという解釈があります。ということは、今の日本の若者世代は大人に対して期待を持っておらず、ある種の自分達の世界観のようなものを大事にしていると考えられます。

gendai.ismedia.jp


昨今の大人達の振る舞いを鑑みると、若者から見放されるのもいたしかたない部分もあります。もちろん、その点は大人は改善しなければいけないのですが、では果たしてこの諦められた大人は、もう単なる邪魔者なのでしょうか。もう少しこの諦めるという心境を掘り下げていきましょう。
諦めるという言葉の語源は下記の記事の通り「明らむ」となっていて、本来的な意味合いとしては「つまびらかにする、明らかにする」ということが元になっています。つまり、時を経たり物事を進めるうちに、自分の特性などが明らかになる中で、今取り組んでいることを断念するということからきているそうです。

www.hiroshima-u.ac.jp

 

「諦める」前には「明らかにする」というステップが隠れています。物事を始めるときは不確定なことが多いので、やってみないと分からないという部分があります。やってみてはじめて明らかになることも多いと思うので、結果として自分に合ってないなといったこともあるでしょう。私も小さい頃スポーツをやってましたが、そもそも走るのがあまり速くないし好きでもないということが分かってきて、その道はないなと感じたことが思い出されます。

toyokeizai.net


 さて、では若者が大人を諦めるということはどういうことでしょうか。これはなんとなくなのですが、若者は今の大人の思考パターンをある程度感覚的に理解しているのではないでしょうか。明らかにならないと、そもそも諦めるという心境に至ること自体ができないはずなので。
たぶんですがパンドラの箱はもう開けられていて、そのパンドラの箱は急速に進んだオンライン化によるものと私は考えます。SNSを当たり前に見ている世代は、大人の明らかに不合理な判断や思考といったものに、うんざりきている人も多いでしょう。今は災いや悪いものが、現在進行形で飛び出している瞬間なのかなと感じます。ただ、今の若者がもう日本はダメだ、こんなところで生きていてもしょうがない、と考えているかというと、私はそうは思いません。パンドラの箱の底にある「希望」みたいなのは、持っているようには感じます。
Adoが流行として取り上げられる側で、YOASOBIが若者の共感を得ているという事実もあります。YOASOBIが表現している内容は、一見してけっこう退廃的なイメージを持ってしないがちなのですが、よくよく一連の歌詞の内容を見ていくと大体最後に救いみたいなのを示していることが多いような気がします。だから、私はYOASOBIが表現しているのは、パンドラの箱を開けてから最後に希望が残る、この一連のプロセスなのではないかなと考えています。下記の「怪物」という歌が一番分かりやすいのですが、他の楽曲も基本的には同じような思想で作られていると私は思います。

www.youtube.com


今の若者が今どういう希望を持っているのか私には分かりませんが、ただ社会の色々なことが変わるタイミングが、ようやく来るのかなと感じています。色々と明らかにされてしまった私たち大人はその変化を邪魔することなく、静かに見守ることが大事なのではないでしょうか。諦めることは終わりではなく始まりであるのだから。

錯覚資産と感情と事実

少し前ですが、錯覚資産を上手く使って世の中を上手く渡る、というのが流行ったと思います。この錯覚資産とは「「人々が自分に対して持っている、自分に都合のいい思考の錯覚」及び、それを引き起こす事実」と、錯覚資産が提唱している人が述べています。

diamond.jp

錯覚資産自体は問題では無いと私は思っています。なぜかというと、自分は嘘を付いてるわけでもなく、ただ人に話せる事実だけを言っているにもかかわらず、周りがそれ解釈した結果、想定以上の評価を得られたというのに過ぎないからです。現に私も、自分ではたいしたことやってないつもりでも、なぜかすごい人みたいな雰囲気になってしまうような場面が何度かあったりしました。
では、この錯覚資産を意図的に作ろうとしてしまうとどうなるか。IT界隈で頻繁に話題になるテックキャンプの「転職成功率99%」というのを例にしてみましょう。99%という数字は、そこそこ名が通ってる会社が言ってる以上は「嘘」ではないのでしょう。ただ、色々なところで指摘されている通り、受講した人全員が母数になるというわけではなく、運営側でフィルタリングをかけた上での数字という話もあったりします。

 
今回の私の記事では特にテックキャンプの批判を目的としているわけではないので、何が本当の事実かはおいておいて、この意図的に錯覚資産を作り出してしまうことが、今テックキャンプに限らず問題だと私は考えています。もちろん、当事者は事実と信じ込んで言っているのでしょうが、その客観性が欠如していて、第三者から見ると嘘はついてないっぽいんだけどなんかそれ違うよね、という気持ち悪い状況が生まれてしまっています。下記の記事で述べられているような、まさに「誰もが感じたいことを感じて、それが真実になる」というのが近い感覚かなと思います。

toyokeizai.net


もちろん、感じたことをきちんと発信することは大事なことです。しかし、事実を度外視したある種の感情任せの発信は、時に事実を歪曲して、またその歪曲された事実が他の人の別の感情を呼び起こすような、負のループに陥ることもあると考えています。
なりたい自分の理想像みたいなのは持ってる人も多いと思います。ただ、自分を良く見せたいという感情が先走りして、実績や経歴等を自分の都合の良いような解釈で人に発信をするのは、やはり悪手だなとは感じます。結局はそれが疑わしいものに見られ、自分も得をしないし相手からも信頼されないといったことが起こり得ます。
だから、我々がまずやらなきゃいけないのは「現実を見る」ことであって、現実を見ないことには正しい方向に感情も向かわないと私は考えています。理想像を作るのも全然良いのですが、理想像の最初のスタートは現実であるべきだと思います。現実から始まらない理想像や感情はやはり虚像にしかならないし、結果として感情任せに事実を歪曲することになってしまうのかなと感じます。

戸籍の目的という観点からの夫婦別姓の考察

2018年に夫婦別姓について私のブログで取り上げましたが、
https://toaruit.hatenablog.com/entry/2018/01/16/022243
それから約3年経ってもこの夫婦別姓は実現してません。これはなぜかというと、当時も書いた通りですが日本においては姓と戸籍が深く関係していて、姓について仕組みを変えるのであれば戸籍の仕組みも検討せざるをえないのですが、この戸籍についての議論が全く深まってないからと私は感じます。一方で戸籍制度を変更するとなった場合に、そもそもこの戸籍制度って何のためにあるんだっけ、というのに立ち戻るのが大事と思います。ので、今回はそもそも戸籍の目的と、その目的に基づいて夫婦別姓の議論について書いてみたいと思います。
さて、まずは戸籍制度や姓の歴史的なところですが、下記の記事に詳しくまとまっています。現代の戸籍制度は明治時代の「家」が元になっていて、戦後に夫婦と子供を姓というくくりで同一の戸籍とするような制度になったそうです。現行の戸籍制度は、「夫婦親子の関係を一覧的に把握できる」ことを目的としていますが、欧米のように個人籍のほうが目的を達成する上では良いのではということも触れられています。

www.law.tohoku.ac.jp


さて、ではなぜ「夫婦親子の関係を一覧的に把握できる」ことが重要なのでしょうか。それは「子供への責任」ということに尽きると思います。昨今、日本でシングルマザーが問題になっています。婚外子の場合は子供は母親の戸籍に入り、父親となる人の認知を受けないと相続権がなかったり養育費がもらえなかったりします。もちろん、男性が拒否をすれば裁判で強制的に認知させるという手段もありますが、中々裁判まで起こすのもハードルが高いと思います。なので婚外子のようなケースを減らして、子供がきちんとした環境で育てられるような制度を実現するのが、戸籍のあるべきと私は考えています。

www.kakekomu.com

 

シングルマザーが今現在で問題になっている以上は、現行の戸籍制度は何かしら改善が必要といえると思います。ただ、この問題が取り上げられずに夫婦別姓の問題ばかりが取り上げられるのは、私は少し気持ち悪さを感じています。戸籍制度の本来的な目的が「子供を守る」ための制度であるはずで、今その本来的な目的が達成できていないことのほうが、夫婦別姓より大きな問題であると考えています。
もちろん、戸籍制度を現状に合ったあるべき方向に改正する上で、結果として夫婦別姓が良いのであれば、それはそうするべきだしそれについて文句をいう人は少ないと思います。ただ、目的や現状の問題点に目を向けず、単純に大人の都合で夫婦別姓をさけぶのは違うかなと感じます。守られるべき大事な子供にフォーカスされて議論されていないのは、少し浅はかではないでしょうか。だから、今のような議論を繰り返される限りは、夫婦別姓はたぶん実現しないと私は思います。

クラウドファンディングの問題点

以前に従来の融資による信用創造の代わりとなる手段として、クラウドファンディングを挙げましたが、

toaruit.hatenablog.com

 

もちろんクラウドファンディングが、無条件で良いものというわけではありません。いろんな人が自由に投資できるという便利な側面があるなかで、負の側面も出てきています。今回はその負の側面についてフォーカスして書いてみたいと思います。
クラウドファンディングにも色々な種類があるのですが、今のところ多いのは「購入型クラウドファンディング」であったり、「寄付型クラウドファンディング」でしょう。クラウドファンディングの仕組み自体が問題というよりは、出資を募る人の見極めやフィルタリングが非常に緩いというのが問題と思います。結果として、下記の記事のような想定していたよりも劣悪な品質のものが送られてきたり、書いてある内容に資金が使われないといった、詐欺に近い事案が発生しています。

venturetimes.jp


もちろんクラウドファンディングは自由度が高いのが利点と言えば利点なのですが、出資者の利益保護も合わせて考えないと、騙したもん勝ちになってしまって、まともな案件が埋もれてしまう懸案もあります。また、その気軽さゆえに金に困ったらクラウドファンディングで集めりゃいいじゃん、という短絡的な思考も生まれてしまいます。人から出資を受け、その責任を果たすという意識をより高める仕組みが必要と思います。
また、下記の記事のようにいわゆる融資型のクラウドファンディングである「ソーシャルレンディング」も問題になっています。問題点は、購入型クラウドファンディングと同様なのですが、資金調達をした事業者が不正に資金を流用して、焦付きが発生しそうという事案だそうです。

www.itmedia.co.jp

 

結局のところちゃんと信頼できるところに出資したり融資するというのに尽きるのですが、それを出資者側が判断できる情報をプラットフォーマーはより充実させるべきと考えています。騙したもん勝ちにさせないような仕組みにしていかないと、いつまでもこういった詐欺事件は減りません。そうじゃないと、まだまだクラウドファンディングは詐欺と言う人がいても、しかたない状況なのかなと感じてしまいます。

APIのセキュリティについて考えてみる

最近のWebシステムの構成だと、フロントエンドとバックエンドで分けて開発するのが多くなってきてると思います。もちろん、軽いアプリなら一つのRailsやLaravelなどのフレームワークで完結させても良いのですが、フロントエンドも凝ったものを要求されることが多いのでReactなどのフレームワークを使って実装することが、求められてきます。
さて、フロントエンドとバックエンドで分けて開発するときはバックエンドはAPI形式で、フロントエンドにデータを渡すことになるでしょう。このAPIについて、今後はセキュリティに対する攻撃者は狙いをつけてくることが想定されます。下記にGoogleが発表したサービスのように、APIの管理やその異常検知といった仕組みが今後求められてくる気がします。

jp.techcrunch.com

 

では、具体的にAPIのセキュリティリスクがどのくらい高まっているかが、下記の記事にまとめられています。APIのセキュリティ担保自体がまだそこまで成熟してきていない中で、攻撃者がそこを突いてきているという感じです。APIは画面と違って視覚的にここにリスクがある、というのが見えづらいのも一因かなとは思います。

www.atmarkit.co.jp

 

APIのセキュリティを担保する上で、認証の仕組みはキモになってきます。何のシステムかによってセキュリティをどのレベルまで担保すべきかというのは変わってきますが、認証周りは他のサービス（Google等）を活用するのも一つの手だと思います。また、API認証を行う上でトークンの扱いも気をつけなければいけなくて、トークンをどのように受け渡して盗まれないようにするべきかというのも、けっこう大事かなと感じます。

www.trustbind.jp