背景
Developer's Summit（デブサミ）とは，毎年2月の中旬ごろに翔泳社さんが主催で開催するソフトウェア開発に関わるトピックを共有するカンファレンスです。2020年は「ともにつくる」というテーマで開催されました。参加したセッションの中で印象に残った3つのセッションを日付順で紹介したいと思います。
###(小ネタ)私自身について
私ごとになってしまうのですが、私がデブサミを知ったのは昨年の開催中で、当時私は修士論文の追い込みに追われていました。Twitter等で非常に盛り上がっていて，「来年行けたらいいなぁ〜。でも就職するから無理だろうなぁ…」と思っていました。時は過ぎて、デブサミが近づいてきた時、会社の上司に「デブサミ行ってきていいですか？」と聞きました。なんとその場で「いってきていいよ。ただし20分くらいグループで発表してね」という条件でいく許可をもらいました！ありがとうございます🙇♂️
私は今年から某システム会社に勤めているのですが、非常に学びがありました。ぜひまた来年も行きたいし、行きたいと思う人を増やせればいいなと思いっています。
参加セッション
私は、以下のセッションに参加してきました。発表者は敬称略です。振り返ってみると、私が興味ある分野は、DevOps・組織論・教育・コンテナなどなどでしょうか。発表資料は公式サイトを参考にしています。
1日目
| ID | タイトル | 発表者 |
|---|---|---|
| 13-D-1 | LINEがプライベートクラウドを選ぶ理由 | 室井雅仁[LINE] |
| 13-C-2 | CircleCIの３０００万件のワークフローから得られたDevOpsに関する知見 | 車井登[CircleCI] |
| 13-B-3 | Kubernetes未経験者がGKEの本番リリース〜障害対応を経験して苦悩した話 | 泉水 朝匡[grasys] |
| 13-F-4 | 若年層におけるプログラミング的思考の学びの場づくりと動機づけ | 鷲崎 弘宜[早稲田大学]/齋藤 大輔[早稲田大学]/坂本 一憲[早稲田大学] |
| 13-B-5 | Best Practices In Implementing Container Image Promotion Pipelines -知っておくべきコンテナイメージ・プロモーションの方法 | Baruch Sadogursky[JFrog] |
| 13-D-6 | テストエンジニアが教える テストコードを書き始める前に考えるべきテスト | 風間 裕也[ビズリーチ] |
| 13-B-7 | コンテナをシンプルに使おう 〜 Cloud Run のすゝめ 2020 冬 | 篠原 一徳[グーグル・クラウド・ジャパン] |
| 13-D-8 | エンジニアと人事がともに考えるエンジニア採用 1,2 | 【モデレーター】金山 貴泰[うるる]/てぃーびー（田部井 勝彦）[スタディスト]/伊藤 哲弥[LAPRAS]/安立 沙耶佳[ヌーラボ]/梶原 成親[ヤプリ] |
2日目
午前中は所用があったため、お昼からの参戦です。
| ID | タイトル | 発表者 |
|---|---|---|
| 14-B-3 | K8S使ってますか？リテールテック（小売・決済等）でのコンテナ活用例と「2025年の崖」克服に向けたコンテナ導入のススメ！ | 程 建強[Rancher Labs]/山澤 一仁[スーパーソフトウエア]/井川 知幸[カゴヤ・ジャパン] |
| 14-A-4 | 「問題から目を背けず取り組む」一休の開発チームが6年間で学んだこと | 伊藤 直也[一休] |
| 14-D-5 | マルチクラウドに向けてNGINX活用促進する為に知っておいてほしいこと | 鈴木 孝彰[NGINX (Part of F5)] |
| 14-B-6 | サービスメッシュは本当に必要なのか、何を解決するのか | Yasuhiro Tori Hara[Amazon Web Services Japan] |
| 14-A-7 | TOYOTA x Serverless x Microservices 〜 グローバル展開のコネクティッドカーを支えるアーキテクチャとエンジニアリングチーム | 浦山 雄也[トヨタ自動車]/松本 崇之[トヨタコネクティッド]/内海 英一郎[アマゾン ウェブ サービス ジャパン] |
「CircleCIの3000万件のワークフローから得られたDevOpsに関する知見」
4つの指標を取得して、考察していました。
- ワークフローの動作時間→変更リードタイム
- 長過ぎてもダメだし、短過ぎてもダメ。
- 開発者に適切なフィードバックがされるようにする
- デプロイ頻度→ワークフローが開始される頻度
- そもそもこれは優れた開発チームである指標にならない
- コードをテストする頻度や復旧時間は上記の指標になりうる
- 復旧時間→レッドがグリーンになるまでの時間
- 大体17.5時間。大体、夜回して明日朝修正しているパターン
- 失敗頻度→ワークフローの失敗率
- パイプラインをいじってもビルドに失敗していないプロジェクトが多い
- 今後はパイプラインのベストプラクティスを取り込む方にシフトしよう
大企業に所属している自分として、世間一般ではここまでCICDが進んでいるのか、、、と思いました。自分の会社はどれくらいやっているか調査してみたいですし、これらの指標を元に自分の会社のパフォーマンスが明らかになると思うと、怖いもの見たさでワクワクします。
「問題から目を背けず取り組んでいく… 一休のこれまで」
このセッションでは、ホテル旅館・レストラン予約サイトである一休.comさんが6年かけて、レガシーシステムに切り込み、システムやら業務やら組織やら色々変えていったお話でした。
- レガシーアーキテクチャには逃げずに立ち向かえ
- トップダウンから取り組んでいくことが大事
- 結果的にチームビルディングされるし、マイクロサービス化もする
- 何がしたかったかを忘れないこと
私の所感としては、レガシー解消や基幹システム刷新ができないのは組織が大きいから、というのはただの言い訳なんだなと思いました。立ち向かって、自然とそうなるように仕向ける力が必要だなと思いました。
「TOYOTA×Serverless×Microservices ~ グローバル展開のコネクティッドカーを支えるアーキテクチャとエンジニアリングチーム」
これはとても心身に響くプレゼンでした。日本で一番の大企業であるトヨタ自動車が、まさに社運をかけて挑んでいくプロジェクトの話でした。（資料は非公表だそうです。）
- 「お客さんに、最高のものを最速で届ける」と言う信念をもとにコネクティッドカーのソフトウェア開発に臨む
- チームビルディングで難しいところは、車とソフトウェアの開発期間が異なること
- マイクロサービスごとに、チームを分割し、重厚な部分と変化が早いところを担当する2つわけ、やがて統合
- チームが自己組織し、awsの人呼んだりしてスキルアップ
- デプロイ回数は624回/月になった
- なんで、「お客さんに、最高のものを最速で届ける」と言う意識で統一できたのか
- 全社員につぶれると言う危機意識
- 危機意識あると、替わろうと努力できた
すごすぎる。。。
ここで思ったことは、お客さんに一番価値を提供できる部分は、顧問等にAmazonやGoogleの社員を使うという体制で自社エンジニアがやる未来がきているのかなと思いました。その中で、システム作る会社がどう関わっていくかを考えないといけない、、、と思いました。
終わりに
私が学んだことを超ざっくりまとめると以下の3点です。
- DevOpsを進めれば、開発に関する数値もゲットできるので積極的に進めたい。
- 企業の問題を解決するには、問題を理解することと、その問題にトップダウンで立ち向かうことが必要。
- 企業生命がかかっていると大きく挑戦できる。全社員にそういう危機意識をインプットし、積極的に変化に立ち向かわないといけない。