6名のエンジニア全員が「なんでもやる」アプリ開発体制

僕は2011年にPerlエンジニアとして入社し、既存サービスの改善や、SNS「mixi」の新規サービスの立ち上げに携わってきました。

なので、元々はアプリエンジニアではなかったのですが、そういったエンジニア向けに開催されたネイティブアプリ開発の研修をきっかけに、一時期アプリを大量に作っていました。

そして、当時企画中だった「家族アルバム みてね（以下、みてね）」のアプリ開発を一緒にやらないか、とプロダクトオーナーの笠原に声をかけてもらい、2014年にiOSエンジニアとしてジョインしました。

現在は、25名からなる「みてね事業部」で、開発グループのマネージャーを務めています。

みてねは、スマホで撮った子どもの写真や動画を、家族で簡単に共有できるアプリです。「世界中の家族の心のインフラを作る」という想いからサービスを立ち上げ、2015年にリリースしました。

開発体制としては、インフラを専門とするSREチームと、アプリ開発チームの2つに分かれているのですが、後者に関しては、6名のエンジニア全員が「フルスタック」での開発を行っています。

というのも、最初の頃は、iOS・Android・サーバーサイドでそれぞれ役割を分けていたのですが、それだと重要な設計や仕様の面で、自分の携わっている範囲しか判断ができなかったんですね。

また、他のプラットフォームのタスクが「クリティカルパス」になってしまうこともあり、どうしても開発のスピード感が落ちてしまっていました。

そこである時、「試しに自分の専門領域ではないコードを書いてみる」という取り組みをしたんです。

その中で、アプリエンジニアがサーバーサイドのDBやAPIの設計・実装まで行ってみたところ、クライアントアプリ側で「本当に使いやすいもの」を、最小限のコストで開発できるということを実感しまして。

この経験を通じて、ある程度の規模感であれば、フルスタックの方がサービスの目指す世界観を最速で実現していくことができると考え、「全員がなんでも対応する」体制に移行しました。

プラットフォームを選ばない。全員が優先度の高いタスクから着手

開発は、スクラムの手法を取り入れています。まず、新しい機能開発を行う際には、プロジェクト管理ツールの「Pivotal Tracker」を使い、プロダクト・バックログを作成します。

そして、実際の作業計画を示すスプリント・バックログには、タスク管理ツールの「Trello」を活用しています。

具体的には、Trelloのボード上に、優先度の高いバックログを左から順にリストとして並べます。そのリスト上に、それぞれのバックログに紐づくタスクを、カードにして優先順位の高いものから並べていきます。

また、各タスクのステータス管理は、カードの移動ではなく、スタンプ機能を利用して「着手済み」「レビュー中」「完了」といった形で表しています。

▼Trelloで管理しているスプリント・バックログ（実際の開発内容とは異なります）

毎日の朝会で完了したタスクカードを消していき、バックログの完了に必要なタスクをすべて消化すると、ボード上のカードもリストもなくなる、といった形です。

ここでは、開発対象のプラットフォームに関わらず、基本的に手の空いた人がその時に最も優先度の高いタスクに取り組むようにしています。そのため、誰がどのタスクをやるのかは、自動的に決まるんです。

もちろん、フルスタックとはいえ、エンジニアによってiOSやAndroidなどの得意分野は異なります。

ですが、スプリントを回すごとにチームとして成熟していくことが大切だと考えているので、個人の得意・不得意に依らず、まずは取り組んでみるようにしています。

一方で、かける工数については、プロダクトバックログを作る段階でストーリーポイントを見積もることで、予めそれぞれの難易度を可視化しています。

このポイントは、チームのこれまでの経験値を加味した上で、大まかな開発の難易度を、バックログごとに相対的な点数で見積もるようにしています。

例えば、「コメント投稿機能の追加」であれば5ポイント、「海外からのアルバム閲覧のレスポンスタイムを、国内と同等にする」といったより低レイヤーな知識を必要とする開発であれば13ポイント、といった形です。

こうすることで、非エンジニアからみても開発の難易度が明確になりますし、プロダクトオーナー側からも開発の優先度や納期などの判断がしやすくなります。

すると、効率的に納得感をもって開発することができるため、お客様への新機能や改善のデリバリも、より早く実行することができるようになりますね。

教育はせず、ペアプログラミングを通して「現場で覚える」

一方で、この開発体制を維持する上で難しいのが、最適なエンジニアの「採用」です。

というのも、僕たちのようにフルスタックでの開発経験を持つエンジニアって、社内外ともになかなか見つからなくて。

そのため、採用時には特定領域の経験しか持っていない場合も多く、そうするとチームにジョインしてから自分の専門外の技術を覚えていく必要があります。

そしてその技術は、基本的にはペアプログラミングを通じて、どう実装しているかを自分の目で見て学ぶようにしています。

そこで、知見の多い人を「ナビゲーター」、学習したい人を「ドライバー」という役割でペアを組み、ルールは指定せずに、それぞれのペアのやり方でプログラミングを行っています。

例えば、ナビゲーターが1つずつ指示を出しながらコーディングする場合もあれば、ナビゲーターが一旦全て実装したコードに対して、テストコードを書きながら修正し、その内容を理解していく、といった場合もあります。

特別な教育体制をもっているわけではなく、僕としては「現場で覚える」ことを大切にしているので、ヘルプが必要なタスクが訪れた時に得意な人に聞いたり、ペアプロをしてもらえればと思っています。

また、最近ではiOS・Androidの両方に通ずるアーキテクチャを導入し、それを共通言語として異なるプラットフォームでの実装をレクチャーする、といった取り組みも始めました。

このアーキテクチャは、iOSとAndroidのプラットフォーム間の差異をできる限り吸収するように考慮して設計されているので、お互いに理解がしやすく、以前より実装がスムーズになりました。

それに加えて、技術共有のための社内勉強会は、みんな自主的に行っていますね。

会社のコラボスペースを利用して、僕がランチタイムにiOS勉強会を開いたり、Androidを得意とするエンジニアが自分の専門領域の勉強会を開いたりして、日頃から活発に共有しています。

レビュー会を実施し、社内ユーザーの声を機能に反映

社員同士の交流は、エンジニアだけでなく、事業部全体でも行っています。

例えば、機能がある程度できあがった段階で、正式リリースする前に必ず「社内レビュー会」を実施しています。

というのも、アジャイルの考え方である「すばやく世に出して、それに対してのフィードバックを分析し、改善する」ということを基本としていても、やはり最初の印象ってとても大切だと思うんですよね。

なので、「最初のクオリティ」を高めるために、エンジニアやデザイナーだけでなく、カスタマーサポートなど事業部メンバー全員に集まってもらい、実際にアプリを触ってもらうんです。

その中には、実際にユーザーである人もいるので、ターゲットに対してきちんとアピールできる機能になっているか？　を判断する貴重なフィードバックの機会になっています。

実際、みんなに使ってもらうと、本当にたくさんの指摘事項が出てきますね。

そこで出てきた意見や要望は、その場で「機能に反映するか、しないか」をひとつずつ決めていきます。

そして、反映するとなった場合には、実装にかかりそうな工数もその場で見積もっていくので、実際に反映するものからリリースかかる期間まで、事業部全体にある程度見えるような形になっています。

今の機能は、ほぼすべてこのレビュー会で出た意見が反映されている、と言っても過言ではないのですが、例えば「表紙機能」なんかも、レビュー会で出た意見を参考にブラッシュアップしました。

これは、月ごとのページをスワイプするごとに、最も大きく表示される写真がランダムに変わる機能なのですが、これも初めはランダム表示ではなかったんです。

▼画面をスワイプすると、同月のトップ写真が変わる「表紙機能」

このレビュー会をすると、事業部としても一体感が生まれますし、直接的にフィードバックをもらえることでエンジニアのモチベーションが上がるので、開発における重要なステップになっていますね。

チーム意識と、日頃のコミュニケーションが全てのベースに

こうして、サービス改善を繰り返していった結果、「みてね」はサービス開始から約3年で、250万人以上が利用するアプリへと成長しています。

この拡大に伴い、負荷対策などのインフラ周りも強化する必要がでてきたので、今年からは専門性の高い経験豊富なインフラエンジニアにも、チームにジョインしてもらいました。

一方で、今後、海外展開も進めていく中で今のスピード感のある開発体制を維持していくためには、やはりアプリ開発においては「全員が何でもやる」体制が必要だと考えています。

そこで重要なのは、結局のところ、メンバー1人ひとりの意識や日頃のコミュニケーションなんですよね。

僕は基本的に、細かいマネジメントはしない方がいいと思っていて。

例えばバグなどが発生した時に、専門領域が決まっていないので、「誰が対応するか」「今やっているタスクとどちらを優先すべきか」といった判断の部分が難しいんですよね。

そうした場面では、常にチームでコミュニケーションを取りながら、お客様にとって最適な行動を考えて進めていく必要があります。

「全ての課題は、個人ではなくチームの問題」という前提のもと、それを解決するのが個人だという意識作りを常に行っていますね。

そして、開発する案件の目的をきちんと共有した上で、その案件に対する共感度や、本人の志向と合っているか、といった部分は意識して擦り合わせるようにしています。

今後、サービスが拡大してチームのメンバーが増えていっても、今と変わらないようなスピード感でサービスを良くしていけるように、開発チームの体制を強化していきたいですね。（了）