読者です 読者をやめる 読者になる 読者になる

hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

esaとDocBaseのサービス開発のDiffの話 #DevKan

2015年11月28日に実施された表題の勉強会に参加してきました!

devlove-kansai.doorkeeper.jp

speakerdeck.com

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社くらいは使ってみたい

質問: バージョンの切り方 どこまで作ったらリリースみたいなこと

  • あいまい
  • 2週間のイテレーションのサイクルで出せる方が良い
  • esaの場合はできた段階で出す。

社内のこういうことがしたい、という思いに共感して

課題

  • 検索改善 ElasticSearch
  • 複合で検索できるように
  • elastic searchをAWS側に
  • サービス側からはindexのみにしてセキュリティのリスクを下げる
  • デザイン改善
  • より伝わりやすくするための生理機能
  • 規模が大きい組織向けの大規模対応
  • 画像以外のファイルも対応、ファイル添付
  • もっとスマホから使いやすくするスマホ対応改善

質問: 企画会議などで社内の冷静な意見が出ていた頃、開発メンバーは企画者の思いに共感していたの?(この質問は自分がぶつけてみました)
* 最初は半信半疑だった * なぜなぜ分析などで「なぜ情報共有するのか」などを繰り返した * ドッグフーディングで、社内の意見もクライアントの意見も集まるようになって「これはいけるぞ」という雰囲気になってきた。

なんか本当に素晴らしいと思います。

そしてesaのお話

speakerdeck.com

esa LLC 深谷 篤生(@fukayatsu)さん 赤塚 妙子(@ken_c_lo)

情報を育てたい

  • 最初から完璧を目指さず

WIP

  • 途中でもとりあえず共有
  • みんなにも共有するけど、積極的に通知はしない

WIPをつけるときのきもち

  • こんな感じで考えているんだけど、細かいツッコミはやめてね
  • WIPはエクスキューズ ゆるい感じにする
  • できなかったことができる 書けなかったことが書ける

自分のために書く「ドキュメント」

ユーザー属性

  • チーム規模: 1〜126ユーザー
  • 有料ユーザーの30パーセントが個人ユーザー

一人ユーザーが多い

  • メモ整理アイデアまとめ原稿執筆など
  • alt Evernote
  • 家庭内esa 夫婦カップル
  • 育児や夕食の連絡
  • ゲームのコミュニティ

プログラマ好みの機能・設計

  • 高いカスタマイズ性
  • API
  • シンプルでフラットな設計
  • UIは基本英語

プログラマ好みにした理由

プログラマでもわかりやすい

質問: 見た目テーマ変えないの?

楽しいから、毎日作り続けてる

  • ユーザーのフィードバックがイシューになる
  • 982フィードバック 1000を取った人には何かaword

土日が活発・次点で木曜日

リリースノート9月から100

  • 週1、2回

標準的なリリースのサイクル

  • ユーザからのフィードバック 自分で思いついた機能をGitHubのissueに
  • GitHub Flowにしたがってブランチを作るい、適宜pushしながら実装
  • 導線だけつぶして、公開していることも

毎日がドッグフィーティング

  • 周囲の仲間達とesaで日報を共有
  • 業務委託先の会社でもesa
  • esa社のesa
  • 実家への連絡もesa
  • IT強くなくてもギリギリつかってもらえる
  • DocBase 子供の教育方針 交通事故にあったときの種々の連絡先

スケジュール・ノルマはなし

  • 締め切りによる心理的負担を減らして、より良い選択をしたい
  • 締め切りによるその後の開発も窮屈になってしまう。

Staging環境

  • まだない
  • 本物のデータで確認

Heroku

障害監視

  • Pingdom + PagerDuty
  • サービスダウンしたときに携帯に電話

リリースノート

  • esa上で運営してドッグフーディング
  • webhookで受け取ることができる
  • メール slack

質問: やりたいことをきめるのはどうする?
* 二人同時並行 お互い手伝う * mockまではつくってる これはなしだよ みたいな話はする。 * どうしても収束しない場合は放置 ABなどはしない

カスタマーサポート

フィードバックに5分で返信する

質問に対して、「はい/いいえ」よりも良い返事がある

  • 「xxの機能はありますか?」
  • ユーザの問題はなんだろうか
  • それを現状の機能で解決できるだろうか
  • 他にも応急的な策はあるか?

バグ修正や簡単で効果的な機能追加はその場で実装してすぐにリリース数r

  • サポート中はモチベーションが一番高い

いろいろなチャンネルを使う

  • Web/e-mail/Twitter/直接
  • エゴサーチ

  • 既存の機能の改修ならすぐできる

  • フィードバックが同僚の意見の代わり
  • 井戸端というチャットツールでもフィードバックをもらっている

イベントでプレゼンする

  • 特に技術系のイベントでの登壇

技術系のイベント・コミュニティにツール提供のスポンサーをする

  • 運営チーム向けにesaの1チームを無償提供する
  • 東京Node学園祭2015
  • RubyKaigi2015
  • Wikiガチ勢からのフィードバック

Twitterであそぶ

  • esaアカウント

モチベーション とても大切

  • for motivaated teams
  • 使う人 作る人 両方大切

フィードバックをもらう

  • クレームは宝
  • どんな厳しい意見

リリースノート書きたい

  • 書くのが楽、楽しい
  • リリースノート駆動開発

esaらしさ

esaらしい」こと

  • 上から何かを強要しない
  • 気づいたらそこにあった

「無名の質」

esa LLCについて

2人でいろいろやる

開発者、経営者、ユーザ

2人だと開発スピードは遅い?

  • 現段階ではそうでもない感じ
  • 意思決定のスピードの速さ
  • 多少苦手だった営業などもesaのためだったらやれる 視野が広がる
  • 稼ぐべきお金が少なくて済む
  • 決定権は50・50
  • 得意な領域が違うのでケースバイケース

もともと趣味から始めた

  • Qiita:teamのクローンを2013年の11月につくって満足して放置していた
  • 開発合宿でブラッシュアップした
  • pplog
  • 知り合いのエンジニアさんにiphoneアプリを作ってもらった直後に、深谷さんが勝手にandroidアプリを作っていた 知り合う
  • Qiita:teamフロー

会社よりもプロダクトが先

  • esaのサービスコンセプトが会社のコンセプト

We are not startup.

  • 出資を受けていない
  • 急激に拡大することを目指していない

経済状況

  • 受託とesaの秀英きトントンくらい
  • 週に数日スタートアップのお手伝い
  • フルコミットの受託は受けられない
  • esaの収益だけで食べていくことが当面の目

これから

  • ネイティブアプリ
  • 決済連結機能
  • 検索改善
  • スピードアップ
  • alt Wiki的な可能性
  • GitHubPageのesa

使われても楽しい 自分たちで使っても楽しい

趣味から始めた「楽しさ」をどこまでも維持したい

質問: 大企業 外に繋げないなど オンプレミスはできないの? GitHubEnterpriseのように
* クラウドに依存している S3とかあるので難しいが検討したい。

質問: オフラインモード * 深谷さんがその場でイシュー作ってました!!

感想

esaの新コンセプトであるmotivated teamsですが、この会は参加者が少なかったのもありますが、本当に発表者、そして発表してないほうの発表者、参加者のあいだで活発に質問や意見交換が行われていて、すばらしい会でした。
主催の中村さんも、いつもこんなセッションができたらいいのにというお話をされていました。

この会のあと、電車で帰るときに中村さんに「(この2チームのように)Productに共感して開発したい」という気持ちを伝えたのですが、「共感は出来なくても理解、納得して作らないといけない」との言葉をいただきました。 esaやdocbaseのようにプロダクトに寄り添う仕事がしたいし、 受託案件だったとしてもやることに納得できる案件をとってきてくれるんじゃないかと信頼をして仕事がしたいです。

繰り返し、DocBaseの開発チームの話ですが、

  • 最初は開発メンバーも納得していなかった
  • そこからMVP的なアプローチ、ドッグフーディングで小さく小さく検証しながらプロダクトを育ててきた
  • 社内の冷静な意見もそうやって説得してきた。

というエピソードを聞いて、最もMotivated teamsにふさわしいチームなのではないかと感じました。 最もesaにふさわしいチームがdocbaseを作っていた。つまり、貴族主義は最初から間違っていたんだよ、ザビーネ!

esaとdocbaseこんなになかいいことも知れたし、2つのプロダクトの今後についてフワフワした期待感とともに非常に気になります。

発表者の3名様、DevLove主催の中村さん、参加者の皆さま、そして会場を提供してくれたTAMさん、本当にありがとうございました。