ビジネスロジックに抽象性を持ち込む場合、本来のビジネス要求に存在しなかった抽象を示す語彙を新たに定義する必要が有り、「見知らぬ言葉」に最初は戸惑うのだけど、それが本当に本質を捉えた抽象であれば便利なのでビジネス側の人も使うようになる、とかなんとか
— magnoliak🍧 (@magnolia_k_) 2022年2月12日
休日の午前中から、思考の訓練みたいなツイートが行き交って、考える良いきっかけになった。
つまり、抽象を持ち込む時に、それが本質なのか、実装上の都合で持ち込まれたものなのかを区別しないといけない
— magnoliak🍧 (@magnolia_k_) 2022年2月12日
「本来のビジネス要求に存在しなかった抽象を示す語彙」がまさにユビキタス言語の候補になるものだと思いますし、設計の醍醐味でもあると思うんですよね
— やきにく (@a_suenami) 2022年2月12日
色の専門家の色の語彙の基本レベルと、普通の人間の基本レベルの語彙は大きく異なる。
— 増田 亨. (@masuda220) 2022年2月12日
基本レベルは多くの場合に費用対効果の高い表現として使うことば。これが専門家と一般人では異なる。
必要に応じて基本レベルをグルーピングした上位レベルや細分化した下位レベルの語彙を使う。専門家の基本
レベルは、一般人にとっては細分化レベルかもしれない。
— 増田 亨. (@masuda220) 2022年2月12日
もしかしたら、一般人の色の細分化レベルは、専門家からみれば、上位レベルのできそこないみたいな語彙なのかもしれない。
要求をそのままコードで表現し、下手に抽象化などせず、その範囲で対応できない要求が発生した場合には「仕様変更だ」「要検定義の漏れだ」と言うほうが楽だと思うし、たとえばクライアントワーク等であれば処世術としてある一定の合理性はあると思うけど、それが楽しいのかって話はある
— やきにく (@a_suenami) 2022年2月12日
要求に存在しない抽象を定義して、さらにそれをコードとして表現しようとするのはすごく勇気がいる。ともすればYAGNI原則に反するし、チームの他のエンジニアから要求に対して複雑すぎると言われることだってある。設計者である自分にだけ見えてるナニカがあると信じられないと低きに流れてしまう。 https://t.co/5CGl5VYLeF
— やきにく (@a_suenami) 2022年2月12日
で、結局このツイートに行き着く訳。
システムの要件定義をするまで、ビジネス構造や業務フロー、判断基準がどこにも可視化されていなかった、なんて話はよく有りますよね
— magnoliak🍧 (@magnolia_k_) February 12, 2022
システム化をする前に、そもそも定義がされていない
定義がされていないから、本質の価値に届いていない、みたいな https://t.co/9YvWsQOcFI
「分かっているつもり」のことに対して、きちんと分析することで「分かっているが分かっている」「分かっていると思っていたことが分かっていなかった」「そもそも隠れていた」みたいな本質の構造が炙り出されていき、結果的に「新しいシステム化は単なる既存の業務構造の写像ではない」ということが起きると思っていて、逆にいえば、それが起きないのであればたくさんお金を使って分析したりせずに、ノーコードソリューションや、業務パッケージを使ってダイレクトにやりたいことを実現していく方が時間的なメリットが得られて良いと思う。
問題は「その業務はどこにもない唯一固有の問題を解決しようとしている」のに、本質の構造を分解しないまま、既存の業務構造をなぞったり、まだやってもいないことを「決めつけ」てしまうことではないでしょうか。
そもそも問題もわかっていないのに、正解に一発で近づく訳もなく。