ページ

保有Tポイントのお知らせ







この頃のTポイントはいよいよ分かり難い。誰が運営責任者なのか分かり難い。もともとは蔦屋(ツタヤ)の会員サービスでスタートしているが、間もなく運営が独立して、汎用化して、所謂ユニバーサルポイントサービスの筆頭格として多くの利用者(会員)を確保している。

提携するTポイントカードの数もいくつあるか分からないくらいだし、誰もそんなことは気にしない。

結果的に、次々と何枚ものカードを持つ羽目になる。スマホのアプリ版も出ている。

しかし、

センター機能が良く分からない。マイページを見ても情報量が不十分。タイトルのお知らせが届くがサイトに入るとカードを登録しろと要請する手順になる。だったら、お知らせなどメールしてくるなと言いたい。

管理上のミスマッチが発生している。

最近はヤフージャパンIDが紐づいて仕舞ってますます訳が分からない。

/

巷の噂では、今最も危ないポイントサービスだそうで、さっさと使ってしまうことにした。貯めこむと余計な情が入るから。

ファミマの買い物で使えることは確認できている。ファミマTカードだから当然かな。

/

タイトルのメール、ポイント残高0のお知らせだけが届くのは不愉快だし、止めようがない。サイト設計が歴史的に破綻しているのだろう。引継ぎ引継ぎを繰り返して、詳細スペックを把握しているエンジニアは一人もいないに違いない。クレームが出ても直せる人もいない。情けない状態だ。

しようがないから迷惑メールに指定しておいた。


  • 結論:Tポイントからのメールは迷惑メール。


/

メールの管理



メールの管理


  • To/Ccにアドレス記載のないものはゴミ箱フォルダーへ(1~3か月で自動削除)
  • 長期保存価値のないものは迷惑フォルダーへ(1~3か月で自動削除)

/

ネットは既にゴミの山。最も深刻なのは無尽蔵に送られてくるメール。リッチテキスト、添付ファイル、などは容量被害も甚大だ。

メールの始末を考えないと余計な整理で時間を取られてしまう。

/

フィルターの設定

先ず、自分宛のメールと確認できないもの。宛先がメールリストやBCC扱いのものは、黙って削除しよう。それらは純粋なスパムか、重要でない只の参考情報のことが多い。

大事なものは宛先Toにアドレスが入っている。最低でもCcに入れてくる。

/

次に

自分宛だけど、内容的にはメルマガ、お知らせ、リマインダー、の類、時間が経過したら意味のない情報については、全て迷惑メールの設定をする。

但し、迷惑メールの機能は、設定数に制限があるからか、機能しなくなる時がある。甚だしいものは、やはり、フィルターを設定していいだろう。保存先に、ヤフーメールの場合は迷惑メールフォルダーを選択できないようで、この場合は自分で迷惑メールフォルダーを作る考えもあるが、いずれ削除作業が発生するので、最初からゴミ箱を指定していいだろう。

/


アボカド・ピンクってそもそも何?

アボカドピンク染



アボカドはグリーン、ライトグリーン、イエローが基本ですが、中にはピンク色のものもある。なんて話は聞いたことはない。アボカドが紅葉すると葉の色は落ち着いたピンク色になる。という話も聞かない。

でも、

アボカドを食べる時に、器やクロスが ピンク色なら、素敵な色合いになりそうだ。

だから、仮にアボカド・ブルーでも似たような効果はあるだろう。好みの問題だけど。



写真を撮る時も背景を工夫すると対象の被写体も生えてくる。

碁は背中を見ながら打つものだ。



面白いと言うか本来の話は、アボカドの皮を煮るとピンクの液体が出来るらしい。そんな奇麗なものではないだろう。其の液体で衣類を等を染めることができるらしい。これは普通にアボカドピンク色らしい。食べておいしいアボカド。種を植えてグリーンを楽しむこともできる。加えてピンクの染色まで楽しめるって、アボカドは最高だね。



ブログはまあログですから時間経過に沿って延々続くもの。という訳にはいかない。人は飽きっぽいし、テーマによってはネタが尽きることもある。何かの事情でブログの時間が取れないことも。

エンドレスは人間社会にはない。

終わりを決めてブログと言えども形を作ることだね。

有限資産の中のチャレンジ。

考古学ではないけど、何かしらの資料の塊があれば、そこから何が分かるか。面白い。事実=記録をベースに分析してメッセージを拾い出す。歴史書だね。



固有名詞の扱い:

業種業務はOK。部署名もOK。企業名・担当者名はNG。A者。A担当。などで。イニシャルを回避する場合は必ずA,B,Cを使う。逆に混乱しそうな場合は、実際のイニシャルを使う。担当者も姓名のイニシャルABを使う。

日付は実時間のもの。但し、10年以上経過したものにすること。直近のものはトラブルサム。

場所名は市名までは実際のもの。町名以下は回避。

組織規模は概数。

この手の組織設定は最初か最後に整理しておいた方が間違えないで済む。

攻撃になってはいけないからメッセージは冷静にシステム課題・プロセス課題としての拾い上げに徹すること。

だらだら延々記載しないこと。

課題は川向こうだけでなく革手前にもあることを忘れないように。

それでも中には最低のケースがあるからそこは容赦しないこと。

090326

090326

リスクアセスメントそのものが殆ど出来ていない。事務局だけでやっている。これではISMSの定着は無理。

ルール(ISMSマニュアル)は一定の様式で作成されているが、事務局だけが認識していて事務局だけが実施している。組織全体では形骸化の危険がある。

資産台帳に資産価値も記載されていない。リスク値は現場は誰も認識していない。どうやって資産を守る気かわからない。

資産価値脅威脆弱性の識別区分が妥当性を欠く内容。可用性は、秒のレベルが3で、1日のレベルが1。統計的に見て妥当性を評価する活動もやっていない。

コールセンターはゾーニングとしては、一般公道レベルと最高セキュリティがドア1枚。サーバー室も施錠していない。

ゾーニングは基本的に段階的にレベルアップさせなければいけない。公道(レベル0)にいきなり金庫(レベル3)を置いてはいけない。こういう常識でも、ドアとか間仕切りが入ると忘れてしまうようだ。

コールセンターで私物の持ち込み管理をしていないのも珍しい。受け渡しも無い。バックアップサイトの位置づけもあるらしいが尚更いい加減と言う事になる。

結論:

レベルは低い。腹立たしいくらい低い。一生懸命にやっている姿・情熱も感じない。

丸ごとアウトソースして適用範囲に入れている場合。全てのルールは受け入れる必要がある。PDCAは有効でなければいけない。この組織の場合は、自主的な管理を要求しないまま適用範囲に入れているので穴が空いている状況。ISMS活動の記録が一つもないのもありえない。役割責任の文書ぐらい用意しなさい。

かなり最低レベル。

090226

-オーディット-計画
  • ページ割付をミスしたものあ送られてきたから、注意をしたのに放置。見るソフトとの相性で変な見え方になるケースも考えられない訳ではないから、とりあえず確認することを示唆したのに。10日もたって漸く気付いて修正版をお客に送るのはいいが、こちらに何故添付して教えてくれなかったかクレームしてきた。馬鹿につける薬無しだね。発信控えを見れば済むことだろうに。
  • この人の審査メモはページ数が膨大。確認したいことなど一切をプレプリントして持参だからそうなる。プロセスベースの審査は規格の基本要求だけど、これでは単なる消化器官ですね。

090210

-システム-リスクアセスメント

  • 現場でリスクアセスメントをやっていない。非情に基本的なことだが、本来は自分の問題を事務局に任せる運営になっている。
  • こういうところは弱点の報告、ひやりはっとの類は上がらない。リスクアセスメントそのものをやらないので、資産の変化、脅威脆弱性の変化が、自分たちの態度にどのように反映すべきかが分からない。
  • 詳細なリスク分析は資産価値にレベル3が合った場合。CIAのどれかがレベル3なら実施。資産価値は1~3の3段階。しかしこの場合は、該当するし算数の割合も見ないと適切かどうか分からない。下手をすると形骸化する。ミニマム20%は実施とか別の切り口も必要。
  • リスクアセスの手法はオーソドックスだが、受容レベルが20近い値で極めて高い設定になっているのも懸念。
-オーディット-計画
  • 場所、時間、アテンディーのバランスが悪い。本社の管理機能などが各サイトに分散しているので、仕組み確認と現場確認の割り振りが明確になる工夫が必要。複数の審査員で見るときは役割分担も連携も必要。全体のマネージは弱い。
  • バイオ認証におけるバイオデータの取扱の確認が出来ていない。バイオ情報の深刻さに気付いていない。

090326

-システム-携帯電話の扱い
  • セキュリティゾーンへ入るときに、写真撮影を禁じる観点から、カメラは勿論デジカメ付き携帯まで、預けることを強要するサイトが増えている。
  • ずっと同行しているから隠しカメラでもなければ写真は撮れないのにそのように杓子定規をやる。悪意の人は目立たないところに隠す訳で鼻から預けてはくれない。画しカメラを探ると成ると相当厄介だ。
  • 携帯を仕舞って出さないでくれと言うだけで不十分なのでしょうか。携帯そのものは情報の塊で、それを預かることの方が余程問題だ。ロッカーに仕舞うようにしているが、ロッカーは相当に厳重な管理を強いられる。勝手にロッカーを開けないことは保証するんですよね。

090205

-システム-
  • カスタマーサポートセンターなど顧客との問い合わせ対応は個人情報が出てくるので、良くやっている口かな。
  • 事業継続については、実質的な訓練が出来ていない。バックアップをとる意味が理解されていない。
  • 24時間体制は凄いけど人に負担が掛かっているのだから、教育にしても業務固有のリスクへの配慮などの工夫がいる。
  • リスクアセスメントはやや形骸化。脅威脆弱性を部署で拾えているか。結果の妥当性をみるために、統計情報での検証活動が無い。
  • データセンターは、委託先に変わって説明してはいけない。委託先の説明を行きだす形のセッティングが必要。
  • 共用エリアに名札をつけて設置しているのは頭かくして尻隠さずに近い。実際に他社のラックを見ても名前は全部伏せてある。
-審査員-
  • 審査計画は破綻していない。殆ど1箇所だから。部署数も少ない。
  • ホテルでクレームしてきたのは始めただ。決の穴の小さい男かも。違うところに泊まれば料金は違って当然。
  • 鼻から、チームメンバーを信用しない態度では大物にはなれない。図体はでかいのに。
  • コンサルのネガティブ情報を披露してきたのは有り難いが、スタンスが違うだろう。この男もあの馬鹿コンサルの力量を見抜けていないということだな。
  • 3年間の振り返りで、日付の指摘が多いといっていたが、この男がそればっか見ていたということ。是正のフォローと効果確認も同様だが、もし繰り返しを問題にするなら、問題の本質に迫るコメントが必要。
  • 途中段階の星取表にクレームしてきたが、網羅性の観点で、初日に目くじら立てないでよ。
  • プレチェックリストが膨大すぎる。前の審査機関のチェックリストより酷いかもしれない。本当の審査にならないだろう。だから枝葉末節の指摘ばかりになるんだ。今回こちらで見つけた単純な指摘はとっくの昔に終わっている筈のもの。馬力と熱意はあるが、かなり空回り。
-システムアドバイス-
  • 適用範囲を素直に広げなさい。
  • 特に情報システムなどの基幹インフラ部門が入らなければPDCAが回り難いので形骸化しやすい。
  • 現場でリスクアセスをやってもらう。
  • マンネリ化の懸念払拭のために審査員を変更する。
-アセスメントアドバイス-
  • もっとゆったりと本質に迫ること。
  • チェックリストはもっとラフに。星取表もこの人だけやたら細かい。
  • 内部監査の指摘件数のカウント~トレンドに本質的な意味は無いことを知るべき。((こういう発想をやるから問題ないのがいいことになってやがて自滅していくんだ。その意味ではこの審査機関の審査全体に共通するスキームだから始末が悪い))
  • 疑心暗鬼で仕事をしてはいけない。
-
  • 更新審査でも、スキームまで手を付けるお客は皆無に等しい。
  • 改善件数を競うスキームに組み替えないと駄目だ。内部監査で指摘をすると是正と効果確認と手番が増えて、嫌がる形になる。指摘が無いのが現場の本音として助かる形。これじゃ駄目だ。改善競争に変えるべきで、誰がどれだけ有効な(リスク値を下げる)を改善をしたか。こうなるとリスク値を一度上げてやらないといけない。環境変化を取り込むとリスク値は上がるから、リスクアセスも回り始める。
  • 空回りするだけのシステムを大量生産している。
  • 迎合的審査態度。

090127

-system-

  • 驚くね。こういうところが何故ISMSなんかやるんだろう。
  • 問題、課題を抽出して改善につなげること自体を否定している。三遊間は絶対拾わない。継続的改善も自分のポジションで逃げ隠れ出来なくなってから取り組む。どんな教育をしているんだろう。働いているのは保身の力学だけ。超サラリーマン世界。
  • ひそかにこっそりやる改善は改善のためでなく保身のため。自分さえ守ることが出来れば良い。少なくとも保身優先。
  • 監査とか審査とかで指摘が出たら、担当者の評価が下がる。指摘は改善スタートポイント。それを否定するのだから、救いようが無い。改善の芽を摘む活動をやっているのだから。マイナス型価値評価。悲劇だ。
  • 改善件数を競うような形にすれば、積極的に問題を拾うから、改善のスピードは早い。情報の共有も進む。
-Adv-
  • ここの助言はISMS以前だね。プラス型の評価システムの導入。停滞・よどみを嫌うことをトップから発言してもらう。管理を静的に捕らえないで動的に捕らえる癖をつけてもらう。
  • 課題抽出競争。世の中の変化、事業の変化、業務の変化を捕らえる力。
  • 課題解決競争。
  • 課題がなくなったら?。
    そういう事業は撤退すれば良い。事業ニーズが無いか事業遂行力が無いかのどちらかだからね。
-
  • 資産価値の評価で、CIAでレベルを分けるのをやめること。何故、Cは4段階で、IとAは3段階なのか。情報が出てこなくなったり、中身が摩り替わることだって、大変なことだ。個人情報漏洩に絡めての機密性への過剰反応はやめても良い頃だ。金額換算すれば同じだね。

090113

-Advisory-
  • リスクアセスメント方式の見直し。オーソドックスなやり方に戻す。

090113

-
  • リスクアセスメントも内部監査も実質的に出来ていない。
  • 工数を掛けていない。
  • 事務局だけのリスク対応計画。現場部署での取り組みは極めて希薄。
  • 分けの分からないリスクアセスメントプロセス。ツールを使って実施しているがツールの実績も無い。提供されるリスク値とインプットとの因果関係が不明確。
  • 最初のコンサルの言うとおりに進めると大変な工数になるから簡略化できるツールを導入したようだが、重要な判断ミスをしている可能性がある。
-
  • 開始会議の説明はよどみなく良く訓練されている。
  • 所見は本質的なものは少ない。殆ど無い。末節が多い。

20090113

-system-

-audit-
  • 下手な審査計画だ。オープニング会議に集めて、その後、直ぐに別のサイトに移動。オープニングだけに出るなんて意味が無いだろう。本来はトップインタビューを聞いて、トップの審査への期待を確認して各サイトに出るものだ。
  • 全体のプランの出来も悪いから、リーダーとしては不足に見える。
  • 審査員に対する基本的な教育が出来ていないようだ。こうすると、審査計画を見るだけでも、ある程度、審査員の能力が測れるようだ。

-advisory-

予約の日程

予約の日程と言ってもピンと来ないでしょう。

出張の時の予約のことです。

宿(ホテル)と足(交通機関)。先ず、宿を取ります。宿のキャンセルは自由度が高いので早くとって問題ない。早期予約料金の設定もあるから安く泊まることができる。それに、受験とかイベントとかが入ると急に宿が取れなくなることもあるので、その意味でもなるべき早期にとる。

東横イン、アパホテル、ルートイン、などのホテルチェーンを利用する人は出張先の細かい住所が不明でも、取り合えず押さえる。ホテルの会員メンバーなら尚のこと。

次に優先するのはフライト。席が直ぐに埋まる。都合の時間のフライトで、良い席で移動したい。遅くなると真ん中の窮屈な席になる。自由度が低いため、日程が確定したら、なるべく早く予約する。

予約すると3日以内に決済を要求されるので、出張スケジュールが本当に確定しているかどうかの確認は必要。1ヶ月を切ったら予約に入ること。

在来線の特急。全く読めないが満席になる懸念は少ない。最悪、自由席、立ち席でも良いでしょう。新幹線も同様。2週間を切ったら即予約が良い。即時決済だから、スケジュール確定は大事。



  • ホテル:スケジュール提示、都市確定で即手配。
  • フライト:スケジュール提示、手配了解確認の上、30日前に予約。チケットレス搭乗。領収書は機械発行のもので済ます。
  • 新幹線:スケジュール提示、手配了解確認の上、15日前に予約。駅ネットチケットは1週間前。領収書は窓口。
-

20090113

-system-

-audit-
  • やたらと細切れの審査計画。話を聞いている内に終わってしまうよ。
  • 自分だけ新幹線で仙台~大宮と素直な流れで気持ちよくお泊り審査を設定している。審査する業務領域(機能)も単純な営業支店2件。リーダーが見る領域じゃない。
  • 他人には日帰りで静岡~千葉と振り回す。前泊出来ないようにわざわざ変な開始時間に設定している。審査効率も移動効率も何もない。審査領域は特殊な業務と営業。こちらが複雑と言うか大事。

-advisory-

20081215

-system-

  • 全体のバランスが良くない。形式主義的な印象。昔のISO9000の文化に馴染み過ぎたのではないかと思う。本質を見る考えるが上手くできていない。いまだ手探り。

-audit-
  • 審査計画は酷い。まるで素人。
  • 単なる人数比で時間を決めているから製造部門はやたら意味も無く長い。
  • 所見は凡庸。

-advisory-

アボカド-コンテンツ・ガイド

◇「システム」

構築されたISMSシステム。「システム-1」(概要)は場所、規模、事業分野など一般的な内容。「システム-2」(特徴)は非常に優れている事項、非常に劣っている事項、一般から乖離している事項内容。

◇「審査」

システムを評価する審査概要。「審査-1」は審査チームの人数・経験・年齢・傾向、及び審査計画の概要。「審査-2」は審査所見の特徴。優れた所見、劣る所見、見逃した事項。

◇「助言」

「助言-1」はシステム構築・改善に向けたシステムオーナーに対する助言。「助言-2」は「審査チームに対する助言。

アボカド-コーディング・ポリシー

審査開始日-年月日(6桁)
審査日数(実出動日数。半日も1日。前泊・後泊は含めない)(1桁)
チームメンバー数(1桁)
初回登録年(2桁)

0812085407

system
  • 静岡県
  • リスクアセスメントが酷い。資産価値評価はCIAの観点から実施されているが、リスク値評価は資産価値との関連が消えてしまっている。資産価値と別に影響の大きさを出しなおしている。では最初の資産価値は何だったのか疑問。リスク値に持って来る時はCIAの観点が消えてしまう。
  • リスクアセスメントでゼロ(0)が使われている。ゼロはアナログ情報を論理値のゼロに変換してしまうので取扱が難しい。問題の所在を明確にするために使っているとの説明は説得性がない。刻みを変えれば済むこと。
  • 資産価値をゼロにすると無いのか有るのに低いのかすら分からなくなる。脅威をゼロにすると無いのか有るのに低いのかすら分からなくなる。脆弱性をゼロにする絶対神が入るのか人間としては相当頑張っているに過ぎない状態なのか分からなくなる。完璧な人間は存在しないから神とのギャップは大きいし、実際の着地は脆弱性しかないのだから、ゼロが存在したら話は終わってしまう。
audit
  • 酷い計画。最も長いサイト間移動に対して審査外の取扱にして、他は大した距離移動がなくても審査内の扱いにしている。不公平もいい所だ。
  • リスク対応計画に基づかない施策展開。リスクアセスメントとの関連付けも当然無い。降って涌いたような施策が蔓延ししたら適切な成長を妨げることになりかねない。好ましくないのは自明。それでも所見とすることに否定的な審査員がいる。不思議なことだ。
Advisory

0901133205

audit
  • 酷い計画。リーダーは地方遊説でなく本社拠点をやれよ。秘匿性の高いサイトで行き先が分からなければ審査できないのだからアクセスガイドくらい出して欲しいね。
  • 酷い計画だね。静岡へ行って、わざわざ朝一番の移動を強要しておいて、次は千葉に追いやる。時間の無駄だろう。静岡県内か神奈川県内か方向ぐらい合わせろよ。帰りがまた大変だし。このやろう何も考えていないな。このくそたわけが。
system
  • n/a
advisory

0812155208

audit
  • ひどい審査計画だ。審査員を西や東に振り回してどうするつもりだ。右往左往というのだ。分けの分からない理屈を並べて、人数が多いところでないと全体の把握が出来ないと決めて掛かっている。時間配分が上手く取れないと決めて掛かっている。本末転倒だ。この男は馬鹿だね。
  • 京都まで行って、その後、たった一時間の審査のために、名古屋に戻る。その後、また関西へ向かうのだから、それも只の半日仕事でだ。半日日当で一日中振り回すなんてどういう了見だ。この野郎め。

人気の投稿30

人気の投稿365

人気の投稿