名もなき未知

エンジニアリングとか、日常とかそういうのをまとめる場所。アクセス解析のためGAを利用、Googleに情報を送信しています。商品紹介のためAmazonアフィリエイトを利用、Amazonに情報を送信しています。記事に関しては私が書いていない引用文を除いて自由にご利用ください。

DevSumi2020の1日目に参加していました

今更ですが、参加していたので書きます。

ブースについてはこちらの記事に移しました。

どんなイベントか

Developers Summit 2020

詳細に関しては公式サイトに説明を譲ります。ポイントとしては下記でしょうか。

  • 翔泳社さん主催の技術カンファレンスイベント
    • 具体的なテクノロジーからマネジメントまでと範囲は広め
  • スポンサー企業も多数参加している
    • ブースもある
  • カンファレンスについては事前予約制
    • 翔泳社IDを用いて2週間くらい前に予約
    • 僕はこれを忘れていて締め切り1時間前に一気に登録した

資料について

まとめてくださっている方がいるようなので、その人の記事をペタリ。

Developers Summit 2020 資料リンクまとめ - Qiita

聞いたセッションについて

とりあえず申し込めたのが下記の3つだったので、それを聞きに行きました。

直書きのメモもあるのですが、流石にそれを公開するのはちょっと(というか会社でどう生かしていきたいか、みたいなのもチラホラあってコンプラ的に怪しい)と思ったので、雑に切り貼りして公開します。

GitHubMicroSoftが機能リリースする舞台裏

MicroSoftパート(前半)

大事なことは下記3つのことでした。

  • カルチャー
  • 開発・テスト
  • リリース・ライブサイト

カルチャーに関してはリーン開発をプロセスとして根付かせた事が大きいということでした(自分もリーンスタートアップ等に関しては全然理解が及んでいない領域なので早く読まねば… この記事とかとりあえず見てる)。また、もともとクローズドな雰囲気だった開発体制をインナーソース(組織内におけるオープンソースの文化とベストプラクティスの実現、と聞いた)にすることにより、開発に参加しやすい・改善しやすい環境づくりに務めたそうです。

次に開発・テストに関しては、自動化とユニットテストがポイントでした。手動でのオペレーションの危険性について理解しているのはもちろんのこと、部分的な自動化を避け徹底的に自動化していることがすごいなと思いました。また不具合の数のモニタリング、指標設定も徹底されていてシステム化が進んでいるなあという印象を受けました。また結合テストではなくユニットテストを増やしていくことで、影響箇所を最小にしつつCIによるチェックを小さくしFBを早くする取り組みがなされていることが印象的でした。(CIによるFBで数十分かかっててNGだったらそりゃ記憶数十分戻さないといけないし、嫌ですからね)

最後にリリース・ライブサイトについては、デプロイメントのステージを細かく分け慎重に検証し最小の影響範囲で済むような仕組みが整備されていました(いきなり顧客に使ってもらって失敗だと最悪数十億人規模で影響が出るから、でしょうね)。またライブサイトでプロダクションの状況を常にモニタリングすることで、いち早くプロダクション環境での問題に対応する環境づくりがなされていました。

GitHubパート(後半)

次の3つを大事にしているとのことでした。

  • GitHub Flow
  • ChatOps
  • Continuous Delivery

GitHub FlowはGitHubさんでも愚直に運用されていますが、CIの数が50くらいあって驚きました。ここでも徹底的な自動チェックがされていることを感じました。そしてGit Flow的に開発環境も分けられていて(review-lab 、production/canary、productionと手元のメモにはある)、自動的にデプロイしたり、実際に本番で流れてくるようなデータを処理してみて問題がなければproductionに含まれるみたいなフローらしいです。すごい 。

次にChatOpsに関しては、Slackでビルドやテストを回せる環境を整えているとのことでした。Hubotを使ってカスタマイズしたコマンドをガンガン使っているそうです。また担当者情報もHubotが返してくれるので、自明なことはbotが返すことによって人が返信する手間を排除しているんだろうなと思いました。

最後にContinuous Deliveryについては、開発効率を最大化するために現在はリリーストレインという仕組みを使ってProductionに反映しているそうです。これはPRを一つ一つデプロイして反映していると時間がかかりすぎてしまうため、いくつかをまとめてビルドして反映する仕組みだそうです。ボトムアップ的にこのアイディアが採用されたというのもオープンソース的なカルチャーが影響しているのでしょうか、業務改善が様々なところから出てくるのはとても良いなと思いました。

エンジニアはものづくりの夢を見るか - AWS Loft Tokyo 入館アプリの開発事例 -

結構エモ目な話だった記憶があります。個人的に重要だと思った点だけ箇条書きでピックアップ。

  • ソリューションアーキテクトという普段はAWSをどう使うかをやっているエンジニアがアプリケーションを作ることで、アプリケーションレイヤーの人視点も持てた
    • 普段の活動から得られない視点が普段の業務にも役立った
    • なぜその需要があるのかを発見できた
  • 「技術的な負債があろうが、現在動いているソフトウェアはなにかしろの問題解決はしている」→「エンジニアならばクレームではなく、技術的な正確性を持って問題に対応していく」
  • きちんと開発する = 組織のルールに則ること AND 体制変更に耐えること、という気づき
    • 個人で開発されたスクリプト、その人が退職したあとメンテされない問題
    • 本番でしか正しく動かないアプリケーション、構成
  • ちゃんと開発する、時間が取れない問題との向き合い
    • 🆖 一度に大きな変化をしない
    • 🆗 なにか「きっかけ」を見つけ、小さな変化を続けていく
  • そのためにやったこととして
    • 人の冗長化(1人でやると自分自身が単一障害点になる)
    • 組織のルールに「準拠できている」チームのメンバーを巻き込んで、メンターになってもらう(そして要件と早く合致させる)
    • 必ずやらなければいけないことと、その期限を明確化し、それをチームで分担してフォーカスする
    • 小規模MVP(Minimum Viable Product)をまず作ってリリースし、評価と改善のサイクルを回す
    • 長期安定性を見るためにか並ぶベータリリースをはさみ、可能な限りカナリアリリースとロールバックの仕組みを整える
    • 開発以外のリソースを減らす(SaaSの活用)
    • 自分のモチベーションの適切な保ち方を見つけ定期的に思い出す
  • 技術的に便利だったもの

こんな感じでしたかね…。結構最後は気持ち!みたいなところもありつつも、どうすれば問題を解決できるのかに全力でフォーカスしロジカルな行動をとってちゃんとリリースできてるのがすごいと思いました。

あのイベントの裏側が知れる!?カンファレンス運営者LT

どういったイベントがあるのか、またどうイベントを運営していくのかについてLTを聞きました。日程かぶってて行けないやつも結構あったけど…。全部について書いているとスペースが足りないので、ここで発表があった各種イベントの開催日情報だけまとめます。

知っているイベントも知らないイベントもあったのですが、明日の開発カンファレンスとXP祭りはそもそも知らなかったです。どちらも自分の興味とかぶりそうなので、気になっています。

あと個人的に印象に残っているのがXP祭りの運営方針です。長年開催されていることもあり、スタッフが巡り巡って基調講演の発表者として登壇するなどの循環が特に興味深かったのと、まずは最低コストで運営する(いわゆるMVPがしっかりされているということだと思います)ことの話が心に残りました。また、PHPConのモデルコースっていうのも面白かったです。

自分自身もカンファレンススタッフとしてぼんやり参加していることもあるので、こういうところで学んだことを自分が関わるところへプラスになる形で取り入れてみたいなと思いました。

まとめ

久々に大きめのカンファレンスで参考になりそうな話をたくさん聞けたので良かったです。(もっといえばこういう場所で発表できるような成果をあげて、発表しなければ… とは常に思っていますが)

このあと参加予定だったイベントは例のウィルスの問題で潰れてしまったので、このカンファレンスで得た熱い想いを受けて活動していけたらと思います。AWSの受付アプリで話があったAWSのサービスはちょっと覗いとこう…。