2005年07月29日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 音楽関連7団体がiPodなどへの私的録音補償金適用を要望[http://www.watch.impress.co.jp/av/docs/20050728/shiteki.htm][著作権]次の記事 >> このエントリーをはてなブックマークに追加

どこからお金を取るかの問題なので、
音楽ライブラリを持ち出すことをコンセプトに開発されていることは明らか
に補償金を求めるのは理解できるのだけども、
当初はデジタルオーディオプレーヤーのみならず、PCやデータ用CD-R/RWなどについても政令指定を求めていく方針だった
というのは無茶な話。逆にこういう発言をするから、何を言っても無茶な要求をしている様に評価されるのではないか。
私的録音録画補償金制度を前提にしながら、
2 私的使用を目的として、デジタル方式の録音又は録画の機能を有する機器(放送の業務のための特別の性能その他の私的使用に通常供されない特別の性能を有するもの及び 録音機能付きの電話機その他の本来の機能に附属する機能として録音又は録画の機能を有するものを除く。)であつて政令で定めるものにより、当該機器によるデジタル方式の録音又は録画の用に供される記録媒体であつて政令で定めるものに録音又は録画を行う者は、相当な額の補償金を著作権者に支払わなければならない。
著作権法を無視する姿勢には疑問を感じる。
それとも、彼らには、パソコンはCDをコピーする機械にしか見えないのだろうか。

■ 関連記事

■2 続・Linuxサーバの3分の2はウイルス未対策、ソフォスが「考えて」[http://www.nantoka.com/~kei/diary/?200507c&to=200507271#T200507271][セキュリティ]<< 前の記事 このエントリーをはてなブックマークに追加

コメント[http://www.nantoka.com/~kei/diary/board.cgi?act=read&msgid=332] を頂いた。
では本来やるべきレイヤやポイントとはどこを指すのでしょうか?
難しい問題だ。きっと、「本来はやらなくて良いこと」だからだと思う。どうやっても、きれいな解決にならないのですよ。ウイルスに感染する作りになっているのがおかしい。
現実にはそれこそ本来のところで解決できないから、変なところで対策している状況があって、いずれもうまい解決にならないとそういった状況にあるでしょう。

この記事に頂いたコメント

Re: 続・Linuxサーバの3分の2はウイルス未対策、ソフォスが「考えて」 by i    2005/07/29 22:51
だいたい「未対策」という言葉がずるい、だって感染してる台数なんて僅かだから...
Re: 続・Linuxサーバの3分の2はウイルス未対策、ソフォスが「考えて」 by sashenka    2005/08/01 09:54
自社製品を売るための無責任なアドバイスに過ぎないですね。ソフォスが考えるほうが先...
Re: 続・Linuxサーバの3分の2はウイルス未対策、ソフォスが「考えて」 by てんて    2005/08/04 03:33
拙い質問にお答え頂きありがとうございます。 とても参考になりました。

■ 関連記事

詳細はこの日の詳細から

2003年07月29日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1ぐる[ぐる]次の記事 >> このエントリーをはてなブックマークに追加

サービス残業:“隠し”が悪質化 パソコン記録を改ざん[http://www.mainichi.co.jp/news/selection/20030728k0000e040057000c.html]:

オフィスの電気を消し、電気スタンドや懐中電灯の明かりでパソコンの仕事をさせる例もあるという。
平成の世に女工哀史を見るようだ。 パワハラによる首切りといい、あまりにも社会が殺伐としている様に思う。 革命前夜?

■ 関連記事

■2 トラコスにユーザーサポートを外注している企業は珍しくない。[http://www.otsune.com/diary/2003/07/28.html#200307281][電子自治体]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

どうして電子自治体という括りで出してきたかというと、自治体の窓口業務をコールセンターに外注しようという流れがあって、これは電子自治体と無関係ではないからです。

窓口業務を電子化(Webで受け付け)すると、サポート窓口が必要になることは想像に難くない。行政としては電子化したからにはどんどん使って欲しいわけだから、サポートせざるを得ないのです。

ここで、サポートは今まで紙ベースの申請をやっていた時よりも低コストにならなきゃいけないという課題があります。
時間単価の高い公務員さんがマニュアルを読めば分かる様なサポート業務をやっていることは許されないのです。
そうすると、マニュアルを読めば分かるようなサポート業務はサポートセンターにまとめて外注すれば、低コスト化できるし、今よりも愛想の良い対応が期待できるかも知れない。
また、何しろ窓口業務は大変なので、一部の自治体では窓口で住民と対応するのは、 ストレスが溜まると言うので、窓口手当が支給されていたと言う話もあるらしい:-P
窓口業務のアウトソースによって:

  • 行政の低コスト化が図れる
  • 新たな雇用を発生させる
  • 過酷な窓口応対業務から開放される
  • サービス事業者のノウハウによる住民満足度向上

というメリットがあるのだけれども、このシステムを動かしていくためには、 実は役所内部のシステムの改善が大前提として必要になります。

掛けた電話がどうしてたらいまわしされてしまうのかというと、 様々な問合せや相談に対する回答が属人的な知識として蓄積されてしまっているからで、これを共有知識にしていく必要があります。
また、回答に対して窓口が責任を持てるシステムを構築していく必要があります。 「それは○○[県|市|町|村]の回答として保証できますか」「私どもは委託業者なので責任は持てません」 では困るわけです。
「社員じゃないと話しにならん!」というメンドくさいクレーム[http://d.hatena.ne.jp/junx/20030729#p1] に対応できる体制を作る必要があります。「はい。[県|市|町|村]の回答としてご理解ください」と言える体制が作れないといけません。

これらのことを実現するのが本当の課題で、ハードやソフトと言うシステムはほんの枝葉に過ぎないと思っています。

顧客サポートのアウトソースによって顧客満足度を上げる:

ということはきっと不可能ではないと考えます。 同じ費用の使い方で、アウトソースの方が効率的になって、 いつ掛けても繋がらないという状況から開放された例もあるかも知れません。
製品にフィードバックという考え方も、最近の CRM製品[http://crm.fujitsu.com/] には取り入れられています。
コールセンターで受けた内容と過去の対応事例をナレッジとして蓄積して、 データマイニングに活用する事例も珍しくありません。

サポートセンターをCRM最前線としてとらえることができるかどうか:

が重要であろうと思います。 サポート業務を費用を食うだけとネガティブに考えていると、 貴重な情報を捨ててしまうことに気付くかどうかで、 社内でやるかアウトソースするかは大きい違いではないと考えます。
ただ、アウトソースする場合に気を付けないといけないだろうと思う点として、 SLA *1 として エスカレーション *2 の回数を「○○%以下にすること」という条件を入れるのは、かえって危険かも知れないという点が挙げられます。
エスカレーションを減らすためには、各オペレーターのレベルを総体的に上げる必要があるため、オペレーターの教育レベルをエスカレーションの割合によって推測することが可能です。
しかしながら、エスカレーションを減らそうとするあまり、その場逃れの様ないい加減な回答をしてしまったり、本質的な問題を些細な問題に封じ込めてしまう *3 といった問題を誘引する恐れがあります。
結局、窓口業務はアウトソースしても、そこから何を見出してどう改善していくかを外注することはできず、それこそが自分たちが考えなければならないだ、ということを忘れてはならないという話だと思います。
*1: 【サービスレベルアグリメント】サービス提供において、その品質に具体的な目標を定めて明文化したもの。明記した品質を実現できなかった時は利用金額を割り引くといった契約が主流になっている。本来は品質レベルの合意を目的としたものだが「部長!ライバル社が99.8%の可用性を提案しています!」「ウチは99.9%を提案だ!止まったら、ちょこっと罰金払えば良いんだ。」という実体のない信頼性向上提案がなされているかも知れないことに注意を払うべきだと思われる。
*2: 【エスカレーション】今夜はハードコア。オペレータが受けた電話にうまく応対できなかったような場合に、専門性の高い担当者や管理者に通話と一緒に対応状況や顧客情報を転送すること。
*3: 「リセットしてみてください。動きましたか。」「動きました。」「では解決ですね。ありがとうございました。」

■ 関連記事

■3typoによるバグ<< 前の記事 このエントリーをはてなブックマークに追加

ループ変数のiとjを間違うミスをこのところ何度かやらかしている気がする。 目が節穴になったか。
自分を包むループで使っていない変数を使っていたら警告する方法がなかろうか。

■ 関連記事

詳細はこの日の詳細から

2002年07月29日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 佐賀県大和町役場[http://www.saganet.ne.jp/yamato/main/main.html][CLIP]次の記事 >> このエントリーをはてなブックマークに追加

■ 関連記事

■2 黒板に赤いチョークを使わないようにしましょう運動[http://www.ne.jp/asahi/shinsei/saitama/shikijaku/doc/kokuban.htm]<< 前の記事 | 次の記事 >> このエントリーをはてなブックマークに追加

色覚異常関係なく見難いらしい。
色覚異常対応赤色チョーク[http://www.tenjin-chalk.co.jp/] という製品があって、写真で見る限りでは、関係なく見やすいみたい。
蛍光チョーク[http://www.hagoromo-bungu.co.jp/] もあって、こちらは各色あります。

■ 関連記事

■3Windows Media エンコーダーによるビデオ配信<< 前の記事 このエントリーをはてなブックマークに追加

実験中[http://210.164.52.9:8080/] Windows Media プレーヤーでどうぞ。
ビデオ素材なんだけども無限ループしてくれるかしらん。

■ 関連記事

詳細はこの日の詳細から

2001年07月29日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・デジカメ露出計[http://www.nantoka.com/~kei/diary/?200107c&to=200107261&ref=here#T200107261][写真] このエントリーをはてなブックマークに追加

マニュアルは読むべきですね。 撮影後に、INFOキーを押すと、撮影データがスーパーインポーズで表示されます。
撮影フィルムと同じ(でなくても良いけど)ISO感度をマニュアル設定しておけば、 デジカメで段階露出しておいて、狙った感じの露出データで銀塩の方を撮ることができます。

■ 関連記事

詳細はこの日の詳細から

1999年07月29日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1Web日記その後とAmanda次の記事 >> このエントリーをはてなブックマークに追加

早速、 「日記界の偉い人」[http://www.inseki.gr.jp/~kenji/diary/] (?)に反応されて嬉しかったりします。こういうのがWeb日記の魅力ですね。「ウェブ日記(狭義)」の概念は納得です。「言いたかったことはまさにそれなんだ」ってことをうまく言い表した表現に出会えて嬉しかった。
他にも、 「日記鯖」[http://www.fastwave.gr.jp/diarysrv/] というものの存在も教えていただきました。ありがとうございます。
実は、本気度数%で事業計画を考えてみたのですが、さすがに商売としては難しそうです。趣味と実益を兼ねた・・・位ならできるかも。
管理するマシンが増えてきたのでバックアップが辛くなってきました。これまでは、お手製のスクリプトを夜中に走らせて、
  • テープに番号を書きこんでおいて、妥当なテープかどうか判定する。
  • 上書きして良いと判断したら、そのテープにダンプすべき内容を順次ダンプする。
  • 巻き戻して取出しておく。
ということをやっていたのです。
これはそれなりに便利なところがあって、要は'ssh host dump 0fa -'しているだけですし、あるテープに何がダンプされるかも自分で決めている訳ですから間違いがありません。
しかしながら弱点は、どのテープに何をdumpするかを決めるのが大変だというところにあります。
全てのディスクがレベル0でdump(全内容をバックアップ)できるなら苦労はないのですが、「Tape1には、HostAのフルdumpと、HostBの差分と、HostCの差分」「Tape2には、HostAの差分と、HostBのフルと、HostCの差分」・・・
ということをテープとディスク、さらに差分の予想分量をにらみながら表計算ソフトを駆使して作らないといけなかったのです。
スケジュールを決めるのにはいくつかルールがあって、例えば「1本のテープに毎回上書き」ということをしてはいけなくて、少なくとも2本以上のテープにフルバックアップが取られていなければなりません。
バックアップを取っている時にディスククラッシュが起きて、テープもディスクも駄目になるということが考えられるからで、 実際に経験もしています[http://www.nanet.co.jp/~kei/diary/199906.html#19990618]
その他もろもろのルールを盛り込んで、何日か分のテープローテーションを作り上げるわけですが、新たなマシンが増える度に過去のバックアップと整合性を保ちながらルールを作り変えないといけないのです。
で、今回。以前から気になっていた Amanda[http://www.cs.umd.edu/projects/amanda/index.html] を導入しました。
これを使うと、例えばテープは1日1本、周期は7日間と決めたら、スケジューリングを行いつつバックアップを行ってくれます。
「重要度」を設定して、優先的にバックアップを取るべきパーティションを指定することもできますし、バックアップすべきパーティションを途中で増やすこともできます。
今夜のバックアップの予定を知ることもできますし、「このパーティションは今夜フルダンプしてね」って頼むこともできます。もちろん結果はメールで教えてくれます。
極めつけはホールディングディスクの存在で、ある程度大きな容量の空きパーティションを与えておくと、各クライアントからのdumpデータを並列に受け取って一時的にディスクに格納しつつ順次テープに書き出して、バックアップを高速化してくれます。
さらに、必要なテープが入っていなくてもホールディングディスクを活用して可能な限りのバックアップを残します。これで、予定外の外泊もOKです。
こうやって良いことばかりのAmandaちゃんですが、便利な割には日本語の情報源は少ないようです。要望が多かったら別立てで「Amandaの導入と設定」っていうページを作ろうかと思っています。もし余所にあったら教えてください。

■ 関連記事

■2DDSドライブとホールディングディスク<< 前の記事 このエントリーをはてなブックマークに追加

バックアップ体制
バックアップテープは撮影用に配置しました。良い子はテープドライブの近くにテープを置きっぱなしにしてはいけません。

■ 関連記事

詳細はこの日の詳細から

以上、16 日分です。

指定日の日記を表示

前月 2021年09月 翌月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

最近の日記

2019年04月01日

新元号「令和」について

2019年03月23日

DXアンテナ ワイヤレスチューナー メディアコンセント DMC10F1

2019年02月17日

#例のグラボを活用する

2019年01月03日

シリーズ5・myHomeAlexaで自分のCDをかける

2018年12月25日

シリーズ4・英語の楽曲・アルバム・アーティスト名をカタカナに直す

2018年12月23日

シリーズ3: Echo Dotがやってきた

2018年12月19日

続・Echo Dotがやってきた

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

予定

    ToDo

      link

      keikuma on Twitter

      keikuma Name:前田勝之
      Location:長崎市
      Web:http://www.nantok...
      Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

      サイト内検索

      Google AdSense

      Powered by hns-2.19.9, HyperNikkiSystem Project