アーカイブ動画
【POLA・ORBIS】内製開発チーム発足、既存基幹システムのマイクロサービス化推進
株式会社ポーラ・オルビスホールディングス
グループデジタルソリューションセンター
ITプロダクト開発チームリーダー 早川 美穂氏
最初に登壇したのは、株式会社ポーラ・オルビスホールディングスの早川美穂氏だ。早川氏は、SIerで金融系システムの開発を担当した後、2017年にオルビス株式会社へ入社。事業システムの運用保守や開発案件を担当してきた。2023年からは、内製開発チームを発足し、現在は内製開発チームのマネージャーとプロダクトオーナーを兼務している。
ポーラ・オルビスホールディングスは、「POLA（株式会社ポーラ）」や「ORBIS（オルビス株式会社）」といったビューティーブランド企業グループで、お客様との直接的つながりを核としたダイレクトセリングを強みとしている。
加えて、研究開発部門で長年にわたり蓄積された膨大なデータによる分析。さらに、専任パートナーやビューティーディレクターといった“人の力”を掛け合せることで、組織も商品も常に変革し続けている。
事業システムの開発などは、これまで外部のITベンダーに依頼していた。そのためプロダクトの中身が、ブラックボックス化していた面もあった。変化の激しい昨今では、プロダクトの開発スピードが課題となるようなこともあり、内製開発に取り組むこととなった。
2021年に発足した内製開発トライアルチームは、翌年に在庫管理システムというプロダクトを開発し、運用もスタートする。
そこから得た内製開発や運用の知見をもとに、エンジニアの採用やオフショアなど、外部のパートナーなどへの依頼で協力を得て、2023年に改めて本格的な内製開発チームの発足に至る。
早川氏はまず、所属するグループデジタルソリューションセンター（GDSC）のみで利用する勤怠管理システムをPoC開発し、一部のチームで運用をスタート。その後、GDSC全体に展開していった。さらには、オルビスブランドで利用する商品管理プロダクトの開発にも着手していく。
2024年に入ってからは、商品管理プロダクトの運用を開始し、継続的にプロダクトのブラッシュアップを行う。さらにこれまでよりも規模や難易度も高い、オルビスブランド内で使う販促管理システムの開発も手がけるようになる。早川氏はここまでの道のりを振り返り、鳥の成長に例え、次のように述べた。
「徐々にではありますが、最初のころと比べれば成長していると感じています。ただ、現在はようやくヒヨコになれた状態。これからさらに成長して、鳥になりたいと考えています」（早川氏）
実際に手がけている開発プロダクトも紹介された。オルビスブランドで10年以上利用され、複雑・巨大化したシステムの一部を切り出し、マイクロサービス化して、UIも刷新したものだ。
「リファクタリング案件だと思われがちですが、実際にはイチからアプリを作る感覚でした」と早川氏。実際にUIの画面も紹介。使いやすく刷新されていることが分かる。
スクラムマスターも含め、エンジニアの採用も進んでおり、現在は2チーム体制で内製開発に臨んでいる。
続いては、同社のグループデジタルソリューションセンター ITプロダクト開発チームでスクラムマスターを担当する川田大蔵氏が登壇。チームビルディングについて紹介した。
川田氏は、精密機器メーカーで産業装置向けのUIシステムの開発に携わった後、2020年に自動車メーカーに転職。コネクテッドカー向けサービスのバックエンド開発・運用チームでリーダーならびにスクラムマスターを担当していた。2023年にポーラ・オルビスホールディングスに転職し、入社後は内製開発チームのスクラムマスターとして尽力している。
チームビルディングにおいては、「大きく3つの点に注力していた」と、川田氏は語る。1つ目は、リモートワークのメンバーが中心であることから、オンラインでのコミュニケーションの醸成に注力してきた。
具体的には、例えばTeamsを常時つないだ作業部屋を設け、メンバー同士が気軽に話しかけられるように、コミュニケーションハードルを下げる仕組みを整えた。
2つ目は、オフラインでメンバーを集め、プロジェクトに対する抱負や、自分が取り組みたいこと、他のメンバーに期待していること、自分が好まない働き方などの声を集めて、ホワイトボードに貼り付け、見える化したことだ。
そのようにメンバーの声を皆で共有し、確認した上でグランドルールを作成していった川田氏は、次のように述べ、ファーストセッションを締めた。
「現在もことあるごとに、グランドルールがしっかりと運用できているか、メンバーの意見を確認。できていない場合には対応するようにしています」（川田氏）
【ウェルスナビ】クネビン・フレームワークを活用し、開発者体験を向上
ウェルスナビ株式会社
フロントエンド開発グループ
モバイル開発チーム ディレクター 北原 幹也氏
※所属はイベント登壇時のもの
続いて登壇したのは、ウェルスナビの北原幹也氏だ。北原氏はAndroid開発者としてキャリアを積んだ後、2023年にウェルスナビに入社。モバイルアプリ開発チームの責任者、新規事業開発のテックリードを務める。
ウェルスナビでは、「働く世代に豊かさを」「新しい金融インフラの構築」といったミッションやビジョンを掲げ、オンラインで完結する資産運用サービス「WealthNavi」を提供している。
WealthNaviは、ユーザー個人が設定する希望運用プランや目標金額などに沿って、投資先の選定やポートフォリオの構築から運用、さらには税金の支払いまですべて自動で行ってくれるサービスだ。
今後の事業展開としては、生命保険など、お金にまつわるあらゆる悩みを解決する総合的なプラットフォームへの展開を計画している。既に2つの新サービスがローンチされており、北原氏はこの2つの新規サービスにおける、自身の関わり方も含めた開発の舞台裏を紹介した。
ウェルスナビでは、PdM・テックリード体制をとっており、PdMとテックリードはお互いに問題を認識して仮説を立てる。解くべき優先順位を決めて、実現可能な課題に分割していくのだ。北原氏は、エンジニアも含めたそれぞれの役割、関わり方をまずは示した。
続いては、北原氏自身の関わり方について紹介した。ゼロイチフェーズでは、課題の解決や顧客に価値を提供できる可能性のあるアイデアを検証可能な状態とすることである。具体的には、要件定義や仮説・検証といった業務が該当する。
VUCAとの言葉で標榜されるような予測困難な昨今においては、どのような新サービスを開発すればよいのか。「正解を得ることが難しい」と、北原氏は指摘する。
その中で生み出していくためには、仮説検証できるアウトプットの量を増やすことが重要であり、「このような環境の構築は開発者体験の向上にもつながると考えています」と、続けた。
さらに北原氏は、仮説検証を行えるアウトプットの量を増やすには、解くべき問題を決める必要があり、その際に効果的な手法が「クネビン・フレームワーク」だと、述べた。
クネビン・フレームワークでは、いくつかの状態が示されている。1つ目は、問題が何なのか理解できておらず、問題が発生するまで待つしかない状態。いわゆるカオスと呼ばれる「混乱・混沌」とした状態だ。
2つ目が、複数の因果関係が混じり合っている状態だ。3つ目は、因果関係は把握しており、課題解決の予想はついている「困難な状態」。4つ目は、対処方法が明確に分かっている「単純な状態」だ。そしてゼロイチフェーズでは、1つ目のカオス状態の場合が多いと、北原氏は指摘した。
では、混沌とした状態から、どのようにして単純な状態にしていくのか。
「まずは行動することが重要です。行動することで、問題を認知できるようになるからです」（北原氏）
複雑な状態においては、複数の因果関係を探索して把握した上で、対応していく。一方、困難な状態では把握をした上で、分析・対応していく。単純な状態でも把握した後、分類・対応していく。北原氏は改めて、クネビン・フレームワークによる取り組みを、次のようにまとめた。
「問題の状況を把握して必要なアクションを実施することで、問題をできる限り明確な課題などに単純化・分割することで、課題の解像度が上がり、解の精度を高めることができると思っています」（北原氏）
そして、先ほど紹介した2つの新サービスは、「仮説検証可能な状態となったことで、以降のフェーズではプロダクトマーケットフィットに向けて仮説検証を繰り返していきます」と、続けた。
北原氏は、クネビン・フレームワークによる取り組みの課題、失敗も紹介した。先述のように行動・認知・対応などをスプリントとして繰り返すことで、課題の解像度は確実に高まっていった。
課題の解像度を高めることにばかり注力してしまい、気づいたときには中期的なゴールとの認識が乖離していたからだ。「そこからの修正、フィードバックは、それなりの労力を要しました」とも述べた。
このような経験から北原氏は、以下のように述べ、セッションを締めた。
「アウトプットがどんどん出るようになったら、どこからのタイミングで一度立ち止まり、方向性とマイルストーンならびに、ゴールやリリース期日も定めるべきでした」（北原氏）
【タイミー】「開発者体験」の視点や観点で組織運営や経営を考えることは有効
株式会社タイミー
執行役員 CTO 亀田 彗氏
続いては、タイミーCTOの亀田彗氏が登壇した。「スタートアップが好き」と語る亀田氏は、大学生のときからスタートアップやメガベンチャーでインターンを経験してきた。卒業後はピクシブでアプリエンジニアをしながら、CPOとしてタイミーと関わるようになる。2020年にタイミーの執行役員CTOとして改めてジョインし、現在に至る。
亀田氏はまずは内製開発について、「必要性から考える必要がある」と、自身の考えを述べていった。最初に取り組むべきことは、既存のSaaSやサービスを調べることであり、「既存サービスの活用が最も速く、信頼がおけるからです」と、亀田氏は語った。
その上で、既存のSaaSなどでは課題が解決されない場合、内製化も含めた開発を検討していく。外注と内製化の判断については、解決する問題が明確で、変化がないものであれば、外部委託が有効だという。
逆に、変化が生じたり、変化する流れや課題解決の方法が分からなかったりする場合は、内製化が有効だと述べた。そのため「変化については精査する必要がある」と補足した。
「内製開発は、変化と曖昧さに圧倒的に強い」と亀田氏は強調する。このような特徴を持つため、ビジネスモデルが不明瞭であったり、これから広げていったりするようなITソリューションの開発において大きく寄与すると語った。
さらに内製開発のメリットを2つ紹介した。1つ目は、事業ならびにソフトウェアの解像度が高まる点だ。実際、タイミーの歩みを振り返ってみても、創業当時はソフトウェアのスペシャリストや、業界のエキスパートであったわけでもなかったという。
しかし、継続的にソフトウェアを内製化していくうちに、タイミーが手がけたいビジネスと、その実現に向けたソフトウェアが描かれていったのだ。
もう1つは、内製開発は変化の容易性を高めることができる点だ。具体的には、お客様から至急修正してほしいとの依頼があった場合、外部委託では対応が難しいが、内製開発であれば可能な場合もあるからだ。
このような内製開発の強みやメリットを踏まえた上で、「内製開発はモノへの投資から、チームとプロセスへの投資へのシフトだと捉えています」と、まとめた。
続いては、もうひとつのテーマ「開発者体験」についての見解を述べた。CTOやVPoE などの経営陣は、「開発生産性」の観点で戦略を立てることが多いと亀田氏は言う。
例えば、ソフトウェアの開発、運用の効果的なパフォーマンスを測定・評価する、DORA Core Modelなどの活用だ。
一方で「開発者体験」はあくまで従業員である一人のエンジニアの観点で評価する体験価値であり、具体的には携わっているプロジェクトが魅力的か、プロダクトそのものに興味があるか、といった内容となる。
さらに亀田氏は、このような開発者体験の観点から内製開発の評価を行うと、ボトムアップな検証や、さらなる説明の補完ができるのではないか。つまり、「開発者体験を考えて投資していくことは、有効だと思っています」と続けた。
具体的には、どのような観点に分解し評価していけばよいのか。ブレークダウンした要素が記載されたスライドも紹介された。
「一人ひとりの時間を豊かに」「『はたらく』を通じて人生の可能性を広げるインフラをつくる」というビジョン・ミッションを掲げるタイミーでは、ちょっとした空き時間に、バイトを簡単に探せるスキマバイトサービスの「タイミー」を開発・運営している。
面接や履歴書は不要、最短1時間から当日申し込みで働ける。給料は即日入金。雇用契約や労務管理などもタイミーのシステムを通じて行える。
このような手軽さや利便性が、求職者や人材を求める事業者両方から支持され、現在ではスキマバイト業界におけるナンバーワンの実績を誇るアプリとして成長している。
亀田氏は技術スタックや開発環境や開発組織についても紹介した。サービス開発組織は現在「マッチング」「スポットワークシステム」「開発プラットフォーム」と大きく3つの部門に分かれている。
マッチング部門は、仕事を求めるユーザーに最適な仕事を提供するタイミーのコアコンピタンスでもある。一方、スポットワークシステム部門は給与の振り込みなど、いわゆる事業システムを開発する部門だ。
「それぞれ自分のスキルが活かせる部門があるので、開発者体験の向上につながると考えています」（亀田氏）
また、それぞれのチームが独立して価値を提供できることを重視しているため、一つのチーム内にさまざまなスキルを持つメンバーが所属している。スクラムマスターも在籍し、チームごとに解決していくテーマが設定され、日々解決に向けてメンバーが取り組んでいる。
エンジニアのキャリアパスは、プロダクト開発領域だけでない。テックリードやアーキテクトといったテクノロジー領域・職種、さらにはスクラムマスターやアジャイルコーチといったパスを用意することで、さらに開発体験を高めることに取り組んでいる。
「個人の視点、観点での開発者体験に立ち戻ったり、開発者体験を高めることは、結果として組織運用に有効であったり、開発者生産性を高めることにもつながるのではないか。そのように考えています」（亀田氏）
【トークセッション】「内製開発」「開発者体験」「チームビルディング」を語り合う
登壇セッション後は、「内製開発」や「開発者体験」といったテーマやイベント参加者からの質問に応えるかたちで、登壇者たちが語り合った。
まずは「開発者体験」と「開発生産性」の関係性について、Googleトレンドにおける検索キーワードの結果も示しながら、それぞれの意見を聞いた。
●「開発者体験」と「開発生産性」の関係性
亀田：開発生産性は、説明することを求め続けられるような気がしています。例えば、リファクタリングしたいと提案する際に、ROIが見合っているかどうかを聞かれる。その結果、Googleで検索し続けているのではないかと、思いました。
北原：開発生産性は最近話題になっていて、いろいろなところで取り上げられていると感じています。開発者体験は後から出てくる個人の無意識の体験であり、言語化されて出てきたものだと捉えています。
川田：開発生産性は注目されるので、Four Keysなどを利用して説明する状況があると思います。実際、我々も取り組みを検討している段階です。開発者体験は働きやすさに尽きると思います。ただ要素が多く細かいため、それらがたまたま言語化されたり認知されたりしてきたのだと思います。
Q．開発のしやすさとの関連性はどうですか？
川田：開発者体験を意識したわけではありませんが、1年ほど前にチームにスクラムマスターとしてジョインして以降、自分が現場のエンジニア時代に経験して良かったこと、逆にできなかったことなどを、開発を進める中で少しずつ取り入れるなどして対応しています。
北原：私も開発者体験を意識したことはなく、無意識で進めてきたと思っています。その中で一つ心がけてきたことがあります。何をやっていいのか分からない、混乱している。そのようなunknowな状態を作らないことです。なんとか解ける問題として、登れる山にするよう意識してきました。
亀田：これまでは「開発生産性に対する意識を持って、ずっと取り組んできた」というのが正直なところです。今回のイベントに参加するまで、特に開発者体験を意識したことはありませんでした。
一方で、みんなが楽しく働くことのできる環境は大事との認識はありましたし、準ずる取り組みも推進してきました。フラグメント（断片）としては、開発者体験を捉えていたんだと思います。
結局のところ、生産性から見るのか、それとも人の体験から見るのかといった観点の違いなのかなという気がします。
ゼロイチフェーズの仲間集め・チームビルディングについて
Q．エンジニア経験の有無など、多様なメンバーでプロダクト開発に臨む際、取り組むべきこと、逆に取り組まない方がよいことは何でしょうか？
亀田：継続的な対話に取り組み、どのようなプロダクトを作りたいのかなど、話し合うことが大切だと思います。当然、コンフリクトは起きますが、乗り越えることで組織全体の力がつくと思うからです。
逆にしない方がよいと思うことは、これはエンジニアリング組織に限ったことではありませんが、それぞれの専門職のメンバー同士で対立や溝を生み出すような振る舞いや構図です。
北原：専門知識を持っていない相手に「どうせ分からないでしょう」という考えで、情報共有しないことはおすすめしません。「知らない」「分からない」ままで進めると、イメージと全く異なるプロダクトになってしまい、どこかで衝突が起こる可能性があるからです。
専門知識のないメンバーでも理解できるように、文字だけの説明ではなく、可視化して共有する。その上で相手の意見を聞き入れ、議論することが重要だと思います。
川田：北原さんの意見に同意です。いきなり出来上がったプロダクトを見せられ、それが論理的に正しいとしても、一瞬で納得する人は少ないと思うからです。段階を踏んで少しずつコミュニケーションを取りながら、皆で気持ちを揃えて同じゴールに向かっていく。そのような進め方が大事だと思います。
Q．若手や経験の浅いエンジニアが、自らコミュニケーションを取るのは難しいのではないでしょうか？
川田：私も若い頃は自分から意見を言うことは難しかったです。例えば、同期の話しやすい仲間や面倒見のよい先輩など、味方を見つけて巻き込んで数を増やすのがよいと思います。
亀田：タイミーではリモートワークを推進していて、いずれはフルリモートでまわるような組織にしたいと考えています。一方で、リモートワークはどうしてもコミュニケーションパスの作りづらさがあります。そこで、雑談イベントやリモートランチ会などを企画していますが、なかなかリアルなオフィスでの交流には敵いません。
そこで取り組んでいるのが、ドキュメンテーションと非同期コミュニケーションです。クローズドな場で意思決定がされないようにする。みんなが見ている、見える状況でディスカッションが進むような環境を意識しています。
北原：ウェルスナビは、週3回はリアル出社なので、コミュニケーションにおいては、リモートワークよりはるかに高いと捉えています。加えて人事メンバーが1on1を開催したり、他のチームのメンバーを紹介したりするような取り組みをしてくれるのも、大きいと感じています。
メンバーを増やせば、良いプロダクトが作れるわけでもありません。最少人数でケイパビリティをまとめるというか補うというか。今、何が足りないのかといった解決策は難しいですが、メンバーの成長を促し、出会いなどを通じて実現するような施策をよく考えています。
Q．機能追加や改善などにおける優先順位のつけ方について、意見をお聞かせください。
早川：以前は該当する業務部門が決めていましたが、現在はプロダクトオーナーである私が決めています。実際にシステムを使うのは業務部門ですが、工数などの観点から客観的に判断することが大切だと思うからです。
ただ決定案に納得してもらうためにも、普段から業務側のステークホルダーとの関係性を構築することが大事です。また今すぐに取り組まない場合は、理由や次のスプリントで実施しますといったことを伝え、納得してもらうように努めています。
実際、セッションで紹介した基幹システムをマイクロサービスとして切り出すスコープの選定や優先順位においても、我々のチームで決定しました。最初に取り組んだ商品管理機能スコープを選んだ理由は、難易度が一番低いことでした。
内製開発チームができて間もないですから、できるだけ取り組みやすいスコープを選びました。もちろん、必要性が高いことも理由の一つでした。このような背景や理由をまとめて、経営陣にも報告しています。
北原：今が大事だと思っています。そのため重要度は高くても緊急度が低ければ、後の対応となります。ただ、いつどこでリスクが生じるかは分からないので、すべてのリスクをバックログに載せて、定期的に確認し、その順番を変える取り組み方をしています。
亀田：当社も決定は属人化していますし、そうしないとプロジェクトがまわらないと考えています。例えばリファクタリングなどは、皆の意見を公平に聞いたり、比較したりすることは難しいと思うからです。
競合の成果や実際に動くものを作って経営層を説得させるには？
Q．新しい技術やサービスを導入するにはどうすればよいでしょうか？
亀田：CTOや事業責任者と会話する際に、競合が利用していることを伝えるとともに、導入成果としてユーザー体験につながるようなことを示すといいと思います。またその際には、開発にかかる期間や工数なども併せて伝えます。実際、タイミーでもSPA化を2年ほどかけて、リアーキテクチャも進めている最中です。
川田：動くものを見せることが大事だと思います。例えば、リアーキテクチャしたいという要望があった場合には、とりあえず小さい状態で構わないので、さっと作ってできるものを見せるのです。競合が似たようなものを作っていればいいですが、ない場合は自分で作る。動くものを見せるのはインパクトが大きく、説得力が出るからです。
北原：2週間もしくは4週間と短い期間を指定し、「とりあえずその期間だけ取り組ませてください」というアピールをするようにしています。
株式会社ポーラオルビスホールディングス
https://www.po-holdings.co.jp/
株式会社ポーラオルビスホールディングスの採用情報
https://engineer.po-holdings.co.jp/
関連するイベント
