株式会社つみき
プロダクトマネージャー
野田 直軌
高専・大学で情報系を専攻し、iOSエンジニアとしてキャリアをスタート。2014年につみきに入社し、Filmarks（フィルマークス）のiOSアプリ開発を担当。その後、開発全体のリーダーを経て、現在はエンジニアリングマネージャーおよびプロダクトマネージャーとして組織運営にも携わっている。
映画・ドラマ・アニメのレビューサービス「Filmarks（フィルマークス）」の運営会社であるつみき社は、UI/UXに強みを持つデザインファームとして創業し、いまや総レビュー数2億件を超える大規模サービスを開発・運営する企業へと進化しています。
今回お話を伺ったのは、同社でプロダクトマネージャーを務める野田さん。インタビューでは、プロダクトのフェーズに応じて柔軟に形を変えてきた開発組織の変遷、マネジメントの思想、そして文化として根づいている「UI/UXへのこだわり」や「リファクタを重視する姿勢」など、現場視点の深い知見を伺いました。
映画レビューサービス「Filmarks」の誕生と成長
まずは、つみき社の事業概要について教えてください。
つみきはもともと、UI/UXデザインの受託事業からスタートした会社です。2012年に自社サービスとして立ち上げたのがFilmarksです。当時、代表の鈴木がTSUTAYAでレンタル作品を選ぶ際、「観たい映画を管理できるツールがあれば便利なのに」と感じたことがきっかけでした。
Filmarksは現在どのように成長してきたのでしょうか？
最初は映画のレビューサービスとして始まりましたが、2017年にドラマ、2020年にはアニメへと対象ジャンルを広げ、現在はその3ジャンルを網羅しています。ユーザーの集客については、SNSや口コミによる自然流入がメインです。コロナ禍では、特に映画・ドラマの視聴機会が増えたことが後押しとなり、現在ではレビュー数2億件を超えるサービスにまで成長しました。
開発規模は約20名。プロダクトのフェーズに合わせて柔軟に変化
入社された当初の開発体制は、どのような状況だったのでしょうか？
私が入社した2014年当時は、アプリエンジニアが私を含めて2名。他のエンジニアは別業務と兼務していて、実質3〜4名の体制でした。そこからプロダクトの成長とともに、徐々に組織が大きくなっていきました。
現在の開発組織の体制について教えてください。
開発組織全体では約20名で、内訳はサーバーサイドエンジニアが11名、インフラエンジニアが4名、iOS/Androidアプリエンジニアが4名、データエンジニアが2名。加えてデザイナーが3名、ライターが1名います。エンジニアのうち正社員は8名、あとは業務委託の方に協力いただいています。
これまでどのように組織を拡大してきましたか？
新卒を毎年採用するような拡大方針ではなく、必要に応じて採用を行ってきました。たとえば過去には、PHPで書かれたシステムをRailsにフルリプレースしたタイミングでサーバーサイド採用を強化しました。最近ではサービスの複雑性に対応するため、再び体制を見直し、増員を行いました。
人数が増えることで、組織に変化はありましたか？
人数が増えて担当領域の分業化が進む中で、チームごとに設計の方針やコードのスタイルにブレが生まれるようになりました。そういった分断を防ぐために、定例の振り返りを継続したり、横断的なテーマでの情報共有を行ったりと、意識的に「つながり」を保つようにしています。人数が少なかった頃は暗黙知でできていたことも、規模が大きくなると仕組みとして維持する必要が出てきたと感じています。
依頼は“一本化”。フラットな関係を保ちつつ、混乱を防ぐ仕組み作り
マネジメントの基本方針はどのようなものですか？
指示系統はできる限り一本化しています。私がユニット全体のマネージャーとして情報を受け取り、必要であればテックリードを通じてメンバーに展開するスタイルです。これにより、依頼元がバラバラになってメンバーが混乱することを防いでいます。
各チームリーダーにはどの程度裁量を委ねているのでしょうか？
現在は、アプリチームを中心に裁量を移譲しはじめています。リーダーが自ら判断して動ける範囲を明確にしておくことで、私が介在しなくても意思決定できる体制を少しずつ整えているところです。
今後さらに組織が拡大する場合の構想はありますか？
プロジェクトごとにマネジメントする体制を検討していますが、一人のエンジニアが複数のプロジェクトに参画して指示系統が増えることで、混乱してしまう事態は避けたいと考えています。そのため、聞くべき相手を明確に一本にする運営方針は維持していくつもりです。
組織運営にあたって、意識されている理論や考え方はありますか？
人の脳の仕組みや行動心理学に関する本を読むのが好きで、「予想通りに不合理」や「エンジニアリング組織論への招待」といった書籍を読んでいます。そこで得た知見が、結果的にマネジメントにも活きていると感じています。
たとえば、「人はマルチタスクが苦手」「指示が多すぎると認知的な処理が追いつかない」といった脳科学的な前提に立つことで、日々のチーム設計にも自然と意識が向きます。これは特に、開発現場での文脈の切り替えや注意の分散に大きく関わる要素で、人の注意が“今どこに向いているか”を尊重した仕組みづくりは、生産性だけでなく満足感にも直結すると感じています。
また、「確証バイアス」のような認知バイアスについても意識しています。自分の信じたい仮説に都合のよい情報だけを集めてしまう傾向があるため、あえて逆の意見を考えたり、時には自分で発言したりして、バイアスに陥らないよう心がけています。
私はもともと感覚的に動くタイプではないので、こうした知見に意識的に触れながら、論理的かつ客観的に組織やチームの状態を捉えるようにしています。単なる精神論ではなく、人間の認知特性を理解したうえでマネジメントを設計していくことが、結果的に心理的安全性の向上にもつながると考えています。
「リファクタ日」や集中時間の確保。プロダクトと人を守る開発文化
開発チームに根付いている文化について教えてください。
つみきは、最適なUI/UXは何かを考え抜く文化が強く、アプリを利用する際の「わかりやすさ/気持ちよさ」をとても大事にしています。Filmarksは、“作品や人物について調べたら終わり”のようなサービスではなく、ユーザーがじっくり作品と向き合うプラットフォームです。ユーザーに、余計なストレスを与えない導線設計や、スムーズに作品を見つけてレビューを投稿できる使いやすさといった体験の細部にこだわっています。UIの自然さや操作の滑らかさが、プロダクト体験全体の快適さを左右すると考えています。
さらに、技術的負債の解消にも計画的に取り組んでおり、週に一度リファクタに集中する日を設けるなど、開発の質を高く保つ工夫もしています。
「リファクタ日」という取り組みもユニークですね。
毎週木曜日を「リファクタ日」として、その日は、新規開発を一旦ストップして、技術的負債の解消に専念する時間を設けています。さらに、数カ月に一度は、1スプリント分をリファクタに充てる期間を設けることもあります。たとえば、年末年始など、自然と開発の動きが落ち着くタイミングに合わせて設定することが多いです。
「この期間は新規開発をしなくていい」と明確に線引きすることで、心理的にも取り組みやすくなりますし、「いつかやらなきゃ」と後ろ倒しにされがちな作業に計画的に向き合う文化を育てることができます。リファクタは“やった方がいいこと”ではなく“やると決めたこと”として扱うことで、開発の健全性が中長期的に保たれている実感があります。
ミーティング設計にも工夫があるそうですね。
メンバーの集中を妨げないよう、ミーティングは特定の曜日にまとめて実施するようにしています。突発的な相談が頻発してエンジニア陣の集中を阻害しないよう、必要なやり取りは私がハブとなって調整することで、チーム全体の時間の流れをできるだけ分断しないようにしています。これは私自身が開発していた頃の体験から生まれた考え方です。細かくミーティングが入っていると集中が途切れてしまい、思考の流れが分断されて生産性が下がると感じていました。そのため、集中して取り組める時間を確保することを意識しつつ、必要なコミュニケーションのバランスをとるようにしています。
フェーズに応じて組織の形を変えていく。次は「最適なかけ算」が鍵に
今後の開発組織づくりについて、どのように考えていますか？
これまでの組織編成は、プロダクトの成長フェーズに合わせて少しずつ形を変えてきましたが、今後もその方針は変わらないと思っています。たとえば今は、一人ひとりのスキルや個性に対して、どんな「かけ算」をすることで最大限の価値が生まれるかを考えるフェーズに入っていると感じています。
その文脈でAIの活用も選択肢の一つにはなりますが、本質は「人がより本質的な価値発揮に集中できる状態をどうつくるか」だと考えています。人数をどんどん増やしていくのではなく、今いるメンバーの強みや関心をどう引き出し、どんな組み合わせがチームとして最適か。そういった視点で、組織のあり方そのものを見直していきたいです。
今ある形にこだわるのではなく、「今のプロダクト、今のチームにとってベストな形は何か？」を常に問い直しながら、柔軟に設計し直していく。そんな姿勢をこれからも大切にしていきたいですね。
編集後記
「人はマルチタスクが苦手」「指示が多すぎると処理が追いつかない」──こうした脳の認知的な特性を踏まえて、チームの設計を行う野田さんの姿勢には、感覚や属人性に頼らないマネジメントのあり方が表れていました。そこには再現性や効率性だけでなく、メンバー一人ひとりが安心して集中できる環境をどう整えるかという視点が通底しています。
たとえば、毎週木曜日を「リファクタ日」として開発を止めるのも、1スプリント分を技術的負債の解消に充てるのも、「急がない日」をあえて作ることで、エンジニアの納得感や心理的なゆとりを守ろうとする意図が感じられました。
また、ミーティングの頻度やタイミングにも「集中を守る」ための配慮が行き届いており、必要なコミュニケーションを維持しつつも、チームのリズムを崩さないための工夫が印象に残りました。
