ならば

　「この会社ではなんにもできない。」
　ある同僚の営業が発した言葉である。彼曰く、自分たちが売上をなんとか上げる為に、いろいろ新しい取組をしているのに、会社は機材も買ってくれないし、経費も出してくれないと言う事らしい。

　正直思い上がりだと思う。目新しいことに飛びついたり、いろいろ思いつくのは誰だってできるからだ。
　例えば面白い商品があっても、資金・人員・取引条件・損益分岐点の分析などを一通り固めて、初めて企画だからだ。
　特に、うちの会社は零細貧乏企業であるから、投資できないボーダーは低い所にあるし、だからこそ費用対効果や元を取る目途なしには投資できない。

　だが、腹立たしいのは、「自分は前向きに努力をしているのに認めて貰えない」と言いながら、自分の立場も給与も守りつつ、リスクは会社が負えばいいと言う思想そのものだ。
　当然、会社の損害を社員にかぶせるのは違法だし、そんな会社は組織の意味はないと思うが、かといって逆が許される物ではない。
　そもそも、リスクを払う経営者を説得できていないどころか、その行為すら行われていないのだ。正直失笑すらできないレベルの話だ。
　にもかかわらず、現場では「やる」という結論ありきで、それに賛成か反対かで敵味方の線引きすらしているらしい。

　やりたいことを全部やれる、あるいは必要だから、便利だからとなんでも買う。それをしたいのであれば自分が金を用意して、自分がリスクを取るしかない。つまり独立するしかない。

　だが、社長ひとりに頭を下げられないような人が、銀行や取引先などいくつもの相手に頭を下げられる訳はない。


　とかく、零細であると中核あるいはベテランになると、「自分が会社を動かしてやっているんだ」とうぬぼれてしまうが、「社会的・経済的にリスクを取っていない」立場であるのなら、最低でもその一点においては、好むと好まざると荷関わらず、会社に対して、自分が無責任な存在であることは忘れてはならない。
　良くも悪くも雇われている身分なのだ。逆にどれだけ気に入らない経営者であっても、その一点においては敬うべきでああるのだ。

　結論として、無責任な存在である一介の雇われ社員が、会社の資金というリソースを積極的な主体(消極的には存在するだけで使っているわけだ)として要求しようと思えば、リスクを取っている人間を、ルールに従って「説得」し、「納得」させる以外に手段がないということである。


　ふぅ、めっちゃ雪が降ってるけど、仕事するかな。

欠陥はソフトか人か

　道路施設基本データの話。

■発端
　現在公開されている作成ツール(中部地整仕様)で橋梁の「点検補修歴」を作成すると、

　"路線","現旧区分Ｃ","整理番号１","整理番号２","整理番号３","補助番号","橋梁コード","径間番号","径間分割番号","補修年月日","部材区分Ｃ","部材番号","補修補強内容Ｃ"

　ってな感じでデータが出力される。(SYOGENの方)
　ところが、支援サイトで公開されている工事完成平面図等作成要領やチェックシステムの設計仕様は、「路線」「現旧区分C」「橋梁コード」は定義されていないわけです。

　従来のシステムでは、仕様の通り、こう出ます。

　"整理番号１","整理番号２","整理番号３","補助番号","径間番号","径間分割番号","補修年月日","部材区分Ｃ","部材番号","補修補強内容Ｃ"


■問題
　問題はチェックシステムが2.2から2.3に上がった際に、仕様書を無視して、前者に併せていることです。
　仕様書を無視するとか考えられない。

■更なる問題
　ヘルプデスクに質問をぶつけたところ、「各地整に従え、でもチェックは最新版な」とあさっての返答。


　バグッてんのか、頭?


+++++++++++++++++++++++++
2010-10-06

追記:バグッてたのはソフトでした。

ヘルプデスクとのやりとり数度。
10/6付けでチェックシステムの修正版、2.3.1がリリースされました。
思った以上に迅速な改訂。
開発担当様、ご苦労様でした。

CS-GV

　ある人からCS-GVのエラー相談を受ける。

　内容的には、道路施設基本データのフォルダ(SYOGENとかD010とかDRAW)について、XMLに記載のないフォルダがあるという事だった。当然、電子納品チェックシステムも道路完成図等チェックシステムも通っているデータ。

　工事完成図書の電子納品要領にはOTHRSはORGxxxレベルまでの管理で、それ以下は管理対象外と遠い昔から書いてある。
　目の前で見た分けではないが、おそらく欠陥仕様と思われる。

　そもそも、チェックシステムの要求仕様を出していない国交省(まあ、データの定義・要領はあるからSEの欠陥だが)もろくでもないが、勝手に解釈して作られた、いちメーカーの製品が、さも水戸黄門の葵の御紋のごとく扱われていることに非常に危機感を覚える。ルール外の修正を強いられる土木業者に対して、契約上の立場を利用して修正作業を強要するわけだからだ。
　契約上、電子納品要領に従う必要はあるが、それ以上、あるいは正式な手続きを経て除外になっている項目の修正の作業は不当だと言わざるを得ない。寧ろ、要領の内容さえ知らないのだろう、役人は。


　だとすれば、今回初めて受け取った分けではないのだろうが、今までの業者の成果品はどうしたのだろう。そもそも電子納品に基本データを組み込んで無いのだろうか?だとすれば仕様上おかしい。
　それとも、XMLに情報を書くことでエラーを回避したのだろうか?　まあ、DTDごと書き換えないといけないのだから、そんな苦労というか、メモ帳作業をわざわざするとは思えない。逆にエラーが出る。
　まったく理解ができない。


　人間、身の丈に合わない道具は使わない方がいいと改めて思う。
　道具は所詮道具。結果には扱う人間の人間性が反映するだけだ。道具を使うことが目的と化している本末転倒ぶりを見るに付け、滑稽を通り越して哀れですらある。笑止千万、片腹痛い。

大雪っすな

必死こいてやった雪かきをあざ笑うがごとく、再び吹雪。
25cm上乗せらしい。

今年は島根東部〜鳥取中部は当たり年らしい。
写真は再び降り始めた最寄りの交差点。

電子納品要領の平成22年09月改訂に見る国土交通省の本気

　国土交通省の本気・・・・・・・・・・・・探しても見つかりませんでした。


　出ましたね、改訂。

　私は昔から、書類毎に位置づけを明確にすべきだと言っていた口なんですが、やっと重み付けされました。
　最悪の方向で。

　私的には、データとして再利用する(オリジナルである必要)と記録としての書類(手段は何でもいいので電子化)と管理の必要のないもの(紙)をベースに運用を見直して、電子に移行して紙をなくす方向を期待していたわけです。
　ところが、今回の要領は完成図・台帳・地質調査はいるけど、あとはどうでもいいという結論。

　いままで、はしゃいで何でもかんでも業者に無理言って電子データにした上に、どこの馬の骨とも知れない「契約にないチェックシステムによるエラーチェックおよび修正の強要」を行なっていた発注者が、「よくよく考えたら、図面と台帳と地質調査以外は意味なかった」あるいは、「貰っても管理できません。そこまで考えてませんでした」と言い出したに等しいと評価しています。

　ついでにいえば、発注者に内容が普及されていないことでしょうし、しつこいほど「変わることへの抵抗」をする現場の担当の一存で「要領は要らないっていっているけど、今まで通り紙しかない書類をスキャナで電子化して、入れてよ」と言い出すことが容易に想像できるので、現場の混乱は必至です。
　そもそも、当初図ひとつ電子納品の原則によれない発注者がルールが改定されたからと言って守るとは思えません。

　あげくは意味も分からずやっているCS-GV係が成果品に難癖をつけて来るのでしょう。



　無論、書類を全面的に省くわけではないのは要領にも書いてはあるのですが、「情報共有システムを使っている場合(最初から電子の場合)」と条件が付いているのがミソです。
　10年近くたっても、紙にはんこ押して電子決済の導入すら行なわれず、会計検査対策の遡り修正がまかり通っている状況からして、良くて紙と電子の二度手間、悪くて紙だけという書類の状況から、ASPに移行するとは思えません。
　特に、私のお膝元中国地方は、情報共有システム自体がJACICの要件全てを満たすこともできない、数年来ほったらかしの三流システムの上に、殆ど意味ないという状態。

　事実上の書類電子化不要枠へ突入&電子納品屋(コピー屋系統)終了のお知らせみたいなものです。

　マクロでEXCELの資料作りを効率化すると怒られるという伝説でおなじみの、お役人さまには電子化のような効率化は無理だったって事でしょうか?まあ、最初の要領からしてこりゃ駄目だって内容ですけど。
　コンソーシアムには役人と学者と理屈屋しかいないのでしょう。
　はっきり言って、コンピュータの専門(学者では無くエンジニア)が主導していない時点で目に見えてましたが。


　いずれにしても、言えることは一つ。
　
減る分の電子納品の稼ぎ、どうしよう!!

XPは生きながらえるようです

ネタ元[EngadgetJapan-Windows XPはビジネス用PCでシェア74%、2020年までダウングレード可能に]

あまりにも売れた事が仇となってしまったようです。
私も過去に写真管理ソフトの大規模リプレースをしたことがありますが、ユーザが増えすぎてしまうと、新しいものへの移行が困難になってしまうのです。

とりあえず7のサポート中はOEM提供されるみたいなので、サポートがXP止まりの某ソフトを使用する人には朗報と言えそうです。

ツケは払われる、好むと好まないとに関わらず・・・

【大混乱前兆】「来訪するほとんどが中国籍」　お金ください！　「子ども手当て」に連日殺到！！
<http://5959goc.iza.ne.jp/blog/entry/1524624/>


ほれ見たことか、財政破綻。
どうせ、煽りは公共事業へくるんでしょう。
「まずやってみよう」とか「スピードが大事」とかは考えた後にいう言葉。考え無しに言った結果がこれ。

今年の流行語は「政権崩壊」であることを切に願う。まちがっても、「日本崩壊」で無いことを祈りたい。

仕事の質

デスマーチ中にうかんだこと、箇条書き。


・最高の仕事にはなかなかたどり着けないが、最低な仕事はそこら中にころがっている。

・信用とは、積み上げるものでしかなく、無条件に与えられはしない。

・画竜点睛を欠けば全ては無意味である。

・覚悟とこだわりこそが仕事の質を高め、効率は仕事の質を落とす。

・言葉ではなく、形こそが評価につながる。

・わかり合えない人間との議論ほど人生の無駄はない。

・ネガティブシンキングこそがポジティブシンキングをも越えることはよくある。

・辛さが言葉にできるていどなら、辛くない。忙しいと言っていられるうちはまだ余裕だ。

・失って始めて分かる大切さはあるが、どれだけ足っても悔やむことのない無用さははるかに多い。

・嘘つきであること適当であること、真摯であること、潔いこと。その人の仕事が雄弁に語る。

・良い仕事からは多くを学ぶことができ、悪い仕事からは更に多くを学ぶことができる。ただし、良い仕事をする人から学ぶことはあるが、悪い仕事をする人から学べるものはほとんどない。絶望、失望、憤怒、憐憫くらいのものだ。

・睡眠時間を削るより、不毛な会話を削る方がはるかに仕事がはかどる。

・挑戦>>>>>>越えられない壁>>>妥協

・道具に金をかけている人間の仕事は、そうではない人間の仕事に勝る。

・どんな名言も活躍も、日頃の行いには決して勝てない。

・閃きは天才の仕事、思いつきは愚者の仕事。天才は閃きを閃きとは思わないが、愚者は思いつきを画期的な閃きと誤認する。

・拒絶や否定も仕事である。前面肯定はゆるやかなる破滅への誘い。

・展望のないもの程展望を語りたがる。

・蒙昧な者は理想に至る道を模索し道を誤るが、賢人は現実の積み重ねでしか理想に達し得ないことを理解している。

・自分に酔った人間の言葉は、ウォッカより後を引く悪酔いの効果がある。

・〆切を守らない人間ほど、他人の〆切にはうるさい。

・他人の信頼を裏切り続けることほど容易なことはそうそうない。

・猫の手も借りたい時に猫の手を借りようとすると、そんなときに限って猫がいない。

・疫病神は実在する。そして貧乏神は常駐する。

・良い物は相応に高い。安物はどこまでいっても安物。ただし、不相応な価格の粗悪品は掃いて捨てるほどあるから、良い物を見つけるのは大変。

・調子のいい奴は周りの好調な人間の調子を悪くさせる。不調な人間には絶望的なダメージを与える。

・絶望は人の形をしている。希望は決して見えない。

・有能であれば喧伝しない。大げさなビラは在庫処分セールでしかない。

・

データの独立性について

　例えば、発注者がこんな事を言っているのを聞いたことは無いだろうか?
　・XMLは見難いから、うちは日本語フォルダとファイル名でいく。
　・順番がとびとびで、ファイルを開きにくい。
　・○○な風にみれないといけないから、そんな風につくってくれ。


　ありそうな話ですね。実際あるわけですが。
　これらについては不勉強としか言いようがない愚かな話です。加えて、要領やQ&Aに記載がある内容を理解していないとしたら、愚の骨頂。

　これらの部分への本質的なアプローチがそもそも違います。
　そもそも論で言えば、電子納品とは「データを定型化し、納品する」ことに本質があり、末端の担当者風情がデータのあり方を解釈するものではありません。もちろん、それは明確には書いてありませんが、管理ファイルにXMLを採用していること、要領等を土木技術者や役人の目ではなく、「情報処理技術」の観点から眺めることで必然として分かることです。
　XMLベースの管理からして、何らかのWEB系テクノロジが介在する「データベース」の存在が見え隠れし、データベースを用いる以上、データは一定の形式から逸脱してはいけないのである。当然「協議」箇所として定義されている部分はあるが、これは「コンピュータ(DB)には関係ない・人間しかこだわらない(目視レベルがもとめられる)」あるいは「本質的にどうでもいい」部分に限られている。

　脱線したが、データベースと切っても切り離せないものとして「正規化」がある。正規化とはデータの重複部分を整理し、「複数のレコードに同じパターンを使わない」ようにしていくこと等が該当する。これをしなければ、「重複データが容量を占める」「ある部分を直すと同じ修正を何個もしないといけない」「最悪ちぐはぐ不整合が起きる」などに見舞われることとなる。
　通常データベースでは、「データの持ち方」と「データの入力方法・見方・出力形態」は切り離されているものである。
　つまり、規定のデータ形式である電子成果品が見難いとすれば「ビューアがゴミ」か「見ている奴の見方が悪い」のいずれかでしか有り得ない。ツリー状に表示したり、日付順やタイトル順にソートしたり、指示・協議等を見かけ上フォルダ分けして表示したりといった、「データを人間の為に再配置する」仕事は、見せることが仕事のソフトの役目であり、データの作り方をどうこうすべきではないのである。

---

　正直わかりにくいので、別の例を挙げると「年賀状ソフト」がある。
　データは住所の定型データを保存している、あるいはCSVをイメージした方がいいだろうか。電子納品と同じように、「人間に見やすい」データでは無い。が、コンピュータにはこちらの方が都合が良い。
　そして、このデータさえきちんとしていれば、年賀状やら封筒やら、全くデザインが異なるものに配置し直してくれる。
　また、住所録編集の際には、カード型(台帳型)表示とリスト(一覧)表示を切り替え、好きなインターフェイスで編集もできる。これらは、データとヒューマンインターフェイス(以降はI/F)が独立しているが故に成立しているのである。

　電子納品については、「作る」ことばかりが取り上げられ、データの構造化や「見る」と言ったことがおざなりになっている。問題の本質を間違えてはいけない。

---

　さらに・・・
　データの正規化が足りない問題も散見される。
　容量的な意味から言えば、「打合せ簿」の鑑など最たるものだろう。中国地整の書式だとExcelで30KB弱だったと認識しているが、この殆どは「A4の形に引かれた書式」のデータ容量である。内容が違っても、この部分は「必ず存在する」データなのだ。打合せ簿の数だけ。
　つまり「人間が見る為のムダ」である。この部分もデータの独立性を損なう部分であり、WEBで言えばスタイルシートとかテンプレートで実装されているように、「同型式の書類データが一意に参照する」形で外部にレイアウト情報を持っていれば、ファイル一つ一つに同じ内容を埋める必要はない。
　このブログだって、テンプレートを換えるだけで、見せ方も変えられる。そんな風になっていけば、よりムダも無くなる。最悪、データを人間向けに並べる機能はビューアが持っていれば、CDに入っている必要すらない。

---

　また、問題はXMLの定義にもある。
　打合せ簿の日付なんかも、鑑のデータ内とXMLに両方存在する。不整合が起こりかねない。ただし、「日付で検索」は行ないうる操作なので、理想的にはXMLと鑑データの連動が望ましいかもしれない。

　酷いのはCADである。
　まず一つは重複の問題。打合せ簿の日付と同様に、図枠(SXFVer3であれば表題の属性)とかぶる管理項目があり、かつ、やろうと思えば違う内容も入力できる。

　二つ目は管理項目の問題。「縮尺」は要らなく無いか?どうしても要るというなら仕方ないが、「1/100の図面が欲しいな」って検索する姿は全く思い浮かばない。図面リストを出力とかは考えなくもないが、その為だけにわざわざ入力するのは人生の無駄。

　そして、三つ目はファイル名。XMLとも表題ともかぶり、命名が悪すぎて生データの並びもわるい。以下つっこみを。
　・「ライフサイクル」:レイヤみたいに部分的に変更されるならともかく、現行ルールでは「工事なら発注図も変更図も完成図もＣ」だし、設計なら「Ｄ」。別に図面一枚一枚に付ける必要あるの?むしろINDEXにSDCMを一文字打っておけば十分。
　・「整理番号」：前一文字と後ろ六文字がかぶったときとか、契約図と参考図を区別とか、変更回数とかはっきり言ってろくに考えてない事がこの一桁に集約されている。契約図と参考図とか、変更回数とかXML側にフラグなり入力欄を設けるべきだ。抽出できないじゃん。
　・「図面種類」：これもXMLに持たせれば十分。
　・「図面番号」：XMLにあるし、ファイル名で表現する必要なし。
　・「改訂履歴」：削除図面も欠番にしなかったり、完成図は常にZで意味ない。そもそも書き換えた図面かどうかっていう観点が「納品後」に必要かどうか甚だ疑問。


　で、結論。ＣＡＤのファイル名って連番でいいじゃん。打つの面倒なんだよ、相当に。その割りに意味ないしってこと。

---

　で、最終結論。
　・発注者はＩＴとか勉強しなさい。むしろ自分らの出している要領くらい理解しろ。
　・電子納品業の人は「CALS」の専門家(??)である前に、「土木・建築」の専門家でもあればベター。さらに「情報処理」の専門家で合ってすら欲しい。
　・請負業者の人は、こんなロクでもない話に巻き込まれてご愁傷様です。

　と言うことで、長文失礼。

関係ねえ

「ネットやIT技術に弱いブロガー」を１秒で見分ける方法!?

　要約すると、ネットは英語圏のもので、英語は頭下げせずに書くから、ネットに通じている奴は頭を下げないという内容。
　私も英語書くときはそうするけど、日本語は日本語の文法作法で書くだろう普通。

　なんか、「パンツは腰ではくのが格好良いから、あらゆるものを腰はき」みたいなもんか、あるいは外国語でいえば格好良いみたいなもんだ。「君にHEY YOU、LOVE　愛してる」ってなもんだ。


　そもそも、そういう書き方の奴って、携帯でＩＴデビュー的な臭いがする。ディスプレイ狭いの?って感じだ。私も、情報処理技術者試験も通ってるし、プログラムのコードも書けば、ダンプリストとにらめっことかもするし、エキスパートでは内にしても疎いつもりもないですが、これは理解できない。字下げとかは文章力と常識の問題であって、ＩＴ関係ないよ。むしろ、英語と日本語を区別できないことの何が格好良いのか、日本が心配になってくる。