＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
パッケージ製品の面白さはなに
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-05-10 09:16
パッケージ製品の面白さはなにというスレを立てました。
自分はとある企業に常駐してパッケージ製品のカスタマイズ、移植、機能追加などを やっています。 個人的にはパッケージ関係は あんまり想像力とか独創性とかが入り込む余地が少ない ためいい加減やめたいなぁと思っています。 そこでですが、パッケージ製品にかかわっている人はどんな気持ちで開発しているのか教えてください。 | ||||||||
|
投稿日時: 2004-05-10 12:53
私はＥＲＰパッケージの仕事が多いですが、経験上、ＥＲＰを製造／管理している企業と 自分が所属している企業の役割で結構、異なります。 手順通りで設計担当企業の言う通りの開発現場は、一定スキルを持つＰＧには、つまらないです。 逆に設計も任され、インタフェース仕様（画面の動き）さえ合わせれば良いよ、と言う現場は 結構、自由度があり、雑多な仕様決定は「ＥＲＰ基準に合わせる」で済ませれるので楽です。 
大雑把に別ければ、既存プログラムの変更はつまらん。アドオンは面白い。 と言うのが個人的な考えです。
初心者ＰＧの時は、サンプルプログラムが沢山あるという気持ちでコピペをしまくり ＥＲＰの大体のソースが頭に入るとコピぺの動作自体が面倒臭くなり、 「良く使うソース」のランチャーを作成して楽していました。 お蔭様で言語コマンドが憶えれない（読むのは出来る）ので、マニュアルは手放せません。 
ＰＧとして技術が上がると、取決めの多さ、改善案の通り難さから、嫌気が差してきます。 私は、嫌気が指したと同時に設計の仕事をする様になったので、それほどＥＲＰを 懸念しなくて済みました。
ＳＥになってからは、ＥＲＰは参考書扱いです。ただ、ＥＲＰ自体の設計書が 外に出無い（製造元にはあるよね．．．）ので、 「ソースやＤＢの解析」「実操作」「操作マニュアル」で残体像を 把握するしか無いのが辛いです。． 
ＥＲＰでも、他社のＥＲＰパッケージをすれば新鮮に感じると思います。 １企業に所属している人は難しいですが．．． | ||||||||
|
投稿日時: 2004-05-10 15:44
そうですよね 個人的にはＤＢ設計したいと思っているのですが、ＴＢＬを作るような仕事 がないのがつらいかな
一応設計の仕事もやってますが、まったくの新規というのはほとんどない。なんらかの言語で作成したものを解析して設計書を書き上げるというのが多いです。 リバースエンジニアリング ばかりやっているような気がする。とほほ | ||||||||
|
投稿日時: 2004-05-10 18:25
こんにちは〜。
私も某パッケージの機能追加（主に通信制御）の仕事をしていたことがあります。 そのときはペーペーでしたし（って今もそうですが、更にということで・汗）、そのパッケージ（の中身）がとてもすばらしいモノだったので、長期間携われたこともあり、徐々に hack する楽しみを得ることができました。
（公開されている情報は少なかったですね〜ソースから洗っていました） 逆に 「なんじゃこりゃー！  」 なパッケージ（の中身）だと、かなりツライと思われます…。
通常業務の中でやりたいことをするのは、難しい場合も多いですよね。 私は 「何がしたい？」 を探している途中だったりしますが、「つまらない」 に ”ちょっとの余裕” がプラスされるのであれば、色々なものに手を出してみるのもよい案だと思います。 （そうやって、通常業務とは全く関係のない Linux を勉強しています。おもしろいですよ〜☆） 人間、何かしらの ”楽しみ” がないと、続けていくのは大変です（苦笑）。 初心に帰って 「よかった探し」 をしてみるのもステキかもしれませんね。 
| ||||||||
|
投稿日時: 2004-05-10 20:00
入社したての頃、消防署で他システムと連携し、地図を表示するというパッケージの、顧客向け特殊機能部の開発をしていました。
それで思うのは、使う人が変われば要望違う、ということでしょうか。その「違う要望」が面白かったです。 ・山林地図と市街地図との連携 縮尺と「北」が違う地図を、途中でジャンプさせてつなげる。 ・個別表示 NTTのデータと連係し、通報してきた「家」を特定する。 当時、ナンバーディスプレイはなかった。（消防署だけ、番号が通知されていた） ・地図転送 司令室で表示した地図を、車庫の入り口にあるＷＳに転送し、印刷する。 救急隊員が出動間際に地図を持って行く為、スピードが命。 ・緊急配備 これは県警用。逃走車のスピードと、時間を入力し、検問を設置する場所の 候補を表示する。 ・パトカー表示 県警用。当時のシステムでは実現不可能だった。パトカーから上がってくる GPSデータより、住宅地図上にパトカーの現在位置を表示する。表示位置は 誤差を含むので、移動方向などにより「走っていると思われる道路」を ブリンク表示させる。 | ||||||||
|
投稿日時: 2004-05-11 09:35
楽しそうな感じが伝わってきますね。初心に帰って 「よかった探し」 をしてみたいと思いますが、ちがうことをやりたいなぁ今の所では？いくらスキルつんでも収入は据置きだし（笑） 最近思うことは 要件定義とかの仕事をしたいということかな エンドユーザーと話しをつめる とかやってみたいと思う | ||||||||
|
投稿日時: 2004-05-11 09:43
技術的なレベルは想像もつきませんが、こういった要件ならおもしろそうですね。 ところで パッケージ開発をやっていて 次のレベルを目指すとしたら何ですか？ | ||||||||
|
投稿日時: 2004-05-11 10:46
パッケージソフトに関してはいろいろやりました。大きく分けると、
１．パッケージそのものの開発 ２．パッケージのアドオンの開発 ３．パッケージのカスタマイズ／業務への適用 となるのですが、純粋に技術者としてのおもしろみは１．のところが一番でしたね。 でもまぁ、よくあることですが１．の部分には不特定の顧客・ユーザーという漠然 とした対象なので、業務という部分は比較的薄くなり、対顧客折衝なんてのはあん まり無いわけで、そういうところに興味がある人には面白く無いかもしれません。 逆に３．の部分では通常のオーダーメイド業務アプリを作るのと同じように顧客 とのかかわりが出ます。ですが、パッケージ標準機能が顧客の要求とマッチして いる場合には良いのですが、無理な要求があったりするともう．．． 融通が効かないパッケージの場合には、ストレス溜まりまくりで、トリッキーな 手法で実現はしても後味悪いです。 何故かこれ良くあるんですよねぇ．．．パッケージの導入が先で開発業務は後から なんてことが。（顧客のスタンスの問題か、パッケージの売り方の問題かわかり ませんが）でも、業務系の知識を吸収という意味では３．もすごくおもしろいと 思いますね。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.