チムスピ勤怠の導入をしたお客さまが「導入から運用開始までを約１週間とする」ことを目標に、2024年8月にリリースされた「勤怠設定ナビ」の開発プロジェクトを企画したTSF※のPMである奈良さんにお話を伺いました。

※TSF：中小企業向け自社製品を指す社内用語

― なぜ「勤怠設定ナビ」を作ろうと思ったのでしょうか

今回の「勤怠設定ナビ」を作ろうと思ったきっかけは、私がチームスピリットに入社してすぐのオンボーディングでのことでした。 既存の機能について勉強をしていたんですが、初期設定でとても苦戦しました。

特にSalesforceを基盤にしているので、Salesforceやチームスピリットの設定画面がいろんな場所にあり、説明された部分をあれこれ試していたら迷子になってしまいました。

私は前職がSIerで、受託開発だけではなく、場合によっては他社サービスを導入するサポートもしていたので新しいサービスに慣れるのは比較的得意なのですが、それでも難しい。

もちろん、毎日使っていれば慣れるとは思いますが、チームスピリットのお客さまは初期設定が一段落すると、年に数回の組織変更の時しかさわらないことも多いので、毎回大変ではないかと課題感を持ったんです。これが最初の仮説になりました。

ちなみに、開発の施策（社内ではEpicともいう）を考えるときはいろいろなパターンがあるのですが、今回は【仮説】と【データ収集】から始めました。仮説とデータ収集は補完関係にあるので、どちらかが先ではないといけない、ということはありません。

仮説を裏付けるためにいろんな分析をしますが、データ収集や分析の過程で新しい仮説が生まれることも多くあります。

― 奈良さんご自身の経験から、仮説を立てて開発をしようと思われたんですね

そうなんです。
「お客さまが初期設定で苦労している」という仮説を裏付けるために、データ収集をしました。

チームスピリットは年に１度お客さまに顧客満足度アンケートをとります。 フリーコメントなどもあるので、数年分をすべて読み、要素でグルーピングします。また、各種検索サイトの口コミも読みました。
すると全体の母数に対して、相対的に「設定が難しい」というコメントの割合が多いことが分かりました。 これが仮説を裏付けるデータの1つになりました。 また、「設定が難しい」に類似していますが、「使い切れていない」も多い。

でも、本来システムは「使うもの」で、「使わなければいけないもの」ではありません。機能があるからといって必要ないものを無理に使う理由はないはずです。

ここから考えられる仮説は、「どこまでやれば設定が終わるのか納得感が得られない」と「多機能すぎて自分に有益なものの選別が大変」の2つの仮説が派生しました。
前者の仮説は初期設定の施策と合わせて対応ができそうです。後者は使い始めてからのことなので、別の施策に落とすことにしました。
このように仮説とデータ収集を繰り返しながら、よりお客さまに価値を提供できる仮説をたくさん出していきます。

― 仮説が多いと、どれを優先すべきか迷いますね

はい。そのため次は、出した仮説についてどれから取り組むべきか優先順位を決めます。

仮説は緊急度や重要度でざっくり分けますが、それでも緊急かつ重要なことが50や100などのレベルで常にありますし、緊急のトピックスも日々発生します。この中で優先順位を決めないといけません。
そうなると、優先順位は相対的なものになります。仮説の中で一緒にできそうなものをグルーピングして、2個ずつ比べて、どちらがより緊急度と重要度が高く、かつ多くのお客さまにとって効果が高いかを並び替えるんです。

― 100個全部並べるのでしょうか？

全部並べても、また明日には外部状況で優先順位が変わってしまうので、ざっくりトップ5くらいを決めて次の施策の作成に進めるイメージですね。

仮説もそうですが、施策を作ったり、プロダクトバックログ※１に落としたり、開発が始まってからも外部状況が常に変化するので、「今取り組むべき最優先はこれか？」を常に問い続けることになります。

優先順位を決めるためにも、データ収集は基本です。さらに、解約データを確認しました。すると年度別でみた解約率では初年度が多い。初年度解約が多いのは、始めやすくやめやすいSaaSサービスの傾向でもありますか、解約時の理由でも「設定が難しい」が多い。

前職のSIerではお客さまのRFP ※２策定やサービスの評価にも携わりましたが、無数にあるサービスから1つを選定して導入するのは、お客さまにとっては、とてもエネルギーのいる仕事なんですね。 そのなかで選んでいただいたチームスピリットを1年で解約されてしまうということは、仮説の優先順位が高いと判断しました。

なお、データ収集の注意点は「意図的に探すと見たいデータが集まりやすくなる」ことです。あくまで優先順位は相対的なものなので、バイアスがかからないよう、定期的に他にもっと優先順位の高い仮説はないのか大きな視点に立ち返るようにしています。

「言うは易し」ですが、試行錯誤していますね。

※１　プロダクトバックログ：スクラム開発において、プロダクトの改善に必要なタスクが優先度順に並んでいるリスト
※２　RFP：Request for Proposalの略。企業が特定のプロジェクトやサービスを外部のベンダーに委託する際に、提案を求めるために発行する文書のことで、「提案依頼書」とも呼ばれる。

― 優先順位をつけた後は、どのようなステップを踏むのでしょうか

優先順位が高い仮説は、施策（Epic）として企画書のようなものを作ります。
施策の背景や目的、ターゲットとなるお客さま、解決したい課題、解決するための案などをまとめます。また、今回の施策は「いかに簡単かつ短時間で設定を完了できるか」という課題に対し、UIが非常に重要なポイントになります。

ワイヤーフレームを作るために、チームスピリットにどういった設定があり、どの順でナビゲートするかの案を作成しました。
次にそれを持って社内のいろんな方にヒアリングします。例えば、実際にお客さまに接している営業部門の方々に、トライアルのお客さまからどういった質問が出るのかについて、課題になるポイントはどこかをディスカッションしました。

その中で、「打刻からまずは始めたい」お客さまがいることがわかりました。そのようなヒントから、打刻が使えるようになる最低限の設定はどこか、勤怠申請ができるようになるにはどこまでか、という視点で順番をブラッシュアップしました。
（なお、勤怠設定ナビでは打刻、勤怠申請、勤怠データの初期設定をわかりやすくナビゲートしていますので、完了させてから社内展開したほうが、社内展開のアナウンス等がシンプルにできておすすめです。）

他にも、実際に導入をサポートするカスタマーサクセスの部門からもヒアリングをしました。 私も勉強不足で、足りない設定も多々見つかり、さらにブラッシュアップできました。

― 施策を進行するにあたり、難しい部分はどんなところでしたか？

一番難しかったのは設定する順番と、設定項目の取捨選択です。

例えばシステム目線で考えると、実は最初に休暇の種類から設定するのが早いのですが、初めてのお客さまからすると、「とりあえず打刻したいのに、なぜ関係のない休暇を入れないといけないの？」となりますよね。さらに、設定の流れや全体感も掴みづらい。
そのため、あえて最初の手順から外しました。チームスピリットではよくある休暇の種類は入っていますので、それらの休暇を選びやすくすることで対応しました。

また、設定項目の取捨選択についてです。チームスピリットはお客さまの運用にあわせたオプション設定がたくさんあります。その反面、全部の選択肢を最初にみても、お客さまは自社に不要な設定まで勉強しなければならず、負荷がかかります。そのため、ターゲットとなるお客さまを200名以下（注）とし、よく利用される設定だけに絞って表示することにしました。  （注:ユーザー数での制限はありませんので200名以上の場合もお使いいただけます。）

表示した設定には、これまで導入したお客さまがよく利用されているおすすめの設定をいれました。最初の情報量を最小限にすることで、設定時間を短くでき、早く実際に試すことができるので、運用上変えたい設定が明確になります。
追加の設定は必要になりますが、自社では使う予定のない設定まですべて理解してから始めるより、時間の効率がよいと考えました。

課題だったSalesforceの設定とチームスピリットの設定が分かれている件は、勤怠設定ナビから直接開けるようにしました。こうすることで、迷ったらナビに戻れば、すぐに必要な設定画面にたどり着けます。またマニュアルを探すのも手間があったので、リンクで直接表示できるようにしました。多くのお客さまは、本来の業務と並行してシステムの導入をすることが多いので、ステータスも管理できるようにし、別の日でも続きから再開しやすいようにしました。

このように課題や仮説を元に、ワイヤーフレームと実際のモックを作って、何度も社内に展開し、フィードバックを得て作りました。途中からはデザイナーさんにも協力してもらい、デザイン込みで施策を準備しました。

― モックはPMが作るのでしょうか？

必ずしもPMが作るわけではありません。得手不得手もあると思いますが、スピードを考えると自分でできたほうが経験上はスムーズに進みます。

ただ、PMは必要とされている役割が広いので、PMチームの中でも多様性をもって専門領域をカバーし合えるとチームとして強くなります。なので、モックが作れることはPMの必須の要件ではないと思います。

スクラムチームに得意な方やデザイナーさんがいれば、スクラムチームで作るのもおもしろいと思います。

―施策はその後、どのようにして実際に開発していくのでしょうか

施策ができたら、プロダクトバックログに落とし込んで、開発チームに内容を伝えます。PMが主導して動くのはここまでです。

当社ではスクラム開発※を採用していますので、ここからはスクラムチームがメインで進めます。実際に設計や開発業務に入ると、想定外の課題も多くでてきますので、日々キャッチアップして補足するなど、PMもお客さまの代表として議論に参加します。スクラム開発の場合はプロダクトオーナーの立ち位置になりますね。

ここからは、PMから開発チームにバトンを渡して、どうやって「勤怠設定ナビ」ができていったのか解説します。

※スクラム開発：アジャイル開発手法の１つ。さまざまな専門性を持ったメンバーがチームを組み、短期間（当社では2週間）のスプリントと呼ばれるサイクルで開発を進める。各スプリントの開始時に計画を立て、終了時に成果物をレビューし、次のスプリントに向けて改善点を見つけ実践を繰り返す。毎日チーム内で進捗を確認し問題点を共有することで、変化に柔軟に対応しながらプロジェクトを進めることができ、品質の高い成果物を迅速に提供することが可能となる。

― 奈良さん、ありがとうございました！
この続きは、開発編でお届けいたします　―