DevelopersIO 2023に参加してきました
クラスメソッド株式会社さんが主催するイベント「DevelopersIO 2023 〜GETだけじゃもったいない、POSTしてPUTする2日間〜」に参加してきましたので、そちらについての記事となります。
本当は参加翌日くらいに公開したかったのですが色々と立て込んでいて一週間後になってしまいました。
本イベントは7/7(金)と7/8(土)の二日間に渡って開催されたのですが、私は7/8(土)の午後から参加してきました。
会場は日比谷フォートタワー(最寄り:霞ヶ関)でしたが土日はどのお店も空いていないのですね。。。
お昼ご飯を食べてからセッションを受けようと思ったのですが、あまりにもお店が空いていなさすぎて頑張ってコンビニを探して軽食を取りました。
もしかすると知らないのは私だけ説ありますが、霞ヶ関に行くのが初めての方がいましたらお気をつけ下さい。
ということで自分が参加した各セッションについて簡単にお話していこうと思います。
AWSを使ってAPI公開したくなったときに検討すべき６つの項目
時間に対してスライドが多いのもあって現地ではついていくのが大変でしたが、話されていた内容のいずれも重要で参考になる話だったと思います。
中でもAPI Gateway+Lambdaのパターンでよいかはちゃんと考えようねというお話があって特に共感しました。
サーバレスを含めてシンプルなものってそうでない一般的なものを知っていないと扱いづらいと思っていますし、その前提で考えるとAPI Gateway+Lambdaができる人よりもALB+ECSやApp Runnnerの方が一般的な構成ではあるので人員を確保しやすいというのはあると思います。
確かにAPI Gateway+Lambdaの構成は低コストかつシンプルで最低限のことはすぐに出来ちゃうから気軽に使えるというのは間違いなく利点ではありますが、逆に細かいことをしようとするとめんどくさいイメージがあるのでこのあたりは適材適所ですかね。
ちなみに私は対して知識もスキルもないので「このAPI作るにあたってAPI Gateway+Lambdaの構成だとやばそうじゃね？」という懸念が少しでもあるならば、先述したALB+ECSやApp Runnnerの方がコントロールしやすいのでそちらを使うと思います。
登壇資料
DevOpsとSREのために知るべき３つの原則
現在DevOpsを担当しているというのもあり、気になっていたセッションでした。
冒頭で「具体的なツールの紹介はしない」とあって少しガッカリはしたのですが、こちらのセッションもどれも参考になるお話でした。
木こりのジレンマのお話は本当にそうだよなと思います。
まぁこれに関しては私に限らず多くの開発者が実感していることだと思いますが、実際に行動するのはなかなか難しかったりするんですよね。
というのは、例えばリソース的な問題やチーム内のスキルの違い、組織や部門からの期待値とのギャップだったりと様々な要因が絡み合って実行できないという状況が出来上がっていると思っているのですが、中長期的に見て生産性が上がるのであれば実行すべきであるというのは間違ってはいないと思います。
ただし、実行するにあたって鍵を握る人の理解が得られるかは別の話なので、ある程度の説得材料を用意しなければならないのと用意したところで理解が得られないケースもあるので、そのあたりが面倒で放置にされがちになるという側面もあるんだろうなと思っています。
あとはDevOpsの言葉の定義については考えたこともなかったので面白かったです。
弊チームはまさに「DevもOpsも」という状況になっていますので、理想像である「DevのOps」を目指していきたいですね。
結局、課題感を感じているにもかかわらず実行に移せていないという点が最大の問題点な気がするので、セッションでも紹介されていたようなフレームワークを導入して体系化しちゃうというのがいいんでしょうね。
登壇資料
ChatGPTに独自データを付与してQAボットを作成する方法
事前予約では満員だったのですが当日枠で入れてもらいました。
冒頭はベクトル化やEmbeddingについての説明だったので知っている部分も多かったですが、LlamaIndexについては使ったことがなかったので勉強になりました。
本セッションはハンズオン形式でコードを見ながら実行する感じだったため分かりやすかったです。
実際の運用では色々と考慮することはあるかと思いますが、とりあえず動かすレベルであればすぐに出来そうだなと思いました。
また、現地で出た質問についても「ヒットしない場合にどうなる」とか「チューニングのポイントは？」とか実際の運用で課題となりそうな視点で質問されていましたので参考になりました。
運営側のサポートも手厚くてたくさんフォローしていただきました、感謝です。
登壇資料
懇親会
私は今回ぼっちでの参加だったため適当なテーブルにお邪魔しましたが、そのテーブルにいた全員(3人)が同じ会社の人で少し気まずかったです笑
なんだかんだ話していくうちに打ち解けることができて、短いながらも濃いお話はできたかなと思います。
しかし、これから他の人とも喋ろうと思ったタイミングで懇親会自体が終了してしまったのは少し残念というか、1時間で終わっちゃうのは思ったよりも少し早いなーと感じました。
とはいえ参加費1000円で軽食を食べてお酒も飲んでいるので文句は言えないですし、土曜であるにもかかわらず運営いただいたクラメソの皆様は大変だったかと思いますので、1時間でも懇親会を開いていただいたことには感謝せねばですね。
もし次回も参加するとなった場合は1時間という前提で動こうと思います。
最後に
このようなイベントに参加するのは初めてでしたが有意義でしたし楽しかったですし、また機会があれば参加したいと思いました。
反省点としては、昼飯難民になりかけて焦って行動してしまったのでもう少し事前にリサーチしておくべきだったなぁと。
あとは写真をもっと撮っておけば良かった。
くらにゃんとのツーショットくらいしか撮っていないので、次に参加するイベントではもっと写真を撮ろうと思います。
くらにゃんかわいいですよね、こういうマスコットキャラクターがいるとその会社に対してポジティブな印象を与える効果もありそうだなと思いました。
【書評】まんがわかる デザイン思考
デザイン思考とは何か知りたい、将来PdMを目指しているという方にオススメです。
漫画形式でストーリーも赤字経営のカフェチェーンを立て直すという現実的なお話なので分かりやすくサクッと読めました。
あとはよく見かける「カスタマージャーニー」や「ブレインストーミング」についても触れられており、実施の流れやポイントについても記載されている点が良いと感じました。
逆にデザイン思考について知っている方や既にPdMとしてプロダクトマネジメントをされている方などにとっては物足りないだろうなと感じました。
本書から得られる情報は
- デザイン思考とは何か？
- デザイン思考の各プロセスについて
- 各プロセスをスムーズに進めるための手法やフレームワークについて
などを簡単に触れられるというだけで、それ以上のことは得られません。
私みたいな「デザイン思考って何ですか？」という人が最初に読む本としては適していますが、そうでない人は読んだところで得られるものは少ないだろうなと思いました。
社内SEやコーポレートエンジニアにも読んで欲しい
私は現在コーポレートエンジニアとして社内の業務改善を行なっていますが、ぜひ社内SEやコーポレートエンジニアの方にも読んでほしいと思いました。
特に私のような社内の業務改善を行なっている人は社内PdMと捉えることもできると思っていて、従業員の体験を良くするという観点でデザイン思考という考え方を取り入れるのはアリだと思いました。
どこにペインがあってそれをどう実現するのかというのはプロダクトも社内も変わらないので、社内SEやコーポレートエンジニアであってもこのような思考を持つことは大事であると考えます。
また本書でも触れられていますが、ユーザからの声を安易に聞くのは危険でこちらからアプローチをすることも重要だと思っていましたが、本書で触れられている「カスタマージャーニーマップの作成」「ブレインストーミング」などの手法やフレームワークがあるとアプローチしやすいなと感じました。
私は全社員が利用するSlackアプリの開発などに携わってきましたが、改善点や潜在的ニーズを洗い出すためにこのようなフレームワークなどを活用してみようと思います。
解説だけでなくマネジメント的な観点も触れられている
例えばブレインストーミングを実施する上でのポイントとして
- 質より量にこだわろう
- 案は多数決で決定しよう
などの手法そのもののポイントがいくつかあげられているのに対し、
- 上下関係の影響を排除する
- 支配欲に気を付ける
などの人間関係やマネジメント的な観点についても触れられているのが良いですね。
このあたりは気をつけないと実施そのものが苦痛となってしまい、潜在的ニーズからイノベーションを生み出すという本質的な部分から遠のいてしまうため、最も重要だと考えます。
ここは自分を含めて誰しもがやってしまう可能性がありますので、意識しないといけない点だと思いました。
