- どんなカンファレンス？
- イベントを通して感じたこと
- 参加セッションの資料と参加録
どんなカンファレンス？
初回の開発よりもスタートしたサービスが開始されたシステムにて対して より早く価値を提供し続けるために、計測や仕組みを通じて、開発スピードをあげていく話がメインでした。 そのため、SIerよりは自社開発して事業展開してる会社のエンジニアや、EMなどのエンジニアを束ねるリーダーや事業責任者の方向けのカンファレンスでした。 全体を通して「LeanとDevOpsの科学」の本に書かれているワードに関連したセッションがほとんどであったので、 この本を読んで考えた方が惹かれた方も学べる実践例が多いと思います。
イベントを通して感じたこと
LeanとDevOpsの科学の基礎化
１日目に「LeanとDevOpsの科学」の著者が登壇されていたり、t-wadaさんがカンファレンスの課題文庫だよねっておっしゃってました。 DevOpsの定量、定性の計測だったり、組織の役割の話がメインなので、「LeanとDevOpsの科学」を読んでからきた方がいいなと思った。 同時にエンジニアの前提書籍だなと感じたカンファレンスでした。
参加者の傾向
セッションで運営の方が出してくれた情報で公開してくれた人がいらっしゃいました。 開発生産性と題したカンファレンスだったこともあり、VPoEやPMのポジションの人が多い傾向だったようです。 開発生産性は現場より予算などを管理する層の方の関心が高そうでだなと感じました。
複数のセッションで聞いたワードのまとめ
複数のセッションで聞いて耳に残ったワードをピックアップしてみました。 関心が高かったり、メジャーなやり方になっているとから複数で話にあがってると思うので、これを機に押さえておいた方がよさそうと感じました。
DORAが提唱しているSPACEフレームワーク 本で提唱されてるワードだったのに、覚えてなかったことに気づいた Freeeさんのセッション資料に説明あります
BigQueryのデータ溜めてGrafanaで可視化 FourKeyｓなどの情報を蓄積して図示する仕組みとして一般化したやり方になってそう
テストピラミッド 単体、結合、E2Eのどの範囲で実施するかに課題を感じている現場が多いのかなと印象
参加セッションの資料と参加録
自分が聴講したセッションの資料とそのセッションの概要が気になった点を参加録に記載します。 もし興味を持つセッションがあれば、ぜひ資料も確認してみてください。
LeanとDevOpsのためにE2Eテストができること
参加録
テストツールを作る会社から見て、E2Eテストを自動化する際の失敗談と克服方法の例の話。
現場に持ち帰れそうなこと
今社内のアセットを作るチームにいるので、SaaS会社と同じように解約率？（導入後に打ち切った例）をだしてみるのも作ったアセットの有用性を測る意味でありだなと思う。 社内アセットだと強制力働くことが差分ではありますけどね。
資料
https://speakerdeck.com/magicpod/leantodevopsnotamenie2etesutogadekirukoto
組織横断支援チームによるFour Keys計測基盤の構築と活用に向けた取り組み
参加録
システムや組織の規模が大きくなり、コミュニケーションコスト増や低いデプロイ頻度の改善の取り組みの話。 初期の試験導入チームの選び方は紹介の通り自発性があり、積極的なチームを炙り出す方法が素敵でした。 自発性と積極性のあるチームであったからこそ他のアクションの成功につながっていたように思うので、新規ツールの導入の観点として真似していきたい。
現場に持ち帰ること
FourKeys測定だとTeam+とかSaaSを使った方が導入のハードルは低いと思う。 ただ、現場の制約で難しい点もあるため、この紹介であったOSSのdora-tema/fourkeyが今の現場で使えるツールの１つだった。 そのため、FourKeysを現場に取り入れる案として出していこうと思ってます。
資料
Metrics-informed development; theory and practice
参加録
初めての同時通訳英語セッションの聴講だったのですが、英語の発表資料と少し遅れてくる通訳の話がリンクしなくて、理解が追いつかなかったです。 全体を理解することはできなかったですが、とある現場の数値化にて、２回目以降のリリースでは前回以前のリリースのHotFixが含まれてしまい、徐々に新しい機能のリソースが減っていく話があった。 言われてみれば当たり前かもしれないけど、それを数値化したことによって、 新規機能の開発速度が落ちることは社内で認識合わせられるから数値化することの重要性を再確認できました。
資料
atalog.us-east-1.prod.workshops.aws/event/dashboard/en-US
「開発生産性を上げる改善」って儲かるの？に答えられるようにする
参加録
リファクタリングなどの開発生産性向上の話を現場はする。 けど、自分はそれがどのように事業に貢献できたのかをすぐに言えなかった。 目線の違いの説明やその変換の方法を説明されていて、事業者と開発者の目線が違うことを理解して 生産性の話ができてないことに気づくきっかけになりました。
資料
https://speakerdeck.com/i35_267/is-development-productivity-profitable
アーキテクチャレベルで考える開発生産性
参加録
変更の容易性を上げる方法がDDDだって話がありました。 DDDだと責務わけがしっかりできてるので、コードの場所が絞りやすく変更はしやすかったので、容易性の回答だと実体験と照らすとわかりやすかった。 コードの話でどのクラスの責務にするかの話になってしまうことが多いのだけど、サービスの差別化する点を抽出する戦略的設計が前提で目的と手段の逆転になってることが多いと振り返ってた。 立ち止まって、戦略的設計が前提にあることを置いた上で進めるようにしていかないといけないという学びに繋がりました。
資料
https://speakerdeck.com/minodriven/architecture-and-productivity
freeeにおけるスモールスタートを意識した開発生産性向上の実践事例
参加録
DevOpsの一通りのアクションを導入していった実践例と知見の紹介 一番残ったのはトランクベース開発を組織的に導入したこと。 LeanとDevOpsの科学でも紹介されてますが、早く価値を届けていくために最適なブランチ戦略ではあるものの開発の仕方変えていかないため、導入のハードルが高いと思ってました。 実践した人のリリースフローの簡略化はリリースの事故減らせることは開発者としても運用品質の向上につながるメリットがあると思いました。
現場に持ち帰ること
現場でも障害が発生してから止血までの時間を計測したいって話もあったので、そのプラクティスはやはりチケット（FreeeさんはJIRA）で時刻記録していく方法がスタンダードだよなと再確認した。
資料
開発生産性の観点から考える自動テスト
参加録
描きたい話が多いので、個別で書こうと思ってる。 E2Eテストが自動化されると手運用の労力はないと思っていた。 E2Eは万能ではなく、発表でもあったように単体テストに比べると時間もかかるし、複数のシステムが絡むことによるバージョン不一致などの脆さを兼ねている。 早く問題に気づくためにも、保証したい観点を守れるのであれば、より単体テストに近いテストで実装していく考えは持ち続けておかないとアンチパターンのアイスクリームコーン型（より広範囲で実行するテスト）が継続されそう。
