具体的な機能

ユースケースで分析すると具体的な機能が設計されがち

柔軟性に欠ける

例えば、既存の現場のフローに合わせたステータス設計とか、検索項目の設置とか

これは修正のコストも上がる

現場の業務フローが変わるたびにシステムを修正しないといけない

逆に言えば、システム改修コストがかかるから、(微妙と感じつつも)業務フローを変えない、という選択をしてしまう

システムの存在がボトルネックとなり、現場の改善ができないということになる

親切さで言えば具体的な方が、次に何をすれば明確になるので良いのだが、

validationとかをゴリゴリにしてしまうと、規定された操作以外ができなくなってしまう

これもユースケースで、具体的に、設計しているのに近い

「間違っていてもとりあえず遂行できる」ことが必要なこともあったりする

どのレベルの抽象度・汎用度にするのかのバランス感覚が大事になる

極論言えば、プログラミング言語ぐらいまで抽象度を上げれば、大抵の問題は解決できる

しかし、そのために、ユーザにプログラミングの能力を強いることになる

ある程度、帰納的な作業が必要になる

具体的な機能を考えるのは容易であるので、そちらに流されてしまう

この問題を直撃で解決する機能を発案したり、どこかから持ってくればよいだけなので。

「文字が小さくて読みづらい」という要望があったときに、

「文字をデカくする機能」を提案している感じ