ヴェルク - IT起業の記録

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

boardで多様な色覚に配慮したカラーユニバーサルデザイン(CUD)認証を取得した話

2019年5月19日から、board内で使われている色を調整し、色弱・色覚特性などと称される色覚「P型・D型」の方にも識別しやすい配色にしました。

こういった取り組みが、多くの製品・サービスで行われるようになれば良いなと思い、経緯や実際に行ったことなどを紹介したいと思います。

 

今回の取り組みは、NPO法人「カラーユニバーサルデザイン機構(CUDO)」に検証を依頼し、問題のある箇所は修正後、無事、同機構が発行するカラーユニバーサルデザイン(CUD)認証を取得することができました。

ちなみに、CUDOさんによると、請求書作成・販売管理・会計・SFAなどの業務支援システムとしてこの認証の取得は初めてらしいです。

 

カラーユニバーサルデザインとは

現在日本には、割合が最も多い一般色覚「C型」の他、色弱・色覚特性とも称される色覚「P型・D型」の方が男性の約20人に1人、女性の約500人に1人の割合で、計320万人以上*いるとされています。

カラーユニバーサルデザインとは、こうした多様な色覚に配慮し、より多くの人が対象を識別しやすいように配色されたデザインの呼称です。

*出典:特定非営利活動法人カラーユニバーサルデザイン機構

 

今回の取り組みの経緯・背景

以前から「日本人男性の20人に1人」という割合は知っていました。

boardは、見積書や請求書の作成などの販売管理分野を扱うサービスですが、5%の割合であれば、当然、ユーザの中にP型・D型の方もいるはずなので、ここ数年、どこかのタイミングで対応したいと考えていました。

ちなみに、単純に比較するものではないですが、2019年5月時点のboardユーザのブラウザ別の割合を確認すると、

Firefox:4.53%
Edge:4.21%

なので、「20人に1人」という割合は、決して無視できる数字ではないなと。

ただ、対応するにしても、「実際にどう見えているか」というのはわかりません。協力してくれる方がいないと対応が難しいため、頭の片隅にはありつつ、数年経ってしまっていました。

 

そんな中、昨年、board内の色合いを少し変えた際に、β版の頃から使って頂いているシャムロック・レコードの青木さんからフィードバックを頂き、その話の流れで、カラーユニバーサルデザインの話になりました。

シャムロック・レコードさんは、UDトークという音声認識と自動翻訳技術を使って会話・スピーチをリアルタイムに文字化・翻訳するアプリを開発していて、UDトークは外国人対応や聴覚障害者対応などで使われています。

そういった背景もあり、システムにおけるバリアフリーについてよくご存じで、NPO法人「カラーユニバーサルデザイン機構」をご紹介頂き、今回の取り組みがスタートしました。

 

元々この対応は、開発ロードマップにもなく突然出てきた話で、とくに今年は、改元・税率変更・軽減税率対応と、期限が決まっているイベントが目白押しで、他のことをやっている余裕はなかったのですが、こういうのはタイミングが大事だと思うので、やることにしました。

 

board上で色の識別に意味がある箇所

boardには、案件一覧の受注ステータス、ダッシュボードでのアラートや売上分析のグラフなど、色で意味を識別できる箇所があります。

たとえば案件一覧の場合、下図のように色分けされていますが、これは「受注ステータス」ごとに色分けされています。

f:id:fw_tx76129:20190510143450p:plain

上記のように、主要なステータスは色で簡単に判別できるようになっていて、もちろん識別できなくても使えるのですが、識別できた方がよりわかりやすくなります。

また、グラフは、色の識別ができないと区別がつかないので、これは必須ですね。

 

余談ですが、担当の方と話していた中で「グラフはできれば模様が異なる方が良い」という話があって思い出したことが1つあります。

僕はアメリカの大学に行ってたのですが、授業の中で「グラフは色だけでなく、模様で判別が付くようにしないといけない」って言われてたのを思い出しました・・・。

欧米だと10人に1人の割合らしいので、もっと一般的だったんですね。当時は全然理解していませんでした。

 

検証と対応の進め方

検証は、P型・D型に加え、一般色覚のC型を含めた3名の検証員が行います。

全画面に対して、各色覚を持った3名の検証員全員が色の違いを識別できるかという確認をしていきます。

パンフレットなどと違い、システムの場合は動的に表示が変わる点が難しく、「スクリーンショットでの検証」と「実際の画面を操作しての検証」の2ステップで進めました。


スクリーンショットで検証

まずは全画面のスクリーンショットを撮り、スクリーンショットベースで確認してもらいます。

この際、同一画面で複数の表示が切り替わるケースなどもあるため、スクリーンショットは126ファイルになりました。

 

スクリーンショットベースで検証された結果の指摘事項は、たとえば以下のようなものでした。

f:id:fw_tx76129:20190510144038p:plain

f:id:fw_tx76129:20190510144058p:plain

f:id:fw_tx76129:20190510144112p:plain

 

当然、こういう視点でフィードバックを頂くのは初めてで、これらのフィードバックを受けて、以下のようなことがわかりました。

  • 色数はできるだけ少ない方が良く、色に意味がない場合は統廃合していく方が良さそう。
  • 赤はオレンジが入っていると識別できるようになる。
  • 隣接する色によって見えたり見えなかったりするため、データの状態に応じて色が変わる箇所が難しい。
  • 既存ユーザに配慮して「現在の色の系統を維持する」必要があり、それが難しい。

 

検証の結果、NGだったものについては変更案を頂いて、それを反映してみるところから始めるのですが、これがなかなか苦労しました。

とくに「現在の色の系統を維持する」のは大きな制約になり、またデザインの方針として選べないものもあります。そのため、提案してもらった色をそのまま使えないケースもあり、その場合は、その色を元に調整した案を数パターン作成し、再度そのスクリーンショットを確認してもらうという流れで色を決めていきました。

また、この際、闇雲に色を調整しても難しいため、「色のシミュレータ」アプリを使って、P型・D型での見え方を確認しながら調整しました。

色のシミュレータ

色のシミュレータ

  • Kazunori Asada
  • 教育
  • 無料

なお「色のシミュレータ」アプリで問題なくても検証でNGとなることが何度かあったので、とくに見えるか見えないかギリギリのラインの場合は多少見え方に差はありそうです。

 

色を変更したスクリーンショットを再度検証してもらい、識別できたものとその優先順位(見やすい順)を教えてもらい、その中から、boardの方針として採用可能な一番優先順位が高いものを選択していきます。

たとえば、一覧画面のステータスに応じた色の場合、以下のようなパターンを作りました。

f:id:fw_tx76129:20190510144313p:plain

この結果、すべて合格ではあったのですが、見やすさの順番として、3→2→4→1→5とのことでした。

候補3や候補2は、一般色覚のC型にとっても見やすくとても良いのですが、ステータスに応じて色分けしていたものなので、色で覚えている方も多いはずで、「緑」だったものが「青」になってしまうのは避けたいと考えていました。

そのため、「緑」の系統を維持できる候補4を採用しました。

 

実際の画面で検証

動的に動く部分、マウスオーバーで表示される部分などもあるため、スクリーンショットベースでの検証がOKになった後、実際に画面を自由に操作しながら検証してもらいました。

実際の画面を操作して検証した結果、指摘があったのは、たとえば以下のようなものでした。

<一覧上のアイコン>
一覧の背景色とその上に表示されるアイコンの組み合わせによってNGになるものがありました。

f:id:fw_tx76129:20190510144512p:plain

 <注意を促す赤文字>
下図のような注意を促す赤文字が黒に見えている状態でした。

f:id:fw_tx76129:20190510144526p:plain

<折れ線グラフのプロットの大きさ>
折れ線グラフのプロットが小さくて見にくい状態でした。

f:id:fw_tx76129:20190510144540p:plain

ちなみに、この際に説明してもらったのですが、大きさによっても識別可否が変わってくるようです。

<ヘルプでのステータス別の色の説明>
ヘルプで、下図のように「言葉」で色を表現しているものに対してもNGの指摘がありました。

f:id:fw_tx76129:20190510144634p:plain

このヘルプの記述に関する指摘は目から鱗でした。全く考えたこともなかったのですが、言われてみればその通りですよね。

そのため、以下のように変更しました。

f:id:fw_tx76129:20190510144753p:plain 

変更箇所の例

実際に変更した具体例をいくつか紹介したいと思います。

一般色覚のC型にとっては微妙な違いで、見比べないとわからないものもあるのですが、逆に言えば、既存の色の系統を維持しながら対応できるということでもあります。

<一覧画面のステータスに連動した背景色>

f:id:fw_tx76129:20190519130519p:plain

#e2eddd #e4f3e9
#faf6e2 #fdf8e1
#efe1e1 #efdbe0

 

<ダッシュボード>

f:id:fw_tx76129:20190519130542p:plain

#da7373 #e27e55

 

<グラフ>

f:id:fw_tx76129:20190519130556p:plain

#87b87f #96c392
#6fb3e0 #83b8db
#fee074 #f2de74
#d15b47 #d97652
#af4e96 #7d3a77

 

対応してみた感想

今回の対応をするにあたって、「既存の色を軸に近い色で調整することは可能」とは聞いていたのですが、それでも「既存の色が大幅に変わってしまうのではないか」「デザイン的なバランスが大きく崩れるのではないか」という懸念は少なからずありました。

 

ただ、変更前後の画像を見比べて見ると、一般色覚のC型にとっては大きく違わないものも多く、ほとんどの場合、既存の色の系統を維持しつつ、対応することができました。

そして、そのちょっとした違いで、P型・D型の方が識別できるようになります。

 

*ちなみに、1箇所だけどうしても個人的にしっくりこない箇所はあるのですが、僕以外はみんな新しい色の方が見やすいと言うので、諦めました・・・。既存ユーザからネガティブな反応があるとしたら、ここではないかなあと思っています。

 

また、この対応をする前は「P型・D型の方でも見える色を使う」のだと思っていたのですが、「他の色との違いを識別できる色を使う」ということなんですね。

たとえば、P型は赤が黒に見えるようなのですが、これをオレンジ寄りの赤にすることで、黒との違いを識別できるようになるようです。このような形で調整をするため、既存の色の系統をなるべく維持するということができます。

 

一度こういう取り組みをすると、とくに色にこだわりや決まりがなければ、考慮した色を使おうという意識になります。

たとえば、このブログ記事に出てくるスクリーンショットに入れている赤枠・赤文字は、黒に見えないよう、赤に少しオレンジが入っている色を使っています。

今回の対応に伴い、boardのヘルプのスクリーンショットを差し替えて行く必要がありますが、その際に、すべてこの色を使っていくつもりです。

 

ただ、正直なところ、落としどころの色を決めるのはかなり大変でした。

CUDOさん側も想定していたよりかなり大変だったようで、申し訳ない気持ちなのですが、具体的には以下のような点が大変でした。

まず、既存ユーザに配慮し「色の系統を維持する」のはやはり大変で、最初から対応する場合は、もっと色の選択肢も広がるし、より良い色の選択ができたなと思います。

それから、データの状態によって色が変わる箇所があり、それにより色の組み合わせが変わり、隣接する色によって、見える見えないが変わってきてしまいます。これは、システムがカラーユニバーサルデザイン対応する場合の難しいところだなと思いました。

また、boardはもともと色数が多めで、それも大変な要因のひとつでした。

 

ということで、カラーユニバーサルデザイン対応をする場合は、最初からやるのがオススメですが、なかなかサービス開始当初からそこにリソースを割くのは難しい気もするので、なるべく使う色の数は少なめに抑えておくと、やりやすいかもしれないです。

 

正直なところ、今回の対応で、どれだけの方がどのくらい使いやすくなるのかはわからず、見え方の違いなので僕自身は確認しようがないのですが、これによって少しでも使いやすくなる方がいれば良いなと思います。

また、一般色覚のC型の方にとっては、大きな変更はなく、最初は気になるかもしれませんが、すぐに慣れるレベルで調整できたのではないかなと思っています。
*実際の反応はこれからなので、まだなんとも言えませんが・・・。

 

ちなみに余談ですが、一般色覚のC型でも、人によって色の見え方は違うとされていて、それを体感する出来事がありました。

今回の対応は、実際に対応していたのは僕ではなく別のエンジニアだったのですが、2人の間で、変更後の印象が全く違ったのが面白かったです。

僕が「グラフの色合いが変わったのは全然気にならないけど、案件一覧の色が明るくなって、緑が青寄りになったのがとても気になる」って言ったら、「え!?グラフだいぶ違いますよね?むしろ案件一覧はあまり・・・」って素でびっくりされて、お互いに「え!?」みたいな状況になってました。

今回の中でわかったこととしては、僕はややくすんだ色が好きらしく、普段からそういうチョイスをしていて、その系統の色はしっくりくるのであまり気にならないっぽいです。

デザインは素人なので、実際のところはどうかはわからないですが・・・。

受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入2000社に行くまでの振り返り

2019年5月7日に boardの有料契約が2000社を突破したので、振り返りです。

boardのβを公開したのが2014年5月11日なので、β公開から約5年で2000社まで到達しました。

ちなみに、2000社までの推移はこんな感じ。

f:id:fw_tx76129:20190512094002p:plain

 

1000社までの振り返りは「受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入1000社に行くまでの経営・受託とのバランス(BPStudy発表時の補足)」に書いたので、今回は1000社から2000社までの間を中心に書きたいと思います。

 

1000社から2000社は、約1年半だったのですが、この間はほとんど外にも出ず、ほぼ開発とサポートに注力していました。

そして、boardとしての進め方がある程度固まったというか、自分の中で迷いがなくなった期間でした。

元々あまり迷わず、決めたことを淡々とやっていくタイプなのですが、「うちの会社やboardはこういうスタンスでいいんだな」というのが自分の中でしっくりきたというか、自信を持って言えるようになってきた気がします。

 

ひたすら開発・サポートをやっていた1年半

この1年半はとにかくこれに尽きます。

これはうちの体制的な問題が大きかったのですが、2016年にサポートで採用した人がうまく仕事にフィットせず、2017年にCSのマネージャークラスで採用した人が合わなくてすぐに辞めることになってしまいました。

その結果、1300社くらいまで僕が1人でサポートをやっており、かつ、boardのメイン開発者でもあったので、開発・サポート以外は何もできない状況でした。

2018年3月にサポートで1人入社し、そこから半年は、みっちり付きっきりで教え込んでいました。

boardのサポートでは「boardのCSで大事にしているスキル」にあるようなことに取り組んでいて、要求水準をかなり上げているので、入社してから最低でも半年はかかるイメージで、通常のサポート対応に加え、育成面でかなりリソースを割いていました。

 

ちなみに、前期(2017年12月〜2018年11月)の僕の交通費の経費精算回数が年間で1桁と、たぶんベンチャー社長でトップレベルにどこにも行っていないのではないかと思うレベルで、そのくらい開発とサポートにかかりっきりでした。

ということで、この記事では「こうやって2000社まで伸ばしました」という話は出てきません・・・。

 

boardとしてのやり方

サービス開始後の2年ほどは、検証を兼ねて広告を出したりもしてましたし、集客するにあたって必要なことを見聞きして試すということを繰り返していました。

しかし、弊社に営業やマーケティング担当がおらず、かといって、資金調達をしているわけではないので、先行投資的な採用はできませんでした。

基本的には受託のエンジニアの会社だったので、集客すること・売ることにリソースを割いていたら、回らないなという感じでした。

また、boardは月額980円〜の低価格なサービスなので、広告はペイせず、継続的な手段としては難しいという判断になりました。

そのため、ここ数年は広告も出さず、表立ったマーケティング活動もせず、基本的に口コミか検索からの流入がメインという状況です。

この状況について、「これでいい」と自分で納得するまでには時間がかかったなと思います。

やはり、マーケティング活動したり、広告出稿したり、売るための活動をしていかないといけない、という危機感というか、そういったものは少なからずありました。

 

もちろんやれることはやった方が良いと思ってます。

ただ、リソース的にはできないものはできないし、すべてが中途半端になっても意味がないので、割り切って「やらないこと」を決めていきました。

*ちなみに、この辺りは先日の「明日の開発カンファレンス2019」の発表資料に詳しく書いています。

 

これができた背景としては、

  •  受託で食べていけているので、自社サービスの売上は急がない
  • 当初は自分の1人プロジェクトで、かつ自分自身、受託で必要な売上も上げてたので、他のメンバーに負担もかからない
  • boardへの他のメンバーのアサインは、boardの売上で賄える範囲でやる

という方針でやってたので、売上を伸ばすことを急がなくても大丈夫な持続可能なスタンスでした。

こういった背景から、開発とサポートという、サービスのコアな部分だけに注力していくことになり、また、そうせざるを得ない社内体制でも、迷うことなく注力できました。

 

最近よく言っているのですが「とくにB2Bの場合、多くのユーザはちょっと良い程度だと有名な方を使う」と思っています。

そのため、うちのような無名の小さい会社の場合は「ちょっと良い」ではダメで、「明らかに良い」である必要があるという思いが根底にあります。

それは、仕様・設計・使い勝手・パフォーマンス・安定性・CS・使い始める前の期待値と実態のギャップなど、サービスに関わるすべてというか、ユーザ体験に関わる要素すべてのイメージです。

「良いものを作れば売れる」という時代ではないのは重々承知ですが、小さい会社は、明らかに良いものを作らないと土俵に上がれないんですよね。

それが自分の中ではっきりしたことで、「とにかく開発とCSに注力する」ということに迷いがなくなりました。

 

ちなみに、こういう話を書くと「それで事業として成長できるの?」って聞かれるのですが、1ヶ月の新規有料登録は一昨年が40〜50社前後、昨年が60〜70社前後なので、一応成長スピードも上がってます。

また、有料の退会率もずっと1%以下を維持していて、着実に成長はできているので、急がば回れで強固な土台を作っているイメージですね。

スタートアップ的な急成長を目指しているわけではないので、プロダクトを中心に、時間がかかってもしっかりとした土台を作っていく方法もありかなと思っています。

 

これからやっていくこと

最近「10人の会社で有料1万社が使うサービスを目指す」と言っています。
これは、具体的な数値目標というよりは、人手をかけないサービス運営のための旗印ですね。

それを実現するため、これまでのスタンスは変わらず、より効率的な運用をするための取り組みをしていこうとしています。

さらなる完成度の向上

基本的な方針として、機能の○×では勝負しないので、守備範囲をどんどんと広げていくことは考えていません。

小さい会社は質で勝負していかないと土俵に上がれないと思っているので、今boardが扱っている領域を中心に、さらに完成度を高めていく方針です。

品質管理

現状でもバグや障害の少なさを評価頂くことが多く、品質に大きな課題があるわけではないですが、少人数でより安定したサービス運営をしていくため、品質管理に投資していく方針としており、2018年から本格的に、自動テストの整備などに取り組んできます。

ちなみに、現状7名という規模の会社ですが、専任でQAエンジニアを置きたいと思っているので、興味がある方がいたら、まずは気軽な感じで話を聞きに来て頂いたり、Twitterで話しかけてもらえたらと思います。

SRE

これも品質管理同様、少人数で安定したサービス運営をしていくために、今後、本格的に力を入れていこうとしている分野です。

ヘルプのさらなる改善

現状、350記事ほどあってかなり充実しており、ヘルプの充実を評価頂くことも多いのですが、昨年11月に、元々フリーランス編集者をやっていた者がCSとして入社したのをきっかけに、ヘルプの改善に取り組んでいます。

仕組みとしては下記のようなものを準備し、現在少しずつ、ヘルプの見直し・改善を進めています。

あとは、検索結果の向上など、よりストレスのないスムーズなヘルプにしていこうと思っています。

 

まとめ

「boardのやり方って再現性ないよね」ってよく言われるのですが、「こうやったらうまくいく」みたいな銀の弾丸はないので、自分たちやターゲットなどをよく把握した上で、何をすべきかを考えるようにしています。

とくに自分たちのことをよく知ることは、とにかく大事だと思っています。

 

また、「開発に注力」というと「一点突破」といった印象を持たれることも結構あるのですが、それは少し違っていて、システムだけに限らずサービス全体の「ユーザ体験」を良くするためのことはかなり労力をかけてやっています。サポートやヘルプが良い例ですね。

そして、開発もサポートも「人」がやるので、「人」の本質的なスキルそのものを上げることにかなり軸足を置いています。

 

SaaSのKPIは社内で一言も出てこないし、社長は開発とサポートで引きこもっているなど、よく聞くSaaSのやり方とは大きく異なりますが、うちはスタートアップではないし、 こういうのもひとつのやり方としてありなんじゃないかなと思っています。

ということが、言えるようになった1年半でした。

 

ヘルプの校正をtextlint・prh・CircleCIを使って自動化する

boardのヘルプは、Githubで管理し、プルリクエストを使って編集・校正を行っています。

ざっくり以下のような運用になっています。

  • 新規のヘルプは、僕が書いてプルリクエストを出し、編集者がチェックする
  • 既存のヘルプは、編集者が気づいた点を随時修正してプルリクエストを出し、僕が内容をチェックする
  • 所定のブランチにマージされると、ステージング環境・本番環境に自動的に反映される

これについては、以前詳しく書いたので、興味がある方は下記をご覧ください。

tamukai.blog.velc.jp


実際に運用していて、この仕組みはとても気に入っているのですが、せっかくここまで仕組みができたので、もう一歩進めて、機械的にチェックできるところは、編集者の時間を使わずにチェック・修正をしたいなと考えました。

文章の場合、機械的にチェックできるのは、たとえば、以下のようなものです。
・「とくに/特に」のように漢字・ひらがなの表記
・「ブラウザ/ブラウザー」のように長音の有無

編集者(@note103)がCS(サポート)として入社したことをきっかけに、ヘルプやサポートの中で使う表記を統一していこうという話をしていて、彼にそういったルール作りしてもらう予定でした。

今回、それを自動化しようという取り組みです。

エンジニア的にはrubocopやeslintなどがあるので、それの日本語版ですね。

 

最初は自前でそういう仕組みを作ろうと思っていたのですが、textlintprh (proofreading helper)というものがあることを知ったので、これを使うことにしました。

 

仕組みの概要

textlint・prhを使います。

textlintには様々なプラグインがあるのですが、すでにヘルプだけでも350記事ほどある状態なので、まずは最低限の表記揺れのチェックから始めることにしました。

表記揺れのチェックはprhを使います。@note103に定義を作ってもらい、それに違反したものは、下記のようにエラーになります。

  25:25  ✓ error  予め => あらかじめ  prh
  36:4    ✓ error  例えば => たとえば  prh
  67:24  ✓ error  全て => すべて  prh

 

eslintと同じように、--fixで自動修正も可能です。

手元でtextlintを実行しても良いのですが、それだと忘れがちだし、問題ないことを保証できません。

以前のブログで紹介したように、ヘルプはGithubで管理しているので、ソースコード同様、プッシュしたらCircleCI上でtextlintを実行するようにしました。

違反しているものがあれば、エラーになって通知が来るので気づくことができますし、Githubのプルリクエスト上でもCircleCIが通ったかどうかの確認ができます。

CircleCIでtextlintが通るところまでは、プルリクエストを出す人の責任範囲として運用しています。

 

ヘルプやお知らせ記事など合わせて約650記事あったので、まずはそれらを全て通す必要があり、後からこういう仕組みを入れると、これが面倒なんですよね・・・。

幸い、自分の普段の書き方と@note103のルールが似ていたのと、textlintの自動修正がきれいにできたので、さくっと修正できました。

また、masterブランチへマージすると自動的に本番環境へ反映するようになっているので、反映の手間もかからず、この辺の仕組みを整備していてよかったなあという感じです。

 

まとめ

文章を書くにあたって、ルールを整備しておくことで、読みやすさや統一感というのはもちろん、書く人が迷わずに済むメリットもあります。

そのため、元々ルールを整備したいとは考えていたのですが、今回、自動化までできたので、表記揺れなどの機械的なルールは一切考える必要がなくなりました。

また、そういったことに編集者の頭を使う必要がなくなり、「読みやすくてわかりやすい文章や説明」に注力することができます。

社内に編集者がいるとはいえ、本業はサポートなので、編集の仕事ばかりやってもらうわけにはいかず、編集の仕事は1日1時間としています。

そのため、こういった自動化のメリットはとても大きいです。

10人の会社で1万社が使うサービスを目指す」のブログに書いたように、人数をどんどん増やしていくつもりはないので、自動化できるところは自動化していくというのは、システムに限らず、取り組んでいきたいと考えています。

boardのCSで大事にしているスキル

boardはβリリースから約4年ほどは、ほぼ僕が一人でサポートをやってきました。

昨年前半にCS専任のメンバーが入り、一年ほどかけてスキル移管をしつつ、徐々に体制をシフトさせていっているのですが、その過程で、boardのサポートで最も重要なスキル・大事にしているスキルが、自分の中で明確になってきたので書いてみたいと思います。

 

boardのサポートについて

boardは、見積書・請求書作成を中心とした業務管理・経営管理のB2BのSaaSです。

そのため、問い合わせは主に「○○という業務をやろうとしているけどどうすればいいですか」「○○という機能はありますか」などの使い方・機能の有無や、業務に合わせてどういった使い方をしたらよいか、といった質問が多いです。

サポートはチャットのみで、電話でのサポートはやっていません。
*チャットはintercomというサービスを使っています。

現在、有料導入社数は約1900社で、それをCS二人体制で余裕を持って運用できています。

また、サポートの回答時間の中央値を公開していて、2015年11月以降、10分以下を継続しています。

ユーザさんからは、「今回もさすがです。短期間で解決に辿り着けました。最高のサポートでした!」「こんな情報が少ない質問で的確に切り分けして頂いて、ありがとうございます!」などのようなコメントを頂くなど、それなりに評価して頂いていると思っています。

あとはこんなことを言って頂いていたりします。

どちらのコメントも開発者としてもとても嬉しいのですが、CSとしては 「サポートの的確さ」というのはとても嬉しいですね。

 

boardのサポートの一つの強みは、やはり僕自身がやっていたことは大きく、同時に大きな課題でもあります。

僕の場合、経営・会計・経理周りがわかるし、メイン開発者なのでシステムを隅から隅まで知っているし、長く業務システムの受託・コンサルをやってきているので、多くの業務・企業を見てきて引き出しも多いので、相手の状況を想像しやすく、わりとどんな質問がきてもすぐに対応できて、たぶんそれなりのクオリティの回答ができています。

ただ、これを他のメンバーが一人で同じことをやるのは難しいのは重々承知で、とはいえ、サポート品質を大きく落とすわけにはいかないので、引き継ぐにあたって、何を大事にするか、というのをずっと考えてきました。

boardのサポートは能動的なアクションせず受け身だし、ユーザの行動は分析していないし、KPIはないし、ハイタッチなどの分類もしていないので、おおよそ最近のカスタマーサクセスとは異なる方向性に力を入れているのですが、サポートの本質はコミュニケーションと課題解決だと思うので、「一回のやり取りで一発で解決すること」を理想として、ここのスキルアップに全力を注いでいます。

 

サポートにおけるコミュニケーションの難しさ

コミュニケーションはほんとに難しいと思っています。

口頭で話す際は、その場の雰囲気だったり流れだったり相手に関する知識だったり、様々な情報を元に、コミュニケーションギャップが生まれないように補完しながら話していると思うのですが、チャットサポートというテキストコミュニケーションだと、それらの情報が抜け落ちてしまい、コミュニケーションの曖昧さがより顕在化するんじゃないかなあという気がしています。

特にサポートにおいて難しいポイントがいくつかあります。

相手の基礎情報の不足

普段一緒に仕事をしているメンバーでもコミュニケーションギャップは生まれてしまうのに、サポートの場合、一度も会ったこともないケースが大半です。
しかも、相手がどういう立場・役割なのか、どういう業種なのか、システムに慣れているのかそうでないのかなど、基礎的な情報が全く無い中で対応します。

わからないことを質問する難しさ

自分自身もそうですが、質問する側の立場からすると、「わからないことを質問する」というのはとても難しいことだなと思います。

そのため、質問の文面だけでは状況を把握できないというケースもよくあります。

複数の選択肢があるケース

例えばboardの場合、「発注書」というのは受注・発注の両方にあります。
受注側:顧客から自社にもらう発注書で、こちらで用意し、捺印して返送してもらうためのもの
発注側:自社から発注先へ発行する発注書

そのため、「発注書について質問です」と言われると、「どっちの発注書か」というのがわからないと回答できないのですが、ユーザさんの立場からすると、そもそも2つあることを知らないかもしれないし、知っていたとしても、普通はなかなかそこまで考慮して質問するのは難しい気がします。

「担当者」も「自社の担当者」や「顧客の担当者」などがあるので同じですね。

このように、1つの単語から複数の選択肢があり得てしまうケースもよくあります。

board上に存在しない用語

異なる用語でも同じ意味を示すものは多くあり、業務上使われる用語は会社や業界によって様々です。

質問を頂く際、やはり普段使っている用語を使うことが多く、board上に存在せず、かつ、こちらとしては普段使わない用語だったりすると、board上の何のことを指しているのかわからないことがあります。

直接関係ない情報

ユーザさんは仕様を熟知しているわけではないので、「関係がない情報」が多く含まれていることがあります。

ただ、読み手(CS)側からすると意外とそれらに惑わされがちです。

本来の目的が抜けてしまっている質問

色々と試行錯誤をして頂いた結果、やはりわからずにお問い合わせ頂くケースでよくあるのが、本来の目的(やりたいこと)が抜けてしまっていて、試行錯誤した最後の段階の部分の質問だけが書かれていることがあります。

この場合、質問に対してだけ答えると、ユーザさんが本当にやりたいことではないということになってしまいます。

あの「顧客が本当に必要だったもの」の図でも、「顧客が最初に説明していること」自体が「本当に必要だったなもの」とズレていますが、サポートでも、これはよく起こることだなと思っています。

 

これらの難しさに対応するスキル

前述のような「難しさ」を適切に扱えないとどうなるか。

ユーザさんから見ると、「解決までに時間がかかる」「何度もやり取りが発生してしまう」「質問の意図が伝わらずイライラ」という、よくあるサポートに対する不満になってしまいます。

ユーザ体験というのはシステムだけのことではなく、サポートもboardの大事なユーザ体験の一つだと思っています。

そういう点で、サポートにおけるコミュニケーションの難しさをうまく扱えるスキルがとても重要だと思っています。

これまでのブログにも何度か書いていますが、小さい会社なので全方位に力を入れるだけのリソースはありません。各分野で何か1つ、強みになるレベルに引き上げるまで集中してやるというスタンスでやっていて、サポートの場合はこのコミュニケーションの部分です。

サポートで必要なコミュニケーションスキルというのは、うまく話すこととかではなく、「適切に理解して簡潔に説明する」ということだと思っています。

でも、これがとても難しく・・・。

ポイントは読解力・想像力・文章力だと思っていて、それらの向上に取り組んでいます。

読解力と想像力

「サポートにおけるコミュニケーションの難しさ」の中で書いたとおり、質問者がやりたいことや質問の意図を、文面から正確に把握するというのはとても難しいです。

とはいえ、何度も確認していたら、ユーザさんからしたら面倒ですよね。

そのため、「いかにして限られた情報から質問の意図や本質を把握するか」というのが、スムーズで居心地の良いサポートには不可欠だと思っています。

これには、例えば、以下のようなものの組み合わせが必要になります。
・文章の読解力そのもの
・書かれている情報の要否の切り分け
・可能な限り集められる情報
・相手の状況の「想像」するための想像力。それを可能にする業務や機能の知識
・エスパー(行間以上のことに気づく必要があるケースもある)

エスパーは別として、それ以外については、CSメンバーの育成の中で、「なぜこう解釈したのか」「なぜこういう切り分けをしたのか」ということを論理的に分解しながら解説しています。

これには純粋な「読解力」は不可欠なので、まずは日本語力の強化がベースになります。

その上で、可能な限りの情報を集めて、想像する上で必要な情報を補足していきます。

例えば、以下のようなことをやっています。
・利用開始時期やログイン回数から、使い始めなのか、使い慣れているのか
・コーポレートサイトを探して、業種や規模を確認
・どういった立場なのか(役員だとコーポレートサイトに掲載されているので判断ができる)
・ユーザ権限(管理者なのか担当者なのか)
・質問の内容から、経営者・経理・営業などの職種を想像
・質問の仕方でシステムを使うことに慣れてそうか

質問文の読解に加えて、上記のような情報を合わせて、相手の状況や質問の意図の把握をしていきます。

また、相手の状況を想像する力は、やはり業務的な背景や商習慣の引き出しがものを言います。
これは、時間をかけて増やしていくしかないので、僕が日々の問い合わせを題材にCSメンバーに説明したり、「boardはなぜこういった仕様か、どういう業務を想定しているのか」ということを毎日1トピックずつ書いて共有するなどして伝えています。

わかりやすく伝える文章力

これは自分自身にも言えることなのですが、どうしても色々詰め込みすぎたり、余計な言い回しが多くなって、文章が冗長になりがちです。

なるべく簡潔に無駄な情報がなく、わかりやすい文章を書いていくことで、すっと読むことができます。

特にサポートの場合、読み手に考えさせてしまうような文章はダメだと思っているので、そういった文章力を上げる取り組みをしています。

日々の回答の際は、僕がCSメンバーの文章を校正していたのですが、より改善するため、board初期の頃に広報を手伝ってくれていた方に、「広報の視点でサポートの文章を改善する」という取り組みを月一でやってみています。
*これはとても良い効果があったので、また別途書ければと。

コミュニケーションギャップに気づく仕掛け

どれだけ気をつけても、コミュニケーションギャップは必ず生まれてしまうと思っています。

そのため、「それに気づくことができる仕掛け」を回答の中に入れることがあります。

簡単な例で、例えば「一覧で○○(項目名)を出力することはできますか」という質問があります。

これは、以下のいずれのケースもあり得ます。
・CSVに出力したい(一覧画面ではCSV出力ができるので、"出力"という単語からCSVと解釈)
・一覧に表示したい(画面表示のことを出力という方もいます)

この質問の場合、対象の項目は画面表示はできるが、CSVには含まれない項目でした。

「○○を一覧画面に表示したいといことですか。それともCSVに出力したいということですか」と確認することもできますが、このような質問の場合、大半は「CSV出力」です。そのため、「CSV出力」前提で回答してもほとんどの場合は問題ありませんし、ほとんどのユーザさんからすると、その方が確認のやり取りなしで一発で解決します。

ただ、まれに「画面に表示」のケースもあるので、CSV前提で回答すると、画面表示はできるのに「対応していない」と思われて、認識のズレが発生してしまい、その方にとっては、できることなのに、それを知る機会が失われてしまいます。

そのため、質問の言葉をそのまま使って、「○○を出力することには対応していません」と回答するのではなく、「○○をCSVに出力することには対応していません」という形で情報を補完して回答します。

そうすると、「CSVではなく画面のことです」と質問者が気づくことができます。


明らかに確認が必要なケースはもちろん確認を挟むのですが、このように「ほとんどのケースではこっち」という場合、このように、質問の文面上は情報が足りないことはよくあって、それを補完しつつ回答すると、ズレがある場合に気づくきっかけになります。

コミュニケーションのズレを防ぐ努力はしますが、事前に100%防ぐことはできないので、このような感じで、ズレに気づけるちょっとした仕掛けを入れることで、少しでもズレを拾えるようにしています。

 

まとめ

サポートというのは本質的にはコミュニケーションだし、コミュニケーションはとにかく難しいので、boardのサポートは、ひたすらそのレベル向上を最優先にしています。というか、それしか取り組んでいません。


現在CSメンバーは2名いて、1名は昨年3月、もう1名は昨年11月に入社し(フルタイムは12月から)、今年2月からはどちらかが休みでない限りは、僕は必要な場合のみフォローに入る程度で、基本的には二人で回す体制にシフトしています。

「少ない人数で回す」「10分で回答する」ためには回答の効率化が必要ですが、マニュアル化して機械的な効率化を図ることはやっていません。むしろ逆で、よくある質問だと定型的な回答になりがちなのですが、マニュアル的な対応をしたことで、「間違ってはいないけど微妙な会話のニュアンスのズレ・違和感がある」というのが一番ダメだと思っていて、CSメンバーがこれをやると、僕が一番不機嫌になるパターンです。

そういった効率化ではなく、相手の意図を把握すること、素早く適切な説明ができること。これによって、やり取りの回数を減らすことで、少ない人数で素早い回答を実現するということを目指してやっています。

これは、CSに限らず、経営でも開発でもマーケティングでも共通した自分のスタンスですが、「急がば回れ」だと思っています。

 

今回は、こういうことを目指してやっているという内容でしたが、このために1年ほどかけて色々と取り組んできたので、 具体的にどんなことをやってきたかについては、また別途書きたいと思います。

SaaSの問い合わせを減らすための改善

現在、boardはリリースしてから5年目ですが、リリースから4年ほどは、サポートはほぼ自分一人でやってきたので、「社長もサポートやっている」というより「社長しかサポートやっていない」みたいな状態だったのですが、やはりリリースから3年ほど経って、導入社数が700〜800社くらいになってきた頃には、一人で対応するのがだいぶ大変になってきていました。

2年ほど前に採用したCSメンバーが、仕事内容やカルチャー的に合わずにすぐに退職することになった際、「導入社数の増加とともに、このまま問い合わせが増え続けると一人では対応できなくなるのが目に見えていてやばい」という状況だったため、本格的に「問い合わせを減らす取り組み」を始めました。

 

ちなみに、boardというサービスやヴェルクという会社は、ざっくり以下のような感じでやっています。

  • boardは、見積書・請求書の作成から業務管理・経営管理などを行うことができるサービスで、主に数人〜数十人規模の中小企業がターゲットユーザ層
  • boardの有料導入社数はもうすぐ1900社
  • 弊社(ヴェルク)は現在7名の会社で、10名前後までの小規模組織を維持したいという方針

詳しくは下記をご覧頂ければと思います。

tamukai.blog.velc.jp

 

取り組みの概要

ヘルプを見てもらいやすくするための工夫や、問い合わせが多い箇所を中心に、1〜2週間に1つずつくらいのペースで改善をしていきました。

元々、1〜2週間に1回くらいのペースで何かしらリリースしていたので、リリースペースは変えず、それに乗せていく形です。

改善対象を決めるのは、単純な問い合わせ件数ではなく、問い合わせ対応をしている中で感じた「ここをこういう感じで改善したら問い合わせ減りそう」という肌感覚を大事にして、対応箇所や方法を検討しました。

ちなみに、問い合わせが多くても、内容が複雑なものはこの取り組みではやらず、どちらかというと、ヘルプを見れば一発で解決するような簡単な問い合わせを減らすことを目的としました。

 また、問い合わせが多いということは、わかりにくい点・躓きやすい点だと思うので、そういった箇所の改善は、ユーザさんがスムーズに使ってもらうためにも重要です。

 

取り組みの成果

2018年の1年間で、有料導入社数が約700社ほど増えたのですが、その1年間の問い合わせ件数の推移が以下です。

f:id:fw_tx76129:20190314234942p:plain

 月によって上下はありますが、導入社数は増加してても、問い合わせ件数はそれほど増加傾向にはありません。

ちなみに返信数が以下。

f:id:fw_tx76129:20190314235123p:plain

 1回の問い合わせで何度もやり取りが続くことがあるので、普段は基本的には問い合わせ数ではなく返信数を見ているのですが、これも同じような傾向です。


その結果、2018年前半まで(1400社くらいまで)は自分一人体制でなんとかしのげて、2018年中盤から徐々に自分ともう1名のCSメンバーの二人体制になり、今年からはCSメンバーが二人になり、その二人で余裕を持って回せています。

1900社+お試し中の方々を、自分を除いた二名で回せている状況は、かなり良い感じだなと思っています。


以下、実際に取り組んだことを紹介していきます。

 

初回ログイン時のセットアップウィザード

boardの各種設定のデフォルトは、一般的に多そうな設定をデフォルトにしていますが、会社や業種によって、ばらけるような設定もあり、これらはどうしても問い合わせが多くなっていました。

例えば、以下のような設定です。
・見積書や請求書への単位の表示有無
・見積書や請求書での内税での入力
・窓付き封筒の利用有無

そこで、会員登録後の初回ログイン時に、ウィザード形式でこれらの設定を選んでいくようにしたところ、これらの設定に関する問い合わせは大幅に減りました。

f:id:fw_tx76129:20190314235529p:plain

ちなみに、初回ログイン時にウィザードを入れることで、ここでの離脱が増えることを懸念していたのですが、それはほぼありませんでした。

 

ヘルプ検索

元々、ヘルプページ上で検索はできたのですが、board内からヘルプの検索を直接できるようにしました。

f:id:fw_tx76129:20190315000532p:plain

これによって、ヘルプのアクセス数は3倍以上になり、簡単な問い合わせも減り、「ヘルプを見てもわからなかったので質問させてください」といった感じで、ヘルプを見て頂いた上での問い合わせが増えました。

 

ヘルプの内容の改善

boardのヘルプはかなりしっかり書いているので、ヘルプを評価して頂くことも多いのですが、「どの権限でこの機能を使えるのか」というのがわかりにくく、「ヘルプのスクリーンショットにあるメニューが表示されていない」系の問い合わせはそれなりにありました。

そこで、各ヘルプページの先頭に、その機能を利用できる権限を書くようにしました。

f:id:fw_tx76129:20190315000919p:plain

これによって、権限関連の問い合わせはかなり減りました。

 

仕様に気づく仕掛け

多くの場合、事前にヘルプをしっかり読んでから使うのではなく、操作しながら使い方を把握していくことが多いかと思います。

そのため、表面的には把握しにくい仕様は、操作の過程で「あ、こういう仕様なんだ」ということに気づくきっかけを入れるようにしてみました。

このための仕掛けは色々やったのですが、細かい仕様の話になってしまうので、わかりやすい例で、「失注」ステータスのケースを紹介したいと思います。

 

受注ステータスという受注状況を管理するステータスに「失注」というものがあります。

失注案件はデフォルトでは案件一覧に表示されなくなるため、「失注にしたものが見つからない」という問い合わせが結構ありました。

「失注にすると、デフォルトでは案件一覧に表示されない」という仕様は画面上からは把握できないんですよね。

変更時に「確認ダイアログを出す」という方法も考えたのですが、確認ダイアログって読まずに押されることが多いので、あまり効果がなさそうな気がしました。

そこで、「失注」ステータスに変更する時だけ、以下のように、失注案件の検索方法のスクリーンショット付きの確認ダイアログを出すようにしました。

f:id:fw_tx76129:20190315001213p:plain


普通の確認ダイアログよりも目立つので見てもらいやすくなり、変更前に失注ステータスの検索方法が異なることを把握しやすくなります。

この結果、失注ステータス関連の問い合わせがだいぶ減りました。

 

問い合わせが多い要望を集中的に対応

boardでは「開発ロードマップ」を半年ごとに決めて公開しているので、軽微なもの以外は、あまり途中で差し込むことはしないようにしているのですが、2ヶ月ほどの間に限定して、集中的に、問い合わせが多く、かつ「時間があれば対応したい」と思っていたものを一気に対応しました。

質問や要望が多いものを中心に対応するので、それらが対応されれば、当然その分の問い合わせは減ります。

必要ないものを無理に対応することはしないですが、「時間があればやりたい」と思っている軽微なものは、どんどん対応していった方が、お互いにとっていいなと思いました。

そのため現在では、Trelloに「軽微な改善」リストがあって、ここにあるものは、他の開発メンバーがスキマ時間に勝手に取ってやっていきPR出してもらうという運用にしています。

ちなみに、本来の開発の進捗に影響しないよう、「軽微な改善」リストは、数十分から数時間程度で終わるものに限定しています。

 

時間外問い合わせの自動返信

これは、「問い合わせを減らすための施策」としてやったものではないのですが、予想外に効果的だったので紹介したいと思います。

boardのサポートではintercomを使っていて、intercomに時間外の自動返信の仕組みはあるのですが、日本語が微妙で(今はわからないですが少なくとも当時は)、自分で初めて見た時に、意味がよくわからず「?」だったため、これをユーザさんに体験させるわけにはいかないなあと思い、使っていませんでした。

全て自分が回答していた頃は、時間外であろうと、仕事している時だったらすぐに回答していたのですが、他のCSメンバーにそれをやらせるわけにはいかないので、昨年途中から時間外は回答しないようにしました。

ただ、そうすると、ユーザさんから見ると、いつ返事が返ってくるのかわからない状態になってしまうので、自動返信の仕組みを作りました。

 

時間外に問い合わせをすると、以下のような自動返信が返ります。

f:id:fw_tx76129:20190315001809p:plain

 

仕組みとしてはシンプルで、

問い合わせ→intercom webhook→AWS API Gateway→Lambda→intercom API

という形で、intercomのwebhookとAPIを使って自分で自動返信の仕組みを作った形です。

 

自動返信自体は問い合わせ数を減らす取り組みではなく、「いつ返信がくるのかわからない」という課題の解決のために作ったのですが、この仕組みを入れてから、サポート時間外であることを明確に把握できるようになったからか、以前に比べて時間外の問い合わせが減りました。

たぶん、「時間外だから」ということでヘルプなどで自己解決したんだろうなと思っています。


ちなみにこの自動返信の方法だと、intercomの自動返信機能とは異なり、メッセージも自由に書けるし、曜日だけでなく日本の祝日・年末年始にも対応できるし、平日の臨時休業にも対応できるのでとても良いです。

 

まとめ

問い合わせ自体は気軽にして頂きたいと思うのですが、そもそも質問をしなくて使える方がずっと良いと思うので、とくに簡単な機能や設定に関しては、問い合わせをせずに気づける・自己解決できるための改善を継続することは、双方にとってメリットが大きいなと感じています。


問い合わせは改善の源泉で、これを定量的な数字ではなく、ユーザさんを肌で感じて考えることはとても大事だと思っています。

CS二人体制が起動に乗り始めたため、先月からは僕が常時回答することは減り、難易度が高いものや問い合わせが立て込んだ時、CS二人のうちどちらかが休みの時などだけになりました。

でも、今のところ、毎日全ての問い合わせは目を通していて、どういった問い合わせが多いのか、どういったことで困っているのかなど、機能追加や改善は随時あるので、それによる変化は常に追うようにしています。

 

ちなみに余談ですが、この一連の取り組みで、問い合わせ数の増加を抑えられたという効果と共に、「簡単な問い合わせ」が明確に減ったので、昨年入ったCSメンバーが、最初の頃に簡単に対応できるものが少なく、CSメンバーの最初のハードルが高くなったという副作用がありました・・・。

ヘルプのバージョン管理・編集・デプロイの仕組みを整備した話

前々から、ヘルプのバージョン管理をしたいと思っていたのですが、なかなか手が回らず放置していたところ、フリーランスで編集者をやっていた者がCSメンバーとして入社したので、それを機に、本格的に準備を進めて、今年頭から、運用を始めてみました。

1ヶ月ほど運用してみて、なかなか良い感じなので、紹介したいと思います。

ちなみに、boardという見積書や請求書作成・業務管理・経営管理などができるSaaSのヘルプです。

the-board.jp

なお、仕組みとしては、GithubのプルリクエストとWebhookを使っているだけなので、何か特別なことをやっているわけではなく、ソースコードのレビューやデプロイと同じようなことをヘルプ記事にも適用したという感じです。

これまでのboardのヘルプ

現在357記事あり、通常のヘルプが226記事、FAQが131記事あります。

通常のヘルプは、機能・仕様や効率的な使い方などの説明で、長めの記事が多いです。FAQは、問い合わせが多い質問を中心に、簡単な説明+ヘルプへの誘導という簡潔な内容です。

これまでのヘルプは、 WYSIWYGなHTMLエディタを組み込んだ管理画面を用意して、そこから登録していました。そのため、本文データはHTMLで、DBに保存されていました。

f:id:fw_tx76129:20190224173230p:plain

 

ヘルプに関しては、ユーザの方から「内容が充実していてほとんどヘルプだけで解決する」などのコメントを頂くことも度々あり、実際、有料導入1800社以上いて、CS二人で余裕を持って回せているので、かなり自己解決の役には立っているのではないかなと思っているのですが、今回の取り組みで、より安定した品質と、編集を通すことで読みやすさを改善して、さらにレベルアップさせていきたいと思っています。

今回の方針

バージョン管理を行う方法として、管理画面側に自前で実装する方法も考えられますが、今回、バージョン管理だけでなく編集・校正の運用をしたく、これをGithubのプルリクエストでやりたかったので、管理画面での自前実装はせず、Githubで管理することを軸に考えました。

そのためには、まずは、現在DBに入っているヘルプのデータをファイルにしていく必要があります。

 

ヘルプデータをファイルにするにあたって、HTMLからMarkdownにすることを検討しました。ヘルプなので、それほど複雑な表現は必要ないし、HTMLタグがない方が差分も見やすいかなと。

ただ、以下の理由で、今回は、HTMLのままにすることにしました。

  • できるだけ工数は最小限に抑えたく、ヘルプの表示側の実装は変更したくない
  • データ形式の変更に伴うテスト・内容のチェックなどの時間を確保するのが難しい
  • 表形式で表示している箇所があり、Markdownのテーブルだと厳しかった

ということで、今回は、これまで登録されていたヘルプのHTMLデータはそのままにし、ヘルプの表示側(board上でのヘルプ)の実装は変えず、その手前でバージョン管理をしていく、という方針で考えました。 

今回の仕組みと運用方法

ざっくり図で表すとこんな感じです。

f:id:fw_tx76129:20190224222706p:plain
 バージョン管理はGitを使い、校正のフローはGithubのプルリクエストを使います。

あとは、よくあるシステムのデプロイと同じように、所定のブランチにマージされたら、自動的にステージング環境・本番環境にそれぞれ反映される仕組みです。

現時点ではヘルプの運用に関わるのは、僕と@note103の二人です。@note103 はこれまで10年ほどフリーランスで編集者をやっていたので、僕がヘルプを書き、彼が編集をするという役割分担です。

なぜか普通にgitを使える編集者なので、わりとそれに依存した仕組みではあります。

 

ちなみに、長く編集者をやっていた彼が入社した経緯は本人のブログをどうぞ。

note103.hatenablog.com

 

運用フローは主に以下の2パターンです。

<新規のヘルプ>

  1. 僕が新規のヘルプを書いて、Githubでプルリクエスト
  2. @note103が編集・校正
  3. プルリクエストをマージしてステージング環境へ自動反映→最終チェック
  4. masterにマージして本番環境へ自動反映

<既存ヘルプの修正>

  1. @note103が気づいた点を随時修正してプルリクエスト
  2. 僕が内容に間違いがないかをチェック
  3. プルリクエストをマージしてステージング環境へ自動反映→最終チェック
  4. masterにマージして本番環境へ自動反映

 

上記のように、Gihtubのプルリクエストを使って運用していくため、現在、DBに入っているヘルプのデータをファイルにする必要があります。

ただ、本文のHTMLだけでなく、タイトル・メタ情報・OGPなど、本文以外の情報もあります。

そこで、以下のようにしました。

  • 本文データはそのままDBから取り出して、記事ごとにHTMLファイルにする
  • それ以外の情報は、YAMLファイルにし、1記事ごとに本文のHTMLと対になるように生成

記事ごとに、本文のHTMLファイルと、それ以外の情報を持ったYAMLファイルをセットで管理するような形です。

本文のHTMLだけファイルを分けたのは、単独のファイルにすることで、HTMLエディタで編集ができたり、Middlemanに組み込んで、ローカル環境で、実際のスタイルを当てて見栄えを確認しながら編集できるようにするためです。

ちなみに、文章をGitで管理するということに関しては、「k16's note: 執筆・編集のためのGit(GitHub)ワークフローを考えてみた」がとても勉強になりました。

ヘルプの場合は1つ1つが大きな文章ではなく、文章の骨組みの大幅な変更などはあまりないので、上記の記事にある「じっくり読まなければ何となくいい感じ」からスタートしているイメージの運用です。

この仕組みのメリット

バージョン管理という点では、ブランチを切れたり、簡単に戻せたり、いつでも過去の履歴を確認できるなど、ソースコードのバージョン管理と同じようなメリットがあります。

また、編集をプルリクエストに乗せることで、管理しやすく、差分も確認しやすいので、編集の運用がスムーズです。

ここまでは想定通りなのですが、実際に運用してみて、Githubからのwebhookでヘルプのデプロイができるのがとても良いなと。

ステージング環境でしっかり確認したものをそのまま反映できるので、本番に反映するにあたってオペレーションミスがありません。

システムのデプロイでは当たり前なんですけど、ヘルプでも、本番環境のものは当然ユーザさんの目に触れるものだし、その品質管理は重要だと思っていて、そういう点で、しっかり確認できたものを、人手によるミスがない方法で反映できるというのはとても良いなと思いました。

また、2/10に全体的なデザインが少し変わったことで、スクリーンショットを全て差し替える必要があったのですが、200以上の記事のスクリーンショットを全部差し替えて行くという作業を、管理画面のHTMLエディタでやっていたら、たぶんいくつもミスがあったのではないかなと思います。

ただ、この仕組みのおかげで、スクリーンショット差し替え用のブランチで事前に準備しておき、事前にステージング環境で入念に確認し、リリース時に、ヘルプの方もmasterにマージして自動的に反映されるという、とても楽な方法で一括反映できました。

ちなみに、約150記事を本番に反映した際、3分程度で終わりました。

この仕組みのデメリット

実際運用してみて、やはり管理画面から直接編集していた時に比べて手間はかかるので、「ちょっと修正したい」という時に面倒だなとは思います。
例えば、開発ロードマップの状況を更新するだけの時とか。

あとは、gitに依存しているので、うちの場合は、普通にgitを扱える編集者だったので良かったですが、ここはちょっとハードルにはなるかもしれないです。 

編集者視点での感想

せっかくなので、@note103に感想を聞いてみました。 

■履歴・記録を残せる

一番良いと思うのは、履歴を残せることですね。というのも、日本語の修正・編集って一発で決まるものばかりではなくて、あーでもないこーでもない、と迷いながらやることが多いので、一回決まったと思っても、「やっぱり前のが良かったかも・・」となりやすいです。

そういうときに、記録が残らない方法だと前の内容を参照することは難しいですが、バージョン管理ができると「いつでも戻れる」という前提があるので、逆に気軽にサクサク直していけるという、心理的負担が軽くなる効果があると思います。

 

■複数人で共有・分担できる

あとは、やっぱり修正した内容(差分)を他人が確認できる、ということも大きな利点ですね。これの良いところは、単に「修正内容を共有できる」というだけのことではなくて、「直す人」と「本番環境に反映する人」を分けられるということが重要だと思います。

実際の話、日本語の修正なんてある意味誰でもできるわけですが(とくにタイポの修正など)、でも本番に反映する作業は誰がやっても良いわけではないので、「直す人」がコミット&プッシュして、「反映する人」が差分を見てマージする、という分担の流れはとても効率が良いと思います。

それに関連して、もう一つ地味に大きいのが、自分でも「どこを直したのか」を確認できるのが良いですね。とくに1つのファイルにいくつも修正がある場合、自分がどこを直したかすべて覚えておくことはできないので、後から自分自身で修正箇所をチェックできるというのはメリットだと思っています。

 

■作業がラク

あとはテキストファイルで管理されているので、普段使っているエディタなど好きな環境で作業できるのもありがたいです。いつも使っている検索コマンドをそのまま使えたりして、簡便だなと。これがもし、ヘルプ管理用のブラウザの画面などで一つひとつ直していく、という感じだったら、もっと大変だったかなと。 

まとめ

履歴を管理したり、レビューをしたりというのは、ソースコードでは当たり前にやっていることだと思うのですが、同じような感じで、ヘルプでも運用してみたところ、とても良い体験を得られたのでオススメです。

この運用を始めた年明け以降、新たに追加するヘルプは全てこの運用に乗せて、編集を通しています。

既存のヘルプに関しては、日々のサポートの中で説明の仕方がどんどん改善されているので、それを反映するために全てのヘルプを頭から見直していくつもりで、それなりに時間がかかりそうですが、説明も文章も、今より一段レベルアップしていけるのではないかなと思っています。


余談ですが、編集者の仕事を間近で見るのは初めてなのですが、数百字程度の文章でも、日をおいて何周かチェックして、都度、細かい修正を入れている過程はとても勉強になるので、最終的な修正内容だけでなく、コミットごとの差分を追っていたりします。

10人の会社で1万社が使うサービスを目指す

boardの現在の有料登録数は1700社なので、1万社はまだまだ遠いですが、最近よく「10人で1万社」という言い方をしています。

数値目標を立ててそれを目指してやっていくというのは苦手だし好きではなく、普段から
・会社としては、みんなの賞与を出せるレベルで利益を出す
・boardとしては、前年レベルの成長率は維持する
くらいしか考えていません。

5年ほど前から「売上の座布団を増やしていくためにストック売上を増やす」と言ってきましたが、これも具体的な数値目標や期限は設けず、毎年期末のまとめの際に、社内のみんなに対して「早く50%くらいまで行きたいね〜」「今年は○%まで増えた」という話をするだけでした。

「10人で1万社」というのも、「いつまでに」というのはないし、成長や売上のための目標というよりは、「営業・運用に人手をかけない仕組みを作っていくため」の目標みたいな位置づけです。

人手がかかるやり方をしていたら10人の会社で1万社を獲得し運用するのは到底無理なので、営業においても、システム運用においても、とにかく人手がかからない仕組みを目指しています。

ちなみに、役員2人以外は残業することはほぼないので、もちろんこの状態を維持しつつ。

 

なぜ10人?

サービス以前に、うちの会社は、規模を大きくしない(10人前後まで)という方針でやっています。

もちろん小さい会社でできることというのは限られてきますが、小さい会社でないとできないこともあるし、小さい会社でも多くの人に使ってもらえる仕組みを作れるのがシステムの良いところだなと思っています。特にSaaSは、その傾向が強い印象です。

 

現在の状況

うちは自分を入れて8人の会社で、boardにフルタイムで関わっているのは4人、総務兼任が1名。一人は最近入社したばかりなので、この1年はフルタイム3人 + 総務兼任1名でやってきました。
フルタイムの3人は、エンジニアが1名、CSが1名、あとは僕がプロダクトマネージャ・開発・CS・マーケティングなどを担当しています。11月に入社したのはCSメンバーなのでCSが2人体制になります。

また、総務が個別相談会のデモやテストなどを兼任していて、残りの3名は受託がメインで、たまに手が空いた時にboardの開発を手伝ってもらっていたりします。

 

人手をかけないものとかけるもの

小さい会社では常に人手は足りないし、分野的にカバーできる範囲は限られるので、ある程度思い切った選択が必要だと思っています。

うちの場合は、営業メンバーはいないし、広告運用の経験があるメンバーもいないので、これらはやらない前提で考えるようにしています。

また、そもそもboardの価格帯(月額980円〜5980円)のサービスを人が営業して売っては利益が出ないし、広告もペイしないので、短期的に一気に伸ばす場合を除いては、営業・広告に頼らず売っていかないといけない価格帯なのかなと思っています。

一方、CSには相当力を入れています。
2015年3月から、サポートの回答時間の実績値を公開していて、ここ3年ほどは回答時間の中央値は10分を切っています。

また、他にやる人がいなかったというのもありますが、サービスリリースして3年以上も社長がCSをほぼ一人でやり続けていて、かつ、自分の中では、自分が持っている経営・開発タスクよりも優先度が高い位置づけになっていました。

これは、営業・広告にコストをかけて新規獲得を増やすことができないので、一度会員登録してくれた人をできるだけサポートして使ってもらえるようにしたいということもあり、サポートに力を入れてきました。

 

CSは労働集約型

しかし、サポートは完全に労働集約型の仕事です。

導入社数が増えれば比例して問い合わせも増えてくるので、CS体制も増やしていく必要があります。そのため少ない人数で多くのユーザを抱えるサービスを運営していくためには、ここが大きな課題になります。

例えばチャットボットを導入して、ある程度自動化することも選択肢としてはあるとは思います。しかし、boardのサポートは業務的に込み入った話も多く、わりと人間が頭を使って回答しなければいけないものがたくさんあるため、現時点で、それらをチャットボットで解決できるイメージは湧きません。

サポートもサービス全体のUXの一つと捉えています。サポートとのやり取りでどういう体験をするかというのは極めて重要な位置づけで、少なくとも現時点では、人間がやるべきと考えています。

そのため、以下のようなことを継続的に取り組んでいます。

問い合わせを減らす対策

・問い合わせが多い機能を1〜2週間に1つずつ改善していく
・問い合わせ内容から随時ヘルプを改善
・ヘルプの検索のしやすさの改善
・CSの回答の中で、その場の解決だけを目指した回答をするのではなく、仕組みを理解してもらうための説明をする(将来的な問い合わせを減らす)

回答効率と手離れの良さの改善

・僕のサポートノウハウの整理とすぐにそれを検索できる社内用の仕組みの構築
・マニュアル化ではなく、個人の対応力の向上(業務理解、読解力、文章力、説明力などの強化)
・毎日、質問と回答のチェック・フィードバック・改善を繰り返し、よりやり取り回数を減らすことができる、わかりやすい回答にしていくための取り組み

 

問い合わせ数という点では、特に「問い合わせが多い箇所の改善」は効果的でした。問い合わせが多いということは、わかりにくかったり、躓きやすいところなので、そこを改善していくことで、それ関連の問い合わせが劇的に減りました。

その結果、ここ1年で有料導入社数が700社以上増えましたが、問い合わせ数・返信数は横ばいです。

現在の問い合わせ量だと、CSはほぼ一人で対応できていますが、新しく入ったメンバーも含め、2人体制で4〜5000社くらいまではいけそうな気がしています。

 

バグ・障害の少なさとリリース後の手離れの良さ

バグや障害があると問い合わせが増えてしまいます。そのため、少人数で回していくためには、バグや障害の少なさというのはかなり重要なポイントと考えています。

また、仕様の適切さや完成度もとても重要で、機能追加しても、仕様が中途半端だったり業務とフィットしていなければ問い合わせが増えますし、急遽、当初予定になかった改修が必要になります。これはプロダクトマネージャとしての質ですね。

質の良さは、問い合わせを減らす効果があり、またリリース後の手離れが良く、スムーズに次の開発に入れるので、開発サイクル全体としても効率的になります。

そのため、自分の中では、感覚的には受託の時の2〜3倍程度のコストを品質管理にかけていて、それが結果的に、トータルでのコスト低減や安定したペースでの機能追加・改善に繋がっていると思っています。

boardの場合、少し状況が特殊で、リリース後3年以上、ほとんどの期間でほぼ僕一人で開発・CSをやっていたので、バグを出すと全て自分に返ってきます。

新しい機能をリリースしてバグがあったり既存機能に影響があったりすると、問い合わせが立て続きます。自分でその問い合わせ対応をしないといけないので、その結果修正の時間も取れないという、完全に負のスパイラルに入り込みます。バグ1つの重みがとても重かったのです。

元々受託においても、お客さんから「バグや手戻りがとても少ない」という評価を頂くことが多かったのですが、それよりも遥かに高いレベルのものを自分自身に求め、いかにしてバグを未然に潰せるか、そのプロセスと品質管理の仕組みを改善していきました。

その結果、リリース頻度(年40回前後)と規模を考えると、仕様面での後悔はとても少ないですし、バグもかなり少なく抑えられているのではないかと思っています。ユーザさんからも「他のサービスと比較検討していたけど、品質の良さが決めての一つ」と言われることもあったりします。

もっとも、全体としてはそういう傾向というだけであって、バグは当然あるし、いちユーザから見ると、バグを引いた方も当然いるわけで、そういう人からすると、これを読んで「いや、俺バグ引いたし」と思うと思うので、あまり大きなことは言えませんが・・・。

 

SREやDR

「この価格帯のサービスで、この規模の会社でDRやるの?」と言われたりするのですが、最近、DRやSREに対する取り組みを始めています。

ユーザさんにとっては、当然安定してサービスが利用できることに越したことはありません。

また、うちとしてもこれまで書いてきたように、少ない人数で回していくためには、障害の少なさというのは非常に重要になってくるので、ここは今以上に強化していきたい分野です。

これらの強化はこれから本格的にスタートしたところで、今後、継続的に取り組んでいく予定です。

 

完成度の高さやユーザ体験という差別化

小さい会社は、知名度やリソース(人・金)では戦えません。

システムの完成度・質(仕様的な意味も含めたトータルの質)・ユーザ体験が生命線で、そのために、アプリケーションそのものはもちろん、運用やCSなどを磨き続けていき、そういう差別化を目指しています。

サービスを比較検討する際、機能の○×や知名度は、とてもわかりやすい指標なんですよね。でも、小さい会社はその土俵では戦えないので、程よくターゲットを絞りつつ、その中で圧倒的な完成度に持っていく。

昨年、別にboardのパフォーマンスは悪いわけではないのに、さらなるパフォーマンスの向上の取り組みをしていたのも、「速さは最大のUX」だと思っているので、「ユーザ体験」をより向上させるための投資でした。そして、これは今後も継続してやっていきます。

 

たぶん、今後boardが進む方向はこういう方向なんだろうなと思っています。

とてもぼやっとしていてわかりにくいですが、引き続き地味にじっくり、開発もCSも磨き続けていきたいと思います。

 

そしてそれが実現できれば、ユーザさんに対しては、より高品質のものを今の価格帯のまま提供を続けることができるし、社員のみんなには大きな額の賞与として還元してみんなの収入をぐっと引き上げることができるので、それを目指してやっていきたい。

 

こういう方向に進むための「10人の会社で1万社が使うサービスを目指す」という方針です。

 

ちなみに、エンジニアを募集中です。

こんな方向性でやっているので、興味があるエンジニアの方がいましたら、ラフに話を聞きたいレベルでも全然問題ないので、お気軽にご連絡を頂けると嬉しいです。

 

8期振り返り〜自社サービスのアサイン割合が受託を超えた年

2018年11月に8期目が終わったので振り返りです。

前期は、僕の交通費の経費精算回数が1桁という、あり得ないくらいオフィスに引きこもって、ひたすら開発とサポートをやっていました。ベンチャー社長の中でトップレベルで外出しなかった自信がありますw

それくらい、開発・サポートといった手を動かす方に集中していたわけですが、「受託の会社が自社サービスを立ち上げていく」という取り組みの中で、ビジネス構造としては大きな転換期だった1年でした。

 

売上構造の変化

8期は売上・利益ともに過去最高でしたが、その額よりも、売上構造の変化が、自分の中で一つラインを超えたと感じています。

5年ほど前から、「売上の座布団を増やす」と言って、ストック売上を積み上げていくことを目指していました。

受託ビジネスは納品基準で請求することが基本なので、どうしてもキャッシュフローに波があります。そこで、経営を安定させるために、ストック売上を増やして波を小さくしていこうという狙いです。

8期は、このストック売上の割合が約6割になり、初めて半分を超えました。自社サービス(board)の伸びが一番大きいのですが、それ以外にも保守をはじめ、その他色々と積み重ねた結果です。

今期はストック売上が7〜8割ほどにはなる見込みで、売上構造が受託の会社のものではなくなり、だいぶ直近の売上に振り回されずに済むようになってきました。

これにより取れる選択肢が広がるので、事業を展開していく上でとても大きく、強い経営基盤ができてきていると感じています。

 

受託と自社サービスのアサインの割合

現在うちの会社は、取締役2人を入れて8人ですが、一人は11月に入社したばかりなので、8期は実質7人でした。

内訳は、受託メインが3人、自社サービスメインが3人、総務兼自社サービスが1人と、初めて自社サービスへのアサイン割合が受託を超えました。

自社サービスの事業を進めていく中で、「受託の利益を食いつぶしながらやるのではなく、自社サービスの売上の中でまかなえるアサインで事業を進めていく」というのを基本スタンスでやってきました。

売上が少ない初期の頃は、僕が自社サービスをやりつつ足りない分は受託で稼ぐということをやっていて、ある程度売上が上がるようになってきてからは、その売上でまかなえる範囲で他のメンバーを少しずつアサインしてきました。

そのため、「自社サービスに投資するから一気にリソースを増やす」ということはやっておらず、身の丈にあった形で少しずつ社内の体制も変化させてきたので、この割合が逆転したというのは、自分の中ではとても大きな出来事でした。

 

受託

7期(前々期)から、僕はboardの方が忙しすぎてあまり受託に入れてはいなかったのですが、7期の頃は営業だけは入っていたりしました。

ただ、8期は営業も入ることはなく、昔からやっている3案件のみ引き続き持っているだけで、基本的にはもう一人の取締役(津久井)が中心になって進めています。

受託は好きなので完全に離れつつもりはなかったのですが、boardの方が順調なこともあり、時間が足りなすぎるということで、完全に離れる方向で体制をシフトしています。

ここ2年ほどかけて受託体制の転換を行ってきて、うまく切り替えられたかなと思っています。

また、受託の内容も、以前はわりとなんでも受けていたのですが、最近は関わる人数が減ったこともあり、津久井がずっとやってきたデータ分析支援(小売・大学など)を中心にやるようになってきました。

 

board

boardは、12/5に有料1700社を突破し、1ヶ月半〜2ヶ月に100社のペースで増えています。

初期の頃は、どうやって伸ばしていくかということを試行錯誤していましたが、ここ2年ほどは、営業もせず広告も出さず、「売る気あるの?」って言われたりするのですが、自分自身、営業は得意でも好きでもないし、SaaSなので営業せずに売れる仕組みを作っていこうという思いでやっています。

前期は普段どおりの機能追加・改修は続けつつ、以下のことをやっていました。

  • パフォーマンスの向上
    元々わりとサクサク動いていましたが、速さは最大のUXなのでさらなる高速化への取り組み(今後も継続していく予定)
  • 自動テストの本格的な整備
    これまでほとんど書いていなかったので、単体〜E2Eまでをかなり時間をかけて一気に整備
  • ライブラリのアップデートを日常にする
    自動テストを整備したことにより、Dependabotを使ってライブラリのアップデート間隔を短くする運用を開始
  • テストケースの整備
    僕の中に品質管理のノウハウが閉じてしまっているので、それの整理とアウトプット
  • DR(ディザスタリカバリ)のための取り組みを始める

前々期まではほぼ自分一人で開発してきましたが、前期はもう一人を1年間フルアサインできたので、今後に繋がる内部的な改善などに取り組みました。ちなみに、リリースは年間で40回ほどだったので例年よりも少し少なかったです。

boardは契約社数が1700社を超えるまでに成長してきたので、もう立ち上げのフェーズではなく、今後は、いかにして、品質を落とさず安定して継続開発できるか、そのための土台整備にある程度時間を割き、これは今期も継続していきます。

また、今後はそれに加え、SRE・DRといった、さらなる安定性・耐障害性を高めていくための取り組みをしていきたいと思っています。

「どんどん機能追加をして拡張していくフェーズ」から、「機能追加・改善は継続しつつ、完成度・使い勝手のさらなる向上や非機能要件的な内容をもう一段レベルを上げていこう」というイメージです。

ちなみに現時点で安定性・耐障害性などに課題感があるわけではないのですが、少ない人数で回していくことを考えると、この部分はとても重要で、そこを更にレベルアップしていこうとしています。

 

ユーザさんは、「同じレベルやちょっと良い程度」であれば有名な方・大きい会社の方を選ぶと思っています。

そのため、うちみたいな小さい会社が戦っていくためには、完成度・品質・ユーザ体験などが生命線で、これまでもそれで戦ってきたつもりですが、それをさらに追求していくつもりです。

 

採用

前期は初めて1年間で二人採用をしました。二人ともboardのCSです。

一人は3月に入社し、もうだいぶ軌道に乗ってきています。夏以降は僕ではなくほぼ彼が回答しています。

 

その後は募集はしつつも、急がずに「いい人がいれば」というスタンスで考えていました。

一人目のCSメンバーに色々と教えていた過程で、boardのCSに必要なことや考えが整理されてきて、それが「読解力」「想像力」「日本語力・文章力」でした。

最近のカスタマーサクセスの流れとは全然違いますが、やはり会ったこともない、背景も知らない、立場も知らない人からの問い合わせから、「本当にやりたいこと」を読み解くのはとても難しく、CSの本質は「ユーザさんが本当にやりたいことを正しく把握して、正しく説明すること」なので、様々なKPIを追うのではなく、もっと本質的な「読解力」「想像力」「日本語力・文章力」の強化というところに行き着きました。

ただこれが本当に難しくて、でもCSの8割はこれだと思っているので、他のことは置いておいて、ここにだけフォーカスしていこうという方針でやっています。

というようなことをツイートしてたら、長らくフリーランスで編集者をやっていた@note103 の目に止まり、CSとして入社してもらうことになりました。この辺の経緯は、@note103のブログをぜひ。

note103.hatenablog.com


ということで、CSは二人体制になり、また社内で文章力・日本語力を強化していく体制もできたので、今期は僕がCSから徐々に離れていき、二人で回していける体制に移行できればと思っています。

 

CSはある程度目処が立ってきたので、今後の採用のメインはエンジニアです。

会社規模は10人前後までと考えているので、エンジニアはあと二人くらいのイメージです。

スタートアップ的な勢いでやっているわけではないし、やっぱり無名の小さい会社は採用が大変すぎるので、「人手が足りないからリソース確保のため」の採用ではなく、「うちの会社やサービスをよりレベルアップさせることができるいい人がいて、カルチャーに合えば」というスタンスでじっくりいこうと思っています。

ご連絡頂いて1〜2時間ほどラフに話をするといった感じのこともよくあるので、少しでも興味がある方がいれば、Twitterコーポレートサイトから気軽にご連絡頂ければと。

 

特にboardに関しては、前述した通り、機能面・非機能面ともに、現時点でわりとしっかりしたレベルでできていると思っていますが、これを更にレベルを上げていきたいと思っています。

そのため、スタートアップ的なスピード感というよりは、時間をかけて、通常より高いレベルに引き上げていくようなスタンスで仕事をしたい方の方が向いているかもしれません。

直近では、品質管理やSRE・DRなどに力を入れてやっていくので、この辺が強い方はぜひといったところですが、小さい会社なので、特定分野だけということはなく、「事業に必要なことをやっていく」スタンスになると思います。

 

今後の方向性

よく「受託はまだ続けるの?」と聞かれるのですが、今のところやめるつもりはありません。

受託をやりたいメンバーもいますし、boardだけをやっていると、どうしても知識・経験の幅が狭まってしまうと思っています。

boardは、僕のこれまでの十数年のコンサル・受託の中でお客さんの業務を数多く見てきた経験がとても役に立っていて、これがあるからこそ考慮できるものがたくさんありました。

うちの会社は、僕自身を含め、何か特定の技術や分野に特化するようなタイプはいないので、技術的にも業務的にも、常に引き出しが増えていく環境があることはとても大事で、そういう意味で、受託はとても大きな役割を担っていると思っています。

baordに関しては、「10人の会社で1万社が使うサービスにしていく」というのを最近よく言っています。

これは成長や売上のための数値目標ではなく、「営業・運用に人手をかけない仕組みを作っていくため」の目標みたいな位置づけです。

これについては、また別途詳しく書きたいと思います。

boardの価格戦略

戦略というほどのものはないのですが、boardの価格に関する方針について書きたいと思います。

 

最初にうちの会社について簡単に書くと

・受託をやりながらサービス開発している
・上場もバイアウトも目指さない。身の丈に合ったサービス開発・運営
・会社の規模(人数)を大きくしない。10人前後まで。(現在8人)
・営業・マーケティングにコストはかけず地道に伸ばしていく

というスタンスでやっていて、boardは現在、有料登録が1700社を超えたところといった状況です。

詳しくは以前書いた下記をご参照頂ければと。

tamukai.blog.velc.jp

 

boardの料金体系

boardの料金は、
・プラン別料金
・有料アドオン
・郵送代行
の3つに分類されます。

プラン別料金は、Personal(980円)、Basic(1,980円)、Standard(3,980円)、Premium(5,980円)の4段階で、基本的にはユーザ数に応じてプランが分かれています。

Premiumプランの50名以上の場合は1ユーザ月額216円で追加することができます。

有料アドオンは、現在4つあり、月額324円または540円です。

郵送代行は、1通あたり170円(切手代込み)です。

the-board.jp

 特徴としては、以下の点かと思うので、その辺の背景を書いていきたいと思います。
・提供している機能に対してとても安い(と言われる)
・有料アドオンという形態を取っている
・プランは人数による違いがメインで機能差は少ない

 

リリース時に料金はどのように決めたか

ベータ期間中に知り合いから、「仕事で使うものを無料で使いたくないので、早く有料スタートして」って言われて急いで検討したので、正直なところ、あまり深く考えていませんでした・・・。

boardは、一般的な請求書サービスと中堅向けのERP・業務システムの中間に位置するようなサービスですが、入口としては請求書サービスと比較されることが多いだろうなと思っていたので、他の請求書サービスの価格帯をある程度参考にして決めました。

また、バックオフィスの経験をしてから起業する人はほとんどいませんので、boardを使うことで、最低限やらなければいけないことや見なければいけない数字などがわかるようにしたいという思いもboard開発の目的の1つです。

自分自身が起業した直後のことを考えると、バックオフィスのサービスに月数万円は出せないなあという感覚があるため、起業直後から使える価格帯にしたいと考えていました。

今から思えばもう少しちゃんと考えれば良かったのかなとは思いますが、後悔はしてないし、仕入原価がかかるものでもないので、この価格帯に決めた以上は、これで事業として成立させるのが僕の仕事という考え方でやっています。

 

かなり機能が増えても基本料金の価格改定はしていない

料金は2014年のリリース時から変更しておらず、当時でも「安い」という反応が大半だったのですが、それから相当量の機能が追加されているため、最近では「安すぎて心配なのですが」「もう少し料金を上げてもいいのでは?」「数倍でも使いますよ」と言われることが多くなりました。

ただ、今のところ、機能が増えても料金は変えていません。
*税込価格で金額をそろえたので、消費税増税の時はどうするか迷っていますが・・・

「機能追加によって提供できる価値が増えたので価格を改定する」というのはよくある話ですし、提供価値が上がっているのであれば当然そうなると思うのですが、その機能が必要ないユーザにとっては単なる値上げでしかないので、サービス提供者側の理論だなあと感じています。

特にboardのターゲットユーザである中小企業の場合、今の機能でも十分ということも多々あります。その場合、値上げは満足度の低下を招くし、何よりも「また値上げするかもしれない」というように、サービスに対する「安心感」が損なわれてしまいます。

最近、弊社で使っている、あるサービスの月額料金が倍になる価格改定があったのですが、さすがに倍はキツく、最初からこの価格なら導入していないなと思いつつ、乗り換えを検討し始めました。

 

boardのように、営業・マーケティングをほとんどやらずに、あまり表に出ないで地道に伸ばしていくスタンスでやっていると、値上げによって売上が増えることよりも、そこで失われる安心感・信頼関係の毀損のダメージの方が大きいなと。

あとは、価格が上がるほど営業コストもかかると思っています。うちのように営業がおらず、「営業せずに売る」という方針を軸に考えた場合、あまり価格は上げられないと考えています。

 

また、「上のプランほど使える機能が多い」というパターンも考えたのですが、ユーザ視点で考えると柔軟性がなく、「上のプランのうち、この機能だけ使いたいだけなのに」というケースも結構あるように思います。

 

そのため、boardのプランは人数ベースで機能差は最小限にし、機能が増えてもプランの料金は変えずに、「これはプラスαで頂きたいなあ」という一部の機能を「有料アドオン」という形で、必要な人のみ払って頂くという方法を取っています。

ただ、有料アドオンは増やしすぎると「結局いくらかかるの?」というのがわかりにくくなるため、あまり安易には有料アドオン化しないように気をつけています。

今のところ有料アドオンは4つしかなく、ほとんどの追加機能は標準機能として追加しているのですが、プラスαの機能で開発規模が大きかったものを中心に、有料アドオンとして提供しています。

有料アドオンも、月額324円・540円といった価格帯なので、個別相談会などで価格を説明すると、笑われることも多いですがw

 

営業・マーケティングコストをかけられないゆえの選択

boardは、リリース以降、ほとんどの月で有料継続率が99%以上を維持しています。
*3月だけ退会数が倍くらいになるのですが、たぶん期が変わる会社が多いからですかね。

通常、価格が高い方が解約判断がシビアになるように思います。boardの場合、費用対効果が高いと感じて頂いていることが多いので、その結果、解約率が低くなっているように考えています。

うちのように、営業・マーケティングにコストをかけられない場合、新規獲得を急激に増やすということは難しいです。そのため、一度使い始めてくれた方には、多少安くても長く使ってもらう方がありがたいと考えています。

もちろん、長く使ってもらうためにはシステムそのものの価値が第一なので、ここ3年間は毎年40回以上リリースして、継続的に改善・機能追加を続けています。ただ、ユーザさんの中での意思決定(導入判断)としては、価格と価値のバランスは重要なので、それを「費用対効果の高さ」重視に寄せている感じです。

 

ターゲットがぶれないための価格設定

これは完全に後付けというか、「こういう効果もあるな」と思ったものですが。

業務システムの場合、小さい会社から大企業まで全部にとって使い勝手が良いものというのは無理だと思っています。UI的な意味ではなく、システムの設計としてニーズが異なります。

アップセルを狙うためには、どうしても規模が大きい会社をターゲットにしていく必要があると思っていて、そうすると、当初のターゲット層とずれてきます。

その結果、大企業が増えて売上は向上したけれど、元々使ってくれていた小さい会社からすると使いにくくなった、というのは避けたいと考えています。

実は最近、自分自身が他のサービスを使っていてそう感じることが何度かあって、改めて、「あー、やっぱりターゲット層を上に引き上げるとこうなるんだなあ」と思ってたりします。これはビジネスとしては悪いことではなく、ただ自分がそのサービスのメインターゲット層ではなくなっただけなのですが、使いづらさを感じてしまうのは正直あるなと。

そのため、boardは「数人〜数十人規模」がメインターゲットというのはぶらさず、「その規模で無理なく払える金額」で、サービスを提供し続けようと考えています。

 

この価格戦略の課題

売上の成長率が上がらない

このスタンスは、当然、客単価は上がりません。

リリースしてから4年ほど経っていますが、初期の頃と比較すると、1アカウントあたりの平均単価は1.5倍程度で、ほとんど上のプランを使う会社が増えた分、という印象です。

うちは資金調達もしていないし、「いつまでに売上をここまで伸ばす」といったプレッシャーも目標もありませんので、のんびりはしていますね。


ただ、資金力が豊富なわけではないので、それでも十分利益を出せるような運営をするようにしています。

基本的に営業も広告もしておらず、マーケティングコストがほぼかかっていない状態で、内部の人件費とサーバやセキュリティ対策関連のコストがほとんどです。

人件費も、開発は僕を入れて2人、CSは最近2人体制になったばかりです。開発とサポート以外で人手がかかることを可能な限り減らして、最小限の人数でやっています。

代理店が機能しにくい

これはリリースしてから気づいたのですが、低価格だと代理店制度がほぼ機能しないですね。代理店にとって取り分が少ないので、boardを積極的に売ろうとするメリットがないので。

そのため、現在代理店として紹介が増えているのは、税理士事務所など既存クライアントに対してboardを紹介しているケースですね。

価格が低いと、広告もペイしにくいですし、売り方の選択肢が狭まるということを後から気づきました。

 

おまけ

いち開発者として、価格改定に伴う対応は、面倒だしリスクもあるので、正直気が乗らないんですよね・・・。

その時間・労力・神経を、他の開発に回したいという思いもあります。自分の中では、経営者として短期的に売上を増やすことよりも、boardを強くして中長期的な売上の土台を固める方が優先度が高いんですよね。 

受託の会社が自社サービスをリリースして4年が経った現在地

8/19でboardの正式リリースからちょうど4年が経ちました。

有料アカウントは1500社を超えたところで、会社全体の売上の4割ほどにまでに成長してきました。
単価が安いサービスなので、1500社でやっと4割かという感じがします。

現在、boardにフルタイムでアサインしているのは3人で、エンジニア1名、CS1名、自分がプロダクトオーナー&開発者&CSといったメンバー構成です。

他のメンバーは受託を軸にスポットでboardに入ったり、総務をしながらテストをやったりといった感じで兼任しています。


boardに対するスタンス

これは当初から変わらず、「boardだけでやっていくぜ!」という感じでもなく、急激な成長を目指すわけでもなく、自分たちにできることを自分たちのペースで、着実に続けています。

相変わらず営業もマーケ担当もおらず、ようやくCS専任のメンバーが入り、僕の手が離れつつあります。
まさか、4年目まで、有料アカウントが1000社を超えても社長が1人でCSやることになるとは思ってもいなかったですw

*ちなみに、昨年夏頃からさすがに1人だときつくなってきたので、問い合わせが多い箇所の改善などを続けたところ、導入社数が倍増しても問い合わせ数が横ばいだったので、そういった改善も大事だなと思いました。

 

ここ1年以上、外向けの活動はほとんどできておらず、日々、ひたすらサポート・個別相談会・開発をやっている状況です。
なんせ、僕の今年の交通費精算、まだ片手で数えられる数ですw
そのくらい引きこもってサポート・開発だけをやってます。

「いいもの作れば売れる」という時代ではないのは重々承知ですが、小さい会社は知名度や露出では戦えないので、サービスそのものでは負けない完成度にしようと、地道に改善を続けています。

ちなみに、リリースの回数は以下で、毎年同じようなペースですね。
2014年:25回
2015年:36回
2016年:43回
2017年:49回
2018年:27回(8/19現在)

初期の頃から続けている開発ロードマップの公開や、サポートの回答時間の中央値の公開も続けています。

 

そして、「新規獲得より既存ユーザ」というスタンスも変わらずなので、サポートを一番大事にしていて、全回答時間の中央値は現在でも10分を切っています。

最近のカスタマーサクセスの流れとは真逆ですが、「来た問い合わせに全力で対応する」という受け身のスタンスで、ただ、そのやり取りのクオリティの向上にひたすら取り組んでいます。(これについてはまた別の機会に書きたいと思います)

 

boardはこんな感じで、何か特別なことをするのではなく、粛々と地道な改善を継続していて、すごくありきたりですが、やはり「継続すること」「1つ1つのレベルを上げること」が大事だなと思っています。


受託

boardがかなり成長してきましたが、引き続き受託もやっています。

まだboardだけでは売上が足りないというのもありますが、受託の方が好きなメンバーもいるし、boardだけやっていると引き出しが少なくなってしまうので、今後も受託は続けていくつもりです。

ただ、昨年から僕がboardのサポートにかかりっきりになって受託に入れなくなってしまい、受託は実質3人で回しているので、お待たせしたり、お断りすることが増えてきてしまっています。

とはいえ、人数をどんどん増やすつもりはなく、「10名前後まで」と考えているので、悩ましいところです。

 

勤務時間の短縮

今期から勤務時間を1時間短くしています。

元々、社員のみんなはほとんど定時で帰っていたし、boardの成長に伴って労働集約的な割合がぐっと減りました。

そのため、勤務時間を1時間減らしても、特に売上にネガティブな影響はありませんでした。

ちなみに、勤務時間が短くなったことについて、社外の人からは色々リアクションをもらうのですが、社内のみんなはわりとノーリアクションなのがうちの会社っぽくて面白いですw

 

会社の人数を増やさないという方針

今に始まった話ではないですが、今まで以上に、「人数をどんどん増やすことはしない。10人前後まで」という方針を明確にして、そのための取り組みに軸を移しています。

boardの問い合わせを減らすための改善や、こちらから営業的なことをしない方針など、とにかく可能な限り人が動く・介在することを減らしていくようにしています。

boardにフルタイムで関わっている3人なので、3人で1500社を回せているのは十分効率的だとは思いますが、ここはもっと追求していきたいと思っています。

そのため今後は、「導入社数が増えても運営に関わる人数を最小限に留めるための仕組み作り」がテーマで、自動化・安定性・問い合わせを減らすための改善などを今まで以上に力を入れていくことになりそうです。

 

経営的な変化

「売上の座布団を増やす」という言い方をしているのですが、ストック売上(納品がなくても毎月上がる売上)を増やす取り組みを5年ほど前から続けています。

基本的には、短期的な売上よりも中長期的な売上の仕組みを作っていくことを優先しています。

boardが一番大きいですが、それ以外も加えて、今期売上の65%ほどがストック売上になりそうです。

 

これは、受託の会社の経営的には本当に大きな変化です。

起業して1年目の頃にあった「今月売上が20万しかない!」みたいなことがないので、キャッシュフローに追われることがなくなり、より本業に集中できるようになりました。

個人でも会社でも、経済的な余裕がないとやれることが制限されてしまうと思っているので、そういう意味で、5年ほどかけて売上の座布団を積み上げていくという取り組みは、本当にやって良かったなと思っています。

 

今後

基本的に、大きくは変わらず、今のスタンスでやっていくつもりです。

boardに関しては、継続的に改善・機能追加を続けていきつつ、SRE・パフォーマンス・自動テスト・品質管理周りが今後の重要なテーマになりそうです。

 

会社の人数も10人前後までと考えていて、現在7人なのであと3人。
10人の会社で、1万社が使うサービスを回せたらいいなと思っています。

そして、こんな小さな会社で働いてくれているみんなにはもっと還元していきたいと思っています。

 

エンジニアもあと1〜2名は採用する予定ですが、のんびり考えているので、「まだすぐには転職しないけど、興味があるので話だけ聞きたい」くらいのレベルで全然OKですので、ご興味があればぜひ声かけてください。