天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

最強DB講義 #19 PostgreSQL の拡張機能(山田達朗氏)に参加してきた

dblectures.connpass.com

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

会であった話

PostgreSQLの状況とPostgreSQLの強み

PostgreSQLは高い人気を誇って*1いるという話からスタートしました。

人気の理由としては、

  • BSDライセンス
  • SQLの方言があまりない
  • 拡張性が高い(OSSだからという意味ではなく、ユーザのニーズに合わせて拡張できるという意味)

の3つが挙がっていました。

拡張機能の仕組み

拡張機能の種類と数

拡張機能には公式、非公式それぞれあり、2つ合わせると1100以上の拡張機能が存在するということでした。(2022/9/1現在、公式は56個、非公式は1079個)

拡張機能には膨大な種類があるため、本イベントでは一部のみの紹介となりましたが、

  • 運用監視(pg.statsinfo, pg.stat.statements)
  • 実行計画制御(pg.hint.plan)
  • 実行計画蓄積(pg.store.plans, auto.explain)
  • 実行計画チューニング(pg.plan.advsr)

などが紹介されていました。

拡張機能を利用する際の注意点

拡張機能を利用する際の注意点として、以下の点が挙がっていました。

  • 非公式機能はリリースが不安定であるため、拡張機能が便利かどうかだけではなく、コミュニティが活発かどうかも検討指標とした方が良い
  • 不具合発生時の対応が遅れる可能性もあるため、不具合が出た際にはコミュニティベースで任せるか自分たちで対応するかを事前に決めた方が良い。
  • DBaaSではサポートされている拡張機能に差異がある。
拡張機能で手を入れることができる箇所

非常に多岐に渡っていたので驚きましたが、以下の箇所は拡張可能だということです。

  • 関数
  • 演算子
  • テーブル
  • インデックス
  • 言語
  • Custom Scan
  • FDW
  • 処理
Hookポイントの紹介

ソース上のさまざまな処理存在し、コールバックの仕組みを用いることでユーザの処理を差し込むことができる仕組みであるHookポイントの紹介がありました。

使用頻度が高いExecutorのHookポイントを中心に紹介してくれて、指定した実行時間を超過したクエリのログ出力を行うAuto_Explainを説明してくれました。関数の実装レベルまで踏み込んだ解説を聞くことができて非常に面白かったです。

Hookポイントを用いた開発の最初の一歩

まず最初のstepとしては、pg_plugins/Blackholeを使用することをイベント内ではお勧めされていました。(ソースコードも少なく拡張機能についての理解が進みやすく開発しやすい)

その上で、次のstepとしては、PG本体のcontrib/auto_explainを利用するのが良いのではないかということでした。

FDW

続いて、Postgre以外のDBMSと共存してPostgreを動かしたり、Postgreにデータをマイグレーションしたり、Postgreを複数たてて分散処理を行う場合に用いる機能であるFGWの説明がありました。

Postgre以外のDBMSと共存してシステムを稼働させる際にFDWを利用すると、データのエクスポートやインポートをすることなくPostgreでSQLを発行するのみで済むというメリットがあるという話や、FDWには125種類もの種類があるという話、PlannerとFDW APIsのマッピングに関する話...をしてくれました。

FDW開発の最初の一歩

Hookポイントと同様に、どういうstepを踏んで開発を行うといいかの道筋を紹介してくれました。

まずはBlackhole_fdwを動かし、Postgres_fdwなど自分のターゲットに近いfdwを触ってみるのがいいのではないかということでした。

拡張機能の開発者向け留意点

以下の点が、拡張機能を開発する際の留意点として挙がっていました。

  • C言語の習得が必須
  • Postgreのアーキテクチャ理解やDBMS全般の理解が必須
  • システムリリース後のメンテナンスコストの考慮が必要(バージョン追跡...)
  • 公式の拡張機能を作る際には開発コミュニティと何度も議論が必須
拡張廃発に取り組む意義

上で書いた留意点を踏まえても、拡張機能を開発する意義は確実にあるということで、特に以下のポイントについて紹介がされていました。

  • 利用者よりも深い知識の習得が可能
  • 自社のみならず開発コミュニティ全体への貢献が見込まれる

全体を通した感想

話の順序や内容の粒度、スライド、話し方...どれをとっても質が高くて、非常にわかりやすかったです。

拡張機能開発にちょうど興味を持っていたところだったので関心のあるテーマだったので、参加することができてよかったです。

*1:DBエンジンランキング4位、AmazonGoogleをはじめ、クラウドベンダの多くがPostgreSQLのサービスを提供している

【製造業アジャイル勉強会】LT大会&オンラインOSTに参加してきた

beyond-hardware-agile.connpass.com

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

会の様子

以下、イベントで話されていたことを箇条書きで書いていきます。

社内での仲間の作り方

  • 最初に大きいイベント(社内カンファレンスやAgile Japanの企業サテライト...)をやってみる。その後、大きなイベントで興味を持ってくれたメンバー向けに小さなイベントを定期的に開催していく。興味がある人が釣れたり、実はアジャイルをやっていたという人が現れたりする。
  • 如何に楽をして継続するか?ということを考えてみる。
  • 一緒に運営をしてくれるコアなメンバーを見つける。
  • 偉い人からのお墨付きをもらう。
  • Fearless changeを参考にする。
  • スクフェス三河に参加してみる。
  • 以下のスライドを参考にしてみる。

www.slideshare.net

www.slideshare.net

LT大会*1

高石さん

「モノづくり」に適したアジャイル開発の難しさや現実をプレゼンしてくれました。

ハードウェアは(特に仕様検討など)アジャイルに作らずにウォーターフォールのアプローチを活用した方がスムーズに作れる実感があるという話だったりと、製造業というコンテキストでアジャイルをやる難しさや、そういったコンテキストの中でもアジャイルが適用できている部分の話を聞くことができて楽しかったです。

まつしゅーさん

まつしゅーさんといえば、人を積極的に巻き込みながら社内外かかわらずコミュニティに貢献されているイメージが強いのですが、今回は新卒入社してから2017年まで15年間もの間培ってきたはんだ付けに関する知識をLTに凝縮してくれました。

技能オリンピックのメダリストであることやはんだ付けに関してこれだけ高い技術*2を持っているのは知らなかったので、めちゃくちゃ驚きましたw

まさひろさん

JIRAを活用してスクラムを行っている現場の様子を見せてくれました。

JIRAは普段からPJで使っているのですが、自分がこれまで考えたことがない活用方法を聞くことができて面白かったです。
及部さんも言っていましたが、JIRAは悪口も聞く機会が多いので、今回のようなJIRAを見事に活用したプレゼンを聞けたのは楽しかったです。

いづさん

スクフェス札幌の魅力をたっぷりと伝えてくれるLTをしてくれました。

スクフェス札幌に参加することで得られるメリットが存分にわかるプレゼンテーションで、とても飛び込みとは思えなかったです。
かわいい新キャラやkeynoteの紹介を聞けたのは特に印象的でした。

色々と秀逸なネタがあって笑ったのですが、途中でkeynote speakerであるkiroさんに話を振るのは一番笑いましたw

いいださん

GDPR*3の後に来たるサイバーセキュリティ法規制についてお話をしてくれました。

GDPRもサイバーセキュリティ法規制も全然知らなかったのですが、うまく噛み砕きながら周辺概念*4と合わせて説明をしてくれて、とっても勉強になるプレゼンテーションでした。
また、安定した語り口だったので非常に聞きやすかったです。

全体を通した感想

LTは久しぶりでしたが、賢くなるプレゼンテーションもあり、聞いていて盛り上がったり笑ってしまうようなプレゼンテーションもあり、バラエティ豊かでLTの醍醐味を実感できました。

途中参加途中抜けでしたが、製造業色もよく出ていて、最高のイベントでした!

*1:タイトルはメモしそびれてしまっているものも多いので発表者ごとに様子を書いていきます

*2:0603は肉眼で余裕、業務外に暇潰しでやっていたはんだ付けが社内展示された

*3:2016年に施行されたEUの法律

*4:SBOM...

大人のソフトウェアテスト雑談会 #122【ずんだ】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に参加してきたので、会の様子と感想を書いてこうと思います。

Agile testの失敗パターン

テストプロセスの組み立てができない状態でAgile testを学ぶと、いつどんなタイミングでどのようなテストをしないといけないのかが分からない状態に陥ってしまいながら、なんとなくテストが先延ばしになり、最後に慌ててテストするという状態が起きてしまうという話が出ていました。*1

品川アジャイルスクフェス

www.youtube.com

www.youtube.com

スクフェス仙台でもスクフェス新潟でも品川アジャイルが大活躍していましたが、こちらの副音声ライブの比較や、副音声ライブに込められた想い(スクフェスを知らない人にも認知をしてもらうためにやっている...)、ハイブリッドなカンファレンスを開催しているからこそ出てくる葛藤(オンラインと現地をつなぎたい...)などを聞くことができました。

オンラインとオフラインのハイブリッドはスタンダードなスクフェスの開催形式になりつつありますが、オンラインとオフライン両方で楽しめるコンテンツになっていくかは、今後も常に出てくる課題だと思うので、難しい問題だなあと思いながら聞いていきました。

カメラの画角

Tommyさんやeroccoさん、Ryoさんレベルの方々からしてみると、配信されている映像のカメラワークでカメラマンがプロかどうかや気を抜いているかどうかがわかるそうです笑

そのあたりは自分は全然分からないのですが、こういった細かい違いに気がつくことができるというのが純粋にすごいなあと尊敬の念を抱きました。

全体を通した感想

途中参加でしたが、今日は前半めちゃくちゃ真面目なテストの話をしていて、会のタイトルにふさわしく(?)テストの勉強になる話が多数ありました。

いつもよりは短めの参加でしたが、今日も楽しかったです。

*1:Agile testだからこそ起こるような問題ではないかもしれないものの、Agileでやると問題が顕在化しやすいという話でした

スクフェス仙台のスライドまとめ

スクフェス仙台が8/26-8/27の2日間で開催され、無事に終了しました。
運営の皆さん、登壇者の皆さん、参加者の皆さん、お疲れさまでした!

www.scrumfestsendai.org

ということで(??)、スクフェス仙台のスライドをまとめていきます。(ワークショップセッションは省いています)

公開しているけど貼られていないよ!というものがあれば教えてください。

Kazumasa Ebata - Various Scrum Teams

スライド非公開

Ryutaro YOSHIBA (Ryuzee) / Harada Kiro / Miho Nagase - パワポカラオケ「スプリントプランニング Deep Dive」

www.ryuzee.com

Fujihara Dai - アジャイルになれない開発入門

スライド不明

Yasunobu Kawaguchi / amix edcolor / Iwao Harada / Kei Ogane / Norihide Fujiki / Ryo Tagami / Yuichi Tokutomi - 品川アジャイル presents : カンファレンスの廊下を実況中継

www.youtube.com

Toshiyuki Ohtomo - ダイナミックリチーミングから学ぶ、不確実な状況に適応し続けるためのチーム作り

www.docswell.com

kyon _mm - スペシャリストになれなくても成長する方法 #5000dai

speakerdeck.com

Miho Nagase / Kazunori Otani / Mitsuo Hangai / Teppei YAMAGUCHI / Tsutomu Yasui / Yosuke Ota / Yudai Moriya - F1 仙台グランプリ'22

speakerdeck.com

Kazuki Mori - プロダクトオーナーのための、ふりかえりが日常に溶けるチームのつくりかた

t.co

Koki Shimizu - Certified Team Coach(CTC) への道 〜スクラムマスター・アジャイルコーチのスキル探求〜

スライド不明

Hiroyoshi Takahashi - ど根性学生起業 CTO編 ~ソフトウェアの素晴らしさに目覚めた大学生が起業してみた...そして今~

スライド不明

Kenichiro Okada - 組織を変革する最初の一歩に躓いたけど、それはそれで良かった話

speakerdeck.com

amix edcolor - 週6時間でうまくいくスクラムのはじめかた

スライド不明

Imai Takaaki - アジャイルであり続けるために技術スキルと向き合う

speakerdeck.com

Satoshi Harada - その心理的安全性は間違っている!心理的安全性で陥りやすい間違いとその対策

speakerdeck.com

Shinya Ogasawara - 意志の弱い自分を許せるようになる(かもしれない)セッション

speakerdeck.com

Akiko Iwakiri / Kenta Sasa / Taku Iwamura / Tsutomu Yasui / Yosuke Ota / Yudai Moriya / Yuji Imagawa / Yukei Wachi / yumi kanehira - ワインバーグ先生の未訳本『フィードバック』のエッセンスと読書会の体験

speakerdeck.com

システム運用アンチパターン - Forkwell Library #4に参加してきた

forkwell.connpass.com

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

会の概要

エンジニアのキャリアを全力で応援する、エンジニア愛に溢れた転職サービス「Forkwell」。  これまで Forkwell のイベントで登壇されたエキスパートの方々は、先達が記した書籍から「気づき」を得て実践し、振り返り、再現性のある「学び」として身に付けていく中で、実績を築いてこられました。

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

今回の第4回目では2022年4月に出版され、一躍人気書籍となった『システム運用アンチパターン』を取り上げます。翻訳者である田中 裕一氏をお招きして明日から権限がなくとも実行出来るアンチパターン解決アプローチを伺っていきます。

また、事例講演として株式会社Algoage CTOの安田 洋介氏を迎えて、少数組織におけるDevOpsについてお話をいただきます。

会の様子

システム運用アンチパターンが書かれたきっかけ

世の中が、ユニコーン企業と自社を比較して失敗する企業が多いことや、ユニコーン企業が普通の企業と全然違ったコンテキストで行っていることがベストソリューションとされているような風潮に問題意識を持って著者が本書を出版したというエピソードを紹介してくれました。

パターナリスト症候群

問題を解決するために、問題が起きた事象(例えばデプロイなど)に関与できる人を減らすような解決策に陥るパターナリスト症候群の話をしてくれました。

パターナリスト症候群に陥らないようにするための手段としては、本書だと自動化が挙げられているのですが、訳者の田中さんは、この自動化が単なる効率化やミス防止でされているわけではない点を気に入っているそうです。
具体的にいうと、待ち時間・実行時間・実行頻度・実行のばらつきという風に自動化の観点を細分化した上で、マネージャーをはじめとしたチームメンバーに説得する際にはただ「自動化したい」というのではなく、この細分化した観点で話をするといい旨が書いてあるのが、良いということです。

これは痛いほど経験がある話なので、めちゃくちゃ共感できる話でした。

アラート疲れ

良いアラートとして、

  • 行動可能
  • イムリ
  • 優先順位づけがアラートの中でもされている

の特徴が挙がっていました。

こうしたアラートを作るためには、ユーザーやビジネスの観点からアラートを考えることが必須で、そう考えるとプロダクトに関わるすべてのチームによる協力が必要だよね、というお話をしてくれました。

システム運用アンチパターンの実践

システム運用アンチパターンの内容を実践しているAlgoageの安田さんからどのように実践しているお話がありました。

単体テストでなるべく早い段階でリスクヘッジをして、E2E testを最低限に抑えることが運用段階でのバグ発生を減らせるといった話やシステムの状況を見える化しようという話など基礎を忠実に守った実践事例から、自動化のコストを検討した結果あまりにも高い場合はまずはダブルチェックなど機械に頼らず低コストでできるパッチ的な対応をするなどといった現場の事例など、バランス良い話が聞けました。

本書で書かれているような内容を実践するために、文化の醸成に寄与した人の評価が高くなるような評価システムを活用したり、採用段階で文化とのマッチ度を最重要要素としているというお話も併せてしてくれました。

Q&A

以下からは、Q&Aで話されていた内容を常体+箇条書きで記載していきます。

DevOpsで運用を実践しているのだが「こういう時はこうする」という条件分岐が多すぎて覚えるのがしんどい
  • アラートの文面に徹底的にこだわる。ドキュメントリンクを貼るとか。改善はもしいるならオンコール担当がやるといいと思う。(アラートを見る人が良いアラートに一番詳しいと予想されるため)
作業手順書の自動化(承認プロセスの自動化)が難しい
  • 承認が明確な基準に向いている場合はその基準を自動化すればいいと思うのだが、特に基準は持たずヒューリスティックに承認に携わっている場合は難しい。こういう時は、承認プロセスを自動化しつつも既存の人がやる承認プロセスも残し、自動化した承認プロセスの承認結果と人がやる承認プロセスの承認結果が一定期間一致し続けたら、その結果をもとに自動化を提言すると良いかもしれない。
  • 承認者を固定化せずにダブルチェックするところからスタートしてもいいかもしれない。承認者が複数いれば、権限移譲が進みつつ経験が様々な人に蓄積され、自動化のヒントも得られる。
  • まずはチャットで承認がされたことや、承認する過程を見える化するようなところから自動化してもいいのでは。
オンコール担当を賃金や代休で守ることは実際に日本でされているのか?
  • 正直よくわからないが、労働時間管理をマネージャーが握っているとかはあまりないと思う。
  • 正直よくわからないが、代休を自社では取り入れている。
Algoageで価値観共有するためにやっている具体的な話を聞きたい
  • マネジメント勉強会
  • 相手を思いやる
  • 価値観を言語化して、共有する

会全体を通した感想

講演者のお二人とも説明がわかりやすくて、内容がすっと頭に入ってくるイベントでした。事例と理想の噛み合わせが聞けたのも、いつもながらよかったです。

運用の苦悩が改めて思い出される会でした笑

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

agile-studio.connpass.com

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

会の概要

「SMが変わるとチームが変わる!」というテーマで、木下さん天野さん家永さん+懸田さんでお話していくイベントです。(なお、今回は特別回ということもあって、懸田さん自身がテーマを持ち出してくれました)

会の様子

自己理解

恐れや不安があることに自覚的になっているか?という観点で、自己理解をいかに深めていくことが重要だというお話がまず頭だしとして懸田さんからありました。

「こういうことを言ったら嫌われるんじゃないかな?」といった気持ちを自覚できるようになると、特にSMは日々の行動に変化が生じるのではないか?ということです。

アジャイルコーチの方々が現場で見てきた(感じてきた)不安

上の話に通じて、天野さん木下さん家永さんが現場を支援する中で感じてきた不安や見てきた不安について話をしてくれました。

現場で実際に感じてきた不安
  • アジャイルコーチとして価値を出せないことで、「もう来なくていいよ」と言われてしまうのではないか?という不安
  • (やや威圧的な)POの期待がわからないという不安
現場で実際に見てきたSMが感じていた不安
  • スクラムマスターとして価値を出せないことで、「もういなくていいよ」と言われてしまうのではないか?という不安
  • ぎくしゃくしたチームの関係をスクラムマスターとして修復できないのではないか?という不安(修復できないことでチームが顧客に価値を届けられないことを不安だと思っている)

不安を払拭するための行動は大きな意味を持たない

自分自身の不安を払拭するための行動は、行動だけ切り取るとグッドプラクティスに見えたとしても、結果として何かしらいいインパクトを残さないことが多い実感があるという話を懸田さんがしてくれました。

例えば、「スクラムに関する勉強会を開催する」という行動は、一見すると望ましいように見えても、SMが「自身が貢献できていないのではないか?」という不安を解消するために開いていた場合(=チームが求めていない場合)は、結果としてスクラムを上手に回すことにつながらないのでは?ということです。

こういった行動をしないようにするためには、自己理解を深めることが重要だというお話で、自己理解を深めることで、自身の不安に駆動されない選択肢を選べるようにしたいということです。

全体を通した感想

懸田さん節が全開で、その人自身の内面にフォーカスして色々な話を聞くことができました。

いつもの御三方で繰り広げられる話も楽しいのですが、ゲスト会もとっても楽しかったです。

スクラムフェス仙台(のKeynote)に参加してきた

www.scrumfestsendai.org

本日から2日間にわたってスクフェス仙台が開催されます!

今日は1日目ということで、Keynoteに参加してきたので、Keynoteを聴いて印象的だった部分を書いていこうと思います。

ただし、今回のKeynoteは、動画の録画や資料の連携、スクショが禁止されていたため、内容の具体的な言及(特にどういうコンテキストでの話だったのか)は避けながらの記載になる旨、ご容赦いただければと思います。

斬新なKeynoteスタイル

今回のKeynoteは、一般的にイメージされるスクラムから遠い事例を話してくれたのですが、スクラムから少し遠い事例を7名の方々が話して、江端さんがそのモデレータとなる発表形式で実施してくださいました。

新人が大多数の中でのスクラム

新人が半数を占め、スクラム経験がないような人たちがほとんどという状態でスクラムにチャレンジしたという話を聴いていきました。

ふりかえりが上手にできないから、その前にふりかえりの練習をしようとしたりする事例をはじめ、何がなんだか分からない中でも試行錯誤される過程の話が聞けてよかったです。

テスト実施が専門なチームでのスクラム

テスト実施を専門にしているチームでどのようにスクラムを実践していったのか?というお話を聴いていきました。

PJの規模がめちゃくちゃ大きいということもあり、実行する必要があるテストが100万件近い数生じてしまう(全ケースを)中でPBIをインクリメントする過程でFailしたテストケースをPBIに切って、そのPBIを優先順位順に対応するということをしているそうで、その中でされている工夫や、今後やっていこうと思っていることのお話を聞くことができて、非常に面白かったです。

受発注の関係性が定着していてチームが複数ある中でのスクラム

  • 部署や組織が複数ある
  • 受発注の関係性が定着している
  • 対象とするユーザの数が桁違いに多い
  • 元々ずっとWF開発をしていた

という状況の中でスクラムを導入した話を聴いていきました。壁を作っていた人たちも多い中で目的意識やKPIを揃えながら関係者全員を集めて、改善をしていったというのは大規模なチームでも基礎が通用することを実感できる事例紹介で面白かったです。

One Teamで仕事をやっていくことや、組織/部署間の摩擦を減らしていくことで結果的にプロダクトリリースまでのリードタイムが大幅に短縮されたというのは面白いなあと感じました。

組織運営でのスクラム

組織運営をしていくにあたって、CTOがPOになってスクラムを実践していった話を聴いていきました。

事実や指標を基にしてデータ中心の客観的なふりかえりをしていく話や、多忙なCTOがどのように責務を果たして他のメンバーがどのようにサポートしたのか、という部分は非常に面白かったです。*1

ステークホルダー数を早退見積の指標の一つとするというアイデアと、中長期的な課題もスクラムを実践することで扱いやすくなったという話は特に面白いなあと感じました。

人事でのスクラム

差し込みでの業務が多い人事チームでのスクラム導入事例を聴いていきました。

簡単に業務やスクラムの難しさを説明してくれた後、スクラムに導入したオリジナルプラクティスを説明してくれたのですが、見積にまつわるプラクティスや(医療現場で用いられている)SMART法を参考にしたプラクティスなどを聞くことができて学びがありました。

1on1がPBLとして積まれていたりしたのは、なかなか面白かったです。

全体を通した感想

冒頭にも書いた通りこれまでにないKeynoteで、予想することができないようなKeynoteで、スクラムフェスを実感することができました。

普段聞けないようなスクラムの事例がいくつも聞けて楽しかったです。

*1:データはふりかえりで得られた気づきの数だったり、JIRAのレポートベースで取得しているそうです