べきとうせいTシャツの紹介
マヂカル.fmは関西人のプロダクトマネージャー道部だと、関西人(?)のソフトウェアエンジニアのファミウムが週2で配信する雑談ポッドキャストです。
お願いします。
お願いします。
今日のテーマは?
うん。
べきとうせいって何?
何なの?本当に。
まさか、今日、うぱさんが着ているのはべきとうせいTシャツですね。
道部さんってべきとうせいっていうTシャツ作ってるんですよね。
そうなんですよね。
うぱさんが着ているのはバージョン1なんで、その、前面にしかべきとうせいがいないんですけど、
今販売中のバージョン2は、袖にもべきべきべきべきっていますね。
あの、ラーメンのやつみたいな。
あ、そうですそうです。赤いやつみたい。
べきとうせいってすごい、なんか大事だよね、みたいなのをエンジニアの人から聞くんですけど、
何回説明を聞いてもべきとうせいか何かわからないので、ちょっと今回こそわかるようになろうっていう企画です。
まずべきとうっていう、なんか漢字むずすぎる。
見たことない。
だから、存在しんかったもん。だから、作ったときに。
今まで、その、確かに。
あ、その、違う違う、その、Tシャツを作ったときに。
あー、フォントが?
そうそうそう。私が作りたかったフォントで、べきとうせいのべきっていう字はなかったんで、
あの、わかん無理に巻くの、みたいなやつを。
これわかん無理って言うんだ。
違うのかな?
わかんない、わかんない。
わかん無理ということをしとこう。
あー、なるほどね。
そう、巻くみたいなやつが入る。
わかん無理の和版。
そっち?
わかん無理ってあるよね。あるよ。
やるな。
もちろん。
インテリ。
インテリでもわかんない、何回説明を聞いても。
で、だから、そのべきとうせいのべきって漢字見なさすぎて、その、使いたかったフォントに漢字が存在してなかったんで、
他の漢字の和と巻くっていうやつのパーツを、なんかトリミングしてきて組み合わせてTシャツは作りました。
すごい。
すずりで買えるので、買ってください。
べきとうせいと再現性の違い
じゃあ、このエピソードを聞いて、べきとうせい完全に理解したよーって人は買って、周りのプロダクトマネジャーに。
一万円してください。
一万円してください。
え、それなんて読むの?って聞かれますから。
べきとうせいですとやーって。
マウント。
マウント取ります。
で、みちらさんは、え、それべきとうせい大事じゃないですかって、エンジニアに言います。
あー、そうね。
確かに最近、そう、最近もね、自分が担当しているプロダクトでべきとうせい、マジ大事みたいな話があったんですけど、うわ、出たよってなりました。
なんやねんべきとうせいって。
なんか前々からみちらさんが、なんか再現性との違いなんやねんっていう話をしてたんで。
そうですね、そう。
それは、そうなんですよ。
それを軸にして、なんかいろんな現実世界の例を使いつつ。
あー、そうですね。それが聞きたいかも。
やっていく感じにしようかなと思います。
だから、あんまりコンピューターの話は出てこない。
あ、そうなんだ。ありがたいですね。
ありがたいですね。
なんで再現性との違いがわからんかっていうと、そのべきとうせいってなんですかって聞いたときの、こういうものですっていう、その抽象化された回答は、それは再現性も一緒だろみたいなことを言っているからわからないんですよ。
はいはいはい。
なので、ちょっと一旦そのべきとうせいとは何ですかという質問に答えてもらっていいですか。
はい。べきとうせいは、例えばある操作を何回やっても得られるもの。
ここで最終的な状態って呼ぶんですけど、それが何回繰り返しても、その1回目の動作と変わらない。
だから、N回やったからといって、N回変わったりしないっていう性質のことです。
なんでミスって、これ本当は1回だけでいいのに、10回操作しちゃったっていうときに、その10回にならずに1回になる性質がべきとうせいです。
その後半のやつは、今初めて聞いた言葉なんですけど、その10回やってもと1回やってものやつは、初めて聞いた解説ですが、前半部分は再現性でも同じ説明が成立しますよねって思ってるという感じですね。
はい。じゃあこれ、こっからしないですよっていう説明を。
はい。
ちなみに、そのべきとうせいの話したんで、再現性はそもそもどういう定義なのかっていう話をすると、
同じ条件とか同じ手順である操作を行ったときに、毎回結果が同じになることの性質を再現性っていうふうに言います。
今のさっきのべきとうせいとの説明の差分は?
べきとうせいは、同じ操作何回やっても最終的な状態は初回の1回だけ。10回やってもその操作を1回だけやったことになるのがべきとうせい。
へー、なるほどね。
再現性は、
再現性は、1回目をいっぱいやったときに全部1回目の結果になること?
あー、そうですね。
あー、なるほど。確かにそれは若干違うかもしれない。
そう。
でもずっと、例がもうちょっと聞きたい気もする。
そうですね。なんでちょっと、もう1回なんか性質と具体例を整理すると、性質的には再現性は、ここでちょっとコンピュータチックに言うと、
同じ入力に対して常に同じ出力が得られますっていうのが再現性です。
たぶん1と1を入力して足し算だったら常に2が返ってくる。たまに3になったりしない。
うん。
これが再現性ですよね。
うん。
で、べきとうせいは同じ操作を何回実行しても、ここが何か再現性にない概念が出てくるんですけど、
状態が最初と変わらないっていう。
何も分からなくなった。最初って何の?
あ、その状態っていうものが出てきたんで、再現性とのここが一番違い。
はい。
まあ置いておこう。
はい。
じゃあそうですね、ちょっとみちるださんの、なんかよく使われるのが、
なんか照明とかエアコンのオンオフな話とかなんですけど、みちるださんの、
みちるださん多分あの照明とかエアコン普段使わないと思うんで、
なんで?
もっと身近な話を言うと、例えばサブスク何かしら使ってますよね。
はい。
例えばSpotify、Spotify大好きのみちるださんが、
ちょっと話簡単にするために毎月1000円だとしましょう。Spotify。
で、Spotifyのサブスクの引き落としに対して再現性があるっていうのは、
つまりどういうことかっていうと、
決済されたら1000円が引き落とされるっていうのが再現性で、
2回目になったら1001円になったり999円に毎回なんかランダムになったりしないっていう、
サブスクは常に1000円で引き落とされるみたいなのが再現性ですと。
Spotifyの例と状態の理解
はい。
ここまではOKですよね。
一応それを再現性と言うかはあれですが、それが再現性だったときにという感じで聞きます。
で、べき等性があるっていうことは、
さっき最初の説明であったように、
同じ操作を何回繰り返しても最終的な状態は最初にやった操作と変わらない性質。
うん。
なんで、たとえばみちらさん今月のSpotifyの引き落とし、
Spotifyがバグらせてて、みちらさんから10回サブスクを引き落としましたっていう。
うん。
で、もしべき等性がないとどうなるかっていうと、
行った操作分、その事象が発生してしまうんで、
そうね。
10×10でみちらさんから1万円引き落とされちゃいます。
はい。
で、これにべき等性があるとどうなるかっていうと、
10回みちらさんから引き落としするっていう操作が、
最終的な状態は最初の1回目、初回の操作だけやったのと変わらない状態なので、
10回やったとしても1回分として引き落とされるっていうのが、
べき等性があるっていうことなんですよ。
なるほど。
なんかあれですね、めちゃくちゃ人工的な概念って言ってあれですけど。
そうですそうです。
なんか結果問題が起きないようになっているという状態 is べき等性があることと言ってるみたいな、
なんかそういう印象を受けました。
まあそうですね。
なんか自然事象的にべき等性があるような事象たちみたいなのが存在してるわけではない。
多分、存在しないんじゃないかな。
システム独自の話。
そうかも。
状態っていうものを持ち込んできてるんで。
状態ってさっきのSpotifyで、バグってても1000円しか引き落とされないっていうのは、
そこで言う状態は何ですか。
そこで言う状態はいろんな捉え方できますけど、
簡単に言うと、みちるださんから何回引き落としたかっていうのが状態にできますよね。
月額1000円が引き落とされることかと思ったけど。
それだったら例えば2回。
結果として。
でもそれは結果なのか。
2回引き落としたらその状態ってどう変わります。
2回引き落とされた状態。
そうそう。つまりそれって回数じゃないですか。
2回引き落とされた状態。
なんでそこでは状態は回数として表すのがシンプルですかね。
もう一回、さっきのSpotifyの例だと、
で言う状態は1回引き落とされている。
何回引き落とされているかっていう。
何回引き落とされているかが状態で、最初の状態は1回引き落とされた。
1回引き落とされます。
2回引き落とされたら2回になります。
状態って言葉なんですね。
状態なのか、状態かもしれないけど。
確かに。状態って言葉が短じゃない。
そうですね。何が直感と違うんだろう。
操作と状態の関係
やばい、ここでゆる言語学ラジオの人がいれば、状態の定義から3本話してくれるのに。
なんか操作とかの方がっぽい言葉だなって思うんですよね。
操作をやった結果、状態が遷移する。
なるほどね。
そうですね。操作とか結果みたいな方が近い言葉なんじゃねっていう感じがするんだよな。
なるほど。
状態は、そもそも引き落としされてない状態とか。
そうなのか。
それは0回ですね。
なんでピンとこないんだろう。
例えば電気で話したら、電気が消えてる状態と電気がついてる状態があるじゃないですか。
それを行き来するのって、スイッチのオンオフですよね。
オンっていう操作によって、消えてる状態からついてる状態に操作が行く。
その逆もしっかり、ついてる状態からオフにしたら、オフにするっていう操作によって消えてるっていう状態になる。
さっきの話で言ったら、今月ある月にみちるださんから何回引き落としたかっていう状態があって、
それがまず0回なんですよ。初期状態は。
そうとも言えるな。
引き落としたら、操作が1回、2回、3回、4回、5回っていう風になるって感じ。
さっきの電気の例だったら、オンの状態、オフの状態みたいなのは結構直感的なんですけど、
それをSpotifyの例に転用した時に急に難しい。
そうっすね。
それなんか、いろんな状態があるんだよ。
いろんな状態?
もっと簡単な状態に、回数をやめて、よくある請求前、請求中、引き落とし済みみたいな感じのステータスで考えたほうがわかりやすい感じじゃなくて、
最初、何もしないところから、請求前から、みちらさんのカード会社に、請求中みたいな、引き落とししてっていう依頼が来て、操作があって、請求中っていう風になって、
今、この状態あるじゃないですか、そっから、請求中から引き落とし済み、実際に引き落とすっていう操作あるじゃないですか、
それを10回やっても、100回やっても、最終的にこの状態になるのは操作が1回だけっていう話。
適当性の重要性
それ、今のはめっちゃわかりやすい気がします。
なるほど。
それを状態って、状態の変化って捉える?
そうなんですよ。ステートとかで言いますね。
大学とかだと、ステートマシンっていう図を書いたりして、
ABCみたいなこの丸を書いて、そっからどの操作によって、どの状態からどの状態に移るのかみたいなのを書いたりしますね。
で、この操作は適当性を持たせたい操作とか状態変化みたいなのを定義するみたいな感じ?
そうですね。結構、システム開発にかなり寄ってるんで、そこのステートマシン図上で、ここは適当性あるみたいなのはあんま聞いたことないけど。
そうなんだ。
じゃあ、いつ適当性について考えるんですか?実装するとき?
実装、えーと、なんだろうな。
設計の段階で欲しいってなる?
そうですそうです。設計の段階で欲しいっていう風になります。
例えば、そうだな。じゃあ、なんか現実世界の例はもう良さそうだから。
たぶん。
ちょっとなんか、オンラインショッピングってよくある。
はい。
で、例えばですけど、アマゾンとかでカートに物詰めて、ポチポチっと押して最終的に決済するっていう風なやつあるじゃないですか。
はい。
そこで、えっと、ここの決済するっていうボタンを押したら、たまにミテラさんの家の電気がついたりすることなく、普通に決済が走る。
はい。
たまにミテラさんの家の電気がチカチカするったりする行動にならないっていう点で、それは再現性がある行動っていうか仕組みなんですよ。
うん。
はい。
で、さっきの例とあんまり違わないからわかると思いますけど、ここに適当性が欠けてると、ユーザーが10回クリックしたら10回決済されちゃうっていう問題なんですよね。
で、ここで適当性を導入すると、ユーザーはあるカートの中身を何回決済しようと、最終的にユーザーに決済されるのは一度きりっていうのが、適当性になります。
なるほど。
なので、これは重要層ですよね。
適当性がある状態にするっていうのが正しい日本語ですか?
適当性を担保する。
そうですね。どの言い方でもいけると思います。
適当性を持たせるとか。
さっきの適当性を持たせようと思ったら、ボタンのクリックじゃなくて、どのIDの商品を交流ステータスにしたかを見て請求内容を決めるとかってすると、適当性が保てるみたいな感じなのか。
なので、システム開発だと、適当性を考えずに、とりあえず来たら何でもやりますっていうふうにしちゃうと、結構大変なことになることが往々にしてありますね。
適当性って保とうと思って保ちきれるんですか?なんか99%適当みたいな感じになりますか?
すごいね。
さっきのやつも、例えばIDが同じ時間にいっぱい掲載されたらやらないとかって、できるなって素人なりに思ったんですけど、
でもそれだと時間がちょっとずれたりとかしてたら重複掲載されちゃうなと思って、やり方次第なのか、そういうもんなのかみたいなのを知りたいなと思いました。
結構、場合場合によって結構やり方はいろいろあります。
例えば、めっちゃ簡単な例で言うと、
例えばカードポチッと押した瞬間に、その瞬間に例えばユニークなIDを渡してあげて、
例えば整理番号みたいなのを渡してあげて、1番目みたいな。
今回の購入の整理番号。
で、決済をするときには、その番号札を常にもらうようにする。
そしたら、2回目来たら、あんたもう決済してるよっていうふうにできたりする。
すっごい簡単に言うと、なんかそういう感じで保つんですけど、そうですね。
じゃあ、基本は100%になることを目指すんですか?
目指しますね。
目指す、達成するんではなく目指すんですか?
そうですね、基本的にはいけるはずだけど、
そうですね、いけます。
けど、けどっていうか、その適当性が大事なんで、
コンピューターの世界で絶対に1回だけこれを実行してねっていうのはめっちゃ難しいんですよ。
へー、なんで?
そのExactly OnceとAt Least Onceっていうのがあるんですけど、
なんか1回だけ、絶対1回だけここの、なんだろう、
エンドポイントっていうのが難しい。APIを叩いてくださいっていうのはめちゃくちゃ難しいんですよね。
へー。
なんだろうな。
例えばそのAmazonとかのカートの例でも、それはもう普通に無理だなっていうのがわかるじゃないですか。
例えば、その例だとユーザーが2回クリックしたら、もう2回叩かれるから、
普通にノーガードの状態でいたら、決済2回走っちゃいます。
で、そのために適当性を持たせたら、同じ操作が何回されても1回だけ決済されるっていうふうにできます。
なんで、他にもさっき言ったような、Exactly OnceとかAt Least Onceっていうのがあって、
そのAt Least Onceは、これ説明するの無理だな。
少なくとも1回みたいな。
こっちは結構簡単なんですよ。
少なくとも1回叩いてね。1回読んでねっていうのはいいんですけど、
Exactly Onceってめちゃむずいんですよ。
本当に1回だけ。
本当に1回だけ叩いてください。
へー。
で、なんで、例えば、At Least Onceの世界で生きていくためには、絶対に自分に適当性が必要なんですよね。
少なくとも1回だったら、100回叩かれる可能性もあるじゃないですか。
まあ、そうね。1回以上だからね。
そうそうそうそう。
だから、その世界だと、自分が適当性前提のシステムにならざるを得ない。
そうしないと、例えば、あるユーザーに通知を送りますみたいな。
あー、あれか。その100%が難しいっていうのは、全てのものに対して適当性を持たせるのは大変という意味。
適当性を持たせて決めたものについては、基本100%でやるっていうことか。
できなかったら、バグか、すっげー難しい特有のケースがあるかっていう感じですね。
再現性と適当性
なんで、書き込み系で、これ同時に書き込んだからといって、2回やられちゃまずいよね、みたいなやつは、よく金融系とかはそうなりますね。
なんかお金のやり取り回りとか、なんか小石がすごい大事みたいなやつとかは、ちょっとないとやばいなーっていう感じがします。
そうそう。え、どうですか?
まあ、多分わかった気がします。
再現性と結構、なんか違くないですか?
私、全然違うことを言ってた。
でもそれは、よく出てくる説明が悪いということな気がした。
確かに最初の時点で、10回操作をやったとしても1回目の結果に必ずなることみたいな補足で、ちょっと違うかもなと。
でも誰もその説明をこれまでしてくれなかった。
なんか状態っていうものを考えたら、結構簡単になるかもしれない。
そうですね。ちょっと状態の理解は、なんか本当に具体例がないと結構難しいかもしれない。
なるほど。
で、あとなんか自然的に生まれているものではない。
自然に生まれることはない性質みたいなのも、思ってたのと違いました。
適当性は作るものなんだなという感想です。
かっこいいな。
適当性を書いてるな。
適当性は自然界では見られない概念です。
そうなんだ。それはわからんわ。
適当性は英語で、副詞アイデンポテントリーって言って、
適当なのはアイデンポテンシーだから、よくあるな。
さっき言ったみたいな、Amazonのカートにクリックしたら、なんか番号札あげればいいんじゃない?みたいな。
アイデンポテンシーキーの重要性
1位なキーみたいなやつを、よく適当にするためのキーっていう意味で、アイデンポテンシーキーみたいな名前するんで。
そうなんだ。
その時にも、例えば、アイデンポテンシーキーをどうやって、どういうアイデンポテンシーキーにするかっていうのは結構重要なんですよ。
そうですね。
アイデンポテンシーキーとしてだけ使うのかどうかとかもありますか?
アイデンポテンシーキーって、もうその適当にするためだけに使う?
その単位だとそうですね。
そうなんだ。
さっきの購入整理番号だったら普通に、なんか購入のIDみたいな感じでも使えちゃいそうだなと思ったが。
その場合なんか、アイデンポテンシーキーをもとに、別のシステムがもっとランダムなIDを生成してみたいなケースもありますね。
なるほど。
1番みたいなの出したら、はい、これあなたのID。
そういうランダムなIDの場合もあるし、逆にランダムなIDだと難しいケースもあって、保存しないと難しいケースがあって。
例えばさっきのSpotifyの引き落としみたいなの。
うん。
もっと簡単にアイデンポテンシーキーを作ることができて、
例えばシンプルに、みちるださんのユーザーのIDと、
例えば2025年2月分みたいなのをこうやってくっつけて、アイデンポテンシーキーにすれば、
確かに確かに。
そうそうそう。
それに対して消せば1回ですよっていうふうにできます。
それをランダムにしちゃうと、みちるださんの2月分に紐づいてる謎のランダムのキーはこれだからっていうふうに、
データベースとか保存して、1回作っておかないといけないから、
そういうアイデンポテンシーキーにすると便利。
ちょっと専用のキー作るのはトゥマチだなみたいな。
そうそう。
時があるよって。
そうそう。
で、決済システムとかは、そういうアイデンポテンシーキーとかをサポートしてたりするんで、
みちるだ2025年2月分みたいなやつを何回送っても、1回しか決済されないという感じですね。
なるほど。
でもなんかめっちゃ大事というか、安心してインターネット決済できてるのは、
ビクトセのおかげでしかない。
そうですね。
信頼します。
これは送る側がバカになれるんですよ。
例えば3回、4回、5回送っちゃうっていうのはちょっとバカすぎるけど、
例えばその時に一時的に障害が起こって、
1回決済投げたんだけど失敗しましたみたいなエラーが返ってきた時に、
失敗したんだと思って、もう1回決済お願いしますってやるじゃないですか。
その時にベクトー性があったら、もし失敗したって言い張ってても、
システムの中ちゃんと見たら成功してたわみたいなパターンも大々にしてあるんですよ。
その時もベクトー性あったから、
さっき失敗したって言ったけど、本当は成功しましたわって、
成功の結果を返せるんですよね。
もしベクトー性なかったら、さっきと同じように、
二重で決済されちゃうっていう。
ベクトー性は大事なんです。
システム的工夫の必要性
大事ですね。それは大事だわ。
そうそうそう。
明日からベクトー性マスタリング、いや、今日からベクトー性マスタリング。
そうですね。
確かに、私結構ユーザー的には当たり前でしょって思っちゃいがちなところであるが、
それをちゃんと100%やり切る、保証をするには、
システム的な工夫をちゃんとしないといけないんだなという学びになりました。
そうなんですよ。何でもかんでもね、
ラスト1マイルというか、あとちょっとのところが一番めんどくさいんですよね。
そうですね。ちゃんと1回だけの決済にするみたいなのとか、そうですね。
そうなのよ。
大事ですね。
お、どうですか?
どうですか?
ベクトー性は理解できました?
いや、はい。
お!
多分。
これから自信持ってTシャツ着れます?
そうですね。私、再現性とは違うんだよって。
何が違うのって言われたら、これ聞いてって。
言われる。確かに。
私が出るまでもない。
この回のQRコードをTシャツに印刷しておけば。
確かに。
そうするか。
なので、ちょっとベクトー性大事だなと思った人はTシャツを、
ぜひ買ってきて世界に広めてください。
ベクトー性の概念を。
すごい勉強になりました。
良かったです。
ありがとうございます。
このUpperによるIT解説会は定期的にやりたいです。
次は何がいいかな。
クラウドフレア。
クラウドフレアかRSSか、宣言的に書く手続き的に書くって何?
みたいなのがあります。
宣言的に書くも時々エンジニアの人から聞くんですけど。
なんだっていう。
結論ファーストみたいな感じで思ってます。
なるほどです。
なので次回もお楽しみに。
では、そんな感じで。
感想・質問・フィードバックは、
Xのハッシュタグ、マヂカル.fm全文小文字、
または概要欄のお便りフォームまでお寄せください。
Spotifyのベルマーク等は、
Apple Podcastのフォローを押すと更新通知が届きますので、
そちらもお願いします。
ありがとうございます。
ありがとうございました。
