esaとDocBaseのサービス開発のDiffの話 #DevKan
2015年11月28日に実施された表題の勉強会に参加してきました!
KRAY 天野 充広(@amachin)さん
そう言えば、ホッテントリからKRAYさんの記事ブックマークしてた!
git pull と git pull –rebase の違いって?図を交えて説明します! | KRAY Inc
esaさんとは実は仲がいい
以下、メモ的な内容になりますが、DocBaseさんのお話になります。
少し開始時刻に間に合わなかったので、途中からになります。
なぜ作ったのか?
- 社外秘の情報がいっぱい
- ユーザー数による課金
その結果
- 外部の開発パートナーと共有しづらい
- クライアントと共有しづらい
- アルバイトやインターンを招待しづらい
問題点「有用な情報が関係者全員で共有できない」
一部の人だけが使えないツールの問題はうちの会社でもあります。
結局のところプロパー社員以外も含めて全員に共有するにはメールしかなかったり。
一番共有したい手順やヘルプトピックなどが共有できなかったり。
ドキュメントを作るのは大変(というイメージ)
- ちゃんとしたドキュメントを書かなきゃ。
- 間違った情報を書いてはだめだ
その結果
- ずっと下書きのまま。
- 小さな情報は共有しづらい
- きちんとしたドキュメントを作るのは大変。
この辺でesaさんにはWIP機能があるんですよね、という話が入った。
DocBaseのスライドなのに「esaの命題」というタイトルになっています。
人数少なかったのもあって、参加者と発表者そして、esaの深谷さん、赤塚さんも質問や発表内容の捕捉に加わってもらいながら、いい感じに質問のキャッチボールができてました。
WIPって何て説明すればいいんだろう?仕掛中?
うちの会社では、プルリクエストにWIPというプレフィックスをつけて出す場合がかなりあります。
esaさんはWIP機能で「未完成でもいいんだよ」とハードルを下げて、「ドキュメントを書く」ということを促しているそうです。
DocBaseさんでもWIP機能は検討したそう。
DocBaseの命題:チームの情報共有を活発にさせたい
情報共有が活発になると
DocBaseの特長
- URL一つだけの小さな情報も気軽に投稿できる
- Slackなどにながれる有用な情報をためておける
このコードおかしいから直したい、だとか流れて消えてしまうにはもったいない情報なのかなと思います。
本当によくあることだと思います。
小さく始める
- 小さな情報をまとめて有用な情報にできる
- まとめ機能は手順書を作るときに役立つ
関係者全員で情報共有できる
- 柔軟な権限設定:組織全員だったりプロジェクトごとだったり
- シンプルなUIでエンジニア以外も使いやすい
ユーザー数無制限
いろんなアプリごとにデザインのスクリーンショットをとったりしている
- スクリーンショット貼り付けの機能は、メンバーがいつの間にか入れていた
ヘルプセンターに機能の使い方がかれている ** テーブルを超簡単に作成する方法など
esaはマークダウンでスライドにできる ** かなり使われている!
メモを開いたときに可変にならない 画像の問題があった 広げる機能を作る予定
esaは画像についてはオリジナルを出している
アクティブユーザー2倍
- 共有されたドキュメント数 2ヶ月で1万増
esaとの出会い
- DocBaseのプロトタイプを作っている時期
- 別の仕事で飲んでいたときに、同じタイミングでお互いに内々に作っていたのがわかった (うわ、やりづらくなったなぁ、というのはあった。) (出してから、お互い情報共有して)
設計と開発
新サービスを作りたい
- 受託も楽しいけど
小さく始めるしかない
サービス検討を小さく
Amazonを真似して、プレスリリースを作る
- サービスの概要、問題アピールポイントなどをプレスリリースの形式でまとめます。
- ワーキングバックワード法
モック画面を作る
- 一番価値があると考えている画面を作って検討
10ぐらいのアイデアから1つに絞り込んだ。
企画会議
- お菓子を置いてお菓子を食べながら
作るもの決まったぞ!
社内の意見など
- リソース割くけど、利益出る?
小さく始める
小さなチーム作り
- 最初のチームはエンジニア3人と私の4人。
- 受託開発と並行
価値検証したい部分だけ作る
- モック画面を開発合宿で作って、社内で検証
- 日光にあるペンション ついたらすごい大雪になって、次の日の朝すぐに帰った 帰りの電車の中でも作った
ドッグフーディング
- 社内でリリース
社内インタビュー
- 小さく早く回す
プチ合宿
- 金曜15時から18時までカフェに集まって開発
社内の意見
- EvernoteやQiita:teamあるけど使ってくれるの?
小さく始める
社内のみで公開
アイディアもすぐやめれる サービス自体も。。。
ログインの機能などいろんないらないものはつくらなかった。
社内でリリースした機能を公開 Evernote
- 仮説検証のサイクルをまわしやすい
感想ですが、ドッグフーディングであると同時に完全に仮説検証可能な最小限のプロダクトで何回も仮説検証を回すという、MVPのアプローチになっていると思います。
社外10社くらいに限定公開
- 自分たち以外にも役立つか判断しやすい
- 実験的な機能を盛り込みやすい
- 完璧をめざさなくていい
価値がないとつかってくれないのでわかりやすい
中途半端な機能実装もまだ実験的なので、ということがいえた
クローズドβで少しずつ公開
- 事前登録してもらって1週間に10社ずつ招待
- サポートにたくさん意見をもらえた
- アップデート後のはんのうがわかりやすい
- まだ辞められるという安心感
- そろそろ後戻りができなくなるという不安感
質問: ペルソナを作ったり、アーリーアダプターにユーザーインタビューとかした?
- 自分たちが使ってみたいユーザ ドッグフーディング
- こんなプロトタイプがあるんですが、つかってみたいですか?
- 3社くらいは興味なし、2社くらいは使ってみたい
質問: バージョンの切り方 どこまで作ったらリリースみたいなこと
社内のこういうことがしたい、という思いに共感して
課題
- 検索改善 ElasticSearch
- 複合で検索できるように
- elastic searchをAWS側に
- サービス側からはindexのみにしてセキュリティのリスクを下げる
- デザイン改善
- より伝わりやすくするための生理機能
- 規模が大きい組織向けの大規模対応
- 画像以外のファイルも対応、ファイル添付
- もっとスマホから使いやすくするスマホ対応改善
質問: 企画会議などで社内の冷静な意見が出ていた頃、開発メンバーは企画者の思いに共感していたの?(この質問は自分がぶつけてみました)
* 最初は半信半疑だった
* なぜなぜ分析などで「なぜ情報共有するのか」などを繰り返した
* ドッグフーディングで、社内の意見もクライアントの意見も集まるようになって「これはいけるぞ」という雰囲気になってきた。
なんか本当に素晴らしいと思います。
そしてesaのお話
esa LLC 深谷 篤生(@fukayatsu)さん 赤塚 妙子(@ken_c_lo)
情報を育てたい
- 最初から完璧を目指さず
WIP
- 途中でもとりあえず共有
- みんなにも共有するけど、積極的に通知はしない
WIPをつけるときのきもち
- こんな感じで考えているんだけど、細かいツッコミはやめてね
- WIPはエクスキューズ ゆるい感じにする
- できなかったことができる 書けなかったことが書ける
自分のために書く「ドキュメント」
ユーザー属性
- チーム規模: 1〜126ユーザー
- 有料ユーザーの30パーセントが個人ユーザー
一人ユーザーが多い
プログラマ好みの機能・設計
- 高いカスタマイズ性
- API
- シンプルでフラットな設計
- UIは基本英語
プログラマ好みにした理由
非プログラマでもわかりやすい
質問: 見た目テーマ変えないの?
楽しいから、毎日作り続けてる
- ユーザーのフィードバックがイシューになる
- 982フィードバック 1000を取った人には何かaword
土日が活発・次点で木曜日
リリースノート9月から100
- 週1、2回
標準的なリリースのサイクル
毎日がドッグフィーティング
- 周囲の仲間達とesaで日報を共有
- 業務委託先の会社でもesa
- esa社のesa
- 実家への連絡もesa
- IT強くなくてもギリギリつかってもらえる
- DocBase 子供の教育方針 交通事故にあったときの種々の連絡先
スケジュール・ノルマはなし
- 締め切りによる心理的負担を減らして、より良い選択をしたい
- 締め切りによるその後の開発も窮屈になってしまう。
Staging環境
- まだない
- 本物のデータで確認
Heroku
障害監視
- Pingdom + PagerDuty
- サービスダウンしたときに携帯に電話
リリースノート
質問: やりたいことをきめるのはどうする?
* 二人同時並行 お互い手伝う
* mockまではつくってる これはなしだよ みたいな話はする。
* どうしても収束しない場合は放置 ABなどはしない
カスタマーサポート
フィードバックに5分で返信する
質問に対して、「はい/いいえ」よりも良い返事がある
- 「xxの機能はありますか?」
- ユーザの問題はなんだろうか
- それを現状の機能で解決できるだろうか
- 他にも応急的な策はあるか?
バグ修正や簡単で効果的な機能追加はその場で実装してすぐにリリース数r
- サポート中はモチベーションが一番高い
いろいろなチャンネルを使う
イベントでプレゼンする
- 特に技術系のイベントでの登壇
技術系のイベント・コミュニティにツール提供のスポンサーをする
Twitterであそぶ
- esaアカウント
モチベーション とても大切
- for motivaated teams
- 使う人 作る人 両方大切
フィードバックをもらう
- クレームは宝
- どんな厳しい意見
リリースノート書きたい
- 書くのが楽、楽しい
- リリースノート駆動開発
esaらしさ
「esaらしい」こと
- 上から何かを強要しない
- 気づいたらそこにあった
「無名の質」
esa LLCについて
2人でいろいろやる
開発者、経営者、ユーザ
2人だと開発スピードは遅い?
- 現段階ではそうでもない感じ
- 意思決定のスピードの速さ
- 多少苦手だった営業などもesaのためだったらやれる 視野が広がる
- 稼ぐべきお金が少なくて済む
- 決定権は50・50
- 得意な領域が違うのでケースバイケース
もともと趣味から始めた
- Qiita:teamのクローンを2013年の11月につくって満足して放置していた
- 開発合宿でブラッシュアップした
- pplog
- 知り合いのエンジニアさんにiphoneアプリを作ってもらった直後に、深谷さんが勝手にandroidアプリを作っていた 知り合う
- Qiita:teamフロー
会社よりもプロダクトが先
We are not startup.
- 出資を受けていない
- 急激に拡大することを目指していない
経済状況
これから
使われても楽しい 自分たちで使っても楽しい
趣味から始めた「楽しさ」をどこまでも維持したい
質問: 大企業 外に繋げないなど オンプレミスはできないの? GitHubEnterpriseのように
* クラウドに依存している S3とかあるので難しいが検討したい。
質問: オフラインモード * 深谷さんがその場でイシュー作ってました!!
感想
esaの新コンセプトであるmotivated teamsですが、この会は参加者が少なかったのもありますが、本当に発表者、そして発表してないほうの発表者、参加者のあいだで活発に質問や意見交換が行われていて、すばらしい会でした。
主催の中村さんも、いつもこんなセッションができたらいいのにというお話をされていました。
この会のあと、電車で帰るときに中村さんに「(この2チームのように)Productに共感して開発したい」という気持ちを伝えたのですが、「共感は出来なくても理解、納得して作らないといけない」との言葉をいただきました。 esaやdocbaseのようにプロダクトに寄り添う仕事がしたいし、 受託案件だったとしてもやることに納得できる案件をとってきてくれるんじゃないかと信頼をして仕事がしたいです。
繰り返し、DocBaseの開発チームの話ですが、
- 最初は開発メンバーも納得していなかった
- そこからMVP的なアプローチ、ドッグフーディングで小さく小さく検証しながらプロダクトを育ててきた
- 社内の冷静な意見もそうやって説得してきた。
というエピソードを聞いて、最もMotivated teamsにふさわしいチームなのではないかと感じました。
最もesaにふさわしいチームがdocbaseを作っていた。つまり、貴族主義は最初から間違っていたんだよ、ザビーネ!
esaとdocbaseこんなになかいいことも知れたし、2つのプロダクトの今後についてフワフワした期待感とともに非常に気になります。
発表者の3名様、DevLove主催の中村さん、参加者の皆さま、そして会場を提供してくれたTAMさん、本当にありがとうございました。