WEB道楽

WEB道楽

【日経コンピュータ】電子契約サービスの普及~弁護士ドットコムの挑戦~

電子契約サービスの普及~弁護士ドットコムの挑戦~

日経コンピュータの挑戦者に「電子契約サービスの普及~弁護士ドットコムの挑戦~」が取り上げられましたので、紹介します。

挑戦者

  • 橘大地氏
  • 弁護士ドットコム クラウドサイン事業部長

経歴

新型コロナ禍で注目される電子契約サービス

  • 電子的な文書によって契約を完結
  • 契約当事者に代わり、サービス事業者が電子署名することで契約を担保
  • 国内では弁護士ドットコムのクラウドサインが圧倒的なシェアを持つ

商業・法人登記での認可が普及が加速

2020年5月の内閣府規制改革推進会議で要望

2020年6月に認可

  • 法務省の商業・法人登記におけるオンライン申請
  • 電子契約サービスの電子署名を付けた文書を利用可能
  • 他社の電子契約サービスも利用可能に

期待する効果

  • 従来は取締役全員の電子証明書の準備が必要
  • オンライン申請に必要な準備の手間と時間が大幅に削減
  • 法的有効性を払拭できるため、電子契約サービスの普及が加速

普及を阻む2つの壁

法律の壁

20年改正されていない電子署名

  • 2001年に施行
  • 電子契約サービスで必須となる電子署名について制定
  • 当事者同士の電子署名のみを想定
  • サービス事業者が代行で電子署名することを想定していない

導入企業の法務部からストップがかかる事例

  • 導入企業の事業部へは提案がうまくいくことが多い
  • 電子署名法に準拠していない理由で失注

商習慣の壁

根付いていたハンコ文化

  • 慣れている紙と印鑑を希望する企業も少なくない

導入企業の周りへの理解

  • 導入企業への説得
  • 取引先企業への説得

乗り越えた壁

弁護士の強みを活かした説明

  • 電子署名法に準拠しなくても契約の有効性を担保可能であることを説明
  • 1社1社の顧客に粘り強く説明
  • 電子契約サービスが世界的に広がっている実情を説明
  • デジタル時代に利便性の高い電子契約を採用すべきことを説明

結果

今後の展望と想い

生活をより便利なものへしていきたい

  • 個人への普及がカギ

日本発のサービスを世界へ輸出

  • 世界的にも普及していない
  • 日本が世界トップの電子契約社会になる可能性もある
  • 日本社会の変革を目指す

【日経コンピュータ】富士通、アジャイルフレームワーク導入支援へ

富士通アジャイルフレームワーク導入支援へ

日経コンピュータのニュースに「富士通アジャイルフレームワーク導入支援へ」が取り上げられましたので、紹介します。

2020年6月 富士通が米スケールド・アジャイルとパートナー契約を締結

SAFeとパートナー契約した富士通の狙い

  • DX事業を推進していきたい
  • DXで経営スピードの向上は図り、経営とITの連動で企業全体の変革を目指す
  • アジャイル開発の知見は蓄積したが、経営スピードのノウハウは薄い
  • SAFeの特徴であるとマッチする

資格保持者を増やし、導入支援を拡大へ

SAFe導入支援の認定資格(SPC)の保持者を増やす計画(現在:28人)

  • 研修プログラムの作成など

先行するNTTデータ

  • 2017年にパートナー契約を締結
  • 現在のSPC保持者:60人
  • 2021年までに100人を目指す

さらに先行している北米

【日経コンピュータ】電子社印「eシール」制度化へ~EU手本にGMOなどが先行~

電子社印「eシール」制度化へ~EU手本にGMOなどが先行~

日経コンピュータのニュースに「電子社印「eシール」制度化へ~EU手本にGMOなどが先行~」が取り上げられましたので、紹介します。

社印(角印)とは

概要

  • 企業が発行する請求書、領収書に広く使用されている
  • 企業が使う認印的な存在

社印(角印)の欠点

  • 書類にハンコを押印するため、印刷、封入、郵送などの手間がかかる
  • 新型コロナウイルスの感染拡大防止のために電子化のニーズが高まっている

社印の代替になる「eシール」とは

  • 社印の電子版、電子署名の企業版の位置づけ
  • 自社で作成したPDFなどの電子文書にeシールを付与する
  • データの信頼性を確保する仕組みである「トラストサービス」の1つ

「eシール」の2つの機能

  • 文書を作成したのは自社であることの証明
  • 文書は作成後に改ざんされていないことを証明

必要となる法整備

既に実用化しているEU

  • 「eIDAS(イーアイダス)規則」という法制度に基づき、実用化

日本での法整備

  • 日本では法規制がない
  • 2020年4月に総務省が検討会を立ち上げ
  • ベンダー関係者、有識者が出席し、制度設計を検討

eシール事業進出を発表した2つの事業者

GMOグローバルサイン

  • 電子認証サービスを手掛ける企業
  • 2020年6月に日本版eシール対応のサービス設計、開発の開始を発表
  • 総務省での検討を踏まえて日本版eシール対応サービスを提供

帝国データバンク

  • 企業調査情報を提供する企業
  • 2020年6月に日本版eシール対応のサービス設計、開発の開始を発表
  • 同社が公表する企業調査情報の改ざん防止に使用する予定
  • 電子認証サービス会社との連携も視野

自治体も動き出した

2020年7月に福岡県飯塚市が実証事業を2021年に実施することを発表

住民が遠隔地から各種証明書をスマホアプリで受け取れるサービス

  • 住民票などの各種証明書データに独自のeシールやタイムスタンプを付与
  • データの作成時刻やデータの改ざんがないことを証明

期待するサービスの効果

  • 窓口交付の多い住民票のリモート化による業務効率化
  • 住民票以外の課税証明書など他の証明書への拡大を期待
  • 飯塚市が発行した証明書を企業などが確認、保存利用する社会実装を目指す

【WEBを支える技術】HTTPヘッダ編~~

HTTPヘッダの重要性

  • メッセージボディに対する付加的な情報(メタデータ)を表現
  • クライアントとサーバはヘッダを見てメッセージに対する挙動を決定する
  • メディアタイプなや言語タグなど、アプリケーションのフレームワークでなく、実装者が設定するヘッダも多い

HTTPヘッダの生い立ち

  • HTTP1.0から登場
  • 電子メールのメッセージ仕様のヘッダ形式をもとに追加
    → インターネットの成長とともに規定された歴史
  • HTTP1.0から登場ヘッダと電子メールのメッセージヘッダと共通部分が多い
    例)Content-Type、Dateなど

  • 歴史からくる制約、バッドノウハウも多い

    • メール:7bit ASCIIコード以外の文字が入れられない
    • HTTP:文字エンコーディングの制限でラテンアルファベット以外い入れられない
  • 電子メールとの違い

    • メール
      • 1方向にしかメッセージのやり取りができない
    • HTTP
      • 一度の通信でリクエスト/レスポンスの2つのメッセージをやりとり

日時

MIMEメディアタイプ

  • メッセージでやり取りするリソースの表現の種類を指定
  • 電子メールからきた仕様(Muktipurpose Internet Mail Extensions)

  • Content-Type

    • メディアタイプを指定する
    • タイプとサブタイプで構成
  • charsetパラメータ

    • 文字エンコーディングを指定する。
    • タイプがtextの場合、デフォルトがISO8859-1のため日本語だと文字化けする。
    • xmlの場合だと、xmlの中に文字コードを定義してもHTTPヘッダで定義しておかないと、文字化けしてしまう
    • 必ずcharsetパラメータを定義したほうがいい。

言語タグ

  • Content-Language
    • リソース表現の自然言語を指定する
    • ISO639で定義された言語コードとISO3166で定義された地域コードを指定
      例)「ja-JP」

コンテントネゴシエーション

  • メディアタイプ、文字エンコーディング、言語タグはサーバーで指定
  • クライアントと交渉して決めることができるパラメータ

  • Accept

    • 処理できるメディアタイプを伝える
    • メディアタイプに優先順位をつける
    • サーバーがクライアントからの要求にこたえられない場合、「406:Not Acceptable」
  • Accept-Charset

  • Accept-Language

    • 処理できる言語を伝える
    • 自然言語に優先順位をつける

Content-Lengthとチャンク転送

  • Content-Length

    • ボディの長さを指定する
    • 静的ファイルなどあらかじめサイズがわかっている場合
  • Transfer-Encoding:chunked

    • チャンク転送
    • ボディを分割して転送する。
    • 動的に画像生成する場合など、ファイルサイズが決まるまでレスポンスが返せない場合に応答性能が低下するのを防ぐ
    • チャンクサイズは16進数を仕様
    • HTTP1.1で受信が必須仕様

認証

  • HTTP認証方式

    • リソースへのアクセス制御がかかっている場合のクライアントへの認証情報通知
    • ステータスコード
      • 401 Unauthorized
      • このリソースに対してのアクセスには認証が必要
    • WWW-Authenticateヘッダ
      • 認証方式
      • URI空間
         →URI中にあるパス以下のコト
      • 同じURI空間に属するリソースには同じ認証情報を送信できる
  • HTTPS

    • HTTP、SSL/TLSを組み合わせた通信の総称
    • 通信路を暗号化して通信データを保護し、盗聴を防ぐ目的で利用する
      • 暗号化
      • 認証
      • 改ざん検知
  • Basic認証

    • ユーザー名とパスワードをAuthorizationに入れれてリクエス
    • ユーザー名とパスワードは「:」で連結し、Base64エンコーディング
    • 簡単にデコード可能なので、平文がネットワーク上に流れている
    • 許容されるセキュリティ強度か、HTTPS通信(SSLTLS)で暗号化するなどの検討が必要
  • Digest認証

    • セキュアな認証方式
    • 認証なしでリクエストして、レスポンス情報から認証情報を生成し、再送信する
    • チャレンジ

      • リクエス
        • 認証情報なし
      • レスポンス
        • nonce

          • number used once
          • リクエストごとに変化する文字列
          • タイムスタンプ、パスワード(サーバーのみが知りえる情報)などから生成
          • 有効期間を狭めるためにタイムスタンプを活用
        • qop

          • quality of protection
          • 「auth」 or 「auth-init」が指定
          • クライアントのメッセージダイジェスト作成方法に影響あり
          • auth:メソッドとURIからメッセージダイジェストを作成
          • auth-init:メソッドとURI、メッセージボディからメッセージダイジェストを作成
          • POSTやPUTの場合、メッセージ全体が改ざんされていないことを保証
        • opaque

          • クライアントが推測できない文字列
          • URI空間ごとに共通
    • 再送信

      • ①ユーザー名、realm、パスワードパスワードを「:」で連結し、MD5ハッシュ値を求める
      • ②メソッドとURIのパスを「:」で連結し、MD5ハッシュ値を求める
      • ③①、サーバーから得たnonce、クライアントかがnonceを送った回数、クライアントが生成したnonce、qopの値を「:」で連結し、MD5ハッシュ値を求める
        • リクエストのHTTPヘッダのresponseに③を入れて、再送信する
    • 利点

      • パスワードに関するセキュリティリスクを低減
        • パスワードを盗まれる危険性がない
        • パスワードそのものを預けなくてもよい、パスワードのハッシュ値を保管すだけ
    • 欠点

      • パスワード以外のセキュリティリスクは回避できない
        • パスワードのみを暗号化
        • メッセージ自体は平文でネットワーク上に流れる
      • クライアント側の負担が大きい
        • 同じURI空間でも毎回チャレンジして、ダイジェストを生成する必要がある
          (nonceを取得するため)
    • 普及していない理由

      • クライアント側の負担が大きい
      • ApacheなどのWEBサーバーではDigest認証がオプション扱い
      • ホスティングサービスではサポートされていない可能性が高い
      • 自前で用意する場合もセキュリティ上の問題でApacheがヘッダーを渡してくれないため、Digest認証を利用できない
  • WSSE

    • HTTP1.1の標準外の認証方式
    • AtomPubやWEBAPIの認証で利用
    • Basic認証やDigest認証が利用できない場合にパスワードをネットワーク上に 流さずに認証するために誕生
    • WS-SecurityのUsernameTokenがベース
    • 方式

      • クライアント側

        • クライアントが認証情報なしでリクエス
        • クライアントがリクエストを再送信
        • AuthorizationヘッダにWSSE、profileにサーバから受け取ったUsernameTokenを設定
        • X-WSSEにパスワードダイジェスト、nonce、日時情報を設定
      • サーバー側

        • サーバーが401 Unauthorizedを返却
        • WWW-Authenticateにprofileを設定(UsernameToken)
        • サーバーがクライアントのパスワードダイジェストと比較して認証
    • サーバー側でパスワードを保存する必要がある

    • パスワードがネットワーク上に流れることはない
    • Basic認証とDigest認証の中間

キャッシュ

  • サーバから取得したリソースをローカルストレージに蓄積し、再利用する手法
  • ローカルストレージにキャッシュしたデータそのものをキャッシュと呼ぶこともある

  • ヘッダ(サーバーへのアクセスをしない)

    • Pragma

      • キャッシュを抑制
      • 「no-cache」のみ指定可能
      • 指定された場合は必ずサーバーにアクセスする
      • キャッシュを抑制させない場合に指定(Cache-Controlにも指定)
    • Expires

      • キャッシュの有効期限を示す
      • クライアントが有効期限内からサーバーへのアクセスを行うか判断する
      • 最長1年を推奨
      • 有効期限が明確に決まっている場合に指定
    • Chache-Control

      • 詳細なキャッシュ方法を指定する
      • HTTP1.1で追加、Pragma、Expiresを代用可能
      • 相対的な有効期限設定が可能
      • 有効期限が相対的に指定したい場合に指定
  • 条件付きGET

    • サーバーに判断してもらう
    • クライアントではキャッシュ利用不可と判断された場合でもリクエストヘッダに情報を詰めて、キャッシュ利用可否をサーバーに判断してもらう

    • if-Modified-Since

      • リソースの更新日時を条件にする
    • if-Non-Match

      • リソースのEtagを条件にする
      • サーバーがEtagを出している場合に利用、正確な更新有無が判断可能
    • 静的ファイルの場合

      • Webサーバーで判断可能
      • inode番号、ファイルサイズ、更新日時から自動計算可能
    • 動的リソースの場合

      • アプリケーションで判断する
      • 生成したHTMLなどからEtagを算出
      • サイズが大きなリソースや複雑なクエリが発生する場合はメタデータで生成、リソースの更新カウンタから算出

持続的接続

  • HTTP1.1からの追加機能
  • 問題

    • リクエストレスポンスのたびにTCPコネクションの確立、切断を繰り返していた
       →処理が重くなっていた。画像や外部ファイルが多いWebページだととくに
  • 解決

    • 都度接続、切断を繰り返すのではなく、接続し続ける手法が開発
    • HTTP1.0ではオプション(keep-alive)
    • HTTP1.1ではデフォルト
    • パイプライン化
      • クライアントはサーバからのレスポンスを待たずに同じサーバーにリクエストを送信可能
    • コネクションを切断したい場合、(Connection:close)を指定

その他のHTTPヘッダ

  • Content-Disposition
    • サーバがクライアントにファイル名を提示
    • 電子メール仕様から伝承
    • 文字エンコーディングが必要

まとめ

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

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

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

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

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

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

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

【日経コンピュータ】アフラックの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ステータス編~名は体を表す~

HTTPステータスとは

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

ステータスコードの種類

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

ステータスコードの意味

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

エラー処理

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

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

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

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

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

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

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

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

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

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

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

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

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