『board』のサービス開発の現場 #DevKan
『board』のサービス開発の現場 #DevKan
2015年9月18日にあった表題のDevlove関西の勉強会に参加してきました。
boardとは
ドッグフーディングとは、自分たちの作ったものを自分たちの業務でも実際に使うという開発スタイルだそうです。(※指摘により修正しました)
会社としては受託の事業がメインで受託が好き が、波がある
なぜ受託が好きなのか、ということを質問してみましたが、自分の知らないいろんなビジネスに携われるからとのこと。
私も前職はSIerでしたので、新しいビジネスプロセスにかかわれるときは面白かったです。つらいときはつらかったけど。
そういうつらい状態をなくすために、いい案件を受託するといった努力もしているそうです。
自社サービスの運用を開始した。
本業の受託とのバランスが難しい。
受託の会社なので、要件の検討などはお客様がやったものが降ってくる
つまり、要件の検討などの経験がない。
最初に作ったのはiphoneアプリ
ブレストのやり方を習得
- アイデア１００個を１時間に出す
- 整理する
繰り返し
想像以上にうまくいかない！
初めての自社サービス事業化
営業はいないのでインバウンドマーケティング
ソリューション型なのでお客様の要望を聞く受託に近い
自分たちに近い領域からはじめることが大事
これは本当に思います。
自分の知らないことをいきなり始めようとしてもうまくいかないだろうなぁ・・・
とはいえやらないといけないときもあるのですが
要件どおりに作ることではなく顧客の満足を目指すならば
そして４年目にboardのサービスを始めた
受託が炎上していたら自社サービスの開発は出来ない。
（会社の）自分への依存度を下げる
どういうことかというと、代表である自分がほとんど営業して案件をとってきて案件の実現や管理部分も自分がこなしてしまうことが多かった。
そういうことからの脱却を目指すために、やったのはリスク感覚の一致
トライアンドエラーを繰り返すことで、「アラートあげすぎ」などの違和感をなくしていった。
これはあるあるですね。
能力のあるなし、にかかわらず心配しすぎのせいで前に進めない、リスクを取れないということを自分もしてしまいがちです。
そういった部分が一致しているチームでないと仕事はすごくやりにくい。。。
boardは会社を経営するうえでほしいから作った
(受託IT会社の)経営者視点で開発
売り上げの予想なども出来るようにしたい
開発している自分たちがユーザ
ドッグフーディングできるか？
→自分たちが検証
本質的なニーズを探り出す
機能としては満たすが業務としてはあっていない、というようなことをなくす。
自分事なので調査がいらない。
これがわかるのは本当に大きい。
要件の通りに作ったのに、結果として顧客の業務を円滑に進めることが出来ないということは多々ある。
顧客と常に対話できる状態ならいいのですが(そういう状態を作り出すところがアジャイルの真髄だとは思います。)
ドッグフーディングのデメリット
自分に最適化されすぎて、一般のユーザにとって正しくない可能性
初めて見たときの感覚を失い、新規ユーザへの配慮がなくなる
この問題の解決のために、テストやる人には詳細な実装内容を伝えず始めて使う状態でやっている。
本当はユーザビリティテストなどをやったほうがいいんだろうけど、受託をやりながら、しかも週に１度のリリースサイクルを実現しているためやっている時間がない。
サービスインして自分たちだけで本番環境を試す仕組み
本番環境がいちばん正確ですね
無駄なものを作らない
いついつまでというリリースポイントを決める
リリースは一週間に一回
少し足りないくらいでリリースする
最初は怖い
ユーザに言われなかったら実はいらない機能だったことがわかる。
言われたら対応することで、顧客の要望にこたえることにもなる。
なるほど。したたかな感じ。
中途半端なかかわりのメンバーはなくす
案件の波やタスクの内容とタイミングを調整する
ユーザはIT業界が圧倒的に多い
会社半分くらいが2~10人
受け入れ中で暇だった9月のシルバーウィークに寝ずにプロトタイプを作った
欲しい機能 使い勝手 の6割くらいは9月末までに実装
10月に社内テストを実施し、2月にClose, 5月にPublic Beta
5月は受託で忙しく、製品化した8月までほとんど機能は追加していない
何か作ったりするときにはやっぱり寝ずにやるくらいの勢いが要りますね。
優先度の決め方について
自分が欲しいもの
やってないことのうち 納得できるもの
声の大きい人の意見を優先しない。
全部やったらシンプルさがなくなる
boardを好きになってくれるユーザが増えてきた
そういうユーザの求める優先度もだんだん同じに
不思議な感じがします。
コストかけすぎない
受託もやりながら
広報とSEOは協力を仰ぐ
汎用性はない → 差別化
大事なこととして、受託もboardの開発も大きな山を作らないこと
リリースは週に1度
山があるとほかのことがとまってしまう。
開発だけやっても何にもならない。
確かに、大きな案件に集中しすぎてしまうとほかの案件にまったく手をつけられない状態になることがよくあります。
マルチタスクにしないことも大事だと思いますが。。。
小さいタスク1週に1個
中タスク 月1個
大タスク 年1個 （大規模なリファクタリングとか）
技術的な負債の返済
ペースの維持
チェンジオブペースなんて使う必要はないですね。(言ってみたかっただけ)
ロードマップは公開していて、一貫している
合議制はとらない！
作ってるのが2人とのことですが、ダイアログのときにも出たけれどやさしい独裁者みたいな感じに思えます。
経営者視点だけで気づかないこと
- 捺印申請の機能
期限のみ入れれるようにした
捺印申請出す側としては「上司に日付だけの申請は失礼」という意見があり、コメントを入れられるようにした。
独自の習慣などの要望はお断りする勇気を持つ
カスタマーサポートは自分でやっていて、何でやらないかをとうとうと論理づけて伝える。
これは単純にすごいです。
開発ロードマップを公開することで、ロードマップがあるから使うことにしましたといったユーザも出てきた。
公開ロードマップがあることで自分へのいいプレッシャーになる
時間がない ので メルマガやユーザビリティテストはできない
UI, UXをがんばっていても業務にフィットしていないと意味はない。
まさにその通り、だとおもいます。広義のUXには業務にフィットすることも入ると思うけれど
売込みをする側からこの機能がUIこれだけ使いやすくすればユーザにとってメリットがあり、使ってくれる人が増える、売り上げが増えるといったことを考えていたとしても、結局業務にあっていないと意味がないんですよね。
この辺、小さく作って検証のサイクルを速く回すといったMVP的な最適化がなされている気もします。
(ユニット)テストは後回し
最初書かないとずっと書かなくなるといわれるが、がんばって書く
リリースの規模が小さいと
- テストが楽
- ストレスが小さい
でも主な目的はRailsがバージョンアップしたときのテストのため。
そのため、カバレッジはがんばってあげる。
リリース時のテストは項目は出さない
テスト項目を出すと自分の見えている範囲しかテストしない
うっ。
私もリリース前のテストは自分が変更した部分の確認といった感じになりがちですね。
このやり方のほうがいいのかも
ここで最初のほうに出たリスク感覚の共有といったことも生きてくるのでは。
ＣＳは月100件
平均応答時間8分 即時対応
使えるだろう、と思った機能が使いにくいといったことがあるとき、反応がすぐ感じられる
サポートの実績を公開している
CS応対にはintercomというサービスを利用
固定費を最小にしている 継続のため
逆にintercomのようにこのくらいのコストは許容できるといった外部サービスはどんどん利用する
自分にあったスタンスで開発を続ける
ダイアログも面白かったです。
チームの人数が重要ではないかという意見があり、ベンチャーなどのチームはメンバーが4人でも多いのではないかと。
意思決定はやさしい独裁者が理想。
「こういったドッグフーディングのサービス開発の導入をするにはどうしたらいいか？」
という話題には新しい技術を学ぶタイミングと、やりたいことを結びつければよいのではないかということでした。
そのために自分の欲しいものリスト(ネタ張)を作っておくことは大事です。
田向さん、ありがとうございました。
