品質と新規開発のバランスというタイトルで登壇してきました

こんにちはカミナシでアプリケーションエンジニアをやっている沼田( @keinuma15 )です。先日行われた Startup Issue Gym #1【開発プロセスのIssue】にて「品質と新規開発のバランス」というタイトルで発表してきました。

概要

スタートアップのプロダクトは成長していくにつれて様々な課題にぶつかります。その中でも0→1から1→10フェーズに変化すると既存機能を改善しつつ新機能を開発していく課題が出てきます。今回はカミナシがこの課題どう立ち向かっているのか共有させていただきました。

speakerdeck.com

プロダクトの成長による課題の変化

プロダクトはフェーズに応じて目指しているゴールと課題が変わってきます。

カミナシは2019年12月にピボットして今のプロダクトの開発を開始しました。当時は0→1のフェーズだったため、顧客のどの課題を解くのかやソリューションを考え実現する必要がありました。そこから2020年6月に正式リリースしたのが「カミナシ」です。

カミナシは現場で働いてる全ての業界を対象としたアプリで記録業務をできるプロダクトです。開発を開始して半年ほど経つと次第にユーザーが増え始め、既存機能だけではカバーできていない領域が増えてきました。ユーザーにより価値を届けるためには新機能を開発しないといけないが、すでに提供している機能を改善する必要も出てきました。

狩野モデルとプロダクト開発

新機能と既存機能の開発のバランスをどうとってきたかを説明するために狩野モデルについて紹介させていただきます。

狩野モデルは品質の種類とそれらの顧客の満足度の関係性を示したものです。グラフには3種類の品質が書いてますが、元のモデルには5種類の品質が定義されています。

名前	充実した時の満足度	不足した時の満足度
魅力的品質	満足	不満足にはならない
一次元的品質	満足	不満足
当たり前品質	満足にはならない	不満足
無関心品質	満足にはならない	不満足にはならない
逆品質	不満足	満足

狩野モデルの品質をプロダクトに合わせて考えると魅力的品質が新機能、当たり前品質が既存機能と見ることができます。

カミナシにとって新機能は前例のプロダクトが少なく、ユーザーに提供してから業務に機能が組み込まれフィードバックが来るのに1,2ヶ月かかります。一方で当たり前品質は、カミナシを導入する前は紙を利用して業務を行なっているため運用が止まらないことが前提になりやすいです。そのため高い当たり前品質を維持する必要があります。

これらの特徴を踏まえた上で、カミナシがそれぞれの品質にどうアプローチしてきたか紹介させていただきます。

カミナシの戦い方

カミナシは魅力品質と当たり前品質において以下の作戦を立てていました。

魅力的品質：隣接した業務領域をカバーする
当たり前品質：機能の再構築

魅力的品質

カミナシのメイン機能がカバーしている業務領域は作業後のチェック業務です。

チェック業務はその後の集計、改善まで含めて効果を発揮します。チェック業務だけカバーしていても紙の電子化に留まってしまい、ユーザーに価値を届けきれてないです。そのため、チェック業務の次の工程にある集計業務を新機能として開発しました。

ここからは新機能を開発するフローと同じです。カミナシでは最初にユーザーに現状の業務と課題をヒアリングし、どこに痛みがあるのかを把握します。その結果、集計業務では分析・報告書・システム間連携の主に3種類あり、紙からEXCELファイルに転記しているため作業量が多い課題が存在することがわかりました。

次に3種類の業務をどういうソリューションで解決するか検討します。当時はそれぞれの業務ごとに機能を開発することと業務に関係なくユーザーがカスタマイズできる機能が候補にありました。魅力的品質は改革の性質を持っていますが、カミナシではなるべく元の業務とのギャップを小さくするようにしています。そのため、集計業務として記録したデータを任意のEXCELで出力できるEXCEL変換機能をリリースしました。

当たり前品質

当たり前品質を下げる大きな要因として内部品質とUX品質があります。 UX品質はスタートアップのプロダクトの場合、作りっぱなしで放置されていると低くなりやすいです。

開発当初に想定していた仮説をもとに開発したものの、実際に使い初めてもらうと思っていたものと違うと感じる時があります。カミナシでは当初想定していた仮説の間違いを正して、機能を再構築してきました。

具体例にダッシュボード機能を上げさせていただきます。

カミナシのダッシュボードは予定されていた記録が行われているか確認する機能です。

当初の仮説では記録できていない数を知りたいと仮説をおいていたのですが、使いこなしてくれるユーザーが少ない状況でした。そこでユーザーがどういう情報を知りたいのか声を集めたところ、どの現場でいつできてないのかを知りたいことがわかりました。この学習をもとにダッシュボード機能を再構築し、どの現場でいつできてるかをOX表で表現してリリースしました。

当初はできてない現場が多くXが増えるのではないかという懸念がありましたが、現場の状況がわかりやすくなったというフィードバックをいただいてます。