ヴェルク - IT起業の記録

受託開発と自社サービスの両立への取り組み

board(SaaS)の開発内容の決め方(2021年版)

boardの開発内容をどのように決めているか、というのを書いてみたいと思います。

2021年版と書きましたが、たぶんここ4〜5年くらいは大体同じようなスタンスでやってきました。

boardについて

boardの現在の状況は以下のような感じです。

  • boardは、見積書・請求書の作成から業務管理・経営管理などを行うことができるサービスで、主に数人〜数十人規模の小規模な会社がメインターゲット
  • 2021年9月現在の有料導入社数は3600社ちょっと
  • 弊社は現在10名の会社で、board関連へのアサインは、自分含めエンジニア4名、サポート3名
  • 営業や広告などはせず、基本的にインバウンド頼み

基本的には、どんどん範囲を広げていくのではなく、ターゲットを絞りつつ、「幅広い会社に70点のサービスではなく、フィットする会社に90点のサービスを」というスタンスで開発・運営しています。

 

開発ロードマップ

boardでは、半年ごとに開発ロードマップを公開していて、基本的には、半年間はその内容に沿って開発します。

自分がプロダクトマネージャーでもあるので、開発ロードマップの内容は、基本的にはほぼ自分が決めています。

 

要望の管理

サポート窓口に頂いた問い合わせは、毎日、すべて自分(=boardの責任者)が目を通しています。その中から、要望に該当するものは、Trelloに入れて管理をしています。

Trelloでは、1つのカードが1つの開発トピックになっています。コメント欄に問い合わせのURLを登録して、開発の際に問い合わせのやり取りをすぐに確認できるようにしたり、対応した際には連絡ができるようにしています。

現時点で、Trelloに入っているカードの数(=要望のトピック数)は1500件を超えています。また、その中に複数の問い合わせがあるので、要望の問い合わせ数は数万件といった数になるかと思います。

このように、膨大な数の要望・開発候補があるため、1つ1つの要否というよりは、優先順位を決めて「取捨選択」になります。この「取捨選択」にあたって、どのようなことを行っているか、という話を書いていきます。

 

開発ロードマップの決め方

毎年、12月に1月〜6月の開発予定、6月に7〜12月の開発予定を決めて公開しています。

要望は前述のTrelloにすべて入っているので、6月と12月に入ったら、まずは数回、一通り全部の要望(Trelloのカード)を見ていって、どういった要望があったかを見返します。

毎日すべての問い合わせに目を通しているため、どういった要望が多いか、どういった課題感があるかなどは、常に頭に入っていてアップデートされています。ただ、こうやって見返すことで、「小さいけど重要なもの」や「たまたま最近少なかったもの」などの見落としを拾えます。

また、どうしても「直近で声が大きい要望」の印象が残りやすく、これに影響されてしまうと、適切な判断ができなくなってしまいます。そういった影響をリセットするためにも、一通り見返していくのは大事なプロセスになっています。

 

4つ要素のバランスを取る

自分の中で、開発する内容は、大きく以下の4つに分かれます。

  • 要望が多い(ニーズが多い)機能追加や既存機能の改善
  • 中長期的な世の中の流れや業務改善の方向性
  • boardとしてやりたいこと
  • 既存機能の細かい改善

なお、これに加えて、たまに法改正対応があります。たとえば、2019年の令和対応や消費税率変更・軽減税率対応、2022年の改正電子帳簿保存法対応、2023年のインボイス制度対応などがあります。

法改正対応は、期限が明確に決まっているものなので、これがある場合は、まずはこれを優先してスケジューリングします。それ以外については、上記の4つの要素を、半年ごとにバランス良く配置するのを基本としています。

要望が多い(ニーズが多い)機能追加や既存機能の改善

単純に要望の多さで決めているわけではありませんが、やはり要望が多いものはニーズが多いものなので、重要な判断基準のひとつとしています。

一方、いくら要望が多くても、boardの方針・思想と合っていないものは、対応しないようにしています。もちろん可能性はゼロではないですが、サービスの設計思想やターゲットまでを変えるのか、という論点になりますので、通常の機能追加とはレベル感が数段異なります。

たとえば、よくあるケースですと規模の違いによるニーズの違いです。boardは、数人〜数十人規模の小さい会社をターゲットにしているサービスなので、会社規模が大きくなるにつれてニーズが高くなる機能追加・改善については、優先度は低めになります。

この枠の判断においては、「幅広い会社に70点のサービスではなく、フィットする会社に90点のサービスを」というスタンスが重要な役割を果たします。

中長期的な世の中の流れや業務改善の方向性

これは、中長期的にサービスとしての価値を継続する上では最も重要な要素と考えています。

boardのような販売管理の分野のサービスの場合、対外的なやり取りを含み1社に閉じていないため、SaaS単体で商習慣に基づく業務のやり方をガラッと変えるような大きな変化を起こすことは、簡単ではないです。そのため、基本的には既存の商習慣・業務をベースに、その一歩先を提供し続けていくことが重要と考えています。
*そういう意味では、業務を根本的に変えてしまうようなSaaSはほんとすごいなと思います。

この「一歩先」の判断はすごく難しいですが、バックオフィス系のアーリーアダプターな人たちが、どういったものに注目しているか、どういった意見を言っているか、問い合わせやTwitterなどからそういう情報を拾っていき、日々、頭の中でシミュレーションしています。

あまり早すぎると、アーリーアダプターしか使わない、予測が外れた、という状況になりがちです。うちは前述の通り小さい会社でリソースも限られているため、アーリーアダプターをターゲットに、「業界で1番早くこの機能を実装した」というポジションを狙っていくことは厳しく、もう少しニーズ・流れが明確になってから実装することが多いです。

最近の例だと、boardからクラウドサイン・DocuSignへ連携できるようになった機能があります。

boardでは、発注書や検収書など、お客さんから受領する書類を作成することができるので、たとえば「見積書と発注書をクラウドサイン経由で送付・締結することで、発注書を回収する」ということができます。

クラウドサイン立ち上げ時の中の人が知り合いだったこともあって、初期の頃からクラウドサインを使っていたため、この構想自体は2017年くらいから持っていたのですが、世の中的に、電子契約サービス自体が浸透していなかったので、さすがに早すぎるなと。

その後、電子契約サービス自体の認知も高まり、身の回りで徐々に増えていき、問い合わせの方にも、「電子契約サービスとの連携」という要望を徐々に見かけるようになりました。

2019年にもかなり有力な候補の1つだったものの、令和対応・消費税対応の影響で見送りとなり、そういった中で、昨年(2020年)にコロナ禍で急に在宅勤務が増えたことで、「より受け入れられやすい状況になった」「今後ニーズが増えていく」と考え、対応しました。

コロナ禍直後は、「取り急ぎ請求書の発行業務を自宅からできるようにしないと」という目の前の課題といった問い合わせが多かったものの、ある程度落ち着いた後は、「今後の業務をどうしていくか」という視点の問い合わせも増えてきました。そういった中で、この電子契約サービス連携はかなりフィットした印象です。

このように、早すぎず、でもこの後必要になってくるであろうことをやっていくのがこの枠になります。

boardとしてやりたいこと

2019年のカラーユニバーサルデザイン(色覚特性を踏まえた色への変更)対応、2020年のセキュリティー割引(2段階認証必須またはSSOのみにしている場合は月額料金を5%割引)などがこれにあたります。

tamukai.blog.velc.jp

tamukai.blog.velc.jp

これらは、これによって直接的に売上が増えるようなものでもないですし、うちみたいに広報活動をほとんど行っていないと、うまくマーケティング・ブランディングに繋げていくこともできないのですが、「世の中がそういう方向性になっていくと良いな」と思うようなことをやっているような感じです。

この枠で、インフラ関連の強化など、表に見えない部分の改善・強化などを行うこともあります。

また、要望の対応と絡めて、大きめの改善・機能追加の際に、「対象の機能を完全にゼロから書き直して、メンテナンス性の向上、自動テストの整備など、内部的な開発のしやすさの改善」などもセットで行うこともあり、これもこの枠として位置づけています。

既存機能の細かい改善

開発ロードマップに公開しているトピックは大きなトピックだけですが、デプロイはほぼ毎週行っていて、それらの多くは「既存機能の細かい改善」になります。

開発ロードマップに記載はしていないので、半年ごとにきっちり決めているわけではないですが、開発ロードマップを決める際に、優先度の高めの改善はピックアップして、「この半年で対応したいもの」を整理しています。

これは、主に以下のような内容が多いです。

  • そこそこ問い合わせがあるが少し改善すれば問い合わせ自体を減らせるもの
  • 自分で使っていて、使いにくい・わかりにくいと思うもの

社内では「問い合わせをなくす(減らす)ための改善」という言い方をよくしているのですが、ちょっとした文言の変更、配置の変更、簡単な挙動の変更で、問い合わせが激減したりします。

問い合わせをせずに済むということは、ユーザーさんの使い勝手としてもプラスになります。

また、うちは「会社をどんどん大きくはしていかない」「会社の人数は10人が目安」というスタンスでやっているので、ユーザー数の増加に伴い問い合わせ数が増加していくと、サポートがパンクしてしまいます。そういう意味でも、問い合わせを減らせるための改善はとても大事になってきます。

ちなみに、問い合わせに基づく細かい改善は、サンプル数が少ないと改善の方向を見誤る可能性があります。そのため、気になる問い合わせがあったら、その方の他の問い合わせの傾向、書き方やニュアンスの癖、職種・立場・業界など、様々な要素を踏まえて、どういう背景でこういう問い合わせをしてきているのかを想像するようにしています。

また、特定の人や問い合わせからの意見を直接的に採用するという感じではなく、もう少し主観的な要素を落とした上で考えるようにしています。

 

最終的な取捨選択

前述のようなことを踏まえて、最終的に、開発ロードマップに載せる数の2〜3倍程度のトピックを最終候補としてリストアップします。

その上で、

  • boardとしての優先順位付け(主に、思想・方向性などを元に)
  • 他の開発予定の機能との関係性(並行してやりにくいものは避けるなど)
  • 既存機能や既存ユーザーへの影響の度合い(影響が大きいものが重ならないようにするなど)

などを考えて選択していきます。

 

余談ですが、最終段階で落選したものが、その次の半年の有力な候補になるように思うのですが、意外と、毎回候補には挙がりつつ落選し続けるものとかがあったりして、自分でも興味深いです。

 

まとめ

元々、3年ほど前までは、自分がすべて問い合わせ対応をやっていたこともあり、「問い合わせが改善の源泉」というスタンスが非常に強いです。

一方、サービスの軸がぶれないようにするためには、一部の問い合わせに、短期的な影響を受けないようにすることもとても大事だと思っています。

「xxxを強く要求します」みたいな強いテンションの問い合わせを頂くケースがたまにあって、とくに初期の頃は、かなり影響を受けがちというか、それの位置づけが非常に難しかったです。

そういう中で、開発ロードマップを公開している役割は非常に大きく、また、要望の対応方針も公開しているので、これらをもって、短期的な影響を受けずに、「中長期的に何をやっていくか」を安定して考えられる環境を作っています。

開発ロードマップは半年ごとに公開していますが、その半年間、もっというと数年単位で、基本的にはずっと「次に何をやるか」を考えています。

膨大な要望があるので、それらをすべて対応することはできず、むしろ対応できないものの方が圧倒的に多いです。

たまに「なぜこれを対応してくれないのか」「対応していない理由を説明してほしい」という問い合わせを頂くことがあるのですが、「対応していない = 不要と考えている」わけではなく、また多くの場合「対応しない理由」があるわけでもなく、ただ、膨大な候補の中からできることは限られているため、「取捨選択」になるんですよね。

その取捨選択の精度が、サービスの発展に繋がる大事なポイントなので、ある特定のタイミングで「さあ、次に何をやろうか」という感じで考えているわけではなく、断続的にずっと考えています。

とはいえ、自分の頭でずっと考えていても方向性を間違える可能性があるので、毎日必ず問い合わせを見ているのは、その情報のアップデートやズレの是正だったり、Twitterでバックオフィス系の人たちのツイートを見て、世の中の流れを見ていたり。

そういうことをずっと継続していると、開発ロードマップを決めるタイミングでは、判断に必要な情報は集まっていて、それに加えて、見落としや直近の問い合わせに影響されないように、前述のように、すべてを何周か見返すというのを行うようにしています。

何か手法とかルールとか、そういう体系化されているものはまったくないんですけど、サポートの中で感じる温度感・問い合わせ内容・業務知識や経験・自分としての課題感・世の中の流れなど、そういったものを総合して、バランスを取りつつ決めていく、という感じです。

 

現在、カスタマーサポートのメンバーを募集しています。少しでもご興味があれば、お気軽にご連絡ください。

tamukai.blog.velc.jp