Logic Delight

明日のワシは忘れてしまうから、コードにはコメントを書くのです。

GitHub Japan Constellation Tokyo 2018 〜Day 2 Developers in Business〜

2018/06/13 (水)
9:00 - 17:00 JST

公式サイト:https://githubsatellite.com/
参加申し込み:https://peatix.com/event/366939
ライブストリーミングhttps://githubsatellite.com/live-stream/
Twitter HashTag: #GitHubSatelliteTokyo

体調崩したり、ドタバタしていてUPが遅くなってしまい、鮮度も何もあったもんじゃないですが、記録残しておきますー

基調講演:GitHub Enterpriseプロダクトビジョン

公家 尊裕 (GitHub) ジェイソン・ワーナー (GitHub)

(冒頭はDay1と同じ話)

Tokyo向けに作ったロゴ。富士山、東京タワー、桜。桜はブランチを表現。

f:id:shiopu:20180620083518p:plain

GitHub上の成長率

  • 中国・インドと並んで、日本はTop Growing Countryのひとつ

日本国内IoT市場

  • 2017年:6.2兆円
  • 電力はスマートメーターへの切り替えが行われている
    • 電力自由化後に電気会社を切り替えると、そのタイミングで機器交換される
  • エネルギーの利用状況から、生活上の利用傾向分析・推測ができる
    • 集めたデータをどう解析して、どんなサービスに還元していくか、がビジネスの勝利につながる
  • 2022年:12.5兆円(IDCの予測)
    • 2017-2022:14.9% CAGR

日本国内コグニティブ/AIシステム市場

  • 2017年:274億円
  • 2022年:2947億円(IDC予想)
    • 2017-2022:60.7% CAGR
  • ソフトウェアの勝負
    • 欧米では開発者の奪い合い
      • 自動的にエンジニアの給料も上がる(お約束はしませんが)笑

2030年 IT人材不足

  • 79万人(経済産業省
    • 毎年、4〜5万人が不足する計算
  • これから若者を育て続けても、間に合う気がしない
    1. 頑張る?(残業する?)→ 事実上無理
    2. ツールを使って効率的に開発を進める
    3. 世界中の色んなエンジニアを集めて、グローバルなチームを作る
    4. 上記、2. 3. のMix
  • GitHubは、4.のアプローチを取っている
    • GitHubは、人の可能性を信じている
    • いろいろな人々が融合することで実現できると信じている
    • これは、オープンソースの世界ではこれまでも起きていたこと

GitHub Enterprise

  • 日本の企業ユーザの95%が、Enterpriseを利用
    • (ここで弊社ロゴ・キター!!)

f:id:shiopu:20180620083601p:plain

ジェイソン・ワーナー

f:id:shiopu:20180620083707p:plain

Every company is an innovation company

  • not software company
  • 単なるソフトウェア会社ではイノベーションは起こせない
  • 優秀なソフトウェア会社とは?
  • 難しい課題のバランスが取れる会社
    • セキュリティ
    • スケール
    • アダプション
    • インテグレーション

GitHubの責任

コード革命 → クラウド2.0革命

f:id:shiopu:20180620083738p:plain

  • Pull Request
  • ネットワークエフェクト
    • GitHubは統合の支援、ワークフローの管理も支援できる

GitHubがお手伝いできること

  • テクノロジーを組織の中でデプロイしやすくする
  • 最高の人材を集める

ウェイン・ジン

f:id:shiopu:20180620083803p:plain

これから我々がやってくことの紹介

  • 4つの投資エリア
    • プラットフォーム
    • データ
      • いかにセキュリティを確保するか
    • エコシステム
      • いかに拡張していくか
    • 開発者

プラットフォーム

  • 開発者がコードを作ることだけに注力できるようなプラットフォームを用意する
  • オンプレミス(Enterprise)でも、クラウド(GitHub.com)でも
    • オンプレだとOSSの恩恵が享受できないのが現状
    • オンプレとクラウドを相互に連携する機能が今後出てくる

データ

  • プライバシーやセキュリティは重要事項
  • 「依存関係管理を自動化する企業は、市内企業に比べて、60%も脆弱性のリスクが低くなる。」
  • 機械学習を利用した機能で、これを実現する予定

エコシステム

開発者

  • GitHubは開発者のためのサービスである
  • 開発者の生産性を最大限にする
    • ダッシュボード
      • 開発者が毎朝確認するような
    • エクスペリエンス
    • プロファイル
      • 開発者がどんな経歴があり、どんなスキルセットがあるかが見えるように

所感

出だし基調講演はDay1と同じ内容なのかとゲンナリしかけたが、エンタープライズ向けのビジョンや機能の表明により、日本国内は特にGHE比率が高いこともあり、より一層力を入れていくことが感じられた。

ゲスト基調講演:DMM.comGitHub EnterpriseとCircleCI の活用方法

唐沢 陽介 (株式会社DMM.comラボ)

少ない人員でどうやって生産性を確保しているか?を紹介する。

GHEの構築から運用まで関わっている

  • CircleCIの導入・サポートも
    • CircleCI1.0を2.0への移行支援

今日話すこと

  • (表題)のこと
  • GHE導入して1年経って思うこと

GHEの活用状況

  • 40くらいの提供サービスのうち、比較的新し目のサービスでGHEの採用が進んでいる
  • ほかは、AtlassianのBitbucket(クラウド版)を使っている
  • なぜミックス?
    • 環境改善チームでBitbucketを試験運用していたら、どんどん現場が相乗りしてきた
    • みんな本当はGitHubを使いたかった
    • 本気でGHEを導入する検討を始めた
  • 4つのサービスが稼働中
    • GHE
    • CircleCI
    • ZenHub Enterprise
    • SideCIオンプレミス

f:id:shiopu:20180620083858p:plain

  • サービスはすべてAWS上に構築
    • AWS推奨のサービスが多いため
    • 開発環境と本番環境でリージョンを分けている
  • 運用ルール
    • GHEへのアクセスはFWで事業所とサービスからに制限
    • リポジトリはPublic推奨
    • ユーザとOrg作成は自由(要申請)

社内でおすすめしている利用パターン

  • Gitのブランチモデル
    • 基本は自由だが、相談が来たらシンプルな2つを紹介する
    • Git Flow(簡易版)
      • feature / develop / master だけ
    • GitHub Flow
      • master ブランチへのマージは検証環境へデプロイ
      • Tagを打つと、本番環境へデプロイ
  • CircleCIのうまい使い方
    • ビルド+インスペクション+デプロイを実施している
    • 素早いフィードバックを得るために
      • Docker Executorをつかう
        • Dockerベースのビルド
        • 高速
        • スケールアウトが容易
          • Docker Executorしていると自動で並列にスケールする
        • ローカル開発環境のcliツールが使える
          • ローカル環境のDocker上で、CircleCIでのビルドをシミュレートできる
        • DockerHub以外もOK
      • Cacheを使う
        • ダウンロードしたファイルはキャッシュする
        • ビルドに必要なライブラリをダウンロードするが、毎回ダウンロードではなく、次回以降は使い回す
        • save_cache:restore_cache:
      • Worlflowを使う
        • 自動テストと静的解析を並列化する
          • テストは全部やるが、静的解析は一部(別条件)など
      • Machine Executorは非推奨としている
        • オンプレ版だと非推奨としている
        • ビルドのたびに裏でEC2インスタンスが立ち上がる
          • 2分以上必ず待たされる、遅い
          • 起動数の変更にサービスの再起動が必要で運用が難しい
  • CircleCIですばやくフィードバックループを回す
    • 速度を意識していないとすぐに遅くなる
    • 少しの工夫で高速化できる
  • 困ったらGHEで検索する
    • jobs ruby filename:config.yml で言語ごとのビルドジョブ定義を社内で探してベストプラクティスを横展開できる
  • ドキュメントはGitHub Pagesで
    • GHE → CircleCIビルド → GitHub Pages
  • ZenHub Enterpriseで進捗の可視化
    • GitHubの中だけで開発業務が回るようになった

導入して1年

  • 新規サービスではGHEとCircleCIの採用が進む
    • 利用者はサーバやユーザ管理が不要で、すぐにCIを始められる
    • .circleci/config.yml でアプリケーションの動作要件が分かる
  • 既存プロジェクトも移行できるところから移行
  • 悩んでいること
    • GitHubっぽいソーシャルコーディング感が出ない
      • 扱っている言語、環境、ゴールがチームごとに全然違う
    • Organizationがいっぱいできてしまった
      • プロダクト単位でOrgが作られている
      • 現在80個くらいある
      • 他のOrgで何をやっているか目に入らない弊害
  • 対策として個人的にやっていること
    • 良いリポジトリを見つけたらスターを付ける
    • 少しずつ、この文化が広がってくれれば良い

所感

DockerコンテナベースのCIツールとの連携など、弊社と似たステージにいる認識。すべての既存プロダクトを移行できていなかったり、諸々の課題についても似てより、参考にできるところは取り入れていきたい、リザーブインスタンスとか。。。

ゲスト基調講演/パネルディスカッション:ソフトウェア開発の変遷と、これから

モデレーター 及川 卓也 (フリーランス技術アドバイザー) 大倉 香織 (株式会社サイバーエージェント) 小林 篤 (株式会社ディー・エヌ・エー) 松野 徳大 (LINE株式会社)

GitHubの10年を踏まえ、今後の10年をうらなう

軸となるテーマ

  • 一番進化を感じる技術は?
  • 事前に登場や進化を予測していなかった技術は?
  • 逆に期待はずれだった技術は?

f:id:shiopu:20180620083929p:plain

及川:Git前とGit後で社内の開発は変わったか?
小林:開発者間のコミュニケーションが多くなった
松野:手元で1回コミットしておけるので、途中の作業を保存しやすくなった。途中からカフェに移動して作業したり、とか。メンバーも分散して作業できるのが嬉しい。
及川:コミュニケーションでいうと、SlackとGitHubをペアで使っているところが多い?
大倉:GitHubを先に入れたが、Slackに更新を通知させたりして現在は活用している
小林:Chatbotとして「安藤さん」を作って利用している(記事あり)
及川:言語のトレンドとして何が増えて何が減った?
松野:perlとJavaで開発していた会社が一緒になったのだが、最近はJavaが主流。PythonとJavascriptも増えてきた。Swift/Kotlinもスマホ向けに利用している。
小林:Rubyやgo-lang。最近だとJavaが増えてきている。
及川:最近、Javaが増えた、というのは面白いがなぜ?
小林:人が増えてくるにつれて、新しい人も理解しやすい意味で、型があったり、キッチリした言語にしようか、という話が出てきた。
大倉:ここ最近はgoが多いが、従来はJavaが多かった。
及川:言語採用はどうしている?
松野:若い人はperlをあまり知らないので、採用が難しくなる。最近は採用しやすい言語を使うよう考えている
小林:最近はgo-langが流行ってきているので、採用にも効いていると感じられる
大倉:同じく最近はgo中心にプロダクトを構築していて、世の中的にも増えてきている感がある
及川:10年前と今では何が違う?
小林:インフラでクラウドの進化が大きい、今ではクラウドを選定しないことがほとんど無いくらいになっている
及川:インフラエンジニアの仕事が変わってきている。
及川:10年前に機械学習を意識していたか?それを機械学習またはAIと呼んでいたか?
松野:10年前は今ほどパフォーマンス広告よりも純広告が多かった。今はどういうユーザが広告をクリックするか?などの分析はやっている。
小林:10年前はAIとか言われていなかった。ルールベースでアルゴリズムを処理する、ベイジアンフィルタをかます、などは昔からあった。それが進化したのが今だと思っている。
及川:Googleの検索だって今となればAIと言われるようなものだが、当時はそういう「ラベル付け」がされなかった。
及川:NVIDIAがこんなに大きくなるとは思っていなかった。
小林:GPUの用途が格段に広がった。
及川:皆様の企業はどういう風に変化しているか?
大倉:グループごとのCTOが事業に最適な技術を選定するようになってきている。
小林:事業部ごとにCTOを置くようになってきている
松野:だれが開発をリードして、誰が決定してくのか?を明文化するようになってきている
及川:テックリードやCTOという肩書きや役割が明示されるよう、組織の文化が変わってきている。
及川:今、注目する技術?
小林:自動車産業にむけてのオートモーティブ事業に、ITS(インテリジェントトランスポートシステム)への適用が重要。Uberとかを導入するにあたり、日本は世界に比べて遅れをとっている。土木や都市設計にも関わってくる。次世代の環境を作るためには、日本のITSを底上げしていく必要がある。
及川:日本は要素技術は強いが、応用をする際に、横の連携がまだ足りない感がありますね。
大倉:RPAの導入をしていきたいが、APIが公開されていない(?)など厳しい状況にあるが、できるようになっていきたいと思う。(?)
及川:人間の動きをシミュレートしたり、そういったもので代替されるが、なんとかテックといったものが縦の機能で閉じていて、横の連携をするためにAPIを公開して連携可能にすることで、ユーザーフレンドリーなものが作れるようになっていくのかな、と。
松野:非常に沢山のデータが集まってくる。どういったものを集めて利用していくのか、が重要。気軽に大きなHadoopクラスタを構築できるようになってきたので、その後の扱い方が重要。
及川:データを集めることはできたとして、そのデータをどう扱うのか?が重要だが、データに対するリテラシーはどうやって育てられているか?
松野:データサイエンティストを積極採用したりしつつ、Tableauサーバなど気軽にBIで分析できる基盤を整えたりしている
①例えば、プログラマとして、どこまでプログラムを書かないといけないのか?
及川:インフラはほとんどスクリプト一発で実現できることが増えてきている。GitHubのChrisも、将来はコーディングがなくなっていく世界が来ると言っていた。
松野:どういう要件が必要で、どこがどういうコンポーネントで、といった要件を整理するところは少なくとも人がやるんだと思っている。徐々に、ブロックを繋げるだけで実現できる世界が広がってきているのを感じる。
及川:書き方は簡単になってきているが、やろうとしていることが難しくなってきているので、結果的に書く量は変わっていないようにも思える。
小林:自動車産業がなぜこんなに自動化するか?というと、人間が操縦したりすると事故が起きるから。つまり、人間がコードを書くとバグが生まれる、ということの解決としてプログラミングも自動化されていくのではないかと思っている。
小林:RoRなど簡単なものが増えてきた弊害として、裏側の本質的に行われていることを理解していない人が増えてきているのは、どこかで問題につながりうるのではないか。
及川:マインクラフトの話があったが、ビジュアルプログラミングはどれくらい出てきているか?
大倉:子供向けにスクラッチをやらせてみているが、まだ難しいようだ。子供向けのRubyの本のほうが分かりやすいかと考えている。
及川:ビジュアルプログラミングは、バージョン管理と人とのコラボ(ソーシャルコーディング)が難しく感じる。
及川:将来に向けてインフラエンジニアはどうあるべきか?
大倉:抽象化されたことで自動化やプログラムで解決されるものが増えてきたが、コードを書くのか、より深い要素技術を理解して身につけるのか、どっちかかと思う。
及川:チェスの大会や、自動運転車の世界でもあるように、機械の横に人間が座って、協力して結論を出していく組み合わせがベストな解決につながる、という世界がしばらくは続くと思う。
②ソフトウェアにより制御可能な世界 SDxやxxx as a service その進化はソフトウェア開発やインフラへどう影響を与えるか

(途中、メモれず・・・)
及川:Software eating the world. とも言われるように、ソフトウェアが世界を変える、という流れがしばらく続くかと。
③チーム開発の将来は?VRやARが与える影響は?リモートワークの今後

小林:隣りに座っている人ともSlackで会話する、ということも出てきている。だが直接会って話さないと伝わらない空気感や感覚があるし、初めて会う人がずっとChatというのも抵抗が残るので、対面コミュニケーションはなくならないと思う。
松野:グローバルな拠点でのやり取りはChat(LINE)だったりビデオ会議でやることがある。ビデオ会議でも通訳を通しても通信が不安定だったり、情報が落ちることがある、対面で通訳を通したときの方がまだ安心感がある。今後はVRで徐々に解決されていくのかもしれない。
及川:音声が不安定だと、途切れるのを恐れて、短いフレーズで話す傾向がでてしまい、短い文言での発言だと「怒ってるのかな?」みたいに本来のニュアンスで伝わらないことがある。
最後にひとこと

松野:今後も色んな技術によって、いろいろと便利になっていく、それらに触れられるのが、作る側としても楽しみ。
小林:作り方も高度化している。企画して設計して作って、ではなくユーザ体験とか考慮するようになっている。それらを柔軟に対応できるようになっていきたい。
大倉:今日のディスカッションを踏まえてオートメーション化について今後もディスカッションができると嬉しい。

f:id:shiopu:20180620084008p:plain

所感

golang普通に使っている企業が増えてきたなー。生の及川さん初めて見たー(ミーハー心)

GitHubと共に学生を育てる方法

古橋 大地 (青山学院大学)

@mapconcierge

2017年度の大学1年生

  • 1998年生まれ
  • Googleが生まれた後に、学生たちが生まれている
  • 遠からずGitHubネイティブな学生も出てくる...

文系の学生ですら、ここまではやってるんだな、という話

いつも学生に見せる樹状図

  • 生物の進化
  • 様々な形で生き残るもの、生き残らないもの
    • どういう情報が継承に値するのか?
    • どうやって教育していくべきか

教育の中でGitHubを利用している

どんなことを教えているか?

  • 課題:XYZタイル画像のデータ仕様を図化しなさい。
  • 技術者としてではなく、技術者と一緒に活動できるようになりなさい

キャンパス内でドローンを操作してみる体験

  • ドローンレース
  • どういう映像がドローンを通して見えるか
  • ドローン操作がうまくなる

最先端の技術をどうやって社会実装できるか、を考えられる学生を育成

Wikipediaを参考にしたモデル

  • Free Wiki ...(?)

オープン(=商用利用可能)

オープンストリートマップ

  • 5.0M規模のボランティアの力
  • 海外の仲間との情報共有
    • Mapbox(共同で地図を作っている地図会社)
      • GitHub上で共同作業
      • タスク管理はIssue
    • 人道支援の地図
      • 国境なき医師団などとのコラボ@GitHub
      • ソースコードだけでなく、コミュニケーションとして使う
      • やりとりする情報はMarkdown
        • 途上国、先進国問わず、普段遣い。
        • まず学生に「Word禁止」
        • ウチのゼミはMarkdownでしか資料の提出を受け付けません。
        • レポート提出先もIssueでMarkdown
  • 公開にすることで、学生に適度なプレッシャーになる
    • 外部の人からコメントが来たりする
  • ウェブサイトはGitHub Pages

Gitの仕組みは、Git-it で経験。

  • https://github.com/jlord/git-it-electron
  • 文系の学生もコマンドを使わせる
    • GitHubが使えないことで、そのコミュニティに入れないのは大きな損失である
  • 学生に説明するプレゼン資料はSpeakerDeckで公開
  • GitHubの履歴は就職活動の履歴書にもなる
    • 就職活動前から(1年生から)育てていく必要がある
    • Issueでのやりとりも、PRもすべてがエビデンスになる

最近は、GitHub Projectでタスク管理

外(社会)と中(大学)をつなぐ架け橋がGitHub

  • Publish or Die! (公開するか、さもなければ死を!)

所感

文理系に関係なく、学生にITリテラシーを植え付けようとするその志と、オープンな地図ソリューションで社会貢献しようという情熱が半端なかった。これくらい徹底してGitHub中心に生活させるようにしないと、リテラシーの底上げは実現できないよな、と痛感。

SlerGitHub Enterpriseを使ったら

原口 猛 (株式会社セゾン情報システムズ)

所属グループ「モダン開発推進」とは?

  • 既存のプロジェクトの進め方にプラスアルファをし、いいねを一緒に増やしていく

GHE導入編(SIerでもGHEが使いたい)

  • 背景
    • オールドスタイルのSIerにモダンな開発を取り入れるための組織が発足
    • ソースコード管理ツールが部署・製品・サービスごとに乱立
    • 顧客のソースコードも扱うため、クラウド上のサービスは検討から除外
  • いざ導入
    • Very easy!
      • 公式サイトの記載通りで、数時間の作業で運用できる状態に
    • 段階的導入
    • GitHubの引力
      • 試したい、という声が多数。一度利用するとGitHubの持つ優れたUI/UXの虜に

f:id:shiopu:20180620084345p:plain

GHE運用編(え?運用は私一人ですか?)

  • 2年間運用してトラブル0件
  • 運用で必要となるのは、定期的なアップグレードのみ
  • 運用工数はごくわずか

導入効果

  • デイリーコミット(を推奨)
    • Before
      • 開発工程の終盤(テストの直前)で一斉にコミット
    • After
      • 開発フェーズの最初から、コミット+CIツール静的解析
    • 戻り工数大幅削減
    • コードの共同所有の有用性を体験
      • 自信がない・恥ずかしいコードを早期に共有する文化にする
    • レビュー
      • Before
        • レビューは有識者に教えてもらう場
      • After
        • 相互学習するための場
        • コードをチームで所有し、成長させるための場
      • 注意点
        • 2回で伝わらなければFaceToFace、大事
        • レビューコストをかけすぎない(静的解析ツールを最大限利用する)

まとめ

  • GHEはただのツールではなくプラットフォーム
    • 文化を変えるためのプラットフォーム、豊富なプラクティス
  • 導入ではなく定着がゴール

運用事例

  • 事例1.ペアプロ・モブプロによるシングルブランチ運用
    • PRベースじゃなくてFaceToFaceでレビュー
    • ブランチはmasterブランチのみ
  • 事例2.開発以外での利用例(ポータルサイト
    • GitHub Pages
      • 静的コンテンツを簡単に公開

f:id:shiopu:20180620084409p:plain

マクニカネットワークス 根本さん

GitHub Enterprise の国内一次代理店

  • 導入事例および支援サービスのご紹介
  • GHE および CircleCI オンプレ版 の導入支援

f:id:shiopu:20180620084429p:plain

所感

GitHub Pages 使っているところが多いなー
弊社でも有効活用しないとなー・・・

GitHub Marketplaceと、開発生産性を向上させる幾つかのSaaSのご紹介

角 幸一郎 (SideCI株式会社)

@sumyapp

コードレビュー支援サービスSideCIのFounder,CEO

背景

  • 書籍「クラウド誕生」の出版2009年から9年が経過
    • オンプレミスなソフトウェアやソフトウェアのない世界が残っている
  • ソフトウェアはお金で買える、開発リソースはお金で買えない
  • 開発者は仕事を効率化するために、SaaSやソフトウェアを遠慮なく使える世の中になって欲しい

発表後にやって欲しいこと

  • GitHub Marketplaceですぐに使える便利なサービスを知って、使ってみて欲しい

SideCIで使っているサービスは、数多くある

  • 10数名規模の会社だが、無数のサービス利用によって生産性を最大化している

f:id:shiopu:20180620084520p:plain

GitHub Marketplaceとは?

  • GitHub連携サービスを簡単に購入、導入できる
  • 様々なカテゴリのサービスが利用可能
  • 購入はGitHub上で完結。決済も統合
    • GitHubへの利用料に上乗せされるだけ

Marketplaceサービスの紹介

  • Coveralls | Code quality
  • SideCI | Code review
    • https://sider.review/ja
    • RuboCopやCheckstyleなどの解析機を使って、コードレビューを支援
    • GitHub PullRequestと連動
    • コードを解析、問題点をサジェスト
    • 静的解析ツールは必ずしも正しい指摘をするわけではない
      • 誤検知をCloseする機能あり
      • プロジェクト固有のルールも検査できる
    • 購入パイプラインによって並列実行も可能
    • 今日から sider にサービス名変更
  • Dependabot | Dependency management
  • Rollbar | Monitoring
  • ZenHub | Project management

便利なサービスがたくさんある

  • 開発生産性を飛躍的に引き上げてくれる
  • 簡単に導入できる
  • 人の時間は有限。スケールアウトもできない
    • SaaSなら人の時間を節約できる

所感

今までは、ほとんど自前でゴリゴリと周辺サービス連携をしてきてしまっているので、マーケットプレイスを有効活用して、楽に(お金で解決して)生産性と品質を確保する選択肢を増やしていかないとな。

GitHubを軸とした開発プロセスのリプレイス

大平 哲也 (株式会社スタートトゥデイテクノロジーズ)

テーマ

  • いかに開発者の負担を減らして、楽しく開発できるようにするか
  • 主に「自動化」について話します

開発環境を取り巻く状況

  • 開発体制
    • 基本・内製
    • 100名強のエンジニアでサービスの開発と運用。
    • 本社と密に連携
    • 慢性的な人手不足
  • ZOZOTOWNシステムリプレイスプロジェクト
    • ECサイトのシステムをモダンなものに刷新する
    • 2017年4月の採用広告が話題に(炎上
    • 大規模なシステムリプレイス
    • 開発プロセスについても治すべきところは直す
  • おおまかな方向性
    • 頼れるものには頼る
    • 自動化出来るところは自動化

GitHub導入以前

  • 他社のインストール型Git Repositoryを利用
  • 様々な問い合わせが発生し、十分に対応しきれない
    • サーバが落ちる、ログイン不可、重い
    • 社内での運用は人手不足
  • インストール版のGit repoだと、各種SaaS/PaaSと連携するために自作○○が必要になる

GitHub機能比較 by スタートトゥデイ(GBHの価格は $21 で、GHEと同じ)

f:id:shiopu:20180620084648p:plain

GitHub Business Hosted

GitHubエコシステム

f:id:shiopu:20180620084719p:plain

  • Wercker(CIツール)
    • Oracleが提供
    • privateリポジトリも無料で連携
    • 有償で専用パイプラインを購入できる。
    • すべてのCIプロセスをDocker image上で実行。
  • 自動化
    • テスト
      • いわゆるUnitTestを実施
      • DSLの内容もチェック
        • Terraform/Ansible
    • コード品質の評価
      • push時に品質を自動でチェック
      • Code Coverage
      • Code Smell
      • Duplications
      • PRレビューの補助
      • SonarCloud(SonarQubeのクラウド版)
        • 様々なコードメトリクスを収集
    • コード自動生成
      • 仕様は一箇所で表現したい
      • 仕様を書いたら、そのとおりに成果物ができて欲しい
      • Swagger / OpenAPI
    • 成果物のパッケージ
      • k8sを採用している
      • JAR
      • Docker Image
      • Java開発でJARにパッケージングするのが面倒
        • JitPack
          • GitHubに登録されているJavaソースコードを自動でJARにパッケージしてくれるサービス
          • GitHubにpushするだけで、JARが自動的に使用可能に
          • 有償で private repo にも適用可能
    • デプロイ
      • ...追いつけず

総括

  • GitHub Business Hostedを採用することで運用負荷を減らす
  • 様々なエコシステムを利用できたので、開発者の生産性を向上
  • GitHubをフル活用して開発者が楽しく開発できる環境にしていきたい

所感

k8sを使っている事例を当たり前に紹介されることが増えている気がして、やばい出遅れている感(!)

企業開発に役立つGitHubの最新機能

池田 尚史 (GitHub)

@ikeike443

プリセールスのエンジニア

  • ROI計算の支援とかしてる

GitHubとは

  • The software development platform
  • ソフトウェア時代の主役は開発者であり、それを支援する
  • 色んなバリエーションのプロダクトごとに様々な開発手法がある
    • あらゆる開発手法を受け止められる開発プラットフォームである
  • 10年間に書かれたコード量:500TB
  • 昨年1年間のコミット数:15億
  • マージされたプルリクエストの数:1億
  • 85%のプルリクエストは、実はPrivate(主に企業による利用)

企業利用の選択肢

  • GitHub.com Business Hosted
  • GitHub Enterprise
  • コードベースは同じ
    • エンドユーザー視点で同じ機能を提供
    • GitHubBH
      • GitHub社が運用、マルチテナント、米国
    • GHE
      • 社内にインストール、御社のポリシーで

代表的な機能

  • GitHub Flow(機能というかプロセス)
    • GitHubが提唱しているベーシックな開発フロー
  • Git Code Repository
  • Pull Request
  • Issues
  • Projects
  • 巨大なエコシステム
    • 各種ツール、エディタ、チャットツール、CIツールとの連携

f:id:shiopu:20180620084756p:plain

企業利用に役立つ機能

  • Platform
    • Security Alert
      • 依存関係に脆弱性のあるライブラリがあることを検知
    • Checks API
      • PRに新しいタブが増えている
      • インスペクションの豊富な情報を表示可能に
      • CIサービスのReRunボタンもGitHub側に用意
    • Outlook連携
      • Outlookの中で、GitHubのIssueにリアクションできる
  • Administration
    • Archiving Repositories
      • リードオンリー(参照専用)で置いておきたいニーズに応える
    • Legal Hold
      • 通常は、リポジトリが削除されたら、90日間保持してからパージされる
      • 訴訟などを考慮して、設定されると、削除されてもパージされない
    • High Availability & Backup
      • Primary-Replica構成でリアルタイムレプリケーション
      • Backup-Utils・・・バックアップとリストア
    • Mixed Auth
      • 認証基盤を混ぜる機能
      • LDAP/SAML/CAS
      • テンポラリユーザ向けに、LDAPに登録せずともGitHubビルトインの認証情報を作成可能
    • Hot Patch
      • ダウンタイム無しで適用可能
    • 2要素認証
  • Org/Team
    • Nested Teams
      • 権限グループのネスト
    • Approval flows
      • Teamへのメンバー追加
      • Organizationへのサービス追加
    • Team Discussions
      • チーム単位でディスカッションができる機能
    • Organization Permissions
      • メンバーの初期権限
      • リポジトリの可視性
      • Forkの可否
      • 2要素認証の使用有無
    • Protected Branches
      • 特定のブランチを保護し、マージ条件を設定できる
      • Code Ownerによる承認を必須に
      • CIやテストのパスを必須に
      • 特定のチームのみマージ可能
  • Developer
    • Projectsの改善
      • 自動化カンバンボード
        • Issueのステータスとカンバンの位置移動を連動
      • 進捗のビジュアライズ化
      • 権限管理
      • テンプレート
      • キーボードショートカット
    • 複数のIssueテンプレート
    • ナビゲーションの追加
      • 特定言語について、Jumpと編集が楽に
    • コメント編集履歴

まとめ

  • 企業内開発に役立つ機能
    • Issues/Projects/Pull Requests
    • Organization/Teamによる権限管理
    • 運用管理に役立つ様々な機能
    • 今後も進化していきます
  • GitHub Changelog で変更点は確認できる

所感

Security Alert / Checks API は待望。

GitHub Enterpriseアドミンパネルディスカッション

モデレーター テレル・ブルーマ (GitHub) 伊集院 圭介 (ブラザー工業株式会社) 井内 聡 (フリュー株式会社) サマーズ ハリス 和弘 (楽天株式会社)

テレル・ブルーマさん @domofactor

f:id:shiopu:20180620084823p:plain

1.GitHub導入時点の話

て:導入した理由は?
さ:インフラを導入していく仕組みのリポジトリを管理していくにあたり、GitHubを使えなかったのでGHEを使った
て:大規模な企業だが、簡単に導入できたのか?
さ:導入には苦労はなかった

伊:システム的な問題としてプロプライエタリなVCSはWindowsでしか使えず、Mac/Linuxでは別のものを使っていた。ソーシャルコーディングが開発者から求められていた中で、GitHubEnterpriseを使っている他社の事例を見て憧れを抱いていた。そういうCoolなツールを使いたい、という思いが強かった。

井:レビューを強化しようという流れの中で、SVN+Redmineで行っていたが、GitHubのPullRequestの方が効率的だったので、導入した。.comの利用にはハードルがあったので、GHEを採用した。
て:導入で苦労したことは?
井:SVNからGitへの履歴を含めた移行はすぐにできたが、SVNの外部参照を多用しており、代替の機能がgitにはなかったので苦労した。最終的にはgit-submoduleを使って実現したが、ディレクトリ構成の変更などを伴い苦労した。また、git自体の理解と習得に苦労した。
伊:プロプライエタリなVCSからの移行だったので、事例がない情報がないので苦労した。ツールを使っていたが、特定条件のリポジトリは必ず失敗する、などが起きて職人芸的にクリアせざるを得なかった。gitに理解のないエンジニアに移行を促す作業は、なかなか骨が折れた。今は古いVCSはシャットダウンできている。
さ:最初は特定プロジェクト向けにgitを導入したが、どんどん周囲のプロジェクトから手が挙がって利用者が増えた。当初はライセンスの購入が追いつかなかった。また、よりオープンに公開する文化にシフトするなかで、秘匿化しなければいけないトークンなどまでオープンにしてしまうことを防止したり、そういったポリシーを定めるのに苦労した。
2.いま時点の話

て:GHE導入して、何が変わりましたか?
伊:一言で言うと文化が変わった。自分たちで調べてブランチ戦略を考えたり、勝手にPullRequestでコードレビューを始めたり、そういった変化が自然に起きた。
さ:各プロジェクトが自分たちで作っている製品を管理していたが、今は、チームを横断してPRを投げたりするような文化ができ始めている。良い変化だと思う。
井:様々なツールを見ていたのがGitHubに一本化されて効率があがった。またPRの時点で仕様や要求の共有ができるようになった。
て:GHEを管理していて困ったことは?
伊:ソフトウェア的に問題が起きたことはない。Org/Teamの管理が自分自身でしかできない点が課題。
井:サーバ側でのトラブルはない。gitの勉強コストが困ることがある。git操作での事故がチラホラある。レビューを通すことが必須になったため、本流に入るまでの時間が長くなった部分もある。
さ:弊社はプライベートネットワークとパブリックネットワークが分かれており、それらのインターフェースを毎度設定する必要があり苦労している。今は解決している。
て:管理者からみてGHEのいいところは?
井:安定しているサービスである。サポートが日本語で対応してくれるのも助かる。
さ:安定性はすごくありがたい。他に使っている他社製品はDockerベースのものが多いが、落ちたりバグったりする。管理者用のドキュメントも分かりやすくていい
て:ユーザの反応はどうですか?
伊:良好。早く作業ができていい、という声を聞く。GHE内のすべてのコードを検索できるため、社内の特殊なノウハウを探して参考にしやすいのが嬉しい。
さ:使い出すと戻りたくない、という声が多い。
井:リポジトリをまたいだ検索はありがたい。使うべきではない関数の横断検索などは効率的にできた。
(オーディエンスから質問:福留さん)サーバの運用周りについて、手がかからないという話があったが、何か管理面で自動化の工夫をしている点があれば教えて欲しい。
さ:GHEはモニタリングでGraffanaが統合されているが、独自のモニタリングツールと統合したい場合に、モニタリングのAPIを使って情報を吸い出している。
て:これからGHEを導入したい人へのアドバイスは?
井:PRは開発者にとって大きな変化なので、1つの最善の選択だと思う。
伊:競合製品と比べるのは良いと思うが、結局はGHEに辿り着くと思う。サポートのレスが早い。情報文献も多い。

会場風景

タイムテーブルとフロアマップ(今日はPegasusエリアを使わず)

f:id:shiopu:20180620084137p:plain

このクッションを持ち帰りたかった

f:id:shiopu:20180620084231p:plain

GitHub Japan Constellation Tokyo 2018 〜Day 1 Community〜 #GitHubSatelliteTokyo

2018/06/12 (火)
11:00 - 20:00 JST

公式サイト:https://githubsatellite.com/
参加申し込み:https://peatix.com/event/366890
ライブストリーミングhttps://githubsatellite.com/live-stream/
Twitter HashTag: #GitHubSatelliteTokyo

基調講演:ソフトウェア開発の未来

公家 尊裕 (GitHub) ジェイソン・ワーナー (GitHub)

GitHub サービス開始が2008年、今年でちょうど10年。

GitHubという会社は、コラボレーションとリモートオフィスという考えを大事にしている。全世界に社員がいるが、長い間オフィスはアメリカ1つだった。

2015年、GitHubアメリカ以外の最初のオフィスができた。場所は、Tokyo。

ソフトウェア開発の未来に貢献していきたい。

  • GitHubは10年間で、全世界に

  • サテライトオフィスを設立した日本ではどうなった?(3年前と比べて)

    • GITHUB ユーザーの増加: 250%増
    • PULL REQUEST増加: 550%増
    • OSSユーザーの増加: 77%増

今、開発現場で起きていることは?(ジェイソン・ワーナー)

開発者

  • 皆様が書いているコードが、今、地球上で大きな原動力となってる。
  • ソフトウェア開発者になるのに、今ほどいい環境・状況はない。

より複雑化する開発環境

  • 数年前の時点で、平均的な自動車は、1億Stepのコードで動いている。
  • 2017年、平均的な開発者は1000以上のクラウドサービスから選定をしている
  • 進化は止まらない、追いついていくのは容易なことではない

コミュニティは知識の集合体

  • 私達が最初に作ったもの。

    • 信頼性の高いバージョンコントロールシステム、Web経由でアクセス可能なもの。
  • 作ったシステムは、次第にコミュニティを構築していった。

  • 人やデータ、ツール、すべてが繋がっていくことで成長・進化していく。

開発環境の複雑化は止まらない

  • イデア、コード、ビルド、デプロイ
  • 無数の意思決定がプロダクト作成までの道のりでは必要。

過去、今日、未来

  • 人々が積み上げた試行錯誤を段階的に未来につなげていけるのが、GitHub
  • ツール・サービスには、あまりにも多くの選択肢が用意されている

    • これらをすべて評価してマスターしていくのは不可能
  • これらの乱立するワークフローを解決するのが、Pull Requestだった。

複雑化する開発環境

  • 純化するプラットフォーム、合理化したソリューションが必要
    • ガチガチに固められたソリューション?

より良い開発環境構築のために

開発者感コラボレーションの促進

開発者に必要なのは、より多くコードを書く時間と、ユーザのことを考える時間

新しいテクノロジーは次々と出てくる

  • ソフトウェア開発が将来どういうかたちになっていくか、は誰もわからない

    • どのようになろうと、複雑性を排除してシンプルに開発できる環境を整えることに注力したい
  • 様々な問題を解決するのは開発者の皆様です。

    • GitHubはそれを支援します。

先週、MicrosoftGitHubを買収した。

日本マイクロソフト株式会社CTO 榊原 彰 氏

設計図共有サイトのファンの皆様、こんにちは(会場爆

  • すべてがコンピュータ・ソフトウェア産業になっていく。

    • それを作り、支えていくのは開発者の皆様です。
  • マイクロソフトは変わってきた、あなたのお父さんの世代のマイクロソフトとは違います。

    • 言っても信じてもらえない人もいる
    • 言葉ではなく、行動で示していきます。
  • GitHubの独立性を保って、すべての開発者が今までどおりGitHubの機能を安心して使っていけるようにする。

    • LinkedIn やマインクラフトでも独立性を維持してきた
    • これが、我々の今のミッションです。
    • これからの我々の行動を見ていただきたい。

empower all developer

  • 我々がやりたいこと。
  • すべての開発者とともに、未来を作っていきたい。

f:id:shiopu:20180613031653p:plain

パネルディスカッション:Rubyが生まれた頃、そしてこれからのRuby

アーロン・パターソン (GitHub) まつもと ゆきひろ (Rubyアソシエーション)

GitHubのソフトウェアエンジニア、アーロン・パターソン

(互いに旧知の仲らしく、2人でのセルフィー撮影に始まり、終始和やかなムードで対談)

あ:GitHubはRubyで書いてあるので、まつもとさんありがとう。
あ:Rubyはいつ生まれた?
ま:1993年です。
あ:どうやって生まれた?
ま:バブル経済が崩壊して景気が悪かった、ソフトウェア会社の社内ツールを開発するチームに在籍していた。そういうツールは売上がたたない。景気が悪いのにそんなことをやってられない、プロジェクトが解散した。社内にはツールのユーザが既にいたので、面倒を見るために残されたエンジニアが2人だけ残った、そのうちの一人。何年もかかって作ったツールを2人ではサポートを回せない。自分で作ったもの以外も多数あったので、基本的にトラブルシュートは「再起動してください」で終わらせていた(笑。上司は兼任で忙しかったが、自分たちには時間があった。誰も管理していない状態、そんな中で作ったのがRuby。
ま:会社で作ったが、著作権の考え方に厳しい時代じゃなかったのと、上司が許してくれたので、退職時に外へ持っていけた。上司が許可してくれなかったら今のRubyはなかった。
ま:GitHubに公開されているRuby/Rubyは、公式のミラーであり、実際はSVNで開発が行われている。
ま:なぜGitHubに移行しないのか?をよく聞かれる。RailsもGitHub。PythonのセントラルリポジトリもGitHub。
ま:RedmineでIssueを管理していて、RedmineとSVNを連携させる作り込みを相当しているので、使い続けるという状態。あと、GitHubサービス自体はOSSではないので、一部のコアなエンジニアが完全オープンなサービスにしかアカウントを作りたがらない、というのもある。そういう人々を離脱させたくない。
あ:まつもとさんがGitHubを初めて使ったのはいつ?
ま:Ruby本体で使えなかったので、アカウントは作ったが、ほとんど使っていなかった。自分用のメールリーダーを自作している、OSSにしていないのでユーザは自分しかいない。それを修正するためだけにPRを3回だけやった。
ま:mRubyは、最近の普通の開発がしたかったので、最初からGitHubにホストしている。やっぱり楽でいい。リポジトリなどを自分で管理するのはよくない、と改めて思った。
あ:Ruby開発のコミュニケーションの問題はあるのか?
ま:Rubyのコアコミッターは100名くらいいる。日本人が半分くらいだが、スーパーアクティブな人が日本人なので、日本人がコミッターであるイメージが強い。
ま:Rubyの開発は、オープンソースだけどクローズドだ、と海外の人で言われた。日本人が日本語でいつの間にか方向を決めてやっている。それ以降、Redmmineにすべて内容をダンプして、公式言語も英語にして、オープンになるよう心がけている。議事録も英語で書いているので、日本語がわからないとRubyができない、という世界にはならないようにしている。
あ:Rubyの未来について
ま:頑張って進歩を続けている。RubyやRoRは「ハイプ曲線」を過ぎて、Rubyは死んだ、と言われている(笑
ま:Goなどの静的な型がある言語が持ち上げられてきたので、様々な理由で毎年死んだと言われ続けている(笑
ま:大きなサイトでRubyが使われているのは事実で、そういったサイトをもっと支援したい、と考えている。性能問題が出たときに独自カスタマイズしたRubyを作っている人々が昔はいたが、大体が残っていないと思うし、本来Rubyユーザが汗をかくべきところではないと思っている。
あ:アウトオブバウンズGCの説明。Webサイト利用者にGCによるレスポンス遅延影響を最小化する手法。GitHubで利用することで劇的にUXが改善した。
ま:そういう感じでコアチームの努力によって、Rubyユーザが独自にRubyをパッチしなくてもいいようにするのが責任だと思っている。
あ:プログラミング言語を作るのが好きなまつもとさんの、プログラミング言語のストリームについて教えてください。
ま:言語をデザインする人が、言語をデザインするときにどういう事を考えて設計しているのか、ということが分かるような連載を書いている。そこで作り始めたのがストリーム。まず200行くらいの文法イメージを書いてGitHubにバックアップ目的でアップロードした。特に隠す必要もないと思いパブリックリポジトリにしていたら、次の日に、「まつもとがプログラミング言語を作っている!」というのが見つかって、バズって1000スターくらい一気に行った。。。全然作業途中のものなのに、PRは来るわ、言語のアイコンを作って投げつけられたり、色んなことが起こって、OSS時代の開発は全然違うな、と思った。フリーソフトウェアの時代とは違う。
あ:まつもとさんの開発環境について
ま:普段使っているエディタはEmacs。コンパイラーはgcc。
あ:なんでRubyのソースコードの中で同じファイルの中にTabとSpaceが混在しているか?
ま:どっち派の人もコミッタにいるが、最後に触った人の修正した行が、その人の行はその人の流派になる。特に統一しようとしていない。
ま:昔はスペースよりもタブ派だった。データ数が少ないので。最近はスペース派になった。git blame が効かなくなるので、変換するためだけのコミットをしていない。
あ:私は自作キーボードを使っているが、どういうキーボードを使っているか?
ま:Thinkpadのキーボード、マイクロソフトのエルゴノミクスキーボードを使っている。最近はレッツスプリットというキーボードを使っている。タップキーボードを最近買ったが、まだ使いこなせていない。

余談:日本独自文化「笑う」の意味での「草(w)」の話と GitHubの「草(Contribution activity)」の話。(アーロン大爆笑)

f:id:shiopu:20180613031747p:plain

所感

話を聞いている雰囲気から、Matzは細かいことを気にしすぎない包容力があるから、Rubyのコミッタを含むコミュニティを「いい感じにゆるく」まとめていけるんだなー

エンジニアにとって窮屈さを感じさせる環境を作らない、というのが非常に感じられる。 でも大事な部分はキッチリ真面目に説明責任を果たすし、Techリードはこうあるべきと感じた。

OpenSTFをオープンした結果

シモ・キンヌネン (Dragon Standard Inc.)

https://github.com/openstf/stf

Co-Founder

  • OpenSTFとは?
  • GitHub Starは
    • 9345ついた
  • 公開後、安心安定の成長
    • Fork数、Issue対応数もどんどん増えてる
    • PRの数、200弱あった
      • 公開前は誰もPRしてくれないのでは、という不安があった
  • 公開直後はJumpStartした(知名度が最初にドッと増えた)
  • ポイント
  • なぜ成長が進んだか?
    • ライセンス:Apache2.0なので、ほぼなんでもできる
    • 自然な成長
      • インド・中国・ロシアでは意外と人気
        • クラウドが安定していない、または信用できない傾向のある国である
        • 端末の種類が多い
      • 定期的なアップデート
  • 辛くなったこと
    • メールボックスの状態が、OpenSTFのメールだけで埋まっている…
  • オープンソースのイメージが変わった
    • Google/Facebookなどの大手企業が多数のプロジェクトを出している
      • スター数がある程度多いとフルタイムのチームがあると思われる
    • ソフトは無料だから、サポートも無料だろう、と思われる
  • 文化的な違い(サポートの辛さ)
    • 他人の時間を大事にしない
      • 困ったことがあったら自分で調べるより誰かに聞きたい
      • ドキュメンテーションがあっても読まずに直接聞きたい
    • (折角用意してある)Issue Template を消す
  • 言葉の壁
    • 何で困っているか、通じないことがある
    • 問題を把握するのに非常に時間がかかる
    • 詳しい説明がないから何回も同じ情報を聞く必要がある
    • Issue Template が理解できない
  • 技術の進歩
    • 昔、私達しかできなかったことが、新しいAPIのおかげで比較的ラクに
    • 他のソリューションもある
  • ライセンス
    • Apache2.0なので、ほぼなんでもできる
    • 私達のものをそのままか、ロゴを変更するだけで売っている会社がある、残念
  • 普通に嫌なこと
    • 「○○機能ってまだ?」
    • 「有料の他のツールでは、それができてるよ?」
    • 「じゃ、ほかのものにするよ」
      • すべて解決できるわけではない
  • 役に立ったこと
    • メンバーを増やす
      • 昔は厳しかったが今は2〜3回目のPRでPushを許可する(権限を付与して正式なContributorに)
      • 最初は怖いかもしれないがGitなのでかなり安定する
        • (いざとなれば force push で履歴改変)
    • Issue Template をできるだけ短くする
      • 何が起きた・何をした・ログの有無
      • 考えすぎて無駄に長くすると誰も入力してくれない
      • スクロールすると読んでくれない
    • もちろんCIを設定する
      • (ビルドが落ちても直さない人がいるけど・・)
    • Issue が来たら、すぐに対応にかかる時間を判断する
      • 3分以下なら、すぐ返事してクローズする
      • それ以上なら、あとにする
    • CHANGELOG.md をちゃんと管理する
      • 何がいつ変わったか簡単に分かるから無駄に聞かれない
      • リリースノートでそのまま使える
    • 無駄な約束をしない
      • 「それ、いつかやるつもり」と言ったら無駄に期待されるので、興味・時間がなかったらハッキリ言おう
    • ビジネスをやるつもりがなくてもサポートの値段ぐらいはちゃんと準備しよう
      • 高めにすると面倒くさい要求が簡単に回避できる
  • 良かったこと
    • 普通より面白い仕事をチャレンジできた
    • いいエンジニアと連携できると最高
    • いろいろなイベントに招待された
      • LA、ロシア、中国など
    • 「タイに来てうちの経費で○○機能を作って」という依頼も
    • いろいろな会社と連携できた
      • 恐ろしいスケールのデバイスラボも見せてくれた
    • 仕事にもなった
  • たくさんの端末と遊ぶことができて楽しかった

所感

オープンソースプロダクトを扱う身の 生々しい苦労話とやりがいの話。

Matzのストリーム話との共通点は、オープンにすることで多くのフィードバックが生まれプロダクトの成長が加速した、という点かと。

Microservices in ABEJA Platform - 集約と分散のサービス設計

石川 尊教 (株式会社ABEJA)

我々がどのようにマイクロサービスを開発&運用しているか?

  • 3 Topics
    • About us
    • Technology
    • Culture

About us

  • Deep LearningGoogleトレンド紹介
    • 2012年付近から、急激に右肩上がり
    • 2012年 ImageNet Challenge 2012
      • インターネット上にある画像を分類・画像認識をするコンテスト
      • 毎年開催されていたが、2012年にブレイクスルーが発生
      • Deep Learningモデルが従来の統計的モデルを圧倒
        • 認識エラー率は年々低下している
  • Abejaも2012年創業
  • ニューラルネットワークの簡単な説明

    • (「ゼロから作るDeep Learning」)
    • Data collection
    • Annotation
    • Training
    • Inference
    • Re-Training
      1. に戻る
  • Abeja は創業6年

    • 100を超えるAIプロダクト
    • Abejaプラットフォーム

Technology

Microservicesとモノリシックサービスの連携

  • 30を超えるリポジトリ
    • 5つの開発言語
    • サービス間は gRPC で通信
  • なぜ10名程度の会社でマイクロサービス化を進めたか?
    • Complexity(複雑性)
      • スケーラビリティが求められる機能
      • UI/UXが求められる機能が
      • 並列実行のバックグラウンド機能
    • Motivation()
      • 開発者は顧客にサービスを届けるのが使命
      • 開発者は新しい技術を使いたい、使う機会を得たい
        • Microserviceであれば、新しい技術の採用ハードルが低くできる
    • No Rules
      • 世の中で定められているレベルの最低限のルールを守っているだけで、社内の独自縛りはない
  • ARMSの紹介
    • 横断的な機能はすべてARMSで実装
    • モノリシックなアーキになっている
    • Elixir を採用(ArlangVM)
      • Scalabilityが要求される
        • 並列実行に強く、簡単にスケーラブルな実装ができる
      • ライブラリも充実している
    • Umbrella project
    • SwaggerでAPIインターフェースを定義
    • バックエンドのサービスとの通信
  • モノリシックなGatewayサービスがバックエンドのマイクロサービスのドメインの管理しやすさを後押ししている
    • 中央集権的に実現したい機能はここに実装する

Culture

Diversity

  • 英語を公用言語としているが、日本語ベースのトレーニングも用意
  • Self Starter
    • 待ち、ではなく、能動的なキャッチアップと貢献を推奨
  • LEAN & Flow
    • Waffleをつかったカンバンで朝会を実施
    • リモートオンライン会議はZoom
    • LEAN開発
      • 毎朝のミーティングでカンバンを見ながら同期
      • 自分のスキルと興味に応じてタスクを
    • 壁の一部がホワイトボードになっていて、すぐに会議が始められる

マイクロサービスアーキテクチャを採用して良かった点

  • プラットフォームの構築に向いていた
    • 複雑とはいえ、各サービスの役割が明確
  • 今のフラットな組織に合っている
    • メンバーが固定化されづらい
  • 新規メンバーが参入しやすい
    • 興味のある言語や分野から入っていける

各サービスをつなぐ中心になるもの、(ARMS)を用意することをオススメする。

GitHub LT大会 ~ 事件は現場で起きている!?

モデレーター 鈴木 順子 (GitHub) アーロン・パターソン (GitHub)

36名の応募者、7名が選ばれた。

GitHubポータルサイト ドキュメントを運営して幸せになる話

NTT.com 岩瀬ヨシマサさん

https://www.slideshare.net/iwashi86/github-102233959

  • GitHub Pages
    • 静的WebSiteのホスティング機能
    • GitHubがマネージしてくれるので運用レス
    • 開発者/企業のメッセージを発信する場として活用
  • GitHub Pagesを使うモチベーション?
    • GitHubを使うこと自体がメッセージになる
      • SkyWayは2013年12月にリリース
      • GitHubの会社アカウントも公開
        • このときの外部からの声
          • 「NTT.comは企業アカウントがあるんだ、格好いい!」
    • CI/CDとの組み合わせによる品質向上
      • そもそもエンジニア的にはドキュメントを・・・
        • Markdown/reStructuredTextで書きたい
        • git で管理して、PRドリブンで書きたい&レビューしたい
        • 表記ゆれなどのレビューは人間がやる仕事じゃない
      • ドキュメント開発/運用の全体像
        • MkDocsでHTMLへビルド
          • ソースとなるドキュメントはMarkdownで書く
        • CircleCIにて textlint を実行して事前チェック
          • 文章をlintしてくれるのがtextlint
          • 良い点:指摘点を勝手に直してくれる
      • 普段の開発のようにドキュメントも管理するとイイ!

GitHub as an Authenticator

Wantedlyオオツボシンペイさん

  • 情報共有
  • 社員名簿
  • 権限管理
  • GitHub を使って法務コミュニケーションのスピードを2倍にした話
  • 組織上のチームとGitHub上のTeamが対応
    • 複数チームの兼務も表現できる
  • GitHub Teamをベースに認可

    • HRのフローに乗るだけで良い
      • JOINしたときにTeamに所属させるだけ
    • 権限の外し忘れがない
      • Orgから外せばすべての権限がrevokeできる
    • 特定Teamに入っているとプロダクションへのSSHを許可
    • Webhook Token Authentication on kubernetes で
      • Teamごとに異なるk8sの操作を許可する
  • Summary

    • 社員全員をGitHubに入れる
    • 組織に合わせてTeamを作成
    • Teamに準じて認可する仕組みを

Githubをどうやって初心者に教えるか

湊川あい @llminatoll

「マンガでわかるGit」の著者
http://webdesign-manga.com/git01/ https://www.amazon.co.jp/dp/4863542178

  • 土日にブログで書いたGitに関する初心者エントリーがメディアに取り上げられて書籍化
  • git教え方いろいろ
    • 口頭
    • ドキュメントを紹介する
  • 聞かれるたびに手を止めて対応
    • 「なんかおかしくなっちゃいましたー」
  • Gitを教えるのは大変!
    • なぜ?
    • 初心者にとってGit用語は異国の言葉に聞こえる
    • まずは用語を1つ1つ説明していく
    • それでもなかなか覚えてもらえない
  • ビジュアル化すると理解が早まる!
    • 人の脳が見たものを理解するのにかかる →0.1秒
    • 脳の50%は視覚関係に使われている
    • 文章+絵だと認識率が圧倒的に高い、という研究結果
  • +漫画だと
    • 時間軸
    • 状況
    • 登場人物の心理
      • を表現できる(私が漫画という手法を選択している理由)
    • 漫画でリポジトリを説明してみる
    • フォークとクローンを説明してみる
  • まとめ
    • 学習コストが高いと言われるgit
    • ビジュアル化されていれば短時間で理解できる

所感

そういえば、gitの社内説明で絵を何枚も書いたなぁ。
git説明に限らず、ビジュアル化は本当に大事。

GitHubを導入したいとき、どう説得するか

Yahoo! タナカマサユキ

  • GitHub使っていて当たり前?
    • 導入に向けm社内を説得するために戦っている人もいるはず
  • 導入の壁いろいろ
    • 重要な関係者がGitHubを理解できていない
    • うまく説明できない
  • GitHubってなに?を改めて考えてみる
    • 機能がいろいろある
  • Yahoo!アプリ開発環境で考えてみる
    • 「開発業務の起点」
    • 開発の中心にいる
  • 向き合っている課題
    • アジャイルソフトウェア開発宣言」を見直すと
      • GitHubでこれが実現できている気がする
    • GitHubが「課題解決のきっかけ」
  • 大事なのは、導入するサービスを理解し、腹落ちさせること

技術系同人誌執筆のすすめ

イマイケンタさん @Henteko07

  • I love Developer Tools
    • 同人誌は早く出版できて楽しい
    • GitHubを使うと複数名の執筆でもうまく書ける
  • 商業誌は出版に14ヶ月かかった(経験談
    • 同人誌だと2ヶ月程度でOK
    • デメリ:リーチできる人が限られる
  • 同人誌は自由(Freedom)
    • なにものにも縛られない自由
  • GitHub上でどうやって同人誌を作るか?
    • GitHub上で Re:VIEWを用いて執筆
    • CircleCIでPDFビルド
    • Artifactsをアップロード
      • 各著者がローカルに開発環境を構築する必要がない
  • ツライ点
    • たくさんの画像を扱う書籍
      • 画像管理がワケわからなくなる
    • デザイン系の本であれば、GoogleDrive+GoogleDocumentを使ってる

Mixiにおける技術競技イベント「git challenge」の裏側

Mixi:サトウリョウスケさん

Start OSS Contribution with you know

シバヤマリョウさん @serima

自分にできることからOSSコントリビュートしてみよう

  • 初めてのコントリビュート
    • OSS:PHPにマルチバイトの問題が・・・仕事に支障
      • Issueを立てたらすぐにレスポンスが
      • 世界と繋がった感!!!
  • CircleCIが1.0→2.0に(2018.8末で完全移行)
    • 2.0対応できていないリポジトリを2.0対応していく!
    • Star数が多いところにコントリビュートすると世界への貢献度が高い感がある!
    • 8ヶ月ひたすらCircleCI2.0対応を色んなリポジトリ
      • Danger, Vue.js, yarn
      • 思い出深いPR
        • 1.0の機能をゴリゴリに使っていて移行が大変...
      • レビュワの人とのコンバセーション
        • 基本的に感謝される
        • 世界が広がっていく
  • OSSは継続的に開発されることが重要
    • コントリビュートしたいな、と思うものがあれば気軽に参加すればいい
    • 自分にできることを探す
    • Issueを探す(Help wantedラベルは比較的難易度が低い?)
  • ソーシャルコーディングを楽しみましょう♪

会場風景

入り口 f:id:shiopu:20180613031943p:plain

GitHubグッズショップ f:id:shiopu:20180613050024p:plain

会場案内 f:id:shiopu:20180613032054p:plain

GH Satellite : real-time contribution visualizer f:id:shiopu:20180613032115p:plain f:id:shiopu:20180613032212p:plain

Ask GitHubコーナー f:id:shiopu:20180613032234p:plain

CircleCIコーナー f:id:shiopu:20180613032253p:plain

講演会場ではテクノサウンドが流れる f:id:shiopu:20180613032324p:plain f:id:shiopu:20180613032356p:plain

戦利品 f:id:shiopu:20180613032520p:plain

ORACLE が CIサービスの wercker を買収

Jenkinsオジサンからの卒業その4(werckerを試してみた) - Logic Delight

でお試し紹介した werckerORACLEに買収された模様。

Oracle Buys Wercker

とはいえ、ORACLE Cloud内のSaaSとしてシナジーを効かせたい戦略ということで、wercker的にはログイン後の画面タイトルが「ORACLE+wercker」と変わっただけで、モダンで素敵なUIやサイトの構成には特に変化は今のところない様子。

ORACLE Cloud は、今後、どんなビジネス領域でどこまで先行するクラウドベンダーに肉薄できるのでしょうか?

携帯のメールアドレスに迷惑メールが来たので通報した2

今回のメールはこんな感じ。

差出人:   <j0a7mwgs7@i.softbank.jp>
日時: 2016年10月19日 19:32:43 JST
宛先: (ワシの携帯メールアドレス)
件名: 【速報】大切なお知らせ(19時32分)


大切なお知らせが御座いますのでご連絡差し上げました。
誠に恐れ入りますが、速やかに通知内容をご確認下さい。

●通知先
(ワシの携帯メールアドレス)

●通知内容
http://vv.wefravs5g.com/bin/campX.php?{怪しいパラメータが沢山}
●期限日時
2016年10月20日木曜日
07時32分35秒迄

何卒、宜しくお願い申し上げます。

------
個人情報を保護する為、メール本文に詳細を記載しておりませんが、
URL(リンク)先は受取人の為の特別な秘密情報を含んでいます。
大切なお知らせの為、通常受信していない場合でも配信しております。
尚、当メールは送信用途のみで使用しており、直接返信されましても確認しておりません。

ご理解・ご協力の程お願い致します。

何者かも名乗らずに、さも大事のように「大切なお知らせ」を伝えたがる連中。通知内容のURLパラメータの多さがウケるw そんな大事なことは、こんな胡散臭いメールでは通知せんわ!

ということで、前回同様に通報しました。

@2016/10/27追記
読者のどなたかが引用メールにあるURLにアクセスしたからか、続きのメールが届き始めたのでURLパラメータをごっそりマスクしました。

QCon Tokyo 2016 <Engineer Track>

参加した上での雑なメモ書きです。聴き逃している箇所も多分にあるので、資料のリンクがあるものは資料を見たほうがいいです(笑

http://www.qcontokyo.com/index_et.html

Twitter #qcontokyo

2016年10月24日(月)9:45~18:20

ベルサール新宿グランド コンファレンスセンター 東京都新宿区西新宿8-17-1
住友不動産新宿グランドタワー 5F ベルサール新宿グランドコンファレンスセンター

開会のご挨拶

荻原 紀男 株式会社豆蔵ホールディングス 代表取締役社長

10年近く続いているイベント

テーマ説明

羽生田 栄一 株式会社豆蔵 取締役 CTO QConプログラム委員長

ITが変革するビジネス・組織・社会

QConは、世界的なカンファレンスとして、海外各国でも実施されている

基調講演1 エンジニアリングの物語り(ストーリーテリング) ~人に語るに値するカルチャー

Engineering Storytelling - Culture Worth Talking About
Pete Soderling 氏
Hakka Labs

@PeteSoder

ニューヨークとサンフランシスコでスタートアップを実施

最高のエンジニアリングチームを組成するためにはどうすればいいか

  • Why culture and stories matter
  • Cultual "features" using examples from U.S. tech companies
  • Tips ....

Why culture and stories matter

  • かんばんやAgile、Trello/Githubといったツールを使ってコラボレーションしている

    • ツール自体が Culture ではない
  • 他のチームじゃなくて、ウチのチームに来る、というのは文化で決まる

  • 決してコードだけのコンフリクトではない

    • クリエイティブな問題をどう解決するか?が文化によって変わる
  • ほかと比べてこっちが重要だ、というのが文化

  • アメリカではチームの多様性が問題になってきている

    • チームにもっと女性を入れる、とか
    • データサイエンティストにどうやってコーディングを覚えさせるか
    • 広範にすべての人々にコーディングを教えることが課題
      • Code.org
      • TechCrunch #hackath_n
  • OSSの裏は企業のサポート

    • 公にサポートしていることの重要性
  • エンジニアをリモートで仕事させるための仕組み

    • Slack
    • オンラインで応答ができるかぎり、在宅勤務で構わない
  • 卓球テーブルがある仕事環境

    • エンジニアがリラックスできる環境
    • ペットを連れて出社してもいい、とか
  • 上記のそれぞれが文化というわけではない

  • 特定の規範的なレシピを伝えるつもりはない、正解はない

    • トレード・オフを伴うもの
  • ストーリーを語って、文化を説明する

    • ストーリーは文化的なアイデアを伝えるもの
  • Sapiensという書籍

    • 人間が協力することによって「企業」という物語に繋がった
    • 「国」や「地域」もストーリー
  • エンジニアには心理的なものは受け入れ難い、と言われている

  • ...

    • 我々が存在する意味
    • 知識の共有
    • モチベーションを高める
  • なにを気をつけるべき?

    • Become a better leader
    • Inspire others to join your team
    • Keep your team together
  • なぜエンジニアリング文化が重要か

  • twilio

    • 電話ベースのコミュニケーションアプリ
    • エンジニアを繋ぐ方法が欲しかった
    • twilio がエンジニアを繋いでいる
    • エンジニアは皆 twilio が好きだった→購入した
    • twilio は、エンジニア間を流れていた物語を実現した
      • twilio は愛されています、あなたの開発者に聞いてみてください
    • エンジニアは twilio で働きたい、とも思った

Cultual features & examples from U.S. tech companies

特徴として重要なのは、自主性・『自律性』

あまり管理されないで仕事をしたい、と思っている

  • Googleはエンジニアによって設立され、エンジニアのための企業である
    • ユニークな文化を有する
      • マネージャーを認めない
      • マネージャーにあれしろ、これしろと言われたくない
      • 極力マネージャーを減らす
    • あるときは全くマネージャーを無くしてみた
      • トップ配下はフラット
      • 結果、混沌とした
      • マネージャー層をもとに戻した
      • とは言え、Googleはマネージャーの比率は非常に少ない
    • マネージャーが少ないということは、自分で頭を使える自律性のある人を雇わなければならない
  • Googleは実験をすることを好む
    • 20%ルール
      • 毎週1日は好きなことができる
    • 多くのイノベーティブなプロダクトは20%ルールから生まれた
      • インスピレーションは、自由な発想から生まれる
    • 他の企業も少なからず20%ルールに近いものを導入しようとしている
      • ハッカソンでいつもと違うチームで何か意味が無いかもしれないことに取り組む
    • エンジニアに自律性を生ませる
  • トレード・オフはある
    • Googleは非常に大きな企業
      • Alphabetという企業に作り直した
      • 自分自身の文化を一旦、破壊することも重要
      • 文化を変えるために必要

インパクトを与える』

  • facebookは映画化された、内容は非常に正確
    • facebookという文化がどうやって作られたか
    • マーク・ザッカーバーグは、自分がやろうとしていることを阻害するものを予見して、先手を取って阻害するものに対応していた
    • これから先あるだろうハードルを、早い段階で飛び越える
    • 速く進んで、色んな物を壊す、という文化
    • 入社後すぐに、1日3回リリーストレインとしてリリースする
      • エンジニアとしてすぐに本番環境に影響することができる
      • facebookはあまりQAしない
        • 新しい機能は、まず社内で試験運用される
    • 入社して2日目でリリーストレインに乗せることを期待される
      • エンジニアは大きくエキサイトする
    • もちろんトレードオフはある
      • 私のモットーは "Move Fast AND Break Things."
      • facebookザッカーバーグは、迅速に動いてStableなインフラを持ち続けること、とある時に言った
      • 破壊を限定的にするメッセージ(文化を変える)を伝えた

『Ownership』

  • Etsy

    • 手作りのものだけを売るマーケットプレイス
    • ユーザの文化と結びついている
      • 自分で構築し、自分で運用してください
    • 自分が書いたコードがうまく動かなかったとき、自分で責任を持ってなんとかしないといけない
      • Ownershipを重視する
      • 他の人・QAに頼らない
      • コードをリリースする前にチェックリストを自分で確認する
      • 自分のコードを書いて所有することにプライドを持つ文化
  • NETFLIX

    • クラウド上で完全に運用している最大の企業
    • モノリシックなアプリケーションだった
      • 大きな障害が発生し、3日間Downした
      • エンジニアを集めて、これが2度と起こらないようにしよう、と話し合う
      • モノリシックなアーキテクチャを分解する
      • マイクロサービス化する方向へ
    • 30以上のチームが、それぞれのサービスを担当
      • 各サービス担当者が自サービスへの責任を強く持つ
      • 組織の文化を変えるきっかけに

『学習(Learning)』

エンジニアは誰も学習に意欲的

  • Pivotal Labs
    • 学習を全く新しい次元に引き上げた企業
    • XP を採用
      • ペアプログラミング
        • 2人のエンジニアが常に一緒に仕事をする
        • お互いのコードを見て意見を出し合う
      • Pivotalはこのモデルにコミットしている
      • ビジネスにとっては2倍の人手が必要なので影響する
        • 本来は1人時間でも、Pivotalは2人時間になってしまう
        • 競争力としては支障となる
      • この方針を曲げなかった
      • 教え合う、成長できる文化に
      • 新卒でジュニアな人材を採用しても自然に育成できる環境になった

ストーリーテリングのポイント

ポイントを絞る

  • Etsyの例
    • Code as Craft
      • コードは工芸品・芸術品
    • エンジニアによるアウトプットの公開・共有
      • エンジニアとしてマーケターの気分になって多くの人に話す
      • エンジニアのチームが毎日ブログで発信する
        • Etsyのエンジニアが普段何をしているか
    • 条件が箇条書きになっているエンジニアの求人広告はつまらない
      • ストーリーを語る求人広告の方が数倍魅力的
    • すべての企業にヒーローは必要
      • CTOが語るヒーロー(リーダーシップ)の物語

皆さんが働きたいと思える物語を語る企業に出会ってください

基調講演2 ポスト・ムーア法則時代のコンピューティング

佐藤一郎
国立情報学研究所 アーキテクチャ科学研究系 教授

ムーア法則の状況

限界が来ている

  • 半導体の企業はムーアの法則を満足するために技術革新を行っていた

    • 半導体微細化が1/kになれば、速度はk倍、集積度はk2倍、消費電力は1/k倍になる
      • 当初は1年で2倍→18ヶ月で2倍
    • 高速化、高機能化、小型化、省電力化、大容量化、低価格化 が実現
    • ハードの革新によって、ソフト(アプリ)の性能の悪さは無視できた時代
  • ムーアの法則の綻び

    • 微細化のスローダウンが進行中
      • Intelも36ヶ月で2倍
    • 3つの限界
      • 半導体製造技術的な限界
      • 電力的な限界★
        • スケーリング則の破綻
          • 集積化しても消費電力あたりの計算量が上がらない
        • ダークシリコンの増加
          • 発熱を考えると消費電力が100Wを超えるチップは作れない
      • 経済的な限界★
        • 半導体工場の建設費コストの巨額化
          • 14nmクラスの半導体工場は1兆円越え
          • 製造最小ロットの増大
  • ムーアの法則まとめ

    • プロセッサの性能は消費電力に依存
      • 微細化しても性能はあがりにくい
    • プロセッサのコストはリソグラフィ技術に依存
      • 微細化してもコストはさがりにくい
  • 1ドルあたりのトランジスタ数は減っている

    • 28,14nm以降の微細化で、経済的なメリットがない

フィンテックについて何か話さないと

  • フィンテックと称される技術で新しい技術は少数

    • ブロックチェーンとか
  • 技術的なこととそれ以外を区別すべき

  • ブロックチェーンのProof of Work(PoW)はコンピュータの性能向上が前提

    • ムーア法則の限界はブロックチェーンの限界にもなり得る
    • 対策:
      • PoW専用マシンを作ってエネルギー効率を上げる

ポスト・ムーア時代に起きること

  • 半導体技術を前提にしたコンピュータの高性能化が期待できない時代

    • 今、遅いソフトウェアは、ずっと遅い
  • Intel Xeonは性能向上を続けられるか

    • Xeonは複雑な回路であり、微細化しても消費電力は大きく下がらない
    • 限界が最も近い

ポスト・ムーア時代のクラウドビジネス

  • クラウドのコスト大半は電力代
  • 最新サーバに置き換えても計算量はなかなかあがらない

ポスト・ムーア時代のベンダー&SI事業者

  • IT業界の既存ビジネスモデルは成立しない
    • 最新コンピュータに換えても、性能向上しない
      • システム更新メリットがなくなる
    • ユーザ企業の関心事は、如何に現用ハードウェアを長く使うか、に移る
      • 新規事業者には厳しい

ポスト・ムーア時代の性能改善(ハードウェア編)

  • 正解は見つかっていない
    • 色々な試行錯誤が行われている
    • 方向性1:メニーコア化
      • 消費電力に限界があるのでクロックを下げないといけない
      • 並列化に向かないビジネス的な処理には逆に性能劣化も
      • マルチスレッドプログラミングは難しい
    • 方向性2:大容量メモリを活かす
      • メモリは活性化があまり行われないので発熱の問題はあまりない
      • データをHDD/SSDではなく、メモリに置くことで高速化
    • 方向性3:不揮発性メモリの利用
      • 不揮発性メモリ(NvRAM)
      • MRAMやReRAM、HDD/SSDと比べて高速でDRAMよりも容量が大きい
    • 方向性4:専用ハードウェア・GPUによるアクセレーター
    • 方向性5:分散処理(サーバ台数)でカバー
      • 故障の問題
      • 世界には2種類のコンピュータしかない
        • 壊れたコンピュータ
        • いずれ壊れるコンピュータ
      • データを複製せよ
        • コンピュータが壊れるとデータも失われる
      • 読み出しは手近な複製データに行う(処理を分散化)
      • 更新の難しさが課題
    • 方向性6:Rack−Scale Architecture
    • 方向性7:....

      • AI処理向けチップ
        • AI処理はそんなに高性能を要求しない、サメの脳みそでもいい

ソフトウェア技術者に求められること

結論:余計なトランジスタを使わない

  • 適切に無駄な処理をなくす
  • ソフトウェアによる性能向上

    • 科学的に捉える必要性
  • アルゴリズムの仕組みを理解しているか

    • 対象となる処理に対して適切なアルゴリズムを選択・設計しているか
  • ハードウェアに応じて最適なソフトウェアを作る

  • ハードウェアやソフトウェアの原理を扱う

  • コンピュータサイエンスの知見は不可欠

  • ソフトウェアの性能改善が正当に評価される時代になる

基調講演3 日本の情報システムの未来革新に向けて ~日本の金融業界におけるテクノロジーの可能性と今後の情報システム部門の進むべき道

浦川 伸一 氏
損害保険ジャパン日本興亜株式会社 取締役 常務執行役員

何かにつけて、コードで表すとこのように、と言った感じにコーディングが好きなことが伝わってくる、コードのレベルまで細かく話すかた

Intro

  • 認識している時代背景

    • VUCA
      • Volatility(変動性)
      • Uncertainty(不確実性)
      • Complexity(複雑性)
      • Ambiguity(曖昧性)
  • 2つの変革

    • 1.Digital Transformation
      • R&D組織を立ち上げ
    • 2.Legacy Transformation(今日の主題)
      • 合併を重ねて基幹システムがスピード経営の足かせに
      • オープン系での刷新を決断
  • 現行システムの現状

    • Complex
      • きめの細かさ
    • Fat
      • かゆいところに手が届く
    • Narrow
      • 慎重かつ丁寧な対応
  • →よかれと思ってやってきたことが、この結果

    • →この逆をやろう
  • 3つのS

    • Simple
      • わかりやすい商品・簡素な事務
        • 満期を迎えた商品から新しい商品に載せ替え→データ移行をやらないことに
      • バッチレス
    • Slim
      • 大幅なサイズダウン
      • 手書きコード量の削減
    • Speed
      • ....

Core Architecture

フロント系 ー DB系

  • 全体Architectureの検討ポイント
    • 1.SoR/SoE
    • 2.Language Environment
    • 3.Microservices
    • 4.Framework
    • 5.Cloud

1.SoR/SoE

2.Language Environment

  • Javaか?

    • せいぜい言語の中で22%
    • デファクトとなったJava
    • 決して可読性の良い言語ではない
  • Pythonは簡潔で好き

3.Microservices

4.Framework

5.Cloud

  • すでに多数のクラウドサービスを利活用中
  • Japan Cloud 日本にデータを置く

情報システム部門の変革

ランチセッション オープンソースCMS Drupalの紹介

井村 邦博 氏 株式会社メノックス

(不参加)

昼食後、マクニカネットワークス福留さんに挨拶 CircleCIの Kin さんとも挨拶

A-1 マイクロサービス・アーキテクチャのパターンとベストプラクティス

Patterns & Practices of Microservices
Wesley Reisz 氏 @wesreisz
C4Media社

QCon Product Manager

  • マイグレーション
    • 4年前、TomcatJavaアプリケーション
      • スケールアップ・スケールアウト
      • DBがFat化(スケールアップ)
    • 2年前、Cold / Hot構成にシステムを2分化
      • Reporting用DBの導入
    • Hot / Hot構成へ
    • クラウド環境への移行
      • 多数のアプリケーション
      • マイクロサービスアーキテクチャの基本的な要素が欠けていた

マイクロサービスアーキテクチャのパターンを紹介

マイクロサービスの名付け親(Adrian Cockcroft、NETFLIX

"Loosely coupled Service Oriented Architecture with Bounded Contexts"

  • 疎結合であること
  • 境界があるコンテキスト
    • → DDD

Why Microservices?

モノリシックなシステムはモデルが肥大化し、後発のエンジニアが追いつけなくなる

マイクロサービス化を進めることでクラウド化が簡単に出来るようになった

  • マイクロサービスは進化するアーキテクチャ
    • 万能薬ではない、問題が起こる度に進化し続けなければならない
    • 新しい技術を受け入れやすくなる

FIRST PRINCIPLES

DevOps culture is a MUST.

マーティン・ファウラー - 短時間でプロビジョニングができなければいけない - 基本的なモニタリングができなければいけない - 高速にアプリケーションをデプロイできなければいけない

進化し続けるアーキテクチャ

マイクロサービスには常に変化があるから、先にレイヤーの図を描く訳にはいかない

Scale CUBE

  • 水平方向のスケール
  • 機能の分割
  • データのパーティショニング

CAP理論

  • Consistency / Partition Tolerance
  • Abailability / Partition Tolerance

1. Technical

  • TOOLS
    • "Everything is a tradeoff just be intentional about them"

ツールに飛びついてはいけない

  • SPINE MODEL
    • Needs
      • まずはニーズを見極めろ、ユーザ・要件を見ろ
      • 書き込み要求が高まる箇所と読み込み要求が高まる箇所のバランスをとる
    • Values
    • Principles
    • Practices
    • Tools

アーキテクチャパターン

  • Event Sourcing

    • イベント中心のアーキテクチャパターン
    • イベントをサブスクライブして、イベント駆動で各機能が処理を行う
    • 非同期でImmustableなState変更

    • Immutable Events

    • Recreate the exact state
    • Performance / Load testing
    • Increase in complexity
  • CQRS(コマンドクエリ責務分離)

    • サーバの機能をコマンド(副作用あり)とクエリ(副作用なし)で完全に分ける
    • Decouple queries from Commands to scale each Service
    • オペレーションをRead/Writeに分ける

      • Read側だけスケールアウトできる
    • Domain Specific Models

    • Scale
  • CIRCUIT BREAKER

    • ダウンしたサービスにアクセスしているサービスがハングする
      • ブレーカーを落とす(冷却期間を置く)
      • フラグをたてて、一定時間アクセスしないようにする
      • 別のサービスを立ち上げ、そちらにアクセスするようにする
      • 通常通りのサービスに戻ったら、使うようにする
    • Prevents Doomed to Fail
    • Three states

2. Operational

  • Observability

    • Need consistent, structured logging
    • Logs are not for humans
    • Logstash, Elasticsearch, Kibana works
  • RPC vs HTTP

  • JSON vs Binary
  • Speed/Performance vs Readability
  • Measure serialization, transmission, deserialization costs

  • Look into:

    • Zipkin
    • Prometheus
      • -> Best way to understand Fanout
    • サービスの裏で何が起きているかを把握する

3.Cultural

  • Conway's LAW
    • Organizations which design systems .. are constrained to produce designs which are copies of the communication structures of the organization.

アーキテクチャには組織が反映される

  • Model
  • One ....

ちゃんと意図を持った意思決定をする

頭のなかでイメージが整理できる範囲から考え始める

終わりに

先に決定した判断を見直す必要がなければ、あなたはオーバーエンジニアリングしている

A-2 クラウド・ネイティブなデータ・パイプライン

Cloud Native Data Pipelines
Sid Anand 氏 @r39132
Agari

http://www.slideshare.net/r39132/cloud-native-data-pipelines-qcon-shanghai-2016

  • About Me

  • AGARIの紹介

    • Mailの保護
    • BtoC の Consumer Protection を BtoB にも展開中
    • eMail の trust score を算出
  • 2種類のデータパイプライン

    • BI (Business Integration)
      • Analyst 向けDBの提供(非同期)
    • Predictive (予測型)
      • Data Sourceからリスクモデルを算出してスコアを他のDBへ格納
      • リスクのランクごとにWebServiceから参照
  • おすすめコンテンツの抽出

    • 各所で使われている技術
  • Cloud Native Data Pipelines

    • 大手の技術企業は自社内でデータパイプラインを構築している
    • 大半のスタートアップはデータパイプラインをクラウド上で構築する必要がある

    • Correctness

      • Data Integrity
      • Expected data distributions
    • Timeliness
      • All output within time-bound SLAs
    • Operability
      • Fine-grained Monitoring & Alerting of Correctness & Timeliness SLAs
      • Quick Recoverability
    • Cost
      • Pay-as-you-go
  • Quickly Recoverable

    • Maintainability
      • 壊れても簡単に直せること > 壊れにくい設計にすること
      • 想定外の使われ方をすると壊れやすい、それを前提にする必要がある
      • 回復時間(MTTR)を短くすることが大切
  • Use-Case

    • Message Scoring
      • S3ストアされた大量のデータソースをもとにApache Airflow(Spark)でスコアリングし、別のS3に保存し、SNS/SQSで配信する
      • このバッチ処理は、1日の中で1時間しか動かない
      • EC2で構築すれば23時間分はコスト削減になる
      • ASG(Auto Scaling Group)で処理の流量に応じてCPU使用率が一定になるよう自動スケールさせる
  • Tackling Operability

    • Apache Airflow
      • Managing DAGs
      • Perf. Insights
      • Alerting
  • Use-Case

    • Message Scoring(Near Realtime)
      • Kinesisに大量データを投入、ASGでスコアリングして、結果をKinesisへ、KinesisインポータでDBに登録すると並行してKinesis経由でAlert通知
  • Apache Avro

    • self-describing serialization format that supports
      • primitive data types
      • complex data types
      • many language bindings
    • テーブルの中でスキーマ情報が99%で実データが1%のような構成はOverheadが高い
    • Schema Registry(Lambda)を使ってMessage Sizeを削減
    • スキーマを一意のハッシュKeyで登録、各メッセージはSchemaハッシュのみを格納する

QA Time

  • Airflow はHA構成に対応していない
    • まだ開発者が少なく対応できるリソースがない
    • 誰かやってくれ〜PR募集中

A-3 今どきのアーキテクチャ設計戦略

鈴木 雄介 氏
グロースエクスパートナーズ株式会社 アーキテクチャ事業本部 執行役員

http://www.slideshare.net/yusuke/qcon-tokyo-2016

今どきのシステム開発

  • 山のようにそびえる基幹システム
  • 波のように日々変化するシステム

  • SoR(System of Record)

    • 情報を正しく記録するためのシステム
    • 安全・安心・安定の基幹システム
  • SoE(System of Engagement)

    • 顧客や取引先との「絆」を作るためのシステム
    • 最新の状況を表示し、判断してもらうためのシステム
    • 機能はユーザごとに最適化され、高頻度で改善されていく
  • SoE側のシステム

    • 正しい使用を定義できないシステム開発
      • SoE型には「正しい仕様」は存在しない
      • 社内には「本当のユーザー」がいない
    • 仮説検証型の進め方にするしかない
      • 「仮説としての仕様」から始まる
  • 一方で、企業システムとしての制約

    • SoEはSoRと必ず連携する
      • 基幹システム側は期日ありきで計画主導プロセス
    • 社内部門/業務と必ず関わりがある
      • 多くのビジネスはITだけで完結しない
    • ビジネスは簡単に止められない
      • 社会インフラに近いほど「止まっては困る」
  • フィードバックと改善

    • SoEではフィードバックと改善のリズムを作ることが大事
      • リズムの速さは「ビジネスによる」で問題ない
    • どうやって継続的に機能を追加していくのか
      • アジャイルとかWFの議論ではない
      • 時間制限の中でやる仕事、と、終わるまでやるべき仕事

アーキテクチャ設計基礎

  • アーキテクチャ=システムの分け方と組み方(by ISO)
    • システムのミッションに従い
    • システムの置かれた制約と前提としながら
    • システムに関わる複数の利害関係者の関心事を整合させ、
    • ライフサイクル(設計から保守)まで意識した
    • システムの分け方と組み方のこと

遊星歯車

  • 「振る舞い」と「構造」

    • 振る舞い
      • 機能と非機能
    • 構造
      • 動的構造と静的構造
  • アーキテクチャ設計

    • ある振る舞いを実現する構造を導く作業
      • 「振る舞いへの要求」を理解して構造を定義する
      • 「システムの設計や実装」は事前に決められた定義に従う
  • アーキテクチャ設計の理想的な進め方

    • 必要な振る舞いを定義し、それに対する構造を設計する
      • 振る舞いが正確に定義できているほど、適切な設計を行える
    • 実装が始まる前までに、すべての要求が明確で、それに対して最適な構造が定義される

今どきのアーキテクチャ設計

  • アーキテクチャ設計のジレンマ

    • 要求が曖昧では構造が定義できない
    • 振る舞いを見ないと要求が分からない
    • 構造がないと振る舞いを実現できない
  • SoEでは正しい要求が先にない

  • 変更に対応する構造を作れるか?

    • 初期段階では最適な構造を確定できない
    • 必要な機能が段階的に足されていく
    • なんらかのアーキテクチャ設計戦略が必要になる
      • 予測型、犠牲型、拡張型
  • 予測型

    • 追加される機能に対して同一の構造を割り当てる
      • 予測が正しければ、の話
  • 予測増改築型

    • 予測を長期間維持してこじらせたパターン
      • 保守性が悪く、コストが増加する(別名:温泉旅館型)
  • 犠牲型

    • 最初に作る構造は最低限にしておき、のちに再整備する
      • 技術的負債をガツッと返済するパターン
      • 機能移植にコストはかかるが長期間維持できる
  • 拡張型

    • 構造そのものに拡張性を持たせる
      • ※天才に限る
        • Eclipse(plug-in構造)は15年以上続いている構造
  • 設計戦略の整理

    • そもそも「予測型」には限界がある
    • いつでも「犠牲型」になる覚悟は必要
      • とはいえ毎回犠牲型とは言い難い
    • 「拡張型」をベースにしていく
      • 自分で作らず、他人が作った拡張構造を利用する
  • 他人が作った拡張構造に頼る

    • OSSフレームワークを利用する
    • コミュニティが蓄積しているノウハウに頼る

      • ex.) Spring Security
        • 認証と認可に関する基本的な機能があり、自分で拡張できる構造になっている
    • クラウドサービスを利用する

      • 利用すべきはPaaS
      • パターンに従って実装することで構造が拡張される
    • 構造だけではなく非機能要件まで含めて構造が保証する
      • PaaSの進化
  • サーバーレスアーキテクチャ

    • コードを配置するだけで実行される
    • インフラのマネジメント不要でオートスケール
      • シェルっぽいもの、トリガーやタイマーのような位置づけとしていい
    • 処理内容には制約がある
    • 使い過ぎはピタゴラスイッチ状態になるので注意
  • 機能ごとに最適な構造を用意するのは無駄か?

    • 技術の成熟に伴い、ニッチな構造が増えている
      • ビッグデータ:大規模分散処理
      • リアルタイム処理:ストリーミング処理
      • スケールするデータストア:NoSQL
      • 検索
    • すべてOSSでもPaaSでも利用可能
  • 拡張型×犠牲型

    • 基本構造を変えずに、必要に応じて拡張・再構築していく
  • その集大成がマイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

  • メリット

    • モノリシックなシステムでは変更が全体に影響する
  • カナリアリリース

    • Blue−Greenで徐々に移行させる
  • いかにサービスを管理するのか

    • ドメインは重要だが、正解はない
    • NETFLIXのトップページでは500個のサービスが動く
  • 疎結合を維持する

    • データ分離
      • イベントソーシング(CQRS)
    • テスト戦略
      • Test Doubles
        • テストを動かすのは大変なのでスタブやモック
      • Dark Canaries
        • 本番環境上に開発者用のテスト版をリリース
        • 本物を使ってテストする(ただし、できないものもある)
      • Consumer-Driven Contract testing
        • コンシューマーが要求するCPI挙動を契約として定義し、プロバイダが契約を検証して破壊的変更を防ぐ
    • 不整合の許容
      • Amazonのクーポン」
      • 非同期メッセージによる不整合を許容する
        • データのリアルタイムな整合性を捨てることの金銭的価値
  • 知的なルーター

  • サーキットブレーカー

    • 階層型障害への対応
      • 自分の身は自分で守る
    • 異常処理への対応
  • 分散トレース

    • サービスを横断したログのトレース
  • 障害注入テスト

    • Chaos Monkey
    • 平日日中にサーバをランダムにダウンさせるためのOSS
  • マイクロサービスプラットフォーム製品

    • Spring Cloud
  • ツール群

    • CI/CD
  • エンタープライズ適用

    • 本質:サービス同士を疎結合にして個別変更を許容する
      • サービスの大きさを気にしすぎない
    • 品質の考え方について整理すること
      • サービス全体を保護するために小さな障害を許容する
    • 明日からでも始めるべき
      • 今のシステムから1つ目のサービスを切り出せるか
      • 「マイクロサービスで全体を再構築」はうまくいかない

アーキテクトの役割

  • プラットフォームの選択は重要

  • アーキテクトがいるのは塔か現場か

    • 塔の上から俯瞰するvs現場の関心事を解決する

休憩 & 展示 & ライトニングトーク

太田 昌文 氏「RaspberryPi最新動向」

(不参加)

A-4 サーバーレス・アーキテクチャ

伊藤 直也 氏
株式会社 一休 執行役員 CTO

https://speakerdeck.com/naoya/serverless-architecture

  • 結論

    • サーバーレスアーキテクチャとは
      • 単純にはFaaSを使ったシステム
      • ステートレスなFaaSがリアクティブ、マイクロサービス、コレオグラフィへと導く
    • 現場感覚では「運用が楽でスケールして、安い」
    • 銀の弾丸ではないが、応用領域は広がると思われる
    • ちょっとしたタスクをこなすためや、マイクロサービスの実現手段として、引き出しの一つに入れておいて損はない
  • サーバーレス

    • Shared Nothing

サーバーレスアーキテクチャとは

  • 2つの「サーバーレス」

    • ハードウェア的意味での「サーバー」がない
    • 常駐プロセス的な意味での「サーバー」がない
      • Function as a Service(FaaS)の話
      • 今日は主にこちらの話
  • AWS Lambda

    • serverless framework を利用
    • $ serverless deploy
  • Lambda ファンクションはサーバーレスで実行される

    • コンテナで実行される
    • コンテナは実行時に作成され、終了時に破棄される
    • 常駐プロセスではない。CGIに近いモデル
  • Lambdaファンクションはステートレスである

    • ステートを保持できない
    • ステートレス(Shared Nothing)
      • 何か問題が怒っても、別の実行には悪影響を与えない
      • スケールしたかったらもっと起動すればいい
  • AWS Lambdaはスケールするし、安い

    • イベント量に合わせてLambdaが自動でスケール
      • ステートレスなのでスケールしやすい
      • プロセスが落ちてた。。。なんてことがない。安全
    • 計算した分しか費用はかからない
      • EC2を立ち上げっぱなしにするのにくらべ、かなりお得
  • サーバーレスアーキテクチャ

  • 利用事例

    • AWS S3にアップロードされた画像のサムネイル画像を非同期で作成

      • イベント(JSON形式)駆動
    • エンジニアの書類選考をSlackに通知

      • Redmine -> AmazonAPI Gateway -> Lambda -> Slack通知
        • 以前はHeroku Bot を常駐させて通知していた
    • 行動ログ収集 & 分析

      • Appサーバ(fluentd) -> Kinesis -> Lambda -> S3 -> Lambda -> GoogleBigQuery
    • 紙面ビューアーを支えるサーバーレスアーキテクチャ(by日経新聞

      • 複数のLambdaが連動して処理
  • FaaSでイベント駆動設計を突き詰めておくと、自ずとマイクロサービスが見えてくる

  • CGIはリクエストごとに実行、終わったら破棄

    • アプリケーション全体を毎回 fork がとても非効率
  • 常駐プロセス prefork ・・・プロセスを作っておいて常駐
    • オーバーヘッドが少なく安全だが、並行性能に難
    • スケーラビリティに難
      • メモリフットプリントが大きい。
      • プロセス数が最大同時接続数を決めてしまう(C10K問題)
  • イベント駆動モデルによる並行処理
    • like Node.js
    • 並行性能が高いが可用性に難
  • 起動に伴うオーバーヘッドが少なければ、毎回実行で構わないのでは・・・

    • これがLambda
  • Shared Nothing という制約

  • イベントへの反応として処理を記述する

  • Reactive マニフェスト

    • メッセージ駆動(Message-Driven)
      • 伸縮性(Elastic)
      • 対障害性(Resirience)
        • 高レスポンス(High response)
  • Erlang VM

    • ErlangVM は非常に小さい → 高速に起動できる
    • 起動が十分に高速なら、都度実行すればいい、の例
  • それぞれのLambdaはマイクロな関数になる

    • 小さな(マイクロな)関数をイベントで(疎結合に)組み合わせる
    • FaaSは自然とマイクロサービスを指向する
  • オーケストレーション vs コレオグラフィ

    • オーケストレーション
      • オーケストラによる演奏方法
      • 中央の指揮者がサービスの呼び出しをコントロールし、ビジネスプロセスの実行を指揮する
      • リクエスト・リプライ
        • サブルーチン呼び出し・メソッドインヴォケーション
    • コレオグラフィ
      • バレーや舞踏などのダンサーへの振り付け
      • サービスの呼び出しをコントロールしたり、ビジネスプロセスの実行を指揮する存在はいない
      • イベント駆動
  • スターバックスは2フェーズコミットを使わない

  • マイクロサービスを指向するならコレオグラフィ

    • 非同期のイベント連携
      • 大幅に分離されたサービスを生み出せる
  • FaaSは自然とコレオグラフィを指向する

  • ぶっちゃけどうなの?

  • FaaSを用いたサーバーレスアーキテクチャは、マイクロサービスの具体的な実現手段の一つ

  • どういう時に使うの?

    • 小さなユースケースでは積極的に使えばいい
    • 大きなユースケースではいつ使うのか・・・まだ言語化できてない
      • オーバーヘッドは比較的小さいがゼロではない
    • サーバーレスとそうじゃないのを組み合わえる事例が増えてる
  • サーバーレスの今後

C-5 DevOps導入&実践の落とし穴 - Disciplined DevOpsに見る体系的アプローチ

藤井 智弘 氏
日本ヒューレット・パッカード株式会社

Disciplined Agile

  • DevOpsが腹落ちしない

    • 共通定義が難しい(ひとりひとりのDevOpsが違う)
    • 関係者ごとに目線・目的が異なる
  • 海外では Agile が有効活用され活況

  • 日本では

    • 強いベンダー依存
    • 異なる体制
    • "しきたり"駆動
    • コスト < キャッシュアウト
  • DevOpsの前に DAD

    • Disciplined Agile Delivery
    • DAD の基礎
      • SCRUM の拡張
      • ステークホルダーがどうやって合意形成しながらプロジェクトを進めていくか
      • ゴール駆動アプローチ
  • Disciplined DevOps 導入におけるDAの位置づけ

    • DevOps 以前に Agile ができていない
  • 継続的改善のために

    • IT4IT
    • IT Value Chain

AWS ソリューション Day 2016 セキュリティ&コンプライアンス

AWS ソリューション Day 2016 セキュリティ&コンプライアンス

日時: 2016 年 8 月 31 日(水) 9:30-16:30
会場: ソラシティ カンファレンスセンター(東京/御茶ノ水
来場: 参加無料(要事前申込)
定員: 330名

https://aws.amazon.com/jp/solutiondays20160831/

10:00-10:05 オープニング 長崎 忠雄

(アマゾン ウェブ サービス ジャパン株式会社 代表取締役社長)

現在13リージョン→今年中に17リージョン
シンガポールの銀行(DBS)が情報資産の50%をAWS化を決定
 →世界中の金融機関から問い合わせが殺到

10:05-10:45 基調講演:クラウドサービスセキュリティの国際規格 ~利用者責任と監査の活用~ 永宮 直史

(日本セキュリティ監査協会(JASA) クラウドセキュリティ推進協議会 事務局長)

  • 政府統一基準におけるクラウド利用の基準

    1. 情報の格付けに従ったクラウドサービス利用の判断
    2. 外国法が利用されるリスクの評価
    3. サービス中断時・終了時の円滑な業務の移管
    4. ベンダーロックインをさせないルール・独自仕様の回避・利用者情報取得の自由
    5. 情報流通経路全般にわたったセキュリティ設計・セキュリティ要件
    6. 監査報告の内容や認証制度の適応状況を踏まえた事業者の信頼性の評価
  • 監査にする記載(ガイドP118)

  • ISO/IEC27017

    • 情報セキュリティの共同責任
      • クラウド事業者は、利用者支援のため情報セキュリティ監査に必要な情報提供・機能提供をすること
      • ↑の共通的な基準を表したものが「ISO/IEC27017」
    • ISO27001, ISO27002 のクラウド
  • CSC自身による情報セキュリティマネジメント

  • CSCのための情報セキュリティ機能および情報の提供(サービスマネジメント)
  • CSPの責任範囲における情報セキュリティマネジメント
  • 共同責任

    • CSC(Cloud Service Customer)
      • 1.2. が責任範囲
    • CSP(Cloud Service Provider)
      • 2.3. が責任範囲
  • 監査

    • 文書化した証拠を提出
  • クラウド情報セキュリティ監査の特徴

    1. クラウドのリスク(see WebSite)
    2. プロセスの透明化
    3. 監査調書の雛形を提供
  • クラウド利用者がやるべきこと

    • リスクに応じた利用と対応
    • 監査報告の内容や認証制度の適応状況を踏まえた事業者の信頼性の評価
    • 利用者が負うべき責任を果たすこと
      • クラウド提供者との責任分界の確認と対応
      • クラウド利用に対するガバナンスの確立
      • 情報セキュリティの運用

10:45-11:25 基調講演:サイバーセキュリティ研究の最前線 井上 大介

(国立研究開発法人 情報通信研究機構 サイバーセキュリティ研究室 室長)

今日の資料 https://goo.gl/9JR2eU

  • NICTERとそのスピンオフ技術たち

    • グローバル観測(ダークネット)
      • NICTER
        • ダークネット from-to の通信を観測
      • DAEDALUS
    • ローカル観測(ライブネット)
  • 最近はIoT機器からの通信が多い 23port telnet

    • 日本国内では監視カメラが多い
  • クラウドからクラウドへの攻撃

  • AWSNIRVANA

    • AWSのセキュリティ機能は多々ある
      • Amazon Inspector(脆弱性自動検査)
      • AWS CloudTrail(エンドポイント監視)
      • VPC Flow Logs(通信監視)
      • Amazon Cloud Watch(アラート通知)

11:25-12:05 基調講演:日本のサイバーセキュリティ政策と政府等の対策の動向 三角 育夫

(内閣サイバーセキュリティセンター(NISC) 副センター長 内閣審議官)

新たな「サイバーセキュリティ戦略」について - サイバー空間 - 5th Domain of War - 「無限の価値を生むフロンティア」である人工空間 - 経済社会の活動基盤 - 土台・基盤の大半は「民間」によるもの

  • 政府統一基準の改定
    • 事案発生に備えた対処体勢(CSIRT)、対処・連絡手順などの整備にかかる規定の効果
    • 不正プログラム感染の発生を前提とする情報システムの防御策の強化
    • 情報及び情報システムへの不正アクセスの防止等を目的とする対策の見直し・強化
    • 新たなIT製品・サービスの普及に伴う対策事項の明確化

12:05-13:05 ランチ休憩

13:05-13:50 AWS グローバルコンプライアンス最新情報 Sara Duffer

(Sr. Manager, AWS Risk, Amazon Web Services, Inc.)

  • 規制対象業務とセキュリティ・アシュアランスにおけるグローバルの状況
  • グローバルな規制、および重要業務における原則
  • 各種リソース・情報

FinTech企業の100%はクラウドAWS)を利用

様々な形態の金融機関がクラウド利用を広げている
各国の法令規制に則ったかたちで導入を検討する必要がある

  • ガバナンスプラン
  • データセキュリティ
  • BCP
  • リバーシビリティプラン

  • グローバルにおける規制の原則的な共通要求事項

    • Location of Data
      • データの配置場所は「利用者」が決める
    • Vendor Oversite
    • Data Protection / Securty Addressed
  • AWS Quick Start Program : PCI DSS

    • Standard Architecture for AWS PCI-DSS
  • Securty Operation

    • SOC2 で対応
    • 日本におけるAWSの災害対策(Web)
  • gamedays

    • Activation and Notification
    • Validation
    • Engagement
    • Assessment
    • Recovery
    • Reconsititution
  • Data Protection / Securty Addressed

    • 3 lines defense
      • Operations
        • ビジネス環境のセキュアな構築
        • ex.) Cloud Formation
      • Supervisory
        • セキュリティ対策の有効性を確認
        • ex.) Inspector
      • Evaluation
        • 内部監査などの独立性を有する評価
        • ex.) CloudTrail
  • セキュリティに関する運用の自動化 : Automation

    • Design
    • Package
    • Constrain
    • Deploy
  • 情報リソース

13:50-14:35 セキュリティ・ソリューション・アーキテクチャ : データの完全性に関する考慮事項 Chris Whalley

(Life Science Risk Prgm Manager, AWS Security, Amazon Web Services Inc.)

Data Integrity in the AWS

  1. AWSの概要
  2. データ・インテグリティの概要
  3. トップ10 データ・インテグリティ・コントロール

  4. データの定義

    • Diffenent types of data require different types of data integrity controls.
  5. トップ10 データ・インテグリティ・コントロール

    1. リスクベースのソフトウェア設計、テスト
    2. データアクセスへの制限
    3. 監査証跡へのアクセスの制限
    4. データの同時記録
    5. 文書フォームのコントロール
    6. 定期的な監査証跡、データ、メタ・データのレビュー
    7. 監査報告の完全な保持
    8. 規制対象となるソフトウェア・アプリケーションの検証
    9. 経営上層部のデータ・ガバナンスの実装についての責任
    10. 経営上層部エラー・レポートについての前向きな検討の促進

14:35-14:55 休憩

14:55-15:40 金融機関のグローバルな規制対応情報

梅谷 晃宏 (アマゾン データ サービス ジャパン株式会社 セキュリティ アシュアランス本部 本部長 日本・アジア太平洋地域担当)

AWS FISC対応への情報は公開中 →MAS TRMガイドラインに関する情報

今泉 智(トレンドマイクロ株式会社 事業戦略推進部 業種営業推進グループ マネージャー)

シンガポールでCLOUDSECというクラウドセキュリティイベントを実施

MAS:Monetary Authority of Singapore シンガポールの金融当局規制

日本もシンガポールも、概ね同時期に、FISCやサイバーセキュリティが整備された

MAS TRM/FISCガイドライン 足立 道拡(NRIセキュアテクノロジーズ株式会社 ストラテジーコンサルティング部 部長)

世界的な災害脅威のうち、サイバー攻撃も災害に位置づけてられており、 先進国においては最重要項目にあげられていることも。

シンガポールは「働きやすい国」No.1(関税が低い)ため ビジネス・情報が集まる国なので、同様にサイバーセキュリティについて 国家レベルで関心が高い。

MAS TRMガイドライン9章 おもにサイバー攻撃対応の要求事項が記載されている。

15:40-16:25 製薬医療機器業界のクラウド対応(仮題)

梅谷 晃宏

(アマゾン データ サービス ジャパン株式会社 セキュリティ アシュアランス本部 本部長 日本・アジア太平洋地域担当)

AWSにおけるGxPクラウド GxPコンプライアンスのリソース

尾崎 孝一(東洋ビジネスエンジニアリング株式会社 ソリューション事業本部 関西ソリューション部 部長)

CSV(Computer Service Validation)

  • クラウド環境のバリデーション手法
    • ITインフラのクオリフィケーション+アプリのバリデーション
  • バリデーション対象システムのクラウド環境採用の課題
  • クラウド環境採用の促進に向けて

鴻池 明 (フィラーシステムズ株式会社代表取締役

16:25-16:30 クロージング

梅谷 晃宏 (アマゾン データサービス ジャパン株式会社 セキュリティ アシュアランス本部 本部長 日本・アジア太平洋地域担当)RR

Jenkinsオジサンからの卒業その4(werckerを試してみた)

Wercker

wercker.com

git push からのビルドとデプロイを自動化することを目的に作られたサービス。ビルドの後続処理をPipelineで繋いでいけるのが醍醐味らしい。

使い方

  • アカウントの作成は、独自アカウント作成 or GitHub連携で可能
  • 自動ビルドさせたいリポジトリを選択する
  • 対象リポジトリの設定を幾つかやる
    • deploy key の自動登録を任せるのが一番楽
  • 対象リポジトリのルートに wercker.yml を配置する
    • ここで気付いたけど、werckerがデフォルトで yml サンプル定義を提供しているのは、 GoLang, NodeJS, Python, Ruby ということが判明し、もしやJavaには対応していないんじゃないのorz として企画に幕を下ろしかけた
      • けども、いやまてよ。Dockerコンテナでコマンド実行するだけの汎用的な仕組みなら java 用のコンテナを指定しつつ Drone.io と同様に gradlew とかでビルドできるのではないか
  • ということで、Java ビルドがしたければ、ボックスの指定を box: java:8 とかにするべし
    • Gradleを使いたい場合は、gradlew 一式をリポジトリにcommitすること推奨
      • ビルドコマンドはこんな感じ
steps:
  - script:
      name: gradlew
      code: |
        ./gradlew
  - script:
      name: gradle build and test
      code: |
        ./gradlew check

色々と試行錯誤をしましたが、結果的にはちゃんとビルドできました☆

自動ビルドのトリガー

  • Push
    • default branch 以外のPushもブランチを区別してビルド結果を残してくれる
  • GitHub上のPRとも連携してくれる
    • ビルドがとおったPR(commit)か?が確認できて便利

ビルド結果

  • build badge のURLを提供
    • 過去数回分のビルド結果がRed/Greenの色分けで見れて、コードの安定度の目安にできるかも
  • ビルド成果物(Artifacts)の保存
    • できるのかもしれないけど、方法わからず
  • Mail通知
  • Slack通知

初めはヒントが少なくて戸惑いましたが、UIもイケてるし、多重度2まではFreeで使えるし、リポジトリ&開発者は無制限な模様。なかなか良い感じなのではないかと。

その他

  • 内部的にはコンテナ上でビルドが走る
    • 各ステップの詳細ログが見れる
  • UIはいい感じに今風
  • そういえば、醍醐味である自動デプロイや、Pipeline設定は試していなかった...

SampleでWerckerビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/sample-wercker