読者です 読者をやめる 読者になる 読者になる

若干愚痴モード

仕事
バカ専用フレームワーク -
http://www3.vis.ne.jp/~asaki/p_diary/diary.cgi?Date=20061225

どこの会社でも「バカ専用フレームワーク」と呼ばれる社内ツールは作られ&使われているようです。「このシートの項目に値を入力して、このボタンをポチッと押せば、ほれWebアプリケーションの出来上がり・・」という社内ツールですね。「バカ専用フレームワーク」というネーミングがまた・・(^^;)
で、まー私も会社でそんなようなツールを作る仕事をしてたりするんですが・・。使う側からすれば楽しくともなんともないツールなんだろなと、容易に想像できるわけです。楽しかろうが何であろうが、生産性が高ければ良いっ、という話なんですが(本当にいいのか!?)結局生産性なんてものは計測不能、God only knows。一応、行数数えて「100行中80行自動生成できたから20行書けば完成!80行分、生産性があがった!ワーイ」・・とは簡単に言えるはずもなく。そもそも、値を入力してボタンをポチッ、で生成されるアプリなんて物凄い単純なものに限られるわけで、結局つじつま合わせのカスタムコードを書く羽目になると。そうなってくると、ほんとに生産性が向上しているのかどうかも怪しくなってきて・・。で、プロジェクトごとに当然、機能要件が違うからツールを各プロジェクト向けにカスタムし始める。で、カスタムされたものがプロジェクトチームに展開されるんですが、開発メンバーは当然ツールの詳細なんて知らないから、あれやこれやとイロイロ弄繰り回した挙句、想定もしなかったようなとんでもないツールの使われ方をし(たとえばツール実行中にツールの内部ファイルを書き換えちゃったり、ツールを構成するファイルをむちゃくちゃにされたり・・)、そんな感じで社内の不特定多数の社員と、その5倍くらいの人数の協力会社員の方々にツールが使われ始め・・・・と言うことになってくると、当然ツールのサポート体制なりが問われてくるわけですが、コストセンタであるウチのような部署にはほとんど人がおらず、ひとりでツールの問いあわせ対応から、エンハンス、マニュアル書き、んで社内教育・・・とやることになってしまい、あぁ、ツールのあの部分のエラー処理をもっときちんとしておきたいな・・デバッグログも拡充しなきゃ・・と思っても、お上にとっては「それってツール自体の生産性にどれくらい貢献するの?」ということで機能拡張が優先され、、、テストコードも書けず、ううう。
ということで、この手のフレームワークって本当はどのくらい効果があるのか、わからなくなってきた。たしかにシンプルな構成のものを作るんだったら、このフレームワークを使ったほうが断然効率が良いけど(足場はほぼ自動生成)、一歩、道から逸れはじめると、いよいよ怪しくなってくる。大規模prjに適用しようとなると、ツールの提供側もそれなりのリソースが必要になってくるんだが、そのリソースを直接prjにぶち込めば、それで済む話なんじゃないかなとも思ったり。共通基盤チーム、見たいな感じで。さぁ、いよいよ何が言いたいのかわからなくなってきましたが、とりあえず久しぶりにブログ書いたら疲れた。俺は普段はあまり他人に愚痴を言ったり、悪態をついたりはしないんだが、今日はちょっと愚痴っぽくしてみました。結局俺は何が言いたかったのか。