
2025.02.18
AIが「嘘のデータ」を返してしまう アルペンが生成AI導入で味わった失敗と、その教訓
リンクをコピー
記事をブックマーク
大嶋勇樹氏:(スライドを示して)続けて「これはビジネスロジック?」(というもの)をもう少し見ていこうと思います。2つ目として、リクエストの形式チェックがあります。
例えば、リクエストの必須パラメーターが足りているかとか、データサイズは決められた範囲内かとか、そういうチェックがあると思いますが、個人的にこれはプレゼンテーション層でチェックすべきものだと思っています。
なぜかというと、リクエストは利用者とのインターフェイス、利用者との境界での約束事に対するチェックなので、プレゼンテーション層が実施するべきかなと思っています。
また、不正なデータというものは、後に進んでしまい下手すると何か登録されてしまう可能性もあるので、プログラムがうまく動いていない(時)などは、セキュリティ的にもなるべく先に進めず、できるだけ早く(異常を)検知して以後のプログラムに進ませないようにしたいので、(リクエストの形式は)プレゼンテーション層でチェックしたいなと考えます。
もう1つは、データベースとやりとりする必要もないので、簡単に実装できるという理由もあります。なので、プレゼンテーション層ですべきチェックかなと思っています。
(スライドを示して)またチェックのような話ですが、リクエストの形式より少しだけ複雑な条件チェックは、ビジネスロジック(で実施するもの)かと考えます。
例えば、SNSで自分には「いいね」できないようにするようなものや、TODO管理アプリみたいなもので、過去日のTODOは登録できないようにする(もの)とかですね。
これはロジック、分岐としてはすごく簡単で、実装としても数行ぐらいでできちゃうとか。数行かはちょっとわかりませんが、比較的簡単にできるかもしれないです。こういうもの(のチェック)は、私はビジネスロジックだと思っています。
なぜかというと、プレゼンテーション層は見た目などのUIに直接関わるようなことだけを知っているべきであって、こういう知識をプレゼンテーション層が持っているべきじゃないと思っているからというのが1つ(目の理由)です。
もう1つ、これは「GUIだからとかAPIだからとかコマンドだからこうしたいよね」みたいなルールではなくて、プレゼンテーション層の違いによらない、共通したチェックだと思うからです。
今回実装している、SNSで「自分には『いいね』できないというルールを作ろう」というのは、APIだからではなくて、そのSNSが本来持っているルールみたいなものです。なのでプレゼンテーション層の問題ではなく、ビジネスロジックじゃないかなと私は考えています。
ただこのぐらい簡易的なものになってくると、人によってけっこう意見が分かれることもあり得るかなとは思います。
(スライドを示して)そして「これはビジネスロジック?」の最後。データベースのデータとの整合性チェックみたいなものはビジネスロジックかなと考えます。
例えば、「リバーシ」(の中)でデータベースに毎ターンの盤面の状態を保存しているとして、前のターンの盤面を取り出してきて、(次に)指定された場所に石を置けるか判定する。ほかにも、ECサイトで購入リクエストした商品が購入可能かチェックする。
このような、データベースのデータと整合性をチェックするようなことは、まさにビジネスロジック(がチェックするべきこと)だと私は思っています。ビジネスロジックという言葉もある程度曖昧で、人によって違う意見を持ったりするので「私は」とは言っていますが、「これはビジネスロジックである」と言う人がほとんどだと思います。
「リバーシ」の例でいえば「石をひっくり返す」「(ひっくり返すとしたら)どの点がひっくり返るか計算する」みたいな処理もまさにビジネスロジックですね。
このように、アプリケーションが従うべきルールのチェックやルールを適用する処理が、まさにビジネスロジックの中心です。
(スライドを示して)ここで、ビジネスロジック層の処理をドメインロジックとユースケースの2つに分類して考えてみます。この2つに分類すると、実はちょっと整理しやすくなるんですね。
「リバーシ」で石を打つ時の処理の流れの例から「ビジネスロジックってここだよね」と言っていた部分をちょっと取り出してきました。ここには実は2種類の役割があります。
1個は、盤面に置けるかチェックしたり、石を置いたりひっくり返したりします。盤面に置けるかチェックするというのは、指定された点にもし置いた場合にひっくり返せる点があるか。もしなければ「そこには置けません」みたいなチェック(をすること)ですね。あるいは、石を置くとかひっくり返すとかの処理です。
これはシステムではなく、現実で「リバーシ」で遊ぶ時にも出てくるルールです。「こういうシステムだからどう」とかではなく、その物事に本質的に存在するルールをドメインロジックとかエンタープライズビジネスルールと言ったりします。今日はドメインロジックという呼び方をしようと思いますが、こういうルール、チェックみたいなものがまずあります。
そして、このビジネスロジック層で実装するものの中には、ほかにも処理の流れを実現するものもあります。どこかのサービスクラスかどこかに、データアクセス層を使って「盤面の状態を取得する」をして、盤面に置けるかチェックして、石を置いて、ひっくり返してデータアクセス層を使って、盤面の状態を保存する。
そんな感じの「なにかデータを取り出して、チェックして保存する処理の流れ」があると思います。そういうのは、ユースケースやアプリケーションビジネスルールと呼ばれたりします。今日はユースケースという言葉を使っていこうと思います。
こんなふうに2種類に整理すると、この後の「ビジネスロジックは実際どう実装するんだ」みたいな話が整理されやすくなってきます。
「リバーシ」だけだと少ないかなと思ったので、ドメインロジックの例をもう1例ぐらい挙げています。
「リバーシ」であれば、盤面に置けるかチェックする処理や、挟まれた石をひっくり返す2次元配列のうち、「この点とこの点を0から1に置き換える、石をひっくり返す」ような処理がドメインロジックの例です。
ほかにも、例えばホテルの予約のアプリケーションを作ったとすると、指定された部屋に宿泊できる人数の予約かどうかをチェックする(機能)があると思います。
指定された部屋のマスターデータを見て、何人まで宿泊できるかを確認して、「今回泊まろうとしているのは何人で、人数をちゃんと満たしているな」とか。ほかにも「この人は予約できる条件を満たしているな」というチェックがあると思います。そういうものや「何日前のキャンセルだからキャンセル料はいくらです」という計算をするとか。こういうのがドメインロジックの例です。
ホテルの予約の例は、電話予約や対面の予約など、システムなしで人間が対応する時にもチェックするルールだと思います。
もしも電話予約で、人間がちょっと気を利かせてルールを破ってなにかをやってくれる可能性もあり得なくはないですが、人間が電話予約を受けつけて「何人ですか?」と聞いたり、「キャンセル料はいくらです」という話をしたりする時にも登場するルールだと思います。
こんなふうに、システムなしで現実で同じことをやろうとした時にも出てくるルールは、まさにドメインロジック。ビジネスロジックの中でも、コアなルールのわかりやすい例だと思います。
ということで、この後ビジネスロジックの実装方式の話をしていこうと思います。
ややこしい話をしてきたので、いったんここまでのQ&Aタイムにできればと思います。質問はQ&Aにもらえればと思います。1つ(質問)をもらっているものがあって、せっかくなのでこのタイミングで回答しようと思います。
「ビジネスロジック層のクラスを実装する時の命名は、およそどんなものがありますか? Handler、Manager、Controllerなど」ということです。
ここからビジネスロジックの実装方式について少し話すので、そこで出てくる言葉もあるし、この後にServiceにビジネスロジックを実装する以外の方式の話もしますが、例えばServiceにビジネスロジックを実装する時であれば、“なんとかService”とか“なんとかLogic”という名前がついていることが多い気はします。
あとControllerについては、ビジネスロジックはコントロールをしたいわけじゃないというか、Controllerにビジネスロジックが書いてあることはよくあるのですが、ビジネスロジックを実装するクラスにControllerとつけるのはあまり適していないかなとは思います。
Controllerはテレビゲームのコントローラーを想像してもらうとわかりやすいのですが、ただ入力を受けつけるだけで、ゲームの大事な処理はしないところです。ただ手で触るところがControllerです。ゲームのコントローラーを想像してもらうと役割が見えてくる気がしますね。ただビジネスロジック層に刺さっているだけの、入力を受けつけるだけの部品がControllerです。
Handlerみたいな図形は、どちらかというと個人的にControllerの代わりのHandlerという名前を見た気もします。
あとは、Managerみたいな名づけも(見たことがある気がします)。確かにServiceのところがManagerみたいになっている例は見なくはないですが、Managerという名前自体はあまりいい名づけではないと基本的には言われると思います。
Managerというと役割をすごく広く感じやすいので、あまりつけないほうがいいと言われることが多い気はしますね。真っすぐいくと、“Serviceか、なんとかLogic”が多いとは思います。質問ありがとうございます。
では、質問をいただいた範囲では回答できたので、続きにいこうと思います。
(次回に続く)
関連タグ:
“1つの独立して動く要素”の内部を整理し直す 「改めて整理するアプリケーション設計の基本」で伝えたいこと
アプリケーションアーキテクチャ理解に必要な“3層構造” プレゼンテーション層・ビジネスロジック層・データアクセス層それぞれの役割
3層アーキテクチャで最も謎な「ビジネスロジック層」 “システムのコア”をゲーム「リバーシ」で解説
「ビジネスロジックの処理は2つに分類すると整理しやすい」 4つの例から考える、プレゼンテーション層・データアクセス層の見分け方
ビジネスロジック層内部の2つの実装パターンを比較 選択時に考えたい、アプリケーション設計の観点
「クラスごとの役割を明確化すること」がポイント アプリケーション設計におけるドメインロジックの分離法
重要なのは「基本を押さえ、適したものを採用すること」 “本来の役割”を押さえたアプリケーション設計
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
第20回エクゼクティブメンターイベント「今、「ひと」と組織が共創する〜働き方の未来へ」
2024.12.07 - 2024.12.07