日経コンピュータの記事に興味深いエントリーが。
やっぱり出てきましたね、「自動生成」。
楽して自分の望むものができれば言うことないのですが、
ソースコードやテーブル定義の自動生成ができたとして、
そのツールの出来が良くても「その振る舞いが正しいか」の確認はしなければなりません。
ユースケースレベルの確認であれば、システムテストでよいかもしれませんが
本当にそれまで試験しなくて良いのでしょうか？
システム開発に占める時間は、コーディングやテスト(単体、結合)のようにデベロッパー作業が大半を占めると
言われている所もあります。確かに時間を食う箇所であることは否定しませんが、その理由としては
- 決まらない仕様
- あいまいな仕様
- 頻発する仕様変更
- 矛盾する仕様
- 実装を意識することなく基本設計終了
が殆どではないでしょうか？
仕様が無ければ実装はできません。
仕様が変われば実装も変わります。
手戻りが頻発すればそりゃ時間もかかるでしょう。
デグレも頻発してテストが終わらないでしょう。
いくら自動的にソースコードが生成できたとしても
ふわふわした要件から揺れ動く仕様をきちんと定義できるのでしょうか？
また、ツールを使う上では、そのツールの得意とする型にはめなければなりません。
それから逸脱すると非常に手間と時間がかかってしまいます。
一時は逸脱した方法で成功しても、そのツールがバージョンUPした時でも
問題なく動作できると保証できるのでしょうか？
ちょこっとした修正でもツールを使用しなければならないとしたら
システムとツールは切り離すことができません。
それだったら自分でソースコードが追えた方が気が楽ではないでしょうか？
結局そのツールを使いこなすまでに時間がかかるでしょうから、
得意な言語で作った方が早い気がします。
- ツールができることから逸脱せず作られたシステムをユーザーが受け入れられるかどうか*1
- もやもやしている要件を仕様として定義することができるか
がツールを使ったシステムで成功するかの鍵じゃないかな、と。
で、システム開発での成功の鍵を握るのは
- 要件を仕様として定義できるか
であって、スクラッチでやろうが、ツールを使ってやろうが
肝になるのは間違いない。
「仕様を決めてくれればその通りに実装できるのに」と言うのはただの使いっ走り。
プロジェクトの進め方として、
仕様を決めにいくのか、決まるまで待つのかも、成功の鍵を握ることになるでしょう。
さらに開発者として、自分で作ったソースコードは、テストしてテストの結果も残す
当たり前のことを当たり前にやれば言いと思うんだけど。
単体テストレベルでも、ポイントおさえてきちんとやれば
デグレった時も検知してくれるし。
システム開発に銀の弾丸なんてないって。
個人ができることを当たり前にやるしか方法が無いんだって。
テクニカル(テスト)、プロマネ、チームビィルディングとかバランスよく興味を持つ人が増えれば
変なシステムはそうそうできないと思うんだけどなー。
*1:業務をシステム側に合わせる事ができるかどうか
