社会全体でLLMの議論・活用が散見されており、ますます今後重要な技術となるだろうと感じております。会の企画および開催をしました。この記事では、LT会を通してどのようなアイデアが出たか、LT会をすることで何が分かったかを記載したいと思います。LT会の目的このLT会の主な目的として、LLM技術を使って社会にどのようなインパクトを与えることができるかを模索することと設定しました。参加者は、LLMの活用アイデアを積極的に提案し、その実現可能性や制約を検討することで、LLM技術のポテンシャルをより具体的に把握することを目的としました。送らないこととしました。LT会の内容LTは計10件と多くエントリーされました。全てを紹介することは難しいので、LT会で発表された内容をピックアップして紹介します。QAチームの池田です。(※弊社で使用しているテスト自動化ツールはAutifyです。弊社のQAエンジニアは、各開発チームに「専任QA」として配属されています。私が専任QAとして所属している開発チームのプロダクト領域は「設定・登録」です。プロダクトの中でもコアな部分であり、不具合や障害が起きればその他の機能にも影響してしまうため、とても重要な機能です。「ID・パスワード配布/再発行」という機能があります。「設定・登録」内でも使用率の高い機能ですが、仮にこの機能が動かなくなってしまった場合ID・パスワードの配布等ができなくなり、状況によっては多くのユーザーがログインすらできなくなってしまいます。Classi設定・登録画面の一部しかし、私がチームにジョインした当時は定期的なリグレッションテストが行われておらず、開発/QA側ともに既存の不具合があると認知しつつもすべてを把握してない、という不安定な状況でした。重要な機能であるからには定期的にリグレッションテストを行い、この状況を改善する必要があると思いました。2既存不具合の検出(=現状把握)自動化をするにあたって「既存不具合の検出」をしたいという目的もありました。上記にも記載した通り、この領域は不安定な状況が続いていました。開発チームに所属しているQAの立場として、この状況は一刻も早く解消したい問題でした。そのため、テストを自動化する過程で既存不具合を検出し、現状把握をしていきたいと考えました。計画まずは自動化の計画を立てるところからスタートしました。具体的には下記内容を計画、準備しました。1範囲まず本番環境の自動化を進めることにしました。範囲については、「メインパスを網羅すること」を基本条件としました。(メインパスについては、公開されているプロダクトのガイド一覧に説明があるパスをメインパス、と定義しました。限られた時間やリソースの中でまず優先すべきは本番環境、そしてユーザーが一番通るメインパスであると判断しました。Classiガイド一覧の一部2テスターのアサイン自動化するにあたって、QAチームのテスターの力を借りました。テスターは開発チームには属さず、専任QAからの依頼ベースで動いています。専任QAが検証でテスターを必要とした際に、QAマネージャーに手空きかの状況を確認し、一定期間テスターをキープする、という流れです。テスターの最優先業務は検証であるため、今回私からテスターを一定期間アサインすることはせず、手の空いている際に自動化に対応していただくことになりました。そのため直近のテスターの空き状況を確認し、どのくらい動いてもらえそうかを想定しました。上記を踏まえた上で、大体の完了期限を設定しました。約50シナリオの作成が必要となり、1日1人ほどはテスターを確保できそうでした。1日1人で2シナリオ程度は作成可能であるため、期間を1ヶ月と設定しました。弊社のプロダクトは学校(主に高等学校)に導入されており、学校単位で機能しています。”検証学校1"、”検証学校2”のように、本番環境にいくつか検証用の学校を所持しています。環境についてはQAチームが所持している”学校”の中から、初期状態で1度も検証等に利用されていない"学校"を1つ借してもらいました。最低限必要と思われるアカウントの作成等も行いました。自動化作業は想定よりもスムーズに進んだため、本番環境に加え検証環境でも自動化を進めることができ、両環境合わせて約1ヶ月半で無事完了することができました!具体的にこの1ヶ月半での出来事を大きく4点に分けました。1テスターの進捗管理テスターの進捗を把握するため、作業してもらった日の終わりに進捗を報告してもらいました。難しかったのはテスターのアサイン状況の整理に関してでした。テスターは直前でQAから検証依頼が入ることもあるため、空き状況が読めないことも多かったです。テスターは以前からテスト自動化ツールに触れていたこともあり、私が想定していた以上にスピーディーに進めてくれました。私は今回テスト自動化が初めて、且つテスターの進捗管理も初めて、と初めてづくしだったため、QAマネージャーが「Weeklyで進捗相談のMTGをしようか」と提案してくれました。当初は同じチームのQAメンバーとQAマネージャーだけで行なっていましたが、途中からはテスターも招待してMTGを行いました。テスターとは基本Slackでやりとりしていましたが、Slackのやりとりではなかなか出てこないような些細な事、困っている事などを話せる場があれば良いのではないかと思ったからです。私自身もテスターの意見から何か良い方向に取り入れられることがあればいいな、という思いでした。想定していた通り自動化の過程で既存の不具合が検知され、計4件の不具合を起票しました。どれもクリティカルな不具合ではありませんでしたが、開発側がすぐに改修に着手してくれました。不具合改修に対応してくれた開発側には感謝しかありません...!不具合チケット管理画面4改善要望チケットの起票また、自動化の過程で改善要望チケットを2件起票しました。改善要望チケットを起票した意図としては、正式な改修依頼ではなく、違和感のある、もしくは明らかに使いづらいUI/UXを記録に残しておきたいと思ったからです。当時私が入社してからまだ数ヶ月だったこともあり、プロダクトへの使用感覚が新鮮だったのもあるかもしれませんが、少なくとも私の感覚ではおかしいな、と感じる挙動がいくつかありました。QAとしてプロダクトを過信せず、こういった違和感を忘れないようにしたいと思いました。振り返りこの1ヶ月半を振り返り、良かった点と反省点がありました。良かった点:進捗報告や相談を定期的にできたQAメンバー、テスターとの定期的なMTGで進捗報告や相談をすることができたお陰で、スムーズに進めることができたと思います。定期的に相談できていなかったらアドバイスを頂いても事後となってしまい、後回しになっていた可能性もあったと思います。しては、環境の準備が不足していたと感じています。開始前にログイン等に使用する必要最低限のアカウント等は準備していたのですが、作業過程で必要になる細かな設定等を把握できておらず、自動化しながら必要な設定やアカウントに気づき都度追加していく、という流れになってしまいました。Classiに登録されている「先生」を検索し、ページネーションの確認をするというシナリオがありました。1ページに表示される「先生」の数は20人のため、ページネーションを確認するには最低21人の「先生」の登録が必要でした。このようにシナリオで具体的にいくつのアカウントが必要になるか、という想定ができていなかったため、作業中のテスターに余計な作業を増やしてしまう結果となりました。テスターに指示を出す側の私が、もっと事前に準備に時間を費やすべきであったと反省しています。QAチームについての記事もありますので、ぜひご覧ください。tech.classi.jp自動化の作業はもちろん、テスターの進捗管理等初めて対応する業務が多く勉強になりました。自動化を進めていく過程で、想定していなかった改善要望チケットの起票など、プラスαでできたこともあり、プロダクトに対する気づきも多かったです。この度、シリーズ企画としてClassiで働く開発者のインタビューを始めます。記念すべき第一回目は、プロダクト開発部で部長を勤めているonigraさんです。簡単に自己紹介をお願いします黒猫のアイコンでお馴染みのonigraさんonigraです。社内ではyudaiと呼ばれています。Classiには2019年にソフトウェアエンジニアとして入社して、2022年から開発本部のプロダクト開発部という部署で部長をやっています。色々なことをやったのですが、開発者ブログに書いた内容だとEC2からECSに移行する仕事をやったりしました。tech.classi.jp経歴は、20代半ばまでフリーターをやっていたんですが、流れでソフトウェアエンジニアになりました。ソフトウェアエンジニアになってからは、EC、SIer、介護業界の会社に勤めていました。フリーターからの流れでソフトウェアエンジニアってとても珍しい経歴ですね?フリーターをしていた時、元上司に声をかけてもらってローンチ前のサービスのPMOになったことがソフトウェア開発に携わった始まりでした。当時お金もなくて引き受けるしかない感じでした(笑)そしてその後サービスをリリースしたはいいものの、リリースしたら不具合でトラブルが頻発しました。目の前のトラブルを解決しないといけないけどプログラマーが足りない、トラブルを解決するにはデータベースというものを修正しないといけないらしい、データベースを修正するにはSQLという言語を使う必要があるらしい、それならSQLの書き方を調べてみよう、という感じで勉強していったのがエンジニアキャリアの始まりです。自分でやるようになったんですか?お願いして待ってるだけという状況はフラストレーションがたまるので、自分ができるようになりたいと思ったんです。それを繰り返しているうちに、色々な社内の技術スタックに触れたり学んだりするようになりました。ソフトウェアエンジニアを続けることができた理由は?純粋にプログラミングが楽しかったからですね。自分が書いたものが考えた通りに動く、それによってサービスが回っていく、課題を解決していくことが面白かったです。問題は大小色々あるし形も変わっていくけれど、ソフトウェアエンジニアの面白さの原点はそこにあって、今でもこの仕事を続けれるのはそういう感覚が味わえるからですね。は?転職を考えていた時期にスカウトがあったことが最初のきっかけです。面談で話をしていく中で、事業内容が自分の今関心があることと一致していること、自分の得意領域が活かせそうなこと、技術に対するスタンスや考え方が食い違わないこと、ビジネスモデルがしっかりしていることなどが決め手となり入社を決めました。その他に気が合いそうなメンバーがいたことも大きいかもしれません。id:nkgt_chkonkさんのブログは元々見ていて知っていました。面談の中で特に印象に残っていることはなんですか?各面談の中で共通で投げかけていた「競合についてはどう考えているのか?」という問いに対して、「同じ課題に立ち向かってる会社だと思っている」と理啓さん(Classi社長)が熱弁してくれたことですね。それを聞いて真摯に社会課題に向き合っている会社だなと思い、共感して入社しようと思いました。Classiでの仕事内容を教えてください今は開発本部、プロダクト開発部で部長をしています。元々はソフトウェアエンジニアとしてClassi内に存在するさまざまなレガシーなコンポーネントを修正する仕事をしていました。ソフトウェアエンジニアとして具体的に何をやっていたんですか?デベロッパーサクセス(組織横断的な技術課題を解決するチーム)として入社したんですが、当時のClassiにはRuby、Railsのバージョンアップという大きなミッションがありました。いうことが課題の会社はバージョンアップ以外にも色々な課題(インフラや組織など)があることが多いので、目につく課題をひたすら解決しようという感じで仕事をしていて、気がついたら部長になってました。部長になってからはどんな仕事をしていますか?肩書がついて役割は変わりましたが、取り組むことは基本的に「課題解決とボトルネックの解消」であり、現場のプログラマとしてやっていたことと基本的に変わってないと思っています。対象が組織課題や経営課題になっただけで、やっていることは最適化問題なんですよね。これは、故・岩田聡氏のおっしゃっていたことに影響を受けています。追悼企画】岩田さんは最後の最後まで“問題解決”に取り組んだエンジニアだった。)部長になろうと思ったのも、「今の会社のボトルネックはマネジメントだ」と考えていた時に部長の打診を受けたからで、課題解決するには自分がマネージャーになるのが手っ取り早いと判断したからなんですよね。部長という役割にまったくこだわりはなくて、なりたくてなったわけではないんですよ。隙あらば部長をやめたい(笑)組織というのは、トップの人間が組織力の上限になってしまうと思っているので、自分よりも優秀な人に一刻も早く蹴落とされたいと思っています(笑)Classiでの仕事の面白さや、やりがいについて教えてください。学校に向けたサービスというのは、個人的に関心がある社会問題へのアプローチにつながることになり、とても可能性とやりがいがあると思っています。学校へ訪問する機会があるのも楽しいですね。最近は部長という役割を通して仕事のステージが変わってきたことを実感しています。管理職ならではの仕事の面白さがわかってきました。学校にアプローチすることはonigraさんにとってどういう意味を持つのでしょうか?僕は貧困問題や機会の均等に興味があるんですが、教育水準を上げることによってその問題は改善に向かうと考えています。Classiは教育の中でも塾とかアドオンのものではなく、多くの人が通うであろう「学校」にアプローチしている。それは学校に行く人なら基本的に触れるClassiがよくなれば、その子どもの将来の可能性が広げられるということだと思っています。それはすごく可能性があることだし面白いと思っています。いう時に学校に訪問するのですか?Classiはユーザーヒアリングで直接学校に行く機会があります。高校生と話す機会なんて社会人になったらなかなかないので、とても新鮮な気持ちになりますし純粋に楽しいです。管理職の仕事の面白さややりがいとは?取り組む課題の質が変わることによって仕事のステージが変わった実感がありますし、それは純粋に面白いですね。経験したことのない課題に取り組むには、コンフォートゾーンを出て新しい知識を学ぶ必要があります。それは新しく言語や技術を学ぶことと変わらないので、できることが増えていく実感もありますしやりがいも感じます。今後また現場に戻った時にも役に立つことも多いと感じています。プログラミングの方が楽しいのは今でも変わりません。隙あらば管理職をやめて現場に戻りたいと思っています(笑)Classiでの仕事の難しさや課題について教えてください。10年近く運営されてるサービスなので、やはりレガシーなものも多いです。いわゆる「分断されたモノリス」状態によるコンポーネント間を跨った機能の影響で、仕事がコンポーネント内で収まらないことも多く、職能やチームを超える振る舞いが求められることが多いです。レガシーなものがあるとどんな課題があるのでしょうか?レガシーなものの対応でいっぱいいっぱいになっていて、ビジネスを伸ばすことに注力しきれていないというのが正直なところだと思っています。レガシーへの対応は色々あるけれど小手先で何か直せるものは終わっていて、残っているのはアプリケーションに手を入れないといけないものが多く難しい課題が多いです。これらをさっさとやっつけて、サービスを成長させるための開発をもっとたくさんできるようにしていきたいですね。個人的にはこれまで所属していた会社でも同じような仕事をやっていたこともあり、技術的には面白い仕事だと思っています。職能やチームを超える振る舞いについて詳しく教えてくださいある程度規模のあるレガシーなサービスは大体複数のコンポーネントが協調して動いていることが多く、Classiも例に漏れずそういう状態です。自分が普段触るリポジトリの修正だけでは解決できない問題も多く、チームを越境する動きが必要になっていきます。その際、他のチームのことや他のコンポーネントの知識が必要になるためなかなか難しいところだと思っています。社内で活躍しているメンバーはチームを超えてコミュニケーションしたり、別のチームのリポジトリにプルリクを出したりすることに抵抗がないメンバーが多いと思います。働く上で大切にしていることは何ですか?最小限の努力で最大限の結果を出すことですね。そのために具体的に何をやっていますか?僕は自分のことを怠惰な人間だと思っています。してもプログラマという職種は作ることを求められますが、「作らずにその問題を解決する方法はないか?」を考えるようにしています。提案されたソリューションは本当にやる必要あるのか?その方法しかないのか?最善策なのか?など現状を疑うところから始めます。一発逆転できるような、簡単でコスパがいい方法はないのかを常に考えています。最後にひとことカジュアル面談に出ることが多いので、是非Classiに興味を持っていただけましたらお話ししましょう!Classiでは「子どもの無限の可能性を解き放ち、学びの形を進化させる」というミッションに、ともに向き合っていただける仲間を募集しています。Corp.引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。