Developers Summit 2024 のリレーセッションでプチ登壇してきた

の最後の時間枠で「生成AIで開発生産性向上!リレーセッション」の中で8分ほどだけしゃべってきました。

ちょうど同時刻に、「オフラインカンファレンス復活!イベント現地参加の魅力を語りつくすリレーセッション」っていう、めちゃくちゃ聞きたい感じのセッションが被ってたのが心残りですが、とりあえず初めてのデブサミ参加で結構楽しめたかなーと思っています。

資料

speakerdeck.com

とってもながーいタイトルですw

どうしてこんなタイトルにしたのかはのちほど...

登壇までの話

れいによって、どういう取り組みをして登壇に至ったのかを書いておこうと思います。

デブサミに申し込むまで

特に深い理由はなかったものの、なんとなくTwitterで流れてきてて応募してみた、くらいのノリでCFP出しました。

Developers Summitは、なんちゃらKaigiとかとは違って、特定分野に異常に詳しい人達が話すというよりは、技術的な知見や運用知見などを共有して、日本のITなコミュニティの成長に貢献していこう的な感じのカンファレンスのようです。ということで、内容もどちらかというと運用知見を多めに話をしてみようとは思っていました。

「でも、自分が生成AIとかなんとかで運用知見というと、、うーーん、なにもない(苦笑)」みたいなところから始めました。

CFP出す数日前に「ボット運用してみて良かったところ改善したところとかを、丁寧に共有すれば普通に知見として成り立つんじゃね?」ってことで、あらためて会社のブログ記事に書いていた内容を思い出し、iPadで手書きメモでストーリーを軽く練って、それっぽくCFP書いたら奇跡的に通りました。

ストーリーを深く練る

これはKaigi on Rails 2021, Kaigi on Rails 2023, と続けてきたことです。スライドは極限まで作らない。手書きでストーリーをとにかく仕上げる。

最初はマイクロソフトのドキュメントがくそすぎるとか、Microsoft Teamsでボット作らせる気ないだろうとか、愚痴ばっかりでしたが、まぁそんな発表が面白いはずもなく、結構書いては捨てて書いては捨ててという感じで推敲を重ねました。

あと、実装に踏み込むと知見の共有という部分がだいぶ薄れてしまうことから、「実装についてはブログみてください」に振り切ったり。

あとは、タイトルは惜しみなく長くして、冒頭でなぜそのように考えたかをしっかり絵で説明しよう、とか。

プロフィール登録、タイトル・概要登録、資料アップロード...

Acceptされると、本番に近づくにつれて解像度の高い情報を提供するような感じで、翔泳社CodeZine編集部のデブサミ運営事務局からけっこう丁寧に細かく連絡がメールで来ます。自分はふだんメールの習慣なんてないので、結構見逃します。メールが来たらSlack通知するとか仕掛けておくべきでしたね...。(ごめんなさい、、、翔泳社CodeZine編集部の方々...。)

あと、今回の発表は「リレーセッション」という形式上、自分のPC持ち込みではなく、共用のWindows PC上であらかじめ送付しておいたPowerPointプレゼンテーションを操作して行うというものでした。かれこれ10年くらいMacユーザなので、PowerPointなんて普段は全くつかいません。とりあえずKeynoteで作りました。アニメーション周りで非互換とかバグるといやなので、アニメーションは全く使わず、ただ絵を並べただけにしました。

PowerPointで見てみると案の定フォントサイズの調整が必要な程度には崩れましたが、10分で直せる程度のものだったので、Keynote意外と使える子でした。

練習

6分くらいで収めるよう、2回くらいTeams会議で録画してプレゼンして見直して、ってのをやってみました。

淡々と10分弱しゃべるのだと全く面白くなくて、

こういうスライドを急遽追加したり、

あとは、ながーいタイトルを口にすることなく進めるというのも意外と難しくて何度か練習しました。

で、タイトル長すぎじゃね?

「ChatGPTを個々人が使っていた組織から、チームチャットにボットを棲まわせてみんなが活用する組織になるまでの変遷、ぜんぶ紹介しちゃいます」

これは、口にすると10秒くらいかかる。長い。ただ、そんな複雑なことを言うつもりもなくて、スライドにあった

これを表現したかっただけ。なんだけど、どの要素も削るに削れなくて、結局長いままになってしまった、というオチです。変に削って伝わらないよりは、多少長くてもイメージが正確に伝わるほうがマシかなと諦めた、というのもあります。

あと、デブサミの事務局の方々に審査をしてもらう段階でも埋もれないようにと意識したところはあって、生成AIセッションの応募でチャットボット系のものはいくつかあるだろうから、「なーんだこいつもチャットボット自慢かー」と誤解をされないようにしないといけませんでした。

「ChatGPTを個々人が使っていた組織から、チームチャットにボットを棲まわせてみんなが活用する組織になるまで」

だと、なんか自慢でもするのかなこいつ、って見えるじゃないですか?なので「変遷、ぜんぶ紹介しちゃいます」のように変遷にフォーカスがあたっていることを強調したのでした。

登壇

仕事の都合でどうしても前日入りが難しく、2日目の午前中移動でその日の夜に最終便で帰るという強行スケジュールで臨みました。

今年は羽田空港なので(福岡から行く身としては)かなり便が良く助かりました。

半日しかないので、ブースを回ったり他の会社の人としゃべったり、という方向に集中して参加しました。いわゆる「廊下」です。

ちなみに、なにか話すきっかけになるかな?とおもって無造作に置かれたピアノで2〜3曲弾いてみたりしたものの、そもそも自分はコミュ障だし、そもそもそんな道端でピアノ弾いている人がエンジニアとはみんな思わないわけで、この作戦は大失敗でしたw

肝心の発表自体は、ちょっと緊張気味でセリフをなんどか飛ばしてしまったので、若干時間オーバーに。ごめんなさい...。

懇親会

AIプログラミングの話を聞いたり、自分のOSSを布教してみたりしていました。mablやAutifyの方々とゆるく話せたのは結構楽しかった。

懇親会に限らずですが、デブサミはわりと「名刺」の出番が多かったです。Sansanとかじゃなくて、紙の名刺

帰り

福岡空港といえば門限があるので、北九州空港行きの最終便。

呉服町付近でメルチャリがなかなか見つからず、天神まで歩いてようやく発見。疲れていたので、電動アシスト付き自転車を初めてつかったけど、すんごい楽で感動した。室見川の前後の坂道もまったく息が上がることなくスイスイ。

まとめ

業界の有名人が結構いて、懇親会だけでも価値があると思いました。(雑w)

Kaigi on Rails 2023 現地参加して "E2E testing on Rails 2023" というお話をしてきた

幸いに登壇のチャンスがいただけたので、Kaigi on Rails 2023に現地参加してきました。

E2E testing on Rails 2023 by Yusuke Iwaki - Kaigi on Rails 2023

2年前の「システムテスト解剖学」という発表の続編的な位置づけで、RailsのE2Eテストを取り巻く技術の解説に徹する発表でした。

自分の発表のスタイルとして、「◯◯したらいいよ」「△△ライブラリ使うといいよ」系の発表にはしたくないというちょっとしたこだわりがあり、とはいえ今回の発表は手を抜くと「Playwright最高だよ、めっちゃいいよ」になってしまうので、注意深くストーリー展開を練って本番に望みました。

  • Node.jsベースのテストランナーを話す必然性
  • Railsで何をしたら幸せになれそうか?の定義
  • じつはあれもこれもしなくても、1個だけ仕組みを作ればいいんだという発見の導出

などなど、狙ったポイントについてはしっかり伝えられたかなーと思っています。

いっぽうで、DEMOのコンテンツの練習不足で、一部やることを忘れてしまうなどハプニングもありw、現地開催の面白さ・難しさも改めて実感しました。

(てか、そういえばリアル登壇これが初めてだよ自分...。Ginza railsもKaigi on Rails 2021もオンライン開催で自宅から話してたんだ。

Kaigi on Railsを引っ張る @okuramasafumi さん、および実行委員の皆様には本当に感謝です。Railsにゆかりのあるエンジニアが集まる場に参加して登壇できたことはエンジニアとして本当に至福の時間でした。

とりあえず登壇までにやったこと、当日のこと、などなどを忘れないように書き留めておこうと思います。(たぶん誰の参考にもならないw)

登壇ネタを決めるまで

今回は、おそらくかなりの倍率になろうかと思い、2つネタを出した。

たまたまE2E testingのほうが通ってしまった、というのが正直なところで、実はもう一個出していたネタ(Railsで作ってしまったものをRailsじゃなくSinatraへ移行する系のお話)のほうが渾身のネタではあった。

これはいずれどこかでまた発表するとして、まぁ世の中の期待というかお困りポイントとしてはE2Eテストなんだろなーという事情も察して、「E2E testing on Rails 2023」の準備を進めることにした。

登壇ネタの深掘り1 - Playwrightに詳しくなる

準備期間は2ヶ月もあるので、とりあえず最初にやったことは、Playwrightテストランナーのコンサルティング能力を上げること。中身を知り、どういうユースケースでどんな機能を使うべきか、詳しくなること。(はっきりいってRailsは何も関係がないw)

ただ、これをやったのにはいちおう理由も一応あって、Playwrightテストランナーは世の中のイケイケQAさん(いわゆるアーリーアダプター)がワッと使い始めているにすぎないフェーズで、もしかすると次の波がやってくるかもしれない。そうなるとPlaywrightテストランナーの何が凄かったのか?という話にもなる。つまり、現時点においてPlaywrightだけがすごい部分と、Node.jsベースのテストランナー全般としての利点と、べつに技術スタック関係ないけどPlaywrightでは利用しやすい機能と、など分けて考えておく必要がある。

Playwrightは公式の動画があり、開発してる人がかなりいろいろと紹介してくれているので、まずはそれを片っ端から見ていくことにした。

www.youtube.com

メモはこんなかんじでGoogleのメモに。

1.14から1.37まで、2年分のアップデートをとりあえず脳内に叩き込んで、次へ。

登壇ネタの深掘り2 - 必然性を感じられるストーリーの練り上げ

ここが結構時間かけたところ。Keynote触り始めるとそれだけで時間がかかってしまうので、今回もApple Pencilに投資をしてiPadでひたすら手書きメモで作っていった。

こんな感じで、図で説明すべき部分と、文章やチャートで説明すべき部分と、いろいろ脳内整理が捗った。

8割くらい作ったところで、なんかわけわからんくなって、雑記もまた色々w

仕事の方もそこそこ忙しかったので、空き時間でメモ、空き時間でメモ、空き時間でメモ、って感じでネタを作り上げていきました。

スライドの枚数的な進捗でいうと、8/21の登壇確定から10/21まで2ヶ月にわたり0枚ww

iPadでの脳内整理メモの効果により、60枚近いKeynote資料をほぼほぼ一晩で書き上げたのでしたw

登壇の反省

まず、なによりもDEMOの準備不足でした。焦って、VSCodeのPlaywright拡張機能の起動方法を忘れてしまうという大失態。

とはいえで、Playwrightの便利さが100%伝わらずとも、Node.jsのテストランナーが主流になってきているという事実づけから始めたストーリー展開により、DEMOの混乱が多少あっても、全体のストーリー理解には大きな支障が出なかったのが不幸中の幸い。

Shift + Command + Pでコマンドパレットを出すと、本来は Focus on Playwright viewが出て、うまくいくはずだったんだけど、なんか本番でやっても出なかったんだよなー・・・・必殺再起動が必要だったんだろうか・・・やっぱりわからんw

登壇発表のときに感じたこと

今回、現地の発表で、現場の様子を見ながら喋れるのが本当によかった。

2年前はオンライン開催で動画は事前収録だったこともあり、撮り直しができる最強のメリットはあったけど、やっぱり反響のないなかで喋り続けないといけない辛さも結構あった。

今回は、ONKさんらしき方が最前列でめっちゃウンウン聞いてくれているし、テスト書いてますか〜?みたいな挙手もリアルタイムにフィードバック得られるし、気分的にはかなり最高な発表だった。エンジニアリングのカンファレンスはこうじゃなくっちゃ!

発表資料

speakerdeck.com

ちょっとTwitterに共有するタイミングが速すぎて、直前の方の発表に埋もれてしまったのが反省。

サンプルコードなど

これずっと共有しわすれてましたw

DEMOサイトはこれ↓

github.com

Railsとして協調するために作らないといけない部分はこれ、ってところで紹介していたのは、いちおうGemにしていて、これ↓

github.com

ぜひ併せて見てほしい動画

Playwright作者の一人が、「なぜPlaywrightテストランナーを作ったのか」語っているものが、結構印象的です。

自動テスト関係なく、ぜひみんな見てみるとよいです。

www.youtube.com

まとめ

冒頭にも書いたように、Railsにゆかりのあるエンジニアが集まる場に参加して登壇できたことはエンジニアとして本当に至福の時間でした。また来年いけるよう準備するぞ

Rakuten miniを3000円で買って、みまもり端末にする

つくったもの

  • 学校にいるであろう時間帯は、アプリが何も使えない時計状態
    • でも親が本当に連絡を取りたいときに、電話はかかる(時計状態でも、着信画面は出る)
    • 動作確認してないが、たぶん地震速報とかそれ系もくる
  • スマホ使っていいよって時間帯は、限られたアプリだけ起動できる。

これなら「スマートフォン持ち込みなんて許さん、けど、みまもり端末に限って持ち込んでいいぞ」てきな学校を攻略できるんでは?そういう需要ありそうでは??

とか妄想してみたのであった。

つくりかた

  • 楽天ミニの中古デバイス
  • eSIM
  • 特定のアプリだけを表示するランチャーアプリ(自作する)
    • ManagedConfigurationを使って「お家モード」「学校モード」の切り替えができるように作るのがミソ

があればできる。

ランチャーアプリを作る

ランチャーと言っても、今回のユースケースでは任意のアプリを起動できる必要はない。

固定でアプリアイコンを配置してしまって、そのアイコンが押されたら特定のアプリ決め打ちでIntentを投げるだけのウルトラ適当実装で十分だ。

あとは、「お家モード」「学校モード」の2つのFragmentが切り替わるだけの1Activityのアプリを作ればいい。

ふつうにアプリを作る上ではあまり馴染みがないであろうRestrictionsManagerという機能を使い、MDMから流し込むことができる設定を定義・設定値の取得を行う。

Android Management APIでポリシーを作る

今回のアプリはAndroidバイス管理機能のKIOSKモードで動かす。(POSレジアプリとかでよく使われてるやつ)

ただ、大抵のMDMサービスを契約すると手間もお金もかかるので、簡易的なMDMサービスを自分で作ってしまうのがいいだろう。作り方は去年のアドベントカレンダーに結構細かく書いている。興味ある人は読んでくれ。

zenn.dev

で、MDMを作ってどういうポリシーを用意すればいいかというと、こんな感じ。「お家モード用のポリシー」「学校モード用のポリシー」の2つを用意し、お家モードで起動したいアプリは両方のポリシーにFORCE_INSTALLED指定で入れておく。

先の手順で作ったランチャーアプリはprivate appsとしてAndroid Management APIに登録し、以下のようにManaged Configurationを指定してインストール+KIOSKモードにする。

「お家モード用のポリシー」↓

  "applications": [
    {
      "packageName": "com.google.android.apps.maps",
      "installType": "FORCE_INSTALLED"
    },
    {
      "packageName": "com.google.android.apps.tachyon",
      "installType": "FORCE_INSTALLED"
    },
    {
      "packageName": "com.android.chrome",
      "installType": "FORCE_INSTALLED"
    },
    {
      "packageName": "dev.yusukeiwaki.mylauncher",
      "installType": "KIOSK",
      "managedConfiguration": {
        "mode": "home"
      }
    }
  ],

学校モードはmodeをschoolにしただけ。

      "packageName": "dev.yusukeiwaki.mylauncher",
      "installType": "KIOSK",
      "managedConfiguration": {
        "mode": "school"
      }
    }

あとは、適当な時間帯で、Android Management APIを叩いてポリシーを当てるようにすればいいだけ。IoTスイッチ的なものでポチッとできるようにするとさらに素敵かもしれない。

まとめ

Android Management APIがあれば専用端末作り放題で楽しい。

Rakuten miniは安くてコスパ最高