欠点列挙法でアイデア出し良いアイデアのポイントリーンキャンバス作成リーンキャンバスの基本リーンキャンバス作成インセプションデッキ作成インセプションデッキの基本インセプションデッキ作成ストーリー出しストーリー出し見積もりスコープ削りMVP開発Bot側のプログラム作成AI側のプログラム作成KPTでふりかえりKPTの基本KPTでふりかえりさいごにはじめに先月からお世話になっているmofmofさんの研修で、顔を変えて遊ぶTwitterBotを開発しました。この記事は開発したTwitterBotの紹介と、mofmofさんで学んだ研修内容のまとめです。「顔変えるBot」は、AIが生み出した実在しない人物の顔を、AIによる顔合成技術でユーザーの顔に合成して、顔を変えて遊ぶTwitterBotです。こんな感じで顔変えるBot(@kaokaeru_bot)に人物画像をメンションすると、顔を変えた画像をリプライしてくれます。「アイドルにして!」、「髭面にして!」のように、なりたい顔を指定することもできます。いう顔を匿名化するWebサービスを個人開発したのですが、こちらがアイデアのベースになっています。自分はフリーランスとしてmofmofさんにお世話になっているのですが、まだまだ経験が浅いこともあってmofmofさんの研修を受けさせていただくことができました!mofmofさんではリーン/アジャイルに関する10程度の研修を、社長のはらぱんさんによる講義/ワークショップの形式で受けることができます。研修で学んだことの実践の場として、メンターさんの指導を受けながら一人でプロダクト開発を行います。顔変えるBotはそこで開発したプロダクトです。(通常は1ヶ月かけてRailsアプリの開発を行うそうですが、自分の場合はRailsアプリ開発の経験があったのと他の仕事であまり時間が取れなそうだったので、TwitterBotの開発をさせていただきました。)ここからは研修で学んだことを自分なりにまとめていきます。開発の概要リーン開発には「全ては仮説である」という前提があります。プロダクト開発を始める際にリーンキャンバス(後述)などのツールを使って、ターゲットとする顧客や解決したい課題を明確にしていきます。そこで想定している顧客や課題はただの仮説です。自分がどれだけ良いプロダクトだと思っても、実際にはそんなものを欲しがっている人はどこにも存在しないかもしれません。そのため実際に使ってもらえるプロダクトを開発するためには、この仮説が正しいかどうかをまず検証する必要があります。Product)を開発します。MVPとは最小限の機能だけを備えた、仮説を検証するためのプロダクトです。MVPを作って、実際にユーザーに使ってもらってフィードバックを受け取り、そこから学んだことをチームで学習し、MVPを修正します。Learn(学習)のループを繰り返すことで、仮説検証を行っていきます。常にユーザーから学び修正していくので、MVPが最終的にどういう形になるかは予想がつきません。MVPを作る際には以下のことに気をつけます。機能を作りすぎてしまうと無駄なコストをかけてしまうし、コア機能がぼやけてしまう。仮説検証を行うためには機能は最小限でよい。Must-haveだけ作るようにしてNice-to-haveはスケール時に必要になってから作ればよい。そのため顧客との対話を重視する。リーンではマーケティングも含めて、全ては検証による学びを得るために行う行為になる。リソースは有限なのでリソースが尽きる前に仮説検証する必要がある。そのためには仮説検証ループは素早く回す。アーリーアダプタに向けて作る。全員に向けて作ると誰も欲しくないものができてしまう。全員に好まれるものではなく、一部に熱狂的に愛されるものを作る。ソリューションの質を上げるのはその後でないと無意味。課題が間違っていたら作り直しになる。MVPはプロダクトではなくハリボテを作る場合もあります。有名なところではDropboxのデモ動画等がありますが、mofmofさんの場合は実際に触れるプロダクトを作ります。Deck本だとリーン・スタートアップの青本が有名ですが、実践方法について詳しく書いてなくて自分には難しかったです。企業の科学が読みやすくてよかったです。Realと小さなチーム、大きな仕事もRailsエンジニアには馴染みがあっておすすめです。初めは、どんなプロダクトを作るのかアイデア出しを行います。アイデア出しでは連想が基本になります。人はなにもないところからアイデアを出すことはできません。何かしらの手がかりを元にして発想を行います。うまくアイデア出しをするためにはこの手がかりを何らかの形で自分に与える必要があります。「タウンウォッチング法」という発想法があります。街中に出て人やものを観察して、観察したものをメモしておきます。街中を歩いた際の記憶やメモを元に新しいアイデアを発想します。ここでとるメモはテキストに限定されません。手がかりになればよいのでイラストでもOKです。具体的なアイデア出しの方法についてはこちらの「発想する技術」をおすすめされました。30の発想法が網羅的に書いてあります。欠点列挙法でアイデア出し自分の場合は以前作った「リアルバーチャルYoutuber」を改善したいという思いがあったので、プロダクトの改善案を発想する「欠点列挙法」という方法を参考にしました。プロダクトの欠点を列挙していき、そこから改善案を発想していく発想法です。「リアルバーチャルYoutuber」は動画をアップロードすると架空の人物の顔に変換してくれるWebサービスです。こちらの欠点を列挙していきます。欠点としては動画にサイズ制限/時間制限があるため使いにくい動画の顔変換に時間がかかるサインアップ、動画作成で離脱してしまう人が多い変換した動画を共有する手段がない改善案としては動画ではなく画像にすれば、サイズ/時間制限はなくなる動画ではなく画像にすれば、短時間で学習できるWebサービスではなくTwitterBotにすれば、離脱ポイントが減るWebサービスではなくTwitterBotにすれば、そのまま共有できるこんな感じで「リアルバーチャルYoutuber」のTwitterBot版を作って、動画の代わりに画像を変換すればもっと使ってもらえるようになるのでは?と発想していきました。良いアイデアのポイントリーン開発において良いアイデアには以下のようなポイントがあります。できるだけこれらもおさえておきます。一言で表せるアイデアが良いアイデア。インパクトを与えるためには、一言で表せないといけない。現実の課題を解決するアイデアが良いアイデア。架空の課題を解決しても誰も使ってくれない。自分の課題を解決するアイデアが良いアイデア。自分になるので、課題を深く理解できる。技術ドリブンではなく課題ドリブンなアイデアが良いアイデア(場合による?)顔変えるbotはどちらかというと課題ありきではなく技術ありきの技術ドリブンなのですが、個人開発とか場合によってはこういうやり方もアリなようです。リーンキャンバス作成リーンキャンバスの基本アイデア出しが終わったら、そのアイデアをリーンキャンバスにまとめます。アイデア出しが発散で、リーンキャンバス作成が収束です。発散と収束は分けて行います。リーンキャンバスではこんな感じでキャンバスが用意されるので、9つの項目を埋めていきます。項目を埋めていくことでビジネスモデルを整理できて、実際に開発する価値があるかどうかを分析できます。リーンキャンバスの良い点は以下のとおりです。ビジネスモデルを整理できる。ビジネスアイデアをピッチできるようになるビジネスモデルを分析できる。どこに弱点があるかわかる。事業計画書は作るの大変だけど、リーンキャンバスなら10分で作れる。顔変えるbotのリーンキャンバスはこんな感じになりました。https://www.mof-canvas.com/canvases/41この中でも特に重要な項目が課題と顧客セグメントです。今回の顔変えるbotは課題と顧客セグメントがなかなか固まりませんでした。いうのも顔変えるbotは、自分の顔を変えてそれをシェアして楽しんでもらうことを想定しています。「楽しむ」とか「遊ぶ」というのをどうやって課題にすればいいのわかりませんでした。メンターさんに相談したところ、例えば女子高生をターゲットにするなら暇を潰したいのかもしれないし、インフルエンサーをターゲットとするならその人達はフォロワーを増やしたいかもしれない。深堀りすれば出てくることもあるよーとアドバイス頂きました。これ以外にもハイレベルコンセプトは1つに絞ったほうが良さそうとか、チャネルとしてインフルエンサーさんに使ってもらうのもいいかもねとか、フィードバックをもらいつつさらにブラッシュアップしていきました。リーンキャンバス作成にはmof-canvasというサービスを使いました。こちらはmofmofの社員さんが研修で作成したサービスになります。使いやすいし、作成から公開まで簡単にできるのでおすすめです。インセプションデッキ作成インセプションデッキの基本インセプションデッキは、10の質問に答えることでプロジェクトの全体像を明確にして、プロジェクトの目的をチームメンバー間で合意するためのドキュメントです。プロダクト開発をする際、顧客自身が必要なものを的確に表現できるわけではありません。顧客に言われたものをただ作るだけだと、だれも欲しくないものを作ってしまうかもしれません。見当違いなものを作ってしまうかもしれません。顧客に言われたものをなんとなく想像で作るのではなく、顧客が望む価値を実現することが大切です。価値を実現するためには、開発を始める前にそもそもプロジェクトの目的が何なのかを明確にして、それを合意しておく必要があります。インセプションデッキはそのためのドキュメントです。インセプションデッキ作成時のポイント合意のプロセスが大切。なんとなく合意するのではなく、ちゃんとメンバー間で議論をして合意する。最終的には自分でプロダクトの価値を説明できるようにする。本来はプロダクトオーナーが作るもの。実際には開発者も作って主体となって進めるほうが上手くいく。一度作って終わりではなく、ことある毎に見返して更新していく。本来は11枚のスライドを埋めますが、今回は特に大切な4枚を埋めました。トレードオフ・スライダーでは通常はスコープ/予算/時間/品質の4つのスライダーを使います。「品質」は定義が曖昧になりがちです。保守性の高さを指すのか?見た目の綺麗さを指すのか?バグの少なさを指すのか?、「品質」が何を指すかは自明ではありません。そこで今回は品質の項目は外しました。研修期間は決まっているので時間はMAXにして、予算に大きな縛りがないのでほぼMINにしています。インセプションデッキでは合意のプロセスが大切になります。今回は変則的になりますがメンターさんにPOとしてインセプションデッキを作ってもらい、それを議論しながら合意してこの形にしていきました。最初は「たくさんの顔モデルを用意する」というのがやるリストに入っていたのですが、これはMVPには必須ではないのでは?ということでやらないことリストに移したりしました。ストーリー出しストーリー出しインセプションデッキの作成が終わったら、ユーザーストーリー出しを行います。ユーザーストーリーとはユーザーが実現したいことを簡潔にまとめた文章です。ユーザーストーリーを作る際は以下のポイントに気をつけます。ユーザーストーリーとは?実際のストーリー出しではメンターさんと一緒に付箋にストーリーを書き出していきました。Trackerにバックログアイテムとして登録していきます。今は全てDoneになっていますが、こんな感じのストーリーを出しました。見積もり次に登録したストーリーを見積もります。見積もりとしてストーリーにストーリーポイントを付けていきます。mofmofさんでは「Railsでテーブルに1つカラムを追加して、ビュー等も合わせて変更する」を基準サイズの1としているので、それと比べた相対的なポイントを各ストーリーに付けていきます。理想日のような絶対サイズを使うケースもあるそうですが、ストーリーポイントのような相対サイズを使うほうが主流のようです。注意すべき点として見積もりはあくまでも見積もりでしかありません。確実な予測ではありませんし、コミットメントでもありません。Deck実際の見積もりではメンターさんとフィボナッチ数列を用いてプランニングポーカーを行い見積もりました。Ryuzee.comスコープ削り見積もりが終わると開発にどれくらいの期間かかりそうかが見えてきます。ベロシティはプロジェクトが進めば計算できるようになるのですが、プロジェクト開始時点だとわからないので今回は経験則的に適当な数字を利用しています。小さなプロダクトなのでストーリーは5つ程度とかなり少なめだったのですが、それでもリリース日(研修の最終日)には間に合わない感じでした。ここからリリース日に間に合うようにスコープを削っていきます。このプロジェクトは研修期間が決まっているため、トレードオフスライダーの時間はMAXに設定されています。リリース日はずらせません。予算を増やして開発速度を上げられるプロジェクトでもないのでスコープを削るしかありません。最初は自分には全ての機能が必須に思えたので、削るのは無理なんじゃないかと思いました。メンターさんのアドバイスを元に精査していくと「ユーザーは顔を変換できる」というストーリーはもっと細かく分解できることがわかってきます。ストーリーを細かく分解していくうちに、分解されてできた「ユーザーはなりたい顔を指定できる」というストーリーが実はMVPに必須ではないことが判明します。MPVは実用最小限のプロダクトです。このプロダクトが提供する価値は「顔が変わって、それをみんなと楽しむ」なので、「なりたい顔を指定できる」というストーリーは必ずしも必須ではありません。なにかに顔が変わるだけでも目的は達成できます。こんな感じで必須に見えるけど実際には必須ではないストーリーをスコープ外にしていって、ぎりぎりリリース日に間に合うようにスコープを削れました。(結局最後時間が余ったので、その時にスコープ外にしたストーリーのいくつかは実装したのですが。それはそれでよいのかなーと思います。)MVP開発ここまでで開発の準備は整ったので、ここから実際にMVPとなるプロダクトを開発していきます。今回作成するプログラムはざっくり2つに分けられます。1つはTwitterAPIを利用してメンションから画像を取得してリプライを返すBot側のプログラム。1つは画像の顔を変換するAI側のプログラムです。Bot側のプログラム作成TwitterAPIを使うためにAPI申請をします。最近申請が厳しくなったと聞いていたので、実はここが一番不安でした。この記事を参考に申請してみると、すんなり審査は通りました。申請したTwitterAPIを使ってBot側のプログラムを書いていきます。顔変えるBotではメンションされた画像を加工するため、メンションを監視する必要があります。APIというのを使えばWebhookで通知を受け取れるらしいのですが、別途申請が必要だったり結構面倒なことが多いそうです。APIをポーリングする形にしました。Bot側のプログラムは特に難しいこともなく順調に進みました。顔画像を変換するのにディープラーニングを利用するのでGPUサーバーが必要です。クラウドを使うと数万円/月かかってしまうので自前のGPUサーバーを利用します。(ただのゲーミングPCに電源やGPUを追加しただけですが。)久しぶりにPCを触ったら画面が付かなくて焦りました。結局はマザボに電源を供給するケーブルが劣化していただけだったのですが、これを解決するのに1~2日もってかれてなかなか辛い感じでした...💦AI側のプログラムは「リアルバーチャルYoutuber」で作ったプログラムを流用しています。AIで顔変換する部分とWebサービスが密結合になっていたので、そこだけ修正して独立した形で使えるようにしました。学習モデルはそのまま流用できる感じだったので流用しています。GPUサーバーのセットアップ(物理)にかなりてこずりましたが、なんとかリリースまでに完成できました。完成したプロダクトで社員さんの顔を変えて遊んでいたら、結構喜んでもらえました。最後に研修全体をKPTでふりかえります。KPT(Keep/Problem/Try)とはシンプルで強力なふりかえりの手法です。3つの要素に分けて現状分析を行います。次に挑戦すること(Problemの改善策、Keepでさらに改善すること)ふりかえりを円滑にすすめるために、以下のグラウンドルールが用意されています。積極的に話し、参加する当事者意識を持つ1人で話しすぎない発言をさえぎらない話してない人にも思いあり原因追求をする。DeckKPTでふりかえりまず自分とメンターさんと社長でそれぞれKeepとProblemを付箋に書き出して、その後Problemに対するTryを出し合っていきました。研修で学んだことをブログにまとめれば思い出すまず期日通りリリースできたのが何よりでした。あとは講義で学んだことを実際のプロダクト開発を通じて一通りできたのは良い経験になりました。いうのは実際にやってみないとわからないことも多いし、身につかないものだと思うので。これだけだとまだ基礎を抑えただけなので今後実務で経験を積んでいかなければならないのですが、フリーランスの研修としては十分すぎるほど時間を使わせてもらえて良い経験を積むことができました。さん、お二人のおかげでなんとか完成させることができました。自分の中ではこの記事の公開がプロダクトの正式リリースのつもりなのですが、なんとか形になってほっとした気持ちです。Learnループの最初のBuildが終わっただけで、ここからが本番な感じです。今後は実際に使ってもらってフィードバックループを回していけたらなーと思います。(ただしすでにやる気が消えかけてます。14:01リーンでアジャイルでモフモフなTwitterBot開発Tweet広告を非表示にする関連記事2020-01-02よわよわRailsエンジニアのジレンマこんにちは。よわよわRailsエンジニア愛知代表のshitaです。月別アーカイブ検索はてなブログをはじめよう!nekorailsさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。