devdevdevReports

dev系開発開発者の開発日記

【日経コンピュータ】電子契約サービスだけじゃない!~請求・支払いのデジタル化と成功のポイント~

電子契約サービスだけじゃない!~請求・支払いのデジタル化と成功のポイント~

日経コンピュータの特集が挑むに「電子契約サービスだけじゃない!~請求・支払いのデジタル化と成功のポイント~」が取り上げられましたので、紹介します。

ハンコだけじゃないテレワークの阻害要因

  • デジタル化が進まない請求書、納品書、検収書への押印、郵送業務
  • 契約時のハンコをなくすだけではテレワークの実現は難しい
  • 見積依頼、回答、請求、支払いなど契約前後もデジタル化が必要

大成建設の事例

  • 「SUPER TRIO」を導入
  • 下請けやグループ企業との取引で利用

2019年の実績

  • 全3万3000件のうち、93%で利用
  • 57%で契約書までをデジタル化

    コロナ禍での課題

  • 取引先の経理部門、法務部門の出社をどう減らすか
  • 大口の取引先だけでなく、小口の取引先企業へも展開

サントリーHDの事例

2020年7月に契約関連の新業務システムを稼働

  • 取引先(卸売業者、小売店、飲食店)との契約から請求、支払いまでをデジタル化し、システムで完結
  • 2022年までに国内のグループ企業へ展開

期待する効果

  • 年間300万枚のかみをさくげん
  • 収入印紙代、印刷代郵送料など年間3000万円のコスト削減
  • 業務効率化によるグループ全体で6万時間の時短効果
  • 2~3年でシステム投資分を回収できる

契約関連のデジタル化の成功ポイント

工程間でのデータ引き継ぎ

  • 見積依頼、回答、契約、請求、支払いなどの工程間でデータ連携
  • 人の手を介さずに書類作成の自動化比率を高める
  • 例)見積依頼時に使用した発注仕様を契約書に反映させるなど

書類のフォーマットを標準化

  • 標準化によって、全社的に書類作成の自動化が進む

社内手続きをデジタル化する

  • 書類の自動チェック、承認などもデジタル化
  • システムにワークフローの機能を持たせるなどが必要

2023年10月に導入される「適格請求書(インボイス)制度」

  • 消費税額の計算に必要な明細を請求書に記録、保存する制度
  • すべての企業でデジタル化すべき事務手続き

仕入税控除額の申告に必要となる

  • 現行では帳簿上のデータから申告できる
  • 2023年から適格請求書を交付し、消費税の積み上げが必要
  • 紙のインボイスでは手作業で計算が必要

各業界で使用するEDIシステムのデータ連携が必要に

【WEBを支える技術】HTTPメソッド編~名は体を表す~

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

  • 作者:山本 陽平
  • 発売日: 2010/04/08
  • メディア: 単行本(ソフトカバー)

HTTPメソッドとは

  • クライアントからサーバーへリソースに対してどのような処理を行うかを伝達する

8つのメソッドと意味

  • GET
    • 子リソースの取得
  • POST 子リソースの作成
    • リソースへのデータ追加
    • どのほかの処理
  • PUT
    • リソースの更新
    • リソースの作成
  • DELETE
    • リソースの作事
  • HEAD
    • リソースのヘッダ取得
  • OPTIONS
    • リソースがサポートするメソッドの取得
  • TRACE
    • 自分宛てにリクエスメッセージを返すテスト
  • CONNECT
    • プロキシ動作のトンネル接続への変更

HTTPメソッドとCRUDの関連

CRUD 意味 HTTPメソッド
Create 作成 POST / PUT
Read 読込 GET
Update 更新 PUT
Delete 削除 DELETE

GET メソッド

  • リソースの取得
  • 例)WEBページの取得、画像の取得、映像の取得など

POST メソッド

  • 子リソースの作成
  • リソースへのデータ追加
  • 他のメソッドでは対応できない処理の代行
    • GETではURIにパラメータが多すぎる場合、代わりにPOSTでリクエストボディにパラメータを入れてデータ取得

PUT メソッド

  • リソースの更新
  • リソースの作成
  • POSTとPUTの使い分け

DELETE メソッド

  • リソースの削除

HEAD メソッド

  • リソースのヘッダを取得
  • Content-Type、文字コードタイプなど

OPTIONS メソッド

  • リソースのサポートするHTTPメソッドを取得
    • Webアプリケーションに実装
    • Apacheに挙動を設定

GETとPOSTだけで実装する場合

  • HTMLのフォームはGETとPOSTだけ使用可能
    • HTMLの制限でGETとPOSTだけを利用する時代が長かった
    • AjaxXMLHttpRequestモジュールで解消
    • 携帯電話(ガラケー)ではサポートしていないので、GETとPOSTのみ
  • _methodパラメータで解決する方法

    • inputタグにパラメータとして含め、サーバー側で受け取る
    • 例)'< input type="hidden" id="_method" value=PUT">'
  • X-HTTP-Method-Overrideで解決する方法

    • リクエストボディにパラメータとして含め、サーバー側で受け取る
    • 例)X-HTTP-Method-Override:PUT

べき等性と安全性

  • べき等性
    • ある操作を何度実行しても結果が同じであること
  • 安全性
    • 操作対象のリソースの状態を変化させないこと
  • GET
    • べき等、安全
  • POST
    • べき等でない、安全でない
  • PUT
    • べき等、安全でない
  • DELETE
    • べき等、安全でない

HTTPメソッド、URIとサーバー側処理の整合性をとる

  • GETでリソース作成、リソースの削除を行ってはならない
  • PUTで相対的な更新を行わない

【WEBを支える技術】を読む理由 - devdevdevReports

【WEBを支える技術】REST編 - devdevdevReports

【WEBを支える技術】URI仕様編 - devdevdevReports

【WEBを支える技術】URI設計編~良いURI設計とは~ - devdevdevReports

【WEBを支える技術】HTTP基礎編~シンプルさが標準化~ - devdevdevReports

【WEBを支える技術】HTTPメソッド編~名は体を表す~ - devdevdevReports

【WEBを支える技術】HTTPステータス編~名は体を表す~ - devdevdevReports

【WEBを支える技術】HTTP基礎編~シンプルさが標準化~

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

  • 作者:山本 陽平
  • 発売日: 2010/04/08
  • メディア: 単行本(ソフトカバー)

HTTPとは

  • RFC2616で規定されたプロトコル
  • 最新バージョンは1.1
  • 様々なデータを転送可能
    • ハイパーテキスト(html、xmljsonなど)
    • 画像(img、pngjpeg、gifなど)
    • 動画(mp3、movなど)
    • 音声(asf、asxなど)
    • ドキュメントファイル(pdf、ppx、doc、xlsなど)
  • RESTを実現するWEB基盤
    • 統一インターフェース
    • ステートレスサーバー
    • キャッシュ

TCP/IPとは

階層型プロトコル

アプリケーション層

  • HTTP、NTP、SSHSMTPDNS
  • アプリケーション単位で通信

トランスポート層

  • UDPTCP
  • ポート番号単位で通信

インターネット層

ネットワークインターフェース層

HTTPの歴史

初期(HTTP 0.9)

  • 1990年に発明
  • 仕様書なし
  • ヘッダーなし
  • HTTPメソッドはGETのみ

統一期(HTTP 1.0)

  • 1993年~1996年に発表
  • Netscape、InternetExploreのブラウザ戦争の時期
  • ヘッダーの導入
  • GET以外のHTTPメソッドの導入

完成期(HTTP 1.1)

  • 1997年~1999年に発表
  • チャンク転送の導入
  • Acceptヘッダーによるコンテントネゴシエーションの導入
  • 複雑なキャッシュコントロール機能の追加
  • 持続的接続機能の追加

拡張期

クライアント/サーバー方式

クライアントの役割

  • リクエストメッセージの構築
  • リクエストメッセージの送信
  • レスポンスの待機
  • レスポンスメッセージの受信
  • レスポンスメッセージの解析
  • クライアントの目的に応じた処理(画面表示など)

サーバーの役割

  • リクエストの待機
  • リクエストメッセージの受信
  • リクエストメッセージの解析
  • アプリケーションプログラムへの処理委譲
  • アプリケーションプログラムからの結果を取得
  • レスポンスメッセージの構築
  • レスポンスメッセージの送信

HTTPメッセージ

リクエストメッセージ

  • リクエストライン
    • メソッド
      • リソースに対しての操作
      • 例)GET、POST、PUT、DELETEなど
    • リクエスURI
    • プロトコルバージョン
      • 使用するHTTPのバージョン
      • 例)HTTP/1.1
  • ヘッダー
  • ボディ
    • アプリケーションに渡すデータ(パラメータ)

レスポンスメッセージ

  • ステータスライン
    • アプリケーションが返す処理結果
    • 例)200:成功、403:権限エラー、500:サーバー内エラー
  • ヘッダー
  • ボディ
    • クライアントが目的を果たすために渡すデータ
    • 例)HTML(画面表示)

HTTPメッセージの構成要素

構成要素 リクエス レスポンス
スタートライン リクエストライン ステータスライン
ヘッダー リクエストヘッダ レスポンスヘッダ
空行
ボディ リクエストボディ レスポンスボディ

HTTPのステートレス性

アプリケーション状態

  • システムにログインしてからログアウトするまでの一連の操作の間の状態
  • セッション状態ともいう
  • アプリケーション状態を保存しないのがステートレス

ステートフルの例

ステートフルの欠点

  • クライアントの数が増えた場合にスケールアウトさせにくい
  • 大規模サービスには適用できない
    • 1台のサーバで管理できるクライアントの数には限界がある
    • 不特定多数のクライアントを相手にするとクライアントとサーバを固定できない
    • アプリケーション状態を同期させる必要がある
    • データを同期するとパフォーマンスが低下する

ステートレスの利点

  • システムをスケールアウトしやすい
    • クライアントがアプリケーション状態を都度伝えるため、サーバーで管理しない
    • クライアントが増加した場合はサーバーの増設で対応できる
    • クライアントはどのサーバーにリクエストしてもいい

ステートレスの欠点

  • パフォーマンスの低下
    • データ通信量が多くなる
      • クライアントから冗長的なメッセージを送信するため
      • 認証処理などサーバ負荷が高い処理も冗長的に行うため
    • 通信エラーへの対処が難しい
      • リクエストの途中でエラーとなるとデータの不整合が起きやすい
      • サーバーはアプリケーション状態に関係なく、リクエストを受け付けるため

【WEBを支える技術】を読む理由 - devdevdevReports

【WEBを支える技術】REST編 - devdevdevReports

【WEBを支える技術】URI仕様編 - devdevdevReports

【WEBを支える技術】URI設計編~良いURI設計とは~ - devdevdevReports

【WEBを支える技術】HTTP基礎編~シンプルさが標準化~ - devdevdevReports

【WEBを支える技術】HTTPメソッド編~名は体を表す~ - devdevdevReports

【WEBを支える技術】HTTPステータス編~名は体を表す~ - devdevdevReports

【日経コンピュータ】電子契約サービス導入によるメリット!

電子契約サービス導入によるメリット!

日経コンピュータのCIOが挑むに「電子契約サービス導入によるメリット!」が取り上げられましたので、紹介します。

野村証券の取り組みと成果

電子契約サービスの導入

  • 紙の契約書から電子の契約書への切り替え
    • 契約締結頻度の高い取引先を重点的に開始
    • 2017年NSSOLの電子契約サービスを導入
  • 成果
    • 3年間で1万3000件の電子契約を締結
    • ITベンダーと結ぶ開発、保守契約を中心

電子化導入に合わせた取組み

体制の改革

  • 全社で契約書を集約・管理する体制の構築
  • 契約条件やコストを見直す体制の構築

導入に向けた工夫

  • 法制度の理解
    • 紙への押印と同等の証拠能力があるか
    • 訴訟や調停などの契約内容に争いが生じた場合に対応できるか
  • 契約書の文言の見直し
    • 「電子契約ファイルが原本で印刷物は写しである」と明記
  • 社内規定、運用の見直し
  • 総務や購買など部門ごとに業務フローの見直し

電子契約のメリット

  • 印紙税のコスト削減
  • 紙の保管コスト削減
  • 契約に要する時間短縮
    • 印刷、押印、郵送の業務削減
    • 取引先に届くまでの時間が削減
  • 契約情報の詳細を把握
    • 契約の自動更新、解約通知の有無などを把握
  • データ共有によるデータの有用化
    • 取引先名、契約締結日の詳細情報を検索可能
  • 契約書を共有による不正防止などのガバナンス強化
  • BCP(事業継続契約)対応
    • 災害時の消失リスクの回避

契約内容に合った電子契約サービスの選択

電子契約の2つの形態

電子サイン

  • 従来の役割
  • 仕組み
    • 電子契約サービス運営会社が利用者情報を管理
      (メールアドレス、パスワードなど)
    • 利用者本人が認証し、契約意思を確認
  • 留意点
    • 導入負荷が少ないが、電子署名に比べて簡易的
    • 契約書の改ざんに気づきにくい
  • 正しい使用用途
    • 社内での電子決裁

電子署名

  • 従来の役割
    • 印鑑証明書を取得して使う実印
  • 仕組み
  • 留意点
  • 利用者負荷低減する「リモート署名」
    • 利用者はCAへの秘密鍵取得を行い、電子契約サービス会社に預ける
    • 電子契約サービス会社が秘密鍵を管理、電子証明書を取得を代行

電子サインと電子署名の使い分け

GMOインターネットの例

  • 「電子サイン」:秘密保持契約(NDA
  • 電子署名」:M&Aや株式譲渡契約、一定金額以上の重要な契約

新たなクラウド電子署名(立会人型電子署名

  • 電子契約サービスがCAへの秘密鍵取得~管理まですべて代行
  • 電子サービス会社によって本人確認のレベルが異なる
    • 多要素認証で本人確認
    • メールアドレスのみで本人確認
  • 弁護士ドットコムの「クラウドサイン」
    • メール認証で本人認証
      • 利用者側でメールアドレスと本人の関係を証明する必要がある
    • メルカリが導入
      • 取引先とはメールで連絡を取っているので、間違えるリスクは少ない

リスク分析による電子契約サービスの使い分けが必要

  • 問題発生時の影響と発生確率を勘案して決定すべき
  • 契約額が大きいものは当事者型電子署名を利用するなど

電子契約サービス間の連携

多くの電子契約サービスを利用する羽目になる中小企業

  • それぞれの企業が異なった電子契約サービスを利用
  • 企業間で1つを選択する必要
  • 受注側や中小企業は発注者、大企業側に合わせることに
  • NDAやEDIにも同様の問題

複数の電子契約サービスをつなぐプラットフォームを構築

  • Smile Worksが開発
  • 電子契約サービスやEDIなどの様々なサービス間連携を構築

企業間取引の社会基盤へ

  • 2020年5月 データアプリケーション(DAL)と連携
    • EDIで実績のあるデータ変換エンジンを組み込む
  • 企業間取引に必要な認証も実装予定
  • 標準企業コードの採用
    • 日本情報経済社会推進協会(JIPDEC)が提供
  • 企業情報の連携

【日経コンピュータ】コロナ禍はハンコをなくすチャンス!

コロナ禍はハンコをなくすチャンス!

日経コンピュータのCIOが挑むに「コロナ禍はハンコをなくすチャンス!」が取り上げられましたので、紹介します。

コロナ禍で人気のハンコ代行ITサービス

  • 紙の書類にハンコを押すためだけに必要なハンコ出社

ハンコ出社の代役を担うシヤチハタ社の「パソコン決裁Cloud」

  • 電子印鑑1個当たり月額100円
  • 2020年6月までの期間限定で無料キャンペーン
  • 5月末までで25万件の新規申し込み

dstmp.shachihata.co.jp

人気の理由

仕組み

  • 押印の順番も履歴管理
    • いつ誰が文書に押印したかをクラウドで管理
  • 改ざんの検知が可能
    • PDFで作成した電子署名を連携可能(米ドキュサイン)

ハンコ文化の原因は社会通念

一般的な認識と実情

  • 押印、契約のデジタル化の原因は法制度
  • 企業団体も法制度改正の要望を国に提出
  • 法務省が法制度が原因であることを否定
  • 内閣府法務省経済産業省が連名で電子署名と電子認証サービスの促進を発表

http://www.moj.go.jp/content/001322410.pdf

ハンコの有効性を支える「二段の推定」

  • 最高裁判所での判例で有効性が認められている
  • 本人の意思による押印であることが推定
  • 文書が本人の意思で作成されたと推定

電子署名の有効性

ハンコの信頼性

  • 巷ではハンコの信頼性は高い
  • 一方で複製や偽造は容易
  • 社会通念と実情にはギャップが存在する

デジタル化が進むメリット

  • テレワークによるさらなる業務効率化
  • 紙の契約書に課税される印紙税の削減
  • 紙運用で必要となる文書管理コスト、保管場所の削減

必要なのは一体となったデジタル化の取り組み

デジタル化範囲の拡大

  • 電子契約だけでなく、他の分野にも拡大
  • 受発注のEDI(電子データ交換)、電子商取引(EC)

統一範囲の拡大

  • 電子契約システムとEDI、ECは形式は異なるが、内容は同じ
  • すべてをまとめてデジタルコマースとして推進

行政での推進

  • 補助金申請などでは実印が必要な実態
  • 行政ごとに申請が必要
  • 行政間の情報連携も可能になる
  • 選挙での電子投票など、適用可能範囲は広い
  • 行政サービスの品質向上につながる

【日経コンピュータ】チューリヒ保険の挑戦!在宅コールセンターの導入

チューリヒ保険の挑戦!在宅コールセンターの導入

日経コンピュータのCIOが挑むに「チューリヒ保険の挑戦!在宅コールセンターの導入」が取り上げられましたので、紹介します。

CIO紹介

従業員満足度を高める理由

顧客満足度との強い連動

チューリヒ保険顧客満足度が重要な理由

在宅コールセンター導入プロジェクト

従業員満足度をITで支援

  • 業務水準を落とさずにオペレーターが安心して働ける環境を実現

契機は2019年大型台風被害

  • 交通機関の運休でオペレーターが通勤できず、業務が滞るリスクを解消

新型コロナ禍での成果

  • オペレーター850人のうち、95%が在宅勤務
  • 出社は郵便物の処理などの例外のみ

チューリヒの特徴と戦略

  • WEBサイトと電話によるダイレクト販売
  • WEBサイトだけでの完結は少ない
  • コールセンターでの問い合わせで判断する顧客ニーズは根強い
  • コールセンターのBCP(事業継続計画)は経営の視点から優先度が高い
    チューリヒ保険CEO 西浦正親)

CIOの挑戦

課題の整理

  • 法規制のクリア
  • セキュリティーの確保

解決策

  • 仮想デスクトップ環境(VDI)の導入
  • セキュリティや個人情報保護法上の課題をクリア
  • オペレーターは契約者の個人情報を閲覧して電話対応できる
  • 閲覧したデータはオペレーターのローカル端末には残らない

最大の問題は音声の品質

  • あらゆる環境におけるチューニング
    • 在宅オペレータの通信環境は一様ではない
    • 高品質の通信環境をそろえるオペレーターは少ない
    • あらゆる通信環境で顧客と円滑に通話できるチューニングで解消

業務上の証拠として必須要件となる高音質の録音

問題
  • 社内の電話交換機を介するため、音声を劣化させずに録音するのは困難
解決策
  • 在宅オペレーターのスマートフォンアプリに一時保存
  • 順次サーバーに伝送する方式に変更
  • 2020年初めに完成、新型コロナ対策に間に合う

CIOシェアリングで副業

2019年CIOシェアリング協議会を立ち上げ

  • ITベンダー、金融業で長年の培ってきたITスキルを活かして多くの企業を支援
  • 東急ハンズ元CIO長谷川秀樹さんらも参画
  • チューリヒ保険の仕事とは別の副業として社内で認可

CIOの役割

  • ITを駆使して企業の業績を伸ばす役割
  • 会社や業種が違えど、共通で活かせるCIOの視点

CIOの育成

  • 日本の一般企業のIT部門はシステム開発、運用部門になりがち
  • ビジネス視点で物事を見られるCIOが少ない
  • 外部のCIO経験者として、企業の文化、体制を変革するCIOに影響を与えたい

【日経コンピュータ】カゴメの戦略!AI農業推進

カゴメの戦略!AI農業推進

日経コンピュータのインタビューに「カゴメの戦略!AI農業推進」が取り上げられましたので、紹介します。

インタビュー

  • カゴメ株式会社
  • 社長 兼 野菜事業本部長
  • 山口聡 氏

新型コロナウイルスの影響

好調の個人向け事業

  • トマトジュース、野菜100%ジュースの出荷が増加
  • 2月に発売した野菜と豆乳を合わせた「野菜生活Soy+」が好調
  • 野菜を使った料理メディア「VEGEDAY」も好調(14万アクセスを記録)

www.kagome.co.jp

  • 食を通じた免疫力の向上など健康志向への高まりが影響

落ち込む法人向け事業

  • 外食産業向けの売上が減少
  • 飲食店の休業が影響
  • 経済活動の再開で内食から外食への移行に期待
  • 状況の変化が早い中で、迅速かつ柔軟な対応がカギ

2017年から始まった働き方改革

  • 在宅勤務の推進
  • 人事制度や情報システムの整備
  • 新型コロナ禍で取組みを活用、加速へ

中長期のビジョン

中期ビジョン

  • 2021年までの中期経営計画の推進
  • 収益力は向上、成長力が課題

長期ビジョン

  • 2025年までの目標
  • 食を通じた社会課題解決
    • 健康寿命の延伸
    • 農業振興、地方創生への貢献
    • 世界の食糧問題

健康寿命延伸への取り組み

日本人の野菜摂取量を増やす目標

  • 成人に必要な野菜摂取量:350g/日
  • 平均の野菜摂取量:が290g/日

他社、外部団体を巻き込んだキャンペーン

  • 20社以上が賛同した「野菜をとろうキャンペーン」
  • 新型コロナで一時中断、7月末から再開へ

ITを活用した取り組み

  • 手のひらから野菜摂取量を計測するイノベーション
    • タブレット端末とセンサーを背う俗
    • センサーを手のひらにかざす
    • 手のひらの皮膚に蓄積したカロテノイド(野菜や果物の色素)量から野菜摂取量を算出
  • ドイツのベンチャー企業と共同研究

農業振興・食糧問題への取り組み

農業の収益性向上へ

  • 広い農地を少ない人数で効率化
  • 人工衛星からが追う解析する営農支援AIを開発
  • ドローンでは運用に人が必要、人工衛星は解析ソフトだけでOK

ビニールハウス内にAIを活用した2つのシステム

収穫量の予測システム

  • 気温、湿度、空調の運転記録、気候、トマトの収穫量を蓄積
  • 蓄積したビッグデータからAIで解析
  • 栽培中のトマトが2週間後の出荷可能量を予測

トマトの成熟度を予測するシステム

  • トマトの果実を撮影した画像データを蓄積
  • 画像から色づきなどをもとにAIで解析
  • 出荷に適した成熟度のトマトが1週間後に出荷できる量を予測

収益の変動リスクと抑制効果

  • トマトの価格変動リスク
    • トマトは長期保存できない農作物
    • 想定以上の収穫量の場合、販売単価が低下
  • 変動リスク抑止
    • 事前に収穫量がわかれば、スーパーとの商談がしやすい
  • 今後の展開
    • 玉ねぎなどほかの野菜にもAIを活用

国内農業の実情と課題

国内農業の実情

  • 産業としての農業のイメージ
    • 就農人口の減少
    • 作業の非効率性
    • 衰退産業のイメージ
  • 実際の状況

最大の課題は販路開拓

  • 最大の課題は販路開拓
    • 売れるかわからないまま農作物を栽培する不安
    • いざ収穫したら売れ行きが悪いと価格が下落
    • 安定した販路があれば、安心して生産できる

カゴメの支援

農業生産法人の販路開拓をサポート

  • トマトの加工品を製造販売した実績
  • 保持する様々な販路チャネルを活用

All In Oneのサポートへ

  • カゴメ農業生産法人から農作物を買い取る契約
  • 販路サポートとAIシステムとのセットで営農支援サービスを提供

農業生産法人の経営支援

  • SCMすべてをサポート
    • 栽培、収穫、加工、市場への流通など
    • AIのシステム提供だけでなく、農業法人との成長へ
  • 農業生産法人にとってのメリット
    • 安定的な生産、販売
  • カゴメにとってのメリット
    • 安定的な原材料の調達