今業務システムって何で開発してんの？

うちには東レの漢プリと呼ばれてるプリンターがあるんだけど、こいつはフィード
幅を紙テープで決定し、フォントはテープから読み込むという時代錯誤なやつ。
聞くところによると、現在の役職者が入社した時には既に稼動してたというから
10年どころの話じゃない。
そして、こいつは今でも稼動してる。何の処理をしてるのかは知らないけど、と
にかくこいつにはまだ仕事があるらしい。

ハードウェアの保守契約って最長何年なんだろう？
もう見るからに機械式って雰囲気を帯びてて、メンテなしでは直ぐに潰れそう。
きっと誰かがメンテしてるはずなんだが・・・・・・

つまりCSは５年でリプレイスが前提で開発してると。OSや開発環境は５年後にまた考える。
無駄に開発費払う、いいお客掴んでるなあ。

逆に資産償却がメインフレーム感覚かつ、メインフレームからのリプレイスの客の案件は取れないね。

メインフレームも償却のタイミングでハードを上げる。
中身はそのままのことが多いのでハードのころがしと呼ばれる。
逆に、そのタイミングを見計らってリプレース商談を他社がふっかけてくることも多い。

昔と違って、今はシステムの陳腐化が激しい。そのきっかけはC/Sによるダウンサイジングの流行だけどな

古い機械って今から見ると作りが異様に頑丈でなかなか壊れなかったりするよ。

>>955
そうだね。
俺はオープン系の何でも屋なんだけど、打ち合わせの時に
「なんだかんだ言ってもホストの安定性にはかないませんけど」という
枕詞を使うことで、年寄り連中から非常に可愛がられているｗ

いや、実際ホストの頑丈さをしったらオープン系で「大丈夫です」なんて
言葉は口が裂けても言えないけどね。

まあ汎用機を知らない人に言っても、んなわけねーよって
バカにされるだけだけどな。

>>955
価格も異様に高いんだがな。w

>>956
汎用機はハード・ソフトとも全部自分のとこで
作ってるから，いざというときのサポートがいいよね。
OSのバグとかもすぐ直してもらえるし。

>>956
PCでも9801とかはかなり丈夫だぞ。ウチの会社の工場じゃまだまだ現役。w

昔の機械は部品点数、稼動部品数、精密さで有利だろ。
同じ土俵で比べるのが間違い。
壊れにくさは単純さに比例するだろ。

それは鉄筋無しのマンションでもそうなのか？

ヨドバシカメラやDELLなら高性能のＰＣがもっと安いよ？
ボッタクリじゃないの？
なんて内心思われてるんだろうな…とつくづく思う

>>960
PC-9801のキーボードでは今となっては高級種のメカニカルスイッチだしね

>>963 お客様は「アーキテクチャが違う」と言ったら大体納得する。

鯖に関しては、かなり裁量を任される。ラックに入れるし、クラスタ化必須だったりするし。
なぜそれが必要かはハードウェア構成仕様としてまとめなきゃいかんが。
けどクライアントというか、エンドユーザが使うPCは「好きにさせろ」が多いな。

ま、だからってWebじゃなきゃいけないなんてことはない。ユーザが広域に分散してるが、
セキュリティ上の理由から、あえてC/Sにしたり、スタンドアロンで動作して、データだけ
加工・編集が終わってから転送、もしくはいまだにフロッピーで提出だったりする。
ちなみに、官公庁のシステムです。

>>966
官公庁だったらエンドユーザが使うPCも自分とこの売ればいいのに。

>>967
うちはSI業者でハードは売ってないんですよ。選定はしても、購入・リースはあくまでもユーザです。
システム導入を決めて運用する部署と、使う部署が対等なので、普段使うものを勝手に決めると
反発されるってのも理由です。お役所にありがちな縄張り争いになってしまう。
一社で独占すると癒着と判断される可能性もあって、納税者に怒られるし。

C/SとWEBアプリの境界は、ビジネスロジックをサーバサイドに持つか
クライアントサイドに持つかの違いで、専用クライアント( = 広義のブラ
ウザ。要するに、何かをブラウズする為のアプリケーション)の要不要
とは何の関係もない。

そこが腑に落ちてないから、WEBサービス＋スタンドアロン型リッチク
ライアントへの移行が始まってるって事にすら気付けない。

>>968
了解。
うちはシステム入れるときはサーバからクライアントまで
全部自社製品で揃えてるから官公庁って大概そうなんだと思ってた。

>>969
誰に何を言いたいのか、さっぱりわからん。
何かのコピペか？

WEBアプリでJAVAスクリプトてんこ盛りだともはやTHINクライアントと言えないのでは？
素直にFATクライアントにした方がメンテ楽だとおも。

>>972
Thinってのは別にソースの量の多寡を言ってるわけじゃないだろうが。

RISCとCISCの境界が曖昧になったようにFatとThinの境界も曖昧になると。

漏れの周りでは、WEBサービス＋スタンドアロン型リッチクライアントへの移行なんて始まってないから問題ない。
管理コスト削減には、ウェブアプリケーション＋ウェブブラウザクライアントが最強。

ちゅうか、JavaScriptてんこ盛りでThinクライアントと呼ばれるほど
貧相なUIしか作れないプログラマなんて死んだほうがいい。

>>975
君のまわりで始まってないだけ。
子ぼらー、VBクラサバと同じように時代に残るだけだよ。

FatかThinかの境界は、内部ロジックをクライアント側で持つか否かだと思ってたんだが。
UIとか別の問題じゃね? 確かにThinクライアントだと環境の制限でヘボい場合もあるけどさ。

Webサービスはトランザクション関連の規約作りが統一出来ずに分裂してしまい、今は膠着状態
外部システムとの連携に使う程度で、システム全体の基幹になることは当分無い
Webサービス＋リッチクライアントという構想自体が既に頓挫しつつある。
それに、分散環境を無理矢理システムの中枢とする愚かさは、EJB2の失敗で明らかだしな
結局、サーバサイドは今まで通りで、Javaや.netに依存した形でトランザクション管理等を行い
クライアントはAjaxで強化したWebブラウザで行う方向に進むのではないだろうか

>>979
WEBサービス = 分散環境といういきなり大ジャンプで考えるから膠着する。
そもそも、何もかも１からドーン！と全部纏めて置き換えるなんて事は、どだい無理
なんだよ。誰に売るの？お客さん居ないでしょ？

先ずは小さな不満から解決していく。使い勝手が悪い、寧ろ不便になった。
これはWEBアプリに対して一番多く聞かれる不満。
それじゃあ、クライアントサイドに専用のクライアントアプリを配置するのはどうか？
何か問題ある？あるとして、それは現在の技術で解決困難？

WEBサービスのプロトコルが決まってない？だったら当面WEBアプリ＋αでもいい
じゃない？
配布コスト？JWSだってあるしClickOnceだってあるじゃない？WEBアプリ＋αなら
WEBブラウザでだってアクセスできる。何も失わない。
HTMLはデータ交換に不向き？CSS＋XHTMLならデザインを分離できるし、解析も
XMLを扱うのと手数は変わらないじゃない？

小さな不満は解消される、そんな大したコストは掛からない、大掛かりなリプレース
が必要なわけでもない。そして、次の展開が見えてるだけに此方にとっても好都合。

WEBでC/Sやって何が悪い！、Javaで構築されたサーバサイドにC#.NETで書かれ
たクライアントアプリを配備する。こういう発想もWEBサービスへの布石。
統一規格とか、それによって齎される分散環境なんていう大風呂敷は、その後から
ついてくればいい。路面がスリッピーな時はすり足で半歩ずつ進むの、これ常識。

ところで次スレ行くのか？

>>980
ですね、１行目が全てだと思う。
Webサービス言っても、今までのサーバーサイドプロセスの考えそのままだからね。
分散システムみたいな大規模もあれば、１台でDBまで全てやるようなものもあり。

それに、>>979の後半なんて自分で前半に言ってる事を否定してるんだが。
彼にとってWebサービスって特別すぎに考えてるのではないか？

ウェブサービスってSOAPとかでしょ。
ブラウザでは使えないじゃん。

CS廚の勉強不足じゃね？

悪いことは言わないから、
Webは検索参照・結果DLのみ位で提案しとけ。
そっち方面だけなら間違いなく楽できるしコスト押さえられるしみんなハッピーだよ。


エントリー系は案件毎に条件が違うからガンガレ。

>>982
＞分散システムみたいな大規模もあれば、１台でDBまで全てやるようなものもあり。
「分散」を勘違いしてないか？
C/Sは典型的な分散環境。規模とは関係無い
ちなみに、EJB2はWebアプリケーションだと捉えられがちだが、あれもRMI over IIOPを使ったC/S型システム
クライアントがサーブレットコンテナであることが多いから誤解されがちだけど、仕組み的にはWebサービスとよく似てる

>>983
だから段階的な移行について話してるんだが？

WEBサービスの終点はCORBAやDCOMの延長線上にある。
ぶっちゃけ統一によるベンダーフリーの実現て辺りがミソなんだが、もう一つ、エンド
ユーザーも同じ規格で繋いでしまおうとしてるあたりがCORBAやDCOMとの差異。
#俺個人の印象だけど、DCOMはエンドユーザーも思惑の内に含んでた様に思う。
#だから、現在模索されてるWEBサービスの姿は、DCOMの方により近いと感じる。
#一番の違いはWindowsで閉じてないという辺りか？
ただ、その道程が長いのか短いのかが不明瞭。MSの予定も遅れがちと停滞気味。

だから、WEBアプリ→WEBアプリ(CSS＋XHTML)＋スタンドアロン型リッチクライア
ント(この時点ではサーバサイドは単なるWEBアプリだから、当然WEBブラウザでも
アクセス可能)→WEBサービス＋スタンドアロン型リッチクライアントという流れを考
える。
MS WCF、Firefox XUL、Eclipse RCP、クライアントサイドの候補は既にゾロゾロ出
てきて準備を始めてる。
どう変わるかは分からなくても、どこが変わるかは予見できる。
変化に対応する為の実装技術は今や常識、今ある問題に対処しながら、同時に近
い将来起こるであろう変化に対応する準備も始める。今がそういう時期だって話。

そろそろ埋めよっか

このスレの結論：世の中にはC/S厨もWEB厨もいて、業務システムの実装はそいつらが左右してる

>>985
C/Sは分散システムじゃないわな。
あんたこそ、単に処理を分散していることと、システムを分散して相互作用させることを混同してる。
単に分散って言葉だけ切り出して屁理屈かいてるだけ。

「PHSだってコードレスホンの子機だって携帯できるから携帯電話だ！」
と言っているようなものだね。

WILLCOMを馬鹿にするなよ。

俺も>>984とほぼ同じ考え
ちなみにエントリー系の要件混じってる時は上手い事言って外注か別チームの奴引っ張ってきて俺は全体のアーキテクトと照会系とか印刷関係だけやるようにしてる
メンドクセえエントリー系とは他の奴がヒイコラ良いながらやってるがまあ対外上手く言ってるｗ

1000に近づくにつれて白熱してきたな

CSのほうが鯖落ちると基幹業務全停止のイメージが有るな。東証ダウン状態。
ウェブなら他の鯖には無関係で使える。業者使い分けててよかったと感じる瞬間。

だからな。
Webで出来ないような入力を要求してくる場合は、その妥当性を量れ。
その顧客要求が本当に妥当なものかどうか量れ。
その上で飲ませて、納得が得られれば、客もこっちもハッピーになれるから。

たとえばEnterでフォーカス移動とかくらいは入れてやれ。
コスト的にも問題ないし、顧客の使い勝手を慮っても、
当然それがあるのとないのでは効率が段違いだろ。

でもはしょるべきところははしょれ。もしくはWebで実現できる代替案を提示しろ。
それが通らなかったら、しぶしぶC/S、これ。

通ればラッキー、みんな幸せ。
通らなければ、客は自己満足、でも開発不幸せ。残念。

そゆこと。

>>994
はあ？サーバダウンに関するリスクはクラサバでもWebサーバでも同じだよ。
クラスタ化してあればドッチでも対応可能だし、してなければサーバダウン＝サービス停止。

>>995
客にその理屈を君が通せればね。
開発ツールや動作環境の都合なんぞ客のしったこっちゃないし。

>>996
いや、でも、売り上げ上げるってことの入り口は、つまるところ、
それを通せるか通せないかにかかってると思うのよ。かなりの比重で。

等価なものだったら、より楽に、同じ効果を得られるものを提示して、
その上で納得を得る。なんでも言われたとおりにつくるんじゃなくてさ。
いや、下請けで設計やってないとかならしょうがないけど。
（決して下流工程をなめてるわけでなくて真面目に）

これをやるかやらないかって、WebもC/Sも関係なく重要だと思うんだが。

Webの方がより安くできる場合だけな。

999

1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。