ヴェルク - IT起業の記録

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

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ですので、ご興味があればぜひ声かけてください。

 

受託の会社が資金調達せずに自社サービスを立ち上げて、有料導入1000社に行くまでの経営・受託とのバランス(BPStudy発表時の補足)

以前からブログで「受託と自社サービスの両立の取り組み」を書いてきましたが、ついに、2017年11月1日にboardの有料アカウントが1000社を突破しました!

f:id:fw_tx76129:20171205124843p:plain

1000社突破したらに、これまでの取り組みや現在のスタンスなどの総まとめを書こうと思ったのですが、8月のBPStudyで「受託の会社が調達せずに自社サービスを立ち上げ事業として成立するまでの企画・開発・サポート・マーケティング」という発表をしまして、これらのテーマについては、このスライド以上に書くことがなかったので下記のスライドを見て頂き、ここではそれ以外のことについて書きたいと思います。

 

 

BPStudyのスライドは、はてブでもたくさんコメントを頂いていて、「受託メンバーとの兼ね合い」が結構多かった印象でした。

 なので、今回は土台になっている、経営や受託とのバランスについて書きたいと思います。


経営方針

ヴェルクは受託開発の会社としてスタートして、2017年11月で7期目が終わりました。

現在自分を入れて6名の小さな会社なのですが、人数をどんどんと増やして拡大していくつもりはなく、10人前後を一つの目安と考えています。

元々、何か特定の技術を扱いたいとか、サービスを立ち上げたいとかで起業したのではなく、「この業界の変化は早いので、それに対応していけるチームや環境を作って、自分含め、エンジニアが継続的・安定的に技術に取り組める環境を作りたい」というのが起業のきっかけです。

そのため、当初から上場やバイアウトといったものは全く考えていません。というか、そういう感じでやっているので、投資対象として向かないですね。

僕の経営者としての仕事は、上記を実現するために、

  • 短期的には、きちんと利益を出せる受託案件を取ってくること
  • 中期的には、経営を安定させる事業を作ること
  • それを、社員にはオーバーワークさせず定時で帰ってもらい実現すること

だと思っています。

自分の感覚的には経営者というよりは事業責任者に近くて、経営者っぽいことはあまりやってません。社内で、経営理念とか方針とかそういう話をしたこともないですし・・・。


これらのことに取り組むにあたって、一つの重要なテーマとして考えているのが「労働集約型」からの脱却です。

受託開発は労働集約なので、人数を増やせばある程度それに比例して売上も上がりますが、拡大とともにクオリティの維持が難しく、利益率にも限界があります。

また、小さい会社にとって採用は本当に本当にハードルが高く、しかも人口は減少傾向なので、「人を増やすこと」に依存したモデルは厳しいと感じています。

社内で冗談半分で「10人で利益を10倍にする方法を考えるのが自分の仕事」と言ってたりします。数字は具体的な目標ではなくあくまでイメージですが、2倍とかだと「労働集約型のまま頑張る」という選択肢が残ってしまうので、根本的にビジネスモデルを別で考えないといけない「10倍」にしています。

そのため、ここ3〜4年の僕のミッションは、「中期的に経営を安定させる事業を作って、労働集約型のモデルから脱却すること」で、その一つがboardでした。


ストック売上を増やす

「中期的に経営を安定させる事業を作る」に関連して、僕がずっと社内で言い続けていたのが、「ストック売上を増やす」でした。

受託開発の場合、基本的には「納品」してから請求です。普通に数ヶ月単位で大きな納品がない時期があって、そうするとキャッシュフローが悪化します。

ちなみに、今までで一番預金残高が少なかったのは、起業4ヶ月目に20万という時がありました。その後すぐに入金の予定があったので大丈夫でしたが、キャッシュフローの計算を間違えていないかヒヤヒヤものでした・・・。

そういうリスクを減らすためにも、納品の有無に関わらず月額でお金が入ってきて、売上の座布団になるようなものを増やしていこうという方針です。

最近は、よく「サブスクリプション」という言葉を聞くようになりましたが、当時はそういうことは全然考えておらず、とにかく「売上の座布団を増やしたい」という意識でした。

*「売上の座布団」という言い方が一般的かわかりませんが、僕はよく使っていて、保守のように、納品有無に関わらず毎月請求するタイプのものを指しています。

 

とは言え、すぐにそんな事業を作ることはできませんし、そこに賭けて社員にリスクを負わせるわけにはいかないので、まずは堅実に保守を増やしていくことから始めました。

ちなみに、「保守だけ受ける」ということはやらず、保守がある開発案件を優先するというスタンスです。

ただ、保守ばかり増やしていくと、そっちに手が取られて開発案件ができなくなってしまうし、開発者としては面白くないので、そこはバランスよく、また運用保守に手がかからない仕組みにするように気をつけていました。例えば、自動化できるものは自動化したり、運用回避な要件は避けたり、運用上定常的なオペレーションが発生しないようにしたり。

少しずつでも売上の座布団が増えてくれば、納品ベースで稼がないといけない売上は多少下がっていきます。その積み重ねが余力になってくるし、その余力が自社サービス開発の時間を捻出します。

その後は、知り合いの医学生とのコラボで医療系学生向けの解剖学のアプリをレベニューシェアで出したりしつつ、2013年(3期目)に初めての本格的自社製品「Patto」、2014年(4期目)に「board」をリリースと、自社サービスをリリースしていきました。

毎年期末にその期のまとめとして、売上や振り返り、来期の見込みや方針などを社内で話しているのですが、その時の資料を見返してみると、3期目(2013年11月)の終わりに初めて「ストック売上」という言葉を使っていて、4期目(2014年11月)の終わりに「3年後にはストック売上で50%」という目標を掲げていました。

普段具体的な数値目標を上げることはほとんどないのですが、今から思うと、だいぶ思い切った数字ですね。たぶん、全く具体的に考えていなくて漠然と上げた数字です・・・。

で、その3年後というの7期(2017年11月)なのですが、めでたくストック売上は無事50%を超えました。言ってみるもんですね。


ほどほどの売上に抑える

boardとは関係なく起業当初からの取り組みですが、それぞれの給与に応じて「このメンバーの受託での年間売上はこのくらい」みたいな目安が自分の中にあって、基本的にそのラインまでいったら、ある程度受託へのアサインを抑える、というスタンスでやっていました。

そのため、年間を通しての稼働率は平均7割程度で、空いた時間は、技術的な検証だったり、自社のスマホアプリを作ったりしてました。

各メンバーがもう1つ案件できるくらいの稼働率なわけで、その分も受託で埋めた方が利益を出せます。ただ、そうすると、「次」に繋がる取り組みができないので、稼働率は7割程度に抑えるようにしてきました。

例えば、boardの前に「Patto」というスマホアプリ関連の製品をリリースしているのですが、この時は、boardと違って僕ではなく社員がメイン開発者だったので、「最低限上げて欲しい売上を上げた後はそのメンバーは受託から外し、自社製品の開発に注力して、全体として売上が足りなかったら自分が稼ぐ」という形で進めました。

経営者として、もっと売上を上げられるのに抑えるというのは難しいところですが、リソースは有限なので、中期的に考えてどこに時間を割くべきか、ということを考えるようにしています。

ただ、「それほど多くはなくてもボーナスは出せるレベルの売上は維持する」というのも大事にしていて、「稼働率7割」というのは厳密なルールではなく、状況に応じてバランスも重要です。

社員にとっての受託と自社サービスの関係

僕含め、うちの会社はわりと受託が好きな人が多く、よく聞く「受託がツライから自社サービスを」みたいな思いでは全くやっていません。

2年ほど前に、うちの3人のエンジニアそれぞれに、「今後、受託とboardとどっちやりたい?」って聞いたところ、「boardより受託」「どっちでもいい」「boardやりたい」という形できれいに分かれました。

この前のBPStudyの資料のはてブコメントを見ていると、「受託と自社サービスのメンバーが仲悪くならないの?」「受託をやっているメンバーのモチベーションは?」といったコメントがちょいちょいありましたが、意外と社内ではboardの開発は人気ないのですw

そもそもうちの会社は自社サービスをやりたくて集まったメンバーではないですし、boardのような業務系サービスの場合、ほとんどのエンジニアにとっては直接関係しない業務を扱っています。

なので、あるメンバーが「boardで扱っている業務に縁がないので、業務を聞きながらやっていくことになるから受託と大きく変わらないと思ってる」って言ってたりしたのですが、エンジニアにとってはドッグフーディングできるものではないので、この壁は高い気がしています。

とある知り合いの会社で、B・C向けそれぞれのサービスを出しているところで、中のエンジニアには圧倒的にC向けサービスの方が人気あるという話を聞いて、業務系サービスあるあるな気がしています。


また、うちは、数ヶ月〜半年程度で終わる小規模な案件が多く、案件ごとに新しい試みを取り入れやすいので、それを理由に「受託の方が良い」と言っているメンバーもいます。

あと、受託案件で大変な状況になることはほぼないですし、みんなほぼ毎日定時に帰っているので、受託を積極的にやめる理由もないのかなと思います。


受託と自社サービスのアサインのバランス

現状、「受託チーム」「自社サービスチーム」という形ではっきり分かれているわけではなく、「boardも受託案件同様アサイン先の一つ」で、行ったり来たりしています。

もちろん人によって割合は異なり、例えば、「boardより受託が良い」というメンバーはほぼ受託をメインにしています。

唯一「boardをやりたい」と言っているメンバーは一番若手で、まだまだ多くの経験を積んでほしいので、年間を通して半々くらいになるようにしています。

受託でも自社サービスでも仕事の内容は開発なわけで、個人的には「受託」「自社サービス」といった区別ではなく、各個人が、モチベーション高くできる仕事だったり、足りないものを身につけられる仕事だったり、もしくはつまらないけどやらないといけない仕事かもしれないけど、そういったバランスを大事にしている感じです。


受託をやっているメンバーに負担をかけない

自社サービスを開発する上で、自分の中で決めているポリシーとして、「受託をやっているメンバーに負担をかけない」というものがあります。

「受託と自社サービスの両立」というと、どうも受託の利益を食いつぶしながらサービス開発をしている印象を持たれることが多いのですが、その方法をとると、受託側に負担がかかってしまうので長く続きません。

「サービスがリリースできるまで大変だけど頑張ろう!」みたいな感じでメンバーにオーバーワークしてもらうのは嫌だし、うちはそういうノリの会社ではないので、受託に食わせてもらいながらサービス開発をするというスタンスはとりませんでした。

余談ですが、起業直後に、昔からお世話になっているとある先輩経営者から、「テンション・勢い・イベントなどの"波"に依存した経営をしていると、次はもっと大きい波が必要になって、結果的に長続きしない組織になってしまう」と言われたのがとても心に残っています。

なので、「自社サービスを開発する」というのをイベントにはせず、淡々と進めていました。


boardの場合は、元々僕の個人プロジェクトから始まって、リリース後1年半ほどまでは、僕も普通に受託をやっていて、自分がいち受託メンバーとして上げなければいけない売上はあげつつ、boardを開発していました。

boardの売上が増えてきたら、徐々に僕が持っている受託案件を減らすという進め方で、boardに関わるコストをboard自体で賄えない時は僕が受託で稼ぐというスタンスでした。

これは、自分自身が経営者で、労働時間の概念があってないようなものなのでできたことですが、たっぷりお金がある状況でない以上、どこかで無理をして捻出しないといけなくて、それを社員にやらせるわけにはいかないので、そこは自分がやったという感じです。

 

受託を安定して回すための取り組み

受託をやりながら自社サービスを立ち上げるためには、これが基本だと思っています。

受託の会社である以上、受託を安定して回せることが前提になっていて、それができていないうちは、まずは受託の方に力を注いだほうが良いと思っています。

この話をすると「それができれば苦労しない」ってよく言われるのですが、「受託が大変」という状況を解決するための自社サービスではないと思っているので、自分としては、ずっとこの課題に取り組んできました。

 

まず一番大事なこととして、「適切な価格と適切なスケジュールで受けること」だと思っています。安すぎる受注額だったり、最初からスケジュールが厳しいと、安定して受託を回すのは無理です。

うちの会社は営業がいないので、仕事を取ってくるのは僕か取締役の津久井なのですが、二人ともバリバリ現場でやっていることもあり、見積もりやスケジュールを間違えにくかったり、悪い条件でも受注しようという考えはないので、まずここはクリアできています。


次に仕事の進め方についてです。

僕は、方法論や手法には全くこだわりがなく、うまくいけば何でも良いと思っているし、そもそもメンバ・お客さん・開発するシステムの種類などによって最適な方法は異なると思っています。

基本的には「個人の能力を上げること」が一番重要だと思っていて、そのため、前述した通り、アサインにあたっては「そのメンバーにどういう経験を積んでほしいか」を考えて、受託でもboardでもアサインするようにしています。


この前のBPStudyのはてブのコメントを引用させて頂くのですが、

「オレ」が受託開発にリソースを注ぎまくらなくてもボーナス払える状態っていうのが地味に強みなんじゃなかろうか 

というものがあり、まさにこれだと思っています。


うちの会社には、定例も進捗報告も日報も週報もなく、「進捗報告はいらないから、リスクがある時だけ相談して」というスタンスを取っています。

リスクに対するアラートが適切であれば、そうそう大きなトラブルになることはないと思っています。相談する内容を間違えず、早すぎず遅すぎず。これを「リスク感覚の一致」と呼んでいます。

別に社内で「リスク感覚を一致させていこう」という話をしたわけではないのですが、2〜3年かけて、日々の仕事の中で、これを一致させるようにしてきました。

もちろん最初からうまくできたわけではなく、相談が早すぎたり、問題が大きくなってから相談に来たり。

なので、みんなに任せて放置するのではなく、最初は僕がみんなの動向・状況をかなり気にしつつ、危なそうだったらさりげなく軌道修正するようにしていました。

みんなからしても定例や進捗報告は面倒ですし、とはいえ、そういったものがないと、アラートのタイミングをミスると大変になるので、時間とともにその精度が向上していきました。

もちろん、これは一人ひとりの状況がよく見えている小さい組織だからこそできる方法だと思っています。また、最悪、自分がリカバリに入れば良いと思っていて、リカバリできるギリギリのところまでは任せておこうという感じです。

マネジメント手法は正解があるわけではなく、規模・メンバーの特性などに応じて、最適な方法を考えるべきだと思っているので、自分自身やメンバーの特性、会社の規模などを踏まえて、こういうスタンスに辿り着きました。

結果的に、この取り組みによって、マネジメントコスト・コミュニケーションコストが極めて低いチームになり、僕がそこに割く時間が非常に小さくなりました。

中途で入ってきたとあるメンバーが、「うちの会社のエンジニアって、みんなそれぞれの立場・レベルでの当たり前を当たり前にやっていて、それがすごいし、だから最低限のマネジメントでうまく回っている」という表現をしていたのですが、確かになあと思ったことがありました。

それが納品後の手離れの良さにも繋がっていて、結果的に「余裕」を生んでいます。

小さい受託の会社にとって、創業社長が現場にがっつり入らなくても回るようにするというのは一つの大きな壁で、最初の3年かけてそれができたのが、board開発の土台となっていると思っています。


まとめ

すごく高利益率の仕事をしているのであれば別ですが、普通に受託をやっていると、自社サービスを開発している時間はなかなか確保できないと思います。 うちの場合、決して安い単価で低利益の仕事をしているわけではありませんでしたが、ビジネス構造としては普通の受託の会社でしたので、時間的資金的に、自社サービスを開発するための十分な余裕があるわけではありませんでした。

そのため、「売上の座布団」を作っていって、少しずつ余裕を作るという取り組みを続けてきていたのは、ひとつの重要な取り組みだったなと思います。

急がば回れで時間をかけてやってきているので、「今すぐサービスを立ち上げたい、軌道に乗せたい」というケースにおいては不向きな進め方ですが、受託をやっていると直近の売上は立てられるので、特にtoBであれば、じっくり着実にやっていくという方法もありなんじゃないかなと思っています。

現在、boardがこれだけの規模になってきても、うちの会社では、どこか「案件の一つ」みたいな雰囲気があって、僕自身も、各メンバーのスキルや経験、受託の営業状況、boardの開発予定などを考えて、どういうアサインが良いかというのを考えています。

経営は「ヒト・モノ・カネ」といいますが、残念ながら「カネ」は潤沢にあるわけではないので、「ヒト・モノ」が重要になります。

ただ、小さい会社にとって、採用はほんとに難しく、ずっと課題です。なので、今いるメンバーを大事にしたいし、もっと成長するための機会・環境を継続的に用意したいと思っています。

そういうものの積み重ねが、受託をやりながらboardを生み出せる土台になったんじゃないかなあと思っています。

B2B SaaSの個別相談会を100回やったので振り返り

1年半ほど前に始めたboardの個別相談会、4月に実施回数が100回を超えていたので、個別相談会を開始した経緯や効果などを振り返ってみたいと思います。

 

個別相談会とは

説明会のような大人数が集まる形式ではなく、1社ごとに打ち合わせ形式で、デモ・質問・相談などに対応しています。

本来はこちらから伺いたいところなのですが、うちの会社では営業がいないのと、低価格なサービスのため、訪問してしまうとコスト的に厳しいため、弊社に来社頂くか、Googleハングアウトを使ったオンラインで実施しています。

 

個別相談会は、週2枠用意して、予約制で実施しています。

予め枠を用意しておくことで、こちらは予定をブロックしておくことができるので、都度日程調整ではなく枠を用意して予約制という形を取りました。

始めた当初は週2枠埋まることは珍しく月4〜5件くらいでしたが、ここ半年ほどは週2枠では足りず、週4〜5件入っていることが多いです。

 

個別相談会を始めたの経緯

個別相談会を始めたのは、サービス開始してから1年ほど経った2015年9月でした。

受託の会社なのでサービスのことは右も左も分からず、最初の1年はサポートや継続開発を軌道に乗せることで手一杯でしたが、この頃になると、ある程度慣れてきて、ようやく、サービス開始当初から課題として感じていた、「スムーズに導入してもらうこと」に対する対策としてスタートしました。

 

個別相談会の基本的な構成

個別相談会は以下のいずれかの内容で行うことが多いです。
・基本的なデモを実施して、随時ご質問頂く
・最初から質疑ベースで進める

事前にある程度boardを使い込んだ上で個別相談会にいらっしゃる方は質疑ベースになることが多いですが、割合としては8割くらいがデモベースです。

デモの内容は、質問による中断がない状態で20分くらいの内容で、
・基本的な構成・考え方を理解してもらう
・どういった機能があるのか、といったことを知ってもらう
といった内容が中心で、個別相談会から帰って自分でやってみてもらう際に、迷わないで使えるようにすることを目標にしています。

 

デモの内容は、毎回改善を繰り返しています。

聞いているだけだと飽きてしまうので、なるべく長くなりすぎず、でもしっかり説明するというバランスを試行錯誤しています。

ここ1年ほどは、デモは僕ではなく別のメンバーがやっているので、僕が気になった点をその場でメモして、終わった後に「ここの説明がわかりにくそう」「ここの説明が冗長だった」などをフィードバックして改善するようにしていて、かなり完成度が上がっています。

実際は、デモの途中で質問があったり、デモの後に自社の事業・業務内容を伺ってどういった活用方法が良いかといった話をすることが多いので、1時間〜1時間半ほどになることが多いです。

 

また、たまにboardとは関係なく、バックオフィス業務全般の効率化の相談や、社内システム・セキュリティについてなどの相談があることもあります。

boardの個別相談会は、今のところ必ず僕が出席していて、システム・経営・経理・会計・業務効率化などを、board以外の話もひと通り対応することができます。

あとは、稀に、「どういう会社か見ておきたかった」「ブログに書いてあったDIYオフィスをみたかった」「田向さんに会ってみたかった」というのもあります。

 

無理に売り込まないスタンス

boardの個別相談会なので、当然boardの説明をするのですが、僕自身、エンジニアであって営業ではないためか、「なんとしても売ろう」という意識が薄く、「売り込む」というスタンスではなく、「正しく伝える」「課題を解決する」といったスタンスで臨んでいます。

そのため、ニーズがboardと合わない場合、「○○(他のサービス)の方が合っていると思いますよ」という感じで、正直に伝えるようにしています。

 

個別相談会のメリット

個別相談会のメリットは以下のような点があると考えています。

間違った使い方を防げる

間違った使い方をして、「このシステム使いにくい」「自社にとってメリットない」と判断されてしまうのは、お互い不幸です。

個別相談会のデモでは、単なる使い方だけではなく、
・どういう意図で作られているのか
・どういうシーンを想定しているのか
なども説明するようにしています。

正しい使い方で合わない場合は仕方ないですが、「知らなかった」「勘違いしてた」で満足度が下がることを回避できます。

有料登録して頂ける割合が高い

デモの中で概要を伝えることができるので、その後スムーズに使えることが多く、結果として個別相談会に来た方がそのまま有料登録して頂ける割合が非常に高いです。

有料転換(お試し登録から有料登録への転換)率は、全体では14%前後ですが、個別相談会参加者に限定すると65%前後です。

個別相談会に来る時点である程度真剣に考えているということもありますが、「概要をつかむ」という最初のハードルを個別相談会でクリアできることも非常に大きいのかなと思っています。

また、boardの概要や基本的な設計思想を理解した上で使うと、より有効に活用できるので、おそらく継続率にもプラスになるんじゃないかなと思っています。

問い合わせだけではわからないことを把握できる

業務課題や困っていること、システム導入におけるポイントなどを直接聞いたりディスカッションしたりすることができます。
話した結果、実はあまり重要ではなかったり、ちょっとした工夫で改善できることも多く、要望や課題が、必ずしも額面通りとは限らないのため非常に重要だと思います。

今後の開発のヒントになる

元々、コンサルっぽい仕事をしていたり、受託でもわりとお客さんの方にがっつり足を踏み込むスタンスでやることが多いので、こういった話からニーズや課題を拾って解決策を考えていくのが好きで、それを今後のロードマップに反映していくといったことをやっています。

お互いを少しは知ることができる

僕個人としては、ずっと受託をやってきた人間なので、やはり顔を合わせずにずっと仕事をするというのは、なんか違和感があります。
低価格なサービスなので、全員に会っていたらそれだけで赤字になってしまうので無理ですが、できるだけ面と向かう機会を作りたい、1時間しっかり話す機会を作りたいという思いはあります。

それによって、どういう人か、どういう会社かを把握できるので、チャットサポート時の説明の仕方を調整したりしています。

また、表現が非常に難しいのですが、問い合わせが雑な方は少なからずいるのですが、個別相談会参加後は、丁寧になったり、無茶なことを言ってこなくなるといったことがよくあるので、お互い少しでも知っているということは大事だなと感じています。


個別相談会の課題

体制

個別相談会の申し込みの際に簡単なアンケートをお願いして、事前にある程度はどういう業態なのかを把握できるようにしていますが、それでも蓋を開けてみないと、どういう内容になるかわからないことが多いです。

今のところ必ず僕が参加しているので問題ないですが、単にデモにとどまらず様々な話になることが多く、結果的に扱うテーマが広くなります。今のクオリティを維持しようとすると、簡単に代わりができないので、開催数をなかなか増やすことができません。

オンラインの場合の快適さ

個別相談会は、弊社にご来社頂くか、Googleハングアウトを使ってオンラインで実施していますが、オンラインは、相手側の環境によって快適さがかなり左右されてしまいます。

度々切れてしまったり、音が割れて聞き取れなかったり、そういったトラブルはそこそこあり、もう少しどうにかならないかなあと考えています。

 

まとめ

boardは、マーケティングコスト(広告費などだけではなく社内のリソースとしても)をほぼかけていないのですが、個別相談会にはしっかり時間を割くようにしています。

有料への転換率を高める施策というのは色々あると思いますが、そういった色々な手は打たず、基本的に、個別相談会への参加を勧め、直接顔を合わせて話をするということを大事にしています。

小さい無名の受託会社がサービスを伸ばすにあたって、他と同じことをやっていてもダメで、自分たちの強み(受託の経験)を活かすことを考えた時に、個別相談会で対面して、課題を聞きながら説明していく、というのはぴったりでした。

受託で業務系のシステムをずっとやってきたので、それで増えた引き出しが役に立ってるなあと思います。

 

競合ではなくユーザと業務の現場をみてサービス開発する

昨年ぐらいから、「◯◯さん、ものすごくboardを意識して、調査しているらしいですよ。やっぱり競合として意識しているんですか」みたいなことを言われることが増えました。

2年ほど前までは、競合ではない分野のB2BのSaaSの人たちから、「開発ロードマップの公開」「即レスのチャットサポート」「サポートの回答時間の公開」などの取り組みに興味を持って頂いて、「真似させてもらいます!」みたいなことを言われることはあったのですが、ここ1年ほど、明確に「競合」という言葉が出てくるようになって、ようやくそういう土俵に上がるようになってきたのかなあと思ってたりします。
たぶん2年前は存在を認識されていないw

最近、飛ぶ鳥を落とす勢いの某サービスの人から、「競合さんが、サポートに根掘り葉掘り仕様の質問をしてくる」という話を聞いて「なんだかなあ」と思ったのもあったので、自分の考え・スタンスを書いてみました。

競合はほとんど見ていない

boardの開発にあたっては、競合サービスはほとんど見ていません。

boardの場合、競合が請求書サービスなのか販売管理システムなのか微妙なところですが、多くの人は、「請求書」を入口にサービスを探しているようなので、たぶん競合は請求書サービスなんだと思います。

ちなみに、いくつかの請求書サービスのアカウントは持っていますが、元々boardを開発する前はそれらを使おうと思っていたので、その時に作成しました。

なぜほとんど見ないかというと、実際それらのサービスが自分が求めているものであればboardは作っていないですし、欲しいものと違った(自分自身の課題は解決できなかった)からboardを作り始めたわけです。

なので、他のサービスを見て真似していたらダメだし、影響を受けてブレてしまうのが怖い。

boardはboard。

他のサービスがどういう機能を追加していようがあまり関係ないことかなと思っています。

思想のないツギハギでは使い勝手が悪いわけで、同じ課題に対してでも、boardのアプローチと他のサービスのアプローチは異なります。

であれば、あまり競合を見る意味もないですし、その時間はコードを書いてたいという感じです。

大事にしているのは機能の有無ではなく世界観・居心地・体験

同じ分野の業務システムを作っていると、最終的にはある程度同じ機能をカバーするようになってきます。

そうすると差別化要因は機能の有無ではなく、そのサービスを通してどういったことを実現しているか、という点だと思っています。

例えばboardは、「クラウド上で請求書を作ること」が実現したいことではありません。

すごく曖昧なのですが、単に機能ということではなく、解決しようとしている課題や、サポート・開発・運用のスタンスなどを含め、「boardの世界観」みたいなものを大事にしている感じです。それは真似するものではなく、自分たちで作り上げていくもの。

とある人に要望をもらった際に、「boardの"適度な自動化と適度なゆるさ"を考えるとこんな感じじゃないですか」って言われてすごく嬉しくなりました。boardが目指しているものが伝わっているような気がして。


ターゲットとするユーザ・課題を明確にして、そこを見て開発する

boardは、ある程度業態を絞って、そこに最適化することで、機能的にも使い勝手的にもフィットする人にはものすごくフィットする、というサービスを目指しています。

それは汎用的でマスを狙った請求書サービスや販売管理システムとは別の方向だと思っているので、競合サービスを見ても、そういったものは出来上がってきません。

「競合が実装している機能 = boardユーザにとってニーズがある機能」とも限りません。派手な機能をリリースして注目を集めたけど、実際ユーザはあまり使っていないという話も聞いたりします。

ユーザのニーズは現場にしかないし、ユーザの不満・不便はユーザからしか吸い上げられないと思っています。

それは、アンケートとかそういった形式的な手法によるものではなく、サポート等を通じて直接肌で感じるべきで、そのために、僕自身がずっとサポートをやっています。

これまで1〜2週間に1回程度のリリースを繰り返してきていますが、その多くは、サポートの中で出てきた要望やアイデアです。

そして自分自身もターゲットユーザなので、ドッグフーディングしながら実装に落とし込んでいきます。

「この機能は失敗した。作り直したい」「この機能不要だった」と思ったことや、ユーザさんから「使いにくい」「業務と合っていない」と言われることなどは、この3年間ほとんどありませんでした。

それはこういう取り組みの成果なのかなと思っています。

まとめ

抽象的は話になってしまっていますが、「他のサービスよりちょっと使い勝手が良いもの」を作りたいわけではなく、既存のサービスでは解決できなかった問題を解決したいと思ってサービス開発をしています。

そのためには、ユーザや現場の業務と向き合うことが大事なんじゃないかなと思っています。

 

あと、完全に個人的な意見ですが、いち作り手として、真似して作るのは面白くないですよね。

オフィスにAkerunを導入&HappyPrintersでAkerun用オリジナルカードを制作

新オフィスに移転してから、Akerunを導入して、Akerun用のオリジナルのICカードを制作してみました。

 

ちなみに新オフィスはこんな感じ。

tamukai.blog.velc.jp

 

Akerunとは

Akerunは、後付けで、自動ロックや入退出管理ができるシステムです。

本格的な入退出管理の仕組みと違って工事不要で、月額9,500円(執筆時点)で導入できます。

SuicaなどのICカードやスマホで解錠できたり、管理画面で入退出のログなどをみることができます。

f:id:fw_tx76129:20170327210352j:plain

 

設置も簡単で、30分ほどでできました。

f:id:fw_tx76129:20170327210530j:plain

ちなみに一人の時に設置作業してたのですが、オートロックをONにするとドキドキします。(普通の鍵も持っていればいいだけの話ですが・・・)

Akerunを導入した理由

受託をやっていると、取引先からセキュリティチェックシートの記入を求められることがあります。

その中でよく聞かれるのが「入退出管理をやっているか」という点。

小さい会社なので、人の出入りは全部見えていますし大げさかなあと思っていましたが、オートロックやログが残るのが良いなと思い、移転をきっかけに導入することにしました。

同じようなスマートロックは他にもありますが、実は比較検討はしていません。

こういうものは、身近で使っている人がいて、「運用上支障はないか」という点が大事かなと思ったので、SmartHRを運営しているKUFUさんが使っていたので使用感などを聞いて、問題なさそうでしたのでAkerunに決めました。

Akerunを設置した場所

うちのオフィスは、1フロア1テナントのビルで、エレベータを降りたらすぐに受付でそこから専有エリアになるため、ビルの入口でセキュリティをかけるとエレベータがとまらなくなるという仕組みになっています。

エレベータを降りると会議室やトイレがあるエリアになっていて、それとは別の空間として、鍵がかけられる執務エリアがあります。

そのため、Akerunは、外からのドアに設置しているのではなく、執務エリアに入るところに設置しています。

f:id:fw_tx76129:20170327210429j:plain

執務エリア外に会議室やトイレがあるので、ここは1日何度も出入りします。

ICカードを使うか、スマホを使うか

Akerunは、ICカードやスマホアプリから解錠することができます。

全員両方準備して、好きな方を使うという形で運用をスタートしてみたのですが、うちの場合、全員ICカードになりました。

前述の通り、よく出入りするドアなので、スマホアプリの場合、アプリを起動しないといけないので、その分少し手間取ってしまいます。

そのため、結局みんなすぐに取り出せるICカードになりました。

オリジナルICカードを作る

ICカードは、SuicaやPASMOといった交通系カードを使うことができるので、最初は手持ちのSuicaなどで運用してみました。

ただ、普段パスケースを使っていなくて財布に入れている人は、常に財布を持ち歩くのも邪魔ですし、カードだけ出すのだと忘れそう。

なので、首から下げたいけど、SuicaやPASMOを首から下げているのもなあということで、希望者のみ、オリジナルのカードを作ることにしました。

 

まず、下記のような真っ白のICカードが売っているのでそれを購入します。

これにシールを貼っても良いのですが、シールだと古くなるとボロボロになってしまうので、直接印刷したいなと思い、こういう時はHappyPrintersさん。

 

こんな感じで直接印刷できます。

f:id:fw_tx76129:20170327205729j:plain


HappyPrintersだと、数が少なくても作れるのがいいですね。

うちの場合、オリジナルカードを使っているのは7人中4人ですが、そのくらいでも気軽に作れるので助かります。

Akerunを導入して1ヶ月が経過して

今のところ問題なく快適に運用できています。

最初の頃は、毎回カードをかざすのがちょっと面倒かなという気もしたのですが、慣れてしまえば全然気になりません。

オートロックなので鍵の閉め忘れの心配もないです。

また、清掃会社用にカードを渡しているのですが、清掃が入る曜日・時間帯のみに限定できたり、ログで確認できるので、不正利用の心配も減ります。 

 

ちなみに、カードをかざしてからの反応スピードは、大手のオフィスで使われているようなものに比べると遅い気がしますが、実運用上、特に問題はないです。

もう少し速くなるとより快適だなという感じです。

boardにおける要望の管理・開発の優先順位付けで取り組んでいること

開発の優先順位付け、難しいですよね。

ユーザの方からは日々多くの要望を頂きます。現時点でリストには500以上。
機能が足りなくて困っているケースもあれば、検討段階で「○○があれば使う」という導入判断になるケースもあります。
また、「以前要望した○○はまだですか」なんて言われることもあります。(やるとは言っていないのですが・・・)

もちろん要望以外に、そもそもboardとして実装したいと考えている機能もあります。

これらすべてを対応するのは無理ですし、それをやったら、機能てんこ盛りで、使い勝手の悪いシステムになってしまいます。

そのため優先順位を付けて取捨選択していく必要がありますが、これが色々な要素が絡んで難しい。

既存ユーザの方で機能が足りなくて困っている場合は、それによって満足度が落ちてしまうし、最悪boardから離れてしまうかもしれない。

検討中の方の場合は、それが理由でboardを使わないという判断になるかもしれない。

以前要望出したのに対応されないと不満が募るかもしれない。

でも要望ばかり対応していたら、boardとして搭載したい機能の開発ができない。

基本的に不安との葛藤な気がしますが、そんな中でどうやって整理していっているかを紹介したいと思います。

 

要望は全てTrelloで管理

要望は全てTrelloで管理しています。要望の数が多いので、Trello上で細かく分類します。

開発前のものを以下のように分類して、右側に行くほど対応が近い・優先度が高いものになります。

 

アイデアの種→アイデア(低)→アイデア(高)→要件検討中→開発準備OK→次開発予定

 

新規の要望をもらうと、このうちのどれかに入れます。

また、既存の要望の場合は、そのタイミングで、その位置で良いのか、優先度を上げるかを都度判断していきます。

 

boardでは問い合わせ管理の仕組みとしてintercomを使用しています。

intercomでは問い合わせごとにスレッドになっていて、それぞれURLがあるので、Trelloにintercomの該当の問い合わせのURLも一緒に記入し、後からそのやり取りを確認できるようにしています。

 

基本的な方針

まず大前提の方針として、「ターゲットがぶれないようにする」というのを気をつけています。

boardの場合、

・業種は幅広いですが、ビジネスモデルとして受託型に最適化

・中小規模の会社がターゲットで、数人〜数十人規模がメイン

としています。

規模が大きいところまで広げていけば単価は上がりますし、より多くのビジネスモデルをサポートしていけば、より多くの会社に使ってもらえるかもしれません。

ただ、これがぶれてしまうと、誰にとっても中途半端な使い勝手になってしまうので、この方針をぶらさないようにしています。

 

優先順位付けで気をつけていること

現在は以下のようなルールでやっています。

自分がプロダクトオーナーとして一貫して意思決定をする

サービスのコンセプトがぶれないように、意思決定の一貫性は非常に大事だと思っています。当然社内でも使っているので、他のメンバーから意見をもらったり議論することはありますが、最終的には、自分が全体のバランス・一貫性を踏まえて決定するようにしています。

知り合いや有名な会社の要望に流されない

知り合いや有名な会社からの要望は、どうしても影響を受けがちです。しかし、必ずしもそれが正しいとは限らないですので、優先順位の判断で影響を受けないように、要望を管理しているTrello上では会社名はわからないようにしています。

ロードマップを半年ごとにし、その枠に収まるものを取捨選択する

ロードマップは公開する以上、ある程度は守らないといけないので、無理に詰め込むようなことはしません。そのため、ロードマップを決める過程はわりと保守的になるので、この段階で、無駄が削ぎ落とされます。

既存機能の改善、要望対応、新機能追加をバランスよく対応する

既存機能で不足している点や使いにくい点の改善、要望の対応、全く新しい機能の追加をバランスよく対応するようにしています。

既存機能の改善や要望対応は、既存のユーザ満足度の向上に繋がり、継続して利用して頂くという点でプラスになると思っています。

全く新しい機能の追加は、既存ユーザさんだけでなく、これまで機能が足りずに利用を控えていた見込みユーザが使ってくれるきっかけになるかもしれません。

そのため、どれかに偏るのではなく、バランスよく対応していくようにしています。

整理のための質問

以下のようなものを自問自答します。

・この機能は本当に必要か
・どのくらいの人が使うか
・業務上不可欠なものか、それともあったら便利か
・単なる習慣による要望で、実はなくても問題ないものではないか

全てに当てはまらないと対応しないというわけではありませんが、特に要望が多くて対応しようと思ったものに対して、「あれ、これ実はあまり必要ないんじゃない?」と気づくきっかけになります。

要望の多さと優先順位

要望の多さはニーズの多さでもあるので、ある程度優先順位には反映させるようにしています。ただしboardの思想・方向性的にずれているものは、どれだけ要望が多くても対応しないようにしています。

何度か、サービスをやっている人から「要望の多さと優先順位を連動させるのは違うんじゃない?」と言われたことがあるのですが、業務システムの場合、取引先との関係で、業務上避けられないものなども多数存在します。

使い勝手やUIなど、主観が多分に入っている要望は別ですが、業務的なニーズの場合は、要望の多さは重要な判断材料のひとつにしています。

ロードマップに沿う

・「○○ができないなんて考えられない」「○○は至急対応してほしい」といった大きい声や、「○○があれば使う」といった声に流されないようにするため、原則、半年単位で公開しているロードマップにないものは次のスパン以降での検討にするようにしています。

ちなみに、ロードマップになくても、元々「要望があれば対応しよう」と考えていたものは、要望があればすぐに対応したりもしてます。


こういったルールを決めてからは、だいぶ流されなくなりました。

一応誤解のないように言っておくと、ユーザさんの声には耳を傾けるべきですので、頂いた要望はすべてTrelloで管理し、1〜2ヶ月に1回はすべて見返しています。

ただ、短期的なスパンでは影響されないようにすることは大事かなと思っています。

 

最初の1年目はぜんぜん違うスタンスだった

現在は、ある程度機能も揃ってきていて、以前に比べたら、「○○がないと・・・」というものはかなり減りました。そういった背景もあり、上記のようなルールで運用しています。

しかし1年目は全く違うスタンスでした。

要望の数自体も少なかったので、要望が多いものはどんどんと対応していました。

ただ、その中で大事にしていたのは、「自分自身がその機能を欲しいか」という点です。

これは、そもそも自分のために作り始めたという背景があったり、自分自身もターゲットユーザだったりしたので、その感覚を大事にしていました。自社サービスの経験がなかったので、これを拠り所にしていた感じです。

また、基本的な方針として、「派手な新機能よりも、基本的に既存機能の完成度の向上と、コア機能に関連する業務的に不足しているものの対応」というものがありました。

これは、うちが知名度の低い無名のベンチャーだったことがかなり影響しています。

無名の会社・サービスにとって、「知ってもらうこと」「お試ししてもらうこと」のハードルはものすごく高いです。
1週間で何日も新規お試し登録が0件の日がありました。

そんな状況の中で、お試ししてくれた方を逃がす余裕なんてないんですよね。
なので、お試ししてくれた方に出来る限りそのまま有料へ転換して欲しい。そのためには、とにかく今ある機能の完成度を高めておくこと、まずはターゲットにしている業界・会社規模を絞って、そこでの業務がしっかりカバーできていること、そこを目指しました。

たぶん、それが功を奏して、「要望の対応が速い」と言ってboardを推してくれたり、「受託の会社にとってはものすごくフィットする」といって紹介してくれたり。

boardは当時から今でも、口コミに支えられているのですが、その土台は、最初の1年目のそういったスタンスによる取り組みの効果が大きかったのではないかなという気がしています。

ちなみにこのスタンスの弊害は、リリース内容が非常に地味です。何度「もう少し記事に取り上げられるようなリリースないんですか」と言われたことか・・・。
でも、記事に取り上げて頂くようなリリースをするよりも、目の前のユーザさんをターゲットに開発することを選びました。

*そういった中でがっつり記事を書いてくれたASCIIさんにはほんと感謝しかありません。


1年目のスタンスから今の運用ルールに至った経緯

1年目のそういったスタンスから、前述の現在のルールに至った経緯は、最低限の基本的な部分はカバーできたことが大きいですが、自分自身が慣れてきたという点もあります。

ずっと受託をやってきた人間からすると、多くの顔を合わせたことのない方々から様々な要望が来て、時には「これがないなんてありえない」と言われる経験ってあまりに不慣れで、だいぶ動揺しますよね・・・。

開発ロードマップの公開はかなり初期の頃からやっていましたが、この頃から、「半年単位」という今のスタンスができました。

ちなみに、今でも、「自分自身がその機能を欲しいか」という視点は大事にしています。
さすがに最近は、自社で業務的に必要がない機能も出てきているので、そういうケースは、「その機能に納得感があるか」という視点で見るようにしています。自分が納得しない機能は要望が多くても対応しないようにしています。


実装とのバランス

最近ようやくもう一人開発に入っていますが、それまでの約2年半は、受託の合間にちょっと手伝ってもらう以外は、ほぼ自分一人で開発してきました。

プロダクトオーナーと開発者が同じなので、実装レベルまで完全に頭に入った中で優先順位を考えます。

そのため、機能の対応順番を考える時に、単純な機能の優先順位だけでなく、コードのレベルで考えて、効率が良い、バグを生みにくい順番を考えています。

受託をやっていて、「あー、この仕様、前回の開発の時に一緒に言っててくれれば・・・」なんてことあったりしますよね。
できるだけお客さんと話をしてそういったことを減らせるように取り組んでいますが、今後の予定や構想が全部こちらに伝わっているわけではないので、なかなか難しいんですよね。

あとは、要望は少なくても、「これあるといいな。しかも簡単にできるし」みたいなものは空き時間にさくっとやったり。で、それが意外と好評だったり。

こういったことができるのは、エンジニアがプロダクトオーナーであるケースの強みなのかなと思います。


まとめ

最終的には、ユーザの声は聞きつつも、声に流されないようにする、という点が非常に大事なのかなと思っています。

気持ちの面で戦わないといけない部分もありますが、ロードマップの公開のような仕組みによって、短期的には影響を受けにくくするのも、安定した開発・運営には大事な気がします。

 

1Password Teamsを使ったパスワード管理・運用

うちの会社では、1Password Teamsを使ってパスワードを管理しているので、その運用を紹介したいと思います。


ヴェルクにおけるパスワードの運用ルール

まずはじめに、うちの会社でのパスワードの運用ルールについて。

6年前の起業当初から、以下のようなルールで運用しています。

・パスワードは14桁以上のランダムなもの(当初は桁数は10桁以上でしたが途中から14桁に変更)
・パスワードの使い回しは禁止で全てにおいて異なるものを使用
・パスワードの生成・管理は全て1Passwordで
・2段階認証が使えるものはすべて2段階認証をON

 

パスワードの使い回し禁止は、最近はよく言われるようになってきましたが、それでも一般的にはまだまだなのかなあという印象なので、この記事などをご参考に。

www.motex.co.jp

 なお、これを守らず、こっそり簡単なパスワードを設定する、といった事はできてしまうため、そこは日々のセキュリティに対する意識付けが重要かなと思います。

また、基本的に1Passwordを使ったパスワード管理が快適すぎるので、むしろ1Passwordを使わない方が面倒な気はします・・・。


1Password Teamsとは

1Passwordというパスワード管理ツールに、チーム機能が備わったものです。主に企業利用を想定した機能になっていて、管理者がアクセス権の管理などができます。

管理したい単位(例:プロジェクトごと)にVault(パスワード保管庫)を作成し、それごとにアクセスできるユーザを設定することでパスワードを共有することができます。また、退職した場合はアカウントを停止したり、担当が変わったケースなどでアクセスを止めたい場合は、Vaultへのアクセス権を外すといった管理ができます。

個人ごとのアカウントがあるようなサービスはパスワード共有はしませんが、1ユーザしか登録できないようなサービスや、サーバのパスワードなどを共有するのに使用しています。


1Password Teamsを使った運用

受託案件ごとにVaultを作成し、関係するメンバーのみアクセスできるように設定しています。AWSのアカウントなどは個人ごとにユーザを追加するので、それは「個人」Vaultでそれぞれで管理し共有はしません。共有する情報はサーバ関連のパスワードなどがメインです。

このように案件ごとにVaultを分けることで、アクセスできる範囲を限定できますし、途中から入ったメンバーへの共有も安全でスムーズです。

場合によっては1案件で複数のVaultを作ることもあります。
例えば自社サービスのboardの場合は、「管理者用」「開発者用」「サポート用」に分かれており、本番環境など重要な情報へのアクセス情報は、「管理者用」のVaultにしか登録していません。

ちなみに1点だけ課題があって、まだWindows版が基本的に対応が遅れていて、少し前にベータ版がようやく出たという状況です。


その他のメリット

「Activity Log」で誰が何を更新したといったことが記録されています。

使ったことはないのですが、「Guests」という機能で、外部の人にセキュアに情報を共有できるみたいです。
この記事を書くのに管理画面を見ていて気づきました。これ結構便利なのでは。


1Passwordのマスタパスワードを忘れたら・・・

ユーザに「Recovery」権限というものを付けることができるので、この機能を持っているユーザは緊急時に他のユーザのパスワードをリセットすることができます。

また、管理者ユーザのパスワードがわからなくなった場合、「Emergency Kit」というのがあります。緊急時の解除用のコード等のリカバリ方法が書かれているものなのですが、なんと、「紙で安全な場所に保存していく」ことを推奨されています。

物理的にPCや1Passwordとは全く別の場所で保管することで、リスクを分散する仕組みのようです。

ということで、うちの会社では、この機会に、ちゃんとした金庫を買いました。
もともと買おうかなと思っていたのですが、安全にしまっておけて、かつ火事でも燃えない。


参考:1Password Teams以前の運用

1Password Teamsは、わりと最近出たサービスで、以前は、1Password単体で使用していました。その時は、Dropboxを使って共有していました。

1PasswordはVaultファイルをDropbox上に置くことができるので、社内で共有するためのDropboxのディレクトリを用意し、Valut作成時に保存先をDropboxに保存します。

Vaultにはパスワードを設定できるので、そのパスワードをVaultを共有したいメンバーのみに共有していました。

この運用をやり始めた頃(5〜6年前)はかなり不安定で、パスワードを追加しても、他の人の1Passwordには反映されないという状況でしたが、途中からは安定して運用できていました。

ただ、Teamsが出たため、ベータ版の頃からすぐにそちらに切り替えました。


まとめ

昨今のセキュリティリスクの増大に伴って、パスワード管理の重要性はどんどんと高くなってきています。

パスワード管理ツールはぜひともオススメしたいのですが、企業利用の場合は、Teamsを使った運用かなりオススメです。

 

ちなみに、パスワード管理ツールは、LastPassなど他にも色々とありますが、昔から1Passwordを使っていたためその流れで1Password Teamsを使っています。他との比較をしているわけではないです。