アカウント名:
パスワード:
＞文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ...
この件がどうかは知りませんが、自治体の案件では人名とか地名を扱うことが多いので、 JISの第２水準までに含まれないような文字が使用できるように求められることがよくあります。 今は Unicode系を使えばなんとかなるのですが、
包摂して実用上問題ないものでも、 利用部門が (場合によっては門外漢のお偉いさんが)「これと同じ形で見えなきゃダメだ」の一点張りだったりします。
Unicode以前は各ベンダーから独自に自治体対応に拡張したコード系が提供されていたので、そんなのを使用して実装していたようです。
というか、業務を知りもしないで「Unicode にすれば大丈夫です！」みたいな嘘八百の提案書を役所の上の人に見せるのはやめてくれ > 某外資系コンサル # ほかにも XML とか SOAP とかオープンシステムとかオープンソースとかクライアント・サーバとかシンクライアントとか、 彼らがどこかで聞いてきただけの単語を並べるだけの提案が色々……
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:1, 興味深い)
＞文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ...
って…、まっとうなソフト会社じゃなくて素人さんに発注してしまったんじゃないのん？Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:4, 興味深い)
1. 仕様書の間違い発見
2. ソフトアカデミー: 文字コードの仕様変更
3. オーイーシー: 仕様変更分の開発費を要求
4. ソフトアカデミー: 支払い拒否
5. オーイーシー: 撤退
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:0)
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:4, 参考になる)
発注元（＝青森市）が要件を出せないでいる状況でかなり奮闘した上で発注元が大幅な仕様変更を提示した訳ですから、
追加工数に関する費用をベンダに出す（＝追加工数分を発注元に請求して然るべき費用をベンダに支払う）義務が中請け（＝ソフトアカデミーあおもり）には発生する訳で。
そこでベンダと中請けの間で紛争が起きて決裂した訳ですから、ベンダが撤退するのはしょうがないでしょう。
この案件、結局青森市（の一部上級官僚）が今まで丸投げしていたF社を切って金をケチりたかった上に、
天下り団体からのキックバックまで欲しがっていたから無茶苦茶になったと言う構図から来た破綻して当然の案件に見えるのですが。
発注元の気まぐれに振り回された上に開発費用が大赤字になるのだからベンダが撤退するのは当り前ではないかと思いますが？
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:2, 参考になる)
開発時に、実際の運用データを貰えない事が多いので、ゼロから開発となると、
まともなテストケースを作れなかった事は予想がつきます。
オープン系だと、技術的に回避が容易では無い場合もありますが、
お役所受注な仕事だと指定された環境と予算と納期の中でしか、
回避策が出せないので、開発部隊には手が打てなかったり、
手遅れになったところで問題が発覚したりという事になるのは、
まっとうなソフト会社でも避けられなかった気がします。
ただ、そういう問題を考慮しても、あまりに出来が悪かったんだなと思う。
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:0)
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:2, 興味深い)
今は Unicode系を使えばなんとかなるのですが、Unicode以前は各ベンダーから独自に自治体対応に拡張したコード系が提供されていたので、そんなのを使用して実装していたようです。
で、そうゆう事情を知らずにシステムを内部を 普通にただのEUC(シフトJISでも)に依存した方式で実装してしまうと、JIS外の文字が化けるという不具合になります。
あ、ひょっとして、Windowsに変えるってのは、Unicodeの使用が関係するのかな？
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:2, すばらしい洞察)
包摂して実用上問題ないものでも、 利用部門が (場合によっては門外漢のお偉いさんが)「これと同じ形で見えなきゃダメだ」の一点張りだったりします。
オープンシステムに移行しても、 他のレガシーな業務システムとの連携の都合で JEF コード等をベースにすることはあります。外字に独自にコードを割り当て (自治体や業務によって包摂基準が変わるので共通化すらできません)、 フォントを作成し、 情報交換用の変換テーブルを作成するのです。
というか、業務を知りもしないで「Unicode にすれば大丈夫です！」みたいな嘘八百の提案書を役所の上の人に見せるのはやめてくれ > 某外資系コンサル
# ほかにも XML とか SOAP とかオープンシステムとかオープンソースとかクライアント・サーバとかシンクライアントとか、 彼らがどこかで聞いてきただけの単語を並べるだけの提案が色々……
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:1)
法律で、公務所等で行う電子化する事務ではJIS(日本工業規格)の情報交換用*文字符号に含まれる文字だけの使用に強制にすべき時期と思います。必要ならば第5? 水準とかも制定する前提で。いい加減ローカルなJISで標準的な文字表現を可能にしないと、特殊仕様のコストやらがかさんでIT化に因る種々のご利益を国民が享受できなくなります。
# でなきゃ、JISの存在価値無し。
## 可能性0に近いでせうが将来Unicodeに入れる(てもらう)為にも、ローカル規格の使用実績が不可欠でせう。
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:1)
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:1, 参考になる)
実装する言語も１種類だとかなら楽勝案件にしか見えませんが、
公共系の帳票印刷というのは、DB格納も画面表示も極めて特殊です。
インターネットでは半角カナは推奨されていないから、入力を許さないとか、
このコード体系にはこの文字が無いとか、技術的正論は通用しない上に、
それをオープン系で行うとなると更にアプリ間の連携でつまづいてしまう、
受注した側は例えばMySQLの開発をするつもりは無かったわけだから、
当初の契約金額と見合わない作業が発生してしまうので予算追加を依頼する。
そのような想定外のトラブルを当然のように見込んでいて、解決するほうが特例的でしょう。
たとえばMSのように人的リソースが潤沢で、公共系の受注実績を維持したい所なら
サクッと対処してくれるけど（但しMS製品の置き換えプレッシャー込みで）。
なんで出来ないのか、と簡単に思うほうが素人さんです。
発注側の市には、当然そうした知識が無いからアカデミーあおもりが中間に入ったんでしょうが。
データ移行部分は、タタというインドの会社に依頼したとか上のほうのソースにあったけど、
タタは契約期間が来たからって事で離脱しちゃったみたいね。
タタに振った仕事が単純で、それを完璧にこなしていたから許可したのだろうか。
個人的には、韓国企業やインド企業に日本語のデータを扱わせるのは、
かならず後で問題が発生する経験ばかりなんだけど、どうだったのだろうか。
OECの見通し・予備調査・技術力が甘かったというのも確かだけど、
技術的対策のための追加予算が出なかったり、パートナー企業が途中離脱したり、
プロジェクトとして空中分解しないほうがおかしい要因に満ち溢れていた。
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:0)
公共の仕事に手を出す以上、「想定外のトラブル」ではなく想定してない方がアホです。
特例でもなんでもない。
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:1)
Windows環境でしか自宅サーバーを立てたことがない人は気にもしないかもしれませんが。
＃という自分は、もともとWinで立ててたWEBサーバをLinuxに移行させたときにShift_JISとEUC-JPが混在してしまって、jcodeとか駆使してごまかしてますがｗ
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:0)
# いやぁ、前の会社の社長（技術者）といっしょですな。
# 最後は口八丁で妥協させるか、それでもダメなら逃げるんですよ（笑）
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:0)
元、同じ会社の方ですか？
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:0)
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:0)
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:1)
Re:文字化けや情報が正しく呼び出されないなどの不具合が相次ぎ (スコア:0)
OOoな人はわかってるようです。
但し、その方面で(もちろん英語で)論議するためには、最低限ハリセン本を理解しとかないとダメだとか。