Developers Summit 2020 Summer : メモ

その後のソフトウェア・ファースト

• ソフトウェア・ファーストで伝えたかったこと
  • どのような事業であっても、ソフトウェアをどう使うか、が重要
    • ソフトウェアが一番偉いというわけではない
    • ソフトウェアの比重が1%であったとしても、その1%をどう生かすか
• 欲しいものに対して、自分たちの収益を重視してしまう人もいる
  • 顧客が戦っているのは競合他社、世界が見えておらずすぐに海外の後発に負けてしまうかも
  • 真の意味での価値提供が必要
  • 自社が儲かるから、世界が儲かるへ、視座を上げる
• ソフトウェアに対する考え方
  • 米国はビジネス、欧州は科学、日本は製造業として捉えている
• ソフトウェア・ファーストというのは海外では当たり前。やっとスタート地点に
  • ソフトウェア開発からプロダクト開発へ

GCP を支える Google のソフトウェア開発環境に見るマイクロサービス設計のヒント

• マイクロサービスは知見を持った上で実装しないと困難。ここでは、その知見を共有
  • SRE：クラウドインフラの知見を持ってシステム運用の方法論を提供
  • マイクロサービス・アーキテクト：アプリケーションデザインの知見を持ってマイクロサービスを設計
• マイクロサービスが必要な理由
  • システムアーキテクチャ：設計者がシステムに与えた物理的・論理的な形状
    • 現代のソフトウェアシステムは要求される動作が日々変化する
    • 変化に追従することが困難
  • システムアーキテクチャの目的：ソフトウェア開発者・システム運用者の生産性を最大化すること
    • システムを提供する人を助けることが重要
  • マイクロサービスで生産性がなぜあがるか？それ以外ではだめか？
    • 開発者の認知能力を超えた連鎖的更新が防止できる（容易に理解できるほど変更の生産性が高まる）
    • マイクロサービスに固有のメリット
      • 技術異質性：マイクロサービスごとに異なる技術を適用できる
      • 部分的スケーラビリティ：必要なマイクロサービスだけスケーラビリティ可能
      • 耐障害性：ひとつのサービスが停止してしまっても、他のサービスは停止しない
      • デプロイ容易性：サービス単位でカナリアリリース、ブルー・グリーンデプロイメントできる
• 標準化されたツール・プロセス
  • 単一リポジトリによるソースコード管理
    • ブランチも持たない
  • コードレビューはGerritに似た独自システムで実施
    • 軽量なレビュープロセスで実施。一回の変更（チェンジリスト、CL）はかなり小さい
  • デプロイ時にはCL単位でリリース・ロールバックが原則
  • アプリケーションフレームワークがあり、監視などの機能を実現できるテンプレートが存在する

週一でリリースし続けるための、フロントエンドにおける不確実性との戦い方

• MVP＝スピード、しかし求められているものって何かが曖昧になりがち
  • 何を作って何を提供する予定なのか一旦整理
  • どんなものを作るのか、チーム共通の言語をつくる
  • 優先度はどうする？安全性、将来性とスピード
• 開発はモブプロで行う
  • 個人に知識が張り付くのを避ける
• 開発を進めると認識が次第にずれていく
  • リカバリーが効くタイミングでのユースケースの確認が必要
• ユースケース駆動で進める
  • BFF（Backend For Frontend）/ GraphQL
• スピード感を保ちながら変更容易性を持つには
  • ユースケースを中心に据える
  • 依存の方向は必ず上位レベルにのみ向かう
    • ユースケースは外のレイヤーに依存させない
    • アダプター（ユースケースとインフラストラクチャをつなぐ層）はユースケースに依存
      • コンストラクタでDIする
    • インフラストラクチャは知識を持たせない
• ブラウザの例外をハンドリング
  • ランタイムエラーは必ずつぶすべき
  • DOMExeptionは都度判断を入れること
  • ネットワークの不通はほとんど看過してよい
  • SecurityError：Cookieがブロックされている場合に起きえるので、UIに表示してあげるべき
  • window.openはabuseされるユースケースが多い（広告を開くのに悪用されがちなので）
  • 非同期でwindow.openすると、ポップアップブロックされる
• GraphQL Errorの活用
  • resolverに例外送出を集中させた

Androidスマホの生体認証の脆弱性、調べてみたらよくある話だった。

• 脆弱性はいろんなところに潜んでいる
  • CPU、デバイスドライバー、OS、コード、…
  • 今回紹介するには、CVE-2020-7958
    • rootユーザーが指紋センサーから指紋のビットマップデータを取得可能
    • 本来はREE（Rich Extention Environment）によって守られている
    • デバッグコードが残っていたためにできてしまった
• ARM社のCPUは実行環境が分かれている
  • 保護されたセキュアな実行環境「Secure World」
  • 保護されない実行環境「Normal World」
  • Android OSはBL3で起動される
• OnePlus 7 Proのアーキテクチャではroot化するとアクセス範囲が広がるが、それでも保護されるはずであった
• リバースエンジニアリングで脆弱性を探す
  • 試行錯誤の結果、指紋データをやり取りしているバッファを書き換えることで起動するコマンドを変更することが可能であることが判明
  • HALを使用、ベンダーごとに異なる
  • 繰り返しリバースエンジニアリングを実行、疑似コードを生成。
• 指紋認証の試験用のコードを埋め込まないと正常に動作しているか判断できない、それが残ったのが良くなかった

モダンなアーキテクチャでゼロから作る証券基盤

• 証券プラットフォーム「BaaS（Brokerage as a Service）」を使うと多大な初期コストをかけずに金融事業を始められる
• 金融系特有の難しさ
  • 機能ごとにセキュリティ・可用性・パフォーマンスが異なる
  • 市場の開いている時間は限られているのでそれに合わせたコスト最適化
• バッチ処理によるエラーのハンドリング、トランザクションはかなり難度が高い

コンテナベースの開発パイプラインへ“セキュリティ”を実装してみよう

• コンテナを利用するメリット
  • 依存関係による問題の削減
  • 自動化テストの適用のしやすさ　等
• DevOpsとコンテナ
  • DevOps：開発から運用までのプロセスにおいて無駄を排除したり効率化したりする活動
  • コンテナを使えばカナリアリリースも簡単に
• コンテナ環境とセキュリティ
  • カーネルを共有して使う
  • コンテナのスケールアウト・スケールインをしたときにどれが対象になるかは自動で選抜される
  • コンテナの実行環境の構成にも注意が必要
  • Dockerfileにパスワードを入れた場合覗き見られたり、ファイルのコピー・削除をしても実は残っていたりするので注意が必要
• どうやってセキュアにするか
  • 利用しているツール：GitHub, CircleCI, JFrog Artifactory, JFrog Xray, Twistlock
  • なるべくDev（開発）に近いところでセキュリティを担保
  • セキュリティ診断を自動化する
  • 開発：野良イメージ、野良アプリは利用しない
  • 運用：デプロイ前にチェック、登録済みのレジストリ・リポジトリからのみダウンロード許可、問題を検知したら自動でブロック、問題を検知したコンテナを削除

プロダクト作りのトランスフォーメーション

• この半年で変わったものと変わらないもの
  • リモートワークへの切替、パフォーマンスは？
    • ただし、パフォーマンスが下がっているからと言って責めるべきではない
    • 計測方法としては開発タスクのリードタイムを調査
      • 4/9時点ではほぼ変わらず
      • 5/25時点でもほぼ変わらず
      • 7/3時点でもさほど悪化しておらず
      • ただし、当然育児との両立などで負担の人にはケア
      • 在宅勤務でパフォーマンスが変わらないように頑張りすぎてないか？は不安
  • リモートワークの問題
    • 気軽に雑談できない
      • Discordなどを取り入れて機会を増やしたり
      • ワーキングアグリーメントの導入
        • チームの暗黙的な約束事を明文化
        • ワーキングアグリーメントはスプリントごとに見直し
        • なぜ重要？
          • 個人に裁量が与えられ、成果主義的に
          • チームとしての約束事は守ってほしい
  • パフォーマンスは変わらない
  • チームの取り組みは変わった。日々、新しいチャレンジができるように取り入れられる仕組みがあると良い
• 不確実性の高い世界のなかで、非連続な成長を生み出す-プレイド開発チームのチーム・ジャーニー
  • 2/25 感染リスクからフルリモート　7月にフルリモート解除
  • 開発チームに大きな混乱なく変化に対して一定の適応
    • サポートする制度が生まれたり、余裕のある人がサポートに回ってくれたり
    • トライ&エラーが大事
    • Whyを主体的に考えられる人を少しずつ増やす
• トランスフォーメーション・ジャーニー - 逆境を乗り越えるプロダクト開発
  • プロダクト開発で立ちふさがるもの
    • 不確実性：事実との分断
    • 逆境：未来との分断
    • 断絶：理解との分断
  • 「整っている状態」からはじまることはない、「混沌」から始まる
  • 背負わなければならないものが多くある
  • リモートワークだと対話が始まりにくい、会話を始めるコストが高くなってしまいがち。さらに分からない相手には何を任せて良いかが判断できない。
  • 上記の問題を抜け出すには「仮説と約束」を置くこと。「共通の認識」をそろえることが大事。
  • プロダクト開発で立ちふさがるものに立ち向かう術
    • 不確実性：探索と学習
    • 逆境：段階と向き直り
    • 断絶：対話と再定義