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

日経コンピュータ日経コンピュータ-2020.7.23号電子契約サービス

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

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

挑戦者
経歴
新型コロナ禍で注目される電子契約サービス
商業・法人登記での認可が普及が加速
普及を阻む2つの壁
- 法律の壁
  - 20年改正されていない電子署名法
  - 導入企業の法務部からストップがかかる事例
- 商習慣の壁
  - 根付いていたハンコ文化
  - 導入企業の周りへの理解
乗り越えた壁
- 弁護士の強みを活かした説明
- 結果
今後の展望と想い
- 生活をより便利なものへしていきたい
- 日本発のサービスを世界へ輸出

挑戦者

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

経歴

東京大学法科大学院修了
サイバーエージェント社内弁護士
GVA法律事務所
弁護士ドットコム

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

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

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

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

クラウドサイン8万社の利用実績をもとに電子契約にまつわる規制緩和を訴求
商業・法人登記における規制緩和を強く要望

2020年6月に認可

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

期待する効果

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

普及を阻む2つの壁

法律の壁

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

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

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

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

商習慣の壁

根付いていたハンコ文化

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

導入企業の周りへの理解

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

乗り越えた壁

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

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

結果

ベンチャー企業を中心に利用企業を拡大
野村証券、サントリーホールディングスなどの大手企業も導入

今後の展望と想い

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

個人への普及がカギ

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

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

2020-08-20

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

日経コンピュータ日経コンピュータ-2020.7.23号 SIer アジャイル開発

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

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

2020年6月富士通が米スケールド・アジャイルとパートナー契約を締結
SAFeとパートナー契約した富士通の狙い
資格保持者を増やし、導入支援を拡大へ

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

スケールド・アジャイルフレームワーク（SAFe）の開発元
大規模システム開発向けアジャイルフレームワーク
世界的に普及しているフレームワークの1つ
経営や事業変革によって、経営スピードの向上が主眼
企画、業務部門、IT部門が協力してアジャイル開発を進める方式

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

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

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

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

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

先行するNTTデータ

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

さらに先行している北米

2017年ごろからアジャイルフレームワークが浸透
これまでに日本ではアジャイル開発は浸透してきた
今後は経営スピード向上を目指すアジャイル手法が普及する見込み

2020-08-20

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

日経コンピュータ日経コンピュータ-2020.7.23号認証サービス

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

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

社印（角印）とは
必要となる法整備
- 既に実用化しているEU
- 日本での法整備
eシール事業進出を発表した2つの事業者
- GMOグローバルサイン
- 帝国データバンク
自治体も動き出した
- 2020年7月に福岡県飯塚市が実証事業を2021年に実施することを発表
  - 住民が遠隔地から各種証明書をスマホアプリで受け取れるサービス
  - 期待するサービスの効果

社印（角印）とは

概要

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

社印（角印）の欠点

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

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

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

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

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

必要となる法整備

既に実用化しているEU

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

日本での法整備

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

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

GMOグローバルサイン

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

帝国データバンク

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

自治体も動き出した

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

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

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

期待するサービスの効果

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

2020-08-11

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

WEBを支える技術

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

作者:山本陽平
技術評論社

Amazon

HTTPヘッダの重要性
HTTPヘッダの生い立ち
日時
MIMEメディアタイプ
言語タグ
コンテントネゴシエーション
Content-Lengthとチャンク転送
認証
キャッシュ
持続的接続
その他のHTTPヘッダ
まとめ

HTTPヘッダの重要性

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

HTTPヘッダの生い立ち

HTTP1.0から登場
電子メールのメッセージ仕様のヘッダ形式をもとに追加
→　インターネットの成長とともに規定された歴史
HTTP1.0から登場ヘッダと電子メールのメッセージヘッダと共通部分が多い
例）Content-Type、Dateなど
歴史からくる制約、バッドノウハウも多い
- メール：7bit ASCIIコード以外の文字が入れられない
- HTTP：文字エンコーディングの制限でラテンアルファベット以外い入れられない
電子メールとの違い
- メール
  - 1方向にしかメッセージのやり取りができない
- HTTP
  - 一度の通信でリクエスト/レスポンスの2つのメッセージをやりとり

日時

DateやExpiresが該当
HTTPではすべてグリニッジ標準時で表現　→　サマータイムなどに対応
メールではタイムゾーン付きの書式を許可

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通信（SSL、TLS）で暗号化するなどの検討が必要
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
- サーバがクライアントにファイル名を提示
- 電子メール仕様から伝承
- 文字エンコーディングが必要

まとめ

HTTPヘッダはメソッドやステータスコードと組み合わせて認証やキャッシュなどのHTTPの重要な機能を実装
電子メールや文字エンコーディングは深い歴史があり、バッドノウハウを引き継いでいる。
HTTPヘッダをうまく利用するためにサーバやブラウザだけでなく、電子メールや文字エンコーディングの歴史も調査する必要がある

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

作者:山本陽平
技術評論社

Amazon

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

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

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

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

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

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

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

2020-07-17

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

日経コンピュータ-2020.7.9号アジャイル開発金融（Fintech）

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

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

ロボット活用における分身出社
- 2019年秋　分身ロボット「OriHime」を導入
  - 「OriHime」とは
  - 活用方法
- テレプレゼンスロボット「temi」で日常業務でも導入
成果をもたらすアジャイル開発体制
- 経営環境の変化を察知
- アジャイル開発体制
  - 3つの組織体制
  - 意思決定の権限委譲

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

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部門メンバーを選抜
トライブ
- スクワッドを管理
- スクワッド間の取り組みの方向性の調整