こんにちは！アルダグラムでQAのお手伝いをしているmiyashitaです！

アルダグラムでは、「KANNA」というサービスを通して、ノンデスクワーカーの業務効率改善を目標に日々開発を行っています。

普段私はQAとして毎日KANNAに触れ、その中でユーザー目線を持って考えながらテスト設計・テスト実施を行っていますが、「実際に1ユーザーとしてプロダクトに触れる」という機会はあまり持てていませんでした。

そこから、

「ユーザー目線で、自社プロダクトをちゃんと使ってみたいな」

という気持ちが芽生え、ドッグフーディングをしてみようという考えに至りました。
そこで、KANNAで現在提供されている以下の3機能を使用して、自分の業務の進捗管理を行ってみました。

工程表(ガントチャート)
報告
ダッシュボード

本記事では、”1ユーザーとして”自社プロダクトを実際の業務に使ってみた結果、

どんな気づきがあったか
どんな業務改善につながったか

を紹介します。

KANNAでできること

まず、各機能で何ができるのかを簡単にご紹介します。

工程表機能

工程表では、主に以下の作業ができます。

作業内容をタイムライン形式で確認
各作業の担当者確認
各作業ステータスの変更・確認

更に、「予実管理」機能もセットにすると、以下の作業もできます。

各作業で以下の項目値を入力・確認
- 実績作業日（開始日・終了日）
- 計画コスト
- 実績コスト
- 計画進捗率
- 実績進捗率

報告機能

工程表では日次の進捗実績を保存する機能がないため、報告機能で管理します。

以下のように記載することで、その日にどれくらい作業が出来たのか、どれくらい進捗したのかを確認することが出来ます。

ダッシュボード機能

ダッシュボードでは、全体の進捗状況に関する各種数字やグラフを確認できます。

これまでの進捗管理方法

次に比較のため、これまでの進捗管理方法を見ていきます。
進捗管理には主にNotionとスプレッドシートを使っていました。

Notion：タイムライン（スケジュール）

Notionではタイムラインテーブルを使用して各作業のスケジュールを把握していましたが、具体的な進捗率まではパッと出せないため、主に「終わった／終わっていない」ベースでの把握が中心でした。

スプレッドシート：テスト実施進捗率

スプレッドシートでは、テストケースの件数を基にテスト実施進捗率を出していました。

これも進捗管理に非常に大事ですが、テストケース1件当たり何分かかるかはものによるため、工数的な意味合いではこの進捗率をそのまま鵜呑みにするのは少し不安が残ります。

そのため、単純に「残りテスト期間3日で進捗率70％なので順調です」などと言われても、本当にそうなのかイマイチ信用しきれないという課題感を持っていました。

KANNAでの進捗管理

次に、KANNAでの進捗管理方法を見ていきます。
KANNAでは、以下のフローで進捗管理をしていきます。

報告機能に日次進捗を記録
工程表の累積実績値を更新
ダッシュボードで全体の進捗状況を確認

進捗管理方法による比較

観点	Notion / スプレッドシート	KANNA
進捗の精度	件数ベースで粗い	工数・EVMベースで正確
数字の見える化	手動で集計	ダッシュボードで自動
コスト予測	しづらい	指標として確認可能
遅延の予兆	気づきづらい	数値で見える

一元管理と数字の見える化によって得られた業務の質向上と新しい視点

実際に業務の進捗管理をKANNAで行ってみると、ツールが一本化されたため運用が楽になったり、ダッシュボードで進捗を俯瞰できるようになりました。
その結果、新たに見えてきた視点がいくつもありました。

１．進捗率が「より正確な数字」で出る

KANNAではEVMに基づく値がダッシュボードで表示されます。
そのため、進捗率がテストケースベースから工数ベースに変わり、以前まで課題感としてあった進捗率の数値に対する信頼度が格段に向上しました。

特に、以下の数値は進捗確認をする上でかなり気にしていました。

スケジュール差異/Schedule Variance：計画出来高 - 実績出来高
- 進行度合いが計画と比較して巻いている/遅延しているの判断。
  遅延している場合は原因を突き止めるとともに、スケジュールやリソースなどを含めてリカバリを図る必要がある。
コスト差異/Cost Variance：実績出来高 - 実績コスト
- コスト効率が計画と比較して良い/悪いの判断。
  悪い場合は何か生産性が低い要因があるため、早急に原因を突き止めて対策する必要がある。

結果、これらが感覚ではなく数字として握れるようになり、客観的な判断材料になったのが大きなメリットでした。

今のペースは計画に対して進んでいる/遅れているのか
来週以降アサイン人数は増やした方がいい/減らしても大丈夫か
完了までに、あとどのくらいコストがかかるのか

これらはスプレッドシートやNotionでできないこともないですが、フォーマット準備などの工数を考えると、KANNAで必要情報を入れるだけで良いというのは業務効率化ポイントだと感じます。

※EVMとは
Earned Value Managementの略で、プロジェクトが計画した通りに進んでいるかを、期間ごとの計画値（PV）、出来高（EV）、実績値（AC）の積み上げ折れ線グラフ表示によって管理する手法です。
参考：https://products.sint.co.jp/obpm/blog/serial/serial10.html

２．遅延の予兆を早く掴める

毎日ダッシュボードで進捗を確認することにより、日々計画との差分を確認する習慣がつきました。その結果、以下のような傾向も掴めるようになりました。

計画との差分が少し開いてきたから、快調で進められている
段々計画と実績の差が詰まってきているから、効率が落ちる要因があるかもしれない

実際の業務でも、以下のような気付きから原因を突き止め、対策を打つ場面がありました。

特定のテストだけ他より実施効率が悪いことに気づく
不具合が多く起票されているという原因に気づく
不具合起票が遅れることでリリース遅延になる事態を回避するため、スポットでリソースを集中させ、不具合を先に出し切る対策を打つ

これは日々ダッシュボードで数字を見ていたからこそ、早期に対策を打てた事例でした。

ユーザー視点で使ってみて気づいたこと

今回、自分自身がKANNAの「1ユーザー」になってみたことで、“初めて気づいた点” がありました。

● 精度が上がる一方で、休日計算の影響を感じる場面も

コストベースで進捗を確認できる点は非常に便利でしたが、
一方で以下のような点も見えてきました。

稼働日や進捗計算に休日が含まれてしまうケースがあり、実態と若干誤差が生じてしまう
最終予測コストは自分で計算しないといけない

これは、実使用で初めて気づいたポイントで、
“ユーザーとして” の体験から得た大切な気づきでした。
こうした気づきはチームに共有しつつ、今後の改善議論の材料になり得ます。

ドッグフーディングからの学び

今回の取り組みを通じて得た学びは、次の3つです。

1. 予実管理の重要性を実感した

計画 vs 実績を日々見比べることでより正確な進捗状況を把握し、
様々な角度から遅延の予兆を掴めることが分かりました。

2. ユーザー体験を深く理解できた

「ユーザー目線で考える」という視点は普段の業務の中でも意識していますが、
今回実体験を得られたことで、より「ユーザー目線」の解像度が上がりました。

3. 改善ポイントは実運用の中で生まれる

実際に業務に組み込むと、
「こうだったらもっと便利かも」という感覚が自然に湧いてきました。

おわりに

今回の取り組みは完全に個人の実験でしたが、自社プロダクトを業務に組み込むことで、
以前までの業務では得られなかった視点や、定量的な進捗管理のメリットを強く実感しました。
更に、ユーザーとしてプロダクトに向き合うことで、より良いUXとは何か改めて考える機会にもなりました。
これからもドッグフーディングを積み重ねながら、より良い品質のプロダクトづくりに貢献していきたいと思います。

もっとアルダグラムエンジニア組織を知りたい人、ぜひ下記の情報をチェックしてみてください！

Discussion