第557話：様々なAPIと通信する全自動請求フロー

業務：大量の月末請求

月末のカード請求業務が、ヌケモレなく実施されるようになった！

それぞれのお客様への「請求金額」について、、、いつ誰が入力し、いつ誰が承認したのか、全てがリアルタイムに捕捉できるようになった。しかも、クレジット会社 API （Stripe API）にアクセスしてくれる「自動工程」のおかげで、ワークフローシステムからダイレクトにカード課金される。つまり、経理システムへの「二重入力」といった二度手間もなくなった。

• 第554話：Web受付、だけどカード情報は非保持(1)
• 第555話：Web受付、だけどカード情報は非保持(2)
• 第556話：月末請求フローに Stripe API

課題：人間依存の低減

しかし、、、この業務プロセス（第556話）は、いまだ「人間のデータ入力」に依存している。つまり、肝心の「課金額」の入力については人間（担当営業）が担当している。

たしかに、「お客様情報」は自動でセットされているし、「カード請求コード」（Stripe CustomerID）だって予めセットされている。更には「請求作業の一覧」もヌケモレなく引き受け待ちリストに表示されているので、複数人で協調して請求作業を行うこともカンタンになっている。つまり「入力の省力化」については、かなり高いレベルで実現できているとは思うのだが。。。

もっとも「課金額」（請求額）の情報は、ワークフローシステムから見て「外部システム」にあたる「売上管理システム」にある。なんとかして売上集計を自動取得させることはできないものか？　（「APIエコノミー」が叫ばれる今日、業務プロセス改善の行きつく先は「無人化」だと思う。。。）

[クレジットカード課金プロセス-再帰呼出＆全自動]

第556話：月末請求フローに Stripe API

業務：毎月のカード課金

月末の請求業務が、大幅に省力化された！

新しいワークフローアプリでは、担当営業が登録した「今月の請求金額」が部長承認されれば、そのまま自動的に「クレジットカード課金」が行われる。経理サイドが「請求書の印刷／押印／郵送」といった作業を行う必要はナイ。当然ながら「銀行入金確認」といった作業もイラナイ。Stripe 万歳！　API エコノミー万歳！　Questetra 万歳！

• 第554話：Web受付、だけどカード情報は非保持(1)
• 第555話：Web受付、だけどカード情報は非保持(2)

ちなみに、お客様にも好評だ。

「請求書の承認」や「振込の手続」といった実作業がなくなった事（！）もさることながら、費用明細が「通知メール」で確認できるのがイイ（！！）、らしい。（ペーパレス）

（「銀行API」も早くオープン化されればイイのに…）

課題：誰に請求してないか？

ただ、、、現状では「全てのお客様に請求できたか？」が分かりにくい。

たしかに『1r.課金額の入力』からワークフローを手動開始（再利用開始）するだけだ。しかし、その開始を「手動」に依存すると、たとえば「前月請求したお客様全員にヌケモレなく請求する」が実現しづらいのだ。

請求件数が増えれば、いつの日か「請求し忘れ」が発生するだろう。。。（ハテサテ）

[クレジットカード課金プロセス-再帰呼び出し]

第555話：Web受付、だけどカード情報は非保持(2)

業務：登録カードへの課金

「クレジットカード登録」の仕組みはできた！ （前回記事参照）

『カード番号』や『CVC』といったカード情報は Stripe 社（決済代行会社）に預けられ、ワークフロー側にはその「預かり番号」としての『Stripe Token』(tok_{24文字})だけが流れる仕組みだ。つまり、日本政府が「2018年3月までにクレジットカード情報の非保持化を！」と言っている要件についても満たすことができたと言える。（非保持化＝カード情報保護のための第一の対策）

コレで「自社システムからカード情報が漏洩するリスク」はゼロになったと言ってもイイ！　安心して Web 登録してもらえる！！

※ Stripe Token は一度の処理にしか使えない仕様（single-use token）となっており、この例では『Stripe Token』から『Stripe CustomerID』(cus_{14文字})への自動変換も同時に行われています。（自動工程「Token to Cus_ID」）

課題：課金オペレーションにおける手作業の排除

しかし、良く考えてみれば、、、実現したのは「カード情報の保護」だけだ。

たとえば『課金金額』を間違えたり、たとえば『課金相手』を間違えたり、、、そんな「課金オペレーション」のミスリスクについては、ゼロになっていない。たとえば「Ｘさんのメールアドレス」に「Ｙさんの名前宛」で課金予告を送ってしまったとか、、、、考えるだけで寒すぎる。「課金業務フロー」における

• お客様の名前
• お客様のメールアドレス
• Token or CustomerID

あたりのデータは、自動的にあらかじめ入力されているようにしたい。そうなっているだけでミス率はゼロに近づくハズだ。下流工程でチェックを担当する「頼りない上司」の負担も、少しは軽減されるだろう。

[クレジットカード課金プロセス]

第554話：Web受付、だけどカード情報は非保持(1)

業務：決済カード登録の受付

「クレジットカード決済」を推進したい…。

サービス利用実績にあわせて自動的に「カード課金」できれば、非常にスムーズな決済が可能となる。もし「明細発行」も電子化できれば、売上回収コストは大幅に低減できるだろう。

電気会社・ガス会社・ケータイ会社のように「カード課金できる体制」を整えたい。

課題：カード情報の漏洩リスク

しかし、セキュリティ要件が厳しくなった今日、「クレジットカード番号を保有すること」は大きなリスクらしい。

ウチは、電力会社でもなければ、Google Facebook といった大会社でもない。つまり「PCI DSS」が言っているような要件は維持できそうにない。カード会社（アクワイアラー）も言っているが「持たないこと（非保持）が大切」なのだろう。

よし、、、日本政府が「2018年3月までに非保持化を目指す」と言う書類にあるように、PAN PIN CVC といったカード情報等は「決済代行業者」に預けようと思う・・・。（どうやって？？）

• PAN：Primary Account Number （カード番号）
• PIN：Personal Identification Number （暗証番号）
• CVC: Card Verification Code/Value （3桁数字。正確にはCVC2。CIDとも）

※参考： クレジット・カード業界データ・セキュリティ標準（PCI DSS Ver.3.2 2016-04）
※参考：EU の法改正（決済サービス指令 2015年）、日本の法改正（改正割賦販売法 2016年）

[クレジットカード情報の受付プロセス]

第553話：脆弱性緊急メールに組織的な対応

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

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

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


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

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

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

課題：属人的な対応

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

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

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

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

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

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

[脆弱性対応プロセス]

第552話：働き方改革は「アイデア募集」が大事

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

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

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

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


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

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

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

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

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


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

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

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

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

第551話：週報スプレッドシートへのコメント

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

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

全店長が一つのファイル（例：『売上報告2017-08-27to2017-09-02』）を同時編集するので、

• 各店長は他店を意識するようになった
• 店長同士で誤入力を指摘し合うようになった
• 本部での集計作業は（Spreadsheet任せなので）不要になった
• 役員達もファイルを閲覧し、各店舗の動向を能動的に確認するようになった

などのカイゼンが図られている。つまり、各店長のコメントを含む「売上データ」が、社内でイキイキと活用されるようになった。（これまでは「売上データ」が死んでいた？）

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

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

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

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

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