ソフトウェアの製造など、一瞬だ！！(誇張)

ソフトウェア設計とは何か？をななめ読みしていたのですが、
自分がいつの間にかSIerに毒されていることに気がつきました。

それはソフトウェアの製造とはどの部分かについてです。

SIer的な見地から言ってしまいますと、
ソースコードを書くコーディング作業は製造にあたります。

そしてよく自分は、
設計と製造は分割できないものであるから分けるなという議論に持っていきます。

でもよく考えてみてください。

分割できないものなのに、
用語では分割して定義している状態は変じゃないでしょうか。

本質的に同じものであるならば、
同じ用語で表現するべきです。

つまりコーディングは本質的に設計なのです。

そして製造とは、
ビルドを実行してからビルドが完了するまでを指すべきなのです。
(インタプリタであれば、毎回製造しているイメージでしょうか。)

これなら明確に設計と製造を分割できます。

実に清々しい、
目からうろこが落ち、
視界が晴れ渡る気分です。

…って、まだ本文をろくに読んでなかったんでした。

では読み進めるとしますかね。

加害妄想の世界へようこそ？

被害妄想という言葉は有名だと思いますが、
加害妄想という言葉もあることを最近知りました。

そして自分の精神を振り返ってみると、
思い当たる事が結構あります。

もしかしたら、
軽い加害妄想を持っているのかもしれません。

(他人が聞いたらドン引きかもしれませんけど)
そこまで致命的な症状でもないので、
ちょっと晒してみようかと思います。

あ、これが加害妄想だっていう確証はありませんよ？

あくまでもそれっぽい事例としてお伝えするだけなので、
「ふ～ん」程度の気持ちでお読みください。



よく発生するのは、
無防備(に見えるよう)な人とすれ違う場合です。

具体的には、
椅子に座って何か考え事をしている時などだと思います。

対象は最低でも顔見知りであることが多いでしょうか。

もうちょっとですれ違うようなタイミングで発生して、
脳内では実際の行動とは違う行動を行う自分の姿が再生されます。

加害の方法は様々ですけど、
すれ違いざまに無理なく行動できる内容に限られます。

思いっきりラリアットしたり、飛び蹴りしたり、
物を持っていたらそれを叩きつけるetc…

映像は実際に行動を起こす直前で止まることが多いですが、
たまに*事*を起こした後の映像も垂れ流されます。

自分で生み出した映像に嫌悪感を覚えていると、
もう現実ではすれ違った後です。

直前に起こった映像に身震いしながらも、
また日常に戻っていきます。



とまあ、加害妄想って言葉を知らなければ狂気と疑う内容です。

自分は狂気持ちなのかなとも思っていましたが、
やはり自分は普通の人間のようです。

そう言えばあまり好きではない人では起こってない気がするので、
その人を傷つけたくないという意識の裏返しなのかもしれません。

ちょっと過激ではありますけどね…



好きな人を傷つけてしまう映像が頭の中で再生されてしまう人がいたら、
どうか不安がらないでください。

それは多分、
あなたがその人を大切に思っている証拠なのですから。

その映像が現実の物とならないよう、
生きていけば良いのだと思いますよ。

(余談：もしその意識がシャドウとして現れるような事になっても、
自分だと認めてあげましょう。)

自我消耗について適当に考える

困ったときはWIREDからネタを引っ張ればいいか…

ということで、
今回は自我消耗について考えてみることにしました。

これより先の文章は、
素人が適当に考えを述べているにすぎません。

こんな考え方もあるのか～程度にお読みください。


まあ自分のイメージを言ってしまえば、
RPGなどでよく登場するMPの概念に近いと思っています。

何らかの決断を行うたびに減っていき、
0に近いときはろくな決断ができなくなってしまい、
寝たりおいしい食べ物を食べると回復するものです。

ここから得られる教訓があるとすれば、
ゲームと同じでMP管理は大事ってことです。


ふ～む、
ではこの自我消耗の最大値には個人差があるのでしょうか？

何らかの精神的成長があれば、
最大値が上昇したりするのでしょうか？

それを確かめるには最大値を測定できれば良いのですけど、
実現は相当難しい気がします。


なぜなら同じ物事での決断あったとしても、
どれだけ自我を消耗するかに個人差が生じてしまうからです。

例えば何度も同じ決断をしていれば慣れが来ます。

最初は全身全霊を掛ける必要があったかもしれませんが、
慣れてしまえば機械的にこなせる作業などは結構ありそうです。

また個人の適正によって、
得意なものなら消費が少ないでしょうし、
苦手なものなら消費は多いことでしょう。

つまりは全てが相対的であり、
客観的に使えそうな絶対値が見当たらないのです。

実用的にある程度数値化するのであれば、
人類の自我消耗の最大値は一律100%としてしまえば良いでしょう。

そしてある行動に対してのその人の消費量を間接的ながらも計測し、
どんな行動や決断で多く消耗するかを調べていくのは有効そうです。

ほとんどの行動に対して消費量が高い人は、
実際に最大値が低いのかもしれません。

しかしその人の得意なものが見つかってないだけかもしれませんし、
経験を積んだ行動は一気に消費量が減って化ける可能性だってあります。

もしかしたら、
誰もが発狂するレベルの事象には踏みとどまれる才能を隠しているかもしれません。

最大値の違いという要素を用意したとこで、
これらについての個性を上手く表現することに成功していません。

実用面に限って言えば、
最大値の差を比べることにあまり意味は無いってことです。


…本当に、
リアルというゲームの分析しているような気分になります。

自分がリアリティ重視のRPGを開発するのであれば、
MPに相当する項目は百分率表記にしてやるとしましょうかね？
(※今暖めているアイデアでは別の項目が百分率のため却下するでしょうけど。)

音が人間に与える影響

Wiredの"超音波を脳にあてて気分を操作"を読みました。

簡単に言ってしまえば、
脳のある場所にある超音波を当てると気分が良くなるというものです。

確かに名曲などを聞けば感情が揺さぶられることはありますが、
これは耳に聞こえない超音波です。

目に全く見えない超音波でここまで劇的な効果が出るなんて、
実はかなり驚くべきことなんじゃないでしょうか。

もしかしたら昔から特別な場所とされていたものの中には、
この超音波のような何かがあったりするかもしれません。
(別に超音波に限らず、目に見えない何かという意味で)


いや、ああなるほど、
携帯電話の電波についての影響が懸念されるのもこういう感じなのかな？

電磁波なら音波よりも脳への影響が強そうですし。

目に見えない*波*によって変わっていく人類…
う～ん、中二病テイストな響きがします。


おっと、話題が逸れました。

あるかもしれない未来に限らず、
今現実にあるものでも既に恐ろしい領域と言えます。

いわゆる音響兵器ってやつです。

研究室の中で完結しているお話ではありません。

こっちはとっくに配備が終わっていて、
使用された実績だってあるのです。

しかもそれなりの効果を上げたという報告付きです。

まあ超音波ではないので、
音は聞こえるそうですけどね。


まだまだ音波ひとつでも色々な可能性が眠っていそうです。

怒りは愛情かもしれないが、それが伝わるとは限らない

特に場所は問いませんが、
誰かが誰かに対して怒っているいるシーンを見たことが無い人はいないと思います。


町中で見かけるようなタイプは、
クレームによる怒りが多いでしょうか。

コンビニでタバコの購入にボタンを押す必要が出てきてから、
それに対してアルバイトの方に怒っているシーンを見かけたことがあります。


オフィスで見かけるパターンは、
何らかの失敗に対して上司や先輩が怒るパターンでしょうか。

怖い上司にビクついたことがさらなる失敗につながり、
さらに怒られるというマッチポンプを見たことがあります。
(この例では上司の方が移動となりました。)


どちらにも共通しているのは、
"何らかの希望や期待を裏切られたことによる失望から発露した感情＝怒り"でしょうか？

強い怒りの背景には強い希望や期待が込められているため、
これらの怒りは愛情表現として見ることができるのだと自分は思います。


まあそれはいいです。

怒りを向けられたことで成長した事例なんてたくさん出るでしょうし、
そこに異論はありません。

問題はその成長の事例の影に隠れた、
マイナスとなった事例はどれだけあるのかという話です。


学生の頃読んだきりなのでちょっと曖昧ですが、
ブラックジャックに紹介したい話がありました。

生徒をやたら厳しく怒り、叱る教師が登場するのですが、
その教師は単に血の気が多いというわけではありません。

その教師はその叱責をバネに一生懸命勉強欲しいという、
いわゆる生徒への*愛情*でそのような態度をわざととっていたのです。

でも生徒の一人が叱責に耐えられなくなってしまい、
自殺を図ろうとしてしまうというお話です。


フィクションの話ではありますが、
これを起こり得ないと言い切れるでしょうか。

自分にはそう思えません。

例え愛情が根源にあったとしても、
それが伝わらない例なんてたくさんあるのではないでしょうか。


このような一方通行の愛情を何と言うか、
私達は"ストーカー"と呼んでいなかったでしょうか。

自分はこれも、
ストーカーの変種だと捉えています。

ストーカー行為を続けていくと、
結果はどうなるでしょうか。

少なくとも、
ハッピーエンドにはならないのではないでしょうか。



まとめます。

怒りは愛情から発露することはあり得ます。

ですがそれでストーカー行為を働くのはやめましょう。

危険な無意識の制御 その3

前回までの話とカクテルパーティー効果の話は最近の記事ですが、
これはリンクしているのではという考えに至りました。

つまりカクテルパーティー効果が薄いことにより、
自分の出している声・音が自分が出しているものだと気がついていないのです。

音を発生させた当事者であるにも関わらず、
当人には雑音のひとつとして処理されてしまいます。

指摘を受けたときは、
自分が出した音に気がついたりしているわけじゃありません。

自分の直前の記憶を引っ張りだして、
音を出しそうな行動をしていなかったか思い返しているだけなのです。

ただそれがどんな音でどれくらいの音量だったのか、
その時の雑音の大きさぐらいしか判断材料がなく困ってしまいます。

そこで雑音が発生しないよう高級レストラン並の行動基準で動くわけですが、
これを長時間行えるような訓練もしてなければ訓練方法も分かりません。

結局静かにできないか、
身体に悪影響を及ぼすことでしょう。

まあ人間の*間*を近づけすぎると、
こうなりやすいってことです。

音は距離の2乗で減衰したはず(うろおぼえ)なので、
ちょっと遠くなるだけでもだいぶ違うんですけどねぇ…

よし、総集編っぽくなりました。

IVRは嫌われ者なのか

かなり古い話題です。

WIRED読者が選んだ「もっとも迷惑なテクノロジー12選」には、
トップバッターとして電話の自動応答システム(IVR)が挙げられています。

日本では大半の自動応答が電話機のボタンで操作しますが、
海外では音声認識が導入されている事が多いようです。

日本語よりもずっと認識率が高いのではと勝手に思っていましたが、
利用者の視点から見た感じでは芳しくないようです。

では電話機のボタンだけなら良いかと言われるとそんなことはなく、
慣れた利用者ほどオペレーターに繋ごうとするなんて事例はよく見かけます。

引きこもり体質の自分としては、
人間を介さずに済むならそれで良いかとついつい思ってしまいます。

ですが世間は逆です。

さっさと柔軟な対応ができる人間と会話を行い、
人間を介したサポートを望んでいるようなのです。
(統計データ上はね)

その邪魔をするIVRは、
"迷惑なテクノロジー"となってしまうわけです。



比較的音声系にいる自分としては何とかならないものかとも思うわけですが、
これに関してはかなり難しいかもしれません。

もしもこの先を目指すのであれば、
より人間的な対応を可能にする必要があります。

でもこの先には"不気味の谷"が待ち構えています。

IVRが迷惑と思われないようにするにはこれを乗り越えればならないでしょう。

…誰が谷を越えようなんて思うでしょうか？

今IVRを売っている企業で、
本気で谷を越えようと思っている企業が居るようには見えません。



もしもこの谷を超えることがあるとすれば、
電話業界とは離れたところからやってくる技術かもしれません。

そのとき、IVRにイノベーションが起こるのでしょう。

その日が来るまで、
IVRは今しばらく嫌われ者であるようです。

試験仕様書からチケットにしてしまった方が楽なのでは

ただいま試験の真っ最中なのですが、
試験項目の分割に頭を悩ませています。

複数人で試験しているのですが、
なかなか綺麗に分割できないのです。

仕方がないので同じ試験仕様書のExcelファイルを複数用意して、
口約束で項目を分担してから最後にマージするような運用を取っています。

さも当たり前のように行われていますが、
これって相当、非効率的な作業ではないでしょうか。



SIerや(担当者にとっての)厳格な品質が求められるソフトウェアの場合、
(ほとんどExcelの)試験仕様書なるものを書いて試験を行うことが普通です。

危うくスルーしかけてしまったのですが、
これも一種の帳票と言えます。

帳票になにかを出力用であって入力用するのはよろしくないと思う自分にとって、
これは改善を考えなければならないポイントに映ります。

つまりは試験仕様書という形に縛られていることが非効率なことであって、
本質的でない部分がたくさんついて回っているのです。


ではどうするのか。

試験を"バグがあるかもしれないから調べておいて欲しい箇所"の束だとすると、
タスクの一種としてバグトラッキングシステムに入れてしまってはどうでしょうか。

手順はこうです。

テキストでもXMLでもJSONでもなんでも良いので、
試験項目の一覧を作成します。

次に作成した試験項目をバグトラッキングシステムにインポートします。

そして通常通り試験を行い、
インポートしたチケットをこなしていくわけです。

新たに追加したい試験項目、
試験で見つかったバグ、
再試験したい項目あれば、
チケットの状態を変化させるなり新規に発行してしまって構いません。

まあただ付け加えるとすれば、
後でエクスポートするのでタグか何かの属性を付与することをオススメします。

試験が完了したら、
エクスポートしてExcelにまとめます。

バグトラッキングシステムのデフォルトの書式が気に入らないなら、
自分でプラグインなりアドオンなり書けばいいんです。

これで帳票を入力に使うという事態は回避され、
より柔軟な試験の対処が行えるようになります。



まあ問題があるとすれば、
バグトラッキングシステムを使っていないような環境では馬に念仏ってことと、
インポートとエクスポートのスクリプトを書くこと自体を許容して貰えるかってことです。

良い案だと思うのですが、
ダメですかねぇ？

簡単になったとしても、素人に任せるべきじゃない

よくソフトウェア開発においては、
「◯◯を使えば素人でも簡単に開発できるようになる。」
なんて文句を聞くことがあります。

実際に使ってみると、
10必要だった手順が3～4くらい省略できたりして、
確かに簡単に開発することができるようになっています。

しかし*素人でも*という部分はどうなんでしょうか。

ユーザーに対して必要な前提知識が減るのは素直に喜べるのですが、
開発者に対しては話が別です。

それは病院に最新の機器が入ったからという理由で、
素人でも簡単に診断ができるようになると言っているようなものです。

医者は医師免許のおかげでそんな事態にはならないのですけど、
プログラマーにはそんなものが無いためホイホイ引っかかってしまいます。

そして素人はその◯◯でスパゲティコードを書いてしまい、
やっぱりダメだったということが繰り返されてしまうわけです。

大抵この手の◯◯は、
用途を限定化させるか抽象化レイヤーを１層作ることによって効率化しています。

しかしそれは、
別に開発者の無能さを隠せるわけではありません。

依然として開発者自身の抽象化技法は要求されています。

ただそれに気がつくまでのタイミングが限定化・抽象化によって遅くなったに過ぎません。

だからちゃんとしたソフトウェア会社は面接時にコードを見るのであり、
それはプログラミングの本質が覆らない限り続くのです。

残業があるかもしれないということ

興味本位でFogCreekの募集要項を覗いてみたのですが、
その中の項目に面白い一文を見つけました。

May involve work after normal business hours, and being on-call

意訳すると、
「残業が出来て、営業時間外の呼びかけに応じられること 」でしょうか。

日本ではあまりに普通すぎてスルーしてしまいそうになりますが、
わざわざ記載が必要だという点が非常に興味深いです。

つまり海外(まあ少なくともニューヨーク)では、
日本と同じ社員の運用をするには要件に載せる必要があるってわけです。

日本の非常識を垣間見えたと思う人も居るかもしれませんし、
よそはよそ、うちはうちと思う人も居るかもしれません。

自分としてはちゃんと記載していることに大変好感が持てるのですが、
皆さんはどのような感想を抱いたでしょうか。