uhyorinの日記: これもオフショア開発になるのだろうか? 2
日記 by
uhyorin
帳票系プログラムをたくさん作ることになった。
普段の作り方なら「あれとこれとそのテーブルをクエリで拾って、レポート内で集計かけながら表示させてね」と無茶?な要求定義がまかり通っていたような気がする。
仕様書なんてまともにもらったこともないし、書いたこともなかったし…どっちかというと要求定義書みたいな簡易仕様書でプログラムを作ってた。
が、今回は社内で初めて中国の某会社に仕様書を投げて製造させることになった。
世間一般的にはオフショア開発とか呼ばれてるけど、本当にコストダウンに繋がるのだろうか?
集計が終わったあとの中間テーブルからレポート出力させる処理のみ行わせるだけだから、やろうと思えばそんなに工数はかからないはず…そもそも外注にする必要もないと思うのだが。(-_-;
SEに転向してからの悩みといえば、「この人に製造を任せれば大丈夫」と思えるようなプログラマさんがまだ周りにいないというか、確立してないってところかなぁ。
# 実際の集計処理はストアドですよ。
# 誰がスプリクトを書くのかと言えばもちろん…。
微妙なところです (スコア:1)
正直、オフショア開発は微妙だと思います。ブリッジ SE を経由すること特有の問題もありますし、物理的に離れているのでレスポンスが悪かったりとか。
私が数年前にヘルプとして入った某プロジェクトでは、とあるフレームワークを使い、仕様は日本で書いて、プログラム製造は中国、というありがちなものでした。そのプロジェクトは、某社の基幹システム群再構築に関わるもので、仕様は凄まじく膨大です。
で、中国からあがってきたコードをちらっと見たことがあるのですが「こりゃ駄目だわ」と思いました。とある Java の WEB アプリのコードなのですが、1 クラス数千~数万行あったりしました。動くことは動いたようですが...メンテナンスにコストがかかることになるのが目に見えてました。
低コスト、高コストには、やはりそれなりの理由があります。自分の経験から言えば、別に中国 SE の技量そのものが低いというわけではないので、仕様を出す日本側の問題もあるでしょう。上述した私の経験では、個人的には使用した Java のフレームワークが原因だと思っています (私もちょっと触ったことがありますが、制限が多くて凄く使いづらいんです)。
結果、やはり技量や納期に信頼の置ける人を、少数精鋭で (←意外と重要)、なるべく席を物理的に近く配置してプロジェクトを進行させるのが一番な気がしています。
何にしろ、そのプロジェクトが、uhyorin さんの良い経験になるといいですね。
Re:微妙なところです (スコア:1)
雑多な作業に振り回されて、仕様書作成がおぼつかない状態に陥っているとどうしても「コピーロボットがっ!」と思ってしまいたくなるのですが。←話が変わってないか?
かつて、東京でVBプログラマをしていたときは上記スタイルでした。
毎日が速攻作成即納品という日々でしたけど、プログラミングのスキルアップと業務知識の習得という面では今でも大いに役立っていますので。
SQL Serverの環境構築手順も付けたし、VB+ActiveReport1.5(という帳票出力OCX)のサンプルソース付きなので、ここまでやって要求水準のものが上がってこなかったら「オフショア反対じゃ!」と説得する立場に周りますのでその点も大丈夫…と思いたい。(^-^;
# たまにはケツイがやりたいです。
# 撤去からどれくらいたったかなぁ…(T-T