みんながパソコン大王
雑談<NO.129>

みんながパソコン大王
総 合 目 録 趣意書

表題一覧表

NO 表題 起稿 起稿日
雑談NO.130
1514 失敗しない「外資系」パッケージソフトとの付き合い方:「これバグでしょ?」 vs. 「それは仕様です!」(ITmedia) 礒津千由紀 17/04/15
1513 ペギー葉山さん死去 「ドレミの歌」「学生時代」など(NHK) 礒津千由紀 17/04/12
1512 京都で一番有名な桜は<?> シバケン 17/04/09
1511 筒井康隆氏、慰安婦像への侮辱促す? 「炎上狙った」(朝日新聞) 礒津千由紀 17/04/08
1510 難病医師:「使命最期まで」…「生きる希望」情報発信(毎日新聞) 礒津千由紀 17/04/07
1509 まだ1万台以上のオフコンが現役で稼働している(ITpro Active) 礒津千由紀 17/04/06
雑談NO.128

NO.1509 まだ1万台以上のオフコンが現役で稼働している(ITpro Active)<起稿 磯津千由紀>(17/04/06)


【磯津(寫眞機廢人)@ThinkPad R61一号機(Win 7)】 2017/04/06 (Thu) 18:39

 こんばんは。


 アプリケーション・ソフトウェアの移行をする費用が捻出できません。


> 残されたオフコンと、どうつきあうのか、あるいは別れるのか――。

> オフィスコンピュータ、略してオフコン。多くの読者が、感慨をもってこの言葉を聞くのではないでしょうか。かつて、全国の中堅・中小企業や工場の情報化を後押ししてきたこの小型コンピュータ群は、しだいにWindowsサーバーなどに置き換えられていき、年間出荷台数は1000台(2015年)程度まで落ち込んでいます。

> ベンダーも次々に撤退しました。とくにNEC、日本IBM、富士通の“オフコン3強”の一つ、NECが事実上の撤退をしたことは、時代の区切りを感じさせるものでした。

> しかし潰えたように見えるオフコンも、まだ1万台以上が現役で稼働しているといいます。困惑するユーザー、苦しむベンダー。そんな隠れた問題を追った記事が、

オフコンの憂鬱(ITpro Active)>

> です。単にオフコンの話としてだけでなく、レガシーとは何かを考える良い機会になると思います。ぜひお読みになって、今後への参考となさってください。
> (ITpro Active編集長 小向 将弘)


NO.1510 難病医師:「使命最期まで」…「生きる希望」情報発信(毎日新聞)<起稿 磯津千由紀>(17/04/07)


【磯津(寫眞機廢人)@ThinkPad R61一号機(Win 7)】 2017/04/07 (Fri) 23:38

 こんばんは。


 四十年近く前、不治の病に侵されながら闘病記と医療の改善(ワークショップの開催、模擬患者の提案、等)を遺した吉岡 昭正という医師がおりました。
 内容が古くなっていますから著書(遺稿)「死の受容」(毎日新聞社)の復刊は無いでしょうが、余命宣告されてからの自分の心理の分析に於いては、此れを超える本は出ていないと思います。


> 難病の筋萎縮性側索硬化症(ALS)とたたかいながら、同じ難病患者や震災被災者の支援に取り組んでいる医師がいる。訪問診療の現場で末期がんの患者らに寄り添ってきた千葉県八千代市の医師、太田守武(もりたけ)さん(45)。手足が動かなくなり、一時は自ら死ぬことを意識したが、周囲の励ましが再起を促した。医師として精いっぱい生き抜く覚悟だ。【江刺正嘉】


> 「人の力を借りてしか生きていけないことに心が折れ、死ぬことばかり考えるようになりました。しかし、訪問診療の先生やたくさんの専門職に優しくしていただき、やっと生きる希望を持つことができました……」

> 在宅医療をテーマに昨年10月、同市内で開かれた市民の集い。車椅子の太田さんは死のふちから生きる希望を取り戻した経験を講演した。呼吸機能が衰えていることから持ち時間の7分の倍以上を要したが、拍手は鳴りやまなかった。「医師としてまだやれることがある」と感じた。

> 発症は6年前。志した訪問診療の仕事が軌道に乗り始めた頃、右足を引きずるようになった。持病の椎間板(ついかんばん)ヘルニアかと思ったが、左足も次第に動かなくなり、車椅子の生活に。専門医に「ALS」の可能性を宣告され、やがて聴診器を持つこともできなくなった。医師の仕事をあきらめ、「生きている間は治療法は確立しない」と絶望した。

> 訪問診療でみとってきた200人近い患者の中にはALSの人もいた。「心残りがない最期を迎えてほしい」と接してきたつもりだったが、同じ立場に立ってみると、受け入れられなかった。何度も自殺を考えた。

> 希望の光をともしたのは、自宅に訪問診療に来てくれる桜川浩医師(54)の一言だった。「難病になった医師の経験を市民集会で話してほしい」。忘れようとしていた日々がよみがえった。「そうだ、自分は医師なんだ。最期まで人の役に立ちたい」。心のスイッチが「生きたい」に切り替わった。

> 医師としてどう生きるか--。決定的な影響を与えたのは、医学生として6年間を過ごした大分県での出会いだ。医学知識の詰め込みに疑問を感じ、医療問題の当事者たちとふれあい、学ぶサークル「かぼすの会」を仲間3人でつくり、自身が代表になった。

> 会の活動で知り合ったのが、乳がんと向き合いながら命の大切さを伝える授業をしていた中学養護教諭、山田泉さん(2008年に49歳で死去)。「一日も無駄にできない」と授業や講演を続ける姿に心を打たれた。「自分の目で見て感じて考えることが大事」という山田さんに影響され、薬害被害者やハンセン病元患者とも交流した。そして「独りよがりな医療ではなく、患者に寄り添いたい」と思い、訪問診療の道を志した。

> 「自分の目で」という山田さんの言葉が、11年の東日本大震災の際、被災地に目を向けさせた。かぼすの会の後輩と約20回も足を運び、がれき処理や行方不明者の捜索を手伝った。昨秋、ALSの症状が進行していたが、後輩の介助で3年ぶりに宮城県南三陸町などを訪れた。支援の継続が必要と痛感した。

> 現在、唯一動く左の人さし指で文章を作成し、フェイスブックで医療や震災の話などを発信する。今年中に、三陸と、熊本県内の被災地で無料の健康相談会を開くことも計画している。「こんな体でも頑張ってます、と少しでも被災者を勇気づけられたら」

> 限られた人生を生き抜いた山田さんの最期の言葉は「自分は人の役に立てたのかなあ」だった。それを自分に問いかけながら、暗闇を抜け出せない患者や被災者たちにもっともっと寄り添いたいと、心に決めている。

<参考=「難病医師:「使命最期まで」…「生きる希望」情報発信」(毎日新聞)>


NO.1511 筒井康隆氏、慰安婦像への侮辱促す? 「炎上狙った」(朝日新聞)<起稿 磯津千由紀>(17/04/08)


【磯津(寫眞機廢人)@ThinkPad R61一号機(Win 7)】 2017/04/08 (Sat) 13:55

 こんにちは。


 侮蔑の内容が分かりませんが、慰安婦像がなぜ少女像なのかに対しては疑問を覚えておりました。


> 作家の筒井康隆氏(82)が自身のブログなどで、韓国の慰安婦を象徴する「少女像」に侮辱的な行為をするよう呼びかけるようなことを書き、国内外から批判の声が上がっている。


> 4日付のブログの投稿で、帰国していた長嶺安政・駐韓大使が韓国に戻ることに触れ、「慰安婦像を容認したことになってしまった」と指摘。慰安婦像の少女を「可愛いから」と述べたうえで、性的な侮辱表現を続けて使った。公式ツイッターも同様の内容を発信したが、つぶやきはすでに削除されている。

> 筒井氏は朝日新聞の取材に対し、「あんなものは昔から書いています。ぼくの小説を読んでいない連中が言っているんでしょう。本当はちょっと『炎上』狙いというところもあったんです」と明かす一方、「ぼくは戦争前から生きている人間だから、韓国の人たちをどれだけ日本人がひどいめに遭わせたかよく知っています。韓国の人たちにどうこういう気持ちは何もない」とも話している。

> 筒井氏はこれまで、社会的なタブーをあえて破る表現で論議を起こしてきた。今回のブログやツイッターに対し、ネット上では「筒井さんの作風」と擁護する声がある一方、「セカンドレイプにしか受け取れない最低な発言」「不謹慎の方向がおかしくなっている」「『下劣』としか評しようがない」などと批判が上がった。韓国紙の朝鮮日報日本語版も「衝撃的な妄言」などと批判している。

> 筒井氏は過去には、教科書に載った小説「無人警察」のてんかんに関する記述が、「差別を助長する」として日本てんかん協会から削除や訂正を求められたことに反発。「自分はブラック・ユーモアの文学的伝統を守ろうとしている」などと反論、1993年に「断筆宣言」をしたが、約3年後に断筆を解いた。

<参考=「筒井康隆氏、慰安婦像への侮辱促す? 「炎上狙った」」(朝日新聞)>
<消滅・18/04/22>


NO.1512 京都で一番有名な桜は<?><起稿 シバケン>(17/04/09)


【シバケン】 2017/04/09 (Sun) 00:16

<問1>=京都で一番に有名な場所は<?>

<答1>=祇園


【シバケン】 2017/04/09 (Sun) 00:37

<問2>=京都で一番に有名な公園は<?>

<答2>=祇園の、円山<まるやま>公園。


【FH】 2017/04/09 (Sun) 08:29

シバケンさん おはようございます。

京都で一番有名な桜の場所は祇園ですか!。
近所の疎水の桜も綺麗に咲いてます。

京都の開花宣言は3/31やったんですね。
見落としていました。(笑)


【シバケン】 2017/04/09 (Sun) 09:56

FHさん、おはようございます。

>京都で一番有名な桜の場所は祇園ですか!。

イヤ、
「祇園の、」
とは、云いませんねえ<笑>
ですが、結果的、そんな事になるですが。

では、
最終問<!>

<問3>=京都で一番に有名な桜は<?>

<答3>=「円山公園」の、「しだれ桜」


に、なるの哉と。

で、
あくまでも、「有名な桜」であって、「桜の名勝」では、ないです。



<続く>


【シバケン】 2017/04/09 (Sun) 10:09

<続き>

での、
再度の、FHさん、

>近所の疎水の桜も綺麗に咲いてます。

そおですか<!>

あの界隈の、疎水なら、情緒あって、綺麗でしょおねえ。

>京都の開花宣言は3/31やったんですね。
>見落としていました。(笑)

オッとの、そですか<!>
全然、知りませんでしたです<ド笑>。

確かに、昨日<4月8日>は、満開でしたです。
ですが、この雨、小雨で、散るも早いの哉と。

又、小雨では、円山公園の夜桜見物も、微妙で、場所にも寄るですが、地面<通路>が、ぬかるんでまして。
夜では、その状態見えませんでして。


【シバケン】 2017/04/09 (Sun) 10:44

イヤ、
わざわざの、円山公園、しだれ桜を見物に。
では無いです。

その目的なら、デジカメ持参するですが<汗>
元々が、その手、習性ありませんでして、いつもの事ですが、しもたなあと<大汗>

イヤ、
主目的、小雨の中、墓参<東本願寺祖廟>に行きまして。
時期が、時期ですので、又、「東本願寺祖廟駐車場」から、墓地えの道中、桜の状態、チラチラ、見えまして。

それならと、墓参を済ませてから、「駐車場」えの、帰りの道中、寄り道にて、「円山公園のしだれ桜」をと。

オッとの、公園には、沢山の桜の木があるですが。
公園の中心部にて、一段の、存在感示してるのが、「しだれ桜」。


での、
小雨の中、大勢の人でしたです。
大多数、レンタル和装の観光客<日本人>と、外国人。


【シバケン】 2017/04/09 (Sun) 11:08

<追記>

オトトの、添付の写真は、当方が撮った、では無いです。
嫁はんの、スマホです。
それを、もらい受けまして<ド汗>

当方も、ケータイ<ガラケー・らくらくフォン>は持参してるですが、持ってるだけで、カメラ機能、使うの習性無く。


【FH】 2017/04/09 (Sun) 12:18

シバケンさん こんにちは。

今、撮ってきました。(笑)
本数はそんなにありませんが・・・、こっちも満開ですねえ。


【磯津(寫眞機廢人)@ThinkPad R61一号機(Win 7)】 2017/04/09 (Sun) 12:27

 シバケン様、こんにちは。


 当地、昨日の4:27~9:18と14:06~23:30と今日の3:32~6:50に大雨警報が出てまして。
 「咲いた花なら散るのは覚悟」(亡父の学校の愛唱歌)とはいえ、可也、散ったと思われるです。

 当地の桜の名所は、駐車場から歩く必要があるところばかりで、此処3年、お花見には行ってませんです。


【シバケン】 2017/04/09 (Sun) 13:06

FHさん

写真、ありがとうございます。

イヤ、
確かに、満開で、壮観ですねえ。疎水そのものが、情緒ありまして。
京都、伏見の銘酒処の、でして、尚更にです<笑>

オッとの、
当方、下戸で、日本酒は、苦手ですが<ド汗>
飲むが苦手だけでして。

過年には、「月桂冠」、河童の、「黄桜」を見学。
「神聖」の鳥せい<料理屋>では、昼食をと。
団体さん<芋煮会>での参加ですが。



礒津千由紀さん

御地では、大雨警報が出たですか。
こちらは、小雨で、本日、朝方も、小雨でしたですが、午前中には、止みまして。
所謂の、曇天です。

我が家、近くには、街路樹としての、桜が植わってまして。結構、綺麗です。
歩きに出る時には、その界隈、通るです。

まだ、散って無ければ、明日にでも、写真を一発<!>と。
覚えてたら、ですが<汗>


にしてもの、
「同期の桜」が、御尊父様出身校の愛唱歌でしたですか。

当方、音痴で、歌のレパートリ少なく、カラオケでは、順番来たら、逃げるですが、逃げられんの状況なら、これを歌うにしてるです。


【磯津(寫眞機廢人)@ThinkPad R61一号機(Win 7)】 2017/04/09 (Sun) 13:59

 シバケン様、こんにちは。


 当地も、車で走ってるとき、庭木の桜の満開を見かけるです。

 「同期の桜」、当該校出身者が懐メロとして歌うは許容なれど、軍国主義・君主主義の塊であり、一般に歌うは、お勧めいたしかねるです。
 軍歌にも数あれど、この歌の歌詞は特別(みごと散りましょ国のため)でして。
 肯定的に歌ってると誤認されるは、宜しくないです。
 私も、上の投稿で、この歌の歌詞を持ち出したことを、後悔してるです。


【シバケン】 2017/04/09 (Sun) 17:54

磯津千由紀さん、こんにちは。

カラオケも、この、十数年、ご無沙汰ですが。
元々が、カラオケも、歌うも、苦手で、カラオケそのものが、数回での、おつきあいです。

の程度で、止めるです。


【シバケン】 2017/04/09 (Sun) 23:28

<副題=「円山公園のしだれ桜」の話>

現在のは、樹齢80年の二代目でして。
先代は、樹齢220年で枯死。

正式名称、「一重彼岸枝垂桜(ヒトエヒガンシダレザクラ)」
文字通り彼岸の時期に花を咲かせる桜。

通称、「祇園のしだれ桜」或いは、「祇園の夜桜」。
と、されてるですが。
当方、「祇園の」とは、聞いた事ありませんです。

「副題」通りの、「円山公園の」です。

まあ、どっちでも、正解は、正解ですが。
「祇園の円山公園」でして。


【シバケン】 2017/04/10 (Mon) 08:18

副題=昔、昔の夜桜見物での話<その1>

イヤイヤ、
その昔、昔。
円山公園に、夜桜見物に行ったです。
云うても、二度しか、行ってませんですが。

その一度目、多分なら、小学生の頃、親に連れられまして。
その時、酔っぱらい女性、当然の成人ですが、浅くて、足首程度の深さの小川に、ハイヒールのままで、入ったのを見まして、ビックリしたです。

二度目は、社会人になってからの、二年目か、三年目の、二十代の頃。
ブラジルからの実習生、日系一世で、日本語出来るですが、それを有志のみ、三人か、四人で、歓迎会として、平日、会社が終わってから、連れてったです。
この時には、ゴザを借りまして、食い物、アルコール類も調達の、まさしくの、夜桜見物、桜の下での、宴会したですが。
当然の、有志の自腹<!>

での、
ブラジル、サンパウロの事、日本では、どこの住人であったのか、ブラジル語は、ポルトガル語である、等々、話に花が咲き。

実習生、至って、大人しい性格でして。真面目でもあったですが、次第、次第に、云うてる事、日本でなら、トンでもの、中身になりまして。
カーニバルでは、ピストルを天井に向けて、撃った、とかとかの、あのなあと。
上に撃ってば、下に玉が落ちて来るです。誰かに当たってる可能性がと。
又、混血多く、私生児多く。女性は美人が多くと。

での、
その実習生が、酔っぱらいまして。
喋ってる事は、中身、異常も、呂律しっかりでしたですが、歩けませんでして。
当方なら、下戸で、殆ど、飲んでませんですが。
帰りは、タクシーで、有志二人哉で、宿泊先まで、送りましたです。

とまあ、
表面的には、この程度。
表面も、事実の話なれどの、次、裏<?>の話。


【シバケン】 2017/04/10 (Mon) 09:56

副題=昔、昔の話<その2>

朝から、何ですが。
ここだけの話の、昔、昔の話故、他言、どでも結構ですが。

実際には、一度目の女性、小川で、用を足し。
二度目のは、その実習生、タクシーの中で、脱糞。

イヤ、
女性の件は、だけの話でして。酒は怖いなと。

実習生のは、彼をしかるべくの、場所で降ろし、席を詰めるの際、座席が、ンの、ザラ付いてまして、濡れてまして。
嫌な予感の、手で触り、臭い嗅げば、ンの、やって呉れたなと。

運転手さんに、どのよに云うて、謝罪して、処理したか、までは覚えてませんです。
そもそもが、どこで、降ろしたも、定かに非ず。モ1人の、同行者も、誰であったの哉の、遠い昔の話でして。

での、
ブラジルからの実習生。
この、夜桜のは、抵抗器工場の、でして。
彼以外にも、後年、何人かが、来てるですが。彼以外は、ブラジルでは新製品、新工場の、ダイオード製造の面々でして。

基本、その手、人材を選んでると、思うですが。
皆様、日系一世で、態度はきはき、礼儀の正しい面々です。

問題は、皆様、数学に非ずの、算数出来ませんです。
四則計算が出来ませんです。暗算なんか、トンでも状態。
当時に電卓、まだまだの高価。
にしたって、この手、基礎の基礎、どやって、教えるの怪と。
実際、どしたかは、忘れたです。

それでも、ブラジルでは、日系人なるは、モテモテの、インテリゲンチャンで、就職するに、引き手数多也と。
そらもお、そもそもがの、文盲多いですて。
フウンと、感心したですが、さもなくばの、地球の裏側えまでの、渡伯はなと。
とは、当方、独断、偏見ですが。


結果的、話が、大いに逸れたですが。
円山公園の、夜桜での、想い出、誰様かは、知らんの、小川でハイヒール女性の、小用と、ブラジルからの、実習生君の脱糞の、以上2件<!>


【シバケン】 2017/04/10 (Mon) 10:17

副題=これより、近在の桜見の散策に出るです

本日、特段の、野暮用も無く。
場所も、すぐの、そこでして。

実は、昨日、夕方にも、ほんの、小雨の中、見に行ったですが。少々、期待外れ感あったですが。
デジカメも、持参するを失念してまして<汗>
此度、デジカメ忘れずにと<笑>


【シバケン】 2017/04/10 (Mon) 12:48

副題=デジカメが、「プロテクトがかかっています」表示

イヤ、
実は、家出るの直前、デジカメの電池はどかと、確認するに、モニター画面に、「プロテクトがかかっています」表示で、えと。

イヤ、
検索、探索にて、判明したです。
「SDカード」の横手に、ノッチがあり、動かす事で、ロックを掛けるですて。

ありましたです。
ノッチを、動くの方向に移動させ、確認したなら、表示されませんでしたです。

嗚呼、ヨカツタなと。

での、肝心の、桜の状況、やっぱり、でしたです。


【シバケン】 2017/04/10 (Mon) 14:03

副題=近所の桜

昨日には、
迫力が無いなあと、此度、周辺、2度、回ったですが、やっぱり、でしたです。
撮し手が、悪いもあるですが、写り具合も悪く<汗>

場所は、国道9号線より、京都縦貫道、大井インターえの道。


【Plamo方面名倉 at Windows 7Starter】 2017/04/10 (Mon) 23:32

京都の桜というと自分的には

Re: <解説>ホーム・ページの運営法<シバケンの場合> 2016/02/03 (Wed) 10:58:56
<参考=「NO.210 <解説>ホーム・ページの運営法<シバケンの場合>」寄稿Plamo-方面名倉 at Windows 8.1pro 2016/02/03 (Wed) 10:58

>たしか嵐電に併用軌道区間があるはず?
京阪京津線京都市内は地下鉄になってしまったが末端の大津市内は併用軌道区間あるはず。

地下鉄になってしまった旧京阪京津線京都市内併用起動区間の桜めあてに京都にいったことがあります回数は忘れてしまったけれど一回ではなかった。

よりおもいだせない。


【シバケン】 2017/04/11 (Tue) 00:24

「京阪京津線」
京阪電鉄<おけいはん>の、京都<山科御陵>-滋賀<浜大津>間ですねえ。
ここは、現在でも、路面電車と、思てるです。

オッとの、以前には、三条京阪駅が起点でした。
且つは、山科は、現在、山科区となり、京都市です。

での、
そ云えば、その道中の、特には、逢坂辺りは、桜が綺麗です。

以前には、滋賀大津にも、行ってたです。
妹家が、琵琶湖大橋の方にありまして。現在<数年前>、伏見に引っ越しまして、用事も無くなったですが。

今々は、分かりませんですが、妹宅からの帰りしな、下手な時間帯に出たら、道路と云う道路は大渋滞で、難儀したです<笑>。


NO.1513 ペギー葉山さん死去 「ドレミの歌」「学生時代」など(NHK)<起稿 磯津千由紀>(17/04/12)


【磯津(寫眞機廢人)@ThinkPad R61一号機(Win 7)】 2017/04/12 (Wed) 17:13

 こんにちは。


 カーラジオで訃報を聞きました。
 馴染み深い歌を沢山、歌って呉れました。


> 「ドレミの歌」や「学生時代」などのヒット曲で知られ、女性として初めて日本歌手協会の会長も務めた歌手のペギー葉山さんが12日、肺炎のため東京都内の病院で亡くなりました。83歳でした。


> ペギー葉山さんは東京都出身で、昭和27年にレコードデビューしました。昭和33年には、NHK高知放送局の依頼で歌った「南国土佐を後にして」が、ふるさとを離れて働く人たちの望郷の歌として大ヒットしました。

> その後も「ドレミの歌」や「ラ・ノビア」、「学生時代」など幅広いジャンルのヒット曲で人気を集め、昭和41年のNHK紅白歌合戦では紅組の司会を務めました。

> また平成17年に亡くなった俳優の根上淳さんと仲のよいおしどり夫婦として知られ、根上さんの闘病生活を支えてきました。
> その後も平成19年に、女性として初めて日本歌手協会の会長に就任するなど第一線で活躍し、おととし3月、放送文化賞を受賞しています。

> 所属するレコード会社によりますと、ペギー葉山さんは最近まで活動を続けていましたが、10日に東京都内の病院に入院し、12日昼前、肺炎のため亡くなったということです。

<参考=「ペギー葉山さん死去 「ドレミの歌」「学生時代」など」(NHK)>
<消滅・17/04/28>


NO.1514 失敗しない「外資系」パッケージソフトとの付き合い方:「これバグでしょ?」 vs. 「それは仕様です!」(ITmedia)<起稿 磯津千由紀>(17/04/15)


【磯津(寫眞機廢人)@ThinkPad R61一号機(Win 7)】 2017/04/15 (Sat) 14:19

副題=前編

 こんにちは。


 良くあるトラブルですね。


> 外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。読者の皆さんも、一度は「それは仕様です」という悪しき“魔法”の言葉を聞いたことはありますよね。ともすれば、トラブルに発展しがちなこの状況はなぜ生まれるのでしょうか。

> [吉丸新一郎(日本ヒューレット・パッカード),ITmedia]


> 「バグのないプログラムは存在しないが、デバッグの不可能なプログラムもまた存在しない。違うか?」

> このせりふは、とあるSF映画の冒頭の一節です。アニメが好きな方ならピンと来るかもしれませんね。今回取り上げるのはソフトウェアのバグについての話です。

> この言葉は、ストーリー上の重要なテーマを暗示しているのですが、ソフトウェアが自分の思い通りに動かなかったとき、それがバグなのか、それとも仕様なのかという問題は、いつもユーザーが(そしてメーカーも)頭を悩ませる問題です。皆さんも次のような状況で困ったことはありませんか?


> 失敗事例14:ユーザーはバグだと思っているが、メーカーは「仕様」の一点張り


≫ ソフトウェアのサポート窓口 A:はい、こちらはXXソフトウェアのサポート窓口です。ご用件をお聞かせいただけますか。

≫ ソフトウェアの運用担当者 B:先日連絡した、xxの実行間隔が5分より短く設定しても、それより短くならない件ですが、原因は分かりましたか?

≫ A:はい、さきほど開発元より回答がありまして、5分より短くできないのは仕様とのことです。

≫ B:それは困ります。どうしても間隔を1分にしないと、うちの会社がお客さまに提供するサービスとの整合性が取れないのです。1分で設定したときも特にエラーにはなりませんし、入力した値で動作しないのはバグではないのですか?

≫ A:いえ、ソフトウェアのコードを確認したのですが、5分以下には設定できないよう、制御されていました。ただ、確かに5分以下の時間が入力可能なのは誤解を招くと思いますので、今後のバージョンで入力制限を検討するとのことです。

≫ B:いや、私がお願いしたいのはそういうことではなく、1分で指定できるようにしてほしいのです。その制御を外すだけでできそうじゃないですか。それに、ユーザーガイドのどこにも、そんな制限があるなんて書いてないし、バグとしか思えないのですが。

≫ A:恐れながら、本ソフトウェアの設計上、5分以下の間隔での動作は想定されておらず、製品コンセプトからも外れた使い方となってしまいます。マニュアルについては不親切な点があったことをおわびいたしますが、コンセプトガイドの方では、本製品はそのような短い間隔での処理にそぐわない旨を記載しております。ご了承いただけませんでしょうか。

≫ B:なるほど、そちらの言い分は分かりました。それでは……


> 今回の例は、多少ユーザー側に分がある内容でしたが、このようなグレーな話はいくらでもあります。「できないなんて聞いてない」「できるなんて言ってない」と終わりのない“水掛け論”になってしまうケースも少なくありません。

> ユーザー側は実現してほしい機能(5分以下に設定できるようにしてほしい)を明確に伝えているし、修正箇所も特定できています。メーカー側はなぜこれを「仕様」だとして、さらにユーザーの意図にそぐわない修正を加えようとしているのでしょうか。


> 「仕様」には2つの意味がある

> その理由は、Aさんの言葉にある「5分以下には設定できないよう、制御されており」という部分が示しています。これは、ソフトウェア設計者が明確に意図した処理(コーディング)だと考えられ、5分以下の設定では動かせない(または動かしたくない)理由があることを意味します。

> これは性能に起因するものかもしれませんし、後続のプロセスとの整合性によるものかもしれません。いずれにせよ、設計書にそのような記述があり、プログラム担当者がそれに従ってコーディングしたのであれば、それは明確に「仕様」といえるでしょう。しかし、開発時に問題があり、ユーザーインタフェース(設定画面)上では、ユーザーが任意に値を入力できるようになっていたわけです。

> 一方、ユーザー側はそのような設計の経緯は知りえません。本来であれば、ソフトウェアの設計に従って入力が制限されるべきところが、ユーザーに見えているのは、その設計に適さない入力画面だけ。しかも、そちらが自分にとって都合がよい場合、なおさら「それはバグだ、修正してほしい」という話になるわけです。

> このように、メーカー側は設計に従った動作を「仕様」と言い、ユーザーは自分にとって望ましい動作が「仕様」で、そうでない場合はバグに見える――というすれ違いが生じます。

> ユーザー側が主張する仕様も「要求仕様」という立派な仕様なのですが、それは製品の選定、または要件定義のフェーズで提示すべきものであって、運用の段階になって提示しても、サポート窓口の担当者は、その要求を聞いて設計するのが役割ではないため、会話が成立しないという残念な結果に終わってしまいます。


> 自分が使った「仕様」の意味を理解しているか

> 今回の話はあくまで一例ですが、「パッケージソフトウェアなのだから、SIのようにがっちりと要件を定義しなくても、自分たちがやりたいことと製品のコンセプトや機能が一致していれば、ささいなことは確認しなくても何とかなるだろう」と思う方もいると思います。確かにせっかく既製品を使うのだから、細かいところまで確認、定義していてはスピードという利点を損ないかねません。

> しかし、今回の例であれば、Bさんの言う「間隔を1分に設定しないと、弊社がお客さまに提供するサービスとの整合性が取れない」というのは、製品を使う上でクリティカルな部分です。これをアーキテクチャ設計の用語で「ユースケース」、または「品質特性シナリオ」と呼びます。

> その評価や設計には客観的な手法が存在しますが、それはまた別の機会に扱うとして、ここでは「仕様」という言葉について、ユーザーが言う「要求としての仕様」と、メーカーが言う「設計、実装としての仕様」では、意味合いが異なるということを理解していただければと思います。それが会話が平行線になるのを防ぐ第一歩です。

> さて、一度矛を収めたように見えるBさんですが、この会話には続きがあるのです。その内容は後編で。

<参考=「失敗しない「外資系」パッケージソフトとの付き合い方:「これバグでしょ?」 vs. 「それは仕様です!」(前編)」(ITmedia)>


【磯津(寫眞機廢人)@ThinkPad R61一号機(Win 7)】 2017/04/15 (Sat) 14:42

副題=後編

 こんにちは。

 結局は「泣き寝入り」になることが普通ですよね。


> 「それは仕様です」

> ITシステムの導入に携わっていれば、この言葉を聞いたことがある人は多いのではないでしょうか。今回も前回に引き続き、ソフトウェアの仕様とバグをめぐるメーカーとユーザーの攻防をご紹介します。

> 前編では、ソフトウェアのサポート窓口Aさんとユーザー企業の運用担当者Bさんが、ソフトウェアの動作について、それがバグなのか仕様なのかとやりとりをしていましたが、メーカー側であるAさんはそのソフトウェアの仕様を説明し、Bさんはその内容を受け入れました……が、一転Bさんが攻勢に出始めます。


> 失敗事例15:「修正パッチをいただけませんか?」


≫ ソフトウェアの運用担当者 B:……なるほど。5分以内に設定できないのは仕様との言い分は分かりました。それでは、弊社だけにその制限を外すパッチを提供してもらえませんか。なにか動作上不具合があっても私が責任を持ちますから。

≫ ソフトウェアのサポート窓口 A:残念ながら、当社は個別のお客さま向けのパッチを提供するサービスを行っておりません。ご要望に沿えず申し訳ございません。

≫ B:このソフトウェアのプログラミング言語はJavaですよね? 私はJavaでプログラミングできますから、この部分のソースを私に送ってくださいよ。そしたら私がパッチを作りますから。

≫ A:申し訳ありません、製品のソースコードは公開できないことになっております。

≫ B:分かりました。もともとそういう動作を期待して買ったのですが、出来ないのであれば返品を検討せざるを得ません。別途購買より交渉させていただきます。

≫ A:お待ちください。ご要望に沿えないことは大変申し訳なく存じますが、そのようなソフトウェアへの改善や、機能拡張の要求をお受けする窓口がございまして、そちらをご案内させていただきます。

≫ B:そんな窓口があるんですか。そちらに連絡すると、どれくらい待てば解決してくれるのですか。

≫ A:いえ、そちらの窓口はあくまでお客さまの要望を受け付ける窓口でして、それが実現されるかの確証はなく、それは弊社のソフトウェア開発部門で決定されます。

≫ B:伝えるだけで、それが実現されるか分からないのでは意味がありません。やはり返品を検討せざるを得ないようです。

≫ A:(困ったな。。)承知いたしました。それでは、弊社営業より早急に連絡させますので、そちらをお待ちください。


> 読んでいて「融通の利かないメーカーだなぁ」と思われたかもしれません。Bさんも要求を言い出した手前、引けない状況になってしまったのだと思われますが、私の経験上、俯瞰的な視点で冷静に話を重ねれば、今回のような、製品のごく一部の機能が原因で、本当に返品されるステージまで話を進むことはまずありません。

> 以前の記事でも触れたように、合法的に取引された製品を、顧客の一方的な都合で返品することはまず無理だと考えていいでしょう。従って、この先もし返品の方向で話が進んだとなれば、メーカー側は本来あるはずの売上が消失し、ユーザー側もプロジェクトにかけたコストや期間、そして返品交渉にかける時間を無駄に消費してしまい(重要な要求は最初に提示する、という教訓は得られるかもしれませんが)、両者にとって不幸な結果となるでしょう。

> この会話には、この他にもパッケージソフトウェアを使用する上で問題となる点がいくつもあります。


> 自社だけの“特別対応”は通らない

> まず、自社だけに「制限を外すパッチを提供してもらえないか」と個別対応を要求している点です。このソフトウェアの売上がその1社のみで構成されているような場合でもない限り、そのような要求を受けることはまずあり得ないと考えていいでしょう。

> もちろん、ユーザーの要求がメーカー側にとっても製品の魅力を高めることにつながるならば、コストや納期などの要因を踏まえて、その機能が実装されるケースもあります。ただ、それはあくまでメーカー側が自社製品としての責任で判断することであり、ユーザーに委任できる話ではありません。

> 次に「私はJavaでプログラミングできますから、この部分のソースを私に送ってくださいよ」というくだりです。一部の例外を除き、商用のパッケージソフトウェアのソースコードは非公開なのが通例で、ソフトウェアの動作からソースコードを逆解析することも、契約で禁止されているケースが多いです。

> プログラムコードやその処理方式は、開発者の知的財産(IP)であり、特許を出願しているものならば、場合によっては法律に抵触します。日本ではアニメやゲームなど、知的財産に対しての理解が深い国だと思いますが、ソフトウェアのコードもそのようなセンシティブな対象との認識が必要でしょう。

> 最後は、Aさんの「ソフトウェアへの改善や機能拡張の要求をお受けするための窓口がございまして」に対して、Bさんが「伝えるだけでは意味がない」と考えている点です。これは、実はソフトウェア開発者とユーザーにとって重要な仕組みで、ITILでも「変更管理」として位置付けられています。

> 変更管理とは、変更要求を受け付けて、その内容を審議し、実際に変更するかどうかをジャッジするプロセスです。重要なのは、要求された全ての変更が行われるわけではないという点です。さまざまな要因から、その要否や優先度を決定し、客観的で妥当性のある結論を導くことで事業活動を最適化することが目的であり、無作為に製品やサービスが変更されることを防ぎます。

> このプロセスに参加するには、まず要求を行うことがスタートとなります。それをしなければ何も始まりません。

> また、ソフトウェアの開発にこのプロセスを適用した場合、それがバグの修正と仕様変更のどちらなのかが重要になります。バグの場合、現状が“あるべき姿”でないので、審議も比較的通りやすいですが、仕様変更の場合は、その理由から審議する必要があります。

> それが「多数の顧客のうち、1人が要求している」だけでは、十分な理由とはなりません。実施の判断を下すためには、多くの顧客からその要望が出されている、市場のトレンドに合うなど、明確なビジネス上のメリットが必要です。

> さらに、仕様変更のインパクトに対する分析も慎重に行う必要があります。変更を行ったことで、別の仕様と干渉するのは望ましくありません。

> もちろん、バグ修正の場合でもインパクト分析は行われますが、元来の設計に直す作業であるため、影響範囲は局所的になりやすいです。それが仕様変更となると、機能の依存関係の洗い出しなど、より広範囲な分析が必要になるでしょう。仕様を「変更する」というのは、単に見えているものを変えればいい、という簡単な話ではないのです。


> バグか仕様か――永遠に続く戦い

> いかがでしょうか。同じ「変更」であっても、それがバグなのか仕様なのかで、結果は大きく異なるのです。これを理解していないと、実現可能性の低い事象に多大な労力を使ってしまったり、せっかくのフィードバックの機会を失うことになりかねません。

> バグか仕様か、判断が難しいケースもありますが、前編から読んでいただいた方であれば、メーカー側が「仕様です」と言うことに対して、バグだと立証するのは、その設計を知りえないユーザーでは難しいことが分かったのではないかと思います。

> それ以外は全て自分の「要求仕様」と割り切るのも近道ですが、メーカーも人ですから、合理的な説明をしているか、バグを「仕様」だと変な言い訳をしていないか(ないと信じたいです)、ユーザー側でも見極める目を持つことは必要だと思います。ソフトウェアに限った話ではありませんが……。

> さて、次回はいよいよ最後のテーマ、運用の道のりで必ず出てくる「ソフトウェアのバージョンアップ」の話です。お楽しみに。

<参考=「失敗しない「外資系」パッケージソフトとの付き合い方:「これバグでしょ?」 vs. 「それは仕様です!」(後編)」(ITmedia)>