正義っていうか・・・考え方

今回は、こちらの本のご紹介。

これからの「正義」の話をしよう――いまを生き延びるための哲学

この10年で読んだ本の中では、なんというのか、一番ぐっとっくる本だった、実際。
ネットの言論ってやつを見るときにも、この本の言う大きな3つの考え方が、せめぎあってるんだな、という道筋ができて、急に世界が見えてきたよう感じられるし、自分の意見というのも、実はどれかに立脚している、というのも、腑に落ちた。

３つの考え方

３つの考え方というのは、ざっくり言えば、功利主義・自由主義・美徳、という考え方。
自分なりに、すんげ〜おおざっぱにまとめると、功利主義は全体が得すりゃいいよね、という考え方だし、自由主義ってのは、各個人が尊重されることが重要、という考え方。美徳ってのは、「正しさ」というのを何にせよ持っているわけで、それを大事にしよう、という考え方。

それぞれは、単独で見るとそれぞれ「まあそうだよね」というお話なんだが、実は対立するケースが多いよね、というお話が連打で出てくる。

たとえば、功利主義と自由主義の対立。極端な話、誰か人柱に出すことでほかの全員が助かる、という状況で、ほかの全員が助かるならＯＫ、だって全体として利益が上がるから。自由主義はダメ。個人を尊重しないといけないから。自由主義っていうからには、自分が人柱になる、という意思決定をすればＯＫかと思ってたけど、それは、理性ある人間を（自分の体であっても）道具として使うわけで、尊重していないからＮＧなんだそうだ。

美徳と自由ってのもある。
他人の子供と自分の子供がおぼれている。一人しか助けられない。どっちを助けるか？
理性ある人間の尊重という自由主義の立場からすれば、「どちらも同じ命」。
けれど、「家族とは助け合うものである」という家族に対する美徳を、実はみんな持っているから、自分の子供をたすけても、文句言う人はあまりいない。
これ、ちょっと大きくなると、他国で地震が発生したときに、日本人だけ最優先で助ける大使館の役目は正しいのか（現地の人を押しのけて助けるはありなのか？）という命題にもなるわけだ。

じゃあ、自分はどうなんだ、と。夫婦別姓を考える

自分自身は、自由主義の人間だと思っていて、誰かが決めた「価値」というものは、自分で選択して初めて「価値」だ、そう思っていたのだが、なるほど、暗黙のうちに同意している美徳って、実は多いんだな、ということに気が付いた。

たとえば、夫婦別姓。
夫婦別姓に関しては、自由主義的な自分は、「まあ、いいんじゃない」と思うのだが、横から別の自分が「え〜？ほんと？そうじゃないっしょ」と、語りかけてくる。
その正体を、今までわかっていなかったのだが、「結婚」の美徳を、私がどう考えていたのか、いや、どう感じていたのか、という点と、深くかかわっていたんだな、と、今さらながら、正体突き止めたり、という感じになった。

田舎の長男坊だった私にとって、結婚とは、今までアカの他人だった人を一族へ迎え入れ、一族の繁栄のために一緒に努力する人を決める行為という定義づけが、無意識のうちにされていたのだ。一族に迎え入れたことの証に、姓を一族のものとするのは、その結婚の美徳から考えると当然、そんな風に思っている自分が、自由主義的な自分の「まあ、いいんじゃない」に、異議を唱えていたのだ。

ということで、もうちょっと考えてみる。
もし、夫婦別姓に関して、美徳を支持する側の自分が納得する答えってないんだろうか？

折り合いのつく考え方

ひとつは、美徳そのものに対する懐疑。
結婚の美徳って、一族へ迎え入れることだ、ってこと自体が違うよね、という話。
ただ、これは、やっぱりだめだな〜。家族ってやっぱり大事だし、結婚するから家族になるんだし。先祖あっての自分、ってのは、本当にそうだと思うし。
本の中では、「物語的道徳」なんて言葉が使われていたけれども（多分、英語のcontextを無理やり訳したんだろうな、という用語）、それはやっぱり大事だと思うわけで。そうじゃなくって、家族や身内だけではなくて、全部の人を愛するなんて博愛主義は、おいらにはとても無理だしな〜

もうひとつは、美徳とほんとうに関係があるの？という懐疑。
うん、こっちのほうがなんかしっくりくる。今一緒に住んでいるヨメさんのお母さんは、当然姓が違うわけだけれども、家族じゃないのか、っていうと、決してそんなことはないよね、実際。けれども、当然私とは姓は違う。けど、家族。ってことは、少なくとも、私の中では、一族へ迎え入れているわけで、それと姓が同じかどうかなんてのは、実は関係ないのか・・・じゃあ、夫婦別姓で何が悪いんだ、ってことか。
うん、これなら、美徳を重んじる自分とも折り合いがつくね。

こういう、思考のフレームワークを与えてくれたという点で、とっても役にたった本だった。決して、正義を教えてもらう本じゅあない。実際、著者の思想自体は、全体主義に陥る可能性を低く見ている印象があり、私には同意できない内容だった。
けれど、それを差し引いても、これから何度か、読み直すことになりそうな本である。

最近のわかいものは・・・

結構勢いで書いてしまうエントリですが・・・

いや、実際ちょっとかわいそうだな、と、思うわけですよ。
こんなに先が見えない状態で、よくがんばってるなあ、なんて思ってしまうおじさんがここにいる、という話で。

世間一般の話をしているわけではなく、IT業界限定、もっというと、自分が今お付き合いさせてもらってる、いわゆるコンサルファームとか、大手ITベンダーとか、そんなところに関するお話なんですけどね。

前はね、思うに、必勝パターンってあったんですよ。
そう、必勝パターンです。
端的にいうと、名のあるコンサルファームにもぐりこんで、何でもいいから5年やれば、それなりに箔もつくし、スキルも付くし、食うには困らずバリバリやれる、みたいな必勝パターンですよ。

確かに、それに乗っかるには、結構苦労しなければならなかった。昔って、コンサルファームの従業員数は1000人いなかったわけで、新卒で入るなんてのが、結構な狭き門だったりするし、中途で入るにも、転職のハードルって、今よりもかなり高かったし。
入ったら入ったで、労働基準法なんて関係なく、年俸制だからって理由で、いくら働いても、一年の給料は一定。時間で割れば、マクドナルドの時給より安い、なんて話が、まことしやかに流れていて。

けど、まあ、勢いはあった。間違いなく。
従業員数が少ないってことは、基本的に自分でなんでもやらなくちゃいけないわけで、私自身も、今までユーザとの打ち合わせなんて行ったことなかったのに、転職した社会人3年目で、いきなり打ち合わせを仕切ってね、みたいな話になり。何も知らなかったから、しゃにむに勉強し、資料を作り・・・そんなのを繰り返し、どんどん知識・ノウハウを溜めていった。それこそ一気に。

そして、会社としてもどんどん大きくなっていったから、生き残ればえらくなる。やめていく人間も多いが、会社が大きくなるスピードはもっと速い。生き残るだけで、役職はある程度ついてくる。
おお、どこかで聞いた。高度成長期の日本みたいな話が、10年ほど前のIT業界・・・まあ、コンサルファーム関連の一部ではあったにせよ、そんな状態が起こっていた。
まあ、わたしも、それに一瞬乗っかったクチ。すぐに離脱したので、生き残れなかった人間側ではあるのだけれど。

ところが、ですよ。
今現在を見てみると、こんな環境じゃないよね、若人は。

先輩らしい人がちゃんといて、レビューをちゃんとやってくれて、残業代分はちゃんとお給料もらえて。そこだけ見れば、前に比べてとってもよくなったように思う。

けど、企業の成長のペースという点では、明らかに前よりスローダウンしてきており、組織として飽和気味になってきている。ま、1000人いないような状態から、日本だけで3000人だと5000人だのにしてしまえば、そりゃ飽和する。

しかし、その飽和してしまった段階で入る人間のほうが、人数としては圧倒的に多い。そりゃそうだ。母数が多いのだから。
けど、企業の成長ペースは遅くなっているわけだから、前のように生き残ればえらくなる、なんてのは、ただの幻想でしかない。そんなのは、今から10年ほど前の高度成長期に入った連中が、先行者利益として、がっつり押さえてしまっている。

若人の仕事はというと、規模がでかくなったから、やっぱり若いうちは、単純作業っつーか、ひとつの仕事をずーっとやるハメになるわけ。
従業員が300人とか500人とかって規模でやってたときには、大きな仕事なんてのは、自分の会社だけではできないから、協力会社を使ってみたり、そもそも大きな仕事には手を出さなかったわけだけれども、大きな規模になれば、大規模な仕事をやって、そこに自分とこの会社の人間を、どお〜っと人数突っ込むほうが効率がいいからさ、そりゃそうなるわけですよ。
で、大規模な仕事を効率よくまわすために、一番手っ取り早いのが、官僚的文化の導入だったりする。手順書、マニュアル。それ自体の価値は否定しないけれど、じゃあってんで、手順書だとか、マニュアルだとかを作る人ってのは誰なの？というと、そんなこと出来るヤツはいなくって、どこかからの借り物で茶を濁す。
たまに作ってみようか、みたいにやってみると、ハエがたかるように、細かな不備をあげつらい、てにをはのチェックだけをやる連中が湧いてくる。使いもにならなかったものを、ちゃんとしたものにしました、みたいなポジショニング。そんなのを狙う連中がわんさと出てくる。
そんな雰囲気のなかなら、当然、若人の最適解は、前例踏襲、マニュアルに基づいた仕事を、きちんとこなしていく。当然そうなる。
ま、それもいいんだが、前例踏襲、マニュアルに基づいた仕事をきちんとこなす、で、なんとかなるのは、大規模な仕事の中だけ。小規模な仕事に入れば、いろいろ自分でやらなければいけないし、大規模な仕事では、他の誰かがやってくれた、口うるさいクライアントや、突然止まってしまうシステムのお相手を、イヤが上でも自分でやるハメになる。つーと、大規模な仕事を続けること、ひいては、大企業になってしまったコンサルファームや、大手IT企業に居続けることが前提になるわけで。

そう、以前の必勝パターンは完全崩壊済み。
短期間で何でもやって、どこに行ってもなんとかなるスキルが身に付く、なんてことは、大規模な仕事の一部を前例主義に基づき、淡々と行うことが最適解の現在、それはただの幻想。
じゃあ、粘って粘って出世して高給取り、なんて路線も、上が詰まってて先がしれている。
こんな中で、よくやってるな、と、本気で感心してしまう。

じゃあどうしたらいいんだ、若人は、という話になると、正直私には答えがない。
客観的に見れば、ある業界がぐわっと大きくなるタイミングで、そこに飛び込むのが必勝パターンなわけだけれども、右左見たって、そんなとこが今あるんだっけ？？なんて感じになる。
ただひとつ言えることは、既得権益者である、おじさん上司の言ってることが、本当に自分のためになるのか、単に昔の経験から言っている時代錯誤なたわごとなのか、意識しているかどうかはともかくとして、若人を捨石にして、自分の立場を強化したいために言っているのか、それを注意深く判定するのが、自衛ってもんだろう、ということくらいだ。

自分自身は逃げ切れるか微妙な世代と立場だが・・・
けど、今の若人よりは、確実に恵まれてたね、ほんと。

給付金システムを脳内設計してみる

定額給付金が昨年出たときに、SalesForceを使ってめっちゃ短期間にシステム構築やりました〜なんて記事がでていたのを、昨今の子供手当て騒動を横目に思い出した。
SalesForceもCRMアプリケーションのひとつなわけで、SAP CRMをメシの種にしているわたしとしても、どんな設計をしたのか、なんてのを考えてみるのも、まあ面白いかなあ、と思うわけで、れっつ思考実験！でございますな。

事務処理の流れ・・・多分こんな感じ

定額給付金は、各自治体によって、具体的な事務処理のやり方は違っていたようだけれども、基本的な流れは一緒のはず。
１．各世帯に、給付予定額の案内を出す。その際、受取方法を指定してもらう。銀行振込一本で行くなら、振込口座を書く用紙を入れておく。
２．各世帯から返事が返ってくる。振込口座を、各世帯ごとに設定する。返事が返ってこない世帯には、案内の再送などで対応をする。
３．実際に振込みを行う。振込み結果がエラーとなった世帯には、再度口座の指定をしてもらう。
まあ、こんな感じに違いない、きっと。

CRMの基本機能を使った実装・・・最初のセットアップ

この業務を、CRMの基本機能を使ってマッピングしてみる。
まず、「各世帯に案内を出す」前提として、それらをマスタ化して保持する必要があるだろうな、ということで、多分住民基本台帳のデータを使って、得意先マスタにインポートする感じなんだろうな〜と、見当をつけてみる。
で、世帯主とその家族の関係を、親会社・子会社の関係みたいにインポートしてやれば、たぶんあとあと便利な感じだろうな〜という感じ。
そのあと、各世帯に対して、リードを自動生成する。このリードに、ステータスをつけてやって、この後の事務処理がどこまで進んでいるか、管理していくわけだ。
各リードには、明細をぶら下げる。ぶら下げる明細は、各世帯の家族。その明細1件ごとに、定額給付の金額を設定する。すると、それを積み上げたリードの金額が、その世帯に対する振込み金額になる、という仕掛けが出来上がる。

CRMの基本機能を使った実装・・・基本的な事務処理の流れ

次に、リードに登録された得意先（住民基本台帳が元）に基づいて、給付予定額の案内を出す。
必要なデータは、上でセットアップしたリードに全部入っている。世帯の住所と、給付予定金額およびその明細だ。
まあ、一括印刷してくれる業者がいるだろうから、その業者にデータを渡すと、戦艦みたいな巨大プリンターで、ガンガン印刷をかけてくれて、郵送されることだろう。そういうアウトそーソングやっている業者は、世間にはたくさんあったりする。郵送がされると、リードのステータスを進め、「案内発送済み」にする。
しばらくすると、各世帯から振込口座が記入された用紙が送り返されてくる。それらを、各リードに登録していく。得意先に紐付け銀行口座を設定できるのは、CRMの基本機能だから、特に問題ない。
で、振込み日が来たら、振込口座と金額をデータにして送信する。そうすると、各世帯が指定した口座に、定額給付金が振り込まれる。

エラーとか、問い合わせ対応とか

この事務処理で、主にエラーが発生しそうなのは2箇所。
郵送した案内があて先不明で帰ってきた場合と、返ってきた振込用紙が不完全である場合もしくは、銀行振り込みをしたらエラーとなって返ってきた場合だ。
このエラーの状態は、正常な状態と同時に存在できないから、上記のステータスでやっぱり表現できる。「あて先不明」の場合は、次のアクションが取れないが、問い合わせがあれば、あて先を訂正し、再度案内を出せば「案内発送済み」にステータスができるし、振込用紙が不完全であったり、振込みしたらエラーになった場合は、「口座再問い合わせ」みたいなステータスを作っておき、再度用紙を送付する、という流れだ。
で、各世帯から、「まだ振り込まれてないんですけど〜」とか、「案内が隣にきたのに、まだウチにはきてないんですけど〜」みたいな問い合わせがきた場合は、住所・氏名を元にして、リードを検索し、ステータスを見れば、どんな状態かわかる。
また、「ウチ、もう一人いるはずなんですけど〜」みたいな問い合わせには、リードに紐付いている得意先を参照し、「何月何日時点では住民票ないんですよね〜」なんて会話をするわけだ。

あれ、案外簡単じゃね？

こうやってみると、住民基本台帳からのインポートと、案内印刷用のデータアウトバウンドおよび振込用のデータアウトバウンドさえ作ってしてしまえば、普通のCRMアプリケーションで、給付金の管理システムは、ちょいちょいと作れてしまうような気がする。
データのやり取り以外の部分なら、得意先マスタからのリード自動生成なんて、CRMの基本中の基本機能だし、リードのステータス管理は、営業さんがどこまで商談を進めているか、という管理そのものだし。
こんな実例を出されたら、個別の市町村に売り込みに行ってるIT企業の営業さんは大変だろうな〜という感じ。次の特需は、たぶん子供手当てなんだろうけど、きっとギラギラした目で営業をかけてるSalesForceの皆さん対、それはさせじと防戦を続ける既存IT企業の営業さんの戦いって感じなんでしょうかね、きっと。。
ま、市町村のIT担当の方って、持ち回りの前例踏襲主義の方が多いから、「クラウド？しらね〜しヤラネ」って言うかもしれませんが。
ではまた。

95年1月17日を振り返ってみる

今回は、この両者のブログから考えたことをまとめてみた。

地震が起こったら、まずこれをしろ！
「「地震の時は水をためろ」はウソ」のウソ - tano13の日記

ただ、最初に、夙川ネタで脊髄反射をしてしまったことを、少々後悔している、という点については、書いておくべきかとも思う。つまり、以下は、中立的に見ようと心がけてはいるが、当然主観も入っている、ということだ。
当事者は当事者しか知らないこともあるが、知っているが故に、中立でいることは、ほぼ不可能だと思う。

時間軸を考えてみる

この両者の議論で、絶対的に違うのは、救援物資が届きはじめるまでの、時間軸の感覚である。

救援物資というものは、大雑把には2段階で用意される。
1段階目：飲料水、食料などの、絶対に必要なもの
2段階目：毛布、衣類、タオルなどの衛生・生活環境整備に使用するもの

1段階目の救援物資が届くまでの日付が、どうやら両者で違うようである。
元ネタのさとなお氏のところに届いたのは、震災発生後1日程度、
JavaBLACK氏のところに届いたのは、だいぶ後、おそらく3日後程度だったのではないか、と、推測する。

3日というのは、おそらく人間が我慢できる最長の日付であろう、そう思うからである。ここまでに飲み水、食料が定期的に届かない、という状態に陥れば、おそらく私も暴動参加者になってもおかしくないな、という感覚値である。
その前提の違いを考えると、「水」についての用途の考えが、両者で決定的に違うのも理解できる。早い段階で飲料水が手に入れば、次の重要な用途はトイレなどの衛生面に移るのはいわば当然で、その段階までの時間では、水は最優先で飲料水にまわすべきで、トイレに使うなんてバカか！という話になるわけだ。

ただ、Tano13氏が指摘しているように（私もそうだが）、自分が住んでいるマンションの貯水槽および水道管が無傷かどうかは、震災発生段階ではわからない。公園の貯水槽も同様である。もし無傷なら、溜めるなんてことはせず、いつくるかわからない飲料水として大事に残しておけ、という、JavaBLACK氏の主張は、結果的に正しいことになるが、もし破損していれば、当座、溜めれるところに溜めておく・・・極端な話、バスタブに溜めてもカセットコンロなどで煮沸すれば、ある程度は大丈夫だし、飲料水として使いまわす・・・という行動のほうが利にかなっている。
つまり、トイレ用に溜めるのはNGだが、飲料水として溜めることは、情報が限られた震災直後段階では当然の行動だと思うわけだ。1段階目の救援物資が届くタイミングが早ければ、トイレ用に流用すればよい。貯水層に残っていることを期待し、溜めない選択をするのは危険すぎる。

ロジスティクス構築の構築と「戦争」

さて、暴動がおきるおきない、という観点では、3日後までに、被災者側への飲料水・食料の継続的な供給が行われること、というのが、トイレ水対飲料水、というシナリオよりも重要なポイントであると考える。そこまでにこのロジスティクスが構築されれば、対立点は解消されるからだ。

このロジスティクス構築に、明らかにマイナスになるのは、被災者の車での移動である。もちろん、この車での移動は、救急救命活動にもマイナスになるため、JavaBLACK氏の言う全体を考えない行動という主張も、スジが通っている。

しかし、さとなお氏の置かれている立場を見てみると、様相は変わってくる。
彼の奥さんは、妊娠9ヶ月であったことがブログの別エントリからわかる。さて、その状態で、車以外の移動手段が現実的にあるだろうか。
段差が発生している道での車の移動は、確かに故障の可能性が高い。しかし、妊娠中の女性の歩く距離を、少なくすればするほど、おなかの子供の生き残る可能性は高くなるのは道理であり、いけるところまで行く、という意思決定をすることは、想像に難くない。しかし、行けば、故障しないまでも、道路渋滞の発生原因のひとつとなり、より緊急度の高い救急救命活動に支障が出ることは自明だ。

ここに、行動を起こさなければ死んでしまうかもしれない（何もなければよし、だが、それは結果論でしかない）自分の子供をとるか、より切迫しているかもしれない赤の他人の命を尊重するか、という、選択が発生する。これを、さとなお氏は、「戦争」と呼んだ、と、私は理解した。JavaBLACK氏は、「じゃあお前を殺してもいいんだな」と、応えたが、もう少し消極的な殺人・・・「あなたを救う救急車が止まり、あなたが死んだとしても、私は自分および自分の身内を優先するがいいんだな」という言葉なら、さとなお氏は、「そういうことだよ。私もそうするから（そうしたから）」と、答えるだろう。

積極的に誰かを殺すわけではないが、間接的に誰かを殺してしまうかもしれない、という状況は、あの日、誰もが経験したはずなのだ。つぶれている家の前を通るとき、少なくとも、その中の人を私は消極的に見捨て、殺した（かもしれない）。しかし、自分の友人のほうが優先だった。それを「戦争」と呼ぶのは、私にはしっくりくる。

つらい作業

つらつらと書いてみたが、やはり、自分の経験がネックになり、この手の話を書くのはつらい。前のエントリで、冷静に見れるようになった、と、書いたが、どうやらウソだったようだ。
ほかにも書いておいたほうがいいことはありそうだが、このへんにしておこうと思う。

15年たって

年も明けて1月も18日。

15年たち、やっと冷静に、95年1月17日を振り返れるようになった気がする。
ちょいちょい書いているけれど、この日、私は友人の死体を掘り出している。
当時は、そんなことで、自分の人生観が変わってたまるか！
なんて思っていたものだけれども、
結果として今、完全にその日にとらわれ、生きている自分も実感する。
避難所で聞いた、Tomorrow Never Knowsを聞くと、
どんだけ下手なヤツが歌うカラオケであっても、当時のことを思い出す。

結婚し、子供ができた、と、聞いたとき、
一番最初に思い出したのは、息子の死体の前で、泣き叫ぶそいつの父親だった。
自分がもしそうなったら？
そうならないためにはどうしたらいいのか？
そのことを、これから一生考えるつもりがあるのか？
「覚悟」なのかもしれないし、ただの感傷なのかもしれない。
けれど、もし、あの日がなければ。
今ほど日々の仕事を真剣にやっているか。
今ほど家族との時間をとろうと努力しているか。
今現在のレベルが、そもそもどうなのか、ということはちょっと棚に上げるが、
やっぱりそれはNoで、もっと劣化しているに違いない。
人生観が変わってたまるか、と、思っていた自分の人生観は、
すべてあの日に向かっていく。

10年目は神戸に行った。
今年は、家族と過ごした。
ヨメは、当時のいきさつをすべて知っているので、
テレビのニュースを、この日だけは、意図的につけようとしない。
いつもは見れないアニメを存分に見れる、子供たちは喜んでいる。
その心遣いが心地いい。

いつか、子供たちにあの日のことを話すことがあるだろうか。
95年1月17日は、5年に一度、ニュースのネタとして消費されるだけの日になり、
追悼式があっただの、特集：地震に備える、なんて話だけが、
ただただ流れていく。
その中で生きてきた子供たちに、何かを話すことがあるだろうか。

答えはないけれど・・・
ただ、子供たちには、長生きしてくれ、と思う。
オチもなにもない話だけれども。

メリークリスマス！！

一部の方には、有名なネタだそうですが、知らなかったんで・・・

すべてのはじまり、移送エラー

今日、たまたま、移送作業がありまして、3人ぐらいでワイワイやってたわけですな。
「げ！！赤くなったぞ、おい！」
「あちゃ〜、テーブルとデータエレメントの移送順、逆になってるじゃね〜か」
「ひえ〜ん、怒られる〜」
「あれ？」
「どったの？」
「なんか・・・エラーログにメリークリスマスって書いてある・・・」
「いくら苦労してるからってさ〜、もうちょとマシなこと言えないの？」
「それ、なんて自虐？」
「いや、ほんとに、ほんとに」
で、見てみると・・・確かにエラーログに「メリークリスマス」の文字がおどっている。
「うお〜案外シャレたことするねえ、独逸人」
「移送エラーの時に出るっつうのが、キュートねえ」
「エラーにかぶせて、クリスマスに働いている人間のダメージをさらに増やす、悪質な所業ですなあ」

悪ノリ開始

「おっし！OSS登録しよう！！」
「ｗｗｗｗ」
「いつもと違うログが出ます、とか、書いちゃう？」
「この際、ほかの日でも出るか聞いてみようよ！」
「そも、明日はどうなんだ？」
「そうねえ、明日、もう一発移送エラー出そうよ」
「勘弁してくれ〜俺が怒られる〜」
「お正月も出るのかな？」
「つっか、イスラム圏の国でも出すのかね、これ」
「アラビア語でログオンしてみるべ！」
「ウチのサーバ、英語と日本語しか言語対応してないっすよ〜」
「そっか、残念」
「・・・ソースみりゃ分かるんじゃね？」
「うん？」
「このメッセージ、ご丁寧にメッセージクラスとメッセージNo.取ってるよ」
「マジで？」
「メッセージクラス　D0、メッセージNo.328」
「よっしゃ、使用先一覧、いってみよ！」
ということで、メッセージ照会。

謹賀新年的な

「ちょｗｗｗｗ、メッセージNo.329ｗｗｗｗｗ」
「おお、謹賀新年！！」
「正月も出るのか〜」
「これ、英語のメッセージ、
SAP wishes you a successfull New Year
って、書いとるどｗｗｗｗｗ」
「移送エラーの瞬間に、成功してねｗｗｗｗ」
「一年の計は元旦に、失敗ｗｗｗｗ」
「これ、正月に一人で見たら、さすがにキレるだろうなあ」
「まてまて、本当に移送でアウトの時に出るかどうかはわからん」
「そりゃ調べないとね〜」
「う〜ん、仕事せずにこんなことを・・・」
「これは、障害対応じゃけん！！」

ソースを追うぞ！

ということで、使用先一覧を見てみる。
「う〜ん、使用先一覧からは出てこないですね〜」
「動的コールか。独逸人やるな」
「ソースコード検索いっときますか」
「そ〜ね、多分移送周りだから、R始まりですよ」
で、やってみると、見事にヒット！！

CASE DATE.
WHEN '1224'. " merry christmas
PERFORM STDO_SMI0 USING PRID SEV: 'D0301', 'D0328', 'D0301'.
WHEN '0101'. " happy new year
PERFORM STDO_SMI0 USING PRID SEV: 'D0301', 'D0322', 'D0301'.

「キタ〜〜〜〜」
「わかりやすいｗｗｗｗ」
「リテラルぅぅぅぅｗｗｗｗ」
「そっか〜、明日は出ないのか〜」
「正月出る〜〜〜」
「コメントそのままｗｗｗｗ」
「あれ？」
「どったの？」
「このhappy new year、メッセージNo.違うよ？」
「へ？あ、ほんとだ」
「この322ってメッセージ、なに？」
「End phase & *****」
「ぜんっぜん関係ねええぇぇぇｗｗｗｗ」
「なぜ正月にこれをだす？」
「つっか、単体テストもれ？」
「よっしゃ！OSS登録だ！！」

・・・あ〜楽しかった。
独逸人のみなさん、ありがとうございました。

ひとたらしの部長さんへ

二週間前にあった通夜は、整然としていた。
まあ、そりゃそうで、上場企業の情報システム部部長さんともなれば、仕事関係だけでもわんさか弔問のかたは来ており、整然と、マニュアルに基づいて誘導しなければ、全員が焼香なんてできやしない。

けど、やっぱり、位置取りが悪かった。
焼香の番はすぐに来てしまった。
親族の方におじぎをし、2回つまんで焼香。その後はもう、自動で外に出るだけだ。
正直、もうちょっと遺影のひとつでも見ていたかった。

もう7年前になる。初めてあったのは。
客観的にみて、ひとくせもふたくせもある、油断のならない御仁であったのは間違いないのだが、少なくとも、この部長さんがいなければ、私の今は、また随分と違ったものになっていただろう。
なぜだかわからないけれど、血の気が多く、すぐ誰彼かまわずケンカしていた私を、なんだかずっと我慢して使い続けてくれた。
6時すぎには、おそらく接待であろう飲み会に行くのだが、10時をすぎて、ふらっとプロジェクトルームに現れる。
当然、お酒が入っているので、赤ら顔なんだけれど、その部屋に残っている人間の名前と、何をやっているのかは、バッチリ覚えて帰っていく。
カットオーバーしてから、銀座のクラブに連れて行ってもらったとき、そのときに私がやっていた仕事を覚えていて、「ま、心配したが、よくやったよな」と、言ってもらったのが、とても嬉しかったことを覚えている。
結局、「ひとたらし」だったんだろうか。

丸々4年、その上場企業にはお世話になった。
当時部長代理だったその人の肩書きは部長になり、設備系のプロジェクトだとか、関連会社へのR/3展開だとか、そういった仕事をやらせてもらった。
そのときに、生産・物流全体であるだとか、予算策定プロセスだとか、原価計算だとか、そういった企業活動全体というヤツについて、実地で学び、経験することができた。
私は、ほとんど全部初めての経験だったのだが、「当然知ってますよ」という体を装った。部長さんは、ニヤニヤとそれを見ていたが、多分ハッタリだと見破っていたのだろう。

私の人生の幸運な時間を作ってくれた恩人は、定年には早すぎる年で、鬼籍に入ってしまった。
まだ、何にもお返ししてないのに。
けど、あの世でニヤっとして言ってそうだ。
「心にもないことを言うな」
いや、たまには、ハッタリなしの話もしますよ、私でも・・・