トーク

dbt-coverageというツールをご存知ですか？

dbt-coverageとは、dbtのテストやドキュメントのカバレッジを計測するツールです。dbtはデータワークフローをSQLとYAMLで定義するソフトウェアで、dbt-coverageとはDBのテーブルに対するテストケースや、YAMLファイルにdescriptionの項目が書いてあるかを計測します。

一見するとよくあるツールに見えるのですが、コードの量が非常に少ない。実のところ、ソースコードが1000行ぐらいしかありません。この量では、とてもYAMLをASTに直し、構文解析することは不可能なように感じました。

本セッションでは、このdbt-coverageのソースコードを解説し、どのようにして短いコードで有用なカバレッジ計測ツールを実現していのかを解説します。

皆さん社内で技術交流していますか？
私はしたいですが、できてません!!

現在は様々な会社でテックブログや勉強会、イベントの主催などで社内・社外でのエンジニア同士の技術交流が活発です。
ただし、全員が全員、活発な会社にいるとは限りません。

社内の技術交流を活発化できないかと、細々半年、本格的に活動を始めて半年が経過し、
どういう施策がダメ・よかったか、ダメだった施策の原因と対策など皆さんに共有できればと思います。

プログラマーとして生きていると、仕事をする中であるいは日々の生活の中で、ちょっとした自動化のためにスクリプトを書くことがあるでしょう。
そういったスクリプトはすぐに使い捨てるつもりだったり、あとで修正することもなかったりするかもしれません。

このとき、みなさんは「最低限の品質」をどこに置きますか？
いざ、ぱっと聞かれると返答に困るような質問かもしれません。

私のなかではある程度の基準があります。
本トークでは「ちょっとした自動化のためにパッと書いたスクリプト」をいくつかのレベルに分けて、どこまで作り込むかの観点と判断基準の一例をお見せします。

MVCモデルのフレームワークにおいて、編集ファイルが多くなり、レビューが大変になったこと、ありませんか？
どうしても編集ファイルが多くなると、変更の意図が伝わりにくく、見落としも増えがちですすよね。
スケルトンコードを活用して学びを最大化しつつ、効率的なコードレビューを実現した方法を紹介します。

お話しすること：

1. MVCモデルでの変更の複雑さと課題
2. スケルトンコードについて
3. 実際の使用結果と得られた学び

何が得られるか：

• スケルトンコード活用法
• チーム全体の開発プロセス改善のヒント

こんな人におすすめ

• 若手エンジニア
• 育成に関わる人
• コードレビューの効率化に興味がある人

似たような経験をしたことのある方にとって、少しでも参考になれば嬉しいです！

MVCモデルのフレームワークにおいて、編集ファイルが多くなり、レビューが大変になったこと、ありませんか？
どうしても編集ファイルが多くなると、変更の意図が伝わりにくく、見落としも増えがちですすよね。
スケルトンコードを活用して学びを最大化しつつ、効率的なコードレビューを実現した方法を紹介します。

お話しすること：

1. MVCモデルでの変更の複雑さと課題
2. スケルトンコードについて
3. 実際の使用結果と得られた学び

何が得られるか：

• スケルトンコード活用法
• チーム全体の開発プロセス改善のヒント

こんな人におすすめ

• 若手エンジニア
• 育成に関わる人
• コードレビューの効率化に興味がある人

似たような経験をしたことのある方にとって、少しでも参考になれば嬉しいです！

PHPerの皆さんは自分が開発しているプロダクトへの愛を持っていますでしょうか？
エンジニアからプロダクトへの愛には「受託開発だから特に愛してない」から「自ら企画した自社サービスだから我が子のように愛してる」まで様々な濃度があると思います。
エンジニアが自らオーナーシップを持つために・エンジニアにオーナーシップを持ってもらうために、プロダクト愛の濃度別にできることを語りたいです。

弊社で開発しているサイボウズ Garoon は利用してくださるお客様のお陰で20年を超える長寿プロダクトとなりました。
当初はオンプレミス版での提供から始まりクラウド版を経て現在では多くのお客様で利用されています。
その中で私はお客様からの問い合わせに対応するバックサポートチームでエスカレーションエンジニアを行っています。
クラウドの障害対応はもちろんですが、Garoon はオンプレミス版も提供しているため多種多様なお問い合わせがあります。

このトークではエスカレーションエンジニアのご紹介と具体的な問い合わせや業務内容をお話します。

PHPは、エンジニア・案件ともに豊富となり、もはや習熟していれば使いどころに困らない昨今となりました。
一方で、copilotの台頭や経営層のIT解像度の深化等により、
エンジニアへ投資する目線もまたシビアになったと言えます。

そんな中で、より魅力的なプロダクト開発や優れたチームの構築へ、私たちを連れて行ってくれるものは何でしょうか？
競合に劣らぬ価値を発揮し、プロジェクトを牽引するには、何が必要とされるでしょうか。

本LTでは、業界、業種、業態(営業→開発、医療→エンタメ等)を問わず経験した話者の観点から、
「必要だったビジネススキル」「掛け算の重要性」を主題としてご紹介します。
技術に伸び悩んだ時どうすべきか。ビジネススキルとは何か。
具体・抽象を交え時間いっぱい詰め込みます。

本LTで新たな気づき・学びをご提供し、ご清聴賜りました皆様のエンジニアライフの一助となれれば幸いです。

令和の今日。性別関係なく、メイクを楽しめる世界になりました。
その中でも、爪を塗る（ネイルする）ことは開発生産性を上げる効果があると、私は考えています。

この5分で、ネイルによって得られるメリットをご説明します。

LaravelプロジェクトにおけるL5-Swaggerの活用方法と、それによるAPI開発プロセスの効率化について深堀りします。
L5-SwaggerはLaravelでSwagger（OpenAPI）ドキュメントを自動生成するツールであり、APIの設計、開発、テスト、そしてドキュメンテーションのプロセスを大幅に改善します。

システム運用時にslack通知設定をしているシステムは多々あると思います。
私が関わっているシステムでも、日々様々な通知をslackに出しています。
しかし、slack通知が多すぎて本当に必要なものが埋もれてしまったり、@channelだらけでミュートしたくてもできないチャンネルになったりしていませんか？実は通知が届いていたのに誰も対応できなかった、なんて経験はありませんか？
そんな運用の苦労を少しでも減らす方法を、実際に運用してみて直面したケースを例にお話ししたいと思います。

■話す事
・slack通知NGパターン
・slack通知を誰が見るか
・slack以外の手段
■話さない事
・slack通知の設定方法

「PHPStanを入れましょう」「静的検査、型の世界をやっていき」といった時に、
必ずしも「レベルをどうするか」「baselineがどのくらいあるか」だけに限らずとも良い訳です。

自分たちのチームやプロジェクトにとって弱みになっている部分、基準としていきたい部分について
ピンポイントでルールを入れていく道があります。
そのために、「使えるルール」が増えると良いですよね。そのまま「静的検査の語彙」になります。

さぁ！！phpstan-strict-rules が来てくれました！！！
必ずしも「全部を有効にする」っていう使い方ではないでしょう、そういうものは本体に居るはず！！

5分で全部のルールを紹介します。
紹介には、「どんなコードを指摘してくれるルールなのか？」が含まれます。

PhpStormでGitやGitHub使っていますか？

• commitしてますか？
• ブランチの操作してますか？
  • rebase, merge, switch, pullやfetchやpushも？renameも？
  • cherry-pick, revert, コミットメッセージの編集も？
  • コンフリクトの解消も？
• コードレビューも？
  • コメントを見たり解決済みにしたりリアクションをつけたり？
• ファイルや行単位での変更履歴の追跡も？
  • 該当の変更が含まれるPull Requestを開いたりも？
• 「変更リスト」の管理も？
• stashも？
• bisectも？

みたいな話をします

みなさんはラフティングというアウトドアスポーツをご存知でしょうか？
このトークではゴムボートで複数人が急流に挑戦するという川のアクティビティのガイド（インストラクター）という一見畑違いの業界・業種からWeb業界に転職してきた私が、
「アウトドアツアー」と「ソフトウェア開発」という一見正反対にも見える２つ産業を経験したうえで気付いた２つの業界の共通点についてお話しさせて頂きます

質問①：最後に誰かにほめられたのはいつですか？
質問②：最後に誰かをほめたのはいつですか？

このトークでは人間関係を円満に保つのに重要な「アクノレッジメント」と、「今日から使える」その応用テクニックについてお話します

サービスを切り出す際に、既存の再利用可能な実装を活用しつつ、ヘキサゴナルアーキテクチャを導入した背景とその効果を紹介します。このトークでは、特定のレイヤーにプロセス外依存や既存コードへの参照を局所化し、依存箇所を明確に管理することで、どのように開発効率やシステムの保守性を向上させたかを具体的な事例を通して説明します。

このトークでは、フロントエンドとバックエンドの整合性を保つために、スキーマ駆動開発（SDD）をPHPプロジェクトにどのように適用しているかを詳しくお話しします。スキーマを契約として定義し、その契約を守ることで、開発の信頼性と効率を向上させる方法を解説します。具体的には、スキーマ設計のプロセスから実装フェーズでの管理方法、さらにトラブルを未然に防ぐための戦略までを包括的に紹介します。

皆さん、チームを分割してみたけど、結局また一つにまとまっちゃったことありませんか！？

チームが分かれれば効率も上がる、役割も明確になる…なんて思っていたのに、なぜかチームが再び一つに引き寄せられてしまったんです。

その原因、実は「コンウェイの法則」にあったんです！

このLTでは、どうしてチームを分割したのに再統合が起きたのか、そしてその結果として何が得られたのかを赤裸々に語ります。

私たちが直面した課題や学びをシェアして、みなさんの組織設計にも活かしてもらえたら嬉しいです！

皆さん、丸投げされてますかーーー！！！？？？

どんな現場にも「タスクとしてパスできる状態に仕立て上げる暇がないから放置されちゃってる仕事」というものがあります。
きっと上司やお客さんは「丸投げできる人がいれば・・・」と日々嘆いていることでしょう。
そう、なんと「丸投げされる技術」があれば一生食うに困らないのです！（過言）

私はよくお客さんから「こんな雑な投げ方なのにいい感じに対応してもらってマジで助かります！あざす！」みたいなことを言われます。

一体私はどのようにしてお客さんに安心して丸投げをしてもらい、どんな手順や仕草で仕事を進めているのでしょうか。

このLTでは、仕事を丸投げしてもらったときの私の頭の中身や実際にやっていることなどをまるっと皆さんにシェアします。

皆さんも丸投げされる技術を習得して青天井の信頼をGETしちゃいましょう！

Macユーザーの皆さんにはお馴染みのHomebrew。
Macの初期設定時のみならず、日々新たに便利なコマンドを見つけてはbrew installしていることと思います。
そんなお馴染みのHomebrewですが、裏側はどんな仕組みになっていて、コマンド自体はどこからダウンロードされているのかはご存知でしょうか？

実はこれ、とても簡単な仕組みになっていて、誰でも自分のGitHubリポジトリを通して自作のコマンドをHomebrewで配布することができます。

このLTでは、実際にPHPでCLIツールを作ってHomebrewで公開するまでの流れをお話しします。
自作のコマンドをHomebrewで公開して、世界に羽ばたきましょう！