リーンでアジャイルでモフモフなTwitterBot開発

はじめに

先月からお世話になっているmofmofさんの研修で、顔を変えて遊ぶTwitterBotを開発しました。

この記事は開発したTwitterBotの紹介と、mofmofさんで学んだ研修内容のまとめです。

顔変えるBotの紹介

「顔変えるBot」は、AIが生み出した実在しない人物の顔を、AIによる顔合成技術でユーザーの顔に合成して、顔を変えて遊ぶTwitterBotです。

こんな感じで顔変えるBot（@kaokaeru_bot）に人物画像をメンションすると、顔を変えた画像をリプライしてくれます。

髭になってますか？(ΦωΦ) pic.twitter.com/Nk1XcCTr33

— 顔変えるbot(ΦωΦ) (@kaokaeru_bot) 2019年12月25日

「アイドルにして！」、「髭面にして！」のように、なりたい顔を指定することもできます。

昔こんな感じの「リアルバーチャルYoutuber」 という顔を匿名化するWebサービスを個人開発したのですが、こちらがアイデアのベースになっています。

mofmofさんの研修

自分はフリーランスとしてmofmofさんにお世話になっているのですが、まだまだ経験が浅いこともあってmofmofさんの研修を受けさせていただくことができました！

mofmofさんではリーン/アジャイルに関する10程度の研修を、社長のはらぱんさんによる講義/ワークショップの形式で受けることができます。そして研修で学んだことの実践の場として、メンターさんの指導を受けながら一人でプロダクト開発を行います。顔変えるBotはそこで開発したプロダクトです。(通常は1ヶ月かけてRailsアプリの開発を行うそうですが、自分の場合はRailsアプリ開発の経験があったのと他の仕事であまり時間が取れなそうだったので、TwitterBotの開発をさせていただきました。)

ここからは研修で学んだことを自分なりにまとめていきます。

リーン開発の概要

リーン開発には「全ては仮説である」という前提があります。

プロダクト開発を始める際にリーンキャンバス(後述)などのツールを使って、ターゲットとする顧客や解決したい課題を明確にしていきます。しかしそこで想定している顧客や課題はただの仮説です。自分がどれだけ良いプロダクトだと思っても、実際にはそんなものを欲しがっている人はどこにも存在しないかもしれません。そのため実際に使ってもらえるプロダクトを開発するためには、この仮説が正しいかどうかをまず検証する必要があります。

リーン開発では仮説を検証するためにMVP(Minimum Viable Product)を開発します。MVPとは最小限の機能だけを備えた、仮説を検証するためのプロダクトです。MVPを作って、実際にユーザーに使ってもらってフィードバックを受け取り、そこから学んだことをチームで学習し、MVPを修正します。このBuild(構築) -> Measure(測定) -> Learn(学習)のループを繰り返すことで、仮説検証を行っていきます。常にユーザーから学び修正していくので、MVPが最終的にどういう形になるかは予想がつきません。

MVPを作る際には以下のことに気をつけます。

• 機能を最小限にする。機能を作りすぎてしまうと無駄なコストをかけてしまうし、コア機能がぼやけてしまう。仮説検証を行うためには機能は最小限でよい。Must-haveだけ作るようにしてNice-to-haveはスケール時に必要になってから作ればよい。
• 仮説検証に注力する。そのため顧客との対話を重視する。リーンではマーケティングも含めて、全ては検証による学びを得るために行う行為になる。顧客と課題の検証は最優先事項。
• 最小限のコストで作る。リソースは有限なのでリソースが尽きる前に仮説検証する必要がある。そのためには仮説検証ループは素早く回す。
• アーリーアダプタに向けて作る。全員に向けて作ると誰も欲しくないものができてしまう。全員に好まれるものではなく、一部に熱狂的に愛されるものを作る。
• まずは課題の質を上げる。ソリューションの質を上げるのはその後でないと無意味。課題が間違っていたら作り直しになる。

MVPはプロダクトではなくハリボテを作る場合もあります。有名なところではDropboxのデモ動画等がありますが、mofmofさんの場合は実際に触れるプロダクトを作ります。

参考: リーン・スタートアップとMVP/lean-startup-mvp - Speaker Deck

本だとリーン・スタートアップの青本が有名ですが、実践方法について詳しく書いてなくて自分には難しかったです。企業の科学が読みやすくてよかったです。 あと正確にはリーンと違うかもしれませんが、BasecampのGetting Realと小さなチーム、大きな仕事もRailsエンジニアには馴染みがあっておすすめです。

アイデア出し

アイデア出しの基本

一番初めは、どんなプロダクトを作るのかアイデア出しを行います。

アイデア出しでは連想が基本になります。人はなにもないところからアイデアを出すことはできません。必ず何かしらの手がかりを元にして発想を行います。

うまくアイデア出しをするためにはこの手がかりを何らかの形で自分に与える必要があります。例えば「タウンウォッチング法」という発想法があります。街中に出て人やものを観察して、観察したものをメモしておきます。そして街中を歩いた際の記憶やメモを元に新しいアイデアを発想します。ここでとるメモはテキストに限定されません。手がかりになればよいのでイラストでもOKです。

具体的なアイデア出しの方法についてはこちらの「発想する技術」をおすすめされました。30の発想法が網羅的に書いてあります。

欠点列挙法でアイデア出し

自分の場合は以前作った「リアルバーチャルYoutuber」を改善したいという思いがあったので、プロダクトの改善案を発想する「欠点列挙法」という方法を参考にしました。まずプロダクトの欠点を列挙していき、そこから改善案を発想していく発想法です。

「リアルバーチャルYoutuber」は動画をアップロードすると架空の人物の顔に変換してくれるWebサービスです。こちらの欠点を列挙していきます。

欠点としては

• 動画にサイズ制限/時間制限があるため使いにくい
• 動画の顔変換に時間がかかる
• サインアップ、動画作成で離脱してしまう人が多い
• 変換した動画を共有する手段がない

改善案としては

• 動画ではなく画像にすれば、サイズ/時間制限はなくなる
• 動画ではなく画像にすれば、短時間で学習できる
• WebサービスではなくTwitterBotにすれば、離脱ポイントが減る
• WebサービスではなくTwitterBotにすれば、そのまま共有できる

こんな感じで「リアルバーチャルYoutuber」のTwitterBot版を作って、動画の代わりに画像を変換すればもっと使ってもらえるようになるのでは？と発想していきました。

良いアイデアのポイント

リーン開発において良いアイデアには以下のようなポイントがあります。できるだけこれらもおさえておきます。

• 一言で表せるアイデアが良いアイデア。インパクトを与えるためには、一言で表せないといけない。
• 現実の課題を解決するアイデアが良いアイデア。架空の課題を解決しても誰も使ってくれない。
• 自分の課題を解決するアイデアが良いアイデア。顧客 = 自分になるので、課題を深く理解できる。
• 技術ドリブンではなく課題ドリブンなアイデアが良いアイデア(場合による?)

顔変えるbotはどちらかというと課題ありきではなく技術ありきの技術ドリブンなのですが、個人開発とか場合によってはこういうやり方もアリなようです。

リーンキャンバス作成

リーンキャンバスの基本

アイデア出しが終わったら、そのアイデアをリーンキャンバスにまとめます。アイデア出しが発散で、リーンキャンバス作成が収束です。発散と収束は分けて行います。

リーンキャンバスではこんな感じでキャンバスが用意されるので、9つの項目を埋めていきます。

項目を埋めていくことでビジネスモデルを整理できて、実際に開発する価値があるかどうかを分析できます。

リーンキャンバスの良い点は以下のとおりです。

• ビジネスモデルを整理できる。ビジネスアイデアをピッチできるようになる
• ビジネスモデルを分析できる。どこに弱点があるかわかる。
• 簡単に作れる。事業計画書は作るの大変だけど、リーンキャンバスなら10分で作れる。

参考: リーンキャンバスの作り方/how-to-make-lean-canvas - Speaker Deck

リーンキャンバス作成

顔変えるbotのリーンキャンバスはこんな感じになりました。

見にくい場合はこちら -> https://www.mof-canvas.com/canvases/41

この中でも特に重要な項目が課題と顧客セグメントです。しかし今回の顔変えるbotは課題と顧客セグメントがなかなか固まりませんでした。というのも顔変えるbotは、自分の顔を変えてそれをシェアして楽しんでもらうことを想定しています。「楽しむ」とか「遊ぶ」というのをどうやって課題にすればいいのわかりませんでした。メンターさんに相談したところ、例えば女子高生をターゲットにするなら暇を潰したいのかもしれないし、インフルエンサーをターゲットとするならその人達はフォロワーを増やしたいかもしれない。きちんと深堀りすれば出てくることもあるよーとアドバイス頂きました。

これ以外にもハイレベルコンセプトは1つに絞ったほうが良さそうとか、チャネルとしてインフルエンサーさんに使ってもらうのもいいかもねとか、フィードバックをもらいつつさらにブラッシュアップしていきました。

リーンキャンバス作成にはmof-canvasというサービスを使いました。こちらはmofmofの社員さんが研修で作成したサービスになります。使いやすいし、作成から公開まで簡単にできるのでおすすめです。

インセプションデッキ作成

インセプションデッキの基本

インセプションデッキは、10の質問に答えることでプロジェクトの全体像を明確にして、プロジェクトの目的をチームメンバー間で合意するためのドキュメントです。

プロダクト開発をする際、顧客自身が必要なものを的確に表現できるわけではありません。顧客に言われたものをただ作るだけだと、だれも欲しくないものを作ってしまうかもしれません。あるいは全く見当違いなものを作ってしまうかもしれません。顧客に言われたものをなんとなく想像で作るのではなく、顧客が望む価値を実現することが大切です。価値を実現するためには、開発を始める前にそもそもプロジェクトの目的が何なのかを明確にして、それを合意しておく必要があります。インセプションデッキはそのためのドキュメントです。

インセプションデッキ作成時のポイント

• 合意のプロセスが大切。なんとなく合意するのではなく、ちゃんとメンバー間で議論をして合意する。
• 最終的には自分でプロダクトの価値を説明できるようにする。
• 本来はプロダクトオーナーが作るもの。実際には開発者も作って主体となって進めるほうが上手くいく。
• 一度作って終わりではなく、ことある毎に見返して更新していく。

参考: インセプションデッキの作り方/how-to-make-inception-deck - Speaker Deck

インセプションデッキ作成

本来は11枚のスライドを埋めますが、今回は特に大切な4枚を埋めました。

トレードオフ・スライダーでは通常はスコープ/予算/時間/品質の4つのスライダーを使います。ただ「品質」は定義が曖昧になりがちです。保守性の高さを指すのか？見た目の綺麗さを指すのか？バグの少なさを指すのか？、「品質」が何を指すかは自明ではありません。そこで今回は品質の項目は外しました。

研修期間は決まっているので時間はMAXにして、予算に大きな縛りがないのでほぼMINにしています。

インセプションデッキでは合意のプロセスが大切になります。今回は変則的になりますがメンターさんにPOとしてインセプションデッキを作ってもらい、それを議論しながら合意してこの形にしていきました。例えば最初は「たくさんの顔モデルを用意する」というのがやるリストに入っていたのですが、これはMVPには必須ではないのでは？ということでやらないことリストに移したりしました。

ストーリー出し

ストーリー出し

インセプションデッキの作成が終わったら、ユーザーストーリー出しを行います。

ユーザーストーリーとはユーザーが実現したいことを簡潔にまとめた文章です。ユーザーストーリーを作る際は以下のポイントに気をつけます。

• ユーザーにとっての価値に重きを置くために、ユーザー目線で書く
• INVESTを満たしている
  • Independent: 各ストーリーが他のストーリーに依存せず単体で機能する
  • Negotiable: かっちり仕様をきめずに、実装方式について交渉可能である
  • Valuable: 価値を提供できる
  • Estimable: 見積もり可能である
  • Sized appropriately: 適切なサイズである
  • Testable: テスト可能である(受け入れ条件がある)

参考: ユーザーストーリーとは？

実際のストーリー出しではメンターさんと一緒に付箋にストーリーを書き出していきました。一通りストーリーを出し切ったら、ストーリーに抜けがないか確認した後にPivotal Trackerにバックログアイテムとして登録していきます。

今は全てDoneになっていますが、こんな感じのストーリーを出しました。

見積もり

次に登録したストーリーを見積もります。

見積もりとしてストーリーにストーリーポイントを付けていきます。mofmofさんでは「Railsでテーブルに1つカラムを追加して、ビュー等も合わせて変更する」を基準サイズの1としているので、それと比べた相対的なポイントを各ストーリーに付けていきます。理想日のような絶対サイズを使うケースもあるそうですが、ストーリーポイントのような相対サイズを使うほうが主流のようです。

注意すべき点として見積もりはあくまでも見積もりでしかありません。確実な予測ではありませんし、コミットメントでもありません。

参考: 見積もり/agile-estimation - Speaker Deck

実際の見積もりではメンターさんとフィボナッチ数列を用いてプランニングポーカーを行い見積もりました。

参考: プランニングポーカーのやりかた – Ryuzee.com

スコープ削り

見積もりが終わると開発にどれくらいの期間かかりそうかが見えてきます。ベロシティはプロジェクトが進めば計算できるようになるのですが、プロジェクト開始時点だとわからないので今回は経験則的に適当な数字を利用しています。小さなプロダクトなのでストーリーは5つ程度とかなり少なめだったのですが、それでもリリース日(研修の最終日)には間に合わない感じでした。

ここからリリース日に間に合うようにスコープを削っていきます。このプロジェクトは研修期間が決まっているため、トレードオフスライダーの時間はMAXに設定されています。リリース日はずらせません。予算を増やして開発速度を上げられるプロジェクトでもないのでスコープを削るしかありません。

最初は自分には全ての機能が必須に思えたので、削るのは無理なんじゃないかと思いました。しかしメンターさんのアドバイスを元に精査していくと「ユーザーは顔を変換できる」というストーリーはもっと細かく分解できることがわかってきます。ストーリーを細かく分解していくうちに、分解されてできた「ユーザーはなりたい顔を指定できる」というストーリーが実はMVPに必須ではないことが判明します。MPVは実用最小限のプロダクトです。このプロダクトが提供する価値は「顔が変わって、それをみんなと楽しむ」なので、「なりたい顔を指定できる」というストーリーは必ずしも必須ではありません。ただなにかに顔が変わるだけでも目的は達成できます。

こんな感じで必須に見えるけど実際には必須ではないストーリーをスコープ外にしていって、ぎりぎりリリース日に間に合うようにスコープを削れました。（結局最後時間が余ったので、その時にスコープ外にしたストーリーのいくつかは実装したのですが。それはそれでよいのかなーと思います。）

MVP開発

ここまでで開発の準備は整ったので、ここから実際にMVPとなるプロダクトを開発していきます。

今回作成するプログラムはざっくり2つに分けられます。1つはTwitterAPIを利用してメンションから画像を取得してリプライを返すBot側のプログラム。もう1つは画像の顔を変換するAI側のプログラムです。

Bot側のプログラム作成

TwitterAPIを使うためにAPI申請をします。最近申請が厳しくなったと聞いていたので、実はここが一番不安でした。でもこの記事を参考に申請してみると、すんなり審査は通りました。

申請したTwitterAPIを使ってBot側のプログラムを書いていきます。顔変えるBotではメンションされた画像を加工するため、メンションを監視する必要があります。Account Activity APIというのを使えばWebhookで通知を受け取れるらしいのですが、別途申請が必要だったり結構面倒なことが多いそうです。なので単純にRubyプロセスを常駐させて、メンションが来ていないか確認するためにREST APIをポーリングする形にしました。

Bot側のプログラムは特に難しいこともなく順調に進みました。

AI側のプログラム作成

顔画像を変換するのにディープラーニングを利用するのでGPUサーバーが必要です。クラウドを使うと数万円/月かかってしまうので自前のGPUサーバーを利用します。（ただのゲーミングPCに電源やGPUを追加しただけですが。）久しぶりにPCを触ったら画面が付かなくて焦りました。結局はマザボに電源を供給するケーブルが劣化していただけだったのですが、これを解決するのに1~2日もってかれてなかなか辛い感じでした...💦

AI側のプログラムは「リアルバーチャルYoutuber」で作ったプログラムを流用しています。AIで顔変換する部分とWebサービスが密結合になっていたので、そこだけ修正して独立した形で使えるようにしました。学習モデルはそのまま流用できる感じだったので流用しています。

GPUサーバーのセットアップ(物理)にかなりてこずりましたが、なんとかリリースまでに完成できました。

完成したプロダクトで社員さんの顔を変えて遊んでいたら、結構喜んでもらえました。よかったよかった🐈

KPTでふりかえり

KPTの基本

最後に研修全体をKPTでふりかえります。

KPT(Keep/Problem/Try)とはシンプルで強力なふりかえりの手法です。

3つの要素に分けて現状分析を行います。

• Keep: 良かったこと（今後も続けること）
• Problem: 悪かったこと（今後はやめること）
• Try: 次に挑戦すること（Problemの改善策、Keepでさらに改善すること）

ふりかえりを円滑にすすめるために、以下のグラウンドルールが用意されています。

• 積極的に話し、参加する
  • 当事者意識を持つ
• 1人で話しすぎない
  • 発言をさえぎらない
  • 話してない人にも思いあり
• 原因追求をする。個人の責任追求をしない
  • 罪を憎んで人を憎まず
  • 「人 vs 人」ではなく、「チーム vs 問題」の構図を意識する
  • だから自己弁護も不要

参考: 振り返り/agile-looking-back - Speaker Deck

KPTでふりかえり

まず自分とメンターさんと社長でそれぞれKeepとProblemを付箋に書き出して、その後Problemに対するTryを出し合っていきました。

こんな感じです。

左がKeep、右がProblem/Try

• Keep
  • 期日通りリリースできた
  • 研修で学んだことをプロダクト開発を通じて一通り実践できた
  • スコープ削りができた
• Problem -> Try
  • GPUサーバーのセットアップに苦戦して期限危うかった -> 必須でリスクが高いストーリーは先に見通しをたてておく
  • コードレビューできなかった -> 詳細設計とか話し合っておけばその時にできた
  • 研修で学んだことをもう忘れそう -> 研修で学んだことをブログにまとめれば思い出す

まず期日通りリリースできたのが何よりでした。あとは講義で学んだことを実際のプロダクト開発を通じて一通りできたのは良い経験になりました。こういうのは実際にやってみないとわからないことも多いし、身につかないものだと思うので。正直これだけだとまだ基礎を抑えただけなので今後実務で経験を積んでいかなければならないのですが、フリーランスの研修としては十分すぎるほど時間を使わせてもらえて良い経験を積むことができました。

さいごに

メンターとして開発に付き合ってくださった @sssgggiiiさん、@harada4atsushi さん、お二人のおかげでなんとか完成させることができました。本当にありがとうござました🙇

自分の中ではこの記事の公開がプロダクトの正式リリースのつもりなのですが、なんとか形になってほっとした気持ちです。

リーン開発としてはBuild -> Measure -> Learnループの最初のBuildが終わっただけで、ここからが本番な感じです。今後は実際に使ってもらってフィードバックループを回していけたらなーと思います。（ただしすでにやる気が消えかけてます 。個人開発で一度リリースするとやる気が消える問題、いい加減どうにかしたいです・・・😇）