業務:脆弱性対応プロセス

「弱点のないソフトウェアはない」、、、らしい(涙)

つまり、無数のソフトウェアが組み込まれているコンピュータや通信機器は「弱点だらけ」なワケだ。それにもかかわらず、会社には沢山のコンピュータや通信機器がある。社員が使うパソコンもあれば、会社ホームページのためのサーバコンピュータもある。売上や給与を管理する業務システムだってある。。。


情シス部による「脆弱性(ぜいじゃくせい)対応」とは、カンタンに言えば「ソフトウェアの補修作業」だ。

具体的に言えば、情シス部は日頃から「IT情報サイト」や「Google Alert メール」で脆弱性情報を収集し、それが会社のコンピュータで使われているソフトウェアに関する情報であれば、「パッチの適用」や「バージョンアップ」といった作業を行うのだ。最近は「自動パッチ」や「自動更新」が行われるソフトも多くなっているとは言え、それでも「手動対応しなければならない事案」は少なくない。

なお、年に1・2度、日ごろの補修作業がキチンと行われているかのチェックをかね、専門業者によるセキュリティテスト(「脆弱性検査」という)が行われる。

課題:属人的な対応

ただ、、、今日では、凄まじい数の「攻撃方法」が毎日毎日発見されている。

古いソフトウェアに関する「攻撃方法」も毎日のように報告される。日々の補修によって「弱点」は克服されていっているハズなのだが、攻撃アイデアや攻撃力も日々向上しているのだろう。永遠に無くなりそうにない。たとえば CVE 公表される「脆弱性」は年間1万件以上にものぼる。(CVE:Common Vulnerabilities and Exposures / 脆弱性情報データベース)

もはや、情シス部が全てに目を通せる量ではない。ベテラン社員がその「嗅覚?」と「属人的な情報ネットワーク?」によって機転を利かせて対応しているのが現実だ。

うーむ、、、もう少し組織的に対処できないモノだろうか?

もっと言えば、「緊急を要する脆弱性」について誰がどのような判断をしたのか・しているのか、についてキチンと記録・共有したいものだ。たとえば「ShellShock」や「Heartbleed」といった世間を騒がせた脆弱性に、いつ誰がどのような対応をしたのか、振り返りたいと思うのだが。。。 (OpenSSL, GNU bash)

「ゼイジャクセイ、対策しろと、言われても…」(情シス川柳)

[脆弱性対応プロセス]


業務:カイゼンを社内募集

日本政府は本気で『働き方改革』をさせたいようだ。

たしかにウチの社内にも「誰も見ない書類の作成」や「非効率なヤリトリ」がある。「◇◇業務に〇〇クラウドの導入」とか「IoT活用」とか、、、具体的な「改善アイデア」を、もっと積極的に吸い上げる方法を考えたい。たとえば「中途社員」や「派遣社員さん」が給湯室や飲み会の席でグチってるだけ…なんて、ほんとモッタイナイ。

とは言え、、、社長が「業務プロセスを改善して生産性を高めよう!」と朝礼で叫んだくらいでは、具体的な「改善提案」は上がってこないだろうな。。。


そうだ。まずは、いわゆる「目安箱」のイメージで、『内部監査室』に「アイデア投稿」を受け付けてもらおう。

そして良いアイデアについて「現場ヒアリング工程」や「社長報告工程」に進める、、、そんなワークフローを運用してもらうのだ。(業務改善アイデア受付プロセス)

課題:社内なら誰でも投稿できるフォーム

しかし、ワークフロー基盤への「ログインID」は、全員が持っている訳ではない。

もしアイデア投稿に「ログインID」が必須なら、派遣社員さんやアルバイトさんが投稿できなくなる。(現場の非効率は、きっとアルバイトさんや派遣社員さんに押し付けられてるんだろうに。。。)


ん?、よく考えれば、ある程度の「匿名性」も担保したい。

たとえば「部長の不正リスクを下げる改善アイデア」といった大胆なアイデア投稿も推奨したいものだ。

う~む、「インターネットに完全オープンなWebフォーム」でアンケート募集する、というのも一手なのだろうが、やはりチョット気持ち悪い。。。(URLがサラされたり。。。ゼンゼン関係ない人が提案してきたり。。。)

[業務改善アイデア受付プロセス]



業務:週次売上報告へのフィードバック

「一週間分の売上」が Google Sheets に書き込まれるようになった。(参照:第550話

全店長が一つのファイル(例:『売上報告2017-08-27to2017-09-02』)を同時編集するので、
  • 各店長は他店を意識するようになった
  • 店長同士で誤入力を指摘し合うようになった
  • 本部での集計作業は(Spreadsheet任せなので)不要になった
  • 役員達もファイルを閲覧し、各店舗の動向を能動的に確認するようになった
などのカイゼンが図られている。つまり、各店長のコメントを含む「売上データ」が、社内でイキイキと活用されるようになった。(これまでは「売上データ」が死んでいた?)

課題:管理職側のコメントがない

しかし、本部マネージャから全店長に「フィードバック」があっても良いのではないだろうか?

セッカク全店長が頑張って報告してくれているのに、本部のマネージャ達から何も感想がないのは寂しい。「目標達成を頼む」の一言でもイイ。マネージャの笑顔を待ちわびる店長達に伝えてやってくれ。。。

そうすれば「実績データについて本部のマネージャ達がどう考えているか/どんな助言をしているのか」を役員達が知ることもできる。

[週次売上報告プロセス-フィードバック]

業務:週次売上報告

各店長には「一週間分の売上」を週次報告してもらっている。

確かに、メールやワークフローを使い、
  1. 一人一人の『店長』が報告し、
  2. 本部の『マネージャ』が確認する
というシンプルな「売上報告プロセス」を回すのも悪くない。しかし各店長は『本部マネージャの顔色』だけを見てシゴトしているような気がする。


たとえば、もっと「他店の動向データに触れる機会」を作っても良いのではなかろうか?

もし『Google Spreadsheets』であれば、全店長が同じドキュメントを編集できる(※50人まで)ワケだし…。 副産物的な話として、『本部マネージャ』の「集計する」という工程が省力化されるハズだ。「入力ミス」についても、他店とデータ比較されることで店長自身が気づくかもしれない。あるいは店長同士で「入力ミス」を指摘し合うかもしれない! (更には店舗間のコミュニケーションも活発になり、生産性向上に…悶々)

課題:新しい SpreadSheet の準備がメンドウ

しかし、そうなると誰かが「報告用の Spreadsheets」を毎週準備する必要がある。

本部の『マネージャ』達には無理だ…。彼らは他人には厳しく、自分にはアマイ。たとえば「経費精算」など、今まで締切日が守られたタメシがない…。う~む「毎週キッチリと、新しいファイルを準備して全店長にアナウンスする」という第一工程がネックだなぁ。

[週次売上報告プロセス]

人事情報の発表方法

「人事異動の情報(配置変更や地位変更)を社内に公表する」という業務はフクザツです。

昇格・降格・採用・退職・休職・部署異動・関係会社出向…と、さまざまなパターンがあり、また個別の事情もそれぞれに異なります。

人事担当者の気持ちとしては、たとえば「信任の厚いベテラン社員が晴れて定年退職される」というケースなら何か月も前から周知しておきたくなるかも知れません。しかし一方で「競合他社に転職する」というケースなら秘密にしておきたいと思うかも知れません。また「家族介護のために休職する」といったケースでも、同僚や関係者に対して(守秘義務違反に配慮し)積極的に事前連絡しようとする人もいれば、黙っていたいと考える人もいるでしょう。

基本的には『既定の解禁ルール』にのっとって、粛々と「人事部内秘の情報」を「社内公知の情報」に切り替えるべきなのでしょう。(人事通達)

業務上の課題

公表方法として「社内掲示」という手法がとられている会社は少なくありません。

しかし、紙に印刷して「掲示板」や「壁」に張り出すという手法では、外出が多い人、長期休暇中の人、あるいはリモートワーカーにとっては見る機会が非常に少ないものになってしまいます。他方、人事部門としても「決められたタイミングで掲示作業を行う」や「決められたタイミングで掲示を終了させる」といった業務は、意外と大きな負担となります。

また「朝礼での口頭発表」という手法がとられている会社もあります。

しかし、これもまた長期休暇中の人やリモートワーカーは、朝礼出席者と同じだけの情報量を得ることは難しいと言わざるを得ません。さらに、口頭であるが故に「異動の日付」や「異動部署」などが正確に伝わらないリスクもあります。

[人事異動情報の公表]

アナリティクスいわく「○×工務店さんが困ってマス!?」

前々回記事前回記事では、「先週のWebアクセス動向」が社内通知される(ほぼ無人の)ワークフローを紹介しました。

この業務プロセスが運用されれば、社員は毎週月曜日の朝、「Google Analytics Reporting API」を通じて得られた最新情報について、メールで確認できるようになります。その結果、日々の「サポート業務」や「セールス業務」は、より効率良いものになるでしょう。

ただ、もう少し欲を言えば、「Analytics に無い情報」も併記しておいてもらいたいものです。つまり、
  • 先週火曜日、プレスリリースを配信した
  • 先週木曜日、ユーザ向けセミナーを実施した(○×工務店さんも居た!)
もしこういった Analytics に無い情報も併記されていれば、「流入の多いリンク元」や「特定の顧客が調べているページ」といった動向情報について、もっと深い理解・洞察が可能となるかも知れません。

カレンダー情報も API 取得

以下の業務プロセス定義は、社内カレンダー『広報予定およおび出展予定』(Google Calendar)に書き込まれているイベント(先週分)が、通知メールの文頭に付加される仕組みです。

これにより、通知メールを受ける社員達は、「Webアクセスに影響を及ぼしたかもしれない関連情報」についても、同時に確認することが可能となります。

[自社サイト運用状況報告プロセス3]

人気ページのランキング

前回記事では、『Google Analytics Reporting API』との自動通信によって「週次レポート」が自動的に生成される方法を紹介しました。

ポイントは、
  • ディメンジョン: ga:hostname, ga:pagePath, ga:pageTitle
  • メトリックス(指標): ga:pageviews, ga:sessions
というルールで集計データを自動取得する自動工程(サービス工程Addon)です。

この工程では「沢山アクセスを得たWebページのリスト」が複数行テキストとしてまとめられます。もし「フィルタ」に『ga:pagePath=~/blog/』の様な設定をすれば「blog フォルダ以下のWebページ」を対象としたランキングも自動的に取得することが可能です。

これらの文章が挿入された通知メールは、マーケティング・チームにとって非常に有用な情報となるでしょう。

他にも数万パターンの集計方法

しかし Google Analytics のデータは、もっと他の角度からも集計したい所です。

前回例では、上述の「3つのディメンジョン」と「2つのメトリックス」でランキング集計されましたが、Google Analytics には他にも約260のディメンジョンと約230のメトリックスが存在しています。つまり、組み合わせを変えることによって、多種多様な集計が可能となります。

たとえば、サイトコンテンツの視点(『行動(BEHAVIOR)』)だけでなく、『ユーザー(AUDIENCE)』や『集客(ACQUISITION)』の視点で集計すれば、「どんな人がアクセスしているのか?」や「どんなサイトから誘導されてきたのか?」といった情報も抽出できるハズです。

参考: ディメンジョン名とメトリックス名

[自社サイト運用状況報告プロセス2]