ほら、よくあるじゃないですか。
こんな感じで作ってるんですっていったら、このやりかたじゃ規模が大きくなったときに対応できないよとか。
でもそのやり方じゃ、規模が小さいときに対応できませんから。
ソフトウェアの方法論って、規模が大きかったり信頼性が必要だったりものを対象にしてるものばっかりで、規模がちいさくて信頼性もそこまで必要ないものを対象にしたものってないですよね。
で、なんか暗黙の了解として、規模が大きいものに対応できれば規模が小さいものにも対応できるとか、信頼性が必要なものに対応できれば信頼性が低いものにも対応できるとか、そういう考え方がある気がします。
スペースシャトルのソフトウェアを作るときの考え方だから、どんなソフトウェアにも使えますよ、みたいな。
でも、規模がちいさいところで適当に使うソフトって、あんまり信頼性を求めても窮屈なだけで、邪魔になることもあったりします。
「こんな感じで入力してください」「それはちょっとめんどくさすぎですね」
「でもこれだと処理できないデータが・・・」「いや、そのときは手で修正しますから」
みたいなね。
日々の作業を面倒にして不正処理を減らすより、楽々作業で、たまにある不正処理は手作業で対応したほうがよかったりするんですね。
モデリングにしても、モデルとして良いモデルを作ろうとしてて、現実の開発作業の流れからは外れたモデルになってたりします。このくらいの規模なら、ワークフローさえ決まれば最初から画面を作れるというようなときでも、なんかいろいろ迂回して設計しないといけなかったり。
だから、設計書はコードのあとで書かれたり、書いてあってもだれも見てなかったりするんですよね。見るより聞くほうが早いっていうか見てもわからん、と。
もっと、こう、作ろうと思ったことを思いついた順にぼんやり書けて徐々に具体化していけるような、自然なモデリング記法やら方法論が欲しいものです。
また、こういう話すると、「このときはどうするんだ」というツッコミ入るんですけど、それは「信頼性が必要なとき」で、今は信頼性が必要ないときの話をしてるわけで。
ともかく、大人の服の一部分を取り出したり切り詰めたりしても、子供服にはなりません、と。
