タスク・プロジェクト管理ツール
Jooto
「1を聞くと10返ってくる」多国籍チームの熱い思い
タスク・プロジェクト管理ツール『Jooto』の開発秘話
株式会社PR TIMES
チーム提案型開発
開発分野： SaaS
組織規模： 11-100名
国内シェアNo.1のプレスリリース配信代行サービスのPR TIMESが、新規事業として取り組むタスク・プロジェクト管理ツールJooto。スタートアップが展開していたサービスを買収してはじまったこの事業部について、譲渡元であり生みの親でもある原氏に、これまでの経緯とスタートアップと大企業の関係について伺いました。
国内シェアNo.1のプレスリリース配信サービス企業の新たな挑戦
PR TIMESの中でJooto事業部がスタートした経緯について教えてください。
原：Jooto事業部は、もともとは2014年に私と、元Jooto事業部本部長である下田がシンガポールで立ち上げたスタートアップで、2017年の10月にPR TIMESに事業譲渡しました。その際に、Jootoの立ち上げメンバーである私たちもPR TIMESにジョインして欲しい、というお話をいただいてPR TIMESに入りました。
プレスリリース事業×プロジェクト管理ツールという戦略
Jootoはプレスリリースと直接的には関係がないツールですが、なぜPR TIMESを巻き込んで、一緒にやっていこうと思ったのでしょうか。
原：プレスリリースを担当する方のほとんどが広報です。弊社の代表の山口が、その方々のタスク管理をなんとかしたいという思いを持っていたんです。広報の方達ってすごく忙しくて、日々いろいろなタスクが上がってくる。そこにJootoと親和性があるのではないかということで興味を持っていただいておりました。最初は、PR TIMESとのクロスセルのような形でアプローチをかけてみないか、というお話がきっかけでした。
サービスの開始当初から、将来的な事業譲渡は見据えており、M&Aは目指したいね、という話も下田としていました。サービス自体も突き詰めていくうえで、ユーザーからの認知、シェアが広がっていけば良いなと考えていました。
国境に縛られない会社経営
シンガポールで起業された理由を教えてください。
原：私と下田が出会ったのはシンガポールでした。その当時は、Jootoは始めていなくて、下田とはバンド仲間でした。一緒に住んだり、色々なことをしている間に、新しいことしたいね、という話になってJootoを立ち上げました。会社自体はシンガポールに登記していたんですが、働く拠点は、しばらくして下田だけ日本に帰って、私は台湾にそのまま残り、そこからリモートでやっていたという感じですね。Jootoを始めた当初から、ホーチミンのオフショア開発会社に依頼をしていました。
もともと将来起業したいとお考えだったのでしょうか。
原：そういうマインドは一切なかったです。普通に働いていて、特に仕事に対する夢とか思いみたいなものもありませんでした。ところが、シンガポールで下田も含め日本では会えないような人々に出会えて「自分たちでもできるんだ」っていう自分の中のマインドセットが結構変わりました。
ホーチミンのオフショア開発会社からSun*へ乗り換えられた理由について教えてください。
原：そうですね。主に下田はWebマーケティング、僕が技術側を担当していました。1年半から2年くらいの間、ホーチミンのオフショア開発会社とやっていたんですけど、スピード感や品質に不満がありました。どうしたらいいか考えていた時に、下田がもともと働いていた会社がSun*を使っていてうまくいっているという話を聞いて、Sun*への切り替えを決めました。たしか、2016年の10月でした。
初めてのオフショア開発、肌で感じた認識のズレ
品質についての不満があったということですが、具体的には、どういったところに課題を感じられていたんでしょうか。
原：機能の追加や改善といったマイナーチェンジを行う上で、こちら側の意図が伝わらなくて、結局バグが多くなってしまったりとか、向こうの方で私の要望を吸い上げて作ったモックアップが、QAのテスト段階ですごく不備が多かったことを課題に感じていました。あとは見積もりですね。オフショア先が提示する工数の見積もりと実際の稼働時間に、すごく差異がありました。こちらとしてはその工数に伴って、どういう風に進めて行くかを考えていくんですが、そこのズレがあまりにも大きかったんです。
日本の開発会社にお願いするという選択肢もなくはなかったんですが、2人で会社を回していたもので、コストのところでやはり問題がありました。その当時のJooto自体の売り上げもそこまで芳しくなく、投資も資金的に厳しかったので、そこはベトナムのオフショアでいこうと決めました。ちょうどその時にSun*の品質に関する評価を聞いて、お願いしようかなと思ったんです。
日本でフリーランスのエンジニアを活用したり、自社でエンジニアを採用するといった選択肢はありましたか？
原：そこはかなり難しかったですね。私は台湾、下田は日本にいたので普段はリモートで作業していました。そうなると、どこの拠点で採用すべきかという問題もあります。会社はシンガポールに登記されているので、給与の渡し方の問題もありました。また、開発の規模自体が結構大きいため、そのボリュームをフリーランスでまかなうというイメージがあまり持てませんでした。だったら最初から、Jootoの開発にも使用されているRuby on Railsに特化したチームを持っているSun*にお願いしようと思ったんです。
経験を積む中で見えてきた、外国人同士のコミュニケーションならではの強み
オフショアのコミュニケーションに課題を抱えている会社が多い中で、どのような工夫をされていますでしょうか。
原：日本人でチームを作っても、結局コミュニケーションの問題は起こります。実は、外国人同士の方が正直にはっきりと物事を伝えることができるので、コミュニケーションが簡単だったりします。日本の方と単刀直入なコミュニケーションをしようとすると、相手のモチベーションが下がってしまうこともあると思いますが、海外の方だとそういったことはほとんどありません。その上で、こちらの意図が相手に伝わっているかどうかを、細かく確かめるようなコミュニケーションを心がけています。
また、今回の開発ではSun*の開発チームの技術力や、マネージャー層の方々のスキルの高さをすごく感じました。プロダクトのリニューアルという大きなプロジェクトに向けてメンバーを増員したため、チームビルディングがすごく大事な要素でしたが、そこについてもマネージャーの方が親身にやってくださって、非常に助かりました。
今年の2月、リニューアルを始める直前に2週間ほどベトナムに行って、開発メンバーの方々と食事をしたんですが、彼らは思ったよりシャイで、意外と話してくれませんでした(笑)。それでも、実際に会うと会わないとでは違いました。僕が日本に帰った後、彼らと話す頻度がすごく増えて、結果として開発が効率的に進みました。
以前のオフショア開発会社と比べて、サポート体制という点ではどのような違いがありましたか？
原：リリースのスケジュールに間に合わないことがわかった時、どうすべきか事前に提案してくれたり、マネージャーだけでは管理しきれない部分を他のメンバーがサポートしてくれたり、僕が知らない間にいろいろ動いてくれていたのですが、そういった組織でサポートしてくれるようなことは以前依頼していた会社にはありませんでした。
例えば、Jootoの開発ではBackbone.jsというフレームワークをフロントエンド側で使っているんですが、これが結構古いフレームワークで運用の仕方を知っている人が少なく、チーム内で共有するのに時間がかかったことがありましたが、そういった課題を明確にクリアしてくれるというのはすごくありがたかったです。
今回の開発で印象に残っている出来事はありますか？
原：今回、リニューアルのデザイン構築をグッドパッチさんにお願いして、そのデザインをSun*に投げたんです。そしたら、エンジニアの子が僕にいきなりメッセージを送ってきて、「このデザインは、今まで僕が見てきた中で最高のUIだ」と言ってくれました。それがすごい印象的で、そういう情熱を持ってプロダクト開発に取り組んでくれたのが嬉しかったです。
また、うちのラボは少し特殊で、ベトナム、カンボジア、バングラデシュの三ヶ国の人々が混ざっているため、やりとりはすべて英語です。カンボジアの方々は途中からリモートで参画しており、バングラディッシュの方達はSun* オフィスにいます。彼らは非常に優秀です。コーディングのレベルが高いだけでなく、「こういう場合は、ユーザーとしてはこうなんじゃないか」といったユーザー視点の意見をどんどん出してくれます。1を言うと、1しか返ってこないのがオフショアだと思うんですが、彼らに1を言うと10が返ってくる、そこがすごいと思いました。
徹底的に掘り下げた「シンプル」から生まれる「安心感」
デザインとシステムの部分でこだわった点を教えてください
原：今回のリニューアルでは「今が見える安心感」というコンセプトでUI/UXを構築しました。リニューアルする前は、デザイン・UI/UXという部分をそこまで考えられていませんでした。「シンプル」というコンセプトでやってはいたんですが、そこを深掘りした建設的な開発が一切できていませんでした。なので、その部分についてグッドパッチさんと一緒に議論できたのは大きかったです。あとは、やっぱりタスク管理サービス自体が世の中にごまんとあるんですが、その中でもどういったユーザーに提供すべきか、というペルソナを立てて進めていました。
結果としてデザインはガラッと変わりました。なので、ユーザーの方々も最初は迷われるかな、という不安はあったんですが、とても良い評価をいただいています。現在、iOSとAndroidでも開発を進めていますので、そこが１つの分岐点になると思います。
だれでも使えるから、プロジェクト全体の管理がもっとスムーズに
他のツールにはない、Jootoの強みはなんでしょうか。
原：入口の強みは、導入コストの低さです。機能面だと、タスク・プロジェクト管理ツールという観点では、機能数はそこまで多くありません。ですが、あくまでシンプルに、誰でも使えるというコンセプトに基づいて開発しているので、エンジニア、QA、デザイナー、そういった方々がすぐに集約して、マネージャーを含めたタスク管理ができるというのが強みだと思います。プロジェクト管理に特化したツールは他にもありますが、導入するとなると、それ自体を学ぶ学習コストがかかります。そこを払拭したいという思いはあります。ただ、後々は機能拡充もしていく予定です。
Jootoを上手く使いこなすコツがあれば教えてください。
原：各所にあるフェーズを切り分けてステータスがどういう状態なのかをリストにおく、というのが重要だと思います。あとはプレイヤーとマネージャーをつなげた上での、タスク自体のステータス管理とカテゴリー管理です。カテゴライズしたものを色で判別して、俯瞰でパッとわかるUIを実現させているので、そこをうまく使っていただけると嬉しいです。また、ガントチャートも入っているので、それぞれの部分における進捗、進み具合を把握しながら進めることもできます。自社で開発したガントチャートを入れており、サードパーティ製のものを繋げる必要がないので、セキュリティの観点からも安心です。
SlackやChatworkといったコミュニケーションツールも合わせて使っていますが、あくまでプッシュ用です。僕の場合は開発メンバーとビデオ会議も行わず、Jooto上でほぼ全てのタスク・プロジェクト管理をしています。
オフショアならではの情熱を感じた瞬間
オフショアに対してネガティブな印象を持っていたり、オフショアを検討している企業に対するアドバイスやヒントなどをいただけますか
原：「どこまでやってもらうか」「どこから関わってもらうか」の切り分けが重要です。上流、中流、下流といった工程での役割を明確にすることはすごく大事だと思います。僕もその辺は過去に何回か失敗しているんですが、きちんと明確にしないと最終的に問題が起きたりします。逆に、そこをしっかり明確にできるのであれば、オフショアを活用するのがベストですね。日本の開発会社に対するコストメリットもありますが、品質もSun*であれば安心して任せられます。
あとは、開発に対する思いです。ベトナムに伺った時に、開発チームのモチベーションや情熱をとても強く感じました。これは日本にはないものだな、というのはすごく感じたので、あの熱量が好きな方は是非、使っていただいた方がいいと思います。
具体的にはどのような熱量を感じられましたか？
原：彼らの朝のミーティングに参加させてもらった時に、リーダーもマネージャーもベトナムの方なんですが、すごい喧嘩するんです(笑)。ベトナム語で話している内容はわからないんですが、はたから見ても言い争っているのが分かる感じでした。朝の8時からですよ(笑)。後で聞いたら、JootoのQAメンバーとプログラマーが、こうじゃないか、ああじゃないか、みたいな熱い議論をしていたと聞いて、僕らの製品にここまで情熱を持ってくれていることが嬉しかったです。
また、SlackやJooto上でもエンジニアやQAの方々、マネージャーの方が、こういうパターンやこういうバグがあるんじゃないか、といったことを指摘した上で、改善案を提案もしてくれるんです。前のオフショア会社にはそういうところはなかったです。彼らが持っている情熱をすごく感じて、こっちも頑張らなきゃと思え、そこにすごく意義を感じました。喧嘩みたいに言い争っている部分はあるんですけど、チームとしてそうあるべきで、そういう過程を経てサービスができるというのは、ある意味正しいことだと思いました。
オフショアだけど、「自分のチーム」
今後のオフショア活用についてどのように考えているのかを教えて下さい
原：現状では、iOS(2018年9月14日にリリース済み)とAndroidのリリースが目下の目標で、Webの方では第二フェーズとして新しい機能を構築している最中です。これから様々な機能拡充を行い、Jootoをもっとユーザーさんに好きになってもらえるように、Sun*と一緒に走り抜けたいと考えています。
もちろん、オフショアに発注しているっていう感覚はどこかにはあるんですけど、実感としては「自分のチームだ」という風に捉えている部分が90%くらいあります。このメンバーたちと、マネージャーと一緒に、どういう風に計画してやっていけばいいだろうっていうのを常に考えて動いています。
なので、「この人たちしかいない」というのが根底にあります。
開発を振り返って
クライアントとの信頼関係があったから、チャレンジできた
Le Dinh Vu-Project Leader
今回のプロジェクトでは、正常にリニューアルができると確信していました。元々のコードは旧バージョンのRailsやBackbone.jsなど古いものが使われていましたが、AWSや他の技術は以前からうまく使用されていたからです。今回のリニューアルでは、ユーザーによりよい体験を提供できるよう大幅にUX/UIを変更することで、ソースコードのすべてのコンポーネントを変更する必要がありました。また、スケジュールの圧迫のため、最初のリリースではシステムのパフォーマンスを保証することができず、私達の最初のチャレンジは失敗となりました。
しかし、プロダクトオーナーからの激励や、Jootoとユーザーの信頼関係により、私たち開発チームも落胆することなくシステムのパフォーマンスを向上させるためのさまざまなソリューションを探し続けることができました。
最終的に、Jootoリニューアルプロジェクトは無事リリースを迎えることができました。リニューアルに際してリファクタリングをしたクライアント側のコンポーネントは、コードの重複などを防ぎ、システムの構造改善に大きく役立つこともできました。また、DBへのクエリも最小限に抑えるよう最適化することもできました。
今回のプロジェクトでは、ベトナム・カンボジア・バングラデシュの3ヶ国の国籍からなるチームが結成されました。クライアントは日本ですが、BrSEは立てず、開発はすべて英語で行われました。そのため、メンバーがプロダクトオーナーに直接ソリューションを提案するなどして、開発期間の短縮を実現することができました。プロダクトオーナーも非常にフレンドリーで私たちを信頼してくれたので、プロジェクトにおけるコミュニケーションは非常に快適でした。このプロジェクトで課題が発生したとき、私たちに、解決策を提案し受け入れてもらえる機会をいただけたことに感謝しています。
開発しているプロダクトそのものを使った開発が面白かった
Kieu Viet Hung - Backend Engineer
私は最初、Jootoをredmineのようなタスク管理ツールだと思っていましたが、開発プロジェクトで実際に導入してみて、このツールはredmineよりも優れていることに気付きました。Jootoは非常に効率的なスクラムツールであり、ボード上にタスクを特定の順序で配置することでタスクを簡単に管理するだけではなく、状況の変化しやすいプロジェクトでもチームメンバーの状況を把握することが可能になります。
今回のプロジェクトでは、インターフェースの全面リニューアルでユーザーによりよいUXを提供することがゴールでした。新しい機能と、システムのパフォーマンス向上に加えて、Backbone.jsを利用した古いコードをリファクタリングすることは私にとって難しいチャレンジでした。
しかし、メンバー同士や、特にPR TIMESさん側からの熱心なサポートで問題をひとつひとつ解決することができました。それにより各自がミッションを達成し、プロジェクトをゴールに導くことができました。このプロジェクトで面白いのは、開発しているプロダクトそのものをプロジェクトの管理ツールとして導入していたことです。私たち自身がプロダクトを常に触りながら、本当に良いものを作ろうとする、最高の経験を得ることができました。
チャレンジングなスケジュールでもこなせるスピード感があった
Bui Quy Tuyen -iOS Engineer
私がプロジェクトに参加したのは、Jootoのインターフェース変更と新機能の追加が決まり、チームメンバーの数が大幅に増えたタイミングでした。それまでラボにいたフロントエンドとバックエンドのメンバーに加え、iOSエンジニアとAndroidエンジニアがそれぞれ5人ずつ新たに加わりました。チームの人数が増えれば、仕様管理やタスク割り当て、およびリソース管理は、より困難になります。今までの経験を活かしながら、プロジェクトを成功させるためにチームで協力しました。
既存のソースコードを使用して開発を進めるには多くの問題があったため、プロジェクトのフォルダ構造からソースコードまで、すべてのリファクタリングを行うことにしました。リファクタリングには多くの時間を費やす必要がありましたが、同時に、App Storeの仕様に合わせて古いロジックをアップデートしなくてはなりませんでした。合理的に時間を使って、品質保証のプロセスを踏みながらリファクタリングを行いつつ、既存のロジックをアップデートしてスケジュールにコミットするというのは大きなチャレンジでした。
また、仕様以外についても、確認する必要のある点がいくつもありました。例えばデザインです。私たちは問題の解決策を積極的にクライアントに提案し、同意していただくことができました。プロジェクトマネージャーやリーダーだけでなく、メンバーからも自信をもってソリューションを提案することができました。このプロジェクトには、確認しなければならない問題が数多くありましたが、私たちの質問に対してクライアントがいつも迅速に回答してくれたので、円滑にプロジェクトを進めることができました。チームメンバーは、仕事終わりにいつも一緒にビールを飲んでいて、それもチームワークの向上につながりました。
変化に素早く対応できる柔軟性があった
Vu Van Hanh -iOS Engineer
私はタスクマネジメントツールとしてTrelloを使用していましたが、今回のプロジェクトでは実際にJootoを使って日々の作業を管理しました。自分が開発に携わったプロダクトが使われることは、自分が書いたコードが価値を生み出すことにもつながり、モチベーションが非常に高まりました。
このプロジェクトを進める上で最も困難に感じたのは、モバイル側の仕様が十分でないということでした。もともとSun*で開発されたものではなかったため、仕様やソースコードのすべてをSun*のメンバーが認識できてはいませんでした。社内で明確にできないことは、積極的にクライアントに聞くようにしていましたが、いつも正確な回答をしてくれました。プロジェクトが進むにつれてチームのサイズが大きくなると、ワークフローをスムーズにする方法が課題になってきます。
当初は、チーム内でもメンバーによって仕様の理解度に差がありました。新しいメンバーはプロジェクトの内容、設計と仕様について熟知し、学ぶ時間が必要です。そこで私たちはタスクを並べ替え、スプリントに従って作業量を分けました。これによって、メンバーは積極的にチケットを処理しながら、内部チームやクライアントと活発なコミュニケーションを行うことができました。モーニング・ミーティングやスプリント・ミーティング（MOM＆Retro）は、仕様やデザインの変化にすばやく対処する手段として非常に有効です。それだけでなく、チームメンバー間のコミュニケーションの時間も増やしてくれます。
