デブサミ2019に行ってきた #devsumi

今年もモチベーションとか色々もらいました:)

例によって印象に残ったセッションを記録です。

Day 1

 Wi-Fi本当にありがたいです🙏🏻

 

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

Speaker Deck @ikeike443

タイトル通りGitHub Actionsについてのお話。

- ワークフロー=アクションの組み合わせ

- アクション=1コンテナ

- アクションの実態はDockerfile

- Dockerでできることは大体はできる

- イベントが色々用意されていて、外からキックすることもできる

- 既に用意されているアクションも色々ある(HTTP叩いたり

楽しそう(小並感。

ベータの申込みをしたので通ったら触りたい。

 

レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

自分のお仕事は結構な割合でレガシーとのお付き合いなので、共感と学びが多いセッションでした。

特に「葬り(不要な機能の削除)」が大事というのは本当にそうだと思います。機能が多いということはリファクタリングするにあたって気にすることが多いということで、不要な機能を残すために気を使うというのは労力的にも気力的にも大変苦しいことですよね…。顧客に「不要」だと認めてもらうスキルが必要だと痛感したことがあります。

 あとは「自分たちでコントロールできるインフラがあると進みが早い」というのも大いに共感できます。これがあるとスクラップ&ビルドも簡単で色々な試しができてスムーズですよね。この観点でIaaSがもたらす恩恵は大きいなと感じています。

 

カオス化した組織とエンタープライズシステム群を、モダン化したい！ノンIT企業のシステム企画開発を、ドメイン駆動型に組織ごと変えるまでの道のり

涙なくしては聞けない、素晴らしいお話でした。あるあるすぎて首がもげそうになる。(心を打たれすぎてろくなことを呟いていない…)

9人で9事業をカバーしてたけど21人で4事業にとか、どうすれば可能なんだろうか…。

「運用・問い合わせはイイヤツに集まる」ありすぎて切ない…。

障害が発生すると保守が回らないので保守、障害対応、パフォーマンス改善に体制を分割した。集中が必要な業務と割り込みが発生する業務を兼任するとどうしようもなくなるのでこれは絶対に分けないとですよね。

外部の会社と仕事をするために「俺流」を捨てる。これも本当に大事だと思います、盲目的に世の中の標準に従えばいいということではもちろんないわけですが、標準はなるべくして標準になっているわけですよね。

あとはいろんな情報を数字として出せているのがすごいですね、見える化ができている…。

ドメイン駆動で「価値の低いドメインは放っておこう」という判断になるのは先程の「葬り」と似てますよね。優先順位をつけるのとやらない判断をするのは本当に大事だと思います。

(C#の会社らしいので個人的にちょっとシンパシーを感じました)

 

「ITエンジニアに読んでほしい！技術書・ビジネス書大賞 2019」プレゼン大会

割と毎年参加しているので今年も:)

もちろん全部の本が良書なのだと思いますが、個人的に刺さったのは「イシューからはじめよ」の「それは本当にイシューなのか？」という問いかけです。

他のセッションでも出てくる「不要な機能」「価値の低いドメイン」と同じように、イシューを磨き込んでいると「これは対応しなくて良いものでは？」となることは意外にあると思います。対応しないという判断を伝えると「サボりじゃないの？」と思われてしまうことがあるので、そこはそうじゃないということを共有していかないといけないですよね。

 

Day 2  

ノートの充電を忘れてピンチだったが、空き時間にラウンジで充電できたので事なきを得ました🙏🏻

 前日伺ったらあんまり残ってなくて「明日の朝来てもらえればあると思います！」とのことだったので早々にゲットしました:)

 

 ソフトウェア開発の「今ココ」に適応するために― カイゼン・ジャーニーから見つかった新たなfunと前進への旅路 ―

カイゼン・ジャーニーから見つかった新たなfunと前進への旅路 - Speaker Deck

我々に越境できない境界は無い。

 技術書大賞でもプレゼンされていたカイゼン・ジャーニーについてのセッション。情熱が伝わってくる内容でした。

「フレームワーク主導NG」はその通りですよね。まずは悩みや課題に注目して、それを解決する手段としてフレームワークが存在する。

 コミュニティが「野戦病院」というのはなるほどそのとおりだなと思いました。傷を癒す場所ではあるけど、居場所ではない。戻る場所がある。「組織を超えた学びの場」確かに必要だと実感しています。

 買いました:) 付箋も貼らせてもらいました:)

 

Site Reliability Engineering at Google

タイトル通りGoogleさんのSREについてのセッション。

SREは業務時間の50%以上を開発やシステム安定化に関わる業務にあてるというルールがあり、それを脅かすようなシステムの運用は開発チームに突き返す権限を持っている。それによって開発チームが安定したシステムを構築する動機付けができて、SREも開発チームが安定したシステムを開発できるように支援する形になる。非常に理にかなった仕組みですよね。

これを回すには「安定している」を共通認識として定義しないといけない。それは「SLOが満たされている」ということ。SLOを満たすために「エラーバジェット」を使う。エラーバジェット=1.0 - SLO。エラーバジェットを超える=安定していない。

エラーバジェットを超えそうになったら新機能のリリースをフリーズしてシステムの安定化に注力する。それで納期が守れなくなったりするならば、それはSLOの設定がおかしいということ。SLOが100%ということは1回でもエラーが発生するとエラーバジェットを超えるということであり、そのような設定はおかしい。SLOの設定は非常に難しいので、運用しながら調整していくもの。

デベロッパーの「Burnout(燃え尽き症候群)」を防ぐことが大事。つまらない仕事をさせていると燃え尽きてしまう。それを防ぐための50%ルール。「Toil(労力のかかる作業)」を削減することが大事、Toilは悪。

障害対応が終わった瞬間に「Postmortem」を書く。発生要因、対応時の反省点、改善策などを文書化する。記憶のダンプ。個人を非難するような内容を絶対に書かないこと、それは個人のミスを誘発するシステムを設計したチームの責任。言い訳のための文書ではなく、知見の蓄積である。

知見に溢れたセッションでした…。

 

 まとめ

今年は例年に増して共感できるセッションが多かったような気がします。

もらったものを糧にして頑張っていきたい所存ですね…。

 ラウンジで糖分不足にうめいていたら飴ちゃんもらいました:) ありがたし。