天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

(オンライン読書会) 能動的推論  ~心、脳、行動の自由エネルギー原理~に参加してきた

educational-psychology.connpass.com

こちらのイベントに参加してきたので、会で話したことを書いていこうと思います。

能動的推論のふりかえり会

序章のまとまり

序章を改めて見ると、行為-知覚サイクルや王道/常道の区別などが整理されており、整理が丁寧にされていたねという話や、序章でベイズという言葉を出したことで信念の話にもつながっていたという話をふりかえりしていきました。

隠れ状態

本書は「隠れ状態」というアイデアが独自なもので面白いよね、という話がありました。

認知科学における表象をこのように捉えることができるのかという発見や、自分にとって都合がいい解釈をするときは隠れ状態をネガティブな情報をOmitした上で更新してしまうという説明ができる(=ある種の適応)ことは、非常に面白いという話題が挙がっていました。

情報利得と実利的価値

情報利得と実利的価値が数式で異なる項に位置するという話から、今持っている信念と一致するのかだけではなく、未来のために今持っている信念をより変化させるための行動が期待自由エネルギーとして説明できるのは面白いよね、ということをふりかえりしていきました。

ブランケットの入れ子

ブランケット入れ子やマルコフブランケットの話から、クラスベースオブジェクト指向からスタートしたあとに、key-valueの組み合わせでしかないという極めて単純なプロトタイプオブジェクト指向を知ったときの感覚に近いものを覚えたという話を聞いていきました。

ベイトソン

この本の前の読書会で読んだ、ベイトソンの「精神と自然」のジェネティックソマティックの対比がちょくちょく出てくるよね、という話をしていきました。

具体的には、生物が過剰な安定性と過剰な分散性の妥協点を常に求めているという話や、階層的な目標処理、論理階型の混同が生成プロセスの中で発生してくるあたりの話が、ベイトソンの話と繋がってくるよねという話でした。

学習と推論

学習と推論の対比から、毎回0からものを積み重ねようとするとものすごく労力がかかるけれど学習してきたことを積み上げするだけだと今まで見たことがない事象に落ち合った時にフリーズするか自身の信念をまるごと変えなきゃいけないような状態になってしまうリスクがあるよねという話をしていきました。

これらの話から、学習の頻度をどれくらい緩やかにしていくのか?というのが重要になってくるのではないか、という意見も出ていました。

ビブリオバトル

続いて次回読む本のビブリオバトルをしていきました。

www.iwanami.co.jp

bookclub.kodansha.co.jp

honto.jp

www.minervashobo.co.jp

こちらの本が候補として挙がり、最終的に

bookclub.kodansha.co.jp

の本を次回以降読むという話になりました!

大人のソフトウェアテスト雑談会 #161【仙台から葛飾】に参加してきた

ost-zatu.connpass.com

スクフェス大阪

最初にスクフェス大阪のドラフト会議の話を聞いていきました。

おおひらさんのセッションの熱い取り合いがドラフト会議のハイライトだったそうで、結果的に品川トラックで唯一のセッション採択になったのはさすがおおひらさんという感じでしたが、おおひらさんは7位指名というのが不服だったそうです。

JaSST東北の感想戦

JaSST東北の感想戦を聞いていきました。

おおひらさんの発表に対して、質問者が意図的に噛み合わせないようにプロレスを仕掛けていたのと、XPの権化であるmiwaさん咳さんの前でスクラムの話をしたのが印象深かったそうです。

miwaさん咳さんが来ていたのは衝撃的だったそうで、(冗談だとは思うけれど)おおひらさん以外の方でも、miwaさん咳さんの姿が発表中に見えなかったのはよかったと言っていたらしいです笑

また、飲み会ではソフトウェアQAじゃなくて人QAの話をしたり、SQAのDeepな話題を話したりしたそうで、非常に充実した時間を過ごしたということでした。

みんなが緊張する人

まずはおおひらさんが目の前にいたら緊張する人の話を聞いていきました。

miwaさんは現在も医療機器のプロダクトでQAを実践されているということと、おおひらさんと比較的カテゴリが近い中で20年以上経験をされているということから、現役だとダントツにmiwaさんに対しては緊張するということです。
また、緊張とまではいかないけれども同業種系の人たちもリアクションが気になってしまうので反応に敏感になってしまうという話や、責任を持った状態でプレゼンテーションする*1のはなかなか緊張するという話もありました。

Markさんは森崎先生や鷲崎先生、西さんなどといった方々の前で話すのは緊張するということで、新潟で話をした時に目の前に西さんがいたときはめちゃくちゃドキドキしたそうです。(なお、目の前にいなくても存在に怯えて緊張するそうです)

Ackyさんは基本的に誰に対しても緊張しないけれど、アジャイルを知った時に最前線を走られていた平鍋さんに対しては唯一緊張するということでした。

ちなみに自分は特定個人に対する緊張はないのですが、昨年のスクフェス札幌のときは一週間くらいめちゃくちゃ緊張していて、人生でもこれ以上ないくらい心臓がばくばくしていました笑

JaSST東北実行委員会

JaSST東北のコミュニティデザインの話を聞いていきました。

JaSST東北は準備がめちゃくちゃ大変らしく、実行委員会に毎年コミットメントし続けるのは難しい事情があるそうで、「今年はコミットメントしません」と宣言する事ができるような仕組みを作ることで継続して運営しているということです。

JaSST東北の感想戦その2

湯本さんとJBさんがビジネスを如何にスケーリングしていくのか?という話をしていたのが面白かったという話を聞いていきました。

そこから派生して、テストチームで認識を揃えるためのアプローチをチーム全体にまで適用していくための方法をタバコを吸いながら話しているのを聞いたりして、だいぶ濃い話ができたそうです。

全体を通した感想

今日はブログには書けないけれどめちゃくちゃいい話や安心するような話を聞けて神回でした。

地味に(?)久々の葛飾でしたが相変わらずとても楽しかったです。

*1:営業のヘルプでプレゼンテーションする

アジャイルカフェ@オンライン 第33回に参加してきた

agile-studio.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

天野さん家永さん木下さんのアジャイルコーチお三方が、視聴者からの悩みに回答していくイベントです。

今回のテーマは、「完成の定義に何を記録するのか?」でした。

会の様子

完成の定義に関して解説

www.agile-studio.jp

こちらの記事をもとに、完成の定義に関して簡単な解説がありました。

ごちゃごちゃにされがちな受け入れ条件との違いであったり、なんで完成の定義が必要なのか?どういう部分がポイントか?*1

普段アジャイルコーチの方が完成の定義に書くことをおすすめすること

チームの成熟度や状況に応じて変わってくるものの、以下の条件をおすすめすることが多いということでした。

  • Unit testが全てPassしていること(カバレッジに関してはメンテナンスコストが高くなりがちなフォースが働くため、チームの成熟度がよほど高くない限りは完成の定義に含めない)
  • VSMを書いてもらった上で、スプリント内で「ここまでは最低限やりましょう」というのを完成の定義に記載することが多い
  • 文章の羅列と言うよりは表とかで整理しながら書くことが多い
  • 情報過多になりすぎないように注意する

また、完成の定義をレトロスペクティブに持っていった上で見直すことで、定期的にメンテナンスをしていくことも重要だということです。

完成の定義に書かないほうがいいこと

一方で、以下の点は完成の定義に書かないように注意するということでした。

  • 完成の定義を細かく記載しすぎないようにする
  • 経過で見ていくような部分はなるべく書かないようにする(例えばまずはE2Eを全件Passさせた上で、次にE2Eにかかる時間をXX時間とする必要があるなら、E2EがXX時間以内にPassするという最終結果を記載し、段階は記載しないようにする)

定性的な完成の定義はありか?(例えば内容がドキュメントにわかりやすく整理するなど)

定性的な完成の定義もありではないか?という話が出ていました。

完成の定義が出ているかの共有の方法は、オノマトペ方式*2だったりペアワークなどでの共有が一つの方法としてあるということです。

また、同じものを話し合うレビューは定性的な完成の定義を作る活動の基本になるというお話も出ていました。

完成の定義を追加した場合はこれまでに「完成した」としていたのも見直すべきか?

参加者からの質問で、「完成の定義が拡張された場合はこれまでの完成の定義を見直すべきか?」という話がありました。

これは、基本的に過去の分も遡って対応する必要があるということですが、当然過去の分に対応するための工数を積むことが必須な点には注意したいということです。

会全体を通した感想

テスト関連の話が多く、ドキュメント系やLinterの話、ドメイン固有の話はそこまで出ていなかったのは意外でしたが、お三方がテスト関連の項目を特に重視しているのがわかったのは非常に興味深かったです。

*1:家永さんからは、「一貫した基準」であることが特に重要だというお話があり、天野さんからは「リリースできる基準」であることのお話がありました

*2:ドキュメントがパリッと書かれているなど...当然チームの中で共通語彙を日頃から形成しておく必要がある

COVID-19に罹っていた

タイトルの通り、COVID-19に罹っていました。

タイムライン

〜5/20...COVID-19とは全然別件でバタバタしていました。バタバタしていた事情はここで記載するのを差し控えますが*1、5/18, 5/19, 5/20の睡眠時間合計が2時間しか取れない事態に陥り、5/21は絶対に休まないとまずいと思いながら生活していました。

5/21...40度超えの発熱。(40.7度)なんとか病院に行こうとするもくらくらしてしまい動けなくなってしまいました。少し休んでから病院に行こうと横になったのですが熱冷ましを飲んでも熱が下がらず、生命の危険を感じたので、タクシーを呼んで無理やり病院に行こうと考えました。しかし、外に出てタクシーを待つ間に意識がなくなってしまい、近くにいた方に通報されて救急車で搬送されました。しばらく意識がない状態が続いたのですが、搬送先の病院で手当を受けてなんとか回復しました。COVID-19の陽性が検査で分かり、腎臓病持ちということもあってそのまま入院になりました。

5/22〜5/25...熱は少し下がりましたが、39度超えの発熱が続きました。このタイミングで喉の痛みや嗅覚味覚の異常が発覚し、咳が止まらない状態になりました。腎臓に関連する数値も悪化してしまい、こちらも薬物療法で対処しました。また、喉が痛すぎてまともに食事ができないので、点滴で栄養を注入していました。

5/26...熱が37度台にいきなり下がりました。このまま死ぬんじゃないかと誇張なしで思っていたので安心しました。喉の痛みや嗅覚味覚の異常は変わらずでした。

5/27...咳がだいぶ少なくなってきました。熱も37度台をkeepするようになりました。腎臓関連の数値も落ち着きを取り戻しました。

5/28...喉は痛いですがご飯も食べることができるようになり、自力で生活できる目処がたったので退院しました。

現状

熱は平熱に戻り、ブログが書けるくらいには回復しましたが、まだ以下の症状が残っています。

  • 嗅覚味覚の異常
  • 痰が定期的に出る
  • 空咳が定期的に出る
  • 軽い頭痛
  • 家を歩くだけですぐに息切れ
  • 心拍数が高い(安静にしているときは今まで50回/分くらいだったのだが、退院後は90回/分)

あとは普通に体力や集中力も落ちている気がするので、明日から生活を営みながら徐々に戻していきたいです。

今後

しばらくは気持ちこれまでの8割くらいのペースで活動をしてみようと思います。あとは規則正しい生活を続けるのと、よく食べてよく寝ようと思います。

後遺症(?)がいつ頃完治したのかはおいおい報告しようと思います。

おまけ(入院中のブログ)

自分に何かしらあった場合は自分が止めない限り勝手にブログが更新されるようになっていたので、記事は以前に書いたものが勝手に更新されていました。

意図して更新したものだったので特に驚きはなかったのですが、SNS等でなんにも通知しなくても反応がある記事には反応があるんだなあというのを痛感しました。(入院中記事についてのコメントがDMで複数来ていたのですが、なんの記事が自動でアップされたのかは自分は把握していなかったため、何に対して反応が来ているのかしばらく理解ができず、一部の丁寧な方のDMでどういうことなのか気が付きました)

*1:Facebookには報告しました。スクフェス新潟の発表準備ではないです

春の復習ランチタイム#6「分岐を低減するinterface設計と発想の転換に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

プログラミング言語にはinterfaceやそれに類似する、抽象的に扱うための仕組みがあります。interfaceを駆使すると分岐が減り、変更が楽になります。

しかし現状の開発でinterfaceは有効に用いられていますでしょうか。仕様変更時、「既存ロジックにむりやりif文をねじ込む」「分岐が異常に複雑化する」といった実装になっていませんでしょうか。分岐の複雑化は変更容易性を著しく低下させます。

interfaceをどういう状況で用いればよいのか観点が不十分なのが原因だと考えられます。interface設計には大幅な発想の転換が必要です。

この講演では、interface設計に必要な考え方について解説します。

会の様子

目的単位で抽象化する

システムには必ず何かしらの目的があるため、システムの構成要素(例えばクラスなど)にも必ず目的があるという話がありました。
更に、目的を達成する際には何かしらの課題とその課題に対しての対応策がセットで必要になってくるということです。

また、実際のシステムでは一つの目的/課題に対して、それらがツリー構造でブレイクダウンされた目的/課題が出てくるため、仕様ごとに目的/課題を整理していくことが重要だというお話も出ていました。

「作る」と「使う」を分ける

良くないロジックは、何を使うのか判断する分岐と何を実行するかのロジックが混在してしまっていることが多いという話がありました。

そのため、「作る」→「作ったものを使う」という風に分類するのが重要だということが話として出ていました。*1

目的のバリエーションと機能性

同じ目的であっても、達成手段それぞれで性能が全く異なるため、自分たちは同じ目的であっても性能を使い分けることが多くあるということでした。

そのため、interface設計可能な箇所は機能性を向上させることができる可能性を示唆している場所であるとも言えるし、より顧客にリーチする機能に置き換えられる可能性を秘めている箇所であるとも言えるだろうということです。

このルールにしたがってinterfaceを設計することができると、より高機能なものに素早く書き換えられるようになり、開発生産性が高まるだろうというお話でした。

interfaceを使うときの注意点

あくまでも目的手段のバリエーションとして利用することが重要で、分岐が複雑だからinterfaceを使うというのは、コードがぐちゃぐちゃになってしまうリスクがあるため注意したほうがよいということでした。

参考書籍

最後に参考書籍の紹介がありました。

Q&A

発表の後はQ&Aセッションがありました。以下、内容を常体かつ一問一答形式で記載していきます。

インターフェースを実装したことがあるのだが、PhpStormなどでコードジャンプするとインターフェースのメソッドに飛んでしまうため、インターフェースはいらないと思う

追わなくても良いクラス(=完成品として作られているクラス)を実装するのが重要。(例えば標準ライブラリなどは中身を追いたい場面が少ないはず)

interfaceは一度広く公開してしまうと変更するのが難しくなる。どのような対策があるのか?

新しいクラスを公開し、古いクラスを非推奨とするのが対策の一つとしてある。(ストラングラーパターン)

目的と解決手段、及びその具体化と抽象化をモデリング言語化する技術力を高めるために最初にやるべきことは?

ビジネスの目的を知るためにドメインエキスパートに話を聞きに行くのが重要。

今日の話はRubyなどインターフェースがない言語で使える話か?

メソッド名が被ったりすることはあるはず。そのため、Rubyでもモジュールをインターフェースの代わりとして使うようにしている。

interfaceに引数やレスポンスを生やし始めると一部しか使わない引数が出てくることがあるのだが、これは設計が悪いのか?

目的が単一になるように分析すれば防げるはず。

抽象化する方法としてAbstractを使う方法もあるが、どう使い分けているのか?

抽象クラスは密結合になりやすいので、抽象クラスをあまり使わないようにしている。

早すぎる抽象化は負債になりかねないと思うが、うまい抽象化を見つけるためにどういうコツがあるのか?

まずものを作ってみて、作ったものを見てやばい臭いを感じ取ることができたら抽象化をするようにしている。

拡張可能性とYAGNIのバランスは?

これもやはり、一度作ってみた上で将来的にどうなるのか?というのを考える必要がある。

会全体を通した感想

質疑応答の内容から、皆さんの現場でも苦しみがだいぶ感じ取れるセッションで、色々と闇の深さを感じました。

ソフトウェアプロダクトラインエンジニアリングはまだ読んだことがなかったので、読んでみようと思います。

*1:作るクラスの例としては、Factoryなどが挙げられる

入門モダンLinux - Forkwell Library #23に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

これまで Forkwell のイベントで登壇されたエキスパートの方々は、先達が記した書籍から「気づき」を得て実践し、振り返り、再現性のある「学び」として身に付けていく中で、実績を築いてこられました。

しかし、日々限られた時間の中で知識や情報をアップデートし続けるのはそう簡単ではありません。Forkwell Library では、著者・訳者・実践者らを登壇者として招き、そんな思いを抱えた開発者の皆さまが「学びのきっかけ」を得られる勉強会を目指します。

Linuxはサーバ、組み込み機器、スーパーコンピュータなどにおいて存在感を示してきました。近年では、オンプレミスのシステムだけではなく、クラウドサービスでも広く使われています。 今回の第23回目では、時代の変化に柔軟に対応できるLinux技術者を目指すなら必読の一冊である入門 モダンLinux ―オンプレミスからクラウドまで、幅広い知識を会得する-を取り上げます。 Linuxの知識を体系的に整理したい、最新動向が知りたい、運用を改善したい、効率的に開発を行いたい、といった要望をかなえる内容となる本書の訳者である、sat氏と大岩氏をお迎えしこの本の魅力について語っていただきます。

会の様子

入門 モダンLinuxとはどんな本なのか?

時を経ても変わらない知識×最新知識、初心者向け×上級者向けという2軸を考えたとき、本書は時を経ても変わらない知識と最新知識をカバーし、レベルとしては初心者と上級者のちょうど中間的な立ち位置にあるということでした。

また、豊富な参考文献が含まれているのが特徴で、章ごとに数十冊のリファレンスがついているということでした。

本の見どころ

1章でLinux入門とあって初心者向けかと思いきや2章でいきなりLinuxカーネルについて触れだすストロングスタイルなところが全体的に魅力だということでした笑
また、全体を通して原著で直されていないバグなどを見つけたり、訳者補足などを充実させている点も魅力だということでした。

以下、訳者のお二人がおすすめだと思う章を幾つかピックアップして簡単に見どころを記載していきます。

第二章...CPUアーキテクチャRISC-V, eBPFについて触れられている

第三章...fishシェルやターミナルマルチプレクサについて説明されている。また、ツール群を多数紹介している(なぜかほとんどがRust製ばかり)

第六章...パッケージ管理としてflatpak, snap, apkなど珍しいものが多数紹介されている。また、コンテナもdocker以外のもの(containerd, podman...)が多数紹介されている。

第七章...ネットワークの基本からスタートし、wiresharkといったツールの説明もされる。また、ip_local_reserved_portsについての補足も追加している。

第九章...高度なトピックを多数扱っている。Firecracker, bottlerocketといった絶対エンドユーザー触らないだろうというネタが紹介されている。

本書の前に読むとよい本

本書が難しすぎると感じた場合は以下の本を読むとよいということでした。

  • 新しいLinuxの教科書
  • 本気で学ぶLinux実践入門

本書の後に読むとよい本

本書を読んだ後にステップアップしたい人は以下の本を読むとよいということでした。

  • スーパーユーザーなら知っておくべきLinuxシステムの仕組み
  • Linuxのしくみ
  • 入門Rust(おまけ)

翻訳しようと思ったきっかけ

元々オライリー編集者と長い付き合いが大岩さんにあり、読んでて楽しかったので翻訳したということでした。

また、ちょうど本の執筆の話もちょうど同時期にあったそうで、ヘルプを武内さんにお願いしたそうです。

翻訳の中で気をつけたこと/苦労したこと

武内さんは今回翻訳初挑戦だったということもあって、以下の点に気をつけたそうです。

  • 意訳につとめる。「翻訳です」みたいな表現は避ける
  • 専門用語の翻訳には気をつける

また、どこが完成なのかがよくわからなくなってしまったり、翻訳してから一定間を空けた2稿でやり直しが大量に出てしまった点は非常に苦労したそうです。

読者のコメント

読者のコメントの紹介がありました。ポジティブな意見としては、

  • 参考文献が豊富
  • Linuxを長年使ってきたのに知らないことが多くあった
  • 本文でわかりにくいところの補足がありがたかった
  • 分厚くない
  • 翻訳がわかりやすい

があり、ネガティブな意見としては、

  • たまに翻訳の品質が中学生レベル
  • 物理的に薄く内容も薄い

という話が挙がっていたそうです。

Q&A

発表の後はQ&Aセッションがありました。以下、Q&Aの内容を常体かつ一問一答形式で書いていきます。

今と昔でLinuxで大きく変わったことは?キャッチアップは何をしているか?
  • サーバや組み込みに広がっただけではなく、分散システムを前提とした部分でLinuxが使われたようになりコンテナ技術がものすごく使われているのは大きな変化だと思う。
  • 大昔は日本語変換が普通にできないという時代もあったのでそれよりはよくなったと思う。キャッチアップは本を書いたりするときに色々調べたりしている。
普段使っているディストリビューションは?

Fedora/Ubuntu

翻訳には専用ツールを使ったのか?

DeepLやChatGPTをたまに使ったくらい。

システムの監視について本書は触れられているのか?

オブザーバビリティのところで節単位でしっかり触れられている。

POSIXにないモダンな機能は書いてあるか?

誰しもが知らない機能の説明が書いてある。

systemdやipなどが新しいLinuxで変わっているが、systemdやip以外に新しいコマンドはあるか?

exa, bat, ripgrepなど。書籍でも紹介されている。

SELinuxはもう必要ないと思うか?

普段はあまり使っていないが、依然必要なものだと思う。周りはまだ使っている。

WindowsLinuxの違いは何か?

何もかもが違うので回答不能。ぜんぜん違うものだがWindowsLinuxに近づいている感じはある。

ご自身が普段使っているPCはLinux

Windowsを使っている笑
ただしほとんどsshLinuxに繋いでいる。

CentOSは今もう使っていないのか?

使われる数はかなり減っている感じがある。

目次を見るとコンテナのところにLXDがなかったが6章あたりで何か書かれている?

特に書いてないと思ってもらって構わない。アプリケーションコンテナに寄った本だと思ってもらえば。

ChatGPTのほうが本よりも情報収集しやすいツールになっている可能性はあるか?

ChatGPTはハルシネーションがあるので現時点だと全然信用できないなあと思って見ている。

翻訳ポリシーはどう決めたのか?すり合わせた?

二人で取り決めたりはしていないが、これはたまたま二人の価値観がぴったりあっていた感じがあったからだと思っている。

Dockerはなぜここまで流行ったのか?

インストールするための手順が煩雑だったり、ライブラリを一つのアプリのために結局持ち歩かないといけなかったりしてしまい手間がかかったりしていたという問題が解消されたからだと思う。

本書にも書いてあるので確認してほしい。

コンテナの仕組みついて学びたい時に良い本は?

TenForwardさんの本やLinuxのしくみが良いと思う。

Linuxを学ぶ意義は何か?そもそもLinuxを学ぶとはどういうことなのか?

楽しいから。あとは折角のOSSなのでパッチを送ってもらいたい。

fishの記法でzshbashとの互換がないのはつらいのだが、これは意図的なものなのか?

意図的だと思うし、互換を消したからこそ使いやすいみたいな話はある。ただ、一から覚えるのは結構大変。

本業と執筆の両立はどうやってしたのか?

半年前後でやっていたのでだいぶハイスピードで訳せた。とにかく早く出したいというモチベーションがあった。

スケジュール調整せずに、自転車操業で気が向いた時にめちゃくちゃ訳すようにした。

会全体を通した感想

質問の量が過去見た中でも一番多く、盛り上がりを感じました。

ちょうど読み進めている最中なのですが、結構マニアックな知識も多くて面白いので、引き続き読み進めていきたいと思います。

DevOpsDaysTokyo2023の全セッション感想

DevOpsDaysTokyo2023の全セッションを見たのでその感想になります。

注意事項

  • 一度見たセッションの感想については、以前の記事を引用しているものもあります。
  • 英語の講演も聞いていますが、ネイティブレベルからは遠いため、内容を誤って解釈してしまっている可能性もあります。

DevOps, Development Cadence and the Product Life Cycle

自然で人間的な働き方(=フルタイムで働くときとゆとりを持ちながら働くときで緩急をつけながら働く)がDevOpsやアジャイルに関わってくるという主張は、今までにない話で面白かったです。
3Xモデルとの絡みや頻繁なリリースを追い求めることの危険性など、話の繋げ方も教科書的な繋げ方とは違っていたので、興味深かったです。

プレゼンテーションや質疑応答の内容から、開発者が頻繁なリリースや常に成長や改善を求められる環境に燃え尽きてしまう現場を何度もMichael Feathersは見てきたのかなあ...?と勝手に感じていました。

生Michael Feathersは最高でした。

自動テストのFour Keys​ ~テストプロセスのソフトウェア化の4つの鍵~

自動テストのメンテナンスをしていく中で、いたずらに自動テストを増やしたり、ただ自動テストケースに着目していくのではなく自分たちで考えた指標を軸に改善をしていく実例が聞けた素晴らしい発表でした。

Lead time for testing/Testing frequency/Testing failure rate/Lead time to recover from test failureの指標自体にも納得感はあったのですが、これらを4 keysとして運用しているというのであれば、それぞれの要素同士の関係性や特定要素を求めたときにトレードオフに見えるような事象が起きないか?という部分をもう少し詳しく聞いてみたい感じはありました。

DevOps最新動向 高パフォーマンスな技術組織の秘訣

State of DevOps report2022の概要を「コンテキスト」に注目してわかりやすく説明してくれた発表で、ストーリー形式で重要なポイントの解説をしてくれたのが非常によかったです。

内容的にはState of DevOps report2022とのdiffはなかったので、一度読んだ身としては良い復習になった感じだったのですが、ロードマップはベストプラクティスと呼べるような画一的なものはなく組織によってぜんぜん異なることや、信頼性を上げるプラクティスは一時的に信頼性を下げることを強調されていたのは、印象深かったです。

Transparent Infrastructure at Uber Scale

Uberの爆発的なスケーリングを支えるGrailの話を聞いていきました。

Grailの存在は今回のセッションで初耳だったのですが、Graph Databaseとして非常に優れた性能を叩き出していることが各種数値から実感でき、素直にすごみを感じました。

ただ、すごい性能を叩き出していたからこそ、技術的にどのようにしてGrailを実現させているのか?という部分はGraphの説明よりもう少し詳しい説明が欲しかったです。

高信頼 IaaS を実現する DevOps

 

社内k8s基盤の作成やCI/CD整備の部分を中心に、かなり具体的な技術要素にまで踏み込んで実現方法や重視していたポイントの解説をしてくれる発表で、学びが多い内容でした。

技術的な話が面白かったのはもちろんですが、DevOpsを推進していった結果、さくらインターネットの組織文化(3つのバリュー)が非常に重要だったという話はすごく素敵でしたし、繰り返し伝え続けることがDevOpsの創造的な文化づくりの基礎になっていたというのもとっても印象的なお話でした。

4keys 導入のリアル〜ひと通りやってみて分かったこと〜

4 keysを現場でどのように計測し、どのように組織の生産性向上に組み込んだのか?という話を聞くことができた発表でした。

計測の部分では、何かしらパッケージ商品を使うのではなく、社内で自分たちなりの4 keys(4keysの定義にしたがったら自分たちのプロダクトにおける4 keys)を考えているのが印象的でした。プロダクトの理解が浅いので指標の妥当性まで細かくは判断できませんでしたが、自分たちの組織に見合うように言語化している姿勢がよかったです。

生産性向上に向けた取り組みとしては、普段から4 keysに接するような機会を作るためにレトロスペクティブに4 keysを組み込んだという工夫が、単なる意識付けに留めない取り組みとなっている印象があってよかったです。

GitHub Actions & オートスケールするSelf-hosted runnerで実現する KAGのみんなのCI/CD

CI/CDの構築方法としてGitHub Actions+Self-hosted runnerの話があり、そのCI/CD基盤をどのように運用しているのか?を最後に説明するという構成で、見事にまとまっていました。

有志での対応ということですが、ごりごりActions Runner Controllerで頑張られているのはなかなかすごいですし、terraform-aws-github-runnerを使わずに労力をかけている理由というのも納得できました。

技術的に制約はなく、自分たちがやりやすいようにしている結果の話だという前提が最初にあった上での発表ということもあって、なんだかんだ今はGitHub Actionsなんだなあというのを実感する発表でもありました。

ファクトから始める改善アプローチ Ep. 2 〜 Four Keys の先にあるアウトカムに向き合ってみた 〜

アウトカムの計測というのは一つのテーマとして色々なところで語られていますが、その中でもEBMをもとにしながらアウトカムの定義をした事例が聞けたのが特によかったです。

また、指標を定義する際に、その道のプロフェッショナルにヒアリングをしたりインタビューを通して指標を洗練させていくというのも、組織で納得感ある運用をしていくにあたって非常に重要なステップなんだろうなあというのを個人的に感じました。

Reliable and Faster Deliveries: Complete Test Automation

テスト自動化を通して信頼性が高い製品を作るために必要な要素がプレゼンテーションの中にぎゅっと凝縮されていました。

一つのプレゼンテーションで扱うスコープとしてはだいぶ広かったので、細かな部分までは話が聞けませんでしたが、色々な観点からのベストプラクティスが幾つも紹介されていて、テスト自動化を考えている人はまずこれを見ればよいのではないか?と感じるセッションでした。

QAセッションではありましたが、テストスキルというよりも開発力の部分にかなりフォーカスをしている印象があった発表で、これまで自分が聞いてきたQA関連のセッションとはいい意味で全然異なる印象を感じる発表でした。

カオナビのGitLab CI/CDにおける自動テスト運用と速度改善

前半にあった使われなくなったE2Eテストの話では、E2Eテストが「ない」ことよりも「使われなくなった」方が組織に与えるダメージとしては大きいんだな、というのを一つの事例ベースではありますが実感するような内容でした。

後半にあったGitLab及びSelf HostでのGitLab Runnnerを使用していく中で出てきた課題やその対応策の話では、以前の失敗経験を活かそうとした結果(?)スモールスタートが一つのキーワードになっているように感じました。

難しい大きな問題に対して、全体を見つめた上で小さな課題に対応していく様子が見られて非常に刺激を受けることができるプレゼンテーションでした。

組織のサイロを打破する!エンジニアがオーナーシップを持って共創する開発プロセス「インナーソース」

DevOpsの文脈でも語られる組織文化の変革(透明化)と絡めて、インナーソースの取り組みの意義やインナーソースにまつわる誤解、インナーソースの効果的な活用方法やアンチパターンの話がメインにあり、最後にAIとの協働に関して話がありました。

最初はインナーソースが解決したい問題意識について話があったのですが、組織のサイロ化を仕組みを活用して壊せるのは非常に魅力的だなあと感じましたし、DevOpsやXPといった思想との相性が知れたのもよかったです。

中盤はインナーソースにまつわる誤解やインナーソースが活用できるユースケース, アンチパターンの説明がありました。
スライドに出ていたほど極端な誤解はなかったですが、自分の捉えている範囲が狭いことを痛感するような話が多くあったので非常に学びが深かったですし、抽象的なポイントから現場であるあるな事例の話まで広く聞けたことで、理解が深まりました。

最後はAIとの協業にまつわる話がありました。
ここでもインナーソースの考え方が繋がってくるというのは見事な流れでしたし、GitHubの中の人からGitHub Copilotの話が聞けて面白かったです。

自分は全然インナーソースに詳しくない状態で話を聞いたのでインナーソースに対する理解が深まったという意味でまず勉強になったのですが、DevOpsという参加者のコンテキストから見事にインナーソースの魅力を伝えている点や、スライドとトークの組み合わせ方がめちゃくちゃ上手な点など、発表のクオリティという意味でも勉強になることが非常に多かったです。

Building Apps in Kubernetes the DevOps way: Tools, Trick and Tips

セキュリティ周りを中心としたk8sの周辺ツールとして、Secret management, Container tools, Container image signature, Software Bill of Materials, Valnerability scaninngそれぞれの観点でツールの紹介をしてくれる実用性が高いセッションでした。

セキュリティ周りのツールはどうしてもアジリティを下げたり開発者体験を悪化させるイメージが個人的には強いのですが、今回紹介されたツールは話を聞く限りそこまでアジリティや開発者体験の低下に寄与しないようなツールも多くあったので、Container image signature, Software Bill of Materialsを中心に、幾つか気になるものを使ってみようと思いました。

肥大化・モノリス化するプロダクト開発組織を自律的で小さなチーム群に変えていく ―kintone開発チームの事例―

「自律的な判断ができるまでにチームを小さくする」という原則のような取り組みを大規模プロダクトで愚直に適応した事例が聞ける素晴らしい発表でした。

組織の変遷を時系列で追いながら、各種取り組みとその中で見えてきた課題の説明をしてくれたので、実際に組織の変遷を追体験できるような感覚があって非常に楽しかったです。

発表でもありましたが、部門に閉じず全体的な視点でアドバイスを与えてくれたりサポートをしてくれるメンバーの存在というのは、こうしたチーム分割をしていく上で一つの鍵になるんだろうなあというのを個人的には実感しました。

変更障害率0%よりも「継続的な学習と実験」を価値とする〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜

最初はDevOpsとは程遠い「障害は起こってはいけないものであり変更障害率は0%を目指すべきである」時代の話から始まったのですが、このあたりは自分自身も前職で経験がある話だったので、強い共感を持ちながら話を聞いていきました。

その後、GoToさんがまず明確にそのスタンスが間違っていることを発生したあたりまではそれなりに聞くような話だったのですが、そこから地道に活動を続け、100点ではないにしろ確実に過程を踏みながら障害を学習の一つとして捉えていく道のりの話になったあたりからは組織の強さやGoToさんを中心とした色々な方々の凄みがひしひしと伝わってきました。
特に、スクフェス大阪で得た学びを次の日から行動に移して次の次の日にはDirtをやっているのは本当にすごくて、きっかけ一つでここまで大きな変革が起きるのか...!というのを実感しました。

最後は、そうした活動をふりかえって再現可能性を高めるようなまとめに続いていったのですが、ここでもいくおさんらしい切り口で、相手を信頼して尊重した結果起きたことを見事に言語化してくれており、素晴らしかったです。

いくおさん自身や会社全体がどのように変革していったのか?というのを、発表の中で強弱をつけながらめちゃくちゃリアルに伝えているのが本当にすごくて、最高の発表でした。
また、途中にあった\DevOps! DevOps!/のスライドを見たときに「これは絶対叫ぶんだろうな」と思ったのですが、期待を超える叫びを見せてくれて大満足でした。

Understanding deeper needs

自分の思い込みや知っているプラクティスに引っ張られてしまった結果相手が求めていたことを見失ってしまうという話は本当にあるあるですが、そういったことを防ぐために、プロダクトリサーチのスペシャリストであるAras Bilgenがネガティブ/ポジティブ両側面から話すことや、感情的に声を大きくしたり話を遮ったりしないように気をつけているというのを聞くことができて面白かったです。

技術的なセッションががんがんと続く中で、「なぜDevOpsなのか?」というところに改めて立ち返れるセッションで、カンファレンス全体のセッションの中で非常にいい味を出していると感じたセッションでした。

また、さらっとAras Bilgenが話していたことに驚きました。

『品質』カルチャーの育て方 ~DevOpsの世界にフィットする5つの方法~

DevOpsの文脈で自動化を推進していくと、自動化に対する恐怖を抱く人が取り残される可能性がある&自動化に対する恐怖は人それぞれ異なる理由で持っている可能性がある、という話は、自分がこれまで持ったことのない観点だったので、自身の内省をするきっかけをもらうことができました。

フィードバック周りの部分を中心に、話を抽象化していく中でちょっと主語が大きくなりすぎているような気もしましたが、具体的な事例と課題意識がセットで語られていたので話としては頭に入ってきやすかったです。

モニタリングからオブザーバビリティへ

オブザーバビリティに関して初心者でもわかるように丁寧な説明をしてくれた見事なセッションでした。

スライドがシンプルで分かりやすかったというのもありますが、そんなに聞き慣れないような言葉であっても、実際のシステムで説明をすると具体的にどういうことなのか?というのを一個一個丁寧に説明してくれたので、表層的に単語の意味だけ知っていた言葉もだいぶ理解が深まりました。

また、プレゼンテーションがすごく上手だったので、ちょっとした小話や具体例を交えながら楽しくオブザーバビリティの話を聞くことができるあっという間の45分間でした。

Fail Fast, Succeed Faster ~ DevOpsで上手に早く失敗する

テストがこけていることにいち早く気がつけるためにしたほうがいい技術的な取り組みの紹介が具体的な例をもとに説明されていた良いセッションでした。

並列実行しているシチュエーションでは、テストが一つこけるとコケた他のテストに引っ張られて無駄にクレジット消費してしまうみたいな話はあるあるなので、バッチ分割を使いましょうというのは納得感がありました。

また、まずはマシンスペックを最適なものにしましょうというのは、元も子もないような話ですがなんだかんだ一番効くことが多いという実感がめちゃくちゃあるので、テストで上手に早く失敗するための第一歩として適切な例だと感じました。

ノリと組織 Groove & Organizations

魂を揺さぶるようなプロダクトをどうやって作っていくのか?というのを、プレゼンテーションの中で体現し続けてくれたように感じる講演でした。

プロダクトを生み出すのは人であり、その人の魂を揺さぶるような感動が起こせてこそその人たちがまた別の人の魂を揺さぶるようなプロダクトを作ることができるというのは本当にそのとおりだなあと感じましたし、人の魂を揺さぶるためにポリゴン・ピクチュアズで行われている取り組みの数々が余すことなく公開されていたのも、非常に高い希少価値を感じるkeynoteでした。

塩田さんの情熱に触れたくて、久しぶりに思わず何度も再生したくなるようなkeynoteが聞けて、この話が聞けただけでも参加して満足!という最高のkeynoteでした。

DevOps推進におけるカルチャー醸成の重要性 ~アサヒビジネスソリューションズ株式会社様の事例~

次々と問題が起きるような環境を研修の中でロールプレイングをすることで、自分たちの普段の活動と重ね合わせ、危機意識が芽生えたしそういったときにどのように動いたらいいのかが当事者意識を持って知れたというのが印象的でした。

長期戦を覚悟しても、研修で得たものを会社の中でものにしていこうと根気強く現在に進行形で組織変革に取り組まれているのは素敵だなあと感じました。

Identity-Native Infrastructure Access Management

ホスティング環境における典型的な攻撃パターンとその対策を丁寧に説明してくれたので、ホスティング環境でどういう状態だとどのような問題が起きるのかが分かるセッションでした。

特に、Connectivity, Authentication, Authorization, Auditの観点からVPNのSSO/LDAPO認証にまつわるリスクが説明され、ここに対してk8sでどのような対応策が考えられるのか?という話は、実際に馴染みがある構成も出てきたのでリスクと対策のイメージがわきやすかったです。

自分の場合はセキュリティに対する知識がまだまだ不足しているので、こうしたセキュリティ系セッションがカンファレンスで聞くことができるのは、すごくありがたいです。

How DevOps & the "Every thing as code" paradigm are powering l'Oréal's Beauty Tech transformation

ロレアル社さんの開発を支えている技術基盤について自動化をキーワードに、その基盤構成で気をつけられていることや具体的な技術要素の話がたっぷりと語られている発表で、めちゃくちゃよかったです。

各技術要素のベストプラクティスにしたがって教科書通りに実現されていてめちゃくちゃすごいなあと思うとともに、ベストプラクティスが適用可能な部分についてはかなり細かい部分まで気を払っている様子がプレゼンテーションでは語られていて、自分たちだけしかできない仕事というのに徹底的にフォーカスを当てている様子が伺えたのが非常によかったです。

How I made Prometheus Remote Write 60% cheaper in one week

Prometheus Remote Writeの新フォーマットを活用することでコストの節約を測った結果をプレゼンテーションしてくれました。

Prometheus Remote Writeのデータ送信方式を考慮して如何にバッチサイズを大きくするのか?という話はたしかにそうだよね、という感じで、イメージ通り大幅にコスト削減ができている実験結果も見ることができてよかったです。

冒頭にはPrometheus Remote WriteやPrometheus自体の説明が簡単にあった他、フォーマットの話をする際には実際に新旧フォーマットの差分を比較して説明してくれたので、イメージがわきやすく聞きやすい発表でした。

Code your Cloud Infrastructure with Jenkins and Terraform

AnsibleやTerraformといったIaCがアジャイル開発やDevOpsに与える影響と、それを踏まえてIaCがアジャイル開発やDevOpsになぜ必要不可欠なものなのか?という話を聞くことができました。

自動化との相性の良さやスモールスタート的なコスト観点からの話、スケーリングの話など大まかな概要の説明があった後に、技術要素の具体的な比較検討の話がされるという構成で話が入ってきやすかったです。

技術要素の部分ではPuppet, ChefといったTraditionalな要素からTerraformに至るまで変遷を辿りながらの説明があったので、技術要素のつながりや関わりが聞けて非常に楽しかったです。