プロポーザル

「ちょっとした技術記事をQiitaやZennやブログに投稿するぐらいなら頑張ればできるけど、技術同人誌を書くのってとてつもなくハードル高くない？」と、思っている方、結構大勢いると思います。かくいう私もその一人でした。

しかし先日、「技術同人誌を書いて技術書典に出す」という実績を解除してみたくなり、見切り発車で書き始めてなんとか電子書籍として頒布するところまでたどり着きました。
ということで、その経緯や、実際に書いてみて感じたことをお話します。

下記のようなトピックでお話する予定です。

• 需要がありそうな内容じゃなくて良い。自分が書きたいものを書こう
• 執筆にはRe:VIEWを使おう（ここがメインかも）
• 紙で出そうとすると準備が大変そう。PDFで配ろう
• 体裁や構成は他の人の同人誌を参考にしよう

こんな人におすすめ

• 技術同人誌の執筆をゆるく始めてみたい人

生成AIアプリについて「AIがアクセス禁止情報まで見てない？」と不安を感じませんか？ RAGを使うAIチャットボットが、社外秘や個人情報から回答を生成すると重大なセキュリティリスクです。
従来のアクセス制御ではAI時代の複雑なデータ管理が困難になります。

本セッションではGoogleも採用するReBAC（Relationship-Based Access Control）を紹介します。「関係性」で制御するReBACは、B2B/B2C SaaSや社内ツールに最適です。
例えば、HRプラットフォームでAIが承認済み文書のみ表示、資産管理アプリでユーザーの銀行データへ安全にアクセス、社員が自身のCRMデータにアクセス権に基づき分析する、といったきめ細やかなデータアクセス制御を実現します。
RBAC/ABACと比較し、ReBACがなぜAI時代にフィットするのかを分かりやすく解説します。

最近では生成AI・LLM API を活用した機能が増えています。

これらの API は非常に強力ですが、一般的にAPIレイテンシーが大きいです。 それらを使った機能やアプリケーションを提供する場合、ユーザーの待ち時間は当然長くなります。
ユーザーの待ち時間は、ユーザー体験に直結する重要な観点です。 この課題を緩和するために vLLMなどの推論高速化手法は日進月歩で生まれています。
しかし、このようなモデル開発者視点での待ち時間を軽減させるための手法は数多く見かける一方で、それを使ったアプリケーション開発者視点での手法はあまり見かけません。

そこで本セッションでは、アプリケーション開発者視点からユーザーの待ち時間を短くするためのシステム設計のベストプラクティスを紹介します。
ユーザーの待ち時間の最適化という視点から、生成AI時代に求められるユーザー体験のあり方を考察します。

深夜の静寂。ディスプレイの光だけが、顔を照らす。
以前に自分が書いたコードが、まるで他人の書いた暗号のように見える。
「ここを直したら、どこが壊れる…?」
震える指でコードを書き換え、動作確認を繰り返す。時間は溶け、自信は削られていく。

「単体テストを書く時間さえあれば…」
いつからかそれが僕の口癖になっていた。

でもある日、ふと気づいたんだ。
テストがないから、この恐怖が生まれる。テストがないから、この無駄な時間が生まれる。

…逆だったんだ、と。

このセッションでは、テストに守られた安心で高い生産性を誇る開発体験を無理なく獲得するための、明日からでも始められる3つの動機づけを皆さんに提案します。
将来、テストなしでどうやって開発してたんだろう、と思ってもらえるようになればうれしいです。

テストはコストじゃない。未来のあなたを、恐怖から解放するための翼なんだ。

私は受託企業のプロジェクトマネージャーとして、あるプロダクトの新規開発からリリース後の継続改善まで、準委任という立場で関わり続けています。

最初はシステムをリリースすることを目的にプロジェクトやチームをマネジメントすることを考えて携わっていましたが、
プロダクトの開発を進めるうちに「分担しすぎたチーム」「属人的な頑張り」「ワンチームに対する表面的な願望」などいくつかの理想と現実のギャップに直面しました。
そうした経験を通していくうちに、DevOpsの考え方や、チームに向いたスクラムの取り組みの重要性に気付きました。

本セッションでは、準委任という枠組みの中で、どうやってプロダクトチームがオーナーシップを醸成していったか、その煮込みのプロセスをお話しします。

アプリケーションを提供する事業会社において、セキュリティ面で考慮しなければいけないことは多岐に渡ります。
一方でデリバリーのスピードや予算、リソース面とセキュリティのバランスを取ることは非常に困難な意思決定の連続であり、特に品質やセキュリティ、アクセシビリティなどは非機能要件として軽視されることもあります。

こうした課題への打開策として昨今では「文化の醸成」といった言葉がよく語られますが、それはどのようにして実現できるのでしょうか。
本トークでは、以前に『Software Design』（技術評論社）に寄稿したシフトレフトの体験談をベースに、セキュリティと組織文化についてお話しします。

なお、タイトルは品質文化について記された名著『LEADING QUALITY』（ Ronald Cummings-John, Owais Peer, 2023）へのオマージュです。

小規模なWebサイトを構築し、ホスティングする業務はよくあると思います。
もちろん公開して終わりではなく、定期/不定期問わずに更新作業も出てくるでしょう。
急ぎのファイル差し替え、本番しかない環境、忘れらるバックアップ、色々な課題が出てきます。

このセッションでは、 AWS Amplify のホスティング機能にフォーカスし、静的サイトのデプロイや運用にまつわる作業をデモを交えながら話していきます。

• AWS Amplify を使ったホスティング
  • Amazon S3 でファイル管理を行なう方法
  • GitHub でファイル管理を行なう方法

特に「Amazon S3 でファイル管理を行なう方法」でも、既存のワークフローを大きく変えずに運用の手間を下げられる可能性があります。
ぜひ皆さんも AWS Amplify で楽にホスティングをやっていきましょう！

「Webサイトを作りたいし、自分でも更新したい。では、CMSはどれをインストールしましょうか」というのは客先でありふれた光景です。納品物に、更新マニュアルも用意して、万全のサポート体勢！

けれど、一度、後ろを振り返ってみましょう。世間には、更新されなくなったWebサイトが溢れかえっています。場合によっては、CMSもインストールされたまま。PHPのバージョンが未だに5.6？！

私たちは、制作時にWebサイトの寿命を見誤っているのかもしれません。そう思い、2019年から、CMSのインストールをやめ、GitHubを中心にユーザの更新環境の工夫を行ってきました。本セッションでは、その工夫と、"ユーザの本当に欲しかったもの"について考えます。

[技術レベル]
ケースとそれへの考察ベースなので、特定の技術力は不要です。GitHubが何かを知ってるとわかりやすいと思います。

皆さんは普段、コーディング規約についてどこまで考えていますか？
筆者はかつてコーディング規約アンチでした。

そんな中去年のtechramen24confのt_wadaさんの登壇からベースラインを作り漸進的に開発していくことの重要性を学び、同じくt_wadaさんが出演していたPodcast、「fukabori.fm - 100. A Philosophy of Software Design (1/3) w/ twada」を聞いたことで、新たな発見を得ました。

それが、コーディング規約によってコードベースの複雑性・不確実性を下げることです。
加えてコーディング規約を定めることで求められる「腹を決める」ことによる覚悟。
これらを通して見えてきた、可読性の高いコードベースの作り方とその挑戦と結果、規約によって得た副次的な効果としてVibe Codingでの活用についもトークします。

概要: 実際の開発プロジェクトで、アーキテクチャ設計に LLM を活用した事例を紹介します。
対象: アーキテクチャ設計に関心のある方・LLM を業務で活用したい方

現代の Web 開発は、迅速なリリースと柔軟な仕様変更が求められます。そのため、対話を中心として情報を共有し、詳細なドキュメント作成は後回し・最小限になりがちです。この方法にも利点があるものの、ドキュメント不足による手戻りの発生や属人化など、課題があります。
しかし LLM の台頭により、ドキュメント作成コストの考え方が変わりました。ドキュメント作成コストが低減した前提に立てば、開発プロセス全体を見直す余地があります。

本トークでは、実装に入る前のアーキテクチャ設計において、LLM を活用した事例について紹介します。LLM の具体的な活用方法、チームでの運用、そしてその効果と課題について、実践に基づいた内容をお話しします。