適用領域の重要性
今チラッと出た、適用領域っていうのはどうでした?呼んでて。
ぴっくりすることにね。全く同じ場所にハイライトしてて。やっぱそこだなと思ってて。
主題と特に重要なキーワードの一つな気はしますね。
自分たちがシステム化しやすいからとか、システムとして扱いたい。何なら過去に扱ったことがあるから、システムを落とし込めばいいんやっていって。
解こうとした問題と、適用領域みたいなものを間違えてしまうと、うっかり動いてるんだけどうまくいかないよね、みたいなことになっちゃって。
これはまさにワインバーグのライトついてますか?でも、このパッケージソフトを使えば数字に計算ができるんですよ、みたいな話があって。
でも、顧客が本当に解きたい問題ってそれだったんだっけ?みたいな話もあったから、同じこと言ってるなって。
ちょうど前回読んだ本がそうだったから、全く同じようにパラレルで全く同じこと言ってるなこれって思いながら結構読んでて。
多分このアプリケーションドメインみたいなものを考えるときに、いわゆる世の中でDDDだっていう話があるんだけども、
適用領域、アプリケーションドメインっていうものがどうなってるかっていうものをシステムに落とし込むことを前提にいろいろ見ていくと、
システムに引っ張られて結果、うまくシステム化されてないってことに落ちてしまうんじゃないかな、みたいな。
この本当に顧客が解きたい課題っていうものが何で、何なら顧客もまだ分かってない状態で、何を解きたいかっていうものをどうやって引き出していくかっていうことも
あわせて考えないとシステム化しやすいから、こういうファイルがあって、ここにはCSVでこういう風に値が入ってるんで、これをこう処理すればこうなるよねっていうことは
多分インプットがあって処理があってアウトプットがあって定義しやすいし分かりやすいんだけども、ただそれに引っ張られてしまうと
何か課題が解決されたかっていうのはまた違うよねっていうような風に思ったりもして、だからこういうふうにすごい気をつけないと
みんなハッピーになっていることで、ハッピーになっていないことが起きるんじゃないかなっていうのを読みながら思っちゃいましたね。
実装の影響とバイアス
でですね、適用領域の章の最後に、最後のパラグラフの出だしのところで、肝心な点はもちろん適用領域を見分けることとそれを機械から区別することであるって書いてあって
なんかゲイさんが言ってた、道具ありきでこれをもっと良くしましょうは、なんか本当に機械、マシーンの方の問題でしかないのに
そこに解決する価値がすごいあるんやっていうすごい作語から始まってるような雰囲気があって、いい本領を向いてきたな
しかも今絶対AIで何とかって話いっぱいあるわけじゃないですか
今ですね、今ちょうどクロードに適用領域は何ですか、簡単に教えてくださいって聞いてましたよ
だからAIでこれを解決したいとかってやるし、自分も実際それでこれAIでやったらパッとできそうだよねって言ってパッとやっちゃうんだけど
なんか、やらなくていい仕事をやりそうだからやってしまうみたいなことは絶対あるはずで
それってただ単にトークンの無駄遣いじゃんとか、AIが動かす電球の無駄遣いじゃんみたいな状態になってしまうんだよなっていうのはすごく思いますね
なんかね、因伝と揃えるとかね、すごい便利ですよね
便利、便利ですね、確かに
なんか少し工夫のいる正規表現、肩代わりしてくれて便利と
そうそうそう
まあそれは言い出してたんですけど
適応領域っていう言葉自体はどうでした?なんか僕なかなかこれはすげー難しい言葉だなと思ったんですけど
まあいかせね2回目なんで読んだの、完全に理解したと思うんですけど
僕好きだったのが問題は適応領域の中にある的な表現がされてて
適応領域って何なのよみたいな話も言わないといけないと思うんですけど
ここが難しいんですよね、だから苦労度に聞いてたという
重要なのはソフトウェア開発の問題は適応領域の中にあり、マシンはその解決策であるという視点です
それ今読んだやつじゃんっていうね
トートロジー
同じこと書いてある
トートロジー
適応領域とはマシンに影響を与えまたマシンから影響を受ける現実世界の部分です
って苦労度は言ってますがあってそうなんですけどね
なんか自分も適応領域ってものを上手に自信持ってこうですって言えば言えないけども
現実の世界ってものがあってその中を全部を対象にしようと思うとやっぱ
じゃあ重力はどうしますかとかなんですけど
いろんなこと、システムを考える上で全てを考えることはやっぱ無理なので
じゃあどういう方向から見てどういう風にあるものをフォーカスして扱いますかっていう風に
いろんなものを制約条件、制約条件というかモデリングして
この世界との中をどういう風にモデリングしてどういう風に切り取って
このままだと世界の一部みたいな言い方をしてるけどその世界一部を作って
それがシステムによってどういう風に変化を受けるのかみたいな
いうものが適応領域と言っていいのかなって思ったりとかしましたね
誰がいて何をやってるんですかっていう
投開付けられたコンテキストみたいな感覚に近いのかもしれないですけど
誰にでも役に立つとかこういうソリューションがあるから
いろんな人に使ってもらおうっていうよりかは
こういう人たちがいてこういう動き、社会だったり世界だったりっていうのが今あるよね
そこの中に機械って言ってるのはソフトウェアのこと機械って言ってますけど
そういう世界に何をもたらしますかどういう風に作用しますかっていう世界観ですよね
適応領域があってそこに機械があって
適応領域の中で機械が世界そのドメイン領域に影響を与えるっていう風な考え方
なので適応領域が何なのかそこで何が起きているのかっていうのを見誤ると
もちろん意味のある価値の高い機械っていうのができないから適応領域は重要である
適応領域の中において機械が何をなすかもしくは何を機械がなさないでいいのかっていうのをちゃんと区別して考えないと
課題制定というかこれが問題だよなっていう定義を非常に誤るよねっていうような感じですね
そうなんですよねそうなんですよねだから前提になってくるんですよね
いろんなものをやる上でのこの前提が見誤ってるとそんな話聞いてないんだけどみたいなことがいっぱい出てきたりとか
その前提の中に曖昧さだったりとかはっきりと私はこう思うっていうだけの表明ではなくて
ちゃんと記述ができるような形になっているようになってないと
今日言ってたことと明日言ってたことが全然変わっちゃう変わっても別にいいと思うんですけど
いいと思うんだけどもいいものを作ろうと思った時にはコロコロコロコロそこが
その日の気分によって変わりますだとちょっと難しくなっていくよねっていうような感じですよね
適用領域なアプリケーションドメインっていうと聞いたことありそうな感じのする言葉になる
アプリケーションスラッシュドメインズとかってディレクトリー見たことある?みたいな
なんか嫌な記憶が読み起こされるような気持ちになっちゃいますけど
そこに本当にアプリケーションドメインが入ってるのだろうかみたいな気持ちは
確かになあとねネームスペースのルートをねドメインだったりアップだったりしがちなの
そうそうそう
適用領域から関連して派生してなんか次ここ行きたいなとかありますか
何をといかにとかもあるんだよな
そうですね何をといかにとあと実装の影響とかは結構
中央順だからマジで無口が見えそう
そうそういう意味ではこれ別に
インデックスがマジでインデックス
こうちゃんとB3でたどれるなみたいな気持ちになりますよねこれ
実装の影響はどういう話と捉えました
これ実装の影響と書いてあるんですけど
インプリメンテーションバイアスって書いてありますね
そうバイアスって書いてあってあれって思って
だから影響ってよりはバイアスなのかなみたいなことをちょっと思いながら読んでいて
この本の中にはページにあることをちょっと自分はページ数わかんないんであるんですけど
80ページから3ページ分なので勘で
その中で我々が注意をどのようにそれを実現するかに向ける前に
システムは何をすべきものかに集中する理由の一つは
我々システムの使用を実装の影響から自由にしておきたいからである
すなわちシステムが何をするかに関する技術がどのようにそれを実現するかという都合によって
影響を受けたり歪められたり混乱させられたり汚染させられたりしてはならない
そうした影響を受けていない仕様は理解しやすいはずであるっていうような話があって
これめちゃくちゃ大事だよねと思ってて
これあれですねいわゆるそれはハウないよ
そうそうそうそう
ホワイオンください
そうそうそうそうだからAIでこれを何とかこうこうこうしてくださいとかって言われて
いやでも解きたい課題それじゃないでしょとか
そのシステムが変わったらどうするのみたいな話になってたりするやつで
結局そのソリューションみたいなものを考えるときに
やっぱりどうしても我々の頭の中ではパッとそれを見た瞬間に
データベースにこういうものを突っ込むのかなとか
テーブルはこうこんな感じになってるのかなとかいうようなことを考えて
結局そこに引っ張られながら仕様を決めちゃったりすると
それで実現できなかったときにどうしようかとか
結局は本当にいろいろ触っているものを見ていく中で
やりたいことっていうのがそうじゃなくて実はこうだったんですみたいなことが分かったときに
全部そのデータベースの制約だったりとかプログラムの制約だったりとか
一度決めちゃったURLでも何でもいいんですけど
そういうものに全部引っ張られちゃったりとかして
それやるとちょっとコースが大変でみたいな
それをやってしまったのはあなたではないんですかみたいな気持ちになっちゃうんですけど
そういうところに汚染されたりしてると辛いよねとか
そういうもののありきで仕様を変えてしまったりすると
本来やりたいことっていうものがどんどん見えなくなっていくっていうのはあるよねと思って
だからこそやっぱりアプリケーションドメインにちゃんとフォーカスすべきなんだよねっていうことをすごく思いましたね
要求と仕様の違い
なんかこの本じゃなかったところで読んだ気がしてて
この本にも似たようなこと書いてあるんですけど
要求と仕様の違いみたいなことを言ったときに
要求と仕様の理解
要求はそのシステムの単語を使わないで表せるものみたいな言い方してる本があって
だからそれはすごいなるほどなって思ったんですよね
だからデータベースとかAPIとかバッチ側とかっていう言葉が出てこないんですよね
ボタンを押すととかインターフェースとかっていう言葉が要求の世界では出てこないはず
そこら辺はもう実装の話だから仕様だよね的なことを言ってて
っていうのを思い出しながらあと今ゲインさんの話聞いてて思ったのが
現実世界の中に機械があるじゃないですか
要するに今生きてるのは適用領域アプリケーションドメインのはずなんですけど
我々の生活の中にそのマシーンはあるわけですよね
カウの塊の装置があってそこに依存しながら生きてるわけじゃないですか
こいつがない世界の言葉が本来の純粋なものなので
純粋な言葉でおしゃべりしてくださいって言われても難しいわけですよね
そうですね
だからゲインさんがコーヒーのない世界を想像してくださいって言われても難しいわけじゃないですか
そうですね
コーヒーを思い浮かべてそのコーヒーがない状態を考えちゃう
だからそこら辺も要求っていうのをちゃんと出す
ちゃんと出すっていうのはかなり独特な言葉遣いというか
英語の人だったらちょんちょんっていうダブルコーテーション付きのちゃんと出すみたいな感じだと思いますけど
機械のない世界を想像するっていうのはやっぱり難しいですよね
そうですね
訓練が必要だし
プロトタイピングとかでもそうですけどやっぱり動くものを見るとそこからアイデアが生まれるわけじゃないですか
何が足りないなとかこういうこともできるかもとか
いい刺激になるな
それをもたらすゲイン戦として機械必要だよねってなると
適応領域
それこそ213ページ要求のところを見ると
要求は適応領域の現象であって機械に関するものではない
とかってことは出てくるんですけど
これは難しいぞっていうふうな気持ちが今めっちゃしてきましたね
適応領域と実装の関係
いやわかります
結局iPhoneやパソコンだったりとかいろんなものがある中で
だから自分たちのその適応領域と
の中にあるコンピューターの足と適応領域の外側にあるというか
外側じゃないな適応領域の中にあるんだけど
自分たちが今から構築しようと思ってるマシーンの話とそうじゃない
所有の条件としても世の中に存在するものを区別しながら喋んないといけないって話ですよね
多分今のって
自分が持ってる知識を手放すの難しいですよ
ましてや経験に強く紐づいているものなんて
してるの難しいですからね
ある種こういうブラックボックスのものがあるじゃんぐらいな
ざっくりとした感じで説明をしないといけなかったりとか
でもその一方でメタファーはすごい良いメタファーって感じされるじゃないですか
メタファーは要するにすでにあるものをコンセプトとか概念として拝借してくるっていうのは
もうなんか偶像の塊でしかない
のにそれは歓迎される
けどそこが少しでも解決領域という機会の話になっちゃうと
ちょっとそれは違うんでって言われる
そうなんですよねだから
多分システムの話って言った時に
例えばAWS上に何かシステムを構築しましょうって言った時に
AWSってことは別に使ってもいいと思うんですよね
別にクラウド上で何かを作るでもいいんですけど
でもそこっていうのは別に右のものに置き換えできますよみたいな
自分たちの世界とはまた別の世界に構築しようと思っている
やりたい解決したいことのものとは
の世界とそうじゃない世界があってみたいな
中小に依存するぐらいいいですね
AWSっていうのがコンクリートじゃなくてインターフェースとかアドストなら
クラウドのことを手言うというか死に行く時というか
AWSって呼ぶというか
そこで言うAWSっていうのは実際クラウドを言いたいためにAWSって言ってるだけかもしれないし
あれですね
家庭用テレビゲーム機のことファミコンと呼ぶみたいな
そうそうそう
なのでそもそも我々の言葉遣いってものにもすごく気をつけないといけないし
自分たちが喋ってる領域ってものがアプリケーションドメインなのかそうじゃないのかっていうことも
いちいち気をつけながら言わないと
結局今何の話してるんだっけとか
できるだけマシーンの話をしないようにしてるはずなのに
それ使った瞬間にマシーンの話引っ張られるよねみたいな話になっちゃって
それはマシーンの話をしたいではないんだみたいな
いう感じになったりとかして
これはたぶんそんな
さっき金城さんすごく訓練しないとこれはうまくできないって言ってたけど
本当にたぶん訓練しないといけないし
この本の中で術語論理だったり論理学だったり
話がいっぱい出てくるけども
ある種自分の中では言葉の厳密さみたいなものを大事にする
哲学者みたいな人たちが考えてるように
システムを作るとかシステムのものを記述するっていうことを
大事にやらないとうまくシステムは作れないんだよって言ってるような本でもあるな
っていうふうに思ったりもしましたね
要求が純粋みたいな感じが
いい要求って要するに機械とか現実性
解決領域リアライゼーションの影響から免れた
ちゃんと純粋な要求みたいなものが
イデアを探るみたいになりますけど
この世界この世界って言ってるのは地球上のどこかっていうか
もっと崇高な精神的な何かかもしれないし
次元が違う話かもしれないけど
この世のどこかには純粋な要求なるものがあるのかなっていう感じがしてくる反面で
結局ビジネスというか現実世界の話なんで
要はバランスで進む話であるんですけど
純粋な要求ってそんなに何がいいものなんだっけっていうのはちょっと
わかんなくなってきませんそんなに嬉しいか本当かみたいな
問題が解ければいいですからね
問題が解ければ動けばいいですからね
動かないと話にならんし
だから多分自分は思ったのは
どういうとこで罠にはまりやすいかとか
要はここ注意ポイントだよみたいな感じなのかなと思ってて
要求を引き出すとか仕様を書くとかいうときに
あんまりこのIDっていうのはデータベースのオートインクリメントの値でとか
そんなことやんないかもしれない
最初の頃ってこうやってデータベースで番号振られるから
これユニークになってとかっていって
抽象度が全然違うものを
抽象度だったり世界が違うものをごちゃっとした結果
実現したいことがうまく伝わらないとか
実現しようと思ったときにあれなんかおかしなことになってるとか
あれこっちがおかしいってことは向こうもそれに引きずられておかしくなるな
いやなんかこれ仕様が間違ってるんじゃないですかとか
そういう変なことが起きてしまう
キャッチ22みたいな話がこの中の本にも出てきたけど
どうしようもならないみたいな状態が起きてしまう
そういう罠から逃れるためには
そういう純粋な世界みたいなものを探求する必要があるんやみたいな
そんな感じなのかなと思ったりしましたね
なんかあれですね人を賢くする道具的な世界観な気がしてて
抽象度の重要性
これ用途ですって言われて
この本だとエレベーターの話が出てくるんですけど
なんか上向きの矢印が書かれたボタンを押したら
上のフロアに行くみたいなのは
もうこれはエレベーターっていう
偶像物を扱ってるからこれはもう完全に仕様なんですけど
ユーザーが生きてる世界って
目的とするフロアに落としていきたい確実にいきたいなんですよね多分
だから上のボタンとか
なんかでけえ箱が上に動くとかって言ってるのは
多分アウトなんですけど
ただその上を押したら
上を押したら上のフロアに行くようにしてくださいって言われた方が
ああはいはいOKですって言って
学名通りに受け取って実装するのは非常に楽ですよね
そうですねそうですね
概念的なところから偶像に落とすみたいな
行ったり来たりを行う必要がなくなるので非常に楽なはずだし
それを要求だと思って出してる側も
自分が望んだものができたかどうかっていうのが
確認しやすいので楽なはずなんですけど
視野を狭くして実装っぽいところに足を突っ込んだまま何が欲しいです
こういうことを実現したいですっていうと
やっぱりバグは踏みやすいですよね
そんなこと言ってなかったじゃないですかっていうエッチケースというか
抜け漏れが発生しやすかったりするのかな
その抜け漏れっていうのは思ったものができないっていうのもそうだし
効率が悪いやり方を間違ってるんじゃないかって
100年後に言われるようなやり方をしてしまうみたいな話もそうだし
最高の回答にたどり着かないで終わっちゃうっていう意味でのミステイクもあるかなっていう気がするし
って考えると純粋な抽象度が高いっていうのかな
実装っていうのを低レイヤーとして
願望っていうのを本当に高いレイヤーの話だとしたら
高レイヤー抽象度の高いところの話ばっかりで会話して
それを受け取って実装するっていうのは非常に
受け取ってこれから考えるぞって人がめっちゃ頭使わないといけない気がするので
人を賢くする道具であったいい道具とは内省を促す
近いなって思って今
疲れるんだな
抽象的に抜け漏れなく提起されていると
この時どうなるんだろうっていうことがたぶん
自ずと導かれるみたいなことはあると思うんですよね
ただ一方であまりにも抽象的な
例えばこの本の中では数学っていう項目があったりとかもしましたけど
抽象度高く記述していくと全部述語論理で
2のXが何とかをするときにはYはこうなるみたいな
全部数式で表すみたいな抽象度最終的に高くすると
全部いわゆる述語論理の背景で全部書けるようになってしまうと
たぶんこれって何やりたいんだろうってわからなくなるんで
たぶんそこまで行き切ってしまうとわけわかんなくなるから
要求と仕様の明確化
ある程度の愚症に降りていくしかないのかなって気がしていて
さっきのエレベーターっていうのはみんなが見知ってるものだし
認識錯誤が起こりにくいようなものだと思うんですけど
ソフトウェアってこの時に作ってる 95年とかに作ってるものって
これからソフトウェアってものをみんながどんどん触っていくとか
体験していく中でどうやってやりたいことを伝えればいいかわからない
っていうような状態の中で要求ってものを言っていかないといけない
記述していかないといけないっていう場合においては
どうやったらうまくいくんだろうねっていうような背景の中で
いろいろしゃべってるのかなっていう気もしていて
じゃあその仕様を書いたりとか要求から仕様に落としていく中で書かないといけない
いろんなこと記述しないといけない 具体を記述しないといけないってなった時には
適用領域の状態 これは本にあるんですけど
もし仕様の中で何らかの状態を記述しなければならないとすると
それは機械の状態ではなく全て適用領域の状態でなければならない
っていうようなことが書いてあって
要はさっき言えばマイスケールのコアオートインクリメントの値でみたいな話ではなくて
これにはこういうふうな例えば決済番号が振られていてとか
その適用領域の中で新しく概念を生み出して
これじゃないものであればそこに言葉を与えて
この言葉っていうのはこういう定義でこういうふうなものですよっていうことを
どんどん与えていくみたいな
言う必要があるんですよっていうようなことを
この中でも言ってるかなと思っていて
そこが結構解決策になるのかなみたいな
さっきの抽象と具体みたいなところで
具体に行くときにどんどんマシンの世界に寄ってしまうんじゃないかっていうところを
そうではなくて言葉がないんだったらちゃんとそこに言葉をつけて
うまく適用領域の中で完結できるような状態を作ってあげるっていうのは
大事なのかなっていうような気がしましたね
抽象と具体のバランス
なるほどね
そうすると指キタス言語みたいな話にもつながってるんですかね
指キタスですもんねどこでも通用するって言ってるぐらいだから
最近読んだ関数型ドメインモデリングって
Fシャープでドメインモデリングしながら実装を書いていくっていう本の中でも
同じような話があって
やっぱりこういう言葉っていうのは
例えば配送済みっていうのは配送の商品があって
これがトラックに乗ってこうこうこういう状態になったことを
配送済みって言いますよっていうのを
配送済みって言うと何とかテーブルのこのフラが1でみたいなことって
実装の世界では多分言ったりすると思うんですけど
例えばその段ボール箱に詰めてそれを週間に来たものが
トラックに乗せて配送されたっていう状態っていうのを
どうやってその適用領域の中の言葉を使って
これとこれとこれを満たしたものが配送済みですよ
みたいな書き方をしたりとかしていて
なんかこれすごい
なんかここでこの本で言ってることと
直近読んだ関数型ドメインモデリングってものが
すごく紐づくなって思ったりとかしながらちょっと読んでましたね
でもそうなってくると
それはあとプログラムに変換すればいいだけって考えたら
結構簡単じゃんっていう気持ちになったんですけど
多分絶対そんなトランスファイルできないんですけどね
その便利な用途ができれば
パドルは下がる
そうそうそう
それでも集約と物理的なパフォーマンスの問題とかっていう
トレードファー出てくるかもしれないですけど
実際はどっかでデータベースにID振ってとか
いろんなものは出てくるんで
厳密にはその実装と使用っていうものが
パラレルにできないけども
じゃあこれは何ですか
配送済みってどういうことですかっていった時に
なんとかテーブルが1になってるとかではなくて
これとこれとこれを満たしたものですっていう風に
しゃべれるようになって
それを満たしたっていう状態って
プログラムでどう表現されてるんですかねみたいなことが
ちゃんと紐づいて言えるようになると
多分うまく適応領域の世界と機械の世界が
上手に記述できて
それらがうまく噛み合った状態になるのかなっていう風に
思ったりはしましたね
なるほどな
あれですね
配送済みみたいな状態を
関数型だから型ではないのか
型というか
なんか配送済みモデルを
クラスとして定義しようではないんですもんね
そうですね
ある任意の配列みたいなものに
関数を適用していった結果
それを満たしたものだけが
フィルターされて出てくるみたいな
そんなイメージとして自分は結構捉えてますね
いや面白そうだな読まんとな
