January 05, 2019

システム開発の現状

一般的に、普段我々がシステム開発と呼んでいるのは、実際にはアプリケーション開発であり、しかもそのほとんどはWindows上で動くアプリケーションの開発である。ただ、1個のアプリケーションで全ての要件を満たそうとすることは非常に稀であり、普通はいくつかのアプリケーションが連携して動作し、エンドユーザに利便性や効率性を提供する。しかし、システムって何ですか?と聞かれて、それはWindowsアプリケーションであると答える気は毛頭ない。たしかに、システム開発とはアプリケーション開発であると言ったばかりだが、それは定義ではなく、現在の状況に過ぎない。

本来のシステム開発であれば、システムに求められる要件定義のあとで、ハードウェア、ソフトウェア(OS機能も含む)それぞれの方式検討、仕様規定、設計、製造、テストが並行で行われ、次に開発されたハードウェア上で、開発されたソフトウェアを動作させ、正常性、安定性を確認する。こういったシステム開発は、Windowsアプリケーション開発に比べて、開発期間が長く、工程が進んでいくにつれて作業がどんどん過酷なものになっていく傾向がある。過去の開発では、進捗キープや納期厳守のために徹夜のテストやバグ改修になることが常であり、そのために1つの開発が終わると、関係者は身も心も弛緩し、次の開発に着手してもなかなか本来の調子が戻らず、気が付くとまた徹夜続きの毎日に戻っているという不健全なスパイラルに陥りやすい。つまり、常にコンスタントに作業することがむずかしい仕事であるということだ。今風の言い方をすれば、ブラック認定間違い無しの業態である。

では、上記のような本来のシステム開発とアプリケーション開発との間にはどんな違いがあるのか?

おそらく、どんなシステムにも性能要件がある。何らかの操作をしたあとで、その結果がいつまで経っても表示されないことを許容してくれるエンドユーザは皆無と言って良いが、ではシステムがどの程度の性能を発揮すれば良いかを規定するのは意外にむずかしい。大した技術的裏付けがなくても普通に時間がかかりそうだと分かることを瞬時に実行するにはそれ相応の費用がかかるので、エンドユーザもヘタなことは言えなくなる。また、同期的に処理するか、非同期的に処理をして完了したら通知するか、などの考え方もある。が、いずれにしても性能はケースごとに数値で定義しないと確認できないのは確かだ。アプリケーション開発でどんな厳しい性能を要求された場合でも、それを実現することが可能なのかと言うとそれは非常に困難である。

性能要件を満たすための方法とは、システムの動作シーケンスを計測可能な箇所で区切って、その区切り毎に想定秒数を決め、シーケンス全体の秒数を合計した時間が妥当かどうかを検討し、その通りの時間で動くハードウェアとソフトウェアを作り上げることである。性能の作り込みというのはそういう地道な作業の積み重ねであり、性能要件を満たすのに必ずしも優秀なSEやプログラマが必要というわけではない。そして、アプリケーション開発でそれをやろうとした場合、開発するアプリケーションの中は同様の方法で性能を作り込むことがある程度可能かもしれないが、アプリケーションがOSの機能を要求した場合に、そのレスポンスタイムを制御することは出来ないという問題がある。もしも、厳しい性能を要求された機能を実行している最中に、マシンがWindows Updateの確認をし始めたら、通常では余裕で性能要件を満たしていたとしても期待する動きにはならないだろう。

Windowsパソコンを使っていれば誰でも経験すると思うが、アプリケーションをどんどん起動していくと、搭載メモリを使い切るちょっと手前あたりでピタッと動きが遅くなる。これは、起動されたアプリケーションを動かすために、実メモリからディスクに退避可能な領域を探し出して掃き出す処理をしながら空きメモリを確保しているからである。仮想記憶によって、実メモリよりもたくさんのメモリが使えると言われてはいるが、それを実用的な性能にするにはそれ相応の性能の(1シークで大量のデータを読み書きできる、大型コンピュータで使うような)ディスク装置が必要になる。これらのことを考えても、アプリケーション開発において性能を要求されても、それを阻害する要因をアプリケーションから制御可能な方法で排除できる仕組みがなければ、ほとんど実現不可能と考えて良いだろう。

普通に考えれば、空きメモリが残り1GBしかないのに、2GBバイト使用するアプリケーションを起動しようとしたら、何らかの警告が必要だろうと思われるが、Windowsはそういう動きはしない。ひたすら空きメモリを確保して、そのアプリケーションを起動しようとするだろう。その結果、たとえばパソコンの動きが止まったように見えたとしても、その処理を決してやめようとしない。これは、ネットワーク上の他のコンピュータから機能要求された場合でも、同様の動きをする。つまり、トラヒック制御をする機能がない。さらに、外見上止まってしまったように見えている状態を自ら検出する機能(故障管理)もない。

それはフォルトトレラントと言って、普通のコンピュータやOSには無い高価な機能だとエンドユーザには説明するのかもしれないが、そんな話を聞いても誤魔化されているとしか思えないだろう。要するに、最初からアプリケーション開発で性能要件など満たせるはずがないことを前提に話を進めなければいけないのだ。


さてここまでは、何年もシステム開発をやっていれば誰もが普通に感じる疑問というか、問題というか、インチキなのだが...ここ数年、民需系の案件を大小問わず何件かこなしてきて新たに浮上した大きな問題がある。これについてはツイッターで断片的に何度か書き込んだが、あまり芳しい反応は来ていない。

すでに死語であるかのように誰も口にしなくなった、ダウンサイジングという言葉がまだ生きていた頃、企業が導入するシステムは大型コンピュータからPCサーバへ、ソフトウェアはスクラッチ開発からパッケージ&カスタマイズへ、アプリケーション開発からWEB迅速開発へ、などの流れでどんどん進化、低価格化していった。このようにシステムの構築技術は進歩したが、エンドユーザは依然として置き去りにされたままだった。

エンドユーザはシステム開発の専門家どころか、コンピュータの仕組みもロクに知らないので、システムの中身がどうなっているかなど分かるはずがない。ところが、システム構築を行なう上で必要となる、要求事項の整理、システム仕様の承認、システムの動作確認を正しくタイムリーに出来なければならないことが暗黙のうちに前提となっている。出来上がったシステムがエンドユーザの望みどおりでなかったとしても、開発者は「ちゃんと仕様確認しましたよね?議事録承認もしてもらいましたよね?エビデンスありますよ?」と言って自分たちには何ら責任がないと主張するのが常だが、それでは問題は解決しない。

このような問題が起きる背景は明らかだ。企業がシステムを導入する場合、たいていそれを担当する人が主に開発ベンダと向き合い、その他の人は本業が忙しいので、誰が何処で開発を進めているかも知らないかもしれない。そしてある日突然、システム担当からシステム仕様の照会がまわってくる。次年度導入される予定のシステムの画面、帳票、大雑把な操作手順などが記されたドキュメントを突然見せられて、的確にコメントが出来る人が居るだろうか?

かなり会社に好意的に振る舞う人でさえ、突然見せられたシステム仕様に対して出来るのは、おそらく現在の仕事のやり方に沿っているかどうかのチェックくらいだろう。そして、どこの職場にも居るキーマン的な社員は忙しいので、それを丹念に読み込んで理解しコメントしているヒマなど無い。結果的にシステム仕様の確認は、現在の仕事のやり方に合っているかどうかの確認になる。それ以上のことを社員に期待しても無駄だろう。

しかし、ここで立ち止まってよく考えてみると、そもそもシステムへの投資目的は何なのかという疑問が湧く。会社によっては、今どき何処の会社でもコンピュータを使って仕事をしているのだから、うちの会社もそうしないといけないんじゃないか?と、経営層から社員まで漠然とそう考えているだけかもしれないが、普通の経営者なら、システムへの投資は将来回収してもなお余りある利益となって返ってこなければおかしいと思うだろう。ものすごく単純に考えれば、現在と同じ人員で売上が拡大するか、同じ売上を出すのに今より少ない人員で...のどちらかしかない。そのいずれにしても、今までと同じやり方をしていたのでは到底達成できないと考えるのが普通じゃないだろうか?

その上で、現在巷で行われているシステム開発を振り返ると、誠にお粗末な状況であると言わざるを得ない。企業が導入するシステムは、その会社の業務を効率化し、さらなる利益をもたらすものでなければエンドユーザは満足しない。ところがほとんどの案件では、提案段階で示されるコストパフォーマンスが絵に描いたモチでしかなく、結果的に業務のシステム化というよりは、業務のペーパーレス化+煩雑な操作性を提供するものでしかない。さらにそのような状況においてさえ、5年毎にやってくるシステム更改の度に初期構築並みの費用が必要になるという、最悪の事態がいたるところで散見される。このお寒い状況の中で近い将来、業務のシステム化から、業務のAI化への波が否応なく訪れるが、まだシステム化も満足に出来ていないのに、AIの導入に進んでいけるのだろうか?

もともと日本の企業の形態、および日本人の性質は、業務のシステム化には向いていない。終身雇用の社員が大勢居る中で可能な業務改善は、せいぜい部分最適化であり、業務の抜本見直しが行われることはない。もしも、終身雇用の老若男女がめいめい業務改善案を口にし始めたら、今までは一体何だったのか?ということになる。今までのやり方を是として継続してきた以上、システム化するからといって急にやり方を変えられるわけではない。さらに、売上拡大の見込みもないのに業務を効率化すれば、いずれ何人かは解雇されることになるだろう。

そろそろ中規模企業のシステム導入も、初期構築をほぼ終えて、すでに2~3度のシステム更改をしている会社もある。そうなると、どこの会社でもシステムの更改費、運用費の決裁がどんどん厳しいものになっていくだろう。今までどおりの業務フローをただコンピュータで実施するというだけのシステムに、毎度々々多額の投資をするほど経営者もバカじゃない。納期間際の確信犯的炎上ごっこも、そう何度も通用するわけではない。


では、どうすればよいのか?まずは、これまでシステムに払ってきた投資を社員に向けることだろう。システム化が単なる不便なペーパーレス化に陥っている責任の半分は、エンドユーザサイドにある。業務の効率化や抜本見直しを開発ベンダがしてくれるわけではない。それはその会社の社員がすべきことなのだ。もし社員にそのリテラシーが不足しているのなら、適当な業務パッケージソフトを選んで購入し、そのパッケージに合わせて仕事をしてみることだろう。そうすれば、システムを構築、更改、運用していくより安くて済み、さらに自分たちの業務をどうすれば導入したシステムに合わせられるか考えるようになる。これをやっていくうちに、社員のリテラシーはイヤでも向上せざるを得ないだろう。

社員のリテラシーがある程度向上したら、次に行なうべきことは業務をコンピュータで実施するだけでなく、社員一人一人の行動や意思決定をナレッジ(どういう場面で誰が何をしたか?その行為を誰がどういう理由で承認したか?)として蓄積していくことである。それを数年続ければ、あとはそれをAIが読み込んで有効な支援をしてくれるようになるだろう。


| | Comments (0) | TrackBack (0)

January 02, 2018

年末ブログ:歌音ちゃん

青木歌音ちゃんという、元男の子の女の子(と公言して憚らない)ユーチューバーがいる。最初のうちは、授かった性別を変更することに大きな疑問を感じていたのだが、動画をいろいろと見ているうちに少し考えが変わってきた。だからと言って、自分は性別を変更する気はないのだが...。あんまり書くと誹謗中傷になりかねないので、遠慮がちに書くことにする。

自分の性別は男であり、それについてほとんど違和感はなく、女になったらどうなるか?などと考えたことはあんまり無い。ただ、もし自分が5人兄弟で、上に姉が4人居たら、どうなっていたかは分からない。そういう環境で少年時代を過ごすとき、何でもお姉ちゃんの言うとおり!とか、逆に唯一の男性として男らしくするよう仕向けられるとか?いろんな状況が考えられる。いずれにしても、そういう状態から何の影響も受けないで育つということは考えにくい。

少し話は逸れるが、まだ20歳代のころ仕事で常駐していたビルで、用を足すのに別の階のトイレに入ったら、なぜか男子トイレに女性が入ってきて、男性社員と談笑していた。会話の内容からそこはどうやら化粧品会社だったらしい。なので、男子トイレの洗面に置く化粧品の世話を女性社員がしているのだった。こういうところでは、おそらく男性社員よりも女性社員の方が多いと思われ、普通の会社とはずいぶん雰囲気が違うんだろうなあと思ったものだ。

さて、自分の性別に違和感を感じたときに、心と肉体の性別が異なっているのではないか?というのを、性同一性障害と言うらしい。その呼称はともかく、要は男なら自分はホントは女なんじゃないか?女なら自分はホントは男なんじゃないか?ということだ。普段たまにそういう疑問を感じるだけでなく、そのことで深く苦悩するようになったとき、反対の性別の格好をしたり、果ては性別適合手術を受けることになるらしい。仮にもし、自分はホントは女なんじゃないか?と思い始めたら、それを抑えるのは非常に難しいだろう。何せ客観的な証拠がない。

もし、自分が何の抵抗もなく女子トイレに入っていけるのであれば、あるいは男子トイレに入るのに違和感を感じるのであれば、おそらく心は女なのだろう。そして、自分のホントの性別で生きていきたいと思うかもしれない。ただ、男で肩身の狭い思いをしていて、女になってそれが解消するかどうかは本人次第であり、それ自体は誰も助けてあげられない。

会社でもたまにLGBTに関する人権がらみの周知メールが飛んでいる。自分個人はプライベートでどのような生活をしている人であれ、会社で普通に仕事をこなしている人であれば何も問題ないと思う。むしろ、そういうマトモな人がなぜ性別で悩むんだろうと思うかもしれない。



歌音ちゃんの動画を見て、ニヤニヤしながらそんなことをあれこれ考えた。実はアイメイクしている歌音ちゃんが上の娘にクリソツでびっくりして以来、すごく親近感が湧いてしまったのだ(笑)

| | Comments (0) | TrackBack (0)

年末ブログ:破綻しないシステム設計

「破綻しないシステム設計にして欲しい」と言うのは、「バグのないシステムを作って欲しい」と同じくらい愚かな物言いであり、そんなことを要望する意味はない。誰だって、破綻するシステムを作ろうとしているわけではないし、故意にバクを見逃そうとしているわけでもない。また、設計にしてもテストにしてもコストがかかることであり、いくら望まれても自ずと限界がある。

単純に「破綻しない」と言っても、そのレベルは様々あるだろう。どんな事態に遭遇してもシステムの設定変更で如何ようにも対応可能、というのが最も望ましいとして、そこから一切の変更はシステム全体の作り直しになる、という最悪の実装までの間には無限のオプションがあり得る。そして当然のことながら、そこにパッケージを使用するか、スクラッチで開発するかという悩ましい問題が合わさってくる。

先に結論を言っておけば、破綻しないシステム設計というのはある種のレトリックでしかあり得ない。そもそも、システムが破綻するかどうかの責任が設計にあるわけがない。もしも破綻しないシステム設計を請け負ったのなら、実際にシステムが破綻した場合にその原因は設計にあるということになり、下手をするとバグ対処せよ!ということになりかねない。しかし、エンドユーザは確信犯的かどうかにかかわらず、往々にしてそういう無茶な要求を出してくるものであり、それを受注したいベンダも調子に乗って引き受けてしまうことがあり得る。

具体的に、システムが破綻するかどうかというのは、スケーラビリティの問題である。当初100名が使用するとしてサイジングしたシステムを、事業拡大によって1000名が使用することになり、性能的にもリソース的にも破綻するということが考えられる。その際に、現在のシステムを止めないで運用したまま利用者の増大に対応できるのが一番だが、そんなことが出来るのは最初からシステムをそのように設計し、そのように作り込み、実際にそれが設計したとおりに動作することをテストして初めて実現する。そして、そのような設計をするのであれば、エンドユーザからそのような要件が出ていて、かつ仕様が規定されなければならない。

しかし、エンドユーザは破綻しないシステムを望むわりに、そもそもシステムが破綻しないとはどういうことなのか、そのためにどうなっていなければならないかまでは考えず、ひたすら破綻しないことだけを願ってやまない。そして、出来上がったシステムを検収する際に、そのシステムが実際に破綻しないよう作られていることを検証する方法も知らない。何年か経ってから何か問題が発生した場合に、破綻しないよう作られているはずだよね?と対応を迫ってくるのだろう。

システム利用者の増大による破綻以外に、コード情報の破綻というのもよくあるものだ。身近な例で言えば、マイナンバーは既に運用前から破綻しているという話を聞く。破綻しないコード設計というのも、わりとありがちなレトリックである。たとえば、コードにおいては通常何種類の状態を表したいかによって、それが100通りなら単純に3桁必要ということになる。しかし、状態は100通りでも1桁目は0、1、2のいずれかにしたいなどのユーザ要件が発生すると、3桁では収まらなくなる可能性が出てくる。そしてこういう要件は、画面や帳票などの設計がある程度固まって社内照会した後に出て来るものだ。ここでユーザ要件と設計をごっちゃにすると、問題が一気にややこしくなる。100通りを3桁にコード化するのは設計かも知れないが、1桁目を特定の値に縛るのは設計でも何でもない。それが当初からの要件にあれば、そもそも3桁には設計しないはずなのだ。逆に言えば、コードが破綻するのは設計するからであって、100通りの状態を表すのにコードを10桁にすれば、そう簡単には破綻しないだろうが、それはもはや設計とは言えない世界だろう。

設計というのは、整然とした要件やそれに基づいた仕様を元に行なうものであり、破綻するのは要件や仕様ということになる。これを勘違いすると確信犯的なエンドユーザの場合に痛い目に遭うだろう。

| | Comments (0) | TrackBack (0)

年末ブログ:土日のうどん、そば、ラーメン

いつからこうなったのか既に記憶が無いが、土日の食事は自分の分だけ作って食べるようになった。食材は自分の手持ちから支出することになるが、外食も含め家族の好みに合わせる必要が無く、好きな時間に好きなように作って食えるようになって、かなり気が楽になったような気がする。

それ以前は、家族といっしょに買い物に行くと、食品売り場で必ず夕食のメニューを相談されるのだが、否定するために聞いてるのか?と言いたくなるくらい、こっちの意見が通ったことはほとんど無い。二人の娘が大きくなるにつれてその傾向はどんどん強くなり、次第に自分の意見が通らないどころか、相談されることも無くなり、結果として買い物に一緒に行くことも無くなった。結果として、土日の食事は家族と別々という状態になった。よく、子供が娘ばかりだと羨ましがる人がいるが、それはそういう家庭の実態が分かっていないんだと思う。たしかに、自分がもし娘の立場だとしたら父親なんて鬱陶しいだけだろう。嫌がられているのにこっちから近づくのはゴメンだ。

そういう経過で、土日の食事は自分で好きなように食えるようにはなったが、贅沢出来るほど手持ちが裕福ではないため、自然と麺類が多くなってしまう。つまりタイトルの通り、うどん、そば、ラーメンだ。それも、一日三食作っていられないので、たいてい朝と晩は食パンやカップ麺であっさりと済ますことが多い。

Photo

これは、いつも買っている少し小ぶりの食パン。これにケチャップとマヨネーズととろけるチーズをのせて、レンジで1分チンしてから、あらかじめ熱しておいたトースターで2分焼く。そうすると外側がカリッとして中フワフワの超かんたんピザ風トーストが出来る。レンジでチンする理由は、トースターで焼くだけだとパンが真っ黒になるまで焼いても、チーズがトロトロにならず、さらにチーズがトーストに定着せず、食べたときにチーズがベロンと剥がれてしまう。

さて、うどんもそばもラーメンも、別に土日のすべての時間を使ってこだわり抜いているわけではなく、作り始めてから食べ終わるまで概ね1時間というのを目安に考えている。また、食材にかける費用も前述の通り青天井ではない。ただ、これはやったことない人には分からないことかもしれないが、うどん、そばのツユも、ラーメンのスープもソコソコの味で良ければ、それほど難しいわけではなく、手間もそれほどかからない。もちろん、結果として味が濃すぎたり、薄すぎたりというのは往々にしてあり得るが、それを気にしていたら何も出来なくなってしまう。そして、うどん、そばのツユやラーメンのスープを作るのが苦にならなくなったら、高いお金を出して外食する気がどんどん失せていくようになる。

Img_0314

これは最近作っている、自称ネギだく天玉ソバ。ネギは軟らかい愛知のネギが良いのだが、残念ながら画像の刻みネギは大分県産。真ん中の生卵を少し混ぜたところで、最初にそこを集中的に食べる。そうしないと卵がツユに拡散してもったいない。

ソコソコの味のツユを簡単に作る方法は、ダシ(煮干しでも、鰹節でも、昆布でも、本だしなどの調味料でも何でも良い)をちゃんと入れて、そこに普段食べているツユの色をイメージして醤油を入れる。その時点で味見すると、そのツユのベースが分かる。あとは好みに応じて、塩や砂糖を加えるだけだ。ツユに砂糖?という人がいるようだが、当然甘くなるほど入れるわけではない。こういう料理で砂糖を使いこなせるようになるのが、一つのマイルストーンじゃないかと思う。ダシの風味が足りないなと思ったら、食べるときにカツオの削り粉をふりかければ良い。

Img_0286

次にラーメンだが、これはその時の気分によっていろんなのを作る。以前よく作っていたのは五目ソバ(関東ではサンマー麺と呼ぶらしい)で、途中までタンメンのスープを作る要領で、麺にスープだけ注ぎ、残った野菜に片栗粉でとろみを付け、それをラーメンに載せるというものだ。最近作っているのは上の写真のような鶏ラーメン。意外に簡単に白濁のスープが出来る。まず、鶏モモ肉の皮の方をカリカリになるまで、中華鍋のようなフライパンでじっくり焼く。すると、皮に含まれるコラーゲンがたくさん出てくるらしい。モモ肉が焼けたら、そこに水を加え、小松菜や青梗菜などの野菜といっしょに煮込む。味付けは、塩、胡椒、おろしにんにく、くらいで十分。スープは薄めの味になるよう意識する方が良い。ただでさえ煮詰まって味が濃くなるし、あんまり濃い味にしてしまうと、せっかくの白濁スープを飲めなくなる。スープを作っている間に麺を茹でる時間は十分あり、それほど焦ることもない。

こんな感じで、相変わらずレシピを見ない料理を楽しんでいる(笑)

| | Comments (0) | TrackBack (0)

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 22, 2017

Emacs Threads 20170122

先月からちょこちょこ作っているTASKクラスであるが、最底邊の部分がある程度出來た氣がする。ちょっと前までcondvar(條件變數)の部分が動かなくて、スタブみたいな感じになっていたが、Emacsが改修されて動くようになったので、本來の處理に變えてみた。

Ws000103


TASKクラスというのはEmacsThreads機能をラッピングする。スレッドを起動するとそれに關するリソースを變數に設定しておかなければならないが、何も考えずにやるとどんどんグローバル變數がトッ散らかっていくので、そうならないようにクラス定義して管理しようとする試み。自分の都合で作っているだけなので、一般的でも、抽象的でも、普遍的でも、效率的でもない。

Ws000104


Ws000105


こんな感じのテストプログラムで自分のイメージ通りに動くことを確認したが、まだこれが何の役に立つのか自分でも分かっていない。この先、このライブラリを使って何かプログラムを書いていけば、どんどん變わっていく可能性が高い。既にcondvarの部分はまだ動作確認しているだけの狀態である。また、mutexcondvarをスレッド每に作る必要があるのか?という、かなり根本的な疑問もある。ただ、スレッドに付けた名前でアクセス出來るという手輕さくらいはある。

スレッドプログラミングはむずかしいという人が多いが、それは不必要性に比例してむずかしくなっていくと思われる。ここはスレッドを起動して多重化した方が良いと漠然と思える部分に使用するのが賢いやり方で、必要もないのに見榮でスレッドを使うような場合にはなかなか思い通りにはならないだろう。當たり前の話だが、必要性を感じないということはイメージしにくいということであり、どう動くかイメージ出來なければ正常動作を確認しようがないからだ。

ソースを見たいという奇特な人は以下のURLからどうぞ(笑)
https://github.com/nobulin

| | Comments (0) | TrackBack (0)

January 19, 2017

人工知能症候群

この1ヶ月ほど人工知能についていくつか與太郞ツイートしていた。プロフィールに書いているとおり自分のツイートの8割は冗談、2割くらいは自己主張という感じか。その閒に同時竝行でどんどん出てくる周圍の人のツイートのほとんどは樂觀論、待望論、ニュースの引用ばかりであり、これじゃあ冗談にもならないくらい前提や認識が自分とかけ離れているなと思った。

まず一番理解に苦しむのが、人工知能によってこれまで人閒が擔って來た職の一部が奪われる、ということに關する樂觀的な雰圍氣である。自分個人の感覺では、職を奪われたら明日からどうやって生きていくのかと眞劍に惱むところだが、彼らはそうではない。仕事をしなくて良くなるなら萬々歲だという感覺なのだ。人工知能が代わりに働くというなら、ノホホンとしていられるのか?人工知能ではなくて、自分よりも優秀な人閒が自分の職を奪うとしたら、それでもあっけらかんとしていられるのか?誰が奪おうが、自分の職が無くなることに變わりはないのだとしたら、少しは焦るのではないか?

もう少し現實的に考えた方が良いと思う。今居る會社の社員がある日を境にすべて人工知能(を搭載したロボット)になり、それに伴って人閒はすべて辭職するなんてことがあり得るのかどうか。たとえば、少しはリアリティがあるケースとして、社長と10人の社員が居る運送會社があったとする。その會社のドライバーが全員同時に人工知能に置き換わるのは非常に考えにくい。最良のケースでも一度に置き換わるのは半分だろう。そうなったとき、人閒社員は誰が殘り、誰が會社を去るのか?それは人工知能vs人閒ではなく、人閒vs人閒の構圖ではないのか?その時會社に殘るのは、閒違いなく10人の人閒の中で優秀な5人になるだろう。

そして、10人のうち會社を去る5人がそのまま潔くプー太郞になるのか、それともいくつかの會社の閒で玉突き的に人が異動するのか、會社によって事情は樣々だろう。いずれにしても、人工知能が人閒の職を奪う時、人閒同士の熾烈な(醜い?)生き殘り合戰が展開されるのではないか?というのが私のイメージである。それでも樂觀的でいられるのかどうか。

人閒も生物のひとつである。世の中に居る生物で遊んで暮らしているものがあるだろうか。形は違っても、生きる糧を得るためにどんな生物でも必死に活動しているのだ。そこらに居る野良ネコでさえ、遊んで生きているのではない。生きる糧が得られなければ生きていけないというのが自然の攝理である。人閒も例外ではない。

| | Comments (0) | TrackBack (0)

January 15, 2017

Emacs Threads 20170115




condvarのテストが初めて期待する結果になった。emacs/test/src/thread-tests.elを見てみると、新たにcondition-waitをテストする記述が追加されている。普通こういうのって動作する前から無きゃいけないと思うんだけど、なんで後付けなんだろう(笑)

| | Comments (0) | TrackBack (0)

January 03, 2017

Emacs Threads 20170103

大晦日にEmacscondvarについて書いた。その後、mutexのオーナーが自スレッドかどうかのチェックを、mutexの作成者かどうかのチェックと勘違いしていたため、それを踏まえて再確認した。

Ws000093

これが今囘使用するテストプログラム。自前のタスクライブラリを使用して、condition-waitを呼び出すだけの無名關數をスレッドとして起動する。

Ws000094

上記のテストプログラムをgdbから起動したEmacsで動かすことにする。その方がクラッシュしたり、知らないうちにスレッドがexitしてしまったりしても、すぐに氣付くことが出來る。

Ws000095

pop-to-bufferのところまで實行してみた。ログにはcondition-waitを呼び出す手前のメッセージが出ており、condition-waitの中で止まっているようである。この部分は事前に詳細に追いかけてみたが、實際にはpthread_cond_waitの中でブロックされている。

Ws000096

gdbの畫面を見るとスレッド(LWP 6279)が1個增えているのが分かる。

Ws000097

その後、condition-notifyを呼び出すと同時にスレッドが1exitする。この部分も事前にステップ實行しているが、なにせスパゲッティコードのような動き方をするので、よく分からない。正常に動作したのであれば「Recieve Notify」というメッセージがログに表示されるはずであるが、その前にスレッドがexitしてしまっている。何となくではあるが、pthread_cond_waitからリターンしてきたあと、longjmpし、cleanup處理(unwind-protectのような動き)をして、run_thread關數を終わっているようだ。つまり、何らかの囘復可能なエラーが起きたものと思われる。

Ws000098

上のソースはcondition-wait關數の中でpthread_cond_waitsys_cond_wait)を呼び出している部分である。その少し手前でcondvarに關連するmutexをアンロックし? pthread_cond_waitには別のロック(src/thread.cの中のstatic變數)を渡している。これはpthreadライブラリを直接使用する、他のCプログラムサンプルとかなり異なる手順に見える。まあ、それでもちゃんと動いてくれれば良いのだが。というか、そもそもcondition-waitってexit待ちじゃないよね?(笑)

| | Comments (0) | TrackBack (0)

«Emacs Threads 20161231