devdevdevReports

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

【日経コンピュータ】アフラックのDX~後編~

アフラックのDX革命~前編~

日経コンピュータの特集に「アフラックのDX革命」が取り上げられましたので、前編を紹介します。

ロボット活用における分身出社

2019年秋 分身ロボット「OriHime」を導入

  • ダイバーシティ推進部が企画
  • 研修場所から離れた地域に住む社員のキャリアアップ支援

「OriHime」とは

orihime.orylab.com

  • オリィ研究所が開発
  • カメラ、マイク、スピーカーが組み込まれている
  • スマートフォンタブレットお専用アプリから遠隔操作できる
  • 遠隔地から映像、音声の確認、発言などが可能

活用方法

  • 細かい動作が可能(手を挙げる、うなずくなど)
  • ビデオ通話よいも親近感のあるコミュニケーション
    (高代公美 東京総合支社支社次長)
  • 集合研修などメイン会場があり、一部が遠隔地の場合に有効
  • 半数以上がリモートの場合は向かない

テレプレゼンスロボット「temi」で日常業務でも導入

「temi」とは

www.robotemi.jp

  • ハウステンボスグループのロボット事業会社「hapirobo st」が販売
  • ディスプレイ、マイク、カメラ、センサーを搭載
  • 自律走行、ビデオ通話が可能

活用方法

  • 介護、育児と仕事を両立支援
  • けがで出社が難しい社員を支援
  • オフィスの雰囲気やメンバーの表情を確かめられる

導入計画

  • 2020年6月 パイロット運用開始
    • 東京在住の管理職が地方都市の拠点で勤務を開始
  • 本格展開
    • 社内での活用に展開
    • 保険代理店などに展開を検討

成果をもたらすアジャイル開発体制

経営環境の変化を察知

従来のプロジェクト

経営環境の変化

  • 異業種のスタートアップ企業が金融サービスに参入
  • 速いスピード感で新しいデジタルサービスを提供
  • 従来のプロジェクト推進では対抗できない

アジャイル開発への切り替え

  • 各業務部門とIT部門が協力してプロジェクト推進する仕組みを構築
  • 2019年1月 アジャイル推進室を立ち上げ
  • 2019年11月 Aflac Agile Baseを新設
  • 透明性、柔軟性を保ち、スピード感ある運営を実現

アジャイル開発体制

3つの組織体制

  • スクワッド
    • プロジェクト開発チーム
    • チーム構成
      • プロダクトオーナー
      • スクラムマスター
      • 業務部門のメンバー
      • IT部門のメンバー
  • チャプター

    • 各部署が担当
    • スクワッドに派遣する業務部門メンバー、IT部門メンバーを選抜
  • トライブ

    • スクワッドを管理
    • スクワッド間の取り組みの方向性の調整

意思決定の権限委譲

  • スクワッドのプロダクトオーナーに権限を委譲
  • 取組みテーマ、予算、意思決定の権限の大半を委譲
  • 迅速な意思決定を実現
  • 意思決定の重さによって待遇を見直し

【日経コンピュータ】アフラックのDX~前編~

アフラックのDX革命~前編~

日経コンピュータの特集に「アフラックのDX革命」が取り上げられましたので、前編を紹介します。

アフラックで起きた51のDXプロジェクト

  • 二見通 CIOが指揮

3つの領域でのDX

顧客・保険代理店

  • 例)ビジュアルIVR
  • 電話とスマホ画面が連動し、顧客体験を一新

社内業務

  • 例)あひるーぺ
  • 社内の情報検索システムにAIを搭載
  • 検索時間を6割削減

マーケティング・営業

  • 例)営業サポートAI
  • 顧客との会話内容をAIがアドバイスなどでサポート

AIスピーカーの開発

企画:音声認識への着目

目的

  • 業務効率化やシステムの利便性向上のため

適用可能性

  • 一般的な会話で利用できる
  • 社内固有の業務用語を予めシステムに登録すれば、認識できる

適用先の課題整理(社内ヘルプデスク)

  • 受付時間
  • 朝から夕方までの担当社員による受付
  • 様々な勤務体系を持つアフラック
  • 早朝出社する社員が利用できない時間帯が存在
  • 混雑
  • 日中は混雑で電話がつながらない

期待する効果

  • 受付時間
  • AIが応答を行うことで24時間対応が可能
  • 混雑
  • AIが応答を行うことで混雑が解消
  • ヘルプデスク担当社員の負荷軽減

開発

アジャイル開発で3か月での稼働を実現

業務直結の効率化

  • 業務利用を念頭にプロトタイプ開発
  • 活用度を高める機能拡張を実現
  • 回答の聞きそびれ、聞き取りづらいなどの課題を発見
  • 応答をスピーカーだけでなく、画面表示やメール送信などの機能追加で解消

3つのポイント

  • UI、UXの実現
  • AIスピーカーでは応答内容を画面表示するUIを採用
  • 適用技術の丁寧に説明
  • ヘルプデスク担当社員に音声認識技術を説明
  • 人を助けるデジタル技術を導入
  • ヘルプデスクをデジタル技術への置き換えではなく、業務負担の軽減と位置付け

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

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

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

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

HTTPステータスとは

  • サーバーからクライアントにリクエストの結果を返すコード
  • HTTPステータスによってそのあとのクライアントの挙動が変わる
  • 仕様通りにステータスを返すことが重要

ステータスコードの種類

  • 1桁目でどの種類のステータスであるかを判別できる
  • 1xx:処理中
  • 2xx:成功
  • 3xx:リダイレクト
  • 4xx:クライアントエラー
  • 5xx:サーバーエラー

ステータスコードの意味

  • コンポーネント間の結合度を下げる
  • クライアントとサーバーを疎結合にする
  • クライアントの置き換えやサーバーのバージョンアップが行いやすい

エラー処理

プロトコルにあたフォーマットでエラーを返す

  • AtomPubを利用したWebAPIの場合、Atomで返す
  • Jsonを利用したWebAPIの場合、Jsonで返す

Acceptヘッダに応じたフォーマットでエラーを返す

  • クライアントからリクエストで指定

ステータスと結果の整合性

  • ステータスは200(成功)で、レスポンスボディには「File Not Found」となっているなど
  • 人間が理解できても、検索エンジンや機械が解釈を間違う。

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

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

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

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

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

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

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

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

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

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

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

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

大成建設の事例

  • 「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)が提供
  • 企業情報の連携