ZEALS様の事業内容について教えてください。

Messengerアプリを活用したチャットボット“fanp”を開発しています。

会話広告と呼ばれるもので、Facebookの広告をクリックすると通常はLPなどのページに遷移しますが、”fanp”の場合はチャットボットに接続するようになっています。そこで会話をして、会員登録ができるようになっています。LPに比べてCVRがとても高いのが特長で、弊社のクライアントでの平均のCVRはだいたい8%になっています。

CVRが高い理由としてはまずUIの満足度が高いこと、一度表示するだけのLPと違って、”fanp”の場合はユーザーがアクションを起こすごとに弊社にwebhookが飛んでくるので、ユーザーの動きを把握できるんです。要は、「メールアドレスの入力まで完了していますが、その後いかがですか？」といったpush通知が可能になります。それを見たユーザーが「あ、入力が途中だったな」と思い出して登録作業を再開してくれる、という流れができるんです。

DocBaseを導入した理由を教えてください。

もともと情報共有に別のサービスを使っていたんですが、あまり機能しなかったんです。

それに加えて料金が人数に応じて変わるものだったので、「誰を入れて誰を外すか」といった作業も必要で、面倒くさいなと…… インターンにも情報共有したいけど、そのためにわざわざツールに入れるかどうかということを考える作業も面倒でした。

その点DocBaseは気軽にメンバーを追加できるのでありがたいですね。それもあって、DocBaseに移行するのはほぼ即決でした。

DocBaseをどのように利用されているか教えてください。

社内全員で使っていて、グループは事業部単位で分けています。エンジニア：ビジネス：バックオフィスで4:2:2といった割合ですね。正社員が18人で、あとはインターンだったり業務委託の方ですね。

情報やナレッジは片っ端からDocBaseに書いています。会議の議事録やAPIの仕様、いまはやっていないんですが、日報もDocBaseに共有するようにしていました。「とりあえずメモにして共有する」という文化ができたのでそこがよかったと思っています。

機能でいうと「スターをつけたメモ」はよく使いますね。見返したいメモはスターをつけて、だいたいここから飛んでいます。

組織への導入時に工夫したことや効果的な使い方があれば教えてください。

導入時は「とりあえずDocBaseに全部書いてください」と周知しました。弊社はSlackを使っているんですが、Slackで会話して流れてしまう、というパターンが一番最悪なので。Slackの運用ルールについても、「ここはこんなルールで運用する部屋です」といったようにDocBaseに書いてまとめています。特にメモ内に他のメモを埋め込むことができる機能は社内でもかなり評判が良く、文書化するのに役立っています。文書化するのは大変ですが、一度作ってしまえば後が楽なので。

これはあえて言うことでもないかもしれないんですが、Markdownが使えるのが大きいんですよね。

DocBaseを導入することで組織に起きた変化があれば教えてください。

ありましたねー。それまでは口頭で伝えることがほとんどで、いざ情報が必要になったときに言った言わないの問題が起きてしまうことがありました。DocBaseに書くことを周知してからは「メモに書いて残してください」と言えるようになったので、そこはよかったですね。

手順書などもテンプレートですぐに作れるので便利ですね。お客様向けのマニュアルもDocBaseで作ったりしています。

組織やチームを成長させるためのカイゼン活動があれば教えてください。

弊社は「RANDOM5」という活動をしています。各事業部からランダムで5人選出して、週に2時間ほど時間をとって、組織の課題や改善について議論をするんです。リーダーと書記をあらかじめ決めておいて、そのメンバーが週のどこかで2時間ほど空いた時間を探して実施します。これは週に1回やるようにしていて、弊社は18人なので、1人が月に1回か2回やるようになっています。

ちょっとしたバグや不満などは慣れてしまうと当たり前になりますが、RANDOM5でちゃんと考えてみると「これはだめだよね」といった声が出てきます。そういったことを洗い出し、解決策を議論し、施策としてアウトプットします。アウトプットをする際は「それが関係する人に必ず提案する」というルールを設けています。例えば、ビジネス側とエンジニア側の連携で、ビジネス側から「いつそのタスクが終わるかわからないから、期限を切ってください」という課題が上がったときに、エンジニアに確認したら「バグが多いときがあると、タスクの優先順位が下がってしまう」という事情がありました。そうやって改めて話をしてみると、ビジネス側とエンジニア側に共通認識ができるんですよね。バグがあるときはそちらが優先されてしまうのは仕方ないので、せめて「わかる範囲でちゃんと伝える」という運用ルールを作りました。

RANDOM5には経営層のメンバーがいないときもありますが、逆に経営層には言いづらいことなども出てくるので、それはそれで上手く機能していると思います。日頃、1対1でのヒアリングも丁寧にやってはいるんですが、実際の業務やタスクの進め方で「こうしてほしい」という要望が拾いきれなかったりするので、RANDOM5をすることによってそういった要望も拾えていると思いますね。

テーマは本当に5人にお任せで、課題を洗い出して、なぜそれを課題として解決しなければいけないかという理由付け・原因・解決策を提案しましょうということだけルールとして決めています。

チームのサービスがクライアントワークが多く、特定のエンジニアしかビジネスに絡まないといった話も多いので、そうすると他のエンジニアとしても「何で自分はこれをやっているんだろう」という、「コミュニケーション不足で温度感が違うことの弊害」が多かったんです。これもRANDOM5をはじめてから減ってきたので、忙しいけども無理にでもやろうと。そういうことで導入しています。