Classi開発者ブログ

教育プラットフォーム「Classi」を開発・運営するClassi株式会社の開発者ブログです。

研修担当として、リモートネイティブから学んだワークスタイル

この記事は Classi developers Advent Calendar 2022 の 12 日目の記事です。

こんにちは。Classiの学習Ⅱコーチング領域にてエンジニアをしています、中島です。

私は、2021年10月、2022年4月入社の新卒メンバーの研修担当の一人でした。

Classiでは2019年から新卒採用を行っています。 まだ新卒採用を始めてから数年しか経っていませんが、研修内容は毎年ブラッシュアップしています。

どのような研修が行われているかは、以前新卒メンバーが書いてくれた記事をご覧ください。

tech.classi.jp tech.classi.jp

今回は研修担当側から見て、メンバーの行動でとても良かったなと思ったことについて共有します。

フルリモートでの研修を担当してみて困ったこと

Classiは2020年3月よりフルリモート体制となっているので、当然ながら研修もフルリモートで行われました。

新卒メンバーと研修担当はリアルに会ったことがないまま、オンライン上で初めましてとなりました。 通常であれば、入社時は顔を合わせて隣で教えることのほうが多いと思いますが、それができなかったことで困ることがありました。

例えば、新卒メンバーが何かに困っていることがあったとしても、研修担当がそれをキャッチできず、サポートが遅れてしまうことがありました。

先程も述べたようにオフィスで顔を合わせたりしておらず単純接触効果がなかったので、親しみがもちづらいというか、気軽に話しかける空気を醸成しづらかったのかなとも思います。 また、最初は新卒者→担当への質問の仕方がわからないこともあったのかもしれません。

入社前に技術レベルのヒアリングはしていたものの、各メンバーがどんなところで詰まるかは研修をやってみるまでわかりません。 本来であればメンバーごとに細かくケアをしたいところなのですが、カメラをオンにしていてもリモートだとなかなか状況を読み取ることも難しいこともあり、もどかしい思いをしていました。

見えないから、教えられない

社会人になって数年も経つと自分が入社したての頃に困ったことや、技術がわからなかったときの気持ちを忘れてしまうことはないでしょうか?

また、新卒メンバーは自分が入社したての頃よりも知識が多い場合もあります。 実は教えようとしていることは、もう既に知っているかも?と思い、教えることを躊躇う可能性もあります。

何も聞かれない場合、万事うまくいってると誤解してしまう可能性もあります。 オフィスにいて、悩んでいる顔を見ることができれば声をかけやすいですが、状況が見えないときに積極的に声をかけることは、リモート環境だとより難しいと感じました。

研修担当がハッとさせられた、研修を受けたメンバーの行動

そんな中、Classiの新卒メンバーは自ら以下のような行動を取ってくれました。

まず、個人の分報チャンネル(Classiではtimesチャンネルと呼んでます)をSlack上に作成し、今どんな研修をやっていてどこまで進んでいるか、どんなところで詰まっているかなどなど、状況を共有してくれました。 そして、相談したいことがある時は、シュッとhuddleに入って集まったりしていました。 その状況は研修担当者だけでなく、新卒メンバーのサポーターや他の先輩方にも伝わり、気付いた人が駆けつけてサポートしてくれる姿が見えました。

元々Classiは、オープンであることが賞賛される文化があります。 分報チャンネルの作成は任意ですが、リアルタイムでログを残すことで今その人に何が起きているのか他の人が気づくことができます。 割とチャンネルを巡回している人も多いので他の人の目に入ることが多く、リアクションが付くこともあります。 特に、困っていることを書いていると先輩方がわらわらとチャンネルにやってきてくれます。 人が集まりわいわいしていると、なんだか楽しそう!となりさらに人が集まり、色々な人が教えに行きやすいと感じました。

改めて気付かされた自己開示の意義

新卒メンバーの取ってくれた行動で、様々な良い影響に気付きました。 前述した通り、サポートする側は相手の状況が見えないと助けに行くことができません。 また、その人に教えるレベルがわからないと本当の意味でのサポートになるかもわかりません。

困っている側は、こんなこと聞いて良いのだろうか?もう少し調べれば答えがわかるのではないか?と迷って時間が過ぎてしまうこともあると思います。 その迷っている「状況」をオープンにすることで、その人に教えなければいけない事柄の「レベル」が相手に伝わります。

この「レベル」が伝わることがとても大事です。「レベル」の高低は関係ありません。 そんなこともわからないの?と思われる可能性を危惧してしまう気持ちもわかりますが、それよりもサポートしてくれる相手が「そこから教えなきゃいけないのね、了解!」とレベルを把握してくれることが重要だと感じました。

一言で言うと「聞くは一時の恥、聞かぬは一生の恥」で終わってしまう話なのですが、まずは相手に自分のレベルを知ってもらうことが初めの一歩だと思います。 隠しているつもりはなくても上手く行かない時に一人で悩んでしまうことは、リモートワークでは相手に全く伝わりません。その状況をいち早く周りに伝え、フィードバックをもらったほうが前に進む確率が上がりそうです。

これは自分の持っているタスクに関する共有だけでなく、例えば会議の内容をオープンな場所に残すなども良い影響があります。その会議に参加してない人にも内容が伝わり知見になりますし、あとから検索もできて便利です。

また、分報チャンネルなどでのわいわいしている様子はその人がどんな人かを知るきっかけにもなります。 非同期のチャットだけでなく、音声で話したほうが早いこともあるのでそんな時はシュッとhuddleに入ると良いですね。 Classiでは新卒研修中は各自にサポーターが割り当てられますので、サポーターと一緒にSlack上でわいわいしてもらっていました。 そういった状況下で、段々と新卒メンバーも会社の雰囲気をつかめた部分があったのではないでしょうか。

Classiは学校教育がドメインの会社であることも関係しているのか、教えることが好きな人が多いかもしれません。 頼られるとやっぱり嬉しいですよね。しかし、リモートワークで教える機会が減ってしまっていると感じました。

誰かに教えると、自分の学びも深まります。教える機会は学びのチャンスです。 知っていることであればそれを見つめ直す機会にできますし、知らない場合は調べる機会にできます。 新卒メンバーに質問をされて、慌てて調べることもあります。実は先輩方も知らなくて、みんなで学びが深まり、質問してくれてありがとう!となった機会も見られました。

そんな大切な機会を双方共に失わないためにも、自己開示が重要だと感じました。

リモートでのコミュニケーションの難しさ

フルリモートでの研修で困ったことにも書きましたが、リモートではリアルでのコミュニケーションほどのコンテクストを得ることができません。 様々な便利ツール(MeetやMiroなど)を使い倒したとしても、伝わりきらない部分は発生します。 ここ!と指をさすことができれば一瞬で解決するのにな、と思う場面も多々あります。

しかし、基本的には書き文字ベースのやり取りになります。そんな中、単純接触効果がない場合、どんな人だかわからないことが理解の妨げを促進する場合もあります。 例えば、書かれていないけどこういう文脈だろうと忖度して全然違う意味に解釈してしまったり、書かれてもいない悪意を見出してしまったり……そのように誤読されたりすれ違ったりするリスクを減らすためにも、できるだけわかりやすい表現を使う、また文脈を知らない人でもわかるように説明を補う等、文章を伝わりやすくする工夫が必要です。

また、上述のようにどんどんコミュニケーションを取って聞いていくことも大事です。コミュニケーションを取れば取るほど衝突が起こる可能性もありますが、上手い伝え方も段々と習得していくことができるようになります。実際にコミュニケーションをオープンに取っている人の方が伸びている印象があります。

私の好きな記事に、スタディサプリさんの以下の記事があります。

blog.studysapuri.jp

大声で作業することは、自分だけでなく周りにも確実に良い影響があることを、新卒研修を通じて痛感できました。 私自身も確実にできているとは言えませんが、これからも意識していこうと思っています。

アドベントカレンダー10日目では、だいちさんが Working Out Loud して仕事を進めてくれた様子を書いてくれました。 tech.classi.jp

過去Classiでは、リモートワークでのコミュニケーションを向上させるため、下記のような施策も行ってきました。合わせてご覧頂ければ幸いです。 tech.classi.jp tech.classi.jp

新卒採用やってます!

現在Classiでは、2024年度入社の新卒メンバーの採用活動を行っています。すでにたくさんの素敵な方々とカジュアル面談、面接をさせていただきました。 これからみなさんにお会いできる日が来ることを楽しみにしています!

hrmos.co

ここまで読んでいただきありがとうございました。

明日の記事は、小川さんです!

入社前後で感じたClassi QAチーム

こんにちは。今年8月にClassiに入社したQAチームの池田です。 Classiに入社し、早3ヶ月が経過しました。 今回は、入社前後で感じたClassi QAチームの良さや気づきをご紹介しようと思います!

入社前に感じた良さ、気づき

興味のあることにチャレンジできる?!

私は転職活動中、Wantedly経由でClassiを知り、カジュアル面談を経てClassi QAチームを知りました。 カジュアル面談では、Classi QAマネージャーが求めるメンバーについて、このように話していました。

  • 「基本的に興味のあること、得意分野を任せる」

  • 「失敗は許される。失敗から学んでほしい」

正直、本当かな?と思いました(笑)そんな都合良く自分の興味のあることにチャレンジさせてもらえるのかな?と半信半疑でした。たとえチャレンジできる環境でも、日々の業務に追われてなかなか手がつけられない可能性もあるのではないか、などと勝手に色々な想像もしていました。

しかし、私はテスト自動化や内部品質の改善などチャレンジしたいことははっきりしていたため、Classi QAチームは魅力的だなと思っていました。

私が入社前に得ていた会社情報は、こちらのClassiの会社紹介資料です。 speakerdeck.com

QAロードマップ

入社前からQAの仕事は好きでしたが、QA活動の目的や自分の目標を見つけるのに苦労していました。チームでのロードマップや目標がなかったため、ただ目の前の業務をこなす毎日で、何のためにQA活動をしているのかが不明瞭になってしまったからです。

そこで転職活動の一つの軸としていたのが、「ロードマップや目標に向かって活動しているチームかどうか」でした。

Classi QAチームの掲げるロードマップはもちろん、お話を聞いている中でClassi QAチームの活動が入念な計画に基づいた活動であることは明白でした。その点もとても興味深かったです。

Classi QAチームの取り組みの詳細は、こちらの記事をご覧ください。 tech.classi.jp

外部への情報発信

一方で、気になっていたこともあります。Classi QAチームの外部発信についてです。 Classiに入社する前から、Twitterでの繋がりやセミナー参加にて、他社のQA活動を知ることができました。この過程で様々な会社に出会いましたが、Classiの名前は一度も出てきませんでした。

私はその後Classiに入社を決めるくらい、とても魅力的な会社、QAチームなのに、カジュアル面談で直接お話しするまでその情報を知ることができなかったのは、正直「もったいないな」と思いました。

この魅力を外部発信できたら、QAチームだけでなく会社としても興味を持ってくださる方もいるのではないかと思いました。

入社後に感じた良さ、気づき

属人化しない、Classi QAチームのドキュメント化

入社してまず驚いたことは、QAチーム内でのドキュメントの量です。具体的には、QAチームの業務に関する運用方法、検証に関するナレッジなどです。

入社してからしばらく業務内容やプロダクト理解のための「インプット期間」をいただいたのですが、ほぼ既存のドキュメントを見ながらインプットしました。

不明点があるときは、まず既にドキュメントにまとめられていないか確認するようにしています。この作業をすることで、目を通していなかったドキュメントを知ることができたり、解消できた場合には、質問に時間を割いて双方の時間を無駄にすることなく済みます。

ドキュメント化をするには、作成から更新まで工数がかかり、メンテナンスも大変だと思います。しかし、ドキュメント化をしていることで、属人化しないClassi QAチームの体制ができているのだな、と感じました。

入社するまで知らなかったので、いい意味のギャップでした。

QAチームが案件対応で使用しているドキュメントの一部

興味のあることにチャレンジできる

入社3ヶ月目の現在、入社前から関心があったテスト自動化の運用を自分のプロダクト担当領域で任せていただきました。任せると言っても自分にとっては今回が初めての取り組みなので、定期的にミーティングをしていただき、相談やアドバイスをいただいています。

そして何より、業務に追われることなくチャレンジできる時間が十分にあり、とてもありがたいと感じています。この環境は、どの会社、QAチームでも作れる訳ではないと思います。人や情報、予算等のリソース状況、開発チームをはじめ他チームからの理解と協力など、様々な要因や基盤があってこそ成り立つ環境だと思います。

ずっとやりたかった事に携われたのがとても嬉しいですし、今後運用していくにあたって出てくる課題に取り組むのも楽しみです。 QAチーム、そして今後の自分にワクワクする日々です。

開発プロセス中のQA施策のひとつであるテスト自動化

QAロードマップ

Classi QAチームは、QAチームの立ち上げ時から長期(4ヶ年)ロードマップに基づき活動しており、今年がその最終年となります。

まずこの4ヶ年計画、計画された4年前から変更を加えず取り組まれてきたそうで、とてもびっくりしました。立ち上げから4年でここまでQAチームを体制化できているのは、長期ロードマップがあってこそなのではないかと感じています。

私が現在取り組んでいる活動も、元々自分のやりたいことではありましたが、チームの目標に基づいた活動でもあります。入社してからを振り返り、改めてチームで同じ目標を目指しながら仕事をするのは、自分の活動意義を明確に理解し、その目的に向かって取り組むという意味で大切だなと感じています。

現在の長期ロードマップは今年が最終年のため、来年から新しい長期(3〜4年)ロードマップに基づき活動していくことになります。今回はジョインした時期が一つ区切りのタイミングに近かったのですが、次は一からロードマップの活動ができると思うととても嬉しいですしワクワクします!

Classi QAチーム ロードマップ

外部への情報発信

Classiに入社して3ヶ月が経ちましたが、入社前に感じていたClassi QAチームの魅力は私の中で今も健在です。この魅力を自分から外部に発信していきたいと思うようになりました。 その第一ステップとして、本記事を執筆させていただいております。

先日はClassi QAマネージャーが、テスト自動化ツール「Autify」の主催するイベントに登壇しました。実際にマネージャーが登壇してお話しされている姿を見て、今後自分もブログなど文面だけの発信でなく、イベントに参加することにも興味を持ちました。

そして、来年Classi QAチームがJaSST’23 Tokyoで登壇させていただくことになりました! 毎年多くの方が参加されるJaSSTで登壇できるというのは、会社としてもClassi QAチームとしてもとても規模の大きい外部発信になると想定しています。

Autifyイベント登壇の様子

おわりに

Classi QAチームに入社以降、日々の活動に希望やモチベーションを持って業務できていることがとても嬉しいです。

本記事を読んでいただき、Classi QAチームに少しでも興味を持っていただければ幸いです。

今後の活動についても、改めて本ブログにてご紹介させていただこうと思います!

Classiの会議室かわいい!(ここは理科室がモチーフ)

新卒がAngularのアップデート対応から経験したこと

2022年4月にエンジニアとして新卒入社しました、@_da1kong です。今年の10月から11月にかけてAngular12から13へのメジャーアップデートの対応を行いました。この記事では、このプロジェクトを進めていく中で学んだことを共有します。

この記事は Classi developers Advent Calendar 2022 の 10 日目の記事です。

アップデート対応の背景

サービス開発では使用しているライブラリを継続的にアップデートすることが重要です。

Classiで使用されているフレームワークやライブラリは、社内でアップデートの進捗を共有しながら管理されています。AngularもClassiが提供しているプロダクトの多くで使用されているため、アップデート対象の一つとなっています。

Angularのメジャーリリースの周期は、6ヶ月ごとと決められています。そしてそのタイミングで、古いバージョンはEOL(End Of Life: サポート終了)となります。そのため、アップデートに追従するためには定期的なアップデートが必要となります。

 Angular 日本語ドキュメンテーション

今回は自分のチームが関わるリポジトリのEOL対応として、Angular13へのアップデートを行いました。

アップデートの2つの問題点

Angularにはアップデートの手引きが整備されています。例えば、以下のようなバージョンの更新するためのチェックリストが、アップデートのバージョンごとに用意されています。

Angular Update Guide

当初の自分は、「このガイドに従えばすぐに対応が済むので、時間はかからないだろう」と考えていました。ところが進めていくと、うまくいかないことが少しずつ明らかになりました。その要因は、主に技術的なことと開発プロセスに関わることの2つあることがわかりました。

1. 依存ライブラリのバージョンが追いついていない

Angularのアップデートのみの対応であれば、マイグレーションガイドがしっかり整備されているため簡単に行うことができます。しかし今回のアップデート対象のリポジトリは、Angularに依存している他のライブラリ(テスティングライブラリやUIライブラリ)も追従しなければCIが通らないため、対応が必要な箇所が予想以上に多くなっていました。

2. 対象のリポジトリに複数のチームが関わっているため、作業連携が必要になる

今回担当したリポジトリは、複数のチームがそれぞれディレクトリを分けて開発を行っていました。そのためライブラリに破壊的変更がありプロダクトコードに変更を加えるときや、PRのレビューにチーム間でのコミュニケーションが必要でした。これも時間がかかる要因でした。

2つの問題点をどのように対処して進めたのか

これらの問題に対処するために、以下の工夫をしました。

slackチャンネルをたて作業進捗を細かく報告した

この宣言とともにプロジェクトは始まりました

まず最初に関係者を集めてslackのチャンネルを作りました。このチャンネルでは、作業進捗を流したり確認事項を投稿し、リポジトリに関わるメンバーと情報共有をしました。これはプロジェクトに関わるメンバーとのやりとりが可視化され、さらにこのチャンネル自体が作業ログになるメリットがありました。

またこのチャンネルをたてたことは、わからなかったらすぐに質問しやすい環境を作ることにもつながりました。よく先輩には「15分悩んで分からないことがあったらすぐに聞いた方がいい」と言われています。社内にはAngularのプロがたくさんいるので、巻き込みながら進めるきっかけになりました。

質問をして打ち返しをもらう様子

ライブラリのアップデートの計画を立てた

依存ライブラリの対応が必要なことがわかってきた段階で、先輩たちと進め方の整理やスケジュールを計画しました。これにより作業の見通しを立てられ、その後のサービスの動作検証をスムーズに行うことにつながりました。

また作業を進めていく段階で必要性に気づいた追加対応もありました。そのようなときは、計画やスケジュールをその都度見直し、作成したチャンネルで共有することを徹底しました。

不要なライブラリやCIフローを削除した

このアップデートを進めていく中で、使用されていないライブラリやCIのフローがあることに気付きました。今後のアップデートやCIのリソースの削減のために、アップデート対応と一緒に実施しました。

今回の経験から学んだこと

Angularアップデート対応が無事にリリースされた後、プロジェクトの最後に振り返り会を行いました。

振り返り会で使用したボード

その中で印象に残ったものを紹介します。

ライブラリのアップデート自体にも技術的な学びがあった

これまで自分は「ライブラリのアップデートは結構地道な作業であり、学びが少ないもの」という印象を持っていました。しかし今回の経験で、その印象は180度変わりました。まず最初にアップデート対象のライブラリを調べることで、サービスでどのように使われているかを理解することにつながります。さらにChangelogとライブラリのソースコードを読むことで、実装や設計のパターンを学べます。ライブラリのアップデートも技術的に学べる宝の山だと知りました。

定期的なアップデートの大事さが身に染みた

アップデートの際のバージョンの幅が増えるほど、Changelogの確認内容やコードの差分が増え、アップデートのハードルが上がります。また、今回のようにフレームワークなどの大きめのライブラリを更新するときに、依存ライブラリの追従に時間がかかります。そのため、日頃のアップデートを怠らないことが大切だと感じました。

リアルタイムで作業を共有しながら仕事をすることのメリットを経験した

今回はSlackチャンネルをたててリアルタイムで作業を共有しながら進めました。このような進め方はWorking Out Loudといい、チームで成果を出す上では重要な行動だと先輩からフィードバックがありました。

 blog.studysapuri.jp

ここに書かれているように、自分の作業や思考のプロセスが共有されたことでコンテキストも伝わり、他のメンバーから作業が見えやすくなるメリットを感じました。

先輩からも「日頃の進捗を発信していたおかげでレビューしやすかった」とフィードバックがありました。

結び

このプロジェクトは、チーム外の方々とコミュニケーションをとりながら進める初めてのものでした。大変でしたが、その分学びも多く良い経験になりました。

この記事から何か身になることが1つでも受け取っていただければ嬉しいです。

Classi developers Advent Calendar 12/10 は QAチームの Kanako さんです!お楽しみに!

学校現場で、プロトタイプを使ったロジック検証をしてきました!

この記事はClassi developers Advent Calendar 2022の9日目の記事です。

こんにちは!2022年4月に新卒入社し、データAI部でデータサイエンティストをしている白瀧です。
今回は、生徒の成績に応じておすすめ問題を提示するロジックを、プロトタイプを用いて学校で検証した話を紹介します。
ロジックの検証からプロトタイプ作成、学校検証まで実行できた良い経験だったので、まとめてみます。

※この記事ではロジックや検証内容には触れず、準備段階や検証を実施する中での私の気づき・学びを書いていきます。

なお、ここで検証したロジックを組み込んだサービス「学習トレーニング」が2023年5月にリリースされる予定になっています。詳細については、以下のYouTube動画をぜひ見てみてください! www.youtube.com

学校検証に至るまで

Classiには生徒自身が学びをするための学習機能が存在します。その中で生徒の成績に応じておすすめ問題を提示するロジックの検証を担当することになりました。
当初の予定では、ロジックの検討と妥当性検証を実施する想定でした。

この頃データAI部では社内向けに、Pythonで簡単にWebアプリを開発できるフレームワークであるstreamlitを使って、動くものを見せることでイメージをつけてもらう動きがありました。データサイエンティストがすばやく開発して、すばやく意思決定を支援するためのものでした。
そこで「ロジックの検証のために学校にこのプロトタイプを持っていけば開発前に検証できる!」と考えて実行することになり、プロトタイプであるWebアプリの開発を進めました。

しかし、ここで2つの問題に気づきました。

  • 作成したWebアプリは社内アカウントの認証を通しており、社外のユーザーが利用することを想定していなかったこと
  • おすすめ問題の解答データを保存する際のセキュリティ観点の考慮漏れ

理想であれば、一定期間生徒に自由にアプリを使ってもらい、解答データも収集したいところでした。しかし今回の検証では、持参した社用PCで操作してもらい(操作時は社員が横にいる)、解答データは収集しないということにしました。
実際に自由に使ってもらうためには、ただ実装しただけでは検証に使ってもらうことはできず、セキュリティ周りを考慮しないといけないことを学ぶことができました。

見せるだけであったり、今回のように目の前で少し触ってもらう程度であれば上記のような考慮は少なく済みますが、実際に自由に使ってもらった方が効果を検証するうえでも、ユーザーのリアルな声を聞くうえでも効果的だと思うので、次回の検証時にはこの辺も考慮に入れて準備を進めなくてはいけないなと思いました。

インタビュー設計

学校検証を実施するうえでもう1つ準備したこととして、インタビュー設計があります。

インタビュー設計では、何を知りたいか、そのためにどのような質問をどのタイミングで聞くかを整理しました。タイミングと聞き方によっては生徒の回答を誘導してしまい、生徒自身が感じたことを聞けないことを懸念したからです。

そこで、インタビューを通して知りたいことを直接聞くのではなく、プロトタイプを見せる前に現在の状態を確認して、プロトタイプを見せた後にどのような差分を得られるのか、また既存のものに代替されるかどうかを深堀って聞くことにしました。

例えば、ユースケースを通学中などの少ない時間で実施する機能を持っていったとします。
そこで、電車で通学している生徒に対して、プロトタイプを見せる前のインタビューでは、通学中での行動を確認します。想定される回答としては、英単語の勉強、ゲーム、LINEを返すなどが考えられます。
プロトタイプを見せた後に通学中の行動に変化はありそうかを質問します。ここで「使う」と回答した生徒に対しては、今やっている行動と時間と照らし合わせて深掘りしていきます。
英単語を勉強している生徒は、代替できるのか?もしくは英単語をやる時間の一部をもらえるのか?や、ゲームをしている生徒はゲームの代わりにできるのか?などを聞いていきました。

これによって、生徒自身も自分の行動と照らし合わせたときにどのように使えそうかをイメージできて、活用をするためのリアルな意見が聞けるのではないかと考えました。

結果的にリアルな声をしっかり吸い上げられたかはわかりませんが、使おうと思える具体的なユースケースやもう少しこうなってほしいという改善要望なども聞くことができたので、期待以上の成果につながったのではないかなと思います。

学校検証を通しての学び

検証での学びを以下の2点に分けて書いていきます。

  • 当たり前なことを気づかせてくれる
  • プロトタイプを使った検証はスムーズな意思決定につながる

学校検証実施後の振り返りボード

当たり前なことを気づかせてくれる

私はさまざまな仮説を整理し、インタビューで想定される回答を洗い出したうえで学校検証に向かいましたが、言われてみれば当たり前な意見にも気づけていなかったり、ハッとさせられることがありました。学校検証は、こういう気づきをたくさん与えてもらえるとてもよい機会でした。
それと同時に、ユーザーの解像度をまだまだ上げていかないといけないなと思いました。

また実際に問題を解いてもらったため、企画自体の検証だけでなく、解いてもらった問題自体のレベル感について確認できたのもよかった点でした。問題自体の検証は日常的には難しい部分になるので、そのあたりの確認も事前にできたのは良い気づきでした。

プロトタイプを使った検証はスムーズな意思決定につながる

大規模な開発は後戻りが難しい場合があり、特にロジック部分は数多くの事前検証が求められます。
今回の学校現場での検証を通して、ロジック部分の違和感がユーザー視点でないことが確認でき、さらに想定していたこと以外の発見にも繋がりました。
その結果として、企画自体とロジックの確からしさを検証することができ、スムーズな意思決定の支援に繋がりました。

不確実性が高い開発において、プロトタイプを使った素早い検証が素早い意思決定・自信のある意思決定を大きく支援でき、思った以上にインパクトが大きいんだなと感じました。

さいごに

今回の学校検証を通して、こういう企画をやりたいと言ったときに協力してくださる学校がたくさんあり、学校との繋がりの強さは絶大で大きな武器だなと改めて感じました。
私自身、学校とのつながりが強く、現場の課題や悩みの解決につなげられることを一番の魅力に感じて入社した背景があるので、これを入社1年目に実行することできて大変うれしく思います。

今回のような学校検証を重ねて、ユーザーの声を反映したプロダクト作りを意識して実行していきたいと思います。

明日は私の同期であるid:kudoaさんの投稿です。お楽しみに。

s3fsを使ってEC2の特定のディレクトリをS3と同期させる

はじめに

この記事は Classi developers Advent Calendar 2022 の7日目の記事です。

こんにちは!SRE留学で基盤インフラチームに在籍している id:ut61z です。 SRE留学についてはこちらのliaob88さんの記事に詳しいので興味がある方は御覧ください。

今回はs3fsというツールをClassiサービスの一部のコンポーネントに試行錯誤しながら導入してみたので、こんな挙動になるんだという発見を交えつつ、どのように設定をしたかなど紹介していきたいと思います。

s3fsとは

s3fsとは、S3バケットをFUSE(Filesystem in Userspace)経由でサーバのファイルシステムにマウントするためのツールです。
https://github.com/s3fs-fuse/s3fs-fuse

s3fsでマウントすると、マウントしたディレクトリを ls コマンドなどで参照したときに指定したS3バケット配下のファイルが表示されます。

また、常にS3と同期されているので、ディレクトリ内のファイルをサーバ上で操作すればS3バケットが、S3バケットのファイルをAWS上で操作すれば、サーバ上のファイルが更新されるという便利ツールです。

実際に設定したときのコマンド

今回はAmazon EC2で起動したAmazon Linux 2インスタンスの特定のディレクトリにS3バケットのマウントを行いました。

まずはインストールします。

sudo amazon-linux-extras install epel
sudo yum install s3fs-fuse

s3fsコマンドを実行します。
実際に設定したときのコマンドがこちらです(パスは適当な値に読み替えてください)。

s3fs some-bucket:/bucket/path /linux/path \ 
-o uid=999,gid=999,iam_role=auto,endpoint=ap-northeast-1, \
allow_other,mp_umask=022

-o 以下がオプションになるので、コマンドの核となる部分は

s3fs some-bucket:/bucket/path /linux/path

のみです。

S3のバケット及び必要であればそのバケット以下のパスと、マウントしたいサーバのディレクトリのパスを指定すればよいシンプルなコマンドです。

しかし、最初はオプションをどう指定すればよいかわからず、試行錯誤して設定しました。
最終的に指定したオプションについて紹介していきます。

s3fsのオプション

s3fsはFUSEのオプションも利用可能で、FUSEのオプションとs3fs独自のオプションを組み合わせて設定していく必要があります。

s3fsの全オプションについてはこちらに記載されていました。
https://www.mankier.com/1/s3fs
FUSEのオプションについてはこちらのREADMEに記載されています。
https://github.com/fuse4x/fuse

最終的に私が指定したオプションは以下になります(上述したものと同じ)。

s3fs some-bucket:/bucket/path /linux/path \ 
-o uid=999,gid=999,iam_role=auto,endpoint=ap-northeast-1, \
allow_other,mp_umask=022

uid・gid (FUSEのオプション)

マウントするディレクトリ配下で作成されるファイルのユーザーとグループを指定するものです。
マウントされたディレクトリで作成されたファイルのユーザー、グループがここで指定したuid、gidのものとなります。
指定しない場合、ユーザー=所有者は root になってしまうので注意が必要です。
なお、uid、gidは id コマンドで確認ができます。
https://www.gnu.org/software/coreutils/manual/html_node/id-invocation.html

iam_role=auto (s3fsのオプション)

このオプションを指定すると、そのEC2インスタンスに付与されている IAM Role を使ってS3と通信することができます。
特定のIAM Roleを指定することも可能で、その場合は auto ではなくロール名を指定します。
なお、当然S3またはそのバケットについて操作できるIAM Roleが付与されていなければS3と通信・操作することはできません。

endpoint=ap-northeast-1 (s3fsのオプション)

AWS リージョンの指定になります。
指定しない場合、順にリージョンを指定して成功するまでS3との疎通を試みるので、指定しなくても動作はしますが、無駄に通信が発生するので指定しておいた方が無難です。
なおdefaultは us-east-1 です。

allow_other (FUSEのオプション)

root以外のユーザーがそのディレクトリについて操作できるようにする設定です。
uid、gidと似ていて最初はuid、gidを指定していれば不要なのでは?と思っていたのですが結論からいうと必要でした。
uid、gidはS3という別空間にあるファイル群を擬似的にサーバのディレクトリ配下のファイルであるように見せるにあたって、そのファイルのユーザー、グループが未指定な状態を解決するような働きをします。
一方で allow_other オプションを指定すると、マウントするにあたってroot以外のユーザーにも操作を許可することができます。
ゆえに、このオプションを指定してあげないとあらゆるユーザーがファイル操作ができなくなるので指定が必要です。

mp_umask=022 (s3fsのオプション)

上記の allow_other オプションではすべてのユーザーに対してすべての操作を許可します。
mp_umask を指定することで、不必要な権限(たとえば所有者以外のユーザーのファイル更新権限)を除外することが可能です。
なおここで指定する引数は剥奪する権限を指定することになるので、最終的に付与したい権限が 755(rwxr-xr-x) であれば 022 を指定する必要があります(777 - 022 = 755 となるため)。

あくまで今回のユースケースに必要だったオプション指定なので、参考程度に見ていただければ幸いです。

導入における注意点

設定時マウントにタイムラグが発生する場合がある

再現性があるわけではないのですが、コマンド実行時マウントにタイムラグがある場合がありました。
マウント後、EC2インスタンスにSSHで接続している状態から抜けて、もう一度SSHでEC2インスタンスに接続し直すとディレクトリとS3の同期が確認できる、ということがありました。

パフォーマンスは期待できない

https://github.com/s3fs-fuse/s3fs-fuse#limitation
GithubのREADMEにも書かれていますが、基本的にパフォーマンスは期待できません。
ls コマンドを打ったときに若干もたついて表示されるような体験は残念ながらあります。
FUSE自体にパフォーマンスの課題はあるので、致し方ない部分はありそうです。

すでにファイルがある状態でマウントするとどうなるか

試行錯誤するなかで興味深かったのは、ディレクトリにすでにファイルが存在する状態でs3fsを用いてS3バケットをマウントすると、もとあったファイルは参照できなくなりますが、アンマウントするともとあったファイルは再び参照・操作が可能になるという点でした。

ディレクトリ内の情報を直接的に上書いているのではなく、マウント指定したパスでのファイル操作をジャックするようなかたちで、S3と同期的に通信し、擬似的にディレクトリ上にファイルが存在するかのように見せているのだということが伺えます。

そもそもFUSEとはカーネルの機能で、ユーザー空間でファイルシステムをプログラム実装できるツールです。”ファイル操作をジャック”するのはFUSEが提供している機能で、それを拡張してS3とやりとりしているのがs3fsなのだということを、調べていくうちに徐々に理解できてきました。

ちなみにファイルが存在するディレクトリにマウントするには nonempty オプションを指定する必要があります。

おわりに

s3fsを使ったS3バケットのディレクトリへのマウントについて紹介しました。

運用上必要に迫られs3fsを導入してみましたが、FUSEという低レイヤーなファイルシステムに対して高レイヤーなユーザー空間でのプログラミングで挙動をジャックする技術におもしろさを感じられてよい経験になりました。

明日は lowput さんです!お楽しみに!

Classiセキュリティ強化への道・後編~Hardening本戦へいざ出陣編~

はじめに

こんにちは、開発本部エンジニアの id:kiryuanzu です。
Classi Advent Calender 2022 の6日目の記事を担当させていただきます!

本記事は先月に同僚の @nomizooone さんが執筆した「Classi セキュリティ強化への道・前編〜Micro Hardening で修行編」の後編パートです。

11月15日、Classiのメンバー3名が沖縄県名護市の万国津梁館で開催されたハードニング競技会(通称: Hardening本戦)に現地参加しました。
社内研修として実施された Micro Hardening で修行を重ねたメンバー達による現地レポートを交えつつ Hardening本戦の経験を通して学んだ内容を中心に紹介していきます。

Hardening本戦とは

前編で説明したハードニング協議会の集大成となる大会で、最近では年1回行われています。
具体的には、脆弱性のある EC サイトなどのビジネス環境を模したシステム群がチームごとに与えられ、競技時間内の売上と脆弱性対応などの堅牢化の技術を競います。
たとえば、サイバー攻撃によってシステム停止が引き起こされればその間の受注が行えないため売上が減ります。また、堅牢化に集中するあまりに商品の在庫切れが起これば、ビジネスの機会損失が起こります。このように、様々なトラブルに対応する中で、いかにビジネスを加速し、売上を理想値に近付けるかを競う競技です。

wasforum.jp

Hardening本戦参加レポート(id:kiryuanzu編)

Hardening本戦は、準備期間が1ヶ月ほど設けられています。応募者の中から Hardening Project のメンバーによって8,9人程度のチームが組まれ、そこから競技当日に向けてチームとして準備を進めていくことになります。
過去にHardening本戦に参加した際はClassiメンバー3人が同じチームを組みましたが、今回は全員が別々のチームでの参加となったことでお互いのチームの様子について聞き合うようになり、自チームの動き方との違いを知る機会が増えたのが新鮮でした。そして見知ったメンバーが誰もいないため前回までとは一風違ったチームビルディングを意識する必要があったのも印象的でした。
筆者のチームでは主に以下のような準備を行いつつ当日を迎えました。

  • チーム名の決定・ロゴの作成
  • 週2の定例MTGの実施
  • スキルチェックシートを元に役割分担決め
  • 当日にやることのタスク洗い出し

また、社内の MicroHardening の研修を受ける中でチームビルディングの重要性をあらためて知ったことでチームメンバーの人たちが話しやすいようにできるだけ相槌を打ったりチャットで反応をしたり、esa で自己紹介ページを作るなどコミュニケーションしやすい場を形成できるよう心がけるようにしました。チームメンバーの方々も進んで自己開示してくれる方が多かったおかげで、和気藹々とした雰囲気が段々とできあがっていったように思います。
チームメンバーの学生の方がチームロゴを率先してデザインし、さらに SUZURI でロゴTシャツを作ってくれたのもチームの結束力を高める動きで大変素敵だったのも強く印象に残っています。
準備期間の間は定例に参加するためにプライベートの予定を調整する必要があり忙しい面もありましたが、普段の業務とはまた違った交流を楽しむことができた1ヶ月間でした。

同じチームになったオイシックス・ラ・大地の方々もブログでレポートを出しているのでぜひ読んでみてください!

creators.oisix.co.jp

いざ、沖縄!

火曜に Hardening本戦当日というスケジュールだったため、日曜に現地へ到着、月曜の日中は滞在先でリモートで業務をし、退勤後に各自当日に向けて準備を進める動きを取ることにしました。

那覇行きの飛行機に乗る前の Classi メンバーたち。まだ表情に元気が見られたころ

飛行機には無事搭乗でき、那覇まではスムーズにたどり着くことができたのですが名護行きのバス停を間違えてしまったこと、高速バスではなく一般路線バスに乗ってしまったことが重なり滞在先に着くまで 4時間以上かかってしまいました。到着してすぐにありついたジューシーとソーキそばの味はしばらく忘れられそうにないです。

ジューシーとソーキそば。ジューシーは沖縄では「雑炊・炊き込みご飯」という意味

移動は大変でしたが、同僚達と沖縄ならではのご飯やお酒を楽しんだり、競技前日の夜は準備作業にいそしみながら好きな音楽をかけてわいわい語り合うなど、修学旅行のようで大変楽しい思い出になりました。自分以外のメンバーも同じ感想を抱いていたようで、一緒に現地で滞在できて良かったと思いました。

若者たちと民泊サービスを利用して1軒屋借りて泊まってたんですが、友達の家で合宿してる感じが楽しかった。前日の準備中、深夜テンションでおかしくなる感じとかも良かった。もうこんな経験は人生で二度とできないかもしれない。

(一緒に参加したメンバー(@nomizooone)のブログから引用)

当日の経験を通して学んだこと

当日の競技では遊撃的に技術タスクを触っていく立ち回りを予定していましたが、直前に CISO(最高セキュリティ技術責任者)の役職を担当することになりました。この役職は主にチーム外とも情報連携をして課題解決する役回りが求められていました。よって、他チームと連合委員会を組んで情報共有したり運営から出された課題に応じて資料を作成するなど、技術以外のタスクにも関わることになりました。

それ以外にも、経験者として初参加の方々の動きをサポートし続けたりサービスの不具合を見つけたら技術班にエスカレーションして一緒に原因を究明するなど、他メンバーとコミュニケーションを密にとりながら問題解決へと取り組む動きが必要な場面が多くありました。

結果的に常に複数のタスクを掛け持ちし続ける状況となっており、今抱えているタスクの中で優先度の高いものを選んで手を動かす必要がありました。しかし、限られた時間の中で焦りが芽生えてくると、優先順位よりも目の前にあるタスクをとにかくちゃんと終わらせることに目がいきがちになり、うまく動けていなかった場面が多々あり反省しました。

競技中シーンその1 Hardening Project より提供

この経験から、どんな状況下でも「優先順位を常に意識して動く」といった振る舞いを維持することの重要性を知りました。普段の業務でもこのように優先順位を意識して行動できるようにしたいと改めて考えさせられました。
また、競技終了後にチームメンバーから自分が準備期間から意識していた誰かの発言にすぐ反応することや相槌を打つ振る舞いを褒めていただけて大変嬉しかったです。この振る舞いで安心する人がいるなら今後もできる限り続けていこうと思えました。

競技中シーンその2 Hardening Project より提供

Micro Hardening では普段から見知ったメンバーでチームを組んで競技に参加したことで課題の認識合わせが比較的スムーズでしたが、Hardening本戦では初対面かつ学生、公務員、会社経営をしている方などバックグラウンドが異なった人たちとチームを組むことになるので課題を捉える前にお互いのことを知っていくところから始める必要がありました。
競技を通してチームメンバーそれぞれの大事にしている価値観やキャリアの考え方、これから挑戦したいことを知れたことで、普段の業務ではあまり関わることもなかっただろう人たちの価値観に触れたのも貴重な経験でした。

いったんここで id:kiryuanzu のパートは終わって当日一緒に参加した Classi メンバーの @_da1kong さんにバトンタッチします。

Hardening本戦 で学んだこと(@_da1kong編)

2022年4月に新卒エンジニアとして入社しました @_da1kongです。普段はサービス開発をメインに行っており、セキュリティに関しては初心者でしたが、Hardening本戦に現地参加しました。沖縄に行ったのは小学生のとき以来です。

このような自分がHardening本戦に参加するにあたって、参加しているときに意識していたことや参加して良かったこと、今後どのように活かしていきたいかを書きます。

参加しているときに意識していたこと

私が一番意識していたことは、チーム内で溢れているタスクや対応できていないものを進んで見つけて探して行うことでした。普段はアプリケーション開発をメインにやっていることもあり、サーバー知識やセキュリティの経験値が少なく、技術面では力不足な部分がありました。そのため準備期間では、チームに貢献しきれていない感覚がありました。

しかし時間を重ねていく中でチームを俯瞰しながら自分にできることを探していると、共有情報が手薄になっている部分など自分にも貢献できそうな部分が多くありました。そこで、チームで話したことや決まったことを共有するための議事録を作ったり、他のメンバーへの連携や連絡を率先して行っていました。競技が終わった後の懇親会でメンバーから、このような気を利かせた動きが良かったとフィードバックをもらったのが嬉しかったです。

また当日は、全員が手持ちの作業に集中していると、新しく障害を見つけても対応する余裕がなくなってしまう状況がありました。その際はできるだけ困っているメンバーの声を早く拾うことを意識しました。自分の力だけでは解決できないこともありましたが、メンバーを巻き込んだり情報を残すことでチームに貢献できました。

競技中シーンその3 Hardening Project より提供

参加して良かったこと

オンサイトで参加することだけでも非常に楽しかったです。RubyKaigiにも参加して思いましたが、現地の空気感は現地でしか味わえないものでした。

tech.classi.jp

現地参加ならではの、沖縄の美味しい料理やお酒も飲むことができました。

美味しいリブロースステーキを頂きました

会社の先輩と同じ宿で修学旅行っぽくわいわいできたのも楽しかったですし、現地でチームメンバーと交流できたのも良かったです。前日に初めてチームメンバーと対面で顔を合わせたのですが、その時に話したり一緒にご飯に行ったりすることで温度感がそろった気がしています。同じチームになったメンバーは情シスやセキュリティ系の人やビジネス系の人がいて、普段接する機会のない方々でした。また若い方が多く、みんなモチベーションと体力のある人ばかりで刺激を受けました。そういう方々と一緒に勉強したり、手を動かして学ぶことができたのはすごく貴重な経験になりました。

砂浜に書かれているのはチーム名です

先輩達とは別のチームでしたが、逆に懇親会ではお互いのチームメンバーを紹介したりして輪が広がりました。

今後活かしていきたいこと

準備や競技の動きで重要だと感じたことは、チームで溢れているタスクを主体性を持って拾うことです。チームで仕事をしていると、どうしても細かいタスクがこぼれ落ちやすい状況にあると思います。そんな時に今回の経験で学んだ状況を俯瞰して情報を拾って行動することが大切だと感じています。与えられた役割をこなすだけでなく、自分で見つけ率先して行動することでチームに貢献したいです。

また普段のサービス開発においてもセキュリティ対策は非常に重要だと再認識しました。競技の最中、実際に攻撃を受けることで、アップデートを怠らないことや権限を絞るなどの基本的なセキュリティ対策が非常に重要だと身をもって感じることができました。このような対策は一時的にやるものではなく、サービスを運用するうえで継続的に行うことが大切です。貴重な経験をした自分が、熱量が高いうちに周りを巻き込んでチーム内でもそういう文化を作っていけるようにしたいと思っています。

最後に

ここまでいろいろ書いてきましたが、準備期間や現地での活動も含めると結構大変なイベントでした。それでも今回参加できたことは、今後のエンジニア人生にとても良い影響を与えてくれると確信しています。

個人的にはこういった経験を自分だけに閉じずに、他の方と共有することがとても大事だと思っています。まずは自分の経験をバネに自分だけでなく、所属しているチームから、行動や文化を変えていけるように頑張ります。

貴重な機会を作っていただき、競技前後も助けていただいた@nomizoooneid:kiryuanzuに感謝しています。ありがとうございました。

まとめ

以上が@_da1kongさんのパートとなります。@_da1kongさんは初参加でさらにチーム内にも知り合いがあまりいない中で慣れないことも多かったと思うのですが、最後までついてきてくれて本当にありがたかったです。

今回のClassi のメンバーが所属していたチームでは前回の順位を越えることはできませんでしたが、この競技を通して学んだことを業務でも活かしてやっていけるように前向きに捉えてます。

Hardening本戦で身についた振る舞いを普段の業務でも意識することで Classi のセキュリティ強化へとつながっていけたらと思います。 Classi アドベントカレンダー 7日目の担当は id:ut61z さんの「s3fsを使ってEC2の特定のディレクトリをs3と同期させる」です。よろしくお願いします!

「技育祭2022秋」で登壇しました!〜年1登壇のススメ〜

この記事はClassi developers Advent Calendar 2022の5日目の記事です。

こんにちは!9月入社でプロダクト開発部でエンジニアをしています @kaori_choです! 今回、技育祭2022秋という学生向けテックカンファレンスで、パネリストとして登壇してきたのでその舞台裏についてお話します。 私としては人生初レベルの大きな舞台で、緊張もしたのですが大変貴重な経験となったので、これから「登壇」にチャレンジする方の参考になれば幸いです。

「技育祭2022秋」とセッション概要

技育祭は「技術者を育てる」ことを目的とした国内最大級の学生向けテックカンファレンスです。教育や育成といった事業に関わるエンジニアとしても、毎年陰ながら応援しておりました。年々参加者は増え、今年の参加者数はなんと3000人規模! そのうち3日目の2022/10/17のセッションにて、パネルディスカッション形式で、女性エンジニアならではの強みや課題、キャリア戦略についてお話しさせていただき、200名ほどの学生さんにご視聴いただきました。

talent.supporterz.jp

登壇のきっかけ

登壇のきっかけは、主催者の楓さんとの前職からのご縁でした。私は女性エンジニアとして2011年から育休産休を経て今まで働いてきた経験があるため、今回の「女性エンジニアのキャリア」をテーマにしたパネルディスカッションを実施するにあたり、ママエンジニア代表(!)としてお声がけいただきました。

ただ技育祭は前述の通り「国内最大級」のテックカンファレンスで、今回も過去最高に豪華なゲストの方が登壇されるのを知っていたため、登壇が決まった際には社内のtimesチャンネルでテンパり散らかしました。

ひどく混乱した様子

事前準備:社内で素振りをお願いする

「これは一人では無理だ事故る」と判断した私は、社内で素振りをお願いすることに。 すると、すぐに5名以上の女性エンジニア・人事の方が挙手スタンプを押してリアクションをしてくれました(嬉泣)

みんなやさしいし嬉しすぎる😭しかもレスが早い

いざ、当日!

この日は日曜日だったため、子ども達を両親に預け、家からオンライン登壇の準備をしていざ挑みました。オンライン登壇だったので、時間の間違いだけが怖くて、1時間くらい前から家の中でソワソワと歩き回っていました。

セッション開始後は、テーマに沿ってパネリストの方とざっくばらんにお話しをしながら、 チャット等でもリアルタイムでリアクションがもらえて、とても嬉しかったです!

また、今回の登壇で「会社のお知らせに掲載される」の実績も解除しました🎉

今回パネリストとして登壇した感想

社名を背負って登壇するからには、学生さんからの認知もしっかりもらって帰るぞ〜!という魂胆も実はあったのですが(笑)、終わってみれば何より「私が一番楽しかったな〜!」というのが一番の感想です。 今回のウェビナー形式だと、参加者の方の表情は見ることができないのですが、チャットのリアクションで「女子学生エンジニア」の方がたくさん参加していることを感じられたのも、とても嬉しかったです。

そして、副次的に嬉しかったのは、今回の登壇がきっかけで"チーム外"のエンジニアの方々とより親しくなれたことです!

そういえば、コロナ禍になってからは、他チームの女性(エンジニア)とばったりトイレであって、「最近どう〜」みたいなお話をする機会がなくなってしまいました。 素振りのオンライン会議で、意図せず「チーム外の人とのコラボ」する機会を作れたのはとても良い体験でした。

私が「年に1度は登壇」にチャレンジしている理由

本記事はアドベントカレンダーのエントリーなので、少し年末っぽいお話もさせてください。 12月ですのでみなさん今年を振り返ったり、来年の目標を立てたりしているでしょうか?

実は、私が登壇をおこなっている理由は2つあります。

  • 女性エンジニアの存在をアピールしたいから
  • 登壇者が一番勉強になる(得るものが多い)と知っているから

1つめの理由は今回の登壇テーマそのままでもありますが、女性エンジニアはまだまだ少ないので、もっと増えてほしいという思いから機会があれば手を挙げ飛び込むようにしています。私自身も女性が少ない中で、先輩の女性エンジニアの存在に励まされてきたので、IT業界のジェンダーギャップ解消に向けて少しでも力になれればと考えています。いずれは、私が表に出なくてもよいようになってほしいのですが(笑)まずは女性比率が3割越えるまでは、挑戦を続けてみようと考えています。

2つ目の理由は、実は登壇者の話を聞いている人ではなく「喋ってる人が一番勉強になっている」のですよね。これは登壇や発表をしたことがある方々は、きっと画面の前でうなずいてくださっているはず。学んだことを人に喋ることは、自分の中での理解も深めます。資料を準備しながら、実はよくわかっていない部分が見えてくることも多いです。すでにわかっていることでも、質問をもらうことで違う見方に気づけます。

今回の私の登壇は、パネルディスカッションなのでただ楽しかっただけですが…(苦笑)そういう「楽しかった、面白かった、うまく話せず悔しかった」という感情すらも、登壇をしなければ得られなかったものです。

年1登壇おすすめですよ!

10年ほど前の私が新卒当時は「年に1つ言語を学びましょう」とか言われたものですが、今もそうなんでしょうか?

年1言語習得も素敵ですが、私からは「年1登壇」をおすすめします!

まずは小さく試してみましょう。

  • 社内のエンジニアを数人集めたライトニングトークで喋ってみる
  • 社外のイベントで登壇者に「質問」してみる
  • 社外のイベントに「登壇者」で申し込みをしてみる

こんな感じで私自身も、小さく小さく積み重ねて挑戦してきました。コツは「まずはポチる」こと。ネタは申し込んでから考えましょう!大丈夫です! このアドベントカレンダーもそうですが、アウトプットすることを先に決めることで、インプットの質も量も変わってきます。 そして、この記事を最後まで読んでくださる勤勉な皆さんなら「意外とやったらできた」という経験にきっとなるはずです。 次はみなさんのお話しが聞きたいです。もし、この記事をきっかけに、今度登壇することにしました〜!という方がいらっしゃったら、ぜひ @kaori_cho にも教えてください!

最後までお読みいただきありがとうございます。

明日アドベントカレンダーは id:kiryuanzu さんの「Classiセキュリティ強化への道・後編~Hardening本戦へいざ出陣編~」です!楽しみですね♪

© 2020 Classi Corp.