LLMとデータ駆動でサービスデスク業務の改善サイクルをまわしていく

10Xでコーポレートエンジニアをやっているハリールです。

このブログでは、社内サービスデスク・ヘルプデスクの運用において、問い合わせの受け付けから始まるデータの流れ、そのデータの蓄積方法、そしてそのデータを活用して改善サイクルをどのように回していくかについて、試行錯誤を重ねてきた経験、LLM活用方法、構成、実用的なTipsなどをまとめています。

前提条件

以下のサービスを使って構成しています。 各SaaSの基本的な利用・操作について記載はないためある程度理解している前提での記述となっています。

  • Slack
  • Jira Service Management
  • Zapier
  • OpenAI
  • Looker Studio

全体構成

全体構成としては

  • 問い合わせのI/Fは日常最も利用するチャットツール(Slack)を利用し、ツールのスイッチングコストをかけない。
  • チャットツールで投げた問い合わせはチケット管理ツール(Jira Service Management)に双方向同期し、情報の欠落・重複データを防止。
  • チケット管理ツールにデータが投入されると内容を元に要約・タグ・分類などを自動生成することで属人的な作業を減らし、精度の高いデータを蓄積。
  • 蓄積されたデータをBIツール(Looker Studio)に連携・可視化。定期的な振り返りを実施し改善サイクルを回していく。

といった流れとなります。

SlackとJira Service Managementとの連携

基本的な設定は以下に公式ドキュメントがあります。 www.atlassian.com 上記設定によってSlackの投稿をJira Service Managementに蓄積する構成が実現できます。 それを踏まえた上でのTipsをまとめていきます。

Tips1. プロジェクトタイプ

Jira Service Managementで利用できるプロジェクトは以前までは企業管理型のみでしたが、現在はチーム管理型も作成できるようになっています。 現在10Xではチーム管理型で運用していますが特に大きな課題はありません。それぞれのプロジェクトの特性や相違点については以下を参照ください。 support.atlassian.com

Tips2. Slackチャンネル情報の登録

Slackのメッセージから同期されているJiraチケットへ遷移したい場合、SlackにJiraチケットへのリンクがあるので問題ないのですが、その逆にJiraチケットからSlackメッセージに遷移したい場合には以下の設定を行うことで実現できます。

設定方法はチケットの属性に requesterChannelLink といった名前で文字列型のカスタムフィールドを設定するだけです。 これでJira Service Managementが自動でSlack投稿へのリンクを挿入してくれます。

カスタムフィールド設定
自動で設定される値

requesterChannelLink にはリクエストを受け付けた発言へのリンクが、slackCreationChannel にはチャンネル名が自動で設定されます。 なお、他にどのような属性が指定可能かについては以前まではHalpやAtlassianのドキュメントに記載がありましたが、現在記述がなくなっており、今後この機能がなくなったり、非推奨となる可能性がありますのでその点ご了承ください。

Tips3. Emoji ショートカットAutomation

Jira Service Managementのチャットはその前身であるHalp時代から絵文字リアクションによる操作が特徴でした。 Slack上でチケットの投稿に対して、 👀 をリアクションして担当になったり、完了を意味するリアクションでチケットを完了させることができます。

なお、現在もその設定はありますが、2024年6月4日までにJira Automationに移行させる必要がありますのでご注意ください。 移行の手間はあるものの、利用可能なアクションの範囲が拡大し、様々な操作をリアクションベースのトリガーで実行できるようになったことは、歓迎できる点だと思います。

詳細は以下を参照ください。

support.atlassian.com

チケット属性をLLMで自動生成

チケットが作成されると以下の情報を自動生成しています。

  • 要約/説明
  • タグ
  • 分類

生成はJira(Automation)からZapierを経由してOpenAIを呼び出しています。それぞれの詳細を記します。

AutomationからZapierコール

まずは、対象プロジェクトに課題が作成されるとZapierにWebリクエスト(WebHook)を送信するAutomationを用意します。

Webリクエストの本文はカスタムデータとし、後続処理で必要なデータを設定します。更新時のチケットを特定するためのkeyと、生成元となるsummaryを設定しています。 なお、reporter(報告者)はZapierから再度Jiraチケット更新する際の必須項目となるため設定しています。

これで自動生成の準備ができました。

余談. データに改行が含まれる場合の注意点

上記のカスタムデータは問題ありませんが、例えばカスタムデータで渡すデータに改行が含まれる場合、上記の記載方法では正常にZapierを呼び出すことができません。さらにいうとJira Automation上の検証は成功するがZapierは呼び出されないためなかなか原因に気付きにくいです。 その場合の対応については以下を参照ください。

zenn.dev

要約/説明

続いてユーザーからの問い合わせ内容を元に、要約と説明を生成します。なお、SlackとJira Service Managementの連携では問い合わせの元の文章は自動的に最初のコメントに記録されるため、今回のように加工したとしても元の情報が失われることはありません。 以前までは長文の場合のみコメントに記録されていましたが、いつからか現在の仕様になりました。このほうが便利ですね。 Automationから呼び出されるZapで ChatGPT ActionかOpenAI Actionを選択しますが、どちらを使っても結果に大きな差はないためどちらでもOKです。今回の例ではChatGPT Actionを使います。

まず要約の生成では以下のプロンプトを指定します。10文字程度と指定していますが、稀に改行が含まれてしまいJiraに設定する際にエラーになることがあるため、改行を含めないような指示も加えています。

その他のパラメタ(ModelやMemoryKeyなど)はそれぞれお好みで指定してください。 続いて説明を生成します。説明はJiraチケットの複数行フィールドのため改行は気にせずかつ文字数の制約なども指示する必要はありません。かなりシンプルな指示なためお好みでカスタマイズしてください。

タグ

続いて問い合わせ内容からタグを生成します。以下のような指示で生成しています。カンマ区切りとしているのは、後続のJiraへの反映時にそのまま投入できるからです。

なお、生成されるタグについては、文章によっては想定外のタグ(個人名やメンションなど)が含まれることもあるため、”ある程度雑に生成されたものをチームのデイリーなどで共有しながら手直しする”前提で運用しています。

それでもすべてを手動で付与していくよりははるかに効率的になったと実感しています。

余談. その他タグを使わない

LLMでタグを生成する際、分類できない場合に ”その他” を設定したくなりますが(というか最初はそうしていました)、現在はそのようなプロンプトはやめました。

理由は後続のBIツールで可視化する際に、例えば円グラフなどで件数が少ないものがまとめられるその他と、明示的に付与したその他の判別がつかなくなったからです。

分類

続いて分類を設定していきます。分類は独自に作成したカスタムフィールドであり、問い合わせの内容を文字通り分類するもので”質問”と”依頼”のいずれかから選択します。 以下のようにChat GPTの Classify Text で問い合わせ内容を質問か依頼に仕分けします。

このようなJiraで選択肢があるフィールドはこのままではZapierから投入することはできません。”質問”と”依頼”はJira上ではそれぞれ別のIDを持っており、Zapierから指定するにはこのIDを指定する必要があります。 それぞれの選択肢のIDの値はZapier上から確認できます。ZapierのJiraのアクションから対象のIssueを選択し分類を見ると以下のようになっているのでこの数値がIDとなります。

LLMで分類した値をこれらのIDに変換するためいくつか方法がありますが、今回は Utilities を使います。 Zapier UtilitiesのLookup Tableを使ってChat GPT Actionで生成した文字列をIDに変換します。

項目の追加や削除があった場合にはここもメンテナンスする必要があるため、その点はご注意ください。

これでJiraに設定するための値が出揃いました。

Jiraチケットの更新

要約、説明、タグ、分類が用意できたので、Update Issue in Jira Software Cloud のUpdate Issueを設定します。

IssueにはWebhookで受け取ったKeyを指定します。

要約・説明・タグ・分類には上記で生成した結果を設定します。

最後に 必須項目である報告者にWebhookで受け取ったreporterを設定すればOKです。

これで問い合わせ内容をもとにした自動属性付与の流れが完成です。任意の問い合わせチケットを生成して値の精度を確認しながらプロンプトを微調整してください。 なお、あくまでも生成自体は補助的なものであり、どこかで人がチェックする運用にしておくほうがより安全かつ確実です(特にタグ)。

BIツールに連携

Jira Service Managementに蓄積したデータはそのままJiraのダッシュボードで可視化することもできますが、利用できるガジェットが限られています。またJira以外のデータも含めて横断的に表現できることからLooker Studioに連携していきます。

Step1. Googleスプレッドシートに同期

Looker Studioにデータを連携するに当たってまずはGoogleスプレッドシートにデータを同期させます。方法はいくつかありますが、ノーコードでありAtlassianが公式に提供しているスプレッドシートのアドオンJira Cloud for Sheetsを使います。

JQLで必要なチケットの抽出、列の選択に加えて、定期実行なども設定できます。使い方の詳細は以下を参照ください。

support.atlassian.com

Step2. スプレッドシートをLooker Studioで可視化

スプレッドシートに蓄積したデータをLooker Studioにデータソースとして追加し、あとは任意のグラフを追加して可視化していきます。

これで常に最新のデータで可視化されたダッシュボードが完成しました。このデータを元に、振り返りでは依頼・質問それぞれの件数とタグの割合を見ながらネクストアクションを考えていきます。

例えば依頼の多いタグに関しては、依頼自体を別途フォームとして用意して効率化できないかを検討したり、質問が多いタグに関しては、ドキュメントの在り方・導線・周知方法などに課題がないかを検討していきます。

また、半期・四半期で組織変更時などは特に質問などが増えるなど組織ごとの特性が見えてくるため、それらを織り込んだ作業計画に繋げられます。

余談. 要約リンク

Jiraのダッシュボードの場合グラフをドリルダウンしてチケットの詳細を確認することができますが、Looker Studioの場合そのままでは実現できません。 そこで以下のような計算式のフィールドを用意しシンプルな表を用意すれば、任意のフィルタ条件で一覧化し、かつチケット詳細に飛ぶ流れが実現できます。

HYPERLINK(CONCAT("https://[Atlassianインスタンス名].atlassian.net/browse/",キー),CONCAT(キー," ",要約))

まとめ

ここまで、LLMを活用して問い合わせデータの蓄積を効率化し、改善サイクルを円滑に回すためのデータフローについてご紹介しました。特に重視したのは、データの蓄積と、そのデータを用いた改善プロセスです。このアプローチにより、より効果的なデータ駆動型の施策を検討することができます。

現在もなお試行錯誤を続けており、プロセス自体にはさらなる改善の余地があるものの、このブログが類似の課題に直面している他の組織や個人にとって、役立つものとなれば幸いです。

GitHub Dependabot Alertを愚直に潰し込んだ話

こんにちは、セキュリティチームでソフトウェアエンジニアをしてる@sota1235です。

明けましておめでとうございます!本年も10X Product Blogを何卒よろしくお願いします。

さて、今回はセキュリティチームで今年の6月ごろから取り組んできたGitHub Dependabot Alertの削減についてお話しします。

サマリーとしては以下です。

  • 今年の6月頃から取り組みを開始
  • 初期はセキュリティチームで毎日トリアージ、泥臭くAlertの対応を行う
  • 主要なRepositoryのAlertは一通り解消、一部は担当チームへの移譲等を行い継続的に維持できる状態へ

結果として半年間で500件弱のAlertをcloseし、残ってるAlertも対応方針が全て確定した状態になりました。

この数が多いか少ないかはソースコードの規模感にも依存するので言及しませんが、この記事では小さいリソースで取り組みを始めて、全てのAlertをハンドリングした状態に半年でたどり着いた過程について赤裸々にお話しできればと思います。

続きを読む

もし過去に帰れるならもっと早く導入したかった開発の取り組み

この記事は🎄10X プロダクトアドベントカレンダー2023の22日目の記事です。

21日目の昨日はaineさんによる「プロダクトマネージャーになった自分が大事にしていること」でした。


こんにちは。エンジニアリングマネージャーの坂本(kazu0620)です。

この記事では10XがStailerの開発に取り入れて来た仕組みやルールの中で、「もしも過去に帰れるならこれは早い段階で取り入れたい」と私個人が特に思ったものたちを紹介したいと思います。

過去に帰ることはできませんが、我々と同じようにプロダクト開発を行っている組織の方の参考になれば幸いです。

Stailer最初期の開発と現在

Stailerの開発が始まったは2019年末のことです。私が10Xに入社しStailerの開発に関わり始めた2020年3月の時点では、ソフトウェアエンジニアの数は6名でした。当時はプロダクトマネジメントはCTOであるishkawaが担当し、まだデザイナーや品質管理に携わるメンバーはいない、という状況でした。

ここから3年半で、開発組織は成長し、今ではプロダクト開発に携わるメンバーの数は50名を超えています。これまでの過程で10Xの開発組織は、Stailerのエンドユーザーやパートナーに早く安全に価値を届けるための制約やプロセスを、数多く加えて来ました。下記は特に印象に残っているものを記載してますが、他にも多くの取り組みや試行錯誤があります。

時期 導入したもの
2021年4月 コードレビューの必須化
2021年11月 Desing Docの運用開始
2021年12月 開発チームの組成
2022年 7月 シフトレフト化によるQAプロセスの改善
2022年8月 Stailer開発ライフサイクルの策定
2022年10月 アプリケーション仕様書の確立
2023年1月 ADRの運用開始
2023年4月 ドメインベースの開発体制への移行
2023年5月 技術的意思決定会の開始
2023年7月 SLOの運用開始

ちなみに、開発初期からこれら全てを揃えて開発を進めるべきか、というと私はNoだと考えています。事業もプロダクトも不確かな状態で、初期から制約やプロセスを増やしすぎると結局事業自体が立ち上がらない、というリスクのほうが大きいと考えているからです。特にプロダクト開発の最初期はスクラップアンドビルドを繰り返す必要があり、あまりに早い段階で制約を設けすぎると、事業やプロダクトの生存可能性をかえって下げてしまうというケースもあるのではないかと思います。

プロダクトの複雑さや守るべきものを守れなかったときのリスク度合いなど、さまざまな要素に応じて徐々にプロセスや制約を追加していくべきだと思います。

ただ、それにしてもこれは早く取り入れておけばよかった、もう一度過去に戻れるなら早い段階から導入してみたい、というものもいくつか存在しています。本日はそうしたものを3つ、紹介したいと思います。

Design Docの導入

Design Docは、システム設計のデザインを記述するものです。永続的にメンテナンスするもの、というよりは、実装に入る前に設計を議論しレビューするためのツールとして10Xでは利用しています。フォーマットはデザインごとに任意ではありますが、以下のような項目を記載することが多いです。

  • 目的
  • Goals
  • Non Goals
  • 選択肢とPros / Cons
  • アーキテクチャ
  • テストやモニタリング、リリースのプラン

Design Docは2021年11月に導入したのでStailerの開発が始まってから2年を経て導入した、ということになります。その2年間の間にも、10Xでは重要なシステムの意思決定を数多く行なって来ました。

Design Doc導入前も設計上気にかかる部分があれば他のメンバーと相談したり、レビューを依頼したり、といったことはしていました。

しかし、やはりフローやフォーマットが正式に存在していることによる敷居の低さ、「これくらい複雑な設計ならDesign Doc書いた方が良いな」という心理が働くことから、Design Doc導入前に比べると設計に関する議論やレビューは盛んになっています。

また、設計に関する議論が実装前・リリース前に行われることにより、コードレビューで大きな手直しが入ることや、ベストではない設計でリリースしてしまったがゆえに負債となってしまう、といったようなことを防ぐことができていると感じます。

こうした恩恵を考えるとDesign Docは、任意かつフォーマットが軽量なものでもよいので、開発初期から取り入れていてもよかったな、と今振り返れば思えます。

ADRの導入

ADR(Architecture Decision Records)は、アーキテクチャや開発プラクティスに関する意思決定の内容や背景を記録し共有するためのドキュメントです。Design Docは設計を考える上での議論に使うフロー型のドキュメントであるのに対し、ADRは決定事項をメンテナンスし続けるストック型のドキュメントになります。

ADRは、以下のようなフォーマットに沿って記載します。

  • 意思決定のコンテキスト
  • 決定内容
  • 影響
  • コンプライアンス(決定をどう遵守するかの方針)

ADRの効用として、チームにとって何が標準であるのか・なぜその標準が存在しなければいけないのかが明らかになる、というものがあります。後からチームに参画するメンバーのことを考えると、これは非常に大きな恩恵があります。

加えて私は、標準・ルールを適用したり変更するためのプロトコルが明確である、という恩恵も同じくらいあると感じています。現在の開発スタイルだったりアーキテクチャに怪しさを感じていたり危機感を持っていても、それを変更するためのプロトコルが明確でない場合、どうしても対応が後手に回るものです。

近い話で、ADR導入の少しあとで始めた「技術的意思決定会」という取り組みも似た効力を発揮しています。これは、技術的な意思決定権を持ったCTOであるishkawaがオーナーとなり、技術的な相談や意思決定を行う、という会議体です。毎週開催され、メンバーが意思決定したいこと・意思決定まではいかないけど相談したいトピックを登録しておき、関心あるメンバーとCTOが議論し、技術的な意思決定をします。

ここでの議論内容がADRとして起票される、という流れになることが最近は多いです。いきなりADRを起票しても良いのですが、事前に同期的に会話可能な場所で相談と合意を経ることができることから、技術的な意思決定に関わる敷居を下げられているのではないかと思います。

このように、決定があとから閲覧可能なものとして残っているだけでなく、アーキテクチャや技術的な方針をどこで相談しどう適用すればよいのかが明らかである、プロトコルが定まっている、というが非常に重要なことではないかと思います。

ADRを導入したのは2023年の1月なので、Stailerの開発開始から約2年と少し後ということになります。これまでの間も技術的な意思決定は10Xの中で多くなされてきましたが、もっと早くこうした仕組みがあれば、早く意思決定を行い良い変化をプロダクトにもたらすことができた可能性はあるな、と思います。これらも少なくとも開発開始から1年後くらいの段階では、軽量でも良いので取り入れていてもよかったのではないかと思います。

シフトレフト化によるQAプロセスの改善

これは、品質管理部の仲間たちが推し勧めてくれた大きな成果です。従来、Stailerの開発はで完成した仕様書をもとに品質管理チームのメンバーがテスト設計を作り、QAプロセスを実施する、という流れでした。

これを2022年7月ごろから、仕様書が確定する前に品質管理のメンバーが仕様書をレビューする、仕様書を作る前の時点から品質管理のメンバーが関わりフィードバックする、といったように徐々にシフトレフト(早期に問題発見する)という動きが進みました。

現在では品質管理チームのメンバーは開発チームの中に入って、仕様が定まる前の段階から仕様がどうあるべきかについてプロダクトマネージャーやソフトウェアエンジニア、デザイナーと一緒に議論を進めています。

これにより、リリース前のQAプロセスで発見されるバグ・あるいはリリース後に発生するインシデントの数を削減ことができました。リリースされたあとよりもリリースする前に問題を発見する方が、開発が完了したあとよりも開発が開始する前に問題を発見する方が、対応にかかるコストはずっと低くなります。

これは、先に挙げたDesing DocもADRも、ある種同じ話であるとも言えます。工程を悪戯に増やすのはプロダクトが立ち上がったばかりの状態では悪手とも思われますが、できるだけ早い工程で問題を発見し、改善するための手を打つことは、小さな組織でもスピードを上げることにつながります。

そういう意味で、これらの3つは仮に過去に戻れるならばまだプロダクトや開発組織の規模がより小さいときから導入したいな、と個人的には思えるものです。

早くやりすぎても成功しなかったかもな、と思うもの

一方で良い取り組みではあったものの、もっと早いタイミングでやったとしてもうまくいかなかっただろうな、と思うものもあるので、補足として紹介しておきます。それは、ドメインベースの開発体制への移行です。これはドメイン(業務)ごとにチームを分割するという組織設計上の試みで、2022年12月から検討を開始し2023年4月に実施しました。

振り返ればStailerというシステムが扱う業務の領域が幅広いこともあり、扱っている業務とシステムの解像度が高まり、朧げにでもどういうドメインの切り方が存在しているのかが明らかになって来たのが2022年半ばのことでした。

Stailerの開発を開始した2019年時点ではStailerの扱う業務の全体像を見通すことは非常に困難だったし、開発開始から1年が経過したタイミングでもまだプロダクトも事業も大きく変化している最中で同様、業務の全体像や業務ごとの関連を見通すのは困難な状況でした。

あまりに早い段階でこうしたチーム構造をとることや、それに応じてドメイン理解が浅い状態でチームごとにモジュール化を進めることは、おそらく混乱や手戻りを生んだだろうなと個人的には思います。

この移行の意思決定を行なった時点では、チームの認知負荷は増大しており、またコードのオーナーシップも持ちづらい状態ではあったのでギリギリとも言えますが、前述の理由から例えばこれをあまりに早くやったとしてもあまり幸せな結果にはならなかったのではないかと思います。

終わりに

ここまで読んでいただき、ありがとうございました。開発に関して必要となる制約やプロセスは、事業の状況やチーム状況に応じて変わるもので、少なければいいというものでも多ければ良いというものでもないのが難しいところだなと思います。

10Xでもこれからまた状況が変わるにつれて、無くなる制約もあれば加わる制約もあると思います。この記事を読んで、自身のプロダクトや組織にはいつどんな制約やプロセスを設けると良いかな、と思いを馳せていただければ幸いです。

続けていたことをやめること、新しいことをはじめること

この記事は🎄10X プロダクトアドベントカレンダー2023の20日目の記事です。

19日目の昨日はogaさんによる「プロダクトチームとCSの連携のお話」でした。


こんにちは、品質管理部のtarappoです。

2023年も終わりですね。

唐突ですが、はじめたことをやめることってむずかしかったりしませんか? はじめたときには目的があったものの、気づいたら惰性で続けてたりしませんか?

1年も終わりが見えてきて「大掃除だ」「棚卸しだ」と動いてたりすると思うので、今日はそのような話にフォーカスしたいと思います。

品質管理部がおこなっているメイン以外のタスク

メインでおこなっているタスクについてフォーカスして話すのもよいのですが、文量が長くなりそうなのでメイン以外のタスクについて話していきたいと思います。 品質管理部ではメインとなるタスク以外にもいろいろなことをおこなっています。

例えば、次のようなものを定期的におこなっています*1

  • 入社時の品管主催のオンボーディング
  • 品管週報

これらは当然、目的があってはじめたものです。

はじめたころから時間が流れていくと、当初の狙った目的が達成できていたり、その目的を達成するにはこのアプローチは異なるといったことが起きてきます。 そういった中で、現状を元に続けるべきかどうかを定期的に考えていますしメンバーからFBをもらうこともあります。

はじめたものは惰性で続けてしまいがちではありますが、これらにはメンバーの時間を一定使っています。 そのまま継続することは関係する人々にとっての時間の無駄使いにもなってしまいますし、見直すことは重要です。

この1年の間にやめる選択をしたもの

この1年間の間に、品質管理部でやめたこととして次のようなものがあります。

  • ドヤ会
  • 品管週報

それぞれには次のような目的がありました。

名前 内容 目的
ドヤ会 部内でメンバーのドヤ!とした出来事を共有する会 だれがなにをおこなったかをチーム間で共有(チームビルディングが目的)
品管週報 週1回、品管メンバーがおこなったことを全体に共有する報告書 品管がどういったことを行なっているか部外の人に知ってもらう(品管の認知向上が目的)

かんたんな目的は上記に記載したとおりです。 もう少しそれぞれについて詳しく次に記載します。

ドヤ会

ドヤ会においては、部内のメンバーの交流の一環としておこなっていました。 誰がどういったことをおこなったかというのをメンバー間で共有する場を用意することで「それいいね」と気づいてもらいやすくするというのもありました。

実際におこなっていた期間は約8ヶ月ほどになります。

それだけの期間がたつと、上述した役割の必要性がなくなったと判断し終了することとなりました。

品管週報

品管週報においては私が入社したタイミングで認知向上の目的でどういったことをおこなっているかをアナウンスするためにはじめたものです。

まだチーム*2が出来て日も浅くどういったことをしているのかというのが知られてないというのがありました。 また、今みたいにチームに入って動いていたわけではなかったため何をいまおこなっているのかというのも分かりづらいというのもありました。

次のような形でNotionに毎週週報を作って全体にSlackで共有していました。

最初にやったこととして次のブログ記事にも書きました。

この品管週報は、金曜日に週1回出し続けて次のVol.80が最終号となります。

最近は次のようなコンテンツで出していました。

コンテンツの内容はたまに見直しし更新はしていましたが、80号ともなると惰性感は出てきていました。 また、開発チーム体制になってからはチームに品管メンバーが必ずいるため当初の目的である認知度向上は達成できただろうということでやめることとしました。

残された課題とその先

上述したものについては、目的の多くは達成したことからやめたわけですが、全てではありません。 従って、残された課題はあります。

品管週報においては「認知度向上」が目的でした。 まずは品質管理部というものを知ってもらうというのがありました。

知ってもらう必要性はなぜか?というと「全員で品質を作っていく」ための第一歩とするためです。 「認知」されなくてはその先の「協業」はありません。

そのため残された課題は、本来の大きな目的に対してどういったアプローチが必要かということになります。

新しいことをはじめる

上述したように残された課題はあります。 従って、その課題を解決するという目的にフォーカスした新しいことを2024年からはじめる予定です。

新しいことをはじめたとしても、それが目的からずれてしまったり、達成したのであれば見直しは必要です。 それを肝に命じながら2024年も、また新しいことを「恐れずに」いろいろとやっていこうと思います。

おわりに

今回は品質管理部がおこなっているメイン以外のタスクについて話しましたが、メインのタスクにおいても同様です。 継続し続けることが必ずしも正しいとはかぎりません。

継続は大事ですが、いつしか惰性となってしまうこともあります。 そして、はじめることよりも止めることの意思決定のほうが大変だったりします。

しかしやめることは大事です。

2023年の1年間で品質管理部もだいぶ変化しました。 その中で取り組んできたことをやめたり、新しいことをはじめたりとしています。

2024年はどういったことを進めるのか、2023年度はどうだったのかについてはまた数カ月後にブログ記事にかければと思います。

*1:メインとなるタスク含め定期的におこなっているものはリスト化しており、定期的に棚卸しをしています

*2:入社当時は品質管理部ではなくQAチームという形でした

10XでProduct Fridayという社内発表会を運営している話

この記事は🎄10X プロダクトアドベントカレンダー2023 の17日目の記事です。

16日目の昨日はkazk1018さんによる「Data as a Product」について考える でした。

こんにちは、10XでProduct Managerをやっておりますkeiです。本日は10Xで行っているProduct Fridayという取り組みについてご紹介します。

Product Fridayとは

もともと「開発共有会」という名の開発で共有した知識により全体のパフォーマンスがあがるものを定期的に共有できる場があり、エンジニアリング本部(SWEやQAを中心とした組織)により運営されていました。それをこの4月からプロダクト本部(PdMやDesigner, データプロダクト)と合同で運営することとなり、趣旨は引き継ぎつつ職種を超えて(主に開発に関わる)知見を共有すること、コミュニケーションを促進すること、発信カルチャーを醸成することを目的に開催しています。

  • 頻度は隔週金曜の16-17時
  • 1枠15分くらいで最大3名の発表(短くても可)、形式は自由
  • 立候補制(ローテとかではない)
  • Audienceの参加は自由、おやつ代の補助あり

Happy Friday的なカジュアルな意味合いも込めてProduct Fridayと命名しました。4/28に第1回を開催してからもうすぐ開催される12/22まで延べ15回、計45の発表がありました。

実際にあった発表例

  • UIとUXの話をしよう - デザイナー採用面接でのWSをやってみる -
    • FigJamを使ってその場で仮想サービスへのツッコミと質疑をやってみるというインタラクティブな発表で、大変盛り上がりました
  • PdM×デザイナコラボでモブ業務フロー一緒にやったらとても良かった話
    • PdM x Designerでラジオ風に業務フローを作ってみる(再現)という斬新な発表で、質問もおハガキ紹介という徹底ぶりでした
  • お届けチームのダッシュボードを作った話
    • パートナー毎のシステムメトリクスや生産性、リリースした機能がどう使われているか?開発スプリントの可視化まで、いかに「定期的に見られる」ダッシュボードを構築するかという観点で非常に参考になりました

やってて良いと感じること

知見の共有

まずは趣旨どおり、10Xに在籍する各種メンバーから知見を共有してもらえるのが良きポイントで、アンケートでも「SWE以外の方の発表を聞けるのが新しい気づきがあってよい」や「他のチームの知見がたくさん聞けて学びが多い」といった感想が集まっています。

コミュニケーションの促進

また、新入社員のメンバーには自己紹介LTをしてもらっており、As-One Mtgという全社定例での自己紹介もありつつ(5分)、より深い自己紹介をプロダクトに関わるメンバーにできることで業務上話す際にもアイスブレイクに繋がっているようです。

運営の流れと難しさ

運営は私を含む3名で行っており、週にかける時間は30分程度というイメージです。開催〜次回までの運営の流れでいうとざっくりこんな感じです。

  • 事前準備
    • 発表者への準備リマインド
  • 当日
    • BGMを流す(Youtube)
    • 録画をする
    • Product FridayのSlackチャンネルでワイワイを促す
    • 積極的に質問をする
    • おわりにアンケートを案内する
  • 次回に向けて
    • 開催翌週の火曜に30分の運営定例を実施
    • KPTしたり次回までのToDoを確認する

難しさとして感じるのは大きく2点で、これからも課題だなと感じています。

1. コンテンツの安定提供

コンテンツを安定的に提供するためにはコンスタントに発表者が集うことが必要なわけですが、立候補にも波がありコンテンツが少なくなってきたときは運営が声掛けを頑張っています。

普段の業務の中でも「これProduct Fridayで発表してみよう」「これはProduct Fridayで聞いてみたい!」みたいな会話が運営を介さずとも自然に発生するような状態が理想かなと思っています。

2. 発表しやすい空気づくり

回を重ねていくと発表のリピーターも出てくるため、発表者のUXは大変重要です。当日の運営としてもチャンネルを盛り上げたり、なるべく質問をしたりするものの、リアクションが見えにくかったという声もあったり課題に感じています。

運営だけでなく空気は参加者みんなで作るものなので、なるべくビデオOnにしたりリアクションを送ったり(10XではGoogle Meetを使っています)、気軽に発表できる空気をつくっていきたいです。

おわりに

最後までお読みいただきありがとうございました!プロダクト組織に所属されている方の参考になれば幸いです。

明日18日目はむらなかさんによる「データ分析はプロダクトの機能の一部である」の予定です!お楽しみに!

SREとして入社し1年たつので振り返り

こんにちは。SREの栗原です。 この記事は10Xアドベントカレンダーの15日目の記事です。

私がSREとして2022年の10月に入社し1年が経ちました。 この1年間でやってきたことについて書いていきます。 現在SREチームは採用募集中です。この記事を見てスキルがマッチしていたり興味が湧いた方は是非カジュアル面談をしましょう!

SRE(Site Reliability Engineer) / 株式会社10X

  • 入社初期の取り組み
  • 自動化と効率化への取り組み
    • Terraform moduleへのresource追加
    • Redashやめる
    • Kubernetes yamlのコピペ運用をやめる
    • サービスアカウントキーの発行方法の見直し
  • 育休の取得
  • その後の取り組み
    • Deny policiesの導入
    • Terraform Planの権限修正
  • これから
続きを読む

GitHubの監査ログを定期的にexportして保存する

こんにちは。セキュリティチームでソフトウェアエンジニアをしてる@sota1235です。

この記事は10Xアドベントカレンダーの13日目の記事です。

www.notion.so

昨日の記事はSuzuki Ryotaさんのお届けチームでオーナーシップを持っていくぞでした!

今回はGitHubの監査ログを定期的にexportし、保存する仕組みを作った話をします。

  • 監査ログとは
  • GitHubの監査ログ
    • GitHubの監査ログは永久には保存されない
    • 監査ログの出力方法
    • この記事の本題
  • 監査ログ出力の仕組み
    • ざっくり要件
    • 技術選定
      • ログの保存場所
      • ログの取得処理
      • ログの取得・保存処理はGitHub Actionsで行う
    • 全体像
      • 1. BigQueryに最新データを取得しに行く
      • 2. 監査ログを取得する
      • 3. 監査ログを保存する
    • 権限管理
      • 監査ログに含まれるデータについて考える
      • 具体的にどこに制限をつけるか
    • 今後の活用方法
  • 最後に
  • 明日は
続きを読む