« January 2017 | Main

March 12, 2017

デヂエのExcel化

數年にわたって會社の案件管理にデヂエを使用していたが、この年度末をもってその運用を停止することになった。理由はいろいろある。もともとはデヂエ好きのお偉い方の「これで部門閒の情報共有の圓滑化をせよ!」との號令で始まったものだ。そんな偉い方の指示ならば、その構築やメンテナンスをみんなが協力して行なうべきと思うが、デヂエの機能だけでは實現できないことまでやろうとしたため、ふと氣付くと自分1人で面倒をみるハメになっていた。そこで「このままでは私が居なくなったら面倒をみる人が居なくなってしまうから、誰か私と同じように面倒を見れる人を立ち上げていく必要があるのではないか?」と問題提起した。それが周圍には「もう疲れたからやめたい」と聞こえたらしく、一氣に運用停止に向かって話が進んでしまったのだ。

私個人は今のロケーションに居るうちは本來業務と竝行で面倒をみても構わないと思っていたので、この決定にはちょっと驚いた。ただ一般的に、誰か特定の人にしか出來ないものを組織として運用するのはリスキーであると考えるのが普通だ。私の蟲の居所が惡ければ、要望がかなえられなかったり、リジェクトされたりする。しかも、本來業務が忙しいなど出來ない理由はいくらでも言える。こんな狀態を見かねての決定なのかもしれない。しかし、そうは言いつつ出てくる要望にはほとんど對應してきたし、「え?誰かそんなこと言いました?」と聞き返されることまでやったつもりだ。そのため、デヂエ本來のセールスポイントである「プログラミング無しで構築できるWEBデータベース」が霞んでしまい、誰にでも容易にメンテナンス出來るシロモノではなくなってしまっていた。

これはシステム構築をする上での敎訓にすべきであるが、分かっていてもなかなか實踐できていない。組織がシステムを導入する場合、箱モノのソフトを買ってきて、あれこれ試しながらどうやって現在の業務に馴染ませていくかを考え、タイミングを見計らってパチッと切り替える、というのが一番安上がりなのは理屈上誰でもわかっている。しかし、90年代から始まった基幹業務のシステム化は、今に至ってもなおペーパーレス化の域を出ていないというのが現實だ。したがって、システムを導入する企業が最初に氣にするのは業務フローの效率化ではなく、システムが表示する畫面や帳票を使用中の紙の傳票や帳票にどこまで合わせられるか、ということになる。つまり傳票や帳票は會社や組織によって千差萬別であり、最初から箱モノのソフトで對應するなんてことは眼中にないのだ。そして、高額な構築費と關係者の多大な時閒と勞力を費やして完成したシステムはたった5年で更改を餘儀なくされる。5年も經てば、少なくともハードウェアやOSがサポート切れになる。さらにタイミングによってはカスタマイズのベースとなった業務パッケージソフトの壽命が終わっている場合もある。それにより、更改にもかかわらずイニシャルに近いコストがかかってしまうことが少なくない。

簡單に言えば、システムに對する投資は初期構築の1囘だけではないということだ。運用が始まれば保守費などのランニングコストがかかり、法改正に影響を受けるのであればその都度費用が必要になる。しかも、パッケージをカスタマイズしてしまうと、法改正對應のパッチを適用できなくなり、カスタマイズに近い費用が必要になってしまう。問題なのは、初期構築時にそういう說明を十分にしないまま、客に言われるがままにカスタマイズしてしまうことだ。まるでアリ地獄に引きずり込むかのように。

以上のようなことを考慮して、デヂエのようなWEBデータベースを有效活用するのは非常に賢明なことであると思う。そして、その賢明なデヂエにもいずれ終わりは來るのだ。終わる時にすべきはデヂエの中に蓄積した情報のエクスポートである。デヂエのデータベースをCSV形式やXML形式で出力するのは簡單だ。問題なのはデータベースの中にファイルを添付している場合である。普通にCSV形式で出力すると添付ファイルの項目はファイル名になる。これでは出力したCSVをExcelで開いても、その添付ファイルへのリンクにはならない。前置きがかなり長くなったが、その添付ファイルをリンクにするための方法を紹介するのがこの記事の主旨である。

デヂエのデータベースの項目はフィールドIDで定義されている。そのIDはXMLファイルを見ると分かるようになっている。しかし、添付ファイルの本體はライブラリID、フィールドIDの階層で切られたフォルダの中にレコードIDをファイル名にして格納されている。これはファイル名の衝突を避けるための方法のひとつなのだろう。これを分かり易くするためにライブラリID、レコードID、フィールドIDという階層にフォルダを切って、實際のファイル名で格納するようにしてみたのが以下のプログラムである。


Ws000135

最初の2つの變數はトップディレクトリを定義する。top-dirはデヂエのデータフォルダで、この配下にライブラリID每のフォルダがある。save-dirは添付ファイルを格納するフォルダのトップで、この配下にライブラリID/レコードID/フィールドID/添付ファイルが作られる。

Ws000136

csv-picker2はデヂエのCSVを讀み込む。各フィールドがダブルクォートで圍まれ、フィールドの中の改行にも對應している。ただし、デヂエのデータ特有の條件(最初のフィールドがレコード番號)を使用しているので他のCSVに流用することは出來ない。一般化するのであれば、ダブルクォートの内か外かを認識するロジックが必要だろう。

Ws000141

get-filesはライブラリID、レコードID、フィールドID、元のフルパスファイル名、格納先フルパスファイル名をリスト化する。

Ws000142

make-files-dirはget-filesで作成したリストを元に格納先フォルダを作成する。

Ws000143

record-file-copyはget-filesで作成したリストを元に添付ファイルを格納先フォルダにコピーする。

Ws000144

get-file-fieldは添付ファイルの各項目のフィールドIDと項目名をリスト化する。

Ws000145

make-excelはメイン處理で、添付ファイルの各項目を格納先のフルパスファイル名に置換して、CSVファイルに出力する。

*scratch*に適當に書いていたものをまとめただけなので、あまり效率的でないと思われるが見直す氣はない。一應ソースはgithubにdedie2excel.elというファイル名であげておいたので、もしも使いたいと思った人はそちらをアクセスしてください。


| | Comments (0) | TrackBack (0)

March 06, 2017

メモ:イジメ

あるテレビ番組を見て、久しぶりに「イジメ」について少し眞面目に考えてみた。が、それをどうしたら解決できるか分かったわけではない。というより、そんなことを考えても無駄だという氣がしてきた。

何の意圖もなく不意に發した自身の言葉が、相手を地獄の底に叩き込むことがある。かと思えば、渾身の嫌味を込めて放った罵詈雜言でも、相手は微動だにしないこともある。

とくに意地惡をしているつもりはないのに、意地惡されている、イジメられていると感じる人が居る。つまり、時と場合と兩者の關係性によって、イジメになったりならなかったりする。それを一體どうしろというのだろうか。

そもそも、ある人閒關係がイジメに見えるのは、それを正面から受け止め、抵抗することをやめてしまっている場合である。ほとんどの場合は、それを不當と思えば言い返すか抵抗くらいはするだろう。そして、その場は何事もなく終わってしまう。

人閒以外の動物の世界では、弱い者は潰される。場合によっては殺される。それによって强い者が殘り、命が受け繼がれていく。より强い者が子孫を殘すから、その種は繼續出來る。そういう世界から見れば、弱きを助け、强きを挫くなどというのは戲言でしかない。弱い者ばかりになれば、その種は滅びる。すべての地球上の生物はその原理原則に從って存在している。

人閒も例外ではない。誰かに怒鳴られただけでシュンとなり、飯も喉を通らなくなるような弱者ばかりになれば、たとえ食物連鎖の頂點に居るとされる人閒であっても、早晚他の種または他の生物に殺され、滅ぼされていくだろう。それを救濟してくれるものなどありはしない。

たぶんつづく。

| | Comments (0) | TrackBack (0)

« January 2017 | Main