こんにちは！TECH Street編集部です！
2024年4月1日（月）に開催した、 「アプリケーション開発エンジニア勉強会」のイベントレポートをお届けします。今回は3社のアプリケーション開発に携わるエンジニアが集まり、それぞれの知見を発表し、学びあう勉強会を開催しましたので、その様子をレポートいたします。
登壇者はこちらの方々！
Seiya Umemoto ／ パーソルキャリア株式会社
azukiazusa ／ 株式会社はてな
今枝 ／ 株式会社オプティム
早速、内容を紹介いたします！
- Azureで社内文書から回答可能な生成AIチャットサービスを作った話
- Reactフレームワークの動向と選定基準
- スプリントレビュー（バザー形式）とそれを支えるCI/CD
- Q&Aコーナー
では、最初はパーソルキャリア株式会社 Umemotoさんの発表です。
Azureで社内文書から回答可能な生成AIチャットサービスを作った話
梅本：本日は「社内文書から回答可能な生成AIチャットサービス」について概要の説明から取り組んだこと、そして今後の課題まで網羅的にお話できればと思います。
目次
- はじめに
- 結論
- 概要の説明
- 取り組んだこと
- 今後の課題
- まとめ
はじめに
社内向けチャットサービスChatPCAとは
以前は社内イントラ用の「きゃりーちゃん」というボットサービスがありました。これは、ルールベースのため、読み込ませた定型の資料内容以外のことは回答できませんでした。
これだと、日々蓄積する社内データに対して柔軟に対応することが難しいため、「生成AIを活用して上手く対応をしたい」と考えました。そこで開発したのが「ChatPCA」です。ChatPCAは、Chat＋PCA（パーソルキャリア）の造語で、パーソルキャリア内で利用されるAIチャットサービスのことです。
課題と解決策
ChatPCAを開発する中で、乗り越えるべき課題がありました。
それは、社内文書は基本的にMicrosoftSharepointで管理していましたが、どういった文章をどこからどのように探したら良いのかが不透明だったのです。また膨大にある社内文書の中から該当する文書を探すのも大変でした。
今回の話の前提
社内向けチャットサービス（ChatPCA）の対象ユーザー
・社内の6000人ほどのフロント・バックオフィスのメンバー
社内文書検索はまだβ版であり継続した改善が必要
・ユーザーからのFBをもとに機能・非機能面の改善が必要
対象の文書はtxt,PDF,Word,Excel,PowerPoint
・埋め込みフォントが組み込まれたPDFファイル等は対象外
・今後OCR等を導入して対応予定
結論
社内文書検索機能をリリースしてみて
＜機能として効果＞
- 既存の標準チャットではできなかった社内用語を元にした回答が可能になりました。
- 社内の勤怠や申請フロー等々業務上の基本的な情報に関する質問に回答が可能になりました。
＜大変だったこと・苦労したこと＞
- GPT-4を使うと運用コストとして負荷が大きいためGPT-3.5でパフォーマンスを担保する必要がありました。
- ハイブリッド検索でパフォーマンスを担保（後半で説明します）
- 開発環境と本番環境の差分による問題点
- LangChainのバージョンアップによる周辺パッケージのデグレ
- 初めはVercel AI SDKを使っていたが、GPT-4でchat_historyが反映されなくなるバグがあってピュアなLangChainにリプレイスする必要がありました。（今回の発表ではこちらには触れないですが、別の機会にお話しできたらと思います。）
概要の説明
生成AIの概要
下図の通り、AIという大きな括りの中に、機械学習やディープラーニングがあり、その中に生成AIがあります。
生成AIができることとして、「テキスト生成」「画像生成」「動画生成」「音声生成」などがあります。
プロンプトエンジニアリング
生成AIで重要なのはプロンプトエンジニアリングと呼ばれる指示文です。具体的なコンテキストを渡すと条件に合った回答が得られる、というものがプロンプトエンジニアリングです。
プロンプトの要素は下図の通り、様々な要素が絡み合っています。
RAG
一方で社内用語や最近できたばかりの用語などは、LLMでは学習されていません。ではどのようにして回答するかというと、ドキュメントをEmbeddingsしてVector DBから参照し、回答を生成するという流れが必要になります。その技術をRAG(検索拡張生成)と呼びます。
LangChainとは
LangChainは、大規模言語モデル（LLM）を活用してアプリケーションやサービスを開発するためのOSSライブラリです。LLMを使った処理のフローを抽象化して実装できるという点がポイントです。
下図のように要素はたくさんありますが、OpenAIやGeminiなどの特定のLLMに特化せずに抽象化して、柔軟な実装が可能です。
アーキテクチャ
チャットUI
- 基本的にAzureを使った構成になっています。
- 認証済みのユーザーはWAF Policyの付与されたAzure Front Doorを経由してApp Service上のアプリにアクセスします。
- ユーザーが社内文書検索機能を使うと、Azure AI Searchを通して質問に関連する社内文書を検索します。
- Azure OpenAI Serviceを通して、質問と社内文書から回答を生成します。
- チャット履歴や関連する分析用のデータはCosmos DB上に保存されます。
社内文書の取り込み
- Microsoft Sharepoint上から社内文書をBlob Storageに取り込みます。
- Azure Functionsで必要なメタデータの加工を行います。
- Azure AI Searchで検索用インデックスを作成します。
- Azure OpenAI Serviceを通して、社内文書データのベクトル化を行います。
分析&可視化
- Cosmos DBからAzure Machine Learningを通して分析用データの転送と加工を行います。
- Power BI上で分析データの可視化を行います。
選定技術
TypeScript & Next.js
・フロントエンドメンバーがメインでアプリ全体の開発を行うため、社内知見の多いNext.jsを使い、言語はTypeScriptで統一しています。
NextAuth.js
・MicrosoftのGraphAPIを用いて認証を行いますが、Next.jsと相性の良いNextAuth.js (v5ではAuth.jsと呼ばれる) を選定しています。
Azure
・こちらはAzure OpenAI Serviceで社内版ChatGPTのChatPCAを構築した話にて選定理由を説明しています。ご一読いただければと思います。
・Azure AI Search
・ベクトルDBとして利用。Azure内のサービスとして親和性が高く、ハイブリッド検索やセマンティック検索など、RAGとして必要な機能が豊富な点が選定理由です。
Azure Cosmos DB(NoSQL)
・6000人規模の社員全員が同時に利用するため、スケーラビリティの高いNoSQLサービスであるAzure Cosmos DBを選定しています。
Vitest
・Jestよりも実行速度が高く、選定時にv1系がリリースされたこともあり、今後のポテンシャルを見て選定しています。
Playwright
・並行処理性能がCypressよりも優れているため選定しています。
Github Actions
・部署内でデファクトスタンダードとなっており、またself-hostで実行が可能なGitHub Actionsを用いています。
Azure OpenAI(AOAI)
・導入当時に最も業界知見の多いLLMモデルとして選定。また、社内のコンプライアンス規定によりリージョンを日本国内に絞る必要があったことも選定理由の一つです。
LangChain.js
・今後さまざまなLLMモデルやベクトルDBと疎結合にするために利用しています。
取り組んだこと
検索用クエリの生成から回答の生成まで -プロンプト
プロンプトチューニング
日本語で扱う事を想定しているため基本的に日本語で指示用のプロンプトを作成しました。検索クエリと回答生成用のLLMにそれぞれプロンプトプレートを指定しました。
検索クエリを生成するLLM用のプロンプト
チャット履歴＋ユーザーの入力プロンプトで検索クエリを生成しました。
回答を生成するLLM用のプロンプト
チャット履歴＋ユーザーの入力プロンプトにコンテキスト（文書データ）を加えて回答を生成しています。
チャンク分割
チャンク分割とは文書を適切な粒度に分割することです。
ドキュメントはページ数が多いとLLMに入れられないので、チャンクに分割したうえでEmbeddingsにてベクトル化する、という作業が必要になります。
インデックスのAnalyzer
Analyzer（検索分析エンジン）の主な種類
・Standard Lucene
・Japanese Lucene
・Japanese Microsoft
「Japanese Lucene」を選択
・「ファイル名」と「チャンク（分割した文書の内容）」の2項目に適用
・英語の検索も考慮する場合はSrandard Luceneの方が適切ですが、今回はそういったユースケースを想定していません。
検索用クエリの生成から回答まで-検索クエリの生成
・検索クエリを生成するLLM
クエリの生成速度とコストを考慮してGPT3.5を使用
・チャット履歴とユーザーの入力を加味して適切な文書検索用のクエリを生成してくれる
生成したクエリをベクトル化して関連する文書を取得する
ただ、ベクトル検索単体だと、ベクトル空間上で距離の遠い文書を取りにいけません。
そこで、全文検索とベクトル検索を組み合わせた「ハイブリッド検索」を使いました。全文検索を組み合わせることで、ベクトル空間上で距離の遠い文書を全文検索のスコアで補完して取りに行けるようになりました。
しかし、それでもまだ課題がありました。
例えば、AZといった短い＋他の用語と衝突しやすい単語の場合、LLMも混同してしまいました。また、全文検索をしても文書への距離が遠い分参照ができませんでした。
そこで、解決策として、全文検索用のクエリを形態素解析（kuromojiを使用）して単語単位で検索させることで全文検索のスコアを向上させました。
検索用クエリの生成から回答まで-検索スコアの閾値
他にも文書所得に関しての課題点がありました。
検索して取得するドキュメントの数は現在6つとしたのですが、そうすると、関連するドキュメントとそうではない文書が入り混じることで、回答に乱れが出てしまいました。
そこで、解決策として閾値となる検索スコアを設けることでノイズを弾きました。
検索用クエリの生成から回答まで-文書の取得
ドキュメント情報の取得方法には
・stuff
・map_reduce
・refine
・map_rerank
以上の4つがあります。
stuff
stuffは一番シンプルな手法でチャンクをそのままLLMに投入することが可能です。
map_reduce
map_reduceは個々のチャンクから並列に回答を作り、最後に回答をまとめて生成します。
refine
refineはチャンクから順番に回答を生成していきます。
map_rerank
map_rerankは個々のチャンクからスコア付きのサマリーを作り、スコアの高いものから回答生成されます。
流れについては、下図をご覧ください。
検索用クエリの生成から回答まで-回答の生成
・ユーザーの設定したLLM（GPT-3.5かGPT-4）によって回答を生成する
・参照した文書データをLangChainのChainの機能を使って取得できるので、これを回答の末尾に加える。
今後の課題
プロンプト評価の仕組み作り
現状のプロンプト評価のやり方は、チームメンバーにエクセルシートへの入力や結果、それに対する評価を記載してもらっている状態です。これでは現実的に運用していくのは難しいので、CI上でプロンプトの出力結果をスコアリングできるようにして、評価を自動化していきたいと考えています。
社内文書の拡充
・現状の社内文書検索機能の課題
・参照している社内文書の質に大きく影響されてしまう
・参照している社内文書が間違っていれば回答を間違える
・ハルシーネーションが発生してしまう
・社内文書が不足していればそもそも回答ができない
・欲しい情報を紹介している文書を増やしていく
・フォーマットを整えていく
・その文書がどういったものなのかを説明する文言を加えたり、カテゴリを明記していく。
・Word,Excel,PowerPoint等々非構造化データに対する対処
・埋め込みフォントやテキストボックスのフォーマットに対する技術的な対応方法は検討中、、
まとめ
・社内のドキュメントをもとにチャットをできるようにしたいというニーズに応え、社内文書検索機能をリリースしました
・パーソルキャリア独自の社内用語等に回答ができるように検索の仕組みに工夫を加えました
・ハイブリッド検索
・更に形態素解析を加えることでパフォーマンスを向上
・検索スコアの閾値
・etc.
・今後の課題点に関して以下の2点を話しました。
・プロンプト評価の仕組み作りについて
・社内文書の拡充に関して
以上で発表は終わりです。
Umemotoさんありがとうございました！続いては、株式会社はてな azukiazusaさんの発表です。
Reactフレームワークの動向と選定基準
azukiazusa：本日は「Reactフレームワークの動向と選定基準」というテーマで以下についてお話しできればと思います。
- メジャーReactフレームワークの紹介
- 技術選定時に考えるべきポイント
- 実際にどのような選択をしたのか
- まとめ
メジャーReactフレームワークの紹介
そもそもReactプロジェクトにフレームワークは必要なのかという話から始めましょう。
ほとんどのサイトやアプリケーションで必要な機能の再発明を防ぐために、フレームワークが必要だと考えられています。
ルーティングやデータ取得、コード分割など、はじめは必要としていなくても、アプリケーションの機能が多くなっていくにつれて必要になってくると思います。
しかし注意してほしいことは、フレームワークの推奨はReactで新しいプロジェクトを始める場合を想定している、という点です。
そのため、フレームワークを使わない選択肢が全く否定されるわけではない、ということです。
例えば、既存プロジェクトにReactを追加するという場合や社内向けツールなどそこまで高度なものを要求されていないという場合にも、フレームワークを使わないという選択肢も考えられます。
React フレームワークの紹介
メジャーなReactフレームワークは、以下の辺りかと思いますので詳細を紹介していきます。
- Next.js(Pages Router)
- Next.js(App Router)
- Remix
- Remix(SPAモード)
- React＋Vite（バンドラ―）
- Gatsuby
- Astro
Next.js(Pages Router)
Next.js(Pages Router)の特徴として、ページごとにSSR・SSG・ISRの中からレンダリング方式を選択できます。
例えば、ユーザーが記事を投稿するようなサイトで都度データが変わるような場合にはSSRで毎回データをサーバーサイドで取得し、反対に変化がない利用規約画面のような静的な画面ではSSGを選択するといったように、ページごとに細かくパフォーマンスの最適化ができるという特徴があります。
Next.js(App Router)
Next.js(App Router)は、Server ComponentsやStreaming, Server Actionsなどの Reactの最新機能をいち早く使えるというメリットがあります。
React Canary: Meta 外での段階的な新機能導入
Remix
Remixは比較的新しいフレームワークですがWeb標準のAPIを採用しているため学習コストが比較的緩やかだと思います。ただNext.js(Pages Router)と比較すると高度な機能は提供されていないので、「パフォーマンスを極めたい！」という場合は他のフレームワークをおすすめします。
Remix(SPAモード)
Remix（SPAモード）はサーバーを実行せずに静的ファイルを出力してSPAとして運用するものです。またRemixの既存のAPIをほぼ利用できます。一方、SPAの特性としてユーザー体験やSEOが犠牲になってしまうのがデメリットです。
React＋Vite
フレームワークを採用しない選択としてReact＋Viteがあります。サーバー運用コストやフレームワーク学習コストが抑えられたり、既存のバックエンドとは統合しやすいメリットがあります。一方、デメリットとしては、ルーティングやデータ取得のライブラリを統合する作業を自分で行う必要がある点です。
Gatsuby＆Astro
SSGに特化されたフレームワークがGatsuby＆Astroです。
静的なドキュメントサイトに使うのが主な用途になっています。
技術選定時に考えるべきポイント
続いて、技術選定をする際に考えるべきポイントについて以下の4点について紹介します。
- プロダクトの特性
- プロジェクトの優先度
- 開発メンバーのスキルセット
- 社内での採用事例
プロダクトの特性
「プロダクトの特性」については「ECサイトなのか、社内システムなのか、BtoB向けのSaaSなのか」などという基本的な目的のすり合わせから必要になってきます。
SaaS向けのアプリケーションでは、ユーザー体験のためにもパフォーマンスを完全に無視することはできませんが、プロダクトを採用する決め手としてパフォーマンスが重視される、ということはあまりない印象があります。
プロジェクトの優先度
フレームワークをリプレイスするような場合には、新規の開発が止まってしまう恐れがあるため「どのくらいの期間であれば開発を止めても良いのか？」というコストを考えます。そして、そのコストに対して、新しい機能を採用することのメリットがどれだけあるのかを考える必要があります。
開発メンバーのスキルセット
開発メンバーのスキルセットを確認します。あまり慣れていないメンバーが多い場合、高度な機能を持つフレームワークを採用すると教育コストがかかります。
社内での採用事例
社内の他のプロダクトで使われている場合、問題に直面した時に他チームの知見が使えます。また、メンバーの増員が必要になった時、同じフレームワークを採用していればJoinしやすいです。
以上をまとめると、ポイントとなるのは「ある機能から享受できる利益と発生するコストを天秤にかけて考える」ということです。
では、実際にどのような選択をしたのかについてお話します。
実際にどのような選択をしたのか
前提条件は以下をご覧ください。
これらの前提条件を踏まえて「React＋Vite」を採用しました。下記が主な理由です。
- まずパフォーマンスが最優先事項ではないこと
- フレームワークのリプレイスに工数を割けないこと
- 社内のその他のプロダクトとは特性が異なるので、採用事例は重視しなかったこ
- 技術選定をした当時Remix SPA モードはStabeではなかったこと
このように技術選定については
- プロダクトマネージャーを説得かさせる材料があるかを考えて言語化する
- 意思決定した際には必ず文書化する
この2点がポイントです。
私たちは、このポイントを網羅すべく技術選定についてはADRと呼ばれる手法で行っています。
ADRとは、特定のアーキテクチャを共有した短いテキストファイルがあり、そのテンプレートにしたがって文書を作成しレビューを受けることです。
まとめ
- Reactのメジャーなフレームワークの特性を紹介
- 技術選定をする際には、与えられた諸条件からある機能を採用した際に享受できるメリットとコストを天秤にかける
- 意思決定者を説得できるだけの材料があるか？を考えて言語化する
- 意思決定した際のコンテキストや決定などを文書化するわりです。
以上で発表は終わりです。
azukiazusaさんありがとうございました！続いては株式会社オプティム 今枝さんの発表です。
スプリントレビュー（バザー形式）とそれを支えるCI/CD
今枝：本日は「スプリントレビュー（バザー形式）とそれを支えるCI/CD」ということで、以下についてお話できればと思います。
- スクラム開発とスプリントレビュー
- スプリントレビュー 運用時の課題
- スプリントレビュー バザー形式とは
- バザー形式 運用事例
- バザー形式を支えるためのCI/CD改善
スクラム開発とスプリントレビュー
スクラム開発とは、少人数のチームで、｢スプリント｣と呼ばれる一定期間に機能の設計、開発、テストを繰り返しながら開発を進めていく手法のことです。
そして、今回お話するのは、スプリント中に完了した作業をレビューして実証する「スプリントレビュー」についてです。
スプリントレビュー 運用時の課題
実際にスプリントレビューを行うと、以下のような課題が出てきました。
- 十分な結合がされていないアプリでレビューされてしまう
- 開発担当者が発表する、受け入れ条件の確認のみになっている
- クローズの場で開催されて社内にプロダクトの状態の周知ができない
スプリントレビューバザー形式とは？
上述の課題を考慮して「バザー形式がよいのでは」という話が出たので、実際にバザー形式を導入することにしました。
バザー形式は実際に触ってもらうということをメインにしながら、スプリントレビューの議論の活発さ向上を狙いとしています。ブースにメンバーが分散しているので、少ない人数でフィードバックを受けられる場となっています。
バザー形式の運用事例 会場・タイムボックス
バザー形式の運用として、下写真のような形で行いました。
バザー形式のスプリントレビューで実際に得られた効果
- ユーザーが自由に触ることでUI・UXデザイン関連の違和感のフィードバック
- 確認が漏れていたバグのフィードバック
- 開発者への質疑応答も活発に行われていた
などより有意義なフィードバックが得られました。
また「定期的にこういった他製品に実際に触れる機会があると売りやすい」といった営業担当の声や「ユーザーの実際の操作を確認しながら、デザインシステム等の懸念点が発見できた」といったデザイナーの声もいただきました。
スプリントレビューの準備の課題
しかし、バザー形式によって以下のようなスプリント課題が浮き彫りになりました。
- スプリントレビューにリリースが間に合わない
- ドキュメント作成の追従が間に合わない
そこでデプロイ周り・リリース頻度改善やドキュメント生成の運用見直しをCI/CD上で実現することを目指していきました。
CI/CDの改善：検証環境へのデプロイフローの見直し
下図が実際に行ったCI／CDのデプロイフローの改善と、ドキュメントの自動生成についてまとめたものです。改善後は、CIとCDがシームレスに繋がるようにしており、はじめて入った方でもデプロイできるように改善しました。
ドキュメント更新・認識合わせ中間成果物もCIから生成
- GitLabのReviewAppsボタンから環境を参照して認識合わせ
- リポジトリのバッチに配置し、瞬時に今の実装の仕様・定義を検索できるようにする
- 結合に関わる定義ドキュメントはCIで自動生成・自動更新
Schema Spyとは
- Schema SpyでER図とテーブル情報定義を検索可能な状態に
- データベースのドキュメントをHTMLで出力するJava製ツール
Redocly/redocとは？
- OpenAPI Specification からコードも生成しているため、簡単に見やすい仕様書の作成のために利用
- Redocは、OpenAI（旧Swagger）定義からドキュメントを生成するためのツール（npmパッケージから利用可能）
CI/CD改善について
速度を上げた開発、デプロイ頻度の増加、品質の担保、その他ドキュメントの整備、CIの高速化に向けてまだまだ課題は多いですが‥‥、スプリントレビュー（バザー形式）を開催できるぐらいの改善はできました。
まとめ
スプリントレビュー バザー形式を導入してみて
- 従来の受け入れ条件の確認等がメインのスプリントレビューを脱却できた
- 有意義なプロダクトを改善できそうなフィードバックが多く集まった
- 導入する際はCI/CD＋運用改善も併せて実施し回せるようになった
などの結果を得ることができました。
最後に、弊社のテックブログもありますので、そちらもご確認ください。
以上で、発表は終わりです。
今枝さんありがとうございました！続いてはQ&Aコーナーです。
Q&Aコーナー
（Q）dodaお世話になっております。こういった社内システムは基本的に既製品ではなく内製ですか？
Umemoto：内製です！生成AIに関しては所属している部署のエンジニア・ビジネスメンバーで開発しています。
（Q）AI等について、どのようにして最新技術をキャッチアップされておりますでしょうか？
Umemoto：AIに限らず、Xから情報収集することが多いです。気になる技術を先んじて発信している方をフォローしています。QiitaやZennもみていますし、Mediumはサブスクに入っています。最近はChromeのホーム画面で表示されるリコメンドも便利です！
（Q）文書構造化（フォーマットを整える）するにあたって、どういう要素が揃えば「生成AIが正確な回答を作れる状態」になるのでしょうか
Umemoto：コンテキストを与えないとちゃんと回答してくれない。主語を書く、フォーマットも分かりやすい文脈にするというアプローチが必要です。技術的なアプローチとして、飛び飛びの文書を補完するということもしています。
（Q）アクセスログなどはどのような見え方になりますでしょうか？
Umemoto：社内のセキュリティ・コンプラの都合上、今回は難しいです！
（Q）生成AIによってどうシステム開発サイクルが変化するか。
Umemoto：現状生成AIによって各工程がなくても良くなることないと思いますが、例えば生成AIに設計や実装の叩き台を作ってもらって、作業者はそれをレビューして修正していくといったフローにシフトしていく流れは徐々にできてきていると思います。
（Q）社内アプリ開発におけるエンジニアのKPIはどのように設定していますでしょうか。目標数値とかは設定していますか？
Umemoto：社内アプリ開発の場合はまず第一にアプリの浸透率が挙がります。
特定の期間において、社内ユーザーが最低限一定の期間にアプリを利用したか、
という指標は最低限の目標値になります。
（Q）はてなさんも最新の技術情報の収集についてどのようにされているかお聞きしたいです。
azukiazusa：Xのタイムラインを眺めて情報収集。Chromeのリコメンド機能も使っています。はてなブックマークが技術トレンドを集めてくれるので、ここも活用しています。
（Q）Reactでのパフォーマンス最適化の工夫でお話しできる点があればぜひアドバイスお願いします
azukiazusa：パフォーマンスの最適化には、まず大切なのは計測です。「どこのパフォーマンスが問題になっているか？」「そこが遅いことでどんな問題があるか？」を把握することが重要です。計測には、LighthouseやChromeの拡張機能を使って、コンポーネントの描画にかかる時間などを探っています。
（Q）SEOが犠牲になるというのは素人目線だと大きいダメージのように見えるのですが、これは「SEOを捨てよう」ではなく「SEOが必要としないようなものに対しては有効打になる」という風に捉えれば良いでしょうか。
azukiazusa：ToC向けのサイトだと、SEOは大切です。今回のプロジェクトは、ログインの必要なSaaSアプリケーションで、SEOの優先度はそれほど高くありません。検索を通してユーザーを獲得することが少ないからです。なので、SEOによるダメージはあまり重視していません。
（Q）社内のエンジニア開発体制ってどのような形式なのか参考までにお聞きしたいです。また今回Reactのお話ですが、こういった技術選定はどのようにされておりますでしょうか。
azukiazusa：2 週間スプリントのスクラム開発を採用しております。1 チーム 3 ~ 5 人で構成されていて、複数のチームが存在しています。
技術選定を行う際には RFC という形式で意見を募ったり、ADR と呼ばれる形式に基づいた文書をもとに議論を行い、文書として残すようにしています。
（Q）Reactを使うためには、Node.jsをはじめbabel・webpackなどのプログラムをインストールすることが求められるので、インストール後は、これらプログラムのアップデートなどの対応も必要でその分、環境の構築に手間がかかることは否めない気がするのですが、このあたりはどうお考えでしょうか。
azukiazusa：インストール後も、プログラムのアップデートの対応が必要になるのはその通りだと思います。
とはいえ、React といったライブラリを採用するとユーザー体験・開発者体験の向上が十分に得られると見込まれるので、環境の構築に手間がかかることに対する対価が上回っていると思います。
（Q）レビューに営業・デザイナーが参加すると、仕様変更が発生して、開発計画がスライドしてしまうといったことが起こるように思ったのですが、どうでしょうか？ 対策あれば教えていただきたいです。
今枝：レビュー計画なので、次のスプリントに対してなので、そこのフィードバックに関しては柔軟に受け入れます。デザインなども、有意義な内容の場合は取り込む姿勢です。
（Q）CICDで使われているツールなど、どういう観点で選定されましたか？
今枝：全社的にGitLabを利用しているのでCIはGitLabベースのもので構築しております。アプリチームが管理しているので、全社的なCICDツール以外はCICDのツールなどはアプリチームが導入を検討し、チームごとに導入しております。
（Q）スクラム開発は昔からずっとですか？（オプティムさん社内）
今枝：ドローンを使う農業や医療だったり、色々なプロダクトを抱えている企業です。そのサービスに合った開発手法をチームごとに採用しています。
昔はウォーターフォールで開発することが多かったと思いますが、最近はスクラムが採用されることが多いです。
（Q）バザー形式は初めて知りました。この形式に至った理由やきっかけ、どこからの発案なのか等知りたいです
今枝：元々はスプリントレビューだったが、POの提案や他社の記事などを参考にして、コロナが落ち着いたというのもあり、バザー形式を導入してみました。
（Q）CI CDについてですが、こちらはアプリケーション規模が大きくなっても運用可能でしょうか？
今枝：今の所問題なく回っておりますが、さらに大きな規模になりパイプライン・デプロイ等に課題が出てきましたら、CICDのスケールアップや別のツール・運用フローを含め検討すると思います。
（Q）構築するサービスやシステム、メンバーの技術力などにもよると思いますが、保守性や可読性を上げるためにコードの設計の際に大切にしていることをお伺いしたいです。
Umemoto：保守性や可読性という点では、レビュー体制を重要視しています。
開発しながらレビューするので、レビューに入れるメンバーもタイミングで変わってくる、どういった形であれ、レビューの体制をいかに属人化させないかを意識している。コードにコメントをつける、アノテーションをつけるはもちろんのこと、コミットメッセージを丁寧に入れています。後で振り返ったときや引継ぎのときに、どんな修正が入ったかが分かるようにしている。そうすることで、チームとしても円滑に回っていくと思います。
azukiazusa：設計の観点でいうと、あまり得意でない人もさわる可能性がある。難しいところを抽象化して、触りやすくしている。既存のページからコピペするだけで、実装できるというのが理想的です。静的解析ツールを入れるのがポイントとしてあると思っています。コードのクセなどをチームで統一しておくと、自動で修正も入ってくれるので、開発スピードも高められます。
今枝：デキる人が共通化やディレクトリのルールを決めておく。静的解析ツールを早めに導入して、コードの品質担保をしておく。
Gitのコミットツールを導入している。コミットレベルやプルリクレベルで見れるようにしています。
（Q）各社さんのお聞きしたいのですが、アプリエンジニアとして社内での現在の立ち位置で嬉しい点とか自慢な点、あとエンジニアとしてのキャリアアップとしてどのようにスキルアップしてPRしているか。イベント趣旨と異なっていましたら申し訳ありません。
Umemoto：裁量の大きさです。フロントエンド、インフラ、アナリティクスなど全部自分で携わっているので、一気通貫で経験できたのは学びが多くて楽しかったです。裁量が大きいからこそ、評価やキャリアアップのためにアピールしていけることは沢山あると感じています。
azukiazusa：裁量が大きい点です。エンジニア個人に信用してもらえていて、自分がやりたいことはやらせてもらえる環境です。
上からこれやってと言われることが少ないので、自分からやることを見つけていく必要があります。受け身な姿勢だと難しいと感じます。キャリアアップでは、はてなではエンジニアのアウトプットを重視されています。ブログ記事を書いたり、登壇なども応援してくれる環境もあります。
今枝：裁量があります。アプリ開発するなかで、技術選定は現場で採用できるのがメリットです。また、会社にはエンジニアの報酬制度があります。OSSのコントリビュートや記事の執筆なども、エンジニア報酬制度では評価される仕組みになっております。
いかがでしたでしょうか、レポートの内容は以上です。
次回のイベントレポートもお楽しみに♪
