はじめに こんにちは、データ・AIシステム本部 検索基盤部 検索基盤ブロックの吉永です。 ZOZOは2026年5月30日（土）に東京・新宿のベルサール新宿グランドで開催された「 JJUG CCC 2026 Spring 」にブーススポンサーとして協賛しました。JJUGは、日本におけるJava技術の向上・発展と一層の普及・活性化を目指して設立された、ボランティアメンバーで運営される日本のJavaユーザーコミュニティです。CCCは、JJUGが主催する「Javaに閉じず」「技術に閉じず」オープンソースを中心とする様々なコミュニティから参加者を募って、コミュニティを横断した「クロスコミュニティなカンファレンス」です。 ZOZOTOWNでは、検索、カート決済、ショップ直送、基幹システムなど、多くの領域でJavaを使用しています。私たちが日々使っている技術を支えてくれているコミュニティへ貢献したいという思いから、昨年秋に引き続き今回も協賛しました。 本記事では、ZOZOのエンジニアが気になったセッションの紹介と、ZOZOブースの様子をお伝えします。 目次 はじめに 目次 Javaエンジニアが気になったセッションの紹介 普通のFeature Flag実践入門 AI時代のソフトウェア設計の学び方 不変条件と整合性境界ービジネスが決める設計判断と実現パターン アンカンファレンス（2）「テーマ：AI×レビュー」 Javaコミュニティの関心の変遷を可視化する：JJUG CCC発表データから見る変化と不変 ZOZOブース 「ソウゾウのナナメウエ × Java」 集まった体験談 バージョン・言語仕様 関連 AI 関連 ”沼”系の苦労話 まとめ Javaエンジニアが気になったセッションの紹介 ZOZOのJavaエンジニアが気になったセッションをいくつか紹介します。 普通のFeature Flag実践入門 ZOZOMO部OMOブロックの木目沢です。irofさん（ @irof ）の『普通のFeature Flag実践入門』を紹介します。 speakerdeck.com Feature Flagについて体系的にまとまった情報があまりなく、非常に役に立つセッションでした。自チームの現状を振り返ると、Feature Flagの利用は散発的でした。導入後の撤去漏れや、AWS AppConfigにおける「インフラ側の管理とコード側の管理を同時に意識しなければならない」という運用コストが課題となっていました。ここ最近は後方互換を保てるリリースだったり、先行リリースしても問題ない状況だったのでFeature Flagをそれほど使わずに済んでいましたが、常にそうした条件が揃うとは限りません。そういう意味でも、今後は積極的に活用していきたいと考えていたので、体系的に説明いただいた今回のセッションは大変貴重でした。 「デプロイとリリースを分離することで、誰が嬉しいのか」という問いが良かったです。その恩恵を受けるのはエンジニアではなくビジネスサイドであるという視点は、改めて重要な示唆を与えてくれるものでした。生成AIの活用によって開発速度が向上しても、リリースプロセスが重ければ効果はあまりありません。自チームはスクラムを採用していますが、スクラムにおいてもスプリントを通じてリリース可能なインクリメントを作り上げることが前提であり、そのリリース自体が重いというのはいい傾向ではありません。 実装面では、Feature Flagの設計におけるON/OFFの制御方針、if/elseの構造、else節の要否といった意思決定が大事であること、撤去が極めて重要であることも改めて確認しました。ログ・監視・マイグレーションとの整合性など、運用上の注意点も網羅されており、実践に直結するセッションでした。 AI時代のソフトウェア設計の学び方 引き続き木目沢が、増田さん（ @masuda220 ）の『AI時代のソフトウェア設計の学び方』を紹介します。 speakerdeck.com 正解のあるなしではなく、増田さんの考えという前提ではありましたが、自分の仕事の範囲における解釈でもやはり「小さな設計の反復×人の活動支援」が今のところ合っていると感じています。コンテキストの制限やLost in the Middleの現象も避けられない現状を見ると、小さな設計の反復をやっていくほうが良いというのが現時点での自分の理解です。 同様に、「ソフトウェア開発」は「事業開発」と「組織開発」と強く結びついているということもすんなり入ってきました。むしろ生成AIで実装は速くできるようになったので、開発者も事業開発や組織開発といった領域に足を踏み入れる余裕が持てるようになったのではないでしょうか？OMOブロックでも去年からビジネス部門と開発部門が一緒になって仕事をすることを始めています。ビジネス部門と一緒にソフトウェア開発をするのはとても良い体験です。 ソフトウェア開発の根底原則は「事業目的の適合性」と「変更容易性」です。特に「ソフトウェア設計のあらゆる原則とパターンは、この変更容易性の原則の特殊化」という言葉には納得しかありません。 気になるのは、生成AIでこのあたりが変わっていくのか、つまり生成AIが読めればなんでもいいのではないでしょうかという論調も囁かれたりします。少なくとも生成AIは「人の活動支援」というスタンスでいるうちは「変更容易性」の原則は変わらないでしょう。私のケースですが、生成AIが変更容易性の高いコードを書くように色々な設計原則をSkillで伝えているのもそういうことかと思います。 「事業目的の適合性」「変更容易性」を学ぶための初級編として「区分」に注目するのは面白いと思いました。思い返せば、売上に直結するような変更をするのに大体「◯◯区分」に手が入っていました。新しいプラン、プランの内容の変更、ルールの追加や変更などですね。 最後に印象的だったのが、内容はあくまで増田さん自身の考えであると繰り返しおっしゃっていたことです。他にも多くの考え方があると承知した上での内容でした（そのとおりの言葉ではないですが、ニュアンスは合っているかと思います）。そもそも生成AIの時代はかつてなく不確実性が高く、1つの答えが存在するはずもありません。そういう意味でも、今の時代は「人と人との相互作用」がより大事なフェーズではないでしょうか。生成AIがこんなに発展しているのに人が大事とはまた面白い時代ですよね。 不変条件と整合性境界ービジネスが決める設計判断と実現パターン 商品基盤部1ブロックの井草です。nrsさん（ @nrslib ）の『不変条件と整合性境界ービジネスが決める設計判断と実現パターン』を紹介します。 speakerdeck.com スピーカーのnrsさんも仰っていましたが、朝一から頭をフル回転させるセッションでした。今回のテーマは「不変条件（Invariant）」と「整合性境界（Consistency Boundary）」です。私自身、オブジェクト指向設計に慣れていることもあり、設計を考えるときは「どのオブジェクトをまとめるか」「どこで集約を切るか」から考え始めることが少なくありません。しかし、このセッションで特に印象的だった考え方があります。 「不変条件が先、集約が後」 です。まず考えるべきなのは、システムが守るべきビジネス上のルールです。そして、そのルールが「一瞬たりとも破ってはいけない真の不変条件」なのか、「最終的に整合していればよい遅延可能な不変条件」なのかを見極めることが重要だと説明されていました。 例えば、二重引き落としや二重予約のように、一度破られると後から補償できないルールは即時整合性が必要です。一方で、後から整合性を回復できるものは、プロセスによる結果整合性という選択肢もあります。 なぜこの見極めが重要なのか。それは、すべてを即時整合性で守ろうとすると、トランザクションや集約が肥大化し、システムの変更や分割が難しくなるからです。マイクロサービス化や分散システムを多く扱う今においては、次の問いを持つことが大切です。 「そのルールは本当に遅延を許容できないのか？」 設計者として、この問いを意識することの重要性を感じました。集約から考えがちな自分にとっても、「まず守るべきルールを見つける」という視点は非常に学びの大きいセッションでした。 アンカンファレンス（2）「テーマ：AI×レビュー」 ECプラットフォーム部マイクロサービス戦略ブロックの半澤です。アンカンファレンスの第二部に参加しました。テーマは「AIが生成したコードを全部見るのか」「レビューする手間は増えていないか」で、Javaチャンピオンの谷本さんの進行のもと、ディスカッションが行われました。生成AIを活用した開発が身近になりつつある今、多くのエンジニアにとって関心の高いテーマではないでしょうか。 今回のアンカンファレンスでは、さまざまな観点から意見が交わされました。AIが生成したコードの確認はもちろん、レビューの認知負荷やコードレビューと品質保証の関係、テストや設計で何を担保するのかといった幅広い話題に及びました。 話題の中で興味深かったのは、AIによってコードを書く時間とレビューする時間のバランスが変わってきているという観点です。AIがコード生成を担う場面が増えると、コードを書く時間は短くなります。一方で生成されたコードを確認する作業が連続しやすくなり、レビューの負荷が大きく感じられるのではないか、という話がありました。その負荷を下げる工夫として、コードだけを見るのではなく確認しやすい形を整える方法が挙がりました。AIや自動化を活用して変更内容の可視化・スクリーンショット・テストコード・補助的なドキュメントを用意するのがその例です。 また、コードレビューだけで品質を保証できるのか、という話題も印象に残りました。レビューでソースコードをすべて確認することだけが品質保証ではなく、テストや設計段階での確認など、複数の仕組みを組み合わせて品質を支える必要があります。一方で、レビューによって見つけられる問題があることも確かです。 レビューで何を見るかも、考え方はさまざまです。細かな実装の書き方すべてを見るというより、リスクが高そうな箇所や、自分が実装するとしても迷いそうな箇所を重点的に見るという考え方があります。たとえば次のような観点は、人間が注意して見る価値があります。データの処理方式、アーキテクチャによって影響が大きく変わる部分、テストでは見つけにくい同時処理や状態管理の問題、後から変更しやすい構造になっているかなどです。AIが生成したコードであっても、人間が書いたコードであっても、こうした観点自体は大きく変わらないのだと感じました。 一方で、AIの生成するコードには、生成させた本人も意図を説明しづらい処理が混入することもあります。なぜその実装になっているのか、不要な処理ではないのか、後から変更しやすい構造になっているのか。そうした点を確認するには、単にコードを眺めるだけでなく、テストケースや設計の意図、変更の影響範囲も含めて見ていく必要があります。 品質に対する考え方は、システムの特性によっても変わります。利用者が限られたシステムで、非常に低い確率でしか発生しない不具合であれば、完全に防ぐために大きなコストをかけるよりも、発生時の対応も含めて合理的に判断する方がよいケースもあります。求められる品質水準は、システムの用途や利用規模、影響範囲によって変わるという点も、アンカンファレンスの中で印象に残った話題でした。 私が普段携わっているZOZOTOWNは、多くのユーザーや取引先に関わるサービスです。そのため、一見すると小さな不具合であっても、実際にはユーザー体験や業務に少なからず影響を与えることがあります。 もちろん、あらゆるケースを事前に防ぎきることはできません。しかし、開発工程が後半に進むほど修正コストが大きくなりやすいため、レビューやテストで気づける問題については、できるだけ早い段階で見つけ、未然に防ぎたいと感じています。そして、そのエラーの先には、実際にサービスを利用するユーザーがいます。また、不具合が発生した際には、その対応にあたる営業やカスタマーサポートなどの仲間もいます。小さく見える不具合であっても、そうした対応が積み重なることで、サービスやチームへの信頼に影響するかもしれません。 だからこそ、合理的な判断は大切にしながらも、ユーザーに届けるものに対してできる限り誠実に向き合いたいと思います。今回のアンカンファレンスを通じて、コードレビューを品質保証における重要な工程の1つとして捉える自分の考えを、改めて認識しました。 AIが書いたかどうかにかかわらず、エンジニアとしても、自分たちが届けるものに責任を持つ姿勢は変わりません。AI生成コードとの向き合い方を通じて、自分たちのレビュー観や品質への向き合い方を見直す、有意義なアンカンファレンスでした。 Javaコミュニティの関心の変遷を可視化する：JJUG CCC発表データから見る変化と不変 引き続き半澤が、Ayana Murakamiさんの『Javaコミュニティの関心の変遷を可視化する：JJUG CCC発表データから見る変化と不変』について紹介します。 speakerdeck.com Murakamiさんは、大学院で情報可視化を専攻していた「可視化オタク」として、遡れる限りの過去のJJUG CCCの発表データを分析されていました。松尾芭蕉の言葉として知られる「不易流行」を軸に、変わらず語られ続けているテーマと、時代に応じて関心が高まっているテーマを、テキスト分析と可視化によって読み解く内容でした。 まず、「変わらないもの」として挙げられていたのは、DBやテーブル設計に関するトピックです。業務の現場で複雑な要件をどのようにテーブル設計へ落とし込むのか、変化に強く柔軟な設計をどう実現するのかといったテーマは、継続して高い関心を集めていました。また、ファイルやクラスといったトピックからは、業務システムの設計だけでなく、Javaそのものの仕組みや内部構造への関心も根強くあるようです。前者は現場での永遠のテーマであり、後者はJJUG CCCでこそ聞きたいテーマでもあります。もし同時間帯に両テーマのセッションがあった場合、どちらを聴講するか迷ってしまいそうです。 次に、関心の高さに周期性があるトピックとして、Spring Bootのアップデートや周辺技術も紹介されていました。Spring BootのメジャーアップデートやJava LTSのリリースに連動するという分析は、自分の経験からも納得感がありました。 「変わるもの」としては、GraalVM / Native Image、Gradle / Maven、コミュニティといった、過去により強く関心を集めていたトピックが取り上げられていました。これらは廃れたというより、現在も議論され続けているテーマです。特にコミュニティに関する発表では、キャリアに関する話題も多かったとのことで、技術だけでなくエンジニアとしてどう成長していくかも、JJUG CCCで語られてきた大切なテーマなのだと感じました。周囲にも「JJUGに育てられた」と感じている人がいますし、自分自身もその一人です。技術的な学びだけでなく、エンジニアとしての視野を広げ、自分の歩み方を考えるきっかけを得られることも、JJUG CCCの大きな魅力だと感じています。 近年関心が高まっているトピックとして、2023年以降ではAIやLLMが挙げられていました。JJUG CCCでは生産性向上や効率化、エンタープライズ領域でのAI・LLM活用が多く語られています。一方、海外のJavaカンファレンスではAIをどうサービスに組み込むかという観点の議論が多いという比較も印象的でした。 JJUG CCCには、コンピュータサイエンスや設計の基礎のように長く大切にされてきた「不易」と、AIやLLMのように時代とともに関心が高まる「流行」の両方があります。Murakamiさんは、その根底にはJavaを使って安定したサービスを届けたいという思いがあると述べられていました。基礎的な知識や新しい技術の両方に触れられる場として、JJUG CCCの魅力を改めて感じるセッションでした。 ZOZOブース 「 ソウゾウのナナメウエ × Java 」 今回のZOZOブースのテーマは「 ソウゾウのナナメウエ × Java 」。 お題として「あなたのソウゾウのナナメウエなJava体験を教えて」を掲げ、来場者の皆さんに体験談を付箋に書いてパネルに貼っていただく企画を実施しました。”ソウゾウのナナメウエ”はZOZOのカルチャーです。ZOZOらしくJavaコミュニティを盛り上げたいという思いからこのテーマを企画しました。やらかし談、ドハマりしたバグ、救われた話など、ジャンルを問わずJavaにまつわるエピソードを募ったところ、 約70件 の体験談が集まりました。 参加してくださった方には、JJUG CCC限定の「 Duke×箱猫マックスステッカー 」をプレゼントしました。 集まった体験談 集まった付箋を分類すると、以下のような5つのトピックに分かれました。 トピック 件数 バージョン・言語仕様 19件 Spring・フレームワーク 14件 コミュニティ・その他 14件 JVM・ビルド・運用 13件 AI・他言語・開発スタイル 11件 注目のトピックをいくつか紹介します。なお、付箋に書かれた体験談は、参加者の皆さんの表現を活かすため原文のまま掲載しています。 バージョン・言語仕様 関連 新機能への歓迎と現場の苦労がリアルに表れていました。「recordクラス誕生！」「Virtual Threadはいいぞ」という新機能への期待の声がある一方、「Java 8→21移行中！」という苦労話も。「Springバージョン上げたいけどJavaバージョン上げられない…」「JavaのVerupするしないで顧客ともめがち…」という現場の率直な声も並びました。「まだJava 8（担当）」という付箋には、多くの参加者が共感していた様子でした。 AI 関連 今年ならではの傾向が出ていました。「AIが書いてくれるのでJavaを書けない」「AIでGradleの使い方を忘れた」「AIネイティブすぎてJavaが読めない」という声が集まりました。「コードのライセンスの問題でAIが使えなかった」という実務的な課題まで登場し、AIに任せる快適さと任せすぎることへの不安が同居しています。エンジニアコミュニティとして今まさに向き合っているテーマだと感じました。 ”沼”系の苦労話 「Eclipseでの環境構築で6営業日溶かした（泣）」「GCチューニングで全部止めた」「ビルド時間にコーヒーのめる」「カレンダーの月が0始まり…」など、思わず笑いを誘うエピソードが並びました。苦労話もユーモアに包んで共有されているのが、JJUGコミュニティらしい温かい雰囲気でした。 今回のお題を通じて、バージョン移行の苦労やAI時代の新しい戸惑いといった技術的なリアルはもちろん、まさに”ナナメウエ”な体験まで、Javaエンジニアのリアルな声が集まりました。苦労話ややらかし談を楽しく共有できる。そんなオープンで温かい雰囲気こそが、JJUGコミュニティの魅力だと改めて感じました！ ご参加いただいた皆さん、ありがとうございました！ まとめ ブースやセッションで交流してくださった皆さん、本当にありがとうございました。これからも一緒に楽しみながらコミュニティを盛り上げていけたら嬉しいです。次のJJUG CCCでもぜひお会いしましょう！ ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに LLM+RAG。とても効果的な仕組みだと思われるかと思います。 ただ、RAGのデータは私が個別に対応しているタスクのことを知らないし、過去やってきたことも知りません。 なので自分専用のRAGを構築したんですが、思ったより使い勝手が良かったので、同じような状況の人の参考になればと思い、手順/効果をまとめてみました！ ご紹介する環境では VS Code（Copilot Chat）にローカルRAGを繋ぎ、Confluence やローカル環境のファイルを検索して回答に活用させています。 またRAGのソースにはベクターDB（Chroma）を使っているので、単純に Markdown を

はじめに はじめまして！株式会社エス・エム・エスで介護事業者向け経営支援サービス「カイポケ」のQAを担当している柏尾です。 普段はQAチームで品質保証にかかわる業務を担当しています。 2025年5月ごろから品質保証の業務とは別で、カイポケ開発部内でのMonthly Win Sessionの運営をはじめました。 Win Sessionとは一般的に、メンバーそれぞれが「Win（成果や良かったこと）」を共有し、称賛し合う場です。 運営としての活動開始から約1年程度経過したので、今回はその経緯やどのような活動を実施しているかをご紹介します。 Monthly Win Sessionをはじめたきっかけ エス・エム・エスでは、過去に開発部内横断での情報共有の場や広報誌という良い取り組みをシェアするような場がありました。 いずれも非常に長く続いてきた取り組みで、取り組みが設計された時よりも組織が非常に大きくなっており、職能の多様化も進んできました。 そのため、その意義や良い点は引き継ぎつつ、現在の組織に合わせた再設計を行い、エス・エム・エスのプロダクト開発部が大切にしているバリュー「あなたがコミュニティ」（詳しくは コチラ ）をよりいっそう体現する新しい枠組みとして検討されていたのが「Win Session」という形でした。 Win Sessionのアイデアが持ち上がり、運営メンバーはマネージャー陣からの推薦で声をかけていただきました。 ただ、決して業務として強制されたわけではなく、「興味があるか」「やってみたいか」と丁寧に意思を確認してもらった上で、納得して運営チームへの参加を決めました。こうした個人の意志を尊重してくれるところは、今の組織のいいところだなと感じています。 集まったのは、開発エンジニア、デザイナー、プロダクトオーナー、そしてQAである私の6名です。所属チームもバラバラで、初対面のメンバーも多い中でのスタートでした。 Win Sessionをやろうという方向でスタートしたものの、場の設計などは全て運営チームの裁量に任されています。「やり方は自由に検討していい、予算が必要なら相談もOK」という、かなり自由度の高い状態です。 まずは「自分たちがどうしたいか」を考えるところから、運営チームの活動がはじまりました。 運営チームの熱い想い 運営チームは普段はあまり接点の無い人が多く、お互いの考え方や仕事のスタイルなど、何も知らない人もいる状態でした。 そのため、まずは全員がWin Sessionに期待することや想いを出し合い、考えのすり合わせを行いました。対話を重ねる中で、各メンバーが組織の課題解決に対して、高い当事者意識を持っていることがわかり、このチームで活動していくことへの期待感が高まりました。 この段階では、早くWin Sessionの開催までもっていったほうが良いのではないかと、焦りを感じることもありました。振り返ってみるとしっかり想いを出し合って、丁寧に目的意識をすり合わせたことはとても重要な時間だったと感じます。 1年近く運営してきて会の改善に取り組んでいる中で、意見が食い違うこともありました。しかし最初に方向性をしっかりすり合わせているため軸がぶれず、最終的にはみんなで納得しながら判断できていると感じます。 現在はWin Sessionを「お互いの理解を深め称賛し合うことで、開発部全体のパフォーマンスを高める交流の場」ととらえ、毎回の会を運営しています。 また、目指したい姿として、「取り組みと称賛のループ」「壁を薄く、重力を軽く」という2つを挙げて取り組んでおります。 称賛の場からさらに良い取り組みを呼び、称賛を受ける、そんなループを作りたいと思っています。 また、カイポケ開発部はいくつものチームに分かれ、更にいくつもの職種の人が存在しています。チームの壁、職種の壁を薄くし、お互いの交流を促すきっかけの場にしていきたいという思いがあります。 運営の進め方 運営の進め方として、現在は週1回の定例MTGを実施しています。それ以外の日は資料作成などタスクを持ち帰って進めることもあります。 メンバーの所属チーム・職種がバラバラである分、繁忙期のタイミングも異なるため、各自の業務状況を見ながら可能な人が積極的にタスクを引き受け、分担することができています。 定例MTG自体も業務状況を見て欠席してもよいというスタイルです。 メインの業務の傍らで継続的に運営するために、運営の負荷を減らすことも重要なテーマだととらえており、定例MTG自体の時間を短くできないか試行錯誤したり、テンプレ化できるものはテンプレ化するといった改善も重ねています。 Win Sessionの実際の会では、参加者からのアンケートも回収しており、そのフィードバックや会の盛り上がりをみながらより良い会にすべく模索を続けています。 例えば、Win Sessionをはじめた最初のころは、より多くの発表を聞きたいため、発表時間は5分縛りにする案が上がっていました。しかし実際にWin Sessionをやってみると、質問が盛り上がることもあり、時間を短く縛りすぎるのはかえって会を盛り下げることになるかもしれないという懸念が運営チーム内で生まれました。 そういった状況を鑑みて、現在は月に1時間の会の中で発表本数は2本のみに制限しています。発表自体は1本あたり最大20分程度で残りの時間を質疑応答や深掘りの会話の時間にあてています。 Monthly Win Sessionの発表例 現在はMonthly Win Sessionとしておよそ月に1回の頻度でオンラインで開催しております。参加者は毎回80人を超える会となっています。 様々なチーム・職種の方に登壇いただき、他の組織の活動を知るきっかけにもなることができています。 オンライン開催のため、感想や質問はSlackの実況チャンネルを用意していますが、毎回たくさんの感想や称賛のコメントで盛り上がっています。 実際の発表時のSlack 単に「すごいね」で終わるだけではなく、発表内容を他のチームで取り入れるなど、業務に役立った事例も多数あります。以下では実際の事例をいくつかご紹介します。 「スクラムチームでモブテストをやってみた」 こちらは記念すべき第1回の1発目の発表です。開発エンジニア、デザイナー、QAで集まってモブプログラミングのようなイメージでテストを実施した事例を実例とともに発表いただきました。 発表直後にはもう以下のようなSlackが流れ、他のチームに良い影響が広がっており、運営チームとしてもとてもうれしかったことを覚えています。 取り組みが波及した例 「生成AIを活用したデザイナー協業ワークフローの再構築」 AIを活用してデザイナーがVibe Codingでデザインを組むために、非エンジニアがAI活用するための環境整備を行った取り組みを発表いただきました。 AI活用は弊社内でもトレンドとなっており、他のチームでも同じような取り組みをしようとしていたと声が上がっていました。 とてもホットなトピックで、実況チャンネルがとても盛り上がっていました！ 「非エンジニアが​AIを​使って​開発環境で​開発した​話」 2例目にあげた「生成AIを活用したデザイナー協業ワークフローの再構築」のセッションをきっかけに実施された取り組みについて発表いただきました。 2例目の発表からわずか3か月後に発表までしていただいており、素晴らしい取り組みにとても驚きました。 私たちが目指している「取り組みと称賛のループ」に一歩近づいたことを実感できる事例でした。 課題とこれから目指したいこと Win Sessionは毎回アンケートでも好評をいただいており、良い影響も生み出せていますが、まだまだ課題はたくさんあります。 最も大きな課題はやはり「発表者集めの難しさ」です。 会をはじめてから1年間で、発表の立候補もいただきましたが数自体は少なく、立候補のみで継続して運営することはできていません。 そのため、現在はSlackを活用した他薦・自薦のネタ集めを中心に行っています。 Slackのリアク字チャンネラー機能 を使っており、Winだ！と思ったSlack投稿にWin Sessionスタンプを押すとWin Session用のSlackチャンネルへコピーされるようにしています。 Slackで使用しているスタンプ コピーされてきたものの中から、より関心がある人が多そうなネタを選んで運営チームから関係者に発表いただけないか声掛けを行っている現状です。 ありがたいことに発表の声掛けをして断られた事例は無く（時期が合わないため先の発表にしてほしいなどはもちろんありますが）、みなさん好意的に引き受けてくださり、運営としての心理的な負担もなく、継続していくことができています。 現在の状況でもそれほど負荷なく運営できている事実はありますが、運営から声掛けをして登壇者を募るフェーズは、あくまで自走に向けた準備期間だととらえています。 誰かに頼まれたから話すのではなく、日常の小さなWinを自然に発信したくなるような、そんな空気が醸成されて初めて、Win Sessionは組織の文化として根付いたと言えると思っています。よりカジュアルに、より気軽に参加できる場を目指して、これからも改善を重ねていく予定です。 運営チームに参加してみて ここまで運営の仕組みや課題についてお話してきましたが、最後に運営メンバーとして活動してきた感想にも触れさせてください。 運営を通して何より刺激を受けたのは、全員が常に目的意識をもって意思決定を進めている点です。ただ漫然とWin Sessionの会を開催するだけでなく、常に目的を達成するための会にできているか思考しながら運営を進めています。 私たちが日々取り組んでいるカイポケのシステム開発も同じで、業界の課題をどう解決するか、常に考えながら向き合うことが求められており、その姿勢がメンバーの習慣となっているように感じました。 本業の枠を超えた活動を通じて、「常に目的意識をもって課題解決をする」大切さを再確認できたことが私にとって大きな収穫でした。 また、チームや職能が異なる人と働く面白さも感じました。 弊社では日ごろの業務の進め方はチームの裁量に任せられているため、チームごとの特色があります。今回他のチームの方と長期間働いてみて、そのごく一端ですが知ることができました。 わかりやすい例だと、Miroの使い方ひとつとってもチームごとに特色があり、良いなと思った活用方法はチームに持ち帰って役立てています。 役割の面では、個人的にはデザイナーさんの考え方に触れることができたことが学びにつながりました。現在私が所属しているチームではすでに稼働中のシステムを担当していることもあり、デザイナーさんとお仕事する機会はほぼありませんでした。 今回デザイナーさんと何度も会話する中で、ユーザー目線、受け取り手目線の考え方がとても勉強になり、QAとしてプロダクト品質に向き合う中でも持つべき視点を学ぶことができました。運営チーム内の他のメンバーからも「Win Sessionでぜひデザイナーさんの話を聞いてみたい」という声が何度もあがっていました。 チーム、役割の異なる人と働くメリットを知ることができたので、こういった機会は今後も大切にしていきたいと感じました。 おわりに 私個人としてはこういった大きなイベント運営にかかわったことはほとんどなく、運営に参加することは大きなチャレンジでしたが、今では一歩踏み出して良かったと思っています。 自由に試行錯誤させてくれる社風や、意見を前向きに受け入れてくれるメンバーのリアクションに助けられて、楽しく活動を継続することができています。 この記事を通じて、Monthly Win Sessionの空気感や、エス・エム・エスの空気感が少しでも伝わればうれしいです。