事業や組織が成長するにつれて、向き合うべき課題は増えてゆく。例えば技術的な観点では、スピードを優先した開発の代償としての技術的負債の解消が求められ、また組織の観点では、拡大と分権化が進む中でいかに一体となって事業成長に取り組めるかも重要になるだろう。

アプリ開発・運用・分析をノーコードで提供するアプリプラットフォーム「Yappli（ヤプリ）」を開発・提供する株式会社ヤプリ。

2013年に3名で事業をスタートした同社も、今や正社員数は250名に迫り（2022年6月末時点）、サービスの導入実績は600社以上。Yappliを通じて作られたアプリの累計ダウンロード数は1億を突破するなど、順調に成長を続けている。

その成長の裏側で、同社は事業と組織の継続的な成長のために数多の取り組みを実施してきた。例えば2018年からは、創業初期から急成長フェーズを支えたYappliのCMS（コンテンツ管理画面）を、PHPからGoに全て刷新するという一大プロジェクトを実施。

また、月に2回、各自が好きな改善案件に集中できる「Yappdateday（ヤップデートデイ）」の実施や、誰でも改善アイデアをプレゼンできる「ヤプリク」の開催、組織全体の開発生産性を高めるための精鋭エンジニアメンバーで構成された「遊撃チーム」の設置など、組織全体でプロダクトの改善に向き合ってきた。

今回は、同社の開発部にてマネージャーを務める山田 智博さんと、プロダクト開発本部にてプロダクトオーナーを務める増渕 亜美さんに、ヤプリ社のこうした取り組みについて詳しくお話を伺った。

▼【左】山田さん【右】増渕さん

プロダクトオーナー4名体制で、50以上の機能を持つヤプリを開発

山田　僕は2018年7月に入社し、当初はサーバーサイドを主軸とした開発者として、プロジェクトの設計や実装などを担当していました。

現在はフロントとサーバーチームのマネジメントや採用業務に加えて、社内では「SWAT」や「遊撃」と呼ばれているミッション型チームのリード業務を担当しています。

現状、ヤプリのシステム開発全般を行うプロダクト開発本部の人数は100名ほどで、その中でもアプリケーション開発を主務とするサーバー、フロント、アプリエンジニアは合わせて40名弱ほどです。

▼ヤプリのエンジニア組織（同社提供）

増渕　私は2017年2月にヤプリに入社しました。社員番号は39番で、同期入社が数名いたので、当時はまだ全体で40名ほどの組織でした。

これまで色々な業務を担当してきましたが、現在はプロダクト開発本部に流れ着いて（笑）、プロダクトオーナー（PO）を担当しています。

POは、ヤプリ全体で4名います。Yappli自体に50以上の機能があり、その全体のバランスをとっていくためにも、プロダクト全体の知見を持つメンバー4名で分担して見ている形です。

私はその中でも、社内では「Enhance（エンハンス）」と呼んでいる、既存機能をより良くしていく役割をメインで受け持っています。

POの基本的な役割は、中長期の目線でやるべきことをリストにして、経営陣と話し合って開発の優先順位を決めることです。

そして実際に作るものが決まったら、リードエンジニアとPdM（プロダクトマネージャー）がアサインされ、キックオフして進めていきます。その中の要所要所で、POに相談や壁打ちをしながら、全体で合意形成をしていきます。

この体制になったのは2年ほど前ですが、それまではプロダクトマネージャー的なメンバーも足りていなかったので、優先順位の判断が遅れるなど、ボトルネックになってしまうこともありました。

そこでPOを4名立てて役割を分割しつつ、従来のPMをPdMという名称に変更して、より開発を進めやすくした形です。

初期のコードをPHPからGoに刷新。技術的負債の解消をスタート

山田　Yappliのプロダクトとしての歴史は長く、2013年の創業時に、創業者の一人である佐野が独力で基盤を築いてくれたことがスタートです。そして一定の成果を実現し、スケールに向けて基盤をより強固にしていく必要が出てきたタイミングで、自分や増渕さんが入りました。

増渕　私が入社した2017年は、プロダクトとしての主要機能が出揃ってきつつあったタイミングでした。当時はまだどちらかというとプロダクトアウトで、「一旦できるものを作ってちょっと当ててみよう」という形でしたね。

当時はまだ、創業時にプロダクトを作った時のコードがずっと生きていたのですが、お客様も200社を超えてシステムとしての限界が来ていて。

プロダクトアウトで作ったものに対するフィードバックや要望を目の前にした時に、現状のプロダクトの作り自体を考え直さないといけない、という課題が顕在化してきていました。

そこで、顧客の要望や、どうしたら売れるものになるかといったことを少しずつ整理しながら、2018年からは既存CMSをPHPからGoに置き換えるという大きなプロジェクトが始まりました。

山田　僕が入社した2018年7月のタイミングでは、もう移行の意思決定はされていて、具体的な設計に入っていく立ち上がりの時期でした。当時、自分はGoを全然触ったことがなかったのですが、大規模なプロジェクトの立ち上げから参加できるということで、ワクワクしていましたね。

チームでワイワイ一緒に物作りしていくことは、自分に限らずヤプリのエンジニアは好きな取り組みだと思います。実際にプロジェクトがスタートしてからは、ビジネス側からの要望というよりエンジニアドリブンで進めた部分も強かったので、みんな楽しんでいましたね。

山田　とはいえ、50以上ある機能ひとつひとつを、PHP側とGo側を両方運用しながらリプレイスしていくとなると実際は非常に大変でした。

最初は半年から1年で終わるだろう、という見積もりだったのですが、蓋を開けてみると、思っていたよりずっと大変で。移行完了まで、想定よりかなり長い時間がかかりました。

ただ、完全に個人的な意見ですが、最初にある意味「見切り発車」的にスタートしたことは良かったのではないかと思う側面もあります。

例えば最初から「5年かかる」と言われていると、高いモチベーションをもったままゴールに向かってやり切ろうという気持ちを持つことも難しいじゃないですか。

ある意味で無知だったからこそ、最初に士気も高くスタートを踏み切れて、結果的に最後までやりきることができたのかなと。

また、このCMSの置き換えとは別の部分でも、技術的な負債を解消するために個別にプロジェクトを動かしてきました。例えば2020年には、プッシュ通知基盤の刷新プロジェクトを行っています。

▼プッシュ通知基盤の刷新プロジェクトの概要（同社提供）

山田　背景としては、プロダクトの急成長によって、プッシュ通知の数が10倍、100倍というペースで伸びていて。現行のシステムでは、数年後にはクライアントが求める数のプッシュ配信を、期待通りの配信速度で提供する事ができなくなる未来が見えてきたので、刷新に踏み切りました。

成果としては、配信スピードが5〜20倍と段違いに改善し、複雑なセグメント条件による処理速度も大きく向上しました。加えてコードの運用保守性が高まったことで、開発スピードや品質も飛躍的に向上しましたね。

開発者以外も参加。全社でプロダクトを改善に向き合う取り組みも

増渕　技術的な文脈に加えて、ヤプリでは全社でプロダクトをより良くしていくために、さまざまな取り組みを行っています。

まずは、2018年の7月から始まった、改善案件に集中する日として月に2回設けられている「Yappdateday（ヤップデートデイ）」です

日々プロジェクトや不具合対応に取り組む中で、なかなか「改善」には時間を割きにくいじゃないですか。「業務の2割を改善に使いましょう」といった目標を設けたとしても、どうしても抜け落ちてしまうので、しっかりと時間を作ろうと。

Yappdatedayでは、普段の業務では優先順位が上がりにくいことを敢えて行います。クライアントの要望から発生する規模感の小さな改善はもちろんのこと、ヤプリでは不具合レベルとして「medium、high、highest、death」の4段階が設定されていますが、とくにmediumに着手するような形です。リファクタリングなども、この時間を使ってやってもらうようにアナウンスしています。

基本的にはメンバーの自主性を重んじたいので、各自が好きなことに取り組んでもらうことが前提です。ただ、「プロダクト目線で優先したいこと」の一覧を作っているので、やることが決まってない人はそのリストの上から順にやってもらったら私たちはめちゃくちゃ嬉しいよ、と伝えています。

山田　エンジニアからすると、明示的に確保された時間を使って普段手が回らなかった業務や自主的な改善に取り組めることももちろん良いのですが、ビジネスサイドからの小さな要望にしっかりと応えられることも嬉しいんですね。お互いにWin-Winの形になっていると思います。

※「Yappdateday」をもっと詳しく知りたい方はこちら：1日は改善案件のみに集中、ヤプリ開発チームで実施した「Yappdateday」で捗った話

増渕　また半年ごとに、開発チーム以外のメンバーも参加するプロダクトの改善イベント「ヤプリク」も実施しています。この名称は、「ヤプリ」「request（リクエスト）」「quest（探究）」からなる造語です。

以前は、全社員で集まって次に何をやるのかを決めるプロダクト会議を行っていたのですが、それが進化していって、今のヤプリクという形態になりました。

ヤプリクの場合は、Slackにプロダクト改善のアイディアを募るチャンネルがあり、一定の期間で締め切ってエントリーするものを決めます。そして発表会という形でプレゼンをしてもらい、受賞したものが実際にプロダクトに実装されます。

Yappdatedayを使って1、2日でやるにはちょっと工数的に足りないけれど、プロジェクトにするほどでもない規模感のものを取り扱う場所ですね。POとしても、現場の声を直接拾える、嬉しい機会になっています。

※「ヤプリク」をもっと詳しく知りたい方はこちら：部署の垣根を超えたプロダクト改善イベント「ヤプリク」を新入社員がレポート #今日のヤプリ

エンジニアの開発生産性を高める精鋭チーム「遊撃チーム」も活躍中

山田　また、エンジニア組織から昨年新しく、課題全般を解決する「遊撃チーム」が生まれました。このチームは経験の深いメンバーで構成されており、ほかのプロジェクトの進行の妨げになるような多種多様な課題をまとめて解決することが期待されています。

最初はサーバーサイドの領域で、ドメイン知識が必要になるような困りごとや、急なインシデント対応、社内からの問い合わせへの対応をまとめて請け負う受け皿として誕生したんですね。

後に、アプリ遊撃やフロント遊撃も立ち上がり、それぞれの領域における技術負債の解消や、品質改善、ルーティン業務の自動化や開発の生産性を高めるための取り組みを行っています。

エンジニアリングって、集中してなんぼだと思っていて。ですがプロダクトの歴史が深いからこそ、発生する運用保守業務も多く、それが集中を妨げてしまうんですよね。

そういった部分を遊撃部隊が巻き取ることで、プロジェクトで機能開発をしているエンジニアは、だいぶ集中して開発に取り組めるようになっていると思います。また、社内の問い合わせ窓口のような形でも機能しているので、社内からも「何かあったらこの人に聞こう」という形で信頼関係ができていて会社全体に貢献していますね。

加えて、個人的に組織づくりの文脈ですごく良いなと思っている取り組みが、「ウィンセッション（win session）」です。

我々は目標管理にOKRを導入しており、運用はヤプリ風に味付けはしていますが、仕組みとして良い部分は制度として積極的に活用するようにしていて。そのひとつがウィンセッションです。

具体的には、各プロジェクトの2週間分の進捗や取り組み、成果を発表して、それをお互いに称え合うという時間になっています。

発表者も小ネタを挟みながら笑いをとったり、Slackの実況チャンネルではにぎやかしがワイワイ盛り上がったり。プロダクト開発本部の雰囲気作りや、メンバーのヒーローマーケティング機会の創出にすごく役立っています。

▼実際のSlackの実況チャンネルの様子（同社提供）

増渕　組織の人数が増えてきたことで、ウィンとして発表されるものもどんどん洗練されてきています。発表する側のレベルの向上と、みんなの称え合おうという気持ち、両軸が育った結果として今の盛り上がりがあると思います。

「この会社が好きだ」と思えれば、パフォーマンスも上がっていく

山田　ヤプリはにまだまだベンチャー気質も残っていますが、これから大きな企業になりつつある…という成長のはざまにいます。実際、僕から見えている景色も毎年変わってきているんですね。

これからは個人個人のアウトプットも大切ではあるものの、「チームとして」「組織として」という文脈がより大事になってくるフェーズだと思っています。

その中で、ウィンセッションの話もそうですが、やっぱり僕はこの会社の雰囲気と言いますか、ポジティブな空気感がとても気に入っていて。それが組織に対して、プラスのバリューをめちゃくちゃ生み出していると思っています。

単純に、「この会社が好きだ」と思って業務に取り組んでもらえれば、「嫌い」より10倍以上のパフォーマンスが出るじゃないですか。なので、このヤプリの楽しい雰囲気を維持したままで組織づくりを行っていくことが、会社も個人も成功にも繋がる大切な要素だと思ってます。

とはいえ、チームを拡大させる上では締めるところは締めることも大事にしたいので、バランスを大切にしていきたいですね。

増渕　私は社歴も長くなってきて、プロダクト全体の仕様も歴史的経緯を含めて知っている範囲も広いので、私がわかっていることをメンバーに伝えてどんどんやってもらう、という段階を今踏んでいて。

その上で、私自身は「ヤプリがどうなったらもっとより良い未来になるか」ということをさらに考えていきたいと思っています。

そして、そういった意見がプロダクト開発部門からも、それ以外の部門からも出しやすいような雰囲気を作っていきたいですね。それによって、結果的にどんどんプロダクト自体も盛り上がっていくようなサイクルが作れたらより良いな、と考えています。（了）