Qast品質宣言とサービス品質向上への挑戦〜カスタマーバリューファーストの品質定義〜
こんにちは！ナレッジプラットフォーム「Qast」を運営するany株式会社 CTO波多野(@hatamasa1988)です。
2024年になって最初の執筆です・・・泣
今回は、前回書いた「サービスを創るエンジニア」でも少し紹介した「Qast品質宣言」についてです！
anyエンジニアキャッチコピー「サービスを創るエンジニア」がすんなりとチームに馴染んでいったので、「Qast品質宣言」も馴染むはずと思っていましたが、実はまだ浸透途中であります。
anyの開発メンバーにも向けて「Qast品質宣言」とは何なのか？なんで作られているのか？を書いていきたいと思いますのでよろしくお願いします！
前回の「サービスを創るエンジニア」はこちら ↓↓↓
プロダクトフィロソフィー
Qast品質宣言に関わるプロダクトフィロソフィーから説明します。
プロダクトフィロソフィー（哲学や思想）は、企業のミッションやビジョン、バリューと密接に関連しており、製品開発の方向性を定め、チームメンバーに共通の目標を提供します。また、顧客に対しては、その製品がなぜ存在するのか、どのような価値を提供するのかを伝える重要な要素となります。
anyではプロダクトフィロソフィーを「ユーザーにとってQastがどんなサービスであるべきか」と簡潔に定義しています。
Purpose, Vision, Mission, Valueはany株式会社としての定義。
プロダクトフィロソフィーはQastとしての定義です。
Qastは
つながっていく、ちょっと気が利く、迷わない。こんなサービスでありたい。心理的安全性、高まる、日常的存在、活気がある。これらを感じられるサービスでありたい。をベースに最終的に下記をプロダクトフィロソフィーとしています。
1.1のラストワンマイル
ユーザーフレンドリー
助け合い、讃え合い、知を響かせる
Qast品質宣言
話は本題に入り、この宣言は「価値ナラティブ」に当たるかと思います。
Leading Quarityは宣言した後で読んだのですが、ナラティブ=語られ方で、それを元に理想と現実のギャップを埋めていくという行動面にも触れられてました。
Qast品質宣言には下記の2つの目的があります。
「サービスを創るエンジニア」を体現するため
プロダクトフィロソフィーに沿った開発を支援するため
この2つの宣言が目標としているものはサービスレベルの向上です。
さらにプロダクトフィロソフィーでどんな価値をユーザーに提供するのかを説いています。
狩野モデルで説明すると、Qastはエンタープライズ企業が全社ないし事業部などをまたいで使うツールであり、「当たり前品質」のレベルがかなり高いです。
この「当たり前品質」を分解すると、バグがない、直感的なUIである、サクサクな使用感、などなどもはやそれは感覚としては「魅力的品質」なのでは？と思わせるくらいの品質が求められます。
そのためには、エンジニアメンバーの意識統一として、何をするにもコードを越境した「サービス品質」にまで目を向ける必要がありました。
そこから品質とは？その関連は？を整理し「内部品質は最終的にサービス品質（顧客価値）に紐づくもの」という考え方の布教を始めました。
Qast品質宣言は一つの俯瞰的な図と内部品質宣言、外部品質宣言の2つの宣言で構成される予定です。
下記の図では、それぞれの品質がどのように影響を及ぼして合っているのかの図を定義しています。
国際規格SQuaRE（ISO/IEC 25000、JIS X 25000）に定義されているソフトウェア品質の図をベースに置き換えて起こしたものでチームに説明しています。
サービスを提供している上でこの構造の理解はとても大切だと思っていて、
まずサービスとしての体験（外部品質）があり、その次に内部品質（コード品質）を重要にしようというリソースが限られたスタートアップの優先順位の話です。
ただここでミスリードしたくないのは、内部品質は必ず顧客価値に紐づくので蔑ろにしてはいけないとしてカスタマーバリューファーストを徹底し続けていくということです。
内部品質宣言
次に、内部品質は外部品質(=顧客価値)に影響を与えるものとして継続的に向上するとして下記の3つの考え方を説いています。
1. 内部品質は”個人のため”ではなく、”外部品質のため”にありサービス品質に影響を与える
2. “ベストプラクティス”や”綺麗なコード”から考えるのではなく、”チーム”や”サービス”への影響から考える
3. “個人へ依存する”のではなく、”仕組みとプロセス”で“個人の努力”をサポートする
内部品質を向上することにより開発生産性を向上して間接的な外部品質向上と開発スピード(=顧客価値)を維持することを目標に、開発者が増えても開発生産性を落とさない状態を目指します。
また、生産性の担保を仕組みやルールで行うことで属人化を防ぎ持続可能な開発プロセスを確立しようという取り組みです。
開発生産性は一年位前からOffersMGRという開発指標の分析や可視化ができるツールを導入しています。
FourKeysやサイクルタイム分析、Githubの指標を継続的にチェックしながら、数値に変化があった時に技術負債や設計で変更がしにくくなっていないかなど内部品質との関連を考えていければと思います。
仕組みの部分では、PRの「運用ルール」と「心得」を定めました。
ただPR運用ルールがあるのではなく、大上段に前述した品質の考え方があることでレビューの位置付けが明確になります。
「運用ルール」の目的はPRプロセスの時間短縮と効率化、チームパフォーマンスの向上として、PRの作成方法、コメントラベル運用、レビュー依頼~修正~マージ方法などをまとめました。
その中で特に重視しているのは、レビューの迅速化とPRの適切な分割、および明確なコミュニケーション戦略を記載しています。
「心得」の目的はチーム全体のコード品質の向上とプロジェクトの効率化として、チーム開発におけるマナーや根底にあるべき行動指針を示しています。
良いコードレビューの重要性と、レビュワーがレビューしやすいように心がけること、適切なコミットの管理、セルフレビューの実施、レビューコメントの品質維持、さまざまな観点からのレビュー実施、効果的なレビュー修正方法などを記載してます。
外部品質宣言
TODOです（すみません🙇）
まずはQast品質宣言と内部品質宣言が浸透してきたのをみつつ、後々定義しようと思っています。
今後の取り組み
現在、このQast品質宣言をもとに下記の施策を走らせています
Datadog導入によるサービス監視の強化
APMツールのでの内部リソース監視
レビュー運用ルールの定期的なブラッシュアップ
また今後は
責任ナラティブ、テストナラティブの定義
外部品質宣言の策定
DevOpsの浸透
CI/CDの充実
QAスキルを持つメンバーの教育/採用
などを取り組み、品質向上に向けて更にギアを踏んでいけたらと考えています！
さいごに
エンジニアキャッチコピー「サービスを創るエンジニア」、プロダクトフィロソフィーに近づくためにサービス品質の向上は欠かせません。
エンジニアであってもプロダクトだけではなく、より大上段である"サービス"について考えていくことが、プロダクトを中心としたサービスレベル向上につながるのではないでしょうか？
今後一緒にサービスを成長させていきたいという、我こそは"サービスを創るエンジニア"だ！という方は転職意欲関係なくカジュ面しましょう！またランチとかもいきましょう！
カジュ面はこちら👇
DMはこちらまでお待ちしております！
それではまた！
いいなと思ったら応援しよう！
