  |
はてなキーワード: ビジネスロジックとは
テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
GでもCでもUIはまた別
結論としては書かないほうがいいと思った。
そういうこともある
全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
まあそれはないだろう
それはデバッグの一環のような
一番よくあるやつ
そこのバランス考えないと
バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる
悪いね
テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね
上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど
バックエンドのビジネスロジックなど書いた方が絶対にいいものもある
まず上流というのがいないんよ
エンジニア数千人いる中で
めちゃめちゃ出来るエンジニアが数人いてその人たちがビジネスロジックを簡単に書けるフレームワークを作る
その人たちは年収数千万とか数億とかのレベルだけどビジネスなんかなんも知らない
そのツールをエンハンスするエンジニアが数百人居てこの人たちもビジネスなんかなんも知らない
そのツールを使ってビジネスロジックを組むエンジニアが数千人いる
そのエンジニアにビジネスの仕様を伝えるビジネスアナリストが何人いたかは知らんけど相当いる
日本の「上流」というのはここでビジネスアナリストあたりの感じだけど、ソフトウェア的にはビジネスなんか一切知らんトップ数人が大事なの明らかやん
そのアプローチは非常に効果的ですね。メイン関数内での処理をシンプルに保つことで、コードの可読性と保守性が向上します。以下にその考え方を反映したサンプルコードを示します。
import json # ビジネスロジックの関数 def business_logic(data): # ビジネスロジックの詳細 pass # 設定情報のロード def load_config(config_file): with open(config_file, 'r') as f: config = json.load(f) return config def main(): # 設定情報のロード config = load_config('config.json') # ビジネスロジックの実行 business_logic(config) if __name__ == "__main__": main()
このコードでは、メイン関数は設定情報をロードし、その情報を元にビジネスロジックを実行するだけです。技術的な詳細は関数内にカプセル化されており、メイン関数はそれらの関数を呼び出すだけです。これにより、コードは自然言語を読むような形で読むことができ、技術的詳細は隠蔽されます。また、各関数の担当者も明確になります。このような設計は、大規模なプロジェクトやチームでの開発に特に有効です。
phpの場合、＜?php 処理 という具合に書くが、この中身にはhtmlやjavascriptも包含することができてしまう
MVCフレームワークを使わないにしろ、基本的にビューとバックエンド処理は分割しておくべき。
さらにDB処理、ビジネスロジック、プログラム処理と言ったものがあるが、
DB処理はdbhandler専用のモジュールに分けておき、さらにそのモジュールを処理するテーブルごとに分けておいた方が良い（MVCではモデルと言う）
特にビジネスロジックとプログラム処理の区別だが、「商品名にアダルト商品と思わしき文字列があった場合は登録を拒否する」という例外は「ビジネスの例外」であるのに対し、「商品名の文字列がDBで用意されたvarcharの可変文字範囲を超えた」という例外は「技術の例外」であるということを明確に区別するようにコードを書く。
「おすすめ機能」のような凝ったアルゴリズムが必要な場合はそれ専用のクラスへ分離しておくこと。
昔、Google Plusでこのような議論があった: 「Facebookぐらいの企業なら、自社全体で自作のOSを使っているだろう」
しかし私はその点について非常に疑問に思っていた。
「OSの自作？そんなことをして利益の足しになるのだろうか？」
一から何かを作るよりは、既存のツールやライブラリの力を借りたほうがバグも少ないし安上がりである。
そういった基礎部分は、外部のライブラリ開発者に任せてしまえばよい。
多くの場合、ビジネスドメインを相手に仕事をしているため、基礎部分を組み合わせた応用に主眼がある。
基礎部分に時間をかけてしまうと、その分の時間や労力が無駄になってしまう。
Webシステムを開発する企業は、ビジネスロジックこそが注力すべき部分であると忘れてはならない。
俺がシステム屋として見てきた限りでは、デザイン屋とシステム屋が別々で
UI/UX何それおいしいの、というシステムが量産されているように思う。
システム屋はプロジェクト初期、まだデータ構造やアプリのユースケースの詰めが甘い段階でデザイン屋に依頼する。
プロジェクトが進むと、システム屋は開発中の様々な問題に対応するために、もうデザインどころではなくなる。
デザインを修正するとしても、ビジネスロジックの深い所にも影響が出る実装を〝やらかして〟しまっており、デザイン修正に対しては激しい倦怠感・嫌悪感。
プロマネは「動くアプリが納期までに完成するか」を祈る事しかできない。トラブル続きで、UXに気を配る心の余裕などない。
自分の仕事としては案件進めているうちに出てくる課題とか機能追加とかバグ修正とかを設計してIssueとして作って他の人に振ったり自分で作業に当たったりと色々なんだけど、
最近とあるプログラミングスクール出身の同僚エンジニア(最近同じ部署になった)が自分の案件にアサインされた。
内容としてはとあるテーブルの特定カラムのバリデーション処理が漏れているから追加してもらって、なおかつユニットテストを修正する、というもの。まあ簡単な奴。
Issueを振ってからしばらくすると同僚エンジニアから質問が来た。
「ん？」と思った。いや別に特殊なことなんて何もないIssueだし似たようなテストケースもリポジトリ上に山程あるしどうにでもなるじゃんって。
まあ特に考えず1個のテストケースを例として自分で作ってみて、「残りは○○の場合とXXの場合と△△の場合のテストケースを網羅してください」みたいな返信をした。
しばらくするとまた質問が来た。「△△の場合のテストケースの実装方法がわかりません。」
いやいや、そんなん頭使ってどうにかこうにか考えろよって。案件特有のビジネスロジックのことを聞かれるならわかるけどこんなレベルの対応どの企業のどの案件で振られても同じことやるだけやん。
この質問してるのが未経験の入社1ヶ月目の新入社員なら自分は笑顔で答えるけどこのエンジニアは俺よりキャリアが長いらしい。
その同僚エンジニアはわからないことがあるととにかく素直に「わかりません」と言ってくれる人だった。
成果物についても指摘事項があまりにも多く、自分(というかその人以外)がやったら10分くらいで終わる対応に数時間以上かけて説明して修正してもらうという感じになった。何のための仕事をしているのかよくわからくなっていた。
自分はITエンジニアが「わかりません」という言葉を使うのは例えばどうしても再現性がなくてログにも何も残ってない謎の不具合とか、コンパイラやインタプリタレベルの不具合で現時点で解消方法がどこにも載ってない奴とか、そういうマジで「参りました」的な状況だけかと思ってた。
こんな公式ドキュメントとデバッグツールだけでどうにでもなる状況で「わかりません」を使う人に遭遇するのは初めてだった。
その人はとにかく「わかりません」が多い。
レビューの指摘の意味がわからない、指摘内容はわかっても修正方法がわからない、影響反映を洗い出してほしいと言ったら影響範囲の洗い出し方がわからないと言われる。何ならわかるのか教えてほしいくらいだった。
うっすら評判悪いのは知ってたけど実際に仕事してみると尋常じゃないほど酷かった。
こっちもいろいろ対策を考えた。
Issue振るときはソース上に「↓ここの○○をXXになるよう修正してください」とコメントを書いてから仕事を振るようにする、「わかりません」が来そうな部分は先手で予想して回答を載せる。
でもダメだ。こちらの対策なんてものともしないように全てを掻い潜ってくる。
もはやその人に仕事を振るのは「この作業を担当してくれたら助かる」ではなく「この作業であれば流石に”わかる”だろう、そして単純作業の量が多いからしばらくは邪魔されないだろう」という感じにできる限り疑問点が少なく時間がかかる作業で”遠ざける”のが目的になっていた。
最低でもあと1年くらいは人事はこの状況らしい。。。
こういう状況ってどう扱うのがいいんだろうなぁ。
ドメイン駆動設計ってあくまで設計手法っていうかビジネスロジックのモデリングまでが本分だから
システムドメイン（領域）にビジネスドメインで履いていた土足のまま踏み入ってはいけない
※補足追記：基本設計したら詳細設計するけども、そこでビジネスロジックをシステムロジックに翻訳するからコードレベルでは一対一にはならないということ
概念の次元が違うのだから現実に漫画の理屈を持ち込むなっていうレベルの話（ビジネスが漫画レベルという意味ではない）
モデリングによって現行のビジネスの問題を洗い出し、それを課題として解決（仕事を楽に）するのがシステム
それも一回で終わりじゃなくてシステム化したビジネスを再びドメインモデル化して分析、課題をシステムで解決ってサイクルを回していかなくちゃいけない
システム側も細かいこと言えば領域が分かれてるからそれぞれの領域に合わせて駆動方法は変えなきゃうまく回らない。
データレイク周りならデータ駆動型の方が適しているし、逆にアプリケーション側でビジネスやUXを無視してデータ主体で走るのは阿呆の所業だし、
馬鹿の一つ覚えで〇〇駆動設計だの開発だの一本槍でパワープレイするやつが多すぎなんだよ！ 適材適所って理解しろよ！
ちゃんと各分野のスペシャリストを雇って意思決定層に組み込んだ方が結果的に時間や金なんかのコストが少なくなるよって話が通じないよね
抽象に依存するってことなんだよね。発想が抽象的でむずかしい。
以下に示すbeforeコードの欠点は、IOに関係する部分とビジネスロジック(誇張)が密結合していることで、このメソッドを変更する理由が複数存在している点である。(単一責任の原則に違反)
変更理由は、IOにnullが入ってくることを考慮するとか、暗号化アルゴリズムを変更するあたりがぱっと浮かんだ。
afterのコードは、readerとwriterを引数から受け取れるようになっていて、インターフェースに依存するようになって、単一責任の原則を守るようになった。
```
# before
def encrypt
end
end
# after
end
end
```
まとめ
Smoozという国産ブラウザアプリがサービスを終了して、私はなんだか無性にイライラしてしまった。
WEBとセキュリティを専門としないので関連記事をざっと見た感じだと、
といった感じが主とした批判理由で、批判記事が書かれた数日後、アスツール社は利用規約を変えるでもなく、サービスの一時停止でもなく、サービスを終了させた。
Smoozを開発したアスツール社、
mala氏、
そしてお前ら
最初、あなたの記事を読んだとき、私は「こんな中華アプリみたいな情報ぶっこ抜きブラウザアプリを作るなんて、なんて腐った連中なんだ」と思いました。あなたの情報を小出しに勝負する様は見ていて気持ちよく、私が明るくないセキュリティに詳しいこともあって、あなたは正義の見方に見えたのです。
しかし、Smoozがサービスを終了させたと聞いて、私の態度は一変しました。もしアスツール社がmala氏の言うような"面の皮が厚い連中"であったなら、最初に取る一手は利用規約を変更して、なんだかんだ理由をつけてサービスを続けるだろうと思ったからです。しかしそうではなかった。
アスツール社は、アプリの使用者に「セキュリティの問題が起きたので使わないでください」というポップアップを表示する機能を実装させ、ストアから削除し、サービスを終了させました。
もしかして、邪悪な情報売買事業者は、存在しなかったのではないでしょうか？
なぜあなたはセキュリティに詳しいにもかかわらず、IPAに報告もせず（してたらごめんね）、アスツール社に報告をせず、初手でブログで開示という方法をとったのでしょう？
それはセキュリティ界隈のキャリアアップの方法が、既存のサービスの脆弱性を見つけて、それを指摘しSNSやブログでバズらせて名を上げるという戦国時代のそれだからでしょうか？（心あたり多すぎですね？）
それとも情報セキュリティマネジメント試験には、「問：脆弱性を発見した場合、これ以上被害がでないために何をすべきか」「答：SNSやブログでバズらせてサービスを停止させる」という問題が出題されているのでしょうか？
不思議なことに、私の怒りはアスツール社から一変、あなたに向けられることになりました。
私は、このmalaさんという方が「アスツール社に脆弱性報告をしている」というのを見て、正直感動しました。
なぜならセキュリティ界隈の人間は戦国時代の武将なので、脆弱性を見つけるや否や、スクショをとって「ここがまずい」「ここがやばい」とSNSに連投したり、なんの権限もないコールセンターとのやりとりをブログでバズらせる人ばかりだと思っていたからです。
しかし考えてもみれば、まじめに脆弱性報告をする人は目立たないのです。私はteraailでこまめに回答を書いている徳丸某氏の活動には目を向けないくせに、声のでかい戦国武将の活動ばかり目を向けて、セキュリティ界隈はクソだと思っていたことを恥ずかしく思いました。
しかしmalaさんの以下の文言を見て、私はそれどこらではなくなりました。
似たような要件で仕様が上がってきたら、多くの開発者が同じようなことをやるだろう。 上から目線で評論家気取りでこれは酷いなどとのたまうばかり、火事場を外から眺めて他人事で自分のことは棚に上げ、 人のふり見て我が振り直しもしない、お前もお前もお前も、漫然とインターネットをしている醜い卑しい下賤の生き物ばかり。なんとかしてくれ。
私はかつて「時間と金」を理由に、数年後に爆発する時限爆弾を見て見ぬ振りをして開発をしたことを思い出しました。そして爆発の火中に巻き込まれるのを恐れて転職しました。
そうです。私は自身の仕事ぶりには棚を上げるくせに、はてなブックマークであがってきたインシデントには人一倍敏感な棚上げクソ野郎だったのです。しかしmalaさん、毅然とインターネットをするには人生は短すぎて、人類は繁栄しすぎています。インターネットはビジネスチャンスの宝庫で、殆どの人類の関心事は他者を出し抜きそのチャンスを掴むことにあります。当然、注力すべきはビジネスロジックで、セキュリティは二の次になります。 あなたの記事をブクマして偉そうなこと書いてる技術的に聡明な人とは違って、私のような凡人は、 あなたの書かれている脆弱性の手法の意味をまったく理解できていないし、関係ない話ですが機械可読性に配慮して文章を紡ぐという必要性すらも感じていません。ただ1週間の残った2日でどう人生を輝かせるかで価値が決まる人生を歩いているのです。
あなたの文章を読んで、自分自身にも怒りが沸いてきました。真にクソなのは、棚上げ転職逃亡クソ野郎の自分自身だったからです。確かに私はインターネットも、人生も、漫然と惰性で生きている。しかしだからといって、どうすればいいのか。ビジネスの意思決定権は自分以外にあり、私にできることといったら、せいぜいが静観を決め込むぐらいだ。
残念だったのが、あなたが reliphoneに暴言を吐いたことです。セキュリティ界隈には強い言葉で反論をしずらくし周りを萎縮させる重鎮が鎮座していると思っていましたが、あなたもそれになっていることです。漫然とインターネットをしない先がそれなら、蛇の道ですね。
まず、私がアスツール社を知ったのは、はてブにSmoozの記事があがってからでした。
そこで私は「なんて非道いアプリだ。許しておけぬ」と思い、代表取締役の名前で検索し、クソ野郎の顔と名前を覚えたぞ、しししと、汚い笑みを浮かべました。
その数日後、Smoozがサービス終了したとアナウンスがあり、私は驚きました。それと同時に、貴社の情報ぶっこ抜きアプリが、果たして本当に悪意によってなされたものかと考えを改め始めました。
貴社のやりたかったことは、広告で収益をあげたかったので、そのために記事中からキーワードを引き抜いてユーザに合った広告を出したかっただけなのでしょう。すべてのユーザがハナから有料ユーザになってくれればこんなビジネスモデルにする必要はなかったのかもしれないが、そんなことは起こりうるはずもないので、無料ユーザからは本文テキストをぶっこ抜いて、DOMをいじって広告を挿入する。これはいいアイデアだと思ったのでしょう。
私も中小零細企業で働いたことのある身。凡人の自分が考えたアイデアなんて世の中にはたくさんあって、思いついたアイデアはどれもこれも上司にリジェクトされる、特許で押さえられていた、法律的にアウト寄りのグレー、なんてのはありふれた話だ。会社員歴十何年の人間が、赤字部署で一度も利益を上げたことがなく嫌気が差しついには退社し増田に入り浸る、というくらいありふれた話だ。
だから、多少の通信の秘密の暴露がなんだというのでしょう。これは開き直ったギャグでもなんでもなく、真面目にそう思います。
そうでもしないと大企業に勝てないし、潰される。あらゆることは大企業が占拠している。中小ベンチャー企業にとって、それをかいくぐったビジネスモデルは死活問題だ。たとえそれが法の穴でも……タックスヘイブンで何兆もの税金を現地に還元していない大企業の脱法行為に比べれば、可愛いものじゃないか！
私は、設立2016年、資本金1億の凡百弱小スタートアップ企業である貴社を応援したくなった。
ふてぶてしくサービスを続けてほしかった。私は クソ野郎なので、そのときはもちろん 貴社 を批判をしているだろうが、SmoozはかつてのLINEのように批判されながら成長する余地があったのではないか、という気がしました。
貴社のような弱小凡百無名スタートアップ企業がセキュリティ人材を雇うのは難しいでしょう。優秀なセキュリティ人材も、 貴社を目にも止めなかったでしょう。もしかしたら、国内ブラウザの開発という、一種のエンジニアの憧れを源泉にビジネスをスタートアップにした時点で、そのフロントエンドの複雑広大なドメイン知識をキャッチアップしきれるはずもなく、セキュリティを二の次にするスタートアップ企業である貴社は必敗が約束されていた……と考えるほど、私は人の夢を悲観的に捉えてたくないのですが、やはり生き残るには、批判を跳ね返す強靭なメンタルが必要なのでしょう。たとえ瑕疵が貴社にあったとしても。 "面の皮を厚く"せねば生き残れないなら。
それとも貴社は、本当は邪悪な情報売買事業者で、さっさとトンズラこいたのか？
「さっさとトンズラ」なんて簡単に言ってくれる。そうですよね？
どっかの誰かに「漫然とインターネットをしている」とキレられたお前らへ。
はてブに聡慧たるコメントを残している皆様におかれましては、Smoozとかいう弱小ブラウザが、他ブラウザであるSafari、Chrome、諸Microsoft製品、その他製品諸々と比較していかにevilであるかをご存知でしょう。
どんなページを見ているかがアスツール社に筒抜けであるのは嫌ですが、どんなページどころか年齢、性別、検索履歴、趣味嗜好、各サービスのアカウントとパスワードは大企業たるGAFAM様には筒抜けでも一向に構わない、という理由付けがあなたの中にあるということです。アスツール批判していてLINEやってる人はいないですよね？それとも最近のLINEはクリーンなイメージだからもう大丈夫、と自分を納得させましたか？
ところでChromeのパスワード管理機能はすごくて、どの端末で開いても、Chromeに自身のアカウントでログインすればその機能が使える。つまりパスワードはサーバで管理されているというわけです。たとえ同期パスフレーズがデフォルトで有効ではなくても、Googleはグローバルビッグカンパニーでnot evilなので、情報を売るなんてセコい商売をするわけがないとハナから信頼されているからこそ許される行為なのです。
「Googleは閲覧履歴を少しずつわからないように販売している 」という発想に私たちがならないのは、Googleはそんなことしなくても事業で成功しているからなのですが、「実はその心理的死角をついて」「裏をかいて」という発想すらもならないのは、やはり単純にGoogleがビッグすぎるからでしょう。一方、弱小貧弱キングボンビーである中小零細企業は、少しでも怪しい所があれば、単純な知識・技術不足 というよりも （弱小企業ゆえにこっちのほうがありえそうな話だとしても）、「あたりまえのように」悪意を疑われてしまいます。
結局、Googleは邪悪な情報売買事業者ではなく、アスツール社は邪悪な情報売買事業者で"ありうる"、という判断があなたの脳内で線引きされるのは、単にアスツール社が弱小凡百零細の聞いたこと無い企業であり信頼が足りない、ということ以外に理由はなく、Googleがやっている「検索履歴やキーワードから適切な広告を表示している」というのが想像以上にドラスティックで大規模にもかかわらずグローバルスタンダードになっているので、それに比較して アスツール社が「本文をぶっこぬいて送信しているから怪しい」というのは、「やり方がせこくて本流ではなく、マナーがなっていない」程度のものでしかないわけです。つまり私はマナー講師が嫌いなので、マナー講師たるお前らに腹が立っているわけです。
四者四様、いや自分を含めたら五者五様に怒りが沸いてくる。これは理不尽な、行き場のない怒りだ。大企業の不祥事は書類送検だが弱小企業の社長は懲役刑になるような理不尽さを見たときの怒り、自身の棚上げ癖と、過去の爆弾を思い出したこと、それを指摘されたように感じた羞恥に似た怒り。界隈のキャリアアップの方法が、受け入れがたいにも関わらず常識になっていることへの怒り、自己矛盾、考えがまとまらない怒り……私には世界がわからない。ビジネスに成功したためしがない。セキュリティもわからないし、なんなら上手な人間関係もわからない。アスツール社が邪悪かどうかの真実もわからない。ただ開発者の気持ちはわかる。あの頃、やばいね、ああやばいねと隣の同僚と話していた頃を思い出す。今、Smoozの開発者の席に、私がいるような気がして、それを考えると、全ての善悪を超えて、みんな許してやってくれんかね、と思うけれど、そういうわけにはいかないだろ、とイライラが一向に収まらないんだ。
DDDだとか、クリーンアーキテクチャだとか、まぁいろいろ言うんだけど、ぶっ壊そうと思えばいくらでもぶっ壊せる。
「んー、このビジネスロジック、DBからあのデータ必要だなぁ・・・せや！ここでDBアクセスしたろ！SELECTだけやしへーきへーき！俺天才！テストコード？なにそれ美味しいの？ｺﾐｯﾄｯﾀｰﾝﾌﾟｯｼｭｯﾀｰﾝ」
みたいなのをどうやって止めるのか。
よし、お前の熱い気持ちしかと受け止めた。バズるのは時間帯が悪かったと思うので、次に投稿するときには夜ご飯ぐらいがいいよ。それでは添削してやろう。
継承はだめ、という主張はわかるぜ。継承のネストが深くなるとメンテナンス性が落ちるし、習い初めのバカは勝手にクラスを使うからな。これは同意する。
そう、昨今の業務では継承とか使わない方が良い。何故か？フレームワーク上でビジネスロジックを記載する時代だからだろ？でもな、そのフレームワーク自体はテンプレート・パターンといったパターンが満載で、アスペクト指向を介してログを排出しているのよね。まぁ、素人に継承を使わせるのはキチガイに刃物なのは事実だが、今という時代はフレームワークで刃物をラップできている時代だと思えば、悪くないと思うよ。うん。
リスコフの置換原則は、継承したメソッドは上下で型の変化を無くせ、というだけだろ？それは、ちょっと能力検定には弱いよね？SOLIDの原則について調べてみよう。
ブロックチェーンや暗号通貨、Web3.0、Dweb というのはここ数年、そしてこれからのバズワードであるようだ。
ここ一週間ぐらいだろうか。マイナンバーにブロックチェーンを導入しようとしている事業に関して色々な議論が発生しているようである。例によって議論に向かない Twitter 上で発生している。というか何が議論の中心になっているのかイマイチよく分からない。ただ雑然と荒れているという感覚がある。
私は技術・歴史・文化といった面からブロックチェーンや暗号通貨に対して知識がなく、学び始めたのはここ一ヶ月と言ってもいいだろう。学ぶ、といっても転がっている日本語の一般的なメディアの記事を気が向いたときに読み散らかすぐらいである。真に技術的なことは何一つ分からない。暗号通貨は Bitcoin とEthereum しか知らないし所持しているのはたまたま貰った僅かな ETH しかない。金銭的に貧しい多摩川に転がっている石くらいどこにでもいる17歳JKである。と逃げの文言を置いておく。
囲み取材で数十秒話したことが記事になっているので、正確に伝わって無さそうです。
・マイナンバーカードをいずれカード不要にしてスマホにインストールできるようにしたい
・その前にそもそも、普及のためマイナンバーカードの発行総数を増やす必要がある
という趣旨かと。
加納氏のこの時期のタイムラインから現在に向けて遡れば様々な第三者の感想や疑問を得ることができるだろう。これらに纏めて答えているのが以下の記事である。
ブロックチェーンの優位性①疎結合｜加納裕三/Yuzo Kano
https://blog.blockchain.bitflyer.com/n/n4b45329e308c
加納氏とは一体何者なのかは以下を参照。
東京大学大学院工学系研究科修了。ゴールドマン・サックス証券会社に入社し、エンジニアとして決済システムの開発、その後デリバティブ・転換社債トレーディング業務に従事。
2014年1月に株式会社bitFlyerを共同創業し、2019年5月に株式会社bitFlyer BlockchainのCEOに就任。
bitFlyer創業以降、法改正に関する提言や自主規制ルールの策定等に尽力し、仮想通貨交換業業界の発展に貢献。
日本ブロックチェーン協会代表理事、ISO / TC307国内審議委員会委員、官民データ活用推進基本計画実行委員会委員。
2018年G7雇用イノベーション大臣会合、2019年V20 VASPサミットに出席。
ttps://finsum.jp/ja/2019/speakers/recQMoKK5nD9yb8Ht/profile/
ブロックチェーンを語るうえで何が重要かというと、その言葉の定義である。議論に参加している人が同じ言葉を使っているのに、各人の言葉に対する定義が異なっていると、言葉は理解できるが内容が理解できないといった状況に陥ってしまう。このことは実生活でも頻繁に起こっているように思えるが、Twitter という短文が好まれるプラットフォームでは著しくないがしろにされ不毛な議論を生む原因になっている。
加納氏が代表の JBA （日本ブロックチェーン協会）に依ると、ブロックチェーンの定義は以下の内容である。
ブロックチェーンの定義
１）「ビザンチン障害を含む不特定多数のノードを用い、時間の経過とともにその時点の合意が覆る確率が0へ収束するプロトコル、またはその実装をブロックチェーンと呼ぶ。」
２）「電子署名とハッシュポインタを使用し改竄検出が容易なデータ構造を持ち、且つ、当該データをネットワーク上に分散する多数のノードに保持させることで、高可用性及びデータ同一性等を実現する技術を広義のブロックチェーンと呼ぶ。」
定義策定のアプローチ
まず、Satoshi Nakamoto論文およびその実装である、ビットコインのブロックチェーンをオリジナルのブロックチェーン(以下「オリジナル」)として強く意識しています。
狭義のブロックチェーン(定義１)は、オリジナルを意識し、それが備える本質的で不可分な特徴を捉え、言語化しました。
広義のブロックチェーン(定義２)は、昨今〜今後の技術の展開を鑑み、オリジナルが備える特徴であっても、別の実装方式や別の目的への展開などにおいて、置換や変化が行われていく広がりを許容しながらも、特徴を捉えられるよう、言語化しました。
総務省のページも見つけたが JBA が定義するものを基礎としている。
ttps://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h30/html/nd133310.html
私が疑問と漠然としたモヤモヤ感を抱くのは、最近の一般層で使われているブロックチェーンの定義には「信頼できる第三者が不要である」という点が抜け落ちているように思われることだ。非中央集権SNSで暮らし脱中央集権を推進したい私にはこの点が"ブロックチェーン"の一番重要な点であると思うが、JBA の第一定義にはこの点が記載されている。不特定多数へのインセンティブによって不特定多数による合意を形成している。これによって「信頼できる第三者が不要である」は満たされている。
blockchain (3.6)
distributed ledger with confirmed blocks organized in an append-only, sequential chain using cryptographic links
Note: Blockchains are designed to be tamper resistant and to create final, definitive and immutable ledger records.
distributed ledger (3.22)
ledger that is shared across a set of DLT nodes and synchronized between the DLT nodes using a consensus mechanism
Note: A distributed ledger is designed to be tamper resistant, append-only and immutable containing confirmed and validated transactions.
ISO の定義によれば、ブロックチェーンは、暗号化リンクを使用した一連の鎖で、追記のみで構成された確認済みブロックからなる分散台帳を指す。改ざんに強く、最終的で確定的で不変の台帳記録を作成するように設計されている。分散台帳は、一連の DTL（分散台帳技術）ノードで共有され、合意メカニズムを使用して DTL ノード間で同期される台帳である。確認された有効なトランザクションを含む全てが、改ざん耐性、追記のみの不変性を持つように設計されている。
さて、加納氏の投稿やその他の加納氏に批判的/賛同的な人たちの反応を見ても、彼らの言っている内容がブロックチェーンの定義を満たすものなのかいまいち分からなかった。
・ビザンチン耐性（BFT)
・改ざん耐性
私はブロックチェーンの主な利点はこの５つ（ただし５つにだけではない）だと考えています。これをここでは５大利点と呼びます。
なおかつ、この５大利点を概ね満たしているものをブロックチェーンと呼んでいます（ただしブロックチェーンと呼んでいるものは、すべてこの定義だとは言ってない。かつ、ブロックチェーンの厳密な定義はこれではない。）
なぜ前提として厳密な定義を加納氏の言葉で説明せずに、勝手に加納氏が定義した内容を”ブロックチェーンである”と語っているのか理解に苦しむが、加納氏の説明したい"プライベート・ブロックチェーン"を ISO の定義を基に判断すると、
加納氏の上記の2つの投稿からは、"プライベート・ブロックチェーン"と"パブリック・ブロックチェーン"のどちらを指しているのか不鮮明ではあるが、note の記事では"プライベート・ブロックチェーン"を想定している、と明記されており、議論の発端となったマイナンバーとブロックチェーンに関しても"プライベート・ブロックチェーン"を指していると思われる。5大利点を満たす"プライベート・ブロックチェーン"は存在しないのでは…。
"一方で、誤解と批判を恐れずに書けば、ブロックチェーンがBitcoinの論文に端を発するものであるとするならば、いわゆるプラベートブロックチェーンやコンソーシアムブロックチェーンと呼ばれているものは、ブロックチェーンと呼ぶのをやめて、「タイムスタンプ2.0」のような別の言葉を使うことも考えてはどうだろうか。それは、これらの技術が、リンクトークン型タイムスタンプのデータ構造の上に、決められたノードによる合意アルゴリズムを加え、記録した情報に対するビジネスロジックに応じた情報処理を加えたものであるからだ。根っこの技術は、同じHaberらによるタイムスタンプを元にしているものの、ブロックチェーンの発端となったBitcoinの論文が目指した「信頼できる第三者機関を不要にする」という方向とは別の方向の進化をしているもので、その別の2つの方向のものを同一の枠で扱うことには無理があり、理解や発展を考える上で両方にとって弊害がある。"
https://link.medium.com/TgeOXv8Dlab
https://link.medium.com/4pz5oNlHpab
これらの記事を読むと、そもそもブロックチェーンと呼ばれるものにおいてパブリックではないものは、なんびとも信用しない状況において根本的に非改ざん性を保障することができないのではないかと感じる。"パブリック・ブロックチェーン"こそがブロックチェーンであり、他のものはブロックチェーンから発展してきた技術を使ったブロックチェーンの定義を満たさない分散台帳なのではないか。
加納氏に関して覚えておきたいことは、彼は bitFlyer の CEO であり bitFlyer は miyabi という"コンソーシアム・プライベートブロックチェーン"を開発しているという点だ。当然行政に対して彼がブロックチェーンを推しているのはこれを売り込むためなのであろう。これが厳密にブロックチェーンなのかは置いておいて、このプロダクト自体は素晴らしい取り組みだと私は感じる。デジタル化によって今までの煩雑な手続きが簡単になる可能性は大いにあるし、公的文書の保存にも役にたつ。黒塗り秘匿文書を撲滅しろ。
ただ、ブロックチェーンをただの空虚なバズワードとして扱うのではなく、厳密な定義の上で使うのは大事なことだ。今回の件は、果たして全てにおいて加納氏が良くない、と言えるのだろうか。言葉というのは多数が使うことによって定義が決まる。時代が変われば定義が変わってしまうこともある。ブロックチェーンという言葉を便利な魔法の言葉にしてしまったのは誰だろう。本質を見極めない我々だ。AI 搭載！！といたるところで見る言葉だが、何をもって AI と呼んでいるのか不思議になる。実際のところ今まで"システム"と呼んでいたものなのに。日々の中で言葉をしっかりと見つめ直すのは大事だ。
この記事は、そもそもブロックチェーンとは何か、という個人的な疑問をまとめたものであり、加納氏を批判する意図は無かったわけで、最後の締めはやんわりとしたかった。だが、加納氏は立場的には日本ブロックチェーン協会の会長で、言葉を定義する立場である。言葉を定義した側がこの有様というのは遺憾である。日本の行政のデジタル化の推進は頑張って欲しい。
