こういうのはアンチパターンとは呼ばない、、と思う
ITエンジニアの「やってはいけない」
こういう粒度バラバラの「べからず」集では、状況の変化に対応できないし、適用できる範囲も狭くて、パターンとしての普遍性を持ってないと思う。
なんか困難な状況が現れている場合は、それをもたらすような圧力(技術的なもの、政治的なもの)があるわけで、その圧力を明らかにして、治療を行うような記述にしないとダメだと思う。*1
例えばリンク先にある「ユースケースを詳細に書きすぎちゃって大変」という症状があるときに、「ユースケースを詳細に書きすぎないようにしましょう」では解になってないと思う。その後の工程に不安があって詳細に書き過ぎすぎちゃうとか、適切な他のドキュメント(画面仕様書とか)を検討できず詰め込みになってたり、クソみたいなテンプレートを押し付けられて変更する権限がないとか、メンバの配分がおかしいとか、何らかの圧力があるはず。その圧力を解消するような治療法を提供してこそアンチパターンじゃないかな。
リンク先みたいな対症療法っぽい思考法をする人が多くて、そういう人に限ってアンチパターンなんて読んだことも無いわけで、話の基盤を合わせるのが難しくて凹むことが多い。
あんまり抽象的に考えすぎて、アーキテクチャ宇宙飛行士になってしまうのも良くないけど。
