• 2019/02/14(木)～02/15(金)、目黒で行われたDevelopers Summit 2019への参加レポート。
• CodeZineさんが発表資料をまとめてくれている > デブサミ2019、講演関連資料まとめ：CodeZine（コードジン）

2/14(木)

イノベーションを支えるアマゾン文化

• AWS 西谷 圭介さん
• Keisuke Nishitani(@Keisuke69)さん | Twitter

The culture of innovation

• ジェフ・ベゾス「イノベーションはクリエイティビティを開放する」
• Amazon: 地球上で最もお客様を大切にする企業であること
  • お客様の生活を楽にする

Our culture of Innovation

• Customer Obsession: お客様への執心
  • Always work BACKWORDS from the customer: 常にお客様を起点に行動する
• Long Term Thinking: 顧客重視と長期的視点
  • 1997年の株主へのレターで「お客様への徹底的なフォーカス」と「長期的視点での投資を継続」と言及
  • Amazon Flex: ライドシェアドライバーを集めるシェアリングサービス
• If you want to be inventive, you have to be willing to fail
  • Kindle: 初代Kindleは大抵の本より重くださかった
  • Amazonはさまざまな領域でイノベーションを起こし続けている
    • 配送センターのロボット、ドローン
    • Amazon Go
• You have to be willing to be misunderstood for a long time

イノベーションのための組織づくり

• メカニズム
  • Working Backwards – PR and FAQs
    • Press Release
      • 主題、副題、サマリ、課題、解決、引用、使い方、ユーザからの声の引用、次のアクション
      • PRがDecisionを後押しする
      • 内部で何度もレビューして成熟させていく
    • FAQ
      • 具体的なアイデアとデータを提供するFAQの準備
      • 顧客とステークホルダー両方のFAQを含める
      • 聞かれたら嫌なハードな質問を含める
      • 質問を集めるためにもPRは早めにシェアする
    • User Manual
    • The 5 Questions
      1. 顧客は誰か
      2. 顧客の機会・課題はなにか
      3. 最も顧客の利益に成るものは
      4. どう顧客のニーズやウォンツを知るのか
      5. UX
    • Visuals
      • ラフアイデア
    • (参考) 6 pager / 1 pager
      • アマゾンでは会議でのプレゼンテーションツールの利用はほとんどない
        • プレゼンは話し手の話術に依存する
        • 聞き手にとって捉え方が変わってしまう恐れがある
      • 会議は6 pager と呼ばれる形式のレポートで行われ、最初の数分は 6 pager を静かに読むことから始まる
• アーキテクチャー
  • Self-service Platform without Gatekeeper を重視
  • 2001年頃、アプリは巨大なモノリスだった。2001-2009からDvelopment transformation
  • マイクロサービス化
    • 単一目的のサービス
    • お互いブラックボックス
• カルチャー
  • 社員一人ひとりがリーダーであり、そう振る舞うことが求められる
  • Our Leadership Principles: https://www.amazon.jobs/principles
    • Customer Obsession
      • すべてお客様から
    • Ownership
      • 長期的な視野
      • DevOps: 開発・テスト・運用
        • テスト重視: Automate Everything! (テスト自動化、CI)
        • 運用重視: Automate Everything!
    • Dive Deep / Learn and Be Curious
      • Root cause analysis
      • 運用: 5whys
      • Brownbag session
    • Frugality
      • 倹約
      • お客様にとって重要でないことにはお金を使わない
      • 発明を育てる源
      • Door Desk: 社員のワークデスクはドア用の板に木の足を付けた簡素なものを利用 (創業時)
    • Think Big
      • お客様に貢献するために従来と異なる新たな視点を持つ
    • Bias for Action
      • スピード
      • やり直しのきくことも多い
      • 過剰な分析をやめる
    • Hire and Develop the Best
      • 高いバー
      • カルチャーフィット (LP)
      • メンタリング
      • ピアフィードバック
    • Have Backbone; Disagree and Commit
      • 経緯を持って異議
      • 安易に妥協しない
      • 決定には全面的コミット
    • Deliver Result
      • 結果を出す
      • あきらめない
    • …
• 組織
  • 2-Pizza Teams
    • チームを小さく
    • 作るものに対するすべてを負う
      • プロダクト計画の策定
      • 開発
      • 運用/カスタマーサポート
    • 大きな組織の一部
  • You build it, you run it. in 2006
  • QAはだれが？オンコールはだれが？ → Two-Pizza team
  • すべてはサービスチームに存在し、自身の役割に集中する
  • 高い水準を維持する
    • チームには権限が与えられ、多くの自由が認められている
    • オンボーディング/トレーニング
  • イテレーション
  • Minimum Viable Product
  • Everyday is still Day One
    • 毎日が最初の一日 (一歩)

GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローのOSS化

• Takafumi Ikedaさん
• Takafumi Ikeda(@ikeike443)さん | Twitter

• 発表資料: GitHub Actionsはどのような未来を描くのか – Speaker Deck

• 2008年にGithub社創業

• Pull Requestの登場。OSSから始まり大きなムーブメントとなった
• ソフトウェア開発にはさまざまな障壁がある
• 便利なツール・ライブラリ・テクノロジー・ベンダがたくさんあふれている
• Github Actionsでソフトウェア開発に関する課題を解決したい
  • ワークフローはモジュラー化されるべき → Github Actionsの誕生
  • コンテナをActionと呼ぶ
    • Actionの実態はDockerfile
  • ワークフローはHashicorp のHCLで記述可能。ビジュアルエディタもある。
    • 26のイベントに対応
      • Repository Dispatch: 外から任意にトリガーできるイベント。長いジョブなどを外部で実行、OKならこのイベントを発火、などの使い方が可能
      • gollum (wiki)
      • Vulnerability
      • Project関連
      • Issue / Label / Milestone 関連
      • その他
  • まとめ
    • コンテナ技術ベース
    • ワークフロー as Code
    • ワークフローのモジュラー化、再利用
    • Pull Requestに続く進化の触媒

現状の仕様、制限など

• 詳細はヘルプドキュメント参照
• ワークフローの実行時間はMAX 58分
• ワークフロー1つに付きアクションは100個まで呼び出し可能
• 1ファイル内に複数ワークフローを定義可能だが、並列実行されるのは1リポあたり2つまで
• アクションは他のワークフローをトリガーできない
• APIコールは1リポジトリあたりトータルで1000回/時間まで
• プロダクションのSecretを格納したないこと (ベータ中はログにそのまま出ます)
• ActionはDockerfileなのでDockerでできることはたいていできるが、制限あり
• Action実行環境について
  • 1vCPU、3.75GB RAM

デモ

• actions/example-aws： Example Workflow to deploy a static website to an existing Amazon EKS cluster

便利なActions

• 各種クラウドActions
  • GCP, AWS, Azure, Herokuに対応。
• https://github.com/actions/bin 以下に基本的なものを提供
  • bats
  • curl
  • debug
  • filter
  • sh
  • shellcheck
• HTTP client: HTTPiesラッパー。Marketplace で入手可能。
• Add an issue reference: ブランチ名からIssueを探し出してクロスリンク
• All in one project: Issue / PR を常に Project へ追加
• Delete Merged branch: マージ済みブランチ削除。Probot app / Actions どちらでも利用可能

リソース

• https://github.com/actions
• github marketplace
• https://github.com/sdras/awsome-actions
• community forum

参考

• GitHub Actions： みなさんが開発し、GitHubで実行 – The GitHub Blog – Japan

GCPに恋してHashiCorpを愛して起業したエンジニアのお話

• 長谷川 祐介さん

HahiCorp Stack

• HashiCorp Suite
  • Nomad
  • Vault、…
• Terraform: あらゆるパブリッククラウドやクラウドサービスのプロビジョニングをCode化
  • Enterprise版: TF構成ファイルのロールバックとバージョンコントロール、監査ログ、CIとの統合、チームマネジメント、TF Versionの管理簡易化、SentinelによるPolicy検証
  • Firewall
  • DNS
  • Load Balancer
  • いわゆる依存関係についてBackupと再現性も含め非常に便利
• Vault
  • Secure Secret Storage
  • Dynamic Secret
  • Data Encryption
  • Lease & Renewal
  • Revocation
  • Enterprise版: Read Replica, Performance
  • Grasysでの活用方法
    • GCPとAWSのLinuxUserのSSH Keyの共有と管理
• Consul
  • Service Discovery
  • Health Check
  • KVS
  • Configration consul-template連携
  • オーケストレーション
  • Grasysでの活用方法
    • システムセントラルとして利用
• Nomad
  • スケジューラ: K8sの薄いやつ
  • Grasysでは利用していない

システムに対する考え方

• 運用設計重視
• 継続的改善

上記の考え方なので、以下も大事

• 運用コスト削減
• 更新の容易さ
• 障害復旧性
• 安定性向上

Grasys Stack

• beatsを多用

GCPのススメ

• Global Launchが多い
• 更にNetwork要件が厳しいものが多い
• 世界中の場所を含めた通信事業者の品質
• 全部ひっくるめて管理することは不可能
• これらをすべてGoogleにおまかせ

起業について、大事なこと

• 何を守り、何を捨てるかを決め、よく考え、よく相談する
• 変化に対応する
• 金は道具、使い方を考える
• 自分のやりたいことを持ち続け、あきらめない
• 一人の時間は大切、いつでもいける自分が心地よい場所を作っておく
• ときどき振り返り、確認をする
• 迷ったときの嫁の言葉は強烈! 嫁は旦那の直感をよく知っている
• 欲は大切!
• 褒められたときは全力で喜べ!
• 恵比寿でIT社長やってももてない

Cloud Native時代における Docker / Kubernetes による開発

• 青山 真也さん
• MasayaAoyama（青山 真也）(@amsy810)さん | Twitter

• 発表資料: Cloud Native時代における Docker / Kubernetes による開発 developers Summit 2019 at 02/14 / devsumi2019_amsy810_k8s – Speaker Deck

• Cloud Native

  • 疎結合なシステム
  • 復元力がある
  • 管理しやすい
  • 可観測である
  • 堅牢な自動化により、頻繁かつ期待通りに最小限の労力で大きな変更が可能

• Cloud Native Ecosystem

  • k8sを中心としたOSS

• Cloud Nativeに適したアーキテクチャ? 大規模な開発に適したアーキテクチャ?

  • マイクロサービスアーキテクチャ
    • マイクロサービスごとに技術選定可能
    • 大規模な開発を加速させる
    • デプロイが容易
    • スケーリングが容易
    • 障害が全体に波及しづらい
  • 500+ microservices: 大規模なシステムのマイクロサービス間を可視化するとデス・スターのようになる。個別マイクロサービスの管理がつらくなっていく。
  • サービスメッシュアーキテクチャ
    • 従来アプリケーション側で制御していた機能を分離、開発者はアプリケーションロジックに集中可能
    • プロキシを必ず通るので、マイクロサービス間のモニタリングが可能
    • 他にも以下のようなことが実現可能
      • Traffic Shifting (ex: Canary release)
      • Circuit Break
      • Fault Injection
      • Rate Limit
      • Retry
      • mTLS
  • Container
    • System ContainerとApplication Containerがある。DockerはApplication Container。
    • コンテナで起動するプロセスは1つにする
    • 一時的なコンテナを作成するようにする (Immutable Insfrastructure)
    • VMに比べて
      • イメージ化が容易
      • 起動が拘束
      • オーバヘッドが少ない
      • 機能ごとに分離 (1機能 = 1プロセス)
  • 複数のコンテナの管理をどうするか: Container Orchestration Engine: k8s
    • 複数のDockerホストの管理
    • コンテナのスケジューリング
    • スケーリング/オートスケーリング
    • ローリングアップデート
    • コンテナの死活監視
    • 障害時のセルフヒーリング
    • サービスディスカバリ
    • ロードバランシング
    • データや機密情報の管理
  • CNCFとStandardization: k8sは完成度が高かったのと中立だったので流行った
  • Kubernetesがもたらすもの
    • Declarative Code and APIs
      • すべてYAMLで宣言的に記述してAPIに登録: Infrastructure as Code
    • Self Healing
      • ReplicaSetとSelf-Healing
        • ReplicaSetではコンテナのReplica数を維持し続ける
    • Automation & Immutable Infrastructure
      • ReplicaSetとRolling Update (Automation)
        • ロードバランサからの除外
        • コンテナイメージのアップデート
        • ロードバランサへの追加
  • k8sはフレームワークと分散システム
    • 分散システムとしてのk8s
      • Control Loop
        • 現在の状態を観測
        • 現在の状態と理想状態を比較
        • 差分に対処する処理を実施
    • Custom Resource Definition
      • AWS/GCP/Acureのマネージドサービスインスタンスの作成が可能
      • k8s上にNatsクラスタのQueueクラスタを展開可能
      • Controllerは、KubebuilderやOperator Frameworkなどにより比較的容易に作成可能
    • 拡張: Knative, Kubeflow, Operator Framework
  • CI/CD
    • GitOps
      • MasterやStagingなどのブランチごとに、コンテナレジストリとマニフェストレポジトリを用意
      • PRによる差分チェックが可能
  • イギリスの銀行 Monzo Bankでk8s + Linkerdを採用

APIを活用したフォントの使い方 ～MR（Mixed Reality）の実例紹介

• 相川 晴俊さん
• 堀尾 風仁さん

フォント紹介

• UD Font
  • 文字のかたちがわかりやすいことにこだわったフォント
• フォントのデザインは、手書きから始まる。65.2mmの方眼紙に1文字ずつ書いて、500文字くらい作る。一日20文字くらい。新人フォントデザイナーはこれから始めて3年くらい続ける。営業含め、入社時研修でやらされる。
• 「永」という文字をまず作る。「永」には書に必要な技法8種がすべて含まれているから。

フォント製品

• MORISAWA PASSPORT
  • 書籍、漫画、映画テロップ
  • 組込み用フォントライセンス
    • スマホ: AQUOS zero: 新ゴ
    • ゲーム: Shadowverse: 解ミン月
• Typesquare
  • サブセット配信: JavaScriptとフォントをTypesquareから配信
    • 必要な分だけ配信することでネットワークやサーバ負荷の軽減
  • Galaxy Mobile Japan公式サイトで採用
  • サムスン電子ジャパン
  • 必要なフォントを必要な文字だけAPIから取得する: パフォーマンス重視
• Webサイト以外でも使えないの？ (アプリ、ゲームなど)という欲がMRにつながっていく

MR

• Kobe Digital Labo

なぜ今、Font×MRに取り組んでいるか

• ポスト・スマホを考える
  • 紙 → PC → Mobile → ？
  • デジタルがディスプレイが解き放たれる未来
  • Mixed Reality
• 注目のMRデバイスはHololens
• 文字が圧倒的に見づらい
  • 透過型ディスプレイなのでアプリケーション起動場所によって背景が変わる
  • 視野角が狭い
• 共同研究テーマ
  • フォントの視認性とデザイン性
  • フォントの変化によって生じるUXの違い

事例

• 営業シーン: 購買体験
  • Display Assistant: 商品の説明をホログラム表示
  • 自転車を買いに行って、店員に説明されても、説明のパーツと実物がつながらない。パンフレットを渡されてもたいてい読まない
  • MRで現物の自転車に商品説明ホログラムをマッピング

• 広告デザイン業務: デザインツール

  • Creative Design X: 看板広告デザインの支援ツール
    • 広告パターンの切替
    • フォントの切替
    • 現地の雰囲気を感じながら、広告の検証が可能
    • 複数のHololensで視野共有: クライアントとデザイナーで同じ看板を見ながら議論が可能

• どのフォントが見やすいかユーザ調査(3種)。一般的にはスマートグラスで明朝体は字が潰れるので避けられる。

  • 見やすさ
    1. UD新ゴ (60%)
    2. 黎ミン (25%)
    3. メイリオ (15%)
  • どのフォントが好きか
    1. UD新ゴ (50%)
    2. 黎ミン (30%)
    3. メイリオ (20%)
  • 黎ミンは、ボールドにしたとき、横線も太くなる。(普通は横線は太くならない)
  • メイリオはゴシック体なのに見やすさ、好感度が低い

• ブランディングはフォントで決まる

MR開発

• Illustratorなどから画像出力 (書体データも)
• 画像を組み込み、Unity上で開発
• UWP出力し、Visual Studioでビルド

• Hololensへインストール

• 毎回illustratorを起動し、修正も大変だった→TypeSquare APIの利用

MR開発

• フォントにこだわると顧客の反応もよい
• 顧客満足度向上→案件化率UP
• エンジニアこそフォントにこだわれ

ヤフー株式会社におけるフロントエンドの取り組み

• 向井 咲人さん
• 森本 恭平さん

• 平山 涼也さん

• 発表資料: ヤフー株式会社におけるフロントエンドの取り組み #devsumi #devsumiB

• 参考資料: ヤフー株式会社におけるWebフロントエンドの技術選定 – Yahoo! JAPAN Tech Blog

メディアカンパニー

• 広告入稿管理のフロントエンド。
• Yahoo!ディスプレイアドネットワーク、スポンサードサーチ、Twitter広告を担当
• jQuery+PHPからReact + Redux + TypeScript + Node.jsのモダンなフロントエンドへ刷新中
  • その他、Redux-Form, Sass, Webpackなど
• 大規模開発の課題
  • 刷新を進めながらも、ビジネス要件の機能開発を進めなければならない
  • 並行して3～4個の機能開発が進む
  • コードレビューの時間が爆増
  • どんどん増えていく開発メンバー
  • コードの足並みが揃わない
• 課題への立ち向かい方
  • 規約の導入
    • LintやPrittierを導入し、コーディング規約を設けた
    • 上記でカバーできない部分のコーディングガイドをGitBookで作成
      • 規約追加時にはPRレビューを出すことで全員に見てもらえる
    • Dangerの導入: PRを出すときに行うことを自動化
      • レビューメンバーの自動アサインやラベル紐づけなど
    • TypeScriptの導入
      • 静的型付けによりｍコンパイル時にエラーが出る
      • 機能修正時に漏れがなく、バグを事前に防げている
  • Atomic Designの導入
    • コンポーネントの粒度を揃える
    • Atoms, Molecules, Organismsという共通言語を作る
    • レビューの際に指摘をしやすいように
  • コンポーネントガイドの導入
    • コンポーネントの見える化: Storybook、docz
    • 新規メンバーの再開発を防ぐ
    • コンポーネント有無の確認による既存メンバー、新規メンバーのコミュニケーションコスト削減
  • Redux層の分割
    • ファイル構成にre-ducksを採用
    • Reduxのデータ層にDomain層、UI層を設ける (App層も追加予定)
  • 日々素振りを続けて課題に挑む
    • この先、まだ未知な課題も出てくる。
    • 日々の素振りを続けて、課題に挑める状況を作り出す。
    • チーム勉強会などのインプット・アウトプットの習慣づけ

コマースカンパニー

• YahooショッピングではABテストを回しまくっている
• 企画 (1週間)→制作(1週間) → 開発 (2週間)
• 上記サイクルの並列度が高い。つらい。
• 工数削減したい
• UIをアップデートしやすくしたい
• UIパーツ集を社内限定でnpmパッケージを公開
• 完成したらどんな未来が待っているか
  • デザイナーが内政したUIパーツ集を使える
  • エンジニアも気軽にABテストのデザインが作れる
  • 簡単なデザインならモックすらいらない
  • デザイナーは「デザインリサーチ」に時間をかけられる
  • いい結果のデザインをパッケージに反映できる
  • 数字によって証明された室の高いデザインで全出面を統一できる
  • 作り途中なのでどこまで効果があるかは不明…

Webフロント技術室

• サービス区切りの組織→縦の組織
• その縦の組織に特化したほうが成長も早いし、効率も良い
• ただし、個別最適化されてしまう
  • リソースがないところは、モダン化されない可能性
  • 人材流動ができなくなる
  • エースが転職してナレッジが会社に残らない
  • ヤフーのWebフロントエンドが見えなくなる

• ある程度全社的な判断や横断的な視点の組織が必要となる

• どういうメンバーで挑むか

  • デザイナーとエンジニアの混合チーム
  • コマースチームとメディアチームの混合
• CTO直轄の組織なのでCTOとの距離が近い

半年間なにをやったか

• よく使われているライブラリの効率化
• 統一したパフォーマンスの計測方法の検討
• ヤフーのWebフロントエンドの健康状態の把握
  • 全サービスにFE環境を手入力してもらって情報収集
  • 統一感がないことを状況把握できた
• 適切な技術選定とその技術の浸透
  • 全社視点での技術選定
  • なぜフレームワークではないか
    • JSｈあエンジニア・デザイナー両方書く
    • React+Reduxなどを実装できない可能性がある
    • リソースもまちまちなのに、突発的なリニューアルを余儀なくされる可能性がある
    • リリースがある場合など、ビジネスを止めることに成る
    • 現状バラバラすぎる
    • フレームワークの統一は現実的ではなかった
  • スタイルを選ばなかった理由
    • CSS in JS系はチームによっては効率が悪い場合がある
    • エンジニア+デザイナー混合のため
    • Webpack周りの設定など苦しみを生むくらいならPostCSSである必要もない
    • Gulp+Sassはアクではない
  • 影響を抑えられ、全社にメリットのある技術: TypeScript
    • MS製。2017年からGoogleの標準に。
    • 特徴
      • 静的型付け
        • 大きなバグを防げる
        • IDEとの連携によるリアルタイムチェック
      • JSとの互換性
        • JSｔお互換性
  • TypeScript布教にあたっての課題
    • スキルの差の問題
    • 始める苦しみをいかにして取り除くか
    • ドキュメントの整備
    • サポート体制の構築

【第2部ハンズオン】GCPをさわりまくれ！スペシャリストに聞きまくれ！大QWIKLABS大会

• 無料のQiklabsクレジットが配られて、GCPクエストを自習
• 電源あり、wifiあり環境。お菓子がいっぱい出た。
• GCPのソリューションアーキテクトっぽい人がいっぱいいて、質問し放題だった。(が、するようなつまづき方はしなかった)

2/15(金)

ドラゴンクエストXを支える失敗事例

• 青山 公士さん
  • ドラゴンクエストXを支える技術の著者
  • ドラゴンクエストXオンラインプロデューサ (責任者)
  • キングボンビーの生みの親というか、プログラマー
    • あくまで生みの親はさくまあきらさん
• オンラインサービス (オンラインゲーム) はリリース後の運用・運営が本番
  • リリースは完了ではない。オフラインゲームはリリースで完了、手を加えられないのであきらめも付く。
  • お客様からのフィードバックが対応の始まり
  • 良い設計・実装: 要望への対応が柔軟、不具合が出づらい、不具合が出ても修正しやすい
  • 重要なのは運営・運用経験
  • 他者の事例を共有することは重要

ドラクエXとは

• オンラインゲーム
• 6年半くらい経つ
• MMORPG: 大規模多人数参加型オンラインゲーム
• 構成
  • クライアント: 見た目上の本体
    • バリデーションロジックくらいを置く
  • ゲームサーバ: 真の本体
    • ゲームロジックは勝手にいじられないように、サーバ上で処理
  • ゲームDB: 世界のデータ

開発ポリシー

• 開発初期から運営・運用が重要という想定

  • 運営: 仕掛け(攻め) → 柔軟性が重要
    • 機能拡張、期間限定イベント
  • 運用: 保守 (守り) → 継続性が重要
    • 不具合修正・障害対応

• 例えば、ロジックは一箇所に集約すべし、など

失敗事例 (3つ)

キラージャグリングの音が鳴り続ける

• 不具合の内容
  • ある更新から突然演出完了後も効果音が止まらずになり続ける
• 原因と対応
  • エフェクトは視覚効果を演出する
  • ドラクエでは表示形状、速度、加速度など、各種パラメータが設定されたデータドリブンで開発
  • アクション音やヒット音はデザイナー作成のデータで指定されたタイミングでC++が実行される
  • アクション効果音の停止処理のあとに、ヒット音を鳴らす処理
  • ヒット時とミス時の前段で停止処理がある
  • ミス時に効果音を停止する改修を実施したら不具合が発生
  • ミス時の効果音停止をC++で無効化したのが原因
  • 他にも同様の問題があるかも: ミス時は個別対応でFIX
• 得られた教訓
  • システム改修はBTSチケット(Redmine)に影響範囲を明記し、全影響範囲を再検証すべし
  • 影響範囲は極力せまくすべし

邪神の宮殿にてパーティが組めない

• 不具合の内容
  • 同盟: オートマッチング
  • 6/10(土) 6:00の更新以降、参加希望者が多数いてもマッチングが成立しない場合がある
  • マッチングに参加できる条件が設定されている
• 原因と対応
  • 条件はプランナー作成のデータで設定される
    • 問題になりそうなデータはなかった
  • 暫定べた書きしたものを本格対応の更新し忘れ、1年後に発火してしまった
  • プログラム (雰囲気こんな感じ)

1
2
3

if (6/10(土) 6:00以降 && ある獄) {
  マッチング処理
}

• 得られた教訓
  • 暫定対応は本格対応まで完了し、BTSシステムで管理すべし

釣り老師に話すと、ビッグサイズやキングサイズなのにノーマルサイズと判定される

• 不具合の内容
  • 魚には大きさがある
  • オウムガイも釣れる
  • 魚を釣ったあと釣り老師に話すとサイズに見合った報酬をもらえる
• 原因と対応
  • 大きさとサイズの分類は魚ごとに設定
  • オウムガイは1023mm以上がビッグ、それ未満がノーマル
  • C++ではmm単位の情報をintで扱い、Luaではmおよびmmをdoubleで扱う: 浮動小数点の丸め処理の誤差
  • 誤差補正処理は入っていた
    • 補正処理が不十分だった
  • 行動ログから全戻しした
• 得られた教訓
  • 表面化していない不具合は存在する前提で対応すべし

振り返り

• リリース後の改修は要注意
  • 影響範囲を考慮
  • BTSチケットに登録
  • 確実にチケットクローズするまで
  • ドラクエX開発チームは運営中に出た問題に対して、「どうすれば事前に防げたか」を検討しパターン別にまとめている
  • BTSチケットに登録していないパターンが一番多い: 開発担当者が軽く考える案件が問題になりやすい
    • 10万くらいチケットがある (タスクチケット含む)
    • 以前のBTSにも10万くらいあったので、計20万チケットくらい

Q&A

Q: 開発体制・人数は？

A: 秘密(人事から止められている)。スタッフロールから想像して。

Q: 修正の影響範囲の特定の仕方は？

A: あまりよくない答えだが、個別・経験値に依存している。

Q: チケット登録がなかなか浸透しない理由は？

A: 開発者がチケット登録するまでもないと思っちゃう。リファクタリングのつもりで軽く対応しちゃうときにバグが埋め込まれてしまう。油断、おごりがある。

Q: 運用以降が本番、というところのモチベーション維持に関しては？

A: 実際、飽きたと言って抜けちゃう人もいる。チーム内で異動させたりする。

IBM Q – 量子コンピューターの最前線

• 小野寺 民也さん

• そもそも量子とは

  • とても小さな世界
  • 物理法則 (ニュートン力学)では表すことができない
  • 量子と波の性質を併せ持つ
  • 量子重ね合わせ
  • 量子もつれ
• CRDS-FY2019-SP-04, みんなの量子コンピュータ: （戦略プロポーザル）みんなの量子コンピューター　～情報・数理・電子工学と拓く新しい量子アプリ～／CRDS-FY2018-SP-04 の図2.2 量子ビット実現手法の比較
  • 超電導回路
  • イオントラップ
• 量子プログラミング: 量子回路を組立てていくこと
• Exponential growth (指数的増大): 2ⁿ
  • 2²⁷ ～ 世界一のスパコン(IBM) 1億4千万並列 ～ 2²⁸
• 万能量子コンピュータ
  • IBM Q Experience
  • 現状、小規模
  • 近似 (Noisy)
  • 5量子ビット～20量子ビットが現状の量子コンピュータ
  • 量子状態を保つ時間も短いので、量子計算をその時間内に納めなければならないという制約がある
• 有望なアプリケーション領域
  • 量子化学
  • 機械学習
  • 最適化
• IBM Q
  • IBM Qシステム
  • QISKitオープンソースSDK
    • Qiskit Aqua | Algorithms for near-term quantum applications
  • IBM Qネットワーク
• CES2019にも出展: The World’s First Integrated Quantum Computing System – YouTube
• 量子力学だけでなく、冷凍機、Microwave工学などの周辺技術も大切。

参考

• IBM Quantum Computing で計算してみよう

午後は打ち合わせがあったので午前中までの参加だった。