課題の起票漏れを40%削減！テモナとフランジアがオフショア開発でBacklogを選ぶ理由

テモナ株式会社はFramgia Inc.とのベトナムでのオフショア開発にBacklogを利用しています。分散開発で起こりがちなコミュニケーションロスをBacklogで未然に防ぎ、ベトナムと日本でのスクラム開発を成功させる秘訣について、テモナ取締役の中野賀通さんとFramgiaの木嵜雅也さんにお話しをお伺いしました。

※Frangia Inc.は、2019年3月3日に株式会社Sun Asteriskに社名変更しました。

―――貴社の事業概要について教えてください。

テモナ株式会社 取締役 COO 兼 CTO 中野賀通（なかの のりゆき）氏：テモナ株式会社は「ビジネスと暮らしをてもなく(簡単に)する」という理念のもと、EC事業者向けに、サブスクリプションビジネスに特化して事業を展開しています。メインサービスの「たまごリピート」は、フロントの受注から、バックエンドの出荷・販促機能、分析まで、ネットショップのリピーターを増やすための機能を包括的に備えた通販システムです。また、訪問客の購入率を向上させるための販促ツール「ヒキアゲール」も提供しています。

―――Backlogはどういった目的で使われていますか？

中野：主にたまごリピートとヒキアゲールのオフショア開発の工程管理にBacklogを利用しています。ベトナムでのオフショア開発により、日本側とベトナム側で共同で利用できるプロジェクト・タスク管理ツールが必要でした。オフショア開発は、フランジアを介して進めています。

―――Framgia（以下、フランジア）社について教えていただけますか？

Framgia Inc. マーケティングディレクター 木嵜雅也（きさき まさや）氏：フランジアは、オフショアでのソフトウェア開発事業を中心にスタートアップへの投資・アクセラレータープログラム、教育事業などの事業を展開しています。ソフトウェア開発事業は、チーム提案型と、プロダクト提案型の2種類の形態があります。

 

Backlog の特長をまとめたご提案資料はこちら

 

「良いサービスを素早くつくる」テモナがベトナムに開発基盤を置いてスクラム開発を進める理由

―――テモナ社とフランジア社では、どのように仕事の役割を分担していますか？

中野：弊社はフランジアのラボ型開発の手法を取っています。チームは、テモナ側は17人、フランジア側は11人の合計28人のエンジニアで編成しています。特にたまごリピートに力を入れており、20人を4チームに分けてスクラム開発をしています。

業務設計、要件定義、運用保守は日本のテモナ側の2チームで進めて、開発と単体テストはフランジア側のベトナム人エンジニアと、テモナ側のブリッジエンジニアの2チームで共同で進めています。日本とベトナムでチームを半分にすることで、パワーバランスを調整しています。また、この人数だとプロジェクトへの思い入れや熱量をメンバーにしっかりと伝えられています。

―――自社に開発基盤を持ちながら、敢えてオフショアでサービス開発をしているのはなぜでしょうか。

中野：私は自社開発とオフショア開発を分断して考えていません。重要なのは、開発手法ではなく、自分たちが掲げるビジョンやプロダクトに向かってどれだけ素早く近づけることですから。より早く、良いプロダクトをつくるにはどうすべきかを考えた結果、オフショア開発が最善策だったので選びました。

2015年からフランジアと協力しながらオフショア開発をしていますが、ベトナムのラボ開発メンバーはとても優秀だと感じます。同社の教育の質が良いのもあると思いますが、オフショア開発のメンバーは日本の商習慣に理解があるメンバーが多いですね。

―――日本とベトナムという分散開発で、どのように連携してプロジェクトを進めていますか？

中野：ベトナムにスクラムマスターとブリッジエンジニアを置いています。ベトナム側のプロジェクトの全体のマネジメントはスクラムマスターが担当しています。プロジェクトに紐づくBacklogの細かい課題の起票や管理はベトナム側のブリッジエンジニアと日本側の各チームリーダーが担当しています。

―――スクラム開発をされているとのお話しですが、課題はどのような基準で起票したり、粒度をコントロールしていますか？

中野：弊社はRailsがメインのフレームワークを活用しているため、どこのアプリケーションのレイヤーがどのくらい開発の後工程に影響を及ぼすのかを見定める必要があります。

いわゆるRailsはMVCモデルと呼ばれるモデルビューコントローラーという三層構想が基本なのですが「モデル」と呼ばれるデータベースの定義やビジネスの根幹をデータベース上にどう表現するのかという点が一番重要です。なので、ここを最初の課題としています。より具体的に解説すると、ビジネスのロジックをデータベースで表現する段階でメソッドの取捨選択をして、その方法をレビューするときに初めて課題を作っています。

ワークフローの切り分け方としては、データベース、業務的に大きいロジック、詳細ロジック、最後のテスト、という粒度に分けています。

―――だいたいどれくらいの期間で課題を完了させることが多いですか？

中野：弊社のスクラム開発では、スプリントを1週間で切って、イテレーションを1ヶ月にしています。大きいイベントスクラムは3ヶ月スプリントで管理しています。チーム単位でおさまるように課題の粒度を変えていて、1日の作業で一番大きくても3時間で収まるような粒度で課題を立てています。

 

Backlog の特長をまとめたご提案資料はこちら

 

課題の起票漏れを40%削減。エンジニアとビジネスチームの間で起きていたコミュニケーションロスを改善

―――Backlogを導入してどれくらい経ちますか？

中野：Backlogは社内のプロジェクト管理ツールとしてフランジアと共同で利用する前から使っていました。フランジアとのオフショア開発に利用するようになったのは2015年4月からです。Backlogを導入する前はRedmineなどのツールを使っていました。

―――RedmineからBacklogに移行した経緯について教えてください。

中野：チームや部署で異なっていた運用ルールを統合して、マネジメントの手法やAPIの監視も1つにまとめたいという案が社内からあがったことがきっかけでした。Redmineを全社に広めることも検討しましたが、ビジネス職のメンバーから使いづらいという声があがったんです。そこで、プロジェクトメンバー全員が気軽に使えるものと線引きした結果、Backlogを導入することになりました。

結果的に、プロジェクトメンバーの誰がみても、プロジェクトの進捗をすぐに把握できて、問題の所在をすぐに見つけられるような、透明性の高い情報共有をBacklogでは実現できるようになりましたね。

―――Redmineを使っていたときの情報共有とBacklogでの情報共有はどのような変化がありましたか？

中野：Redmineを使っていたときは、プロジェクトや個人のタスクの進捗データをCSV出力していました。しかし、起票漏れが多くメンバー全員の動きが正確に把握できるような信憑性の高いデータではなかったんです。Backlogは操作がしやすいので、移行後はメンバー全員が難なく課題を起票できるようになりました。

メンバーがタスクの進捗状況を必ずBacklogに記録するようになったので、マネージャーはメンバーの動きや対応しなければならない課題の数を把握できるようになりました。オフショア開発など現地の作業状況が見えにくい状況でも、フォローがしやすくなり、コミュニケーションロスも減りましたね。

―――コミュニケーションロスは具体的にどのような部分で起きていましたか？

中野：よく起きていたのが、ビジネス職のメンバーから「エンジニアの作業がまったく見えない、今は何をしているの？」という声があがってくることでした。こうした問題は、エンジニアの課題の起票漏れが原因だったり、個人の作業の進捗共有の透明化ができていなかったことが理由で起きていました。

Backlogに移行してからは、Backlogのデータをみればエンジニアがいまどんな作業をしているのか、すぐに確認できるので、相互の不信感が生まれるの防げるようになりました。数値に換算すると、エンジニア全体の課題の起票漏れがBacklog導入前と比較すると約40%改善されましたね。

―――Backlogを見ればメンバーの作業状況が一目瞭然なんですね。

中野：はい。Backlog単体でも個人の作業状況を可視化できますが、より個人の動きと生産性を可視化してコミュニケーションを円滑にするように、Backlogと外部サービスを連携しています。

Backlogを外部サービスと連携しているのは、プロジェクトの進捗を阻害する要因の顕在化と個人の生産性の可視化です。停留している課題はチャットワークとの連携で表面化するようにしています。

 

Backlog の特長をまとめたご提案資料はこちら

 

Backlogと外部サービスと連携！マネージャーが停滞している課題に即座に気づける仕組みをつくる

―――チャットワークを用いた停滞課題の表面化とはどういうことでしょうか？

中野：弊社はコミュニケーションツールにチャットワークを利用しています。調査依頼や開発タスクなどの、Backlog課題をチャットワークbotが回収して、処理中で滞っている課題や進行中の課題の更新状況をチャットワークに通知するという仕組みをとっています。

チャットワークに通知することで、課題の作成者や担当者が誰になっているのか、どれくらいの期間課題が残っているのか、1人に課題が集中していないかチェックするきっかけになります。当日対応しなければならない課題が未対応になっている理由やずっと処理中になっている理由など、プロジェクトマネージャーが課題状況を踏まえて、メンバーにヒアリングをして環境を整えることも迅速にできます。

―――メンバー個々人のタスク状況を可視化しているのですね。一方で個人の生産性とタスク量はどのように判断されているのでしょうか？

中野：Backlogに記録した見積もりと実績にもとづいて、個人に求める仕事量を決定しています。例えば「調査をしてこれくらいのレベルの仕事だったら、xx時間くらいで完成するよね」という具合で工数を見積もります。仕事量に関しては給与から逆算して、時間給で言うとこの課題はこれくらいで完成しないといけない、という指標をポイントに換算して決定しています。このポイントが個人の生産性の指標になっていますね。

―――Backlogの見積もりと実績を活用して、個人の生産性を測定できるような仕組みづくりを作られているんですね。

中野：そうですね。基本的に弊社のメンバーの作業はすべてBacklogに起票しています。人事の査定もBacklogを基準に決定するため、Backlogへの起票漏れは昇進に響くような仕組みになっています。さらに、作業の進捗はBacklogにすべて記録されているので、プロジェクトメンバーから予算や人員を追加する要求があったときに、マネージャーは記録をみて、すぐに判断できます。

―――素晴らしい徹底ぶりですね！ちなみに、他にBacklogと連携しているサービスはありますか？

中野：GitHubにBacklog専用のリポジトリを作って、GitHubのコミットとBacklogの課題を紐づけて管理しています。GitHubにはコーディングなどの粒度の細かい作業を記録して、作業の結果や成果物など粒度の大きいものをBacklogで管理する、というように分けています。GitHubのコミットのタイトルがBacklogの課題名になっているので、「https://社名.backlog.jp/view/」以下にBacklogの課題キーを入れるとBacklogの課題にすぐにアクセスできるようになっています。

 

Backlog の特長をまとめたご提案資料はこちら

 

多数のメンバーが関わる オフショア開発 では「操作が簡単であること」「記録が明確であること」が重要

―――オフショア開発に話を戻します。オフショア開発を成功させるには円滑なコミュニケーションが鍵だと思いますが、Backlogはどのような役割を果たしていますか？

中野：Backlogの作業の”歴史”が残るという点が、現地のエンジニアと日本側の要件定義を進めるメンバーとの間のコミュニケーションロスを圧倒的に削減していると感じます。プロジェクトを立ち上げた経緯やどこでつまずいたのか、過去の遺産として参考にできますからね。

木嵜：予期しなかった部分で便利！と感じたのは、アイコンです。ベトナムは同姓同名のひとが多いので、アイコンをみることですぐに誰かを判断できるのが便利な点だと感じています。

―――現地のエンジニアと円滑にプロジェクトを進めるために、Backlogの運用面で気をつけていることはありますか？

中野：大きく2つあります。1つは、BacklogやGitHubなどのツールで管理するコードを1つにすることです。2つめに、課題の起票ルールを統一するためにWikiに書き方をまとめたり、テンプレートを作成したりしています。

木嵜：フランジアでもテンプレートを重視する声をよく聞きますね。テンプレート化することで無駄な表現を削除することができるので、現地のエンジニアなどの書き手に左右されない情報共有が実現できます。

―――オフショア開発を成功させるために中野さんが工夫していることはありますか？

中野：正直これまであまり困ったことがなくて......（笑）。強いて言うなら、オフショア開発のメンバーでもテモナの社員として接することですかね。引っかかることが少しでもあったら、本人に直接伝えて理解してもらうようにしています。もちろん、そうした信頼関係を築くために、日本のお土産を持ってベトナムのラボに訪問することもあります。ベトナム語を使って会話をすることも。オフショア開発といっても、人と人が協力して仕事を進めることに変わりないので、1人1人としっかり向き合うようにしています。

―――Backlogをオフショア開発の現場への導入を検討している方にどんなメッセージを送りたいですか？

中野：Backlogは誰でも気軽に操作できて、使い方次第で個人の作業状況を細部まで把握できることが大きな特長です。オフショア開発はコミュニケーションロスをいかに減らすかが重要なので、オフショア開発先とのコミュニケーションの取り方に問題を感じているチームは一度試してみてはいかがでしょうか？

木嵜：開発の現場だけでく、テモナ社のように、社内全体の業務改善でもBacklogは使えるので、広範囲で使えるタスク管理ツールを探している方におすすめしたいですね。

—— ありがとうございました！

■ オフショア開発でのBacklog活用事例はこちら

・オフショア開発成功の秘訣！エボラブルアジアがBacklogで実現するベトナムとのプロジェクト管理

・中古車買取販売ガリバーを運営するIDOM社の Cacoo と Backlog 活用事例--分散拠点のコミュニケーションロスを削減

※掲載内容は取材当時のものです。