こんにちは。レシピ事業開発部クロスファンクショナルグループの @kaa です。

クックパッドAndroidアプリは昨年秋にフルリニューアルを実施しました。リニューアル内容としては半年ほど先にiosでリニューアルを実施したものを導入になります。弊社はこのリニューアルプロジェクト開始の2ヶ月ほど前からリモート主体の勤務体制になっており、期間中は週1で出社という状況でした。まだリモート勤務にもみんなが慣れているとは言えないタイミングでの実施となりました。

このプロジェクトのため3ヶ月程度の期間、部署横断でメンバーを集め進めました。体制は以下の通り。

アプリエンジニア6名(1名はAPI兼任)＋決済・基盤・テストのサポートに2名
デザイナー2名(デザインディレクション＋1名)
ディレクター3名(PdM,PjM,開発ディレクション)

このプロジェクトについて、開発ディレクションの立場から楽しくやるために行っていたことをお話します。

モチベーションに関する課題

評価に対する不安

部署横断プロジェクトにありがちな課題ですが、メンバー本人の年初にたてた個人目標・チーム目標とは直接関係がない仕事をすることになります。自分の仕事に対して評価が行われるのかわからない、最終評価者は詳しく見ていない、さらには自分がやりたいと考えていた今年の仕事とは異なる可能性もある。

この課題の対応のため、開発進行をしている人(自分ですが)が期末の追加の評価者として開発メンバー全員の評価にディレクションの立場から参加するということを事前に決めました。

主体性を持ってもらうための仕組み

人がパフォーマンスを出す条件として、次の3点を考えています。

やりたい仕事であること
裁量があること
仕事に集中できること

やりたい仕事であること

初耳の、3ヶ月拘束される本来の仕事と違うプロジェクトでいきなりパフォーマンスが出せる人はまずいません。さらに今回は別プラットフォームでリリース済みのことを実装なので新規性もありません。どうやって自分のやりたい仕事だと思ってもらうかが必要になります。

まず、参加する開発メンバーにいまのアプリ開発で改善したい点をだしてもらいました。

参考：大規模プロジェクトにおけるモバイル基盤の取り組み

長く運用しているアプリですので棚卸ししたい負債や制定したい実装ルールは溜まっています。 minSdkVersionあげたい、マルチモジュール化すすめたい、遷移ルールの統一、スタイルの再定義などなど。やりたいけど実施タイミングがとりにくいものはたくさんです。これらの話題を事前に時間とって話し合い、共通の理想とする実装方法・改善をまとめます。今回は普段は基盤チーム(弊社ではサービス開発と開発基盤は部署として分かれています)に所属しているメンバーも多く参加しておりプロジェクトの事前準備の段階から関わっていました。

そしてこれらを実現できるプロジェクトとして進めました。他の部の仕事にお手伝い参加ではなくいま自分達の考える理想のアプリ開発に近づける仕事にしていきます。

裁量があること

各メンバーに対して、任せたタスクについてはほぼ一任しました。仕様は事前に細かく詰める、でも仕様の実現方法については任せきります。条件はコードレビューが通ること。 (クックパッドではPRのマージには一人以上のapprovedが必要です)

これだけでは実装方法にばらつきが発生しそうですが、事前に実装方法についての方針を開発陣で話し合って方針を決めているため、そこから外れることはありません。自分達の考えたルールに縛られるのはつらいことではなく自分達の理想を実行している状態ですので、やりたいようにやりつつ統一された実装方法で進めている、という状態になります。

また、仕様の実現が難しい場合はいつでも相談が可能としました。実装して触ってみないとわからない問題はどうしても起きるものですしその画面について一番時間を使っているのは実装者本人なので気付ける改善も必ずあります。

ただし、相談には本人のどうしたらいいと思うかをあわせて伝える、というルールです。どうすればよくなるか考えるきっかけにもなり、同時に仕様策定者に対する別の視点の提供になります。実際ほとんどの場合は開発者の意見をそのまま採用しました。 NGの場合は明確な理由があるものなので説明します。サービスの方向性の目線合わせもかねて。

集中できること

基本的に、人は考える必要のあることが少ない状態にあるほどパフォーマンスが上がると考えています。考えてもすぐに結論のでないことはいくらでもありますし、違う話を理解するのも脳と時間のコストがかなり持っていかれます。スイッチングコストは本当にたいへん。

今回は2週間単位にフェーズを切り、タスクは画面単位に分けました。その期間中、または完了するまでの間、他の人のコードレビュー以外で担当画面以外のことを考える必要がない状態を目指しています。

タスク単位を判りやすくしたのは、実装者の成果をわかりやすくする意味合いもあります。〜〜をやりました、とわかりやすく言えると評価に限らず仕事の実感としても感じやすいことを狙っています。画面単位の実装段階は2つにわけ、機能実装と最終デザイン反映を別にしました。これは複数人でフェーズ単位の進め方をすると各実装のデザイン確認の時期がフェーズ終盤に集中し実装者に待ちが発生するのを避けるためです。機能実装が完了した段階ではデザイナーのチェックをなくし(スタイルは反映されているため大きく破綻はしません)、エンジニアは次のタスクに移ることが可能になります。

弊社では通常時はUI変更がある場合にデザイナー確認なしでのPRのマージは禁止ですがこのプロジェクト中は例外としました。

リモートにまつわる課題

リモートではただでさえ距離感が難しくなりますが、今回はそもそも所属している部も異なるメンバーが集まっています。エンジニア同士であればリポジトリ上、slack上でのやりとりはしていたとはいえ、職種が変わるとこれまであまり関わりがない人もいます。実際に開発ディレクションの自分とほとんど話したことのない開発メンバーもいました。

レスポンスを確約する

質問したいことがあった際にすぐ反応がもらえるか、も重要ですが今回は質問に対していつ答えを出すかを事前に決めました。その日のうちに質問しておけば、翌日の昼会で決定した内容を伝えます。昼会で話題にする、相談するでなく決定状態にする、です。持ち越しダメゼッタイ。ディレクションのメンバーもきっちり仕事していると見せないといけません。すぐに反応するとか相談できるではなく確定させるタイミングをルール化します。いつ決定した仕様がわかるのかが事前にわかっていれば実装の段取りもたてやすくなります。どんなことでも知りたいことは翌日には確定したものがわかる、という状況を作ります。もちろん即答できるものは即答です。

情報の公開

実装に集中すればするほど、slack追ってらんないし関係ないかもしれないzoom色々はいっていられない。しかしいまプロジェクトでなにが話題になっているか知りたい時に知れる状態を目指します。これが所属している部での仕事であればミーティングのルール整備といったことになりますがこれは3ヶ月の短期プロジェクトですので整備している暇はありません。

ではどうするか。ほとんどすべてのミーティングに参加している人が1人はいますよね、その人が全部やりましょう。今回の場合自分です。大丈夫数ヶ月の短期プロジェクトならこれでなんとかなる。意地で議事録取り続ける、ミーティング終わったら整理してslackで共有。すべてを明文化です。

楽しくやる

いいものができてきていると言い続ける

リモートによらないことでもありますが、リモート主体であるからこそいま自分達がいいものを作っているという実感を得ながらやっていきたいものです。チームの皆が頑張っている様子を可視化します。

基本姿勢はホメ＆ポジティブです。なにかできていたらこれすげーいいじゃんとかばっかり言ってました。ディレクションとしては内心スケジュール間に合うかとか考慮もれがないかとか不安が色々と発生し続けてますが、それらはあくまで自分の責任であって、それをうまくやるのが仕事なので特に周りに伝える必要はありません、不安なとこ見せない。

メンバーにこのプロジェクトうまくいくか不安なんて伝えても集中できなくなるだけですし、不安は伝搬してしまうし自分の多少のストレス軽減になるだけでなにもいい効果を生んでくれません。であればぶっちゃけるタイミング以外では不安を周囲に伝える必要はありません。

裏目標を作る

最後に、自分自身のモチベーションの話。以前に別プラットフォームで行ったリニューアルの導入プロジェクト、どうしても単なる移植になりがちでモチベーションの確立が難しい部分があります。このプラットフォームにあわせたUIを設計し、仕様に落とし込むのですがその際、先にリリースした時よりもさらに考えることは難しい。OSにあわせて自然に、という意識がどうしても働きます。要は無難なことをしがち。

なので意識的にプラットフォームごとにUIを変更する部分において、いくつかの指標について先にリリースしたものの数字を超えることを目標としました、個人的に。とはいっても特殊なことをするのはダメですし以前のプラットフォーム(今回でいうとiOS)のものをそのまま導入するよりandroidにマッチしたUIである必要があります。プラットフォームへの最適化と数値目標の両立を目指します。導入するのはリニューアルの体験・コンセプトであって焼き直しや単なるOS最適化ではありません。

これにより画面仕様策定の楽しさが格段に上がります。別プラットフォームですでにリリースしたアプリとそのアプリでの数字は既に知っています。これから作るプラットフォームでのアプリでは先にリリースした時よりも理解が進んでいてもっといいものができますよね？