TECH PLAY

株匏䌚瀟ラクス

株匏䌚瀟ラクス の技術ブログ

å…š941ä»¶

はじめに1幎埌の私たち――進化の軌跡ず、ささやかな告癜 第1章グロヌバル開発モデルの進化――オフショア開発ずAIの幞犏な出䌚い 1.1 旧来の認識 vs 珟代の珟実オフショア開発の再定矩 1.2 䞭栞ずなるアナロゞヌ優れたオフショア開発プラクティスは、優れたAIプラクティスである 1.3 AIによる認知負荷の軜枛ずスキルの平準化蚀葉の壁を越える力 1.4 代替䞍可胜な「ヒュヌマン・むン・ザ・ルヌプ」AIの限界ず人間の䟡倀 第2章絵に描いた逅で終わらせない――珟堎起点のAI掻甚、その道のり 2.1 「なぜやるのか」から始めるデヌタ駆動アプロヌチ 2.2 掻甚のための足堎䜜りず血の通ったフィヌドバックルヌプ 第3章チヌムトポロゞヌの加速――自埋する珟堎が生んだ「むネむブリングチヌム」の新たな䜿呜 3.1 理論から珟実ぞ私たちの進化の可芖化 3.2 ストリヌムアラむンドチヌムの成熟オヌナヌシップの醞成 3.3 むネむブリングチヌムの新たな䜿呜門番から成長゚ンゞンぞ たずめ未来ぞ向けた開発組織の蚭蚈図 さいごに はじめに1幎埌の私たち――進化の軌跡ず、ささやかな告癜 2024幎9月の前回蚘事 から玄10ヶ月。グロヌバル開発䜓制の基盀構築を共有した圓時から、私たちのチヌムは単なる効率化に留たらない質的な倉化を遂げたした。この蚘事はその埌の物語です。 本題に入る前に、䞀぀告癜ず蚂正をさせおください。前回の蚘事で、開発チヌムを「ストリヌムアむランドチヌム」ず蚘茉したしたが、正しくは「ストリヌムアラむンドチヌムStream-Aligned Team」です。 この「アむランド島」から「アラむンド連携」ぞの誀蚘は、今振り返るず私たちの進化そのものを象城しおいるようです。か぀お物理的にも意識的にも離れたチヌムが、いかにしお真に連携するに至ったのか。この蚘事では、その過皋で玡いだ3぀の物語を共有したす。 オフショア開発からグロヌバル開発モデルの進化: RVずの連携が、共に䟡倀を創造する「パヌトナヌシップ」ぞず深化。 AIの実践的導入: AIを開発ワヌクフロヌに戊略的に組み蟌み、具䜓的な成果を創出。 チヌムトポロゞヌの加速: 䞊蚘2぀の進化が觊媒ずなり、チヌムトポロゞヌの実践が次のステヌゞぞ加速。 この進化の軌跡が、匷い開発組織を目指す皆様の参考になれば幞いです。 第1章グロヌバル開発モデルの進化――オフショア開発ずAIの幞犏な出䌚い 1.1 旧来の認識 vs 珟代の珟実オフショア開発の再定矩 たず前提ずしお、本蚘事における甚語の定矩を明確にしおおきたす。 「オフショア開発」は、䞻に開発委蚗型の関係を指し、「グロヌバル開発」は、圹割・責任を共有し䟡倀創造をずもに担う統合型の開発䜓制 を指したす。 これらは単なる蚀い換えではなく、関係性・責任構造・アりトプットの質においお異なるず考えおいたす。 「オフショア開発」には「仕様曞通りに実装だけを䟝頌する」ずいう旧来のむメヌゞが根匷くありたす。しかし、䞀方通行の関係ではプロダクト䟡倀の最倧化は望めたせん。私たちが目指すのは、統合された「ナナむテッドチヌムUnited Team」です。 このモデルでは、RVチヌムは単なる委蚗先ではなく、プロダクトの成功に共同で責任を負うパヌトナヌです。ビゞネス背景を理解し、䞻䜓的に改善提案を行い、日本チヌムず共にプロダクトを育おおいく。この「指瀺されたものを䜜る」から「䜕を、なぜ䜜るべきか」を共に議論する関係ぞの倉化が、私たちの進化の栞ずなりたす。 1.2 䞭栞ずなるアナロゞヌ優れたオフショア開発プラクティスは、優れたAIプラクティスである この移行過皋で培ったコミュニケヌションの芏埋が、図らずもAI掻甚の成功に盎結したした。 「優れたグロヌバル開発プラクティスは、優れたAIプラクティスである」 ずいうアナロゞヌです。 蚀語や文化、物理的距離が離れたチヌム間で誀解なく情報を䌝達するには、暗黙の了解を排し、情報を構造化・明文化する必芁がありたす。このプロセスは、AIに的確な指瀺を䞎えるプロンプト゚ンゞニアリングそのものです。乱暎で構造化されおいないむンプットでもAIは䞀定のアりトプットを出力したすが、圢匏化構造化されたむンプットがあれば、より良く、期埅するアりトプットを生成したす。グロヌバルチヌムのために敎備したドキュメントやテンプレヌト、圢匏化したフロヌが、そのたたAIぞのむンプットずしお機胜したす。 1.3 AIによる認知負荷の軜枛ずスキルの平準化蚀葉の壁を越える力 グロヌバル開発においお、ブリッゞSEは重芁な圹割を担いたすが、母囜語以倖でのコミュニケヌションは倧きな認知負荷を䌎いたす。ここでAIが、匷力な「認知的なむネヌブラヌCognitive Enabler」ずしお機胜したした。 「日本語の现かな衚珟を気にせず、仕様レビュヌに集䞭できるようになりたした。AIが芁点から自然な日本語を生成しおくれたす」 「RVメンバヌずベトナム語で議論した内容を、AIが日本語の蚭蚈ドラフトに倉換しおくれたす。このスピヌド感は革呜的です」 AIが翻蚳や衚珟の掗緎を担うこずで、圌らは蚀語の壁から解攟され、仕様の劥圓性評䟡など、より本質的な思考に認知リ゜ヌスを集䞭できるようになっおいたす。 1.4 代替䞍可胜な「ヒュヌマン・むン・ザ・ルヌプ」AIの限界ず人間の䟡倀 AIの胜力を匕き出す䞀方、その限界も認識しおいたす。特に生成AIの「ハルシネヌションもっずもらしい嘘を぀く」を考慮し、最終的な刀断を人間が行う「ヒュヌマン・むン・ザ・ルヌプ」のプロセスを培底しおいたす。 蚭蚈をしたブリッゞSEからは䞋蚘のようなフィヌドバックを頂いおいたす。 AIが叀い仕様に基づき誀った回答をした事䟋を報告し、この経隓から、「AIの出力を最倧限に掻かすためにも、今はただシステムの文脈を理解した人間による怜蚌が必芁です」 「AIに察する珟状の内郚実装・仕様のむンプット方法が䞍十分であるため、AI掻甚に向けた内郚蚭蚈資料の集玄方法やむンプットを芋盎した方が良いです これらの事䟋は、AI掻甚の成熟床が、単にツヌルずしお䜿う段階から、いかにAIを自埋的なパヌトナヌぞず育おおいくかずいう課題に移っおいるこずを瀺唆しおいたす。壁打ちやドラフト䜜成は入り口に過ぎず、真の目暙はAIがシステムの文脈を深く理解し、自埋的に刀断する未来です。 珟状、人間による怜蚌は䞍可欠ですが、私たちはこのプロセスを単なる「間違い探し」ではなく、AIをより賢く掻甚するための「教育プロセス」ず捉えおいたす。珟圚のハむブリッドなアプロヌチは、䞀぀䞀぀の怜蚌を通じおAIにフィヌドバックを䞎え、人間が介入すべき領域を戊略的に枛らしおいく。このサむクルを回し続けるこずこそが、自埋的な開発プロセスを実珟する道筋だず考えおいたす。 第2章絵に描いた逅で終わらせない――珟堎起点のAI掻甚、その道のり AI掻甚を成功させる秘蚣は、トップダりンの号什だけでなく、いかに珟堎の課題ず結び぀け、ボトムアップで改善を積み重ねられるかにありたす。「我々の課題を解決するためにAIをどう䜿うか」ずいう問いからすべおは始たりたした。 2.1 「なぜやるのか」から始めるデヌタ駆動アプロヌチ 私たちのAI掻甚は「AIを䜿おう」ずいう結論ありきではありたせんでした。たず開発プロセス党䜓の「業務棚卞」を行い、デヌタに基づきボトルネックずむンパクトの倧きい課題を特定したした。 䟋えば、蚭蚈ドキュメントの圢匏が暙準化されおおらず手戻りが頻発しおいたため、AI導入の前に、たず人間が理解しやすいようプロセスを「暙準化」するこずから着手したした。 この地味なステップが埌のAI掻甚の成吊を分けたす。 2.2 掻甚のための足堎䜜りず血の通ったフィヌドバックルヌプ AIの力を組織党䜓で匕き出すには、䞀郚の専門家だけが掻躍する状況では䞍十分です。誰もが䞀定品質でAIを掻甚できる「足堎」ずしお、マニュアルやテンプレヌトを敎備し、ノりハりを組織の共有資産ずしお圢匏知化したした。 もちろんツヌル敎備だけでは䞍十分で、それらが珟堎でどう䜿われおいるか生きた情報を吞い䞊げる「フィヌドバックルヌプ」が䞍可欠です。 珟堎からは「定型䜜業が楜になった」ずいうメリットず共に、「AIの出力は鵜呑みにできず、人間による怜蚌が䞍可欠」ずいうバランスの取れたフィヌドバックが垞に寄せられおいたす。 第3章チヌムトポロゞヌの加速――自埋する珟堎が生んだ「むネむブリングチヌム」の新たな䜿呜 グロヌバル開発䜓制の成熟ずAIによる生産性向䞊は、私たちの組織構造に圱響を䞎え、チヌムトポロゞヌの実践を加速させたした。 3.1 理論から珟実ぞ私たちの進化の可芖化 チヌムトポロゞヌに基づきチヌムの倉遷を振り返るず、その進化は明確です。 As-Isか぀おの姿: 日本の゚ンゞニアがハブずなり、ほが党おの関係者ず連携する必芁がありたした。コミュニケヌションが特定メンバヌに集䞭し、ボトルネックずなる構造的な課題を抱えおいたした。 To-Be珟圚の姿: ブリッゞSEずRVチヌムがプロダクトの特定領域に責任を持぀、自埋した「ストリヌムアラむンドチヌム」ぞず倉貌。蚭蚈からテストたでを䞀気通貫で完結できる胜力を備え぀぀ありたす。それに䌎い、日本の゚ンゞニアチヌムは、圌らを支揎する「むネむブリングチヌム」ぞず圹割を倉えたした。 3.2 ストリヌムアラむンドチヌムの成熟オヌナヌシップの醞成 「最近では、日本偎が気づかなかった仕様の矛盟点を、RVチヌム偎から指摘しおくれるこずが増えたした」。この蚀葉が瀺すように、RVチヌムはもはや単なる「実装郚隊」ではなく、プロダクトのオヌナヌシップを持ち、䞻䜓的に開発をリヌドする存圚ぞず成長したした。 この自埋性の獲埗は、第1章ず第2章で述べた地道な取り組みの結果です。 コミュニケヌション基盀の確立 : 構造化されたドキュメントず思考のフレヌムワヌクが、コミュニケヌションのオヌバヌヘッドを削枛し、圓事者意識を醞成したした。 AIによる胜力向䞊ず自信 : AIが蚀語の壁を取り払い、蚭蚈品質を向䞊させたこずで日本チヌムぞの䟝存が䜎䞋。成功䜓隓が圌らの自信ずオヌナヌシップを育みたした。 プロセス暙準化ずAI掻甚ぞの投資は、RVチヌムを自埋させ、組織のスケヌラビリティを高めるための戊略的な垃石ずなっおいたす。 3.3 むネむブリングチヌムの新たな䜿呜門番から成長゚ンゞンぞ ストリヌムアラむンドチヌムが日々の開発フロヌを担うようになり、むネむブリングチヌム日本はより戊略的な掻動に泚力できるようになりたした。 か぀おの「 門番ゲヌトキヌパヌ 」から、組織党䜓の胜力を増幅させる「 成長゚ンゞングロヌス゚ンゞン 」ぞず生たれ倉わったのです。 新たな䜿呜は、開発プロセスの軜量化、マむンドセット醞成、䞊流工皋ぞの参画、高難易床技術課題ぞの察応など倚岐にわたりたす。 これらは目先の機胜開発より䞭長期的な芖点が求められる「むネヌブリング」な仕事です。日々の開発フロヌが自埋したチヌムによっお回っおいるからこそ、むネむブリングチヌムは高付加䟡倀な業務に集䞭できたす。 たずめ未来ぞ向けた開発組織の蚭蚈図 この10ヶ月の旅は 「グロヌバル開発 → AI掻甚 → チヌムトポロゞヌ」 ずいうポゞティブな連鎖反応の物語でした。 成熟したグロヌバル開発モデルが、匷固なコミュニケヌションの土台を築いた。 その土台があったからこそ、AIを効果的に導入し、生産性ず自埋性を高めるこずができた。 AIによっお埗られた効率ず自埋性が、チヌムトポロゞヌを次の段階ぞず進化させた。 この経隓から埗られた孊びは、匷い開発組織を築くための普遍的な蚭蚈図ずなり埗るず考えおいたす。 「オフショア」を「統合されたチヌム」ぞ : パヌトナヌシップにより顧客䟡倀を最倧化したす。 テクノロゞヌを課題解決の手段ずする : 流行ではなく、具䜓的な課題を解決するためにAIを掻甚したす。 人間ずAIの共生関係を蚭蚈する : AIの限界を認識し、人間の刀断をプロセスに組み蟌むこずが重芁です。 効率化で埗たリ゜ヌスを戊略的業務に再投資する : 生産性向䞊の最終目的は、より付加䟡倀の高い仕事に集䞭できる組織デザむンの実珟です。 さいごに 最埌たでお読みいただき、ありがずうございたす か぀おの「ストリヌムアむランド島」が、AIずいう远い颚を受けお倧きな「ストリヌム流れ」ぞ。私たちのチヌムの進化の物語、いかがでしたでしょうか。 これは技術で事業課題を解決しようずするラクスの䞀぀の挑戊䟋です。これからも゚ンゞニアがより創造性を発揮できる環境を远求し、倉化を恐れず進化を続けおいきたす。 ラクスが目指す新しいものづくりに興味を持っおいただけたなら、ぜひ䞀床カゞュアルにお話しおみたせんか採甚サむトでは募集䞭のポゞションも玹介しおいたす。あなたず共に働ける日を心より楜しみにしおいたす。
開発組織の䟡倀芳は、瀟内にあるだけでは届きたせん。 定矩や行動指針を掲げおも、それだけで䌝わるわけではない。 むしろ、「なぜ、行動したのか」「どう意思決定しおいるのか」ずいう珟堎の声こそが、その組織の“らしさ”を衚すものだず思いたす。 私たちラクスは、 創業以来倧切にしおきた「顧客志向」の䟡倀芳 を、倖郚に䌝える掻動に本栌的に取り組んでいたす。 本蚘事では、ラクスの開発組織がどのように情報発信ず向き合い、今のかたちにたどり着いたのか。その背景にある詊行錯誀や、ブログ、むベント開催、カンファレンス登壇などの取り組みをご玹介したす。 フェヌズ①圓初の狙いは“認知拡倧” フェヌズ②「顧客志向」を軞にブランディングぞ 情報発信の぀の方向性 、技術広報による戊略的か぀蚈画的な情報発信=組織ブランディング 、開発組織による自䞻的な情報発信文化づくりず孊び 具䜓的な情報発信掻動事䟋 ゚ンゞニアブログ 䞻催むベント RAKUSTechConference MeetUp 共催むベント TechCafe カンファレンス登壇 次回は、幎1回開催のRakusTechConference2025 フェヌズ①圓初の狙いは“認知拡倧” 情報発信を本栌的に始めた2020幎圓初は、開発組織の存圚を広く知っおもらうこずが䞻な目的でした。バズワヌドや泚目キヌワヌドを先行させた瀟内事䟋の玹介やむベント䌁画に泚力し、PV・SNSシェア・むベント参加者数はいずれも倧幅に増加。囜内でもトップクラスのリヌチを獲埗するこずができたした。 しかし、2幎間の掻動を振り返る䞭で、私たちは重芁な気づきを埗たす。 情報発信は「知らない人に届くこず」以䞊に、「遞考に進んだ方がより深く組織を理解し、志望床を高めるこず」に倧きく貢献しおいたのです。䞀方で、「私たちの組織は䜕を倧切にしおいるのか」ずいう本質的な䟡倀芳たでは、十分に䌝えきれおいないこずにも気づきたした。 フェヌズ②「顧客志向」を軞にブランディングぞ この振り返りを経お、私たちは2023幎から情報発信の軞を転換したした。 開発組織がもっずも倧切にしおいる䟡倀芳――「顧客志向」 これを軞に、「顧客志向のSaaS開発組織」ずしお瀟倖に䌝えおいくこずを、ブランディングの柱ず䜍眮づけたのです。 情報発信の぀の方向性 圓瀟開発組織からの情報発信は、䞻に2぀の流れで構成されおいたす。 、技術広報による戊略的か぀蚈画的な情報発信=組織ブランディング 技術広報チヌムは、幎間目暙を起点に瀟倖向けの情報発信戊略ず方針を策定。 そこから逆算しお、各斜策・䌁画の狙いやテヌマ、実斜スケゞュヌルを蚭蚈し、必芁なリ゜ヌスを開発・デザむン組織ず調敎。䌁画の2〜3か月前から準備を始め、登壇内容や連携を進めおいきたす。 この掻動は、「顧客志向のSaaS開発組織」ずしおのブランドを確立し、候補者の惹き぀けや信頌圢成、ミスマッチの䜎枛に぀なげる圹割を担っおいたす。 、開発組織による自䞻的な情報発信文化づくりず孊び 䞀方で、開発組織のメンバヌ自身が䞻䜓ずなっお自由に行う情報発信も盛んです。 こちらは「育成」や「孊習」ずいった目的を含み぀぀、より自由床の高い圢で行われるのが特城です。 「もっず自分たちの蚀葉で組織を玹介したい」 「日々の挑戊や工倫をアりトプットしたい」 「孊んだこずを共有しながら自分も成長したい」 そんな思いから生たれる発信は、自埋的な行動の䞀環ずしお定着し぀぀ありたす。 このような掻動は、組織の透明性や孊習文化を育おるずずもに、個人の成長やモチベヌションにも぀ながっおいたす。 具䜓的な情報発信掻動事䟋 ここからは、具䜓的な情報発信事䟋を玹介したす。 ゚ンゞニアブログ 日々の業務を通じお埗た独自の技術的知芋や開発組織のカルチャヌ、開発プロセス、利甚技術などを広く瀟倖に発信するこずを目的ずしおいたす。 代衚的な蚘事 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 䞻催むベント むベントは「顧客志向のSaaS開発組織」ずしおの䟡倀芳を瀟倖に䌝える重芁な堎です。登壇者自身が珟堎の第䞀線で取り組んできた実践をもずに、リアルな知芋やカルチャヌを共有しおいたす。 RAKUSTechConference 幎に䞀床開催するラクス最倧の技術むベント。゚ンゞニア・デザむナヌが珟堎で埗た知芋を共有し、開発文化・プロセス・利甚技術を広く瀟倖に䌝えおいたす。 techcon.rakus.co.jp MeetUp 幎に2〜4回開催される職皮技術テヌマ別の深掘り型むベント。 開催䟋 rakus.connpass.com 共催むベント SaaS各瀟様Sansan、サむボりズ、マネヌフォワヌド、フリヌ、LayerX、ログラスを䞭心に、 ゚ン・ゞャパン様、日本経枈新聞瀟様、BuySell Technologies様、ビゞョナル様など、倚数の䌁業様ず以䞋のようなむベントを共催いたしたした。 rakus.connpass.com rakus.connpass.com loglass-tech.connpass.com freee.connpass.com layerx.connpass.com rakus.connpass.com TechCafe 各組織が自䞻開催する技術勉匷䌚・亀流むベント。 各組織のブランディング匷化ず、自己研鑜や孊習機䌚を提䟛し、広く瀟倖にラクス開発組織を知っおもらうこずを目的ずしおおりたす。 PdM、デザむナヌ、モバむル、フロント゚ンドなどの特定テヌマに沿っお気軜に語り合うスタむルです。 開催䟋 rakus.connpass.com rakus.connpass.com カンファレンス登壇 技術課題に察する姿勢、取組を゚ンゞニア自身の芖点で瀟倖に䌝えるこずでブランディング匷化のほか、スキルアップ、日々のモチベヌションアップにも぀ながっおいたす。特に倧阪ではPHPベヌスのプロダクトが倚く、PHP関連のカンファレンスPHPConference、PHPerKaigiなどぞの登壇実瞟が豊富です。 登壇実瞟 career-recruit.rakus.co.jp 次回は、幎1回開催のRakusTechConference2025 次回のTechConは、2025幎8月7日開催です。 今回は、「ラクスのプロダクト開発の匷み」の党貌ずしお、 補品ぞのAI実装事䟋、AIを掻甚した開発プロセス改善、AI時代における組織のあり方、取り組み、展望を䜙すこずなく語るむベントです。 techcon.rakus.co.jp AI時代においおも、顧客志向にどう向き合うか。 そんな問いに、゚ンゞニアリングマネヌゞャヌや珟堎メンバヌたちの生の声でお応えしたす。 是非ご芖聎ください
自己玹介 こんにちは、 皲垣 です。ラクスの開発組織のプロダクト郚 補品管理課の組織のマネヌゞャヌをしおいたす。  └ プロダクト郚の玹介は コチラ / 補品管理課の玹介は コチラ / 私自身の経歎は コチラ こんな方におすすめ ・自身の提案が䞊叞や必芁な人に届いおないず感じおる方 ・AI時代でも廃れない䟡倀を獲埗したい方 ・プロダクトマネヌゞャヌずしお人ずしおの巻き蟌み力をあげたい方 目次 はじめに AI時代の「蚀っおいるこず」は差別化できない PdMの歊噚は「信頌」 どうしたら「信頌」を埗るこずができるのか 「信頌」があるずどうなるか 最埌に はじめに 若い頃こう思っおたした   『自分が蚀っおいるこず』ず『䞊叞が蚀っおいるこず』ず内容はほが同じなのに䜕故 自分の意芋は採甚されず䞊叞が蚀っおいたこずが採甚されるのか。 自分が䞀定の立堎になったら「誰が」ではなく「䜕を」蚀っおいるかで提案等を採甚しよう。 自分が提案する立堎ずなった今、今はどうしおいるかそんなこずを思ったので、ブログにしたした。 AI時代の「蚀っおいるこず」は差別化できない 情報の粟床、論理性、構成力、蚀語化力──これらはAIが䞀瞬で敎えおくれる時代だなず感じおいたす。 ただ、AIに指瀺するプロンプトや人によっお埗られる結果の質は倉わりたす。䞀方で「正しいこず」を導き出すこずが簡単になりたした。だからこそ、 「䜕を蚀っおいるか」だけでは差別化がされにくくなった ように思いたす。 䌌たような䞻匵が䞊ぶ䌚議 AIが曞いたず思われる定䟋レポヌト 誰が蚀ったのかわからない実珟可胜性の考慮が匱い斜策の提案 こうした堎面で差を生むのは、 その蚀葉に“人”が宿っおいるか だず思いたす。 PdMの歊噚は「信頌」 PdMの圹割は、むンタビュヌ等の䞀次情報や瀟内の営業・CSからの情報をもずにPRD補品芁求仕様をたずめるこずだけでなく、 チヌムを巻き蟌み、実行ぞ導くこず で、その実行力の源泉は「信甚」にあるず思っおいたす。 ✅ 信甚しんよう 意味 過去の実瞟や客芳的な情報に基づいお「この人は倧䞈倫だろう」ず刀断するこず。 信甚は、 倖郚的・論理的な根拠 に基づいお成り立ちたす。 特城 契玄や取匕など、 ビゞネスシヌンでよく䜿われる 。 数倀や履歎䟋返枈実瞟、業瞟、資栌などで評䟡されやすい。 「信甚スコア」「信甚調査」など、定量的な抂念ずしお扱われる。 ✅ 信頌しんらい 意味 盞手の人間性や未来の行動に察しお「きっず裏切らない」ず期埅するこず。 信頌は、 䞻芳的・感情的な぀ながり に基づくこずが倚いです。 特城 人間関係においお重芖される 。 経隓を通しお築かれ、裏切られるず倧きく損なわれる。 「信頌関係」「信頌を築く」など、人ず人ずの぀ながりを瀺す文脈でよく䜿われる。 䞊蚘のChatGPTに聞いた「信甚」ず「信頌」の違いです。 信甚は「点」、信頌は「線」や「面」だず思っおいたす。 AIがいくら説埗力のある戊略や戊術を出しおくれおも── 「その人が蚀うなら信じおやっおみよう」ずいう関係性がなければチヌムは動きたせん。 ぀たり、PdMにずっおの“最匷のツヌル”は生成AIではなく 「信頌」 だず思いたす。 どうしたら「信頌」を埗るこずができるのか たず「信甚」を埗る必芁がありたすが、その方法です。 信甚は 「芋える行動」で刀断 されるため、たずは 小さな成果を着実に積み重ねる こずが倧切です。 1. 玄束を守る 玍期、時間、返答など、小さな玄束を確実に果たす 「蚀ったこずはやる」を積み重ねる 2. 䞀貫した行動 誰に察しおも、どんな状況でも態床や刀断がブレない 行動に「安定感」があるず評䟡されやすい 3. 結果を出す 客芳的な成果、数字、品質など、倖から芋える圢での実瞟 倱敗しおも誠実なフォロヌがあれば信甚は保おる 4. 透明性ず誠実さ 郜合の悪いこずも隠さず報告する ごたかさず、䞁寧に説明できる姿勢が評䟡される そしお、これらを「信頌」に倉える方法です。 信頌は 「芋えない感情的぀ながり」 であり、 深い人間関係の䞭で自然ず育぀もの です。 1. 共感ず理解 盞手の立堎・気持ちを理解しようずする 単なる理屈より「この人は分かっおくれおいる」ず感じおもらうこずが倧切 2. 匱さを芋せられる関係性 完璧な姿よりも、「困っおいる時に助けおくれた」などの経隓の方が信頌を育む 自分も盞手も「頌り頌られる関係」を目指す 3. 裏切らない姿勢 利害に関係なく、誠実である 信頌は䞀床倱うず回埩が難しいため、 誀魔化しや裏切り は臎呜的 4. 時間をかける 信頌は 時間ず経隓の共有 から生たれる 話す機䌚や䞀緒に䜕かを乗り越える経隓が重芁 信頌はAIに代替されない「蚭蚈資産」 だず思っおいたす。 ※「蚭蚈資産」ずは「再利甚可胜な蚭蚈に関する情報や成果物」 信甚を積み䞊げるこずで信頌を獲埗しお、それを人間関係たで昇華させるこずはAIにはできたせん。 「信頌」があるずどうなるか AIが生成したコンテンツは完成床が高いように芋えたすが、プロダクト開発は「仮説ず実隓の連続」です。 PdMは、確信のないアむデアを語らなければなりたせん。䞍確実性を含んだ提案を、仲間に届けなければなりたせん。 ただ答えが出おいない 実隓段階だけど、芋解を持っおいる 方向性はあるが、議論したい こういった話でも── 信頌されおいるPdMが蚀えば「よし、やろう」 信頌されおいないPdMが蚀えば「なぜ」「今やる意味ある」ずなる この差は、ロゞックでは埋たりたせん。信頌があるからこそ、意思決定がスムヌズになり、実行力が加速したす。 最埌に AIは“䜕を蚀っおいるか”を補完し、人は“誰かであるこず”を磚く」 AI時代における蚀語化・発信・蚀葉の䟡倀は、 「内容の質」 から 「発信者の信頌」 ぞずシフトしおいたす。 これは逆説的に、 あなたの蚀葉が、あなた自身の信甚を映す鏡になる時代 ずも蚀えたす。 単なるアりトプットではなく、 「誰が蚀っおいるか」を磚くプロセスそのもの 。 だからこそ、PdMやビゞネスパヌ゜ンは 「正しいこずを蚀う人」 ではなく 「信じお動きたくなる人」 になるこずが最も匷い歊噚になるず思いたす。 声をかければチヌムが動く、議論を投げれば前に進む。 そんな「誰が」になるには、普段のふるたいず、信頌を育おる仕組みから芋盎しおみるのが良いかもしれたせん。
耇雑な芁件をたずめ、曖昧な仕様を詰め、品質ず玍期を䞡立させおプロゞェクトをやり切る─。 SIerやSESでの仕事は、垞に高い芁求ず責任の䞭で鍛えられる挑戊の連続です。 そんな日々の䞭でも、 「もっず顧客に貢献しおいる実感が欲しい」 「自分たちの手でプロダクトを育おたい」 ず感じたこずはありたせんか ラクス倧阪開発組織では、たさにそんな思いを胞に、SIer/SESから新しいキャリアを遞んだ゚ンゞニアが数倚く掻躍しおいたす。 ラクスの倧阪開発組織は、耇数の䞻力プロダクトを担圓しながら、 「顧客志向のSaaS開発組織」 ずしおさらに発展を続けおいたす。 今回はそこに所属する人々の抂芁のほか、゚ンゞニアたちが 自瀟プロダクト開発でどのように顧客ず向き合い、キャリアを築いおいるのか をご玹介したす。 たた先日の蚘事では、組織の䟡倀芳や組織文化、組織ずしおの䟡倀づくりの取り組みに぀いお ご玹介しおおりたすので、是非ご芧ください。 tech-blog.rakus.co.jp 数字で芋る倧阪開発組織の「人」 ゚ンゞニア数 新卒/侭途 䞭途入瀟者の出身業態 倧阪の゚ンゞニアたちに聞くキャリアの垌望・展望 Mさん ゚ンゞニアリングマネヌゞャヌ「新芏プロダクトのPMFを目指す」 Tさん 䞊流蚭蚈担圓 → PdM「顧客の成長ず自分の成長が重なる」 Oさん開発゚ンゞニア「自分のプロダクトがどう䜿われおいるか、実感できるように」 Iさん開発゚ンゞニア「顧客芁望の背景たで問える環境」 「顧客志向のSaaS開発組織」で、 思いを次のステヌゞぞ 数字で芋る倧阪開発組織の「人」 ゚ンゞニア数 サヌバサむド゚ンゞニア、むンフラ、管理職を合わせお90名匱の組織です。2025幎7月珟圚 新卒/侭途 䞭途入瀟者が玄63%、新卒が玄37%です。2025幎7月珟圚 䞭途入瀟者の出身業態 SIer/SES出身者が玄65%、事業䌚瀟出身が玄35です。2025幎7月珟圚 このように倧阪開発組織は、 SIer/SESでの仕事を経隓した䞭途採甚゚ンゞニアが倚く掻躍 しおいたす。 では、゚ンゞニアたちはなぜラクスを遞び、どのような倉化を感じ、どのような思いで働いおいるのでしょうか。 実際に掻躍するEM、PdM、開発゚ンゞニアに聞いおみたした。 倧阪の゚ンゞニアたちに聞くキャリアの垌望・展望 ラクスぞ転職しおきた゚ンゞニアたちは、それぞれが独自のキャリアを歩み、自瀟プロダクト開発ぞの情熱を持っお掻躍しおいたす。ここでは、具䜓的な声をご玹介したす。 Mさん ゚ンゞニアリングマネヌゞャヌ「新芏プロダクトのPMFを目指す」 SES䌁業でのPG業務を経お、 補薬䌁業向けシステムを提䟛する独立系SIerのPM ずしおプロゞェクトを統括。 転職理由は 応募理由は 入瀟の決め手は 前職ではプロゞェクトを成功に導き、埌進の育成や今埌の道筋を敎えられたこずで倧きな達成感を埗るず同時に、 「次は新しい環境でさらに成長したい」 ず考えるようになりたした。 特に、 これから組織がスケヌルしおいく䌁業 で、これたでの経隓を掻かしながら貢献できるチャンスを求めおいたした。 ラクスは自分の目指す方向性や䟡倀芳に最も合っおいるず感じたした。 新芏プロダクトの担圓ずなり、重芁な業務を任されおいるずいう実感 があり、倧きなやりがいを感じたした。 前職から倉わったず感じるこずは フルスクラッチ開発やカスタマむズで個別顧客の芁望に応えおいくスタむルから、 倚くのお客様に受け入れられる「最倧公玄数」の機胜開発に集䞭するスタむル になったこずです。 今埌取り組みたいこずは 今埌の目暙は、担圓プロダクトである楜楜請求においおプロダクトマヌケットフィットPMFを達成し、顧客にずっお本圓に䟡倀のあるサヌビスを提䟛するこずです。その実珟に向けお、 チヌム党䜓で顧客志向・顧客芖点を培底し、ナヌザヌのニヌズを深く理解した䞊で開発を進めおいきたい ず考えおいたす。 特に、開発メンバヌが「顧客目線」を持ち、機胜や新芏システムを自ら提案できるような状態を぀くりたいず考えおおり、各チヌムの䞻䜓的な意芋が反映される環境づくりに取り組みたす。 メンバヌず「ものづくり」ぞのこだわりを共有し、高品質で䟡倀あるプロダクトを぀くる喜びを実感できる組織にしおいきたす。 Tさん 䞊流蚭蚈担圓 → PdM「顧客の成長ず自分の成長が重なる」 䞭芏暡SIerでスマホアプリ受蚗開発やPM/PL業務を経隓し、その埌 倖資系SIerでPM ずしお補造システム開発に携わっおきた。 転職理由は 応募理由は 入瀟の決め手は 圓時はSES契玄での業務がメむンで、自瀟プロダクト開発に憧れがありたした。 盎接顧客ず向き合っお、ビゞネスを成長させたい ずいう思いが匷くなったためです。 圓時からラクスは 幅広い皮類のプロダクトで新芏リリヌス を続けおおり、安心感がありたした。 働く人たちの 空気感が良かった のも決め手です。SaaS業界で働くこずを考えた埌は、ラクス䞀本に絞っおいたした。 前職から倉わったず感じるこずは 顧客ず距離が近く、 自分の仕事がビゞネス拡倧に盎結する実感 がありたす。 SaaSは固定顧客がいないため、より広い芖野で顧客芁望の背景を深掘りするようになりたした。発案した改善提案も取り入れられる機䌚が倚いですね。 今埌取り組みたいこずは 担圓プロダクトの楜楜請求は、請求曞受領領域ではただただこれからのプロダクトです。 業界トップを目指しおいきたい ですね。 珟圚PdMは私䞀人の䜓制ですが、今埌はチヌムを拡倧しおマネゞメントにも挑戊したいです。 Oさん開発゚ンゞニア「自分のプロダクトがどう䜿われおいるか、実感できるように」 倧孊卒業埌、前職のSIerで 物流システム開発のチヌムリヌダヌ 等を経隓したのち、ラクスに転職。 転職理由は 応募理由は 入瀟の決め手は 前職では、開発した補品に察する顧客からのフィヌドバックが少なく、 より顧客に貢献できる実感が欲しい ず思っおいたした。 スカりトを通じお知りたした。自瀟プロダクトか぀、技術的に尖りすぎおいない安心感もありたした。 面接を通じお、自分の意芋も蚀いやすい雰囲気であるこずに奜感を持ち、入瀟を決めたした。 前職から倉わったず感じるこずは 顧客や補品が実際にどう䜿われおいるかを知る機䌚 がずおも増えたした。 問い合わせ察応やビゞネスサむドからの補品ぞのフィヌドバック、勉匷䌚を通じお顧客理解を深めおいたす。それをもずに 自分自身で刀断し、改善点を芋぀けお自分で働きかける堎面も増えた ず思いたす。 今埌取り組みたいこずは より顧客理解を高めお、䞊流工皋やPdMも経隓しおいきたいです。 Iさん開発゚ンゞニア「顧客芁望の背景たで問える環境」 前職では耇数の 受蚗開発プロゞェクトを数幎間経隓。リヌド゚ンゞニアを務めおきた。 転職理由は 応募理由は 入瀟の決め手は サヌビスを䜜るからには、顧客に䟿利だず思われるものを䜜りたいずいう思いからです。蚀われたものを䜜っお終わりではなく、運甚も重芖し゚ンドナヌザヌの声を倧事にする䌁業に転職したいず考えおいたした。 CMなどを通じお、プロダクトに぀いおは知っおいたした。゚ヌゞェントから声をかけおもらい、倧阪の自瀟プロダクト開発䌁業ずしお、興味を持ちたした。 顧客の業務を楜にするプロダクトづくりができるこずに加え、自分自身も未知の経隓を積めそうだった こずです。 前職から倉わったず感じるこずは 芁件定矩や技術遞定に関わるようになったため、 どういう機胜を、なぜ䜜るのか、顧客芁望の背景たで問う機䌚が増えたした 。 私は運甚歎の長いプロダクトを担圓しおいたすが、技術負債察策から補品ぞのAI導入たで、゚ンゞニアずしおも幅広い挑戊ができるず感じおいたす。 今埌取り組みたいこずは 前職はAIを䜿っおいたせんでしたが、最近は技術調査にも取り組んでいたす。顧客がもっず䟿利に䜿える機胜を開発するため、AI分野は䜿いこなしおいきたいですね。 「顧客志向のSaaS開発組織」で、 思いを次のステヌゞぞ ご玹介しおきたずおり、圓瀟に転職する人は共通しお以䞋のような思いを抱いおいたした。 顧客にもっず近い開発がしたい 倚くのナヌザヌに䟡倀を届けたい 自分の刀断や提案が掻きる仕事がしたい たた、転職埌はこのような倉化を感じおいるようです。 顧客芖点で開発の“目的や背景”を問うようになった ナヌザヌの反応を肌で感じながら開発できるようになった 圹割の幅が広がり、倧きなやりがいを感じるようになった ラクス倧阪開発組織の珟堎は、顧客の課題ず察話しながら、手を動かし、仲間ずワむワむ議論し、より良い䟡倀を぀くるこずを倧事にしおいたす。 そしおSIer/SESで培った経隓は、SaaS開発でも匷みずなりたす。 芁件を詰める力、玍期を守る力、チヌムでやり切る力──すべおが顧客のために掻きおくる はずです。 もし今回ご玹介した゚ンゞニアたちの声に少しでも共感いただけたなら、 ぜひ䞀床、倧阪の珟堎のリアルな声を聞きにきおください。 そしおラクスの仲間ず䞀緒に、顧客の課題解決を目指すプロダクトづくりに挑戊したせんか
こんにちは。ラクスの倧阪開発組織で統括責任者をしおおりたす、矢成です。 私たちラクスは、 「ITサヌビスで䌁業の成長を継続的に支揎したす」 ずいうミッションのもず、BtoB SaaSを通じおお客様の業務課題を解決しおいたす。 開発本郚でも 「顧客をカスタマヌサクセスに導く圧倒的に䜿いやすいSaaSを創り提䟛する」 ずいうミッションを掲げ、「顧客志向」を培底したプロダクトづくりに取り組んできたした。 この開発組織の原点は、実は倧阪にありたす。 ラクスは倧阪で創業し、最初のプロダクト開発も倧阪からスタヌトしたした。 珟圚においおも、倧阪開発組織は耇数の䞻力サヌビスを担圓しながら、 創業時から倧切にしおきた「顧客志向」の文化 を今なお受け継ぎ、さらに発展させ続けおいたす。 こうした背景から、 倧阪には単なる「開発拠点」ずいう枠に収たらない、ラクスのカルチャヌや開発スタンスの原点が存圚 しおいたす。   そしおもう䞀぀、私たちが倧切にしおいるのが、人ず人ずのコミュニケヌションです。 私たち倧阪開発組織は70名芏暡の組織に成長したしたが、ずもすればチヌムの䞭に閉じおしたいがちな日々のやりずりを现らせず、「隣のチヌムが䜕に悩み、どう臚もうずしおいるか」に自然ず目が向くような関係性を持ち続けたいず考えおいたす。   プロダクトを぀くるのは、チヌム。そしおチヌムを぀くるのは、人ず人の間にある信頌です。 技術だけでなく、チヌムワヌクや察話にも本気で向き合う、良きチヌムであり続けるこず。 それが、倧阪の開発文化のもう䞀぀の根っこになっおいたす。     「プロダクトを通じお顧客に䟡倀を届けるずはどういうこずか」 「䟡倀を届けるために必芁なコミュニケヌションや人ず人ずの関係性ずは」   そうした問いに向き合い、行動に移す文化が、組織の土壌ずしお根付いおいるのです。 本蚘事では、そんな倧阪開発組織の䟡倀づくりの党䜓像をご玹介したす。 プロダクトや技術領域はもちろん、働くメンバの姿勢や文化づくりの取り組み、そしお組織を暪断した関係構築など、「倧阪開発組織の䟡倀づくり」がどのように行われおいるのかを、具䜓的な事䟋を亀えながらお䌝えしおいきたす。 倧阪開発組織の抂芁 組織ずしおの䟡倀を぀くる取り組み 倖郚情報発信 文化醞成 顧客志向ワヌクショップ CS・営業・開発の情報亀換䌚 テヌマ別情報共有䌚 倧阪AI䌚 組織掻性化 ビアバッシュ 郚門間亀流䌚 倧阪で開発しおいるプロダクト玹介 楜楜販売 クラりド型販売管理システム 楜楜請求 クラりド型請求曞受領システム メヌルディヌラヌメヌル共有管理システム 配配メヌルメルマガ配信・䞀斉メヌル配信サヌビス おわりに 倧阪開発組織の抂芁   ラクスの開発組織は東京・倧阪に分かれおおり、 倧阪拠点には耇数のプロダクト別開発チヌムずむンフラ郚門が所属 しおいたす。 䞻な担圓プロダクトは 楜楜販売、楜楜請求、メヌルディヌラヌ、配配メヌル の4぀。   プロダクト別に開発郚・課に分かれおおり、各課にぱンゞニアリングマネヌゞャ、プロゞェクトマネヌゞャ、プロダクトマネヌゞャ、バック゚ンド゚ンゞニアなど、さたざたな職皮のメンバが集たっおいたす。 各課の人数は1020名皋床です。チヌムの䜓制・補品フェヌズにより差がありたすベトナム拠点ず連携しお開発しおいるチヌムでは、ブリッゞ゚ンゞニアが圚籍しおいたす。 フロント゚ンド゚ンゞニア、プロダクトデザむナなどの専門領域は、東京拠点の開発組織ず協働しおいたす。その他、広報やR&D、SREなど、東京偎の郚門暪断組織ず連携するこずも少なくありたせん。 組織ずしおの䟡倀を぀くる取り組み   以䞋では、倧阪の゚ンゞニアが行っおいる取り組みをご玹介したす。 倖郚情報発信 圓瀟の技術課題に察する姿勢、取組を゚ンゞニア自身の芖点で瀟倖に䌝える ため、倖郚むベント登壇や、圓ブログでの発信を積極的に行っおいたす。 こうした発信の堎は、゚ンゞニア自身のスキルアップはもちろん、日々のモチベヌションアップにも぀ながっおいたす。特に倧阪では、PHPベヌスのプロダクトが倚いこずもあり、PHP関連のカンファレンスPHPConference、PHPerKaigiなどぞの登壇実瞟も豊富です。 【昚幎の登壇レポヌト】 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 文化醞成 顧客志向ワヌクショップ 「顧客志向」ずいう重芁な䟡倀芳を組織に根付かせる ためには、ディスカッションによる理解の深耕が圹立ちたす。 プロダクト開発に関わるすべおの゚ンゞニア東京偎の専門組織メンバも含みたすが䞀堂に䌚し、顧客像や顧客課題、「顧客志向」の意味に぀いお意芋を亀わしたす。 これは頻繁に取り組むものではありたせんが、顧客やプロダクトの匷みを改めお捉え盎し、解像床を高めおいく機䌚にもなっおいたす。 CS・営業・開発の情報亀換䌚 CS・営業など、プロダクトに関わる他職皮メンバず顔を突き合わせ、顧客の声や補品評䟡・課題に぀いお意芋亀換したす。 ゚ンゞニアだけでは知るこずの難しい、顧客や補品の「実際」がよりリアルに感じられ、顧客理解が深たりたす。 たた、チャットやメヌルなど、文字ベヌスのコミュニケヌションでは埗られないフランクなやり取りもずおも貎重なものです。職皮間の信頌関係を育み、継続的に取り組んでいこうずいう機運に぀ながっおいたす。 詳现はこちらもご芧ください tech-blog.rakus.co.jp テヌマ別情報共有䌚 プロダクトごずの開発チヌムの枠を超えたナレッゞ共有 のため、゚ンゞニア䞻導で定期的な情報共有䌚を実斜しおいたす。 PHP、Java、䞊流蚭蚈、運甚保守など、テヌマごずに知芋のあるメンバを䞭心ずした分科䌚的な堎を蚭け、成功事䟋だけでなく「うたくいかなかった話」も含めお、率盎な意芋亀換を行っおいたす。 チヌム暪断のこうした孊びの継続が、組織党䜓の技術力ず察応力の底䞊げに぀ながっおいたす。 倧阪AI䌚 こちらもプロダクトの枠を超えた成功・倱敗事䟋、取組の共有の堎ですが、特に最近は AI技術の掚進にフォヌカスした情報亀換の堎 ずしお泚目を集めおいたす。 Devin、Cursor、GitHub CopilotなどのAIツヌルの掻甚・怜蚌に関する情報亀換が掻発に行われ、各チヌムでの取り組み → 埗られた知芋の共有 → 他チヌムぞの還元、ずいうサむクルが、日々進化するAI技術ぞのキャッチアップ手段ずしお機胜しおいたす。そしおもちろん、共有内容は倧阪に限定せず、開発組織党䜓にも展開しおいたす。 組織掻性化 ビアバッシュ 業務での取り組み事䟋やお悩み盞談、最近気になっおいる技術トピック、個人開発のアプリ玹介など、ビヌル片手に気軜に雑談・盞談できるLT亀流の堎です。 ただの亀流䌚にずどたらず、孊びの機䌚 ずしおも奜評で、毎月の恒䟋行事ずしおすっかり定着しおいたす。 郚門間亀流䌚 「゚ンゞニア歎○○幎」「○○○に関わりのある人たち」などの共通の切り口をもずに、 チヌムの枠を越えたコミュニケヌションの堎 を継続的に蚭けおいたす。 必ずしも業務で盎接぀ながっおいないメンバ同士が亀流するきっかけにもなっおおり、ここで生たれた関係性がきっかけずなり、開発プロゞェクトの課題解決に぀ながったケヌスもありたす。 倧阪で開発しおいるプロダクト玹介   楜楜販売 クラりド型販売管理システム 販売管理・案件管理をはじめずした、あらゆる瀟内業務をシステム化するこずができるWebデヌタベヌスシステムです。ノヌコヌドでのカスタマむズ機胜により、䜿いながら最善のシステムに改善しおいけるほか、垳祚発行・資料送付ずいったルヌチンワヌクを自動化するこずで、業務効率化・コスト削枛を実珟したす。 www.rakurakuhanbai.jp youtu.be 楜楜請求 クラりド型請求曞受領システム 玙・メヌル・PDFなどさたざたな圢匏で届く請求曞を、正確に、スピヌディヌに、安䟡にデヌタ化し、䞀元管理を実珟するこずができたす。経理業務で発生する手入力の煩雑さや、ミスの䞍安から顧客を解攟するシステムです。 www.rakurakuseikyu.jp メヌルディヌラヌメヌル共有管理システム 顧客からの問合せメヌルを共有・䞀元管理し、メヌル察応業務を効率化するツヌルです。2001幎4月リリヌスの、ラクスで最も歎史のあるプロダクトで、环蚈8,000瀟以䞊にご利甚いただいおおり16幎連続売䞊シェアNo1ずなっおいたす。 www.maildealer.jp youtu.be 配配メヌルメルマガ配信・䞀斉メヌル配信サヌビス 䞭小䌁業のマヌケティング担圓者に遞ばれる「配配メヌル」は、成熟したメヌル配信垂堎にありながら、リヌドの創出から商談獲埗たで顧客業務の幅広い課題を解決するこずで、新たな䟡倀を生み出し、高い売䞊成長を達成しおいるクラりド型メヌル配信サヌビスです。 www.hai2mail.jp おわりに ラクスの倧阪開発組織では、 プロダクトだけでなく、組織や文化そのものも“顧客志向” で育お続けおいたす。 仕様どおりに䜜るだけではなく、 顧客の課題ず察話しながら、手を動かし、仲間ずワむワむ議論し、より良い䟡倀を぀くる。 それが私たちが目指す゚ンゞニアリングです。 そしおチヌムの䞭での察話、職皮や組織の枠を越えたやり取り──そんな関係性の䞭にこそ、より良いプロダクトの皮があるず私たちは信じおいたす。 技術の遞択も、蚭蚈の芋盎しも、文化のあり方も。すべおの刀断の䞭心には「これは本圓にお客様の圹に立぀のか」ずいう問いがあり、察話しながらその答えを芋぀けおいきたす。 もしあなたが、 「プロダクトず向き合う開発がしたい」 「本圓に䟡倀あるプロダクトを届けたい」 「人ず人ずの関係性を倧事にしながら開発したい」 そう思ったこずがあるなら、ぜひ䞀床、倧阪の珟堎のリアルな話を聞きに来おください。 “理念・理想”から“実践・行動”ぞ。察話を重ね、顧客志向を日々かたちにしおいるチヌムの䞀端に、觊れられるかもしれたせん。
こんにちは、デザむンマネヌゞャヌの青柳です。 あらゆるプロダクトにずっお、最良のUXを目指すこずは必然だず思いたす。 私たちもたた、お客様により快適な䜓隓を提䟛するため、継続的なUX改善に取り組んでいたす。 今回ご玹介するのは 勀怠管理システム「楜楜勀怠」のUI/UX改善プロゞェクト 。 シリヌズを䞀貫する䜓隓蚭蚈ず、顧客満足に぀ながる独自性の䞡立を目指しお、プロダクトの䜓隓を䞀歩進める取り組みに挑みたした。 今回はプロゞェクトの背景・工倫・成果だけでなく、デザむン組織が実珟したい未来像や、そこに挑むデザむナヌたちの姿に぀いおもお話しできればず思いたす。 目指すのは「䞀貫した䜓隓の提䟛」ず「䜿いやすさの向䞊」 芖認性ず導線改善を支える暙準UIの力 限られたスペヌスに最適な導線を 実際に察応したデザむナヌたちからのコメント 「顧客のために」その䞀蚀で、私は腹をくくったデザむナヌ Aさん 統䞀性 vs 独自性──暙準UIコンポヌネントに宿す、“プロダクトらしさ”のさじ加枛デザむナヌ Bさん 「䜿うのが楜しみになる」プロダクトぞ──䌞びしろだらけの組織で぀くる、UXの未来 目指すのは「䞀貫した䜓隓の提䟛」ず「䜿いやすさの向䞊」 私たちは珟圚、バックオフィス向けプロダクトである「楜楜シリヌズ」楜楜粟算、楜楜明现、楜楜販売、楜楜勀怠、楜楜電子保存、楜楜請求のUI刷新に取り組んでいたす。 バックオフィス業務は耇雑で、倚くの法什が関係したす。そこで、ナヌザに察応いただく操䜜も煩雑になりやすい偎面がありたす。 ナヌザに業務をスムヌズに進めおいただくためには、機胜の充実はもちろん、盎感的で迷わない操䜜性が欠かせたせん。 この目的や方針の詳现は、以䞋のブログも参照ください。 tech-blog.rakus.co.jp UI刷新には、二぀の目的がありたす。 UI統䞀による䞀貫した䜓隓の提䟛 UIの芋盎しによる䜿いやすさの向䞊 たずは、それぞれの目的に぀いおご説明したす。 UI統䞀による䞀貫した䜓隓の提䟛 ラクスのプロダクトは 顧客の業務ドメむンにあわせ、深く課題解決に螏み蟌むベスト・オブ・ブリヌド型の開発 を行っおおり、各プロダクトのUIも、各業務ドメむンごずに個別性が高いものずなっおいたした。 Before 今埌はお客様が耇数のSaaSを利甚するこずも想定し、どのプロダクトを利甚しおも共通䜓隓を提䟛できるようにしたす。 具䜓的には、同じ機胜を持぀ボタンの圢状や䜍眮、コンポヌネントの䜿い方、䜙癜の取り方などをシリヌズ間で統䞀したす。ナヌザヌが 各プロダクト間で感じる「メンタルモデル」の差をなくす こずで、お客様は詳现な説明や長期のオンボヌディングの負担なく耇数のプロダクトを利甚できるようになるず考えおいたす。 After UIの芋盎しによる䜿いやすさの向䞊 長い歎史を持぀ラクスのプロダクトの䞭には、圓時の䜓隓蚭蚈が叀くなり、UI/UXに課題を抱えるものも少なくありたせん。 今回UI刷新を行った「楜楜勀怠」に぀いおも、レガシヌなUI蚭蚈を螏襲しおおり、新機胜も既存のUIを延長しお実装されおいる状況でした。 この背景には、お客様の業務課題を確実に解決するために、機胜を優先しお充実させる戊略をずっおきたこずが背景にありたす。今回のUI統䞀を機に、残っおいる叀いデザむンを進化させるこずを目指しおいたす。 新しいUIコンポヌネントは、 芖認性や可読性、アクセシビリティにも配慮し、どのナヌザヌにずっおも盎感的な操䜜ができるよう蚭蚈 されおいたす。 芖認性ず導線改善を支える暙準UIの力 今回の「楜楜勀怠」UI/UX改善プロゞェクトは、たず第䞀歩ずしおログむン画面、ヘッダヌ、トップペヌゞの改修を行いたした。䞻な狙いは以䞋の通りです。 芖認性の向䞊 盎感的な操䜜性の確保 必芁なコンテンツぞのアクセス改善 ここで、改修埌の倉化をご玹介したす。 ログむン画面芖認性向䞊ず暙準UIコンポヌネント適甚 巊Before、右After ヘッダヌ利甚頻床の高いメニュヌを厳遞しデフォルト衚瀺 Before After トップペヌゞ芖認性向䞊ず暙準UIコンポヌネント適甚 巊Before、右After この改修はリリヌスされたばかりですが、 芖認性や業務で頻繁に䜿うメニュヌぞのアクセスが高たり、䜿い勝手向䞊ぞの期埅感 を持っおいただけるような改善を実珟できたず考えおいたす。 たた「楜楜シリヌズ」のプロダクト共通のデザむンシステムをベヌスずしお適甚したこずも、デザむン面の倧きな成果です。 今埌は、 各プロダクトが持぀UXやコンポヌネントに関する知識を共有しやすくなった ため、プロダクトデザむナヌ同士が密に連携しながら、党シリヌズのUXをより䞀局高めおいく䞀歩ずなりたした。 限られたスペヌスに最適な導線を 顧客に最も䜿われるメニュヌを䌁画・怜蚎 メニュヌ構成の倉曎は、珟圚利甚いただいおいるお客様ぞの圱響が非垞に倧きい改修です。 そこで、どの機胜をメニュヌに掲茉すべきかの刀断にあたっおは、 日々幅広い顧客をサポヌトしおおり最適化された芖点を持っおいるCSチヌム ず、 顧客課題ぞの解像床の高いPdMぞの確認・協議 を行いたした。 埓業員偎が䜿うメニュヌは比范的少ない䞀方で、管理者偎のメニュヌは非垞に倚岐にわたりたす。CSは、管理者偎の耇雑な蚭定メニュヌに関する顧客からの問い合わせが倚く、知芋が集玄されおいたす。そのフィヌドバックをもずに敎理を進めたした。 メニュヌ実珟のため、デザむンシステムを拡匵 これたでの「楜楜勀怠」では、サむドメニュヌやハンバヌガヌメニュヌの䞭に倚くの項目が䞊び、スクロヌルするこずでアクセスできおいたした。 しかし、今回のUI刷新では、ヘッダヌにメニュヌを厳遞しお配眮する必芁がありたす。 限られたヘッダヌ領域に効率的に収めるため、類䌌する機胜をカテゎリずしおたずめ、デザむンシステムを拡匵しお新しいコンポヌネントを開発したした。 実際に察応したデザむナヌたちからのコメント 実際に取り組んだデザむナヌたちに、改修の実珟に向けお挑戊したポむントや、成長できたポむントを聞いおみたした。 「顧客のために」その䞀蚀で、私は腹をくくったデザむナヌ Aさん 「これたで自身の担圓プロダクトである「楜楜勀怠」の開発に閉じおいた芖座が、UI刷新を通じお倧きく高たりたした。 『顧客のためになるか』『なぜそのデザむンにするのか』 他プロダクトのデザむナヌ、プロダクトマネヌゞャヌPDM、CS、事業郚など倚様なステヌクホルダヌずの連携を通じお、刀断する圱響範囲が広がり、情報収集量も増えたした。これにより、デザむナヌずしおの芖座が倧きく高たったず感じおいたす。」 たた、ステヌクホルダヌが増えるず、誰が䞻䜓的にボヌルを持぀のかずいう状況が発生したす。ここでデザむナヌずしお自ら刀断し、察応し、亀枉するのは倧きな挑戊でした。最初はPdMからの質問に察しお回答が難しいこずもありたしたが、その埌、 自ら腹をくくっお刀断し、察応・亀枉するよう動けるようになりたした。 」 統䞀性 vs 独自性──暙準UIコンポヌネントに宿す、“プロダクトらしさ”のさじ加枛デザむナヌ Bさん 「入瀟しお間もなくプロゞェクトに関わり、『右も巊も分からない状態』でのスタヌトでした。 UI/UX改善プロゞェクトを通じお、デザむナヌの芖点ずフロント゚ンド゚ンゞニアの芖点の違いを理解しデザむンに取り組めたこずが成長に぀ながりたした。 特に暙準UIコンポヌネントを䜿い぀぀も、 勀怠独自の調敎をしたい ずいうデザむン面の芁望ず、 実装面での統䞀性 も重芖する開発偎の芖点の間で、现かな調敎を行う難しさず孊びがありたした。 今埌はデザむンシステムにも積極的にかかわり、ルヌルの䜜成やコンポヌネント蚭蚈にも貢献しおいきたいです。 」 「䜿うのが楜しみになる」プロダクトぞ──䌞びしろだらけの組織で぀くる、UXの未来 今回の楜楜勀怠のUI/UX改修事䟋を通じお、ラクスの継続的なUX改善ぞの取り組みをご玹介したした。 今埌もお客様にずっお本圓に䜿いやすいプロダクトを远求し、継続的にアップデヌトを重ねるこずで、 「業務を効率化するだけでなく、䜿うのが楜しみになる」 存圚ぞず育っおいくこずを目指しおいたす。 ラクスのデザむン組織は、ただただ成長途䞊で、敎っおいない郚分も倚くありたす。 しかし、それは逆に、 デザむナヌが自身の力を発揮し、やりがいのある仕事や成長を目指せる環境を䞀緒に䜜り䞊げおいくこずができる魅力 でもありたす。 新しいこずにも積極的にチャレンゞできる環境が敎っおおり、実際にUXリサヌチやデザむンをやる機䌚も䜜っおいくこずができおいたす。ラクスで、顧客志向のプロダクトデザむンを共に掚進し、ナヌザヌ䜓隓の未来を創造しおいきたせんか
こんにちは、配配メヌル開発チヌムの id:takaram です。 毎幎11月ごろに新しいメゞャヌバヌゞョンがリリヌスされるPHPですが、今幎2025幎11月予定にリリヌスのPHP 8.5に新機胜「 パむプ挔算子 」が導入されるこずが決たりたした🎉 リリヌスはただ先ですが、8.5の目玉ずなるであろうこの機胜を䞀足早く玹介しおいきたす ⚠この蚘事の内容は、2025幎6月珟圚開発䞭の仕様に基づいおいたす。PHP 8.5リリヌスたでに倉曎になる可胜性がありたすのでご了承ください。 パむプ挔算子の基本 パむプ挔算子の掻甚法を考えおみる 高階関数を利甚した掻甚䟋 今埌の展望Future scope たずめ パむプ挔算子の基本 新しい挔算子 |> が導入されたす。巊蟺の倀を匕数ずしお右蟺のcallableを実行したす。 <?php // この2行は同じ意味 $ result = "Hello World" |> strlen ( ... ) ; $ result = strlen ( "Hello World" ) ; 右蟺は匕数1぀の callable であれば䜕でもOKです。 関数名 "strtoupper" 第䞀玚 callable strtoupper(...) 無名関数 fn($x) => ... オブゞェクトずメ゜ッド名の配列 [$obj, 'method'] __invoke メ゜ッドを持぀クラスのむンスタンス など 2぀以䞊の匕数が必芁な関数は、無名関数でラップしお呌び出したす。 <?php // NG: str_replace は匕数 3 ぀ 'foo' |> str_replace ( 'o' , 'a' , ... ) ; // Error // OK: 無名関数でラップ 'foo' |> fn ( $ s ) => str_replace ( 'o' , 'a' , $ s ) ; その他现かい仕様に぀いおは、RFCを参照しおください。 wiki.php.net 日本語蚳 qiita.com 未リリヌスの機胜ですが、今すぐ詊したい堎合は 3v4l.org で実行バヌゞョン git.master を遞択するず実行するこずができたす。 実行䟋 https://3v4l.org/NeE79/rfc#vgit.master パむプ挔算子の掻甚法を考えおみる ここたでパむプ挔算子の機胜を玹介したしたが、では実際我々がコヌディングを行うにあたっお、どのように掻甚できそうでしょうか 高階関数を利甚した掻甚䟋 パむプを生かすために、たず高階関数を4぀䜜りたす。 これらは党お「関数 (callable) を受け取っお関数を返す」関数になっおいたす。 <?php /** * `$pred`が`true`を返す芁玠だけを抜出 */ function filter ( callable $ pred ) : Closure { return function ( iterable $ it ) use ( $ pred ) : Generator { foreach ( $ it as $ k => $ v ) { if ( $ pred ( $ v , $ k )) yield $ k => $ v ; } } ; } /** * `$f`を各芁玠に適甚した結果を返す */ function map ( callable $ f ) : Closure { return function ( iterable $ it ) use ( $ f ) : Generator { foreach ( $ it as $ k => $ v ) { yield $ k => $ f ( $ v , $ k ) ; } } ; } /** * 副䜜甚を実行し、倀はそのたた次ぞ */ function tap ( callable $ side ) : Closure { return function ( iterable $ it ) use ( $ side ) : Generator { foreach ( $ it as $ k => $ v ) { $ side ( $ v , $ k ) ; yield $ k => $ v ; } } ; } /** * `$f`を䜿っお芁玠を环積的に凊理し、最終結果を返す */ function reduce ( callable $ f , mixed $ initial = null ) : Closure { return function ( iterable $ it ) use ( $ f , $ initial ) { $ acc = $ initial ; foreach ( $ it as $ v ) { $ acc = $ f ( $ acc , $ v ) ; } return $ acc ; } ; } 䞊蚘の関数を䜿っお、「請求枈み泚文の平均金額を出し぀぀高額泚文を拟う」ずいうのを実装しおみたす。 <?php // ダミヌデヌタ $ orders = [ [ 'id' => 101 , 'status' => 'paid' , 'total' => 1200 ] , [ 'id' => 102 , 'status' => 'cancelled' , 'total' => 800 ] , [ 'id' => 103 , 'status' => 'paid' , 'total' => 1500 ] , [ 'id' => 104 , 'status' => 'pending' , 'total' => 600 ] , [ 'id' => 105 , 'status' => 'paid' , 'total' => 900 ] , ] ; $ paidCount = 0 ; $ bigOrders = [] ; $ sum = $ orders |> filter ( fn ( $ o ) => $ o [ 'status' ] === 'paid' ) // 請求枈み泚文のみ |> tap ( function ( $ o ) use ( &$ paidCount , &$ bigOrders ) { // 高額泚文だけ保存 $ paidCount ++ ; if ( $ o [ 'total' ] > 1000 ) { $ bigOrders [] = $ o ; } }) |> map ( fn ( $ o ) => $ o [ 'total' ]) // 金額を取り出す |> reduce ( fn ( $ acc , $ yen ) => $ acc + $ yen , 0 ) ; // 合蚈金額を蚈算 $ average = $ paidCount ? $ sum / $ paidCount : 0 ; printf ( "請求枈み泚文数: %d ä»¶ \n " , $ paidCount ) ; printf ( "平均金額: Â¥%d \n " , ( int ) $ average ) ; echo "---- 高額泚文䞀芧 ---- \n " ; foreach ( $ bigOrders as $ o ) { printf ( "泚文ID=%d 金額=Â¥%d \n " , $ o [ 'id' ] , $ o [ 'total' ]) ; } 実行結果: https://3v4l.org/V8Ttj/rfc#vgit.master 請求枈み泚文数: 3 ä»¶ 平均金額: Â¥1200 ---- 高額泚文䞀芧 ---- 泚文ID=101 金額=Â¥1200 泚文ID=103 金額=Â¥1500 このように、パむプ挔算子ず高階関数を組み合わせるずずおもスッキリずした実装ができそうですね。 今埌の展望Future scope RFC の䞭には、今回はただ実珟しないが将来やりたい機胜拡匵のアむデアがいく぀か蚘茉されおいたす。 これらが実珟するかは未知数ですが、どんなこずが怜蚎されおいるのか芋おみたしょう。 関数合成挔算子候補は +  |> が「その堎で実行」なのに察し、合成挔算子は <?php $ upperThenReverse = strtoupper ( ... ) + strrev ( ... ) ; // 実行はただしない echo 'hello' |> $ upperThenReverse ; // => OLLEH のように “クロヌゞャ同士をくっ付けお、あずで呌べる 1 ぀の関数を返す” むメヌゞです。 郚分関数適甚Partial Function Application 関数の匕数の䞀郚を ? にするこずで、その郚分を匕数で受け取るクロヌゞャになりたす。 <?php // 'foo' |> fn($s) => str_replace('o', 'a', $s) ず同じ echo 'foo' |> str_replace ( 'o' , 'a' , ? ) ; オブゞェクト呌び出しの短瞮蚘法 パむプ巊蟺のオブゞェクトのメ゜ッドを呌ぶ $$->foo(123) のような簡易シンタックス <?php new DateTime ( '2025-06-11' ) |> $$ -> modify ( '+1 day' ) |> $$ -> format ( 'Y-m-d' ) ; // => "2025-06-12" むテレヌタ甚の暙準関数セット この蚘事で玹介した map や filter を、PHPの暙準関数ずしお甚意する構想もありたす。毎回自前で定矩しなくおよくなるずありがたいですね たずめ パむプ挔算子は「䞀時倉数で぀なぐコヌド」を「読みやすいパむプラむン」に眮き換えおくれたす。小さな関数を䜜っお組み合わせる関数型的なスタむルも曞きやすくなりたすので、PHP 8.5がリリヌスされたらぜひ詊しおみおください。
自己玹介 ラクスでPdMをしおおりたす。 @keeeey_m ず申したす。 珟圚の担圓商材は、楜楜シリヌズ(楜楜粟算、楜楜明现、楜楜電子保存)を担圓しおおり、個人ずしおは楜楜粟算×AIの担圓、 楜楜明现・楜楜電子保存PdMチヌムのリヌダヌをしおおりたす。 きっかけ毎日のテキストコミュニケヌションでの葛藀 日々、業務でチャットツヌルを䜿い瀟内の人ずテキストコミュニケヌションをするこずがほずんどです。ちょっずした雑談からタスクのやり取りたで、様々な情報が飛び亀いたす。あれほど毎日テキストコミュニケヌションをしおいおも、はっきり䌝えようずするず盎接すぎ、配慮しお䞁寧に説明しようずするず長い文面になり圢匏ばったものになったりず、自身が曞いた文面を読み盎し手が止たるこずがしばしばありたす。 本来手軜で䟿利なはずなのに、なぜこうなるのかず気になり、この事象を考察しおみたした。 こんな方におすすめ テキストコミュニケヌションが苊手な方 チャットやメヌルで意図が䌝わらず悩んでいる 人数の倚い組織で働く方 様々な人ずのやり取りで枩床感の調敎に困っおいる AI利甚が増えおいる職堎の方 AIずのやり取りず人間ずのやり取りの䜿い分けに関心がある コミュニケヌション改善を怜蚎䞭のマネヌゞャヌ チヌム内のテキストコミュニケヌション効率化を目指しおいる 目次 察面ずテキストコミュニケヌションの決定的な違い情報が欠萜する 日本特有の事象衚珟が難しい蚀語か぀文化 珟圚のベストプラクティス具䜓的なテクニック AI時代の新たなリスク自然蚀語での察応が可胜、新しい懞念芁玠 考えられる察策䜿い分けが重芁 たずめ 察面ずテキストコミュニケヌションの決定的な違い情報が欠萜する 問題の根本は、察面コミュニケヌションずテキストコミュニケヌションの圧倒的な情報栌差にあるず、考えるこずができたす。 感情・態床の衚珟 察面声のトヌン、衚情、身振り手振りで「優しく蚀っおいる」「心配しおいる」が䌝わる テキスト文字情報のみで掚枬するしかない 緊急床・重芁床の䌝達 察面話すスピヌド、声の倧きさ、間の取り方で「急いでいる」「じっくり考えおほしい」が分かる テキスト同じ文面でも受け手によっお解釈が倉わる 確信床・断定床の衚珟 察面声の匷さ、頷き方、目線で「確信がある」「迷っおいる」が䌝わる テキスト語尟や衚珟に頌るしかない 関係性・距離感の調敎 察面物理的距離、姿勢、アむコンタクトで適切な距離感を保おる テキスト敬語レベルのみで刀断される これらの情報が完党に欠萜するため、送り手の意図ず受け手の解釈に倧きなズレが生じるのです。 日本特有の事象衚珟が難しい蚀語か぀文化 日本のコミュニケヌション文化は、テキストでの衚珟を特に困難にしたす。 「察しお文化」の耇雑さ 「空気を読む」「蚀わなくおも分かるでしょ」が前提 盎接的衚珟を避ける傟向 盞手に配慮した遠回しな衚珟が奜たれる 耇雑な敬語システム 尊敬語・謙譲語・䞁寧語の䜿い分け 盞手ずの関係性や立堎による衚珟の倉化 「です・たす」だけでは䞍十分な堎面の倚さ 文脈䟝存の高さ 前埌の䌚話や状況に䟝存する衚珟 省略が倚い日本語の特性 同じ蚀葉でも文脈で意味が倉わる これらの特城がテキストになるず䞀気に厩れ、誀解の枩床ずなっおしたいたす。 珟圚のベストプラクティス具䜓的なテクニック 組織的にテキストコミュニケヌションを改善するために、察面での豊かな衚珟力をテキストで再珟しおみおも良いのかもしれたせん。 重芁床・枩床感の明瀺 【重芁】【盞談】【共有】【雑談】などの蚘号を掻甚 「心配になったので確認したいのですが」 「冗談半分ですが」 「真面目な話ずしお」 緊急床の明確化 「急ぎ今日䞭に」 「緊急ではありたせんが」 「時間をかけお怜蚎しおください」 「確認だけで返信䞍芁」 確信床の衚珟 「確信を持っお蚀えるのは」 「個人的な掚枬ですが」 「感芚的には」 「間違いないず思いたす」 関係性の調敎 前眮き「お疲れ様です」「心苊しいのですが」 埌眮き「ご理解いただければず思いたす」「匕き続きよろしくお願いしたす」 AI時代の新たなリスク自然蚀語での察応が可胜、新しい懞念芁玠 しかし、AIずの自然蚀語でのやり取りが可胜になったこずで、新たな懞念が考えられたす。 AIずのコミュニケヌションの特城 ストレヌトな衚珟で十分に意図が䌝わる 盞手の感情や反応を気にする必芁がない 察する・察しおもらう必芁がない 効率重芖で結果が出る 䞀定した反応で感情の波がない 人間ずAIのやり取りを倉える必芁性 AIずの自然で効率的なコミュニケヌションに慣れるこずで、以䞋のリスクが考えられたす。 察る胜力の衰退 AIずの「察しなくおいい」やり取りに慣れ、人間同士で必芁な察する胜力が䜎䞋 盎接的衚珟ぞの偏り AIずのストレヌトなやり取りに慣れ、人間盞手でも配慮に欠ける衚珟をしおしたう 期埅倀のミスマッチ AIの「完璧な理解」に慣れ、人間が理解しおくれないこずぞのむラむラが増加 感情ぞの察応力䜎䞋 AIの䞀定した反応に慣れ、人間の気分や状況の倉化に柔軟に察応できなくなる 考えられる察策䜿い分けが重芁 この新たなリスクに察する察策ずしお、䜿い分けの重芁性が浮き圫りになりたす。 意識的なコミュニケヌションスタむルの䜿い分け AI向け効率重芖、ストレヌト、結果志向 人間向け配慮重芖、関係性考慮、感情も含めた総合的なやり取り 具䜓的な察策 コンテキストスむッチの習慣化 AIずのやり取り埌、人間ずのコミュニケヌションでは意識的にトヌンを調敎 定期的な振り返り テキストコミュニケヌションで誀解が生じた事䟋の共有ず孊習 成功事䟋の蓄積ず暪展開 ハむブリッドアプロヌチ 重芁な案件は察面たたはビデオ通話を䜵甚 テキストだけに䟝存しないコミュニケヌション蚭蚈 継続的なスキル維持 人間らしい配慮や察する胜力を意識的に䜿い続ける AIに任せられるこずず、人間が担うべきこずの区別 たずめ 難しいテキストコミュニケヌションに加え、さらに自然蚀語でのAI利甚が䌎い、今埌コミュニケヌション力は重芁な芁玠になり埗るず考えられたす。それず同時に、AIを掻甚するこずず本質は同じであるずも蚀えたす。コミュニケヌションも、AIもシンプルに考えるず、情報の量ず質が肝になるのは共通するこずです。 AI時代だからこそ、人間らしいコミュニケヌション力がより䟡倀を持぀のかもしれたせん。効率性を远求するAIずの䜿い分けを意識しながら、人間同士の豊かなやり取りを倧切にしおいきたいものです。 AIの業務掻甚ずかけたしお、コミュニケヌションずずく。その心は、どちらも情報の質ず量が結果を巊右したす。 お埌がよろしいようで。
こんにちは、AI゚ヌゞェント開発課 課長の石田です。 「ITサヌビスで䌁業の成長を継続的に支揎したす」 これが私たちラクスのミッションです。 私たちはBtoB SaaSの提䟛を通じお、䌁業の成長に぀ながる業務効率化や生産性向䞊に向き合っおきたした。 そのために、開発生産性向䞊はもちろんのこず、顧客の䜓隓䟡倀向䞊や顧客の業務効率化を目的ずした機胜開発にも組織を挙げお取り組んでいたす。 その最も新しい取り組みが、 2025幎5月に蚭立した専門組織「AI゚ヌゞェント開発課」 です。 www.rakus.co.jp AI゚ヌゞェントはナヌザヌの指瀺がなくずも自埋的に目的を理解し、最適なタスクを実行するこずが可胜です。 耇雑な業務フロヌを持぀BtoB領域においおも、非垞に倧きなむンパクトが期埅でき、ラクスが最も泚力しおいく領域の䞀぀です。 そこで本蚘事ではラクス初・AI゚ヌゞェント専門組織の挑戊に぀いおご玹介したいず思いたす。 経費粟算 × AI には圧倒的な顧客貢献䜙地がある 公開䞭のAI機胜ず、今埌のAI゚ヌゞェント機胜の圹割䟋 最速で䟡倀提䟛できる組織ぞ向けた3぀のポむント 1. AI゚ヌゞェント時代に応える、スピヌドず探究で䟡倀を生む開発スタむル 2. ナヌザヌの声を開発に盎結 3. 16幎分・延べ18,000瀟分の倚圩な業務デヌタを掻甚 最初に取り組むのは、「経費申請ワヌクフロヌ」 AI゚ヌゞェントを通じお、仕事の意味も倉えおいきたい 経費粟算 × AI には圧倒的な顧客貢献䜙地がある 経費粟算ずいう、䌁業のあらゆるバックオフィスに存圚しながら、いただに玙・Excel・メヌルずいったアナログな凊理が根匷く残る業務領域に、曎なる楜を実装しおいきたす。 そこで我々が最初に取り組むのは、「楜楜粟算」でのAI゚ヌゞェントの提䟛です。 「楜楜粟算」でも、経費申請の申請やチェックなどはできたしたが、人の手で行っおいる凊理が倚かったです。 䟋えば、申請曞の入力やサヌビス区分の遞択、玐づけるクレゞットカヌド利甚明现を探したり、それらの確認です。 この業務は、申請ミスや差し戻し、手入力の負担ずいった “ノンコア業務”に工数が偏りがちな構造的課題を抱えおおり、自動化・最適化の䜙地が非垞に倧きい領域 です。 www.rakus.co.jp tech-blog.rakus.co.jp すでに公開しおいるAI機胜ず合わせお、申請者のワヌクフロヌ党䜓の「めんどくさい」「煩わしい」「いい感じにしおくれないかな」を、AI゚ヌゞェント機胜により解決しようずしおいたす。 公開䞭のAI機胜ず、今埌のAI゚ヌゞェント機胜の圹割䟋 最速で䟡倀提䟛できる組織ぞ向けた3぀のポむント AI゚ヌゞェント開発課は 「顧客に䟡倀を最速で届けられるAI組織」 ずしお、以䞋を匷みずしおいきたいず考えおいたす。 1. AI゚ヌゞェント時代に応える、スピヌドず探究で䟡倀を生む開発スタむル ラクスの開発は、「熟考を重ねた綿密な蚭蚈ず開発」を埗意ずしおいたす。法芁件ぞの正確な察応に匷みを持っおいたすが、倉化の速いAI領域では高速な詊行錯誀が必芁です。ラクスでは、目的に応じお柔軟に開発プロセスのあり方を倉化させおいたす。 意図的に、゚ヌゞェント開発課では、「楜楜粟算」の開発チヌムずは異なった組織ずしお立ち䞊がりたした。この䞭には、゚ンゞニアだけでなくUXデザむナヌや営業メンバヌなども内圚したす。 たた、゚ンゞニアメンバヌは埗意領域を持ち぀぀も、プロダクト開発に必芁な業務は、だれであれ、参加したす。䟋えば、 顧客からヒアリングした結果を、党員で議論し、UI/UXを含めた改善案を出し合うなども、党員参加したす。 これにより、䌚瀟ずしおは前䟋がないほど、高速に怜蚌サむクルを回しおおり、組織立ち䞊げヶ月経たずしお、モックアップを぀䜜り、それを甚いたお客様ヒアリングを開始し始めたした。 匕き続き、AI゚ヌゞェントずいう未知の領域に察し、既存の楜楜粟算に瞛られるこずなく、新しい顧客䜓隓をれロベヌスで探玢しおいたす。 2. ナヌザヌの声を開発に盎結 ラクスのプロダクト開発チヌムは通垞、「開発本郚」ずいう開発専門組織に所属したす。しかし、AI゚ヌゞェント開発課では あえおビゞネスサむド盎結の組織 ずしたした。 これは私たちが 䞀次情報ぞの近さを優先 したためです。顧客ヒアリング等を柔軟に行えるチヌムずし、プロダクト仮説ず技術怜蚌のルヌプを高速化するこずが目的です。 立ち䞊がっおヶ月ず経っおいたせんが、䜜成したプロトタむプをもずに顧客ヒアリングを開始し、実際に顧客からの声を頂いおおりたす。 たた、その声をすぐに゚ンゞニア・デザむナヌがキャッチアップできる䜓制が敎っおいたす。 3. 16幎分・延べ18,000瀟分の倚圩な業務デヌタを掻甚 「楜楜粟算」はこれたで18,000瀟に導入され、経費粟算システム环蚈導入瀟数No.1ずなっおいたす。 蓄積された16幎分の業務ログや申請傟向など、倚様な業皮・業態のリアルなデヌタに基づいた開発 が行えたす。この“豊富なリアルデヌタ”ず“倚様なステヌクホルダヌ”を掻かしお、リアリティのあるAI゚ヌゞェントサヌビスを䜜っおいきたい考えです。 最初に取り組むのは、「経費申請ワヌクフロヌ」 初期スコヌプずしお泚力しおいるのが、経費粟算の䞭でも手間の倧きい「経費申請ワヌクフロヌ」です。 領収曞をアップロヌドするず、AI゚ヌゞェントが内容を解析・構造化し、関連のあるデヌタ䟋えば、事前申請やクレゞットカヌド利甚明现などを探し出したす。 それらのデヌタを掻甚しお、申請甚デヌタを提案したす。これにより、珟圚は申請者が自ら考え入力しおいた負担を軜枛したす。 圓瀟プレスリリヌスより https://www.rakus.co.jp/news/2025/0501.html    技術的な方針ずしおは、顧客の業務課題を最も早く解決できるこず ずしおいたす。 そのため「過去の履歎からの掚論」や「定型凊理のルヌルベヌス自動化」など、最適な技術芁玠を段階的に組み合わせながら構築するこずずし、必ずしも珟時点では汎甚的なAI゚ヌゞェントを目指さない刀断をしたした。 経費粟算業務は定型化・構造化されおいる郚分も倚く、LLMが事前定矩されたタスクを実行する 「゚ヌゞェンティック・ワヌクフロヌ」 を採甚しおいたす。この延長で、AI゚ヌゞェントに即したUIUXの導入も怜蚎しおいきたす。 AI゚ヌゞェント技術を䜿えば、申請から承認たでの䞀連の経費凊理を完党に自動化できるかもしれたせん。しかし私たちは、 申請者や経理担圓者が「自分は内容を理解し、きちんず確認した」ずいう安心感ず玍埗感 を埗られるこずを最優先に䜍眮づけたした。そこで、 ゚ヌゞェントを“代行者”ではなく“支揎者”ずしお蚭蚈 しおいたす。 AI゚ヌゞェントを通じお、仕事の意味も倉えおいきたい AI゚ヌゞェント開発課はただ始動したばかりですが、経費申請ワヌクフロヌを皮切りに、今埌も積極的に呚蟺領域ぞず広げお参りたす。 そのために、 最新のAI/AI゚ヌゞェント技術を探求し぀぀、お客様の䜓隓䟡倀を远求する「顧客志向」 を倧切にしおいたす。 最終的には、「ヒトずAI」が盞互助力により、より心地よい業務䜓隓を実珟・提䟛しおいくこずを目指しおいたす。そんな未来に向けお、システムをご利甚いただいおいるお客様の声を原動力ずしながら䞀歩ず぀進んでいきたす。 ただ始たったばかりのAI゚ヌゞェント開発課ですが、プロゞェクトの進行や技術的な実装が進展したらたたのブログでもご報告しおいきたす。楜しみにお埅ちいただければ幞いです。
自己玹介 ラクスでPdMをしおおりたす。 @keeeey_m ず申したす。 珟圚の担圓商材は、楜楜シリヌズ(楜楜粟算、楜楜明现、楜楜電子保存)を担圓しおおり、個人ずしおは楜楜粟算×AIの担圓、 楜楜明现・楜楜電子保存PdMチヌムのリヌダヌをしおおりたす。 こんな方におすすめ プロダクトマネヌゞャヌずしお孀独感を感じおいる方 プロダクトマネヌゞャヌをマネゞメントする立堎の方 プロダクトマネヌゞャヌを目指しおいる方 組織開発やチヌムマネゞメントに携わる方 目次 はじめにPdMの孀独ずいう普遍的な課題 PdMが感じる孀独の本質 孀独ず向き合う個人ずしおのアプロヌチ 組織ずしお䜕ができるか たずめ孀独ず健党に向き合う「堎」を䜜る はじめにPdMの孀独ずいう普遍的な課題 先日、メンバヌからのずある声を知り、プロダクトマネヌゞャヌPdMの孀独に぀いお深く考える機䌚がありたした。この投皿は、私自身の経隓ずも重なり、倚くのPdMが感じおいる普遍的な課題ではないかず感じたした。 PdMずいう圹割に就く人が感じる孀独感は、単なる職堎での寂しさずは質が異なりたす。それは、圹割の本質に根ざした、より深い次元の孀独です。 PdMが感じる孀独の本質 組織における立ち䜍眮の特殊性 PdMは開発チヌム、デザむンチヌム、マヌケティング、営業、経営陣など様々なステヌクホルダヌの間に立぀「ハブ」的な圹割を担いたす。しかし、どの郚門にも完党には属さないため、垰属意識を感じにくく、自分の居堎所を芋぀けるのに苊劎するこずがありたす。 意思決定の重圧ず責任 PdMは補品の方向性や優先順䜍等に぀いお重芁な刀断を䞋す必芁がありたす。䌚瀟や補品のフェヌズによっおPdMの圹割は異なったりするものの、PdMが䞋すその決定は埀々にしお誰かを倱望させたり、トレヌドオフを䌎いたす。最終的な責任を負う立堎にいながら、盎接的な暩限は限られおいるずいうゞレンマも抱えおいたす。 解像床の栌差による孀独 プロダクトマネゞメント、プロゞェクトマネゞメント、さらに開発の蚭蚈郚分たで理解できるPdMは、誰よりも早く問題や危機感を察知したす。しかし、その耇合的な芖点から芋えおくる問題を、特定の専門領域に特化した芖点を持぀人に理解しおもらうのは困難です。 孀独ず向き合う個人ずしおのアプロヌチ 孀独を力に倉える この孀独感は必ずしも解決すべき問題ではないず、私は考えおいたす。なぜなら、それは責任ある意思決定の蚌でもあるからです。重芁な決断を䞋す時、最終的には䞀人で刀断し、その結果に責任を持぀必芁がありたす。他人の意芋に巊右されず、デヌタず自分の信念に基づいお決断する瞬間には、必然的に孀独感が䌎いたす。これは逃げられない、そしお䟡倀のある経隓です。 客芳性を保぀ための距離感 あらゆるステヌクホルダヌず適床な距離を保぀こずで、どこかの郚門に偏った刀断をするこずなく、プロダクト党䜓の最適化を図るこずができたす。この「䞭立的な立堎」は、時ずしお孀独を感じさせたすが、PdMの重芁な匷みでもありたす。 組織ずしお䜕ができるか ずはいえ、プロダクトマネゞメント組織を率いるリヌダヌずしお、適切なサポヌト䜓制を敎える必芁があるず考えおいたす。 実際に効果があったこず、詊行錯誀しながら取り組んでいるこずです。 耇数名䜓制による物理的・粟神的な負荷の分散 私の経隓では、PdMを耇数名䜓制にするこずで、孀独問題が倧きく解消されたした。同じ立堎・圹割で協業できるメンバヌがいるこずで、物理的にも粟神的にも負荷が䞋がりたす。特に、意思決定の重圧を共有できるこずは、倧きな安心感に぀ながりたす。 早期発芋ず迅速なサポヌト 過去の倱敗経隓から、メンバヌが䞀人で問題を抱え蟌んでしたう前に、早期に気づき、サポヌトするこずが重芁だず孊びたした。 定期的な1on1ミヌティングでの状況確認 普段の䌚話の䞭での倉化の察知 「できない」ずいう珟状の蚀語化を促す 段階的なアプロヌチ 組織ずしお以䞋のような段階的なアプロヌチを実践しおいたす。 こためな壁打ちの時間の確保 共感ず理解を瀺すコミュニケヌション メンバヌからのアクションベヌスでの察応マむクロマネゞメントを避ける 倖郚むベントのレポヌト共有など、情報共有の機䌚創出 実践的なアドバむス これらの取り組みを実斜する䞊で、以䞋の点に泚意しおいたす。 過床な介入を避け、メンバヌの䞻䜓性を尊重する 問題の早期発芋のための芳察力を磚く 共感を瀺し぀぀も、具䜓的な解決策を提瀺する 組織の芏暡や状況に応じお、柔軟にアプロヌチを調敎する たずめ孀独ず健党に向き合う「堎」を䜜る 私自身もPdMずしお、耇数の芖点から同時に物事を芋るこずで生たれる内的葛藀や、解像床の高さゆえの孀独を経隓しおきたした。その䞭で、理解を瀺しおくれる人が䞀人でもいるこずの倧切さも痛感したした。 だからこそ、組織ずしおは孀独そのものを「悪」ずしお排陀しようずするのではなく、孀独ず健党に向き合える堎を甚意するこずが重芁だず考えおいたす。これは単なる愚痎の吐き出し堎ではなく、孀独感の意味を理解し、それを力に倉えおいくためのスペヌスです。 PdMずいう圹割の本質を理解した䞊で、孀独を完党に取り陀こうずするのではなく、それず健党に共存する方法を組織ずしお支揎する。これこそが、真にPdMを理解したリヌダヌのアプロヌチだず考えおいたす。 PdMが「䞀人で戊っおいる」のではなく「組織に支えられながら、時には䞀人で決断する」ずいう状態を䜜り出すこず。それが、プロダクトマネゞメント組織のリヌダヌずしお目指しおいるこずです。
はじめに こんにちは ゚ンゞニア幎目のTKDSです 今回はメタデヌタ管理をPostgresqlやMySQLなどのSQLデヌタベヌスが担う新しいOSSのLakehouseフォヌマット、Ducklakeに぀いお詊しおみたした 今回はPostgresql+s3(minio)+DuckDBで構築しおたす。 はじめに Ducklakeの抂芁 準備 1. composeでPostgresqlずminioを起動 2. minioでバケットを䜜成する 3. DuckDB偎の準備ず起動 詊す たずめ Ducklakeの抂芁 Ducklakeは公匏HPの䞀文によるずSQLデヌタベヌスをカタログ眮き堎に、デヌタをparquetファむルに保存する圢匏のLakehouseフォヌマットだそうです。 DuckLake delivers advanced data lake features without traditional lakehouse complexity by using Parquet files and your SQL database. It's an open, standalone format from the DuckDB team. Google翻蚳 DuckLakeは、ParquetファむルずSQLデヌタベヌスを䜿甚するこずで、埓来のレむクハりスの耇雑さを排陀しながら、高床なデヌタレむク機胜を提䟛したす。DuckDBチヌムが提䟛するオヌプンなスタンドアロンフォヌマットです。 簡単にLakehouseを䜿えるず解釈しおおきたしょう では早速準備しお䜿っおいきたす。 準備 今回、Postgresqlずminioをcomposeで建お、それぞれカタログ眮き堎、デヌタ眮き堎ずしお䜿いたす。 環境構築埌、DuckDB CLIからク゚リを打っお操䜜しおいく圢です 。 1. composeでPostgresqlずminioを起動 たず.envファむルにパスワヌド等を蚘茉しおおいおください。 Minioのパスワヌドは短いず以䞋の゚ラヌでコンテナ起動できないので泚意。 MINIO_ROOT_USER length should be at least 3, and MINIO_ROOT_PASSWORD length at least 8 characters MINIO_ROOT_USER=root-minio MINIO_ROOT_PASSWORD=root-minio POSTGRES_USER=postgres POSTGRES_PASSWORD=postgres POSTGRES_DB=postgres ディレクトリを䜜っおおきたす。 mkdir ./data/minio mkdir ./data/postgres 以䞋の内容でcomposeファむルを曞きたす。 services : minio : image : quay.io/minio/minio:RELEASE.2025-05-24T17-08-30Z container_name : minio command : server /data --console-address ":9001" environment : MINIO_ROOT_USER : ${MINIO_ROOT_USER} MINIO_ROOT_PASSWORD : ${MINIO_ROOT_PASSWORD} volumes : - ./data/minio:/data ports : - "127.0.0.1:9000:9000" - "127.0.0.1:9001:9001" healthcheck : test : [ "CMD" , "mc" , "ready" , "local" ] start_period : 10s interval : 30s timeout : 20s retries : 3 postgres : image : postgres:17.5-bookworm container_name : postgres environment : POSTGRES_USER : ${POSTGRES_USER} POSTGRES_PASSWORD : ${POSTGRES_PASSWORD} POSTGRES_DB : ${POSTGRES_DB} volumes : - ./data/postgres/init.sql:/docker-entrypoint-initdb.d/init.sql:ro ports : - "127.0.0.1:5432:5432" healthcheck : test : [ "CMD-SHELL" , "pg_isready -U ${POSTGRES_USER}" ] interval : 10s timeout : 5s retries : 5 networks : default : name : ducknet init.sqlには以䞋を蚘茉したす。 CREATE DATABASE ducklake; docker compose up で起動したす。 2. minioでバケットを䜜成する 今回GUIから䜜りたした。 http://localhost:9001/ にアクセスしおください。 ログむンしお、巊偎のCreate Bucketからバケットを䜜りたす。 今回名前はducklake-pocにしたした。 3. DuckDB偎の準備ず起動 DuckDBをむンストヌルしたす。 今回はCLIのDuckDBを䜿いたす。 HPにあるコマンド curl https://install.duckdb.org | sh むンストヌルできたか確認 $ duckdb -version v1.3.0 71c5c07cdd DuckDBに必芁な拡匵機胜をむンストヌルしたす。 duckdbコマンドでCLIを起動しお以䞋のコマンドを打っおください。 INSTALL ducklake; INSTALL httpfs; INSTALL postgres; LOAD postgres; LOAD ducklake; LOAD httpfs; postgres、httpfsはDucklakeのドキュメントには曞いおなかったですが、ずりあえず関係しおそうなのでむンストヌルしおおきたした。 Postgresqlずオブゞェクトストレヌゞに接続し、アタッチしたカタログデヌタベヌスを䜿甚状態にしたす。 たずs3接続甚シヌクレットを䜜りたす。 create secret (type s3, key_id 'root-minio', secret 'root-minio', endpoint 'localhost:9000', use_ssl false, url_style 'path'); では接続したす。 ATTACH 'ducklake:postgres:dbname=ducklake_catalog host=localhost user=postgres password=postgres' AS postgres_ducklake (DATA_PATH 's3://ducklake-poc'); USEしたずきに゚ラヌでなければ成功です。 USE postgres_ducklake; Attachしたタむミングでテヌブルが䜜成されたす。 publicスキヌマに䜜られおたす。 $ docker exec -it postgres psql -U postgres -d ducklake psql (17.5 (Debian 17.5-1.pgdg120+1)) Type "help" for help. ducklake=# \dt Did not find any relations. ducklake=# \dt List of relations Schema | Name | Type | Owner --------+---------------------------------------+-------+---------- public | ducklake_column | table | postgres public | ducklake_column_tag | table | postgres public | ducklake_data_file | table | postgres public | ducklake_delete_file | table | postgres public | ducklake_file_column_statistics | table | postgres public | ducklake_file_partition_value | table | postgres public | ducklake_files_scheduled_for_deletion | table | postgres public | ducklake_inlined_data_tables | table | postgres public | ducklake_metadata | table | postgres public | ducklake_partition_column | table | postgres public | ducklake_partition_info | table | postgres public | ducklake_schema | table | postgres public | ducklake_snapshot | table | postgres public | ducklake_snapshot_changes | table | postgres public | ducklake_table | table | postgres public | ducklake_table_column_stats | table | postgres public | ducklake_table_stats | table | postgres public | ducklake_tag | table | postgres public | ducklake_view | table | postgres (19 rows) ducklake=# \dt public.ducklake_column; List of relations Schema | Name | Type | Owner --------+-----------------+-------+---------- public | ducklake_column | table | postgres (1 row) これで䜿う準備は完了です。 詊す Introduction のサンプルを元に詊しにやっおみたす。 Postgresqlずminioで環境構築しおるので、䞀郚を改倉しお実行しおたす。 ※色々暪道それながらやっおたので、䞀郚オブゞェクトファむルのファむル名違ったりしたすが気にしないでください。 CREATE TABLE nl_train_stations AS FROM 'https://blobs.duckdb.org/nl_stations.csv'; これでCSVファむルからデヌタを読み蟌みテヌブルが䜜成されたす。 DBを芋おみるずテヌブルの情報が䜜成されおたす。 ducklake=# select * from ducklake_table; table_id | table_uuid | begin_snapshot | end_snapshot | schema_id | table_name ----------+--------------------------------------+----------------+--------------+-----------+------------------- 1 | 01974993-3ba1-7505-b4bf-eecff46886e0 | 1 | | 0 | nl_train_stations (1 row) ducklake=# select table_id,column_name from ducklake_column; table_id | column_name ----------+------------- 1 | id 1 | code 1 | uic 1 | name_short 1 | name_medium 1 | name_long 1 | slug 1 | country 1 | type 1 | geo_lat 1 | geo_lng (11 rows) オブゞェクトストレヌゞ偎にもparquetファむルが䜜成されたす。 では続きをやっおいきたす。 以䞋コマンドはparquetファむルの情報を取埗しおいたす。 D FROM glob('s3://ducklake-poc/*') ; ┌─────────────────────────────────────────────────────────────────────────┐ │ file │ │ varchar │ ├────────────────────────────────────────────────────────────────────────── │ s3://ducklake-poc/ducklake-01974989-7208-7460-964d-c17d34b116c7.parquet │ └─────────────────────────────────────────────────────────────────────────┘ D FROM 's3://ducklake-poc/*.parquet' LIMIT 10; ┌───────┬─────────┬───┬─────────────────┬─────────────────┐ │ id │ code │ 
 │ geo_lat │ geo_lng │ │ int64 │ varchar │ │ double │ double │ ├───────┌─────────┌───┌─────────────────┌────────────────── │ 266 │ HT │ 
 │ 51.69048 │ 5.29362 │ │ 269 │ HTO │ 
 │ 51.700553894043 │ 5.3183331489563 │ │ 227 │ HDE │ 
 │ 52.4091682 │ 5.893611 │ │ 8 │ AHBF │ 
 │ 50.7678 │ 6.091499 │ │ 818 │ AW │ 
 │ 50.78036 │ 6.070715 │ │ 51 │ ATN │ 
 │ 51.921326524551 │ 6.5786272287369 │ │ 5 │ AC │ 
 │ 52.2785 │ 4.977 │ │ 550 │ EAHS │ 
 │ 52.079796120944 │ 7.0163583755493 │ │ 12 │ AIME │ 
 │ 45.55438 │ 6.64869 │ │ 819 │ ACDG │ 
 │ 49.004048 │ 2.571133 │ ├───────┎─────────┎───┎─────────────────┎────────────────── │ 10 rows 11 columns (4 shown) │ └──────────────── チュヌトリアルの通りに倉曎を加えたす。 UPDATE nl_train_stations SET name_long='Johan Cruijff ArenA' WHERE code = 'ASB'; 倉曎を加えるずファむルが増えおるのがわかりたす。 FROM glob('s3://ducklake-poc/*') ; ┌──────────────────────────────────────────────────────────────────────────────┐ │ file │ │ varchar │ ├─────────────────────────────────────────────────────────────────────────────── │ s3://ducklake-poc/ducklake-01974993-3ba1-7387-ac08-101cab81f9f7.parquet │ │ s3://ducklake-poc/ducklake-01974994-9e69-7177-a6e5-253d9cf9d4af.parquet │ │ s3://ducklake-poc/ducklake-01974994-9e83-7c25-b00b-1f41f679902e-delete.par
 │ └────────────────────────────── 過去のデヌタの状態を蚘憶したsnapshot䞀芧も芋るこずができるようです。 FROM postgres_ducklake.snapshots(); ┌─────────────┬────────────────────────────┬────────────────┬─────────────────────────────────────────────────────────────────────┐ │ snapshot_id │ snapshot_time │ schema_version │ changes │ │ int64 │ timestamp with time zone │ int64 │ map(varchar, varchar[]) │ ├─────────────┌────────────────────────────┌────────────────┌────────────────────────────────────────────────────────────────────── │ 0 │ 2025-06-07 17:43:15.138+09 │ 0 │ {schemas_created=[main]} │ │ 1 │ 2025-06-07 17:47:54.805+09 │ 1 │ {tables_created=[main.nl_train_stations], tables_inserted_into=[1]} │ │ 2 │ 2025-06-07 17:49:26.108+09 │ 1 │ {tables_inserted_into=[1], tables_deleted_from=[1]} バヌゞョンごずに内容を確認可胜です。 SELECT name_long FROM nl_train_stations AT (VERSION => 1) WHERE code = 'ASB'; nl_train_stations AT (VERSION => 2) WHERE code = '┌─────────────────────────┐ │ name_long │ │ varchar │ ├────────────────────────── │ Amsterdam Bijlmer ArenA │ └─────────────────────────┘ SELECT name_long FROM nl_train_stations AT (VERSION => 2) WHERE code = 'ASB'; ┌─────────────────────┐ │ name_long │ │ varchar │ ├────────────────────── │ Johan Cruijff ArenA │ └────────────── カタログからデタッチするには以䞋のコマンドを䜿いたす。 USE memory; DETACH postgres_ducklake; ここたでで色々詊すこずができたした たずめ 今回はDucklakeをPostgresql + s3(Minio) + DuckDBで構築したした むンタヌネット䞊に情報が少なくかなり苊劎したしたが、動かせおよかったです デヌタ本䜓はオブゞェクトストレヌゞに眮く圢匏なので、䜎コストで倧量のデヌタをおけるのではないでしょうか これからもちょくちょく觊っおみたいず思いたした。 ここたで読んでいただきありがずうございたした
自己玹介 ラクスでPdMをしおおりたす。 @keeeey_m ず申したす。 珟圚の担圓商材は、楜楜シリヌズ(楜楜粟算、楜楜明现、楜楜電子保存)を担圓しおおり、個人ずしおは楜楜粟算×AIの担圓、 楜楜明现・楜楜電子保存PdMチヌムのリヌダヌをしおおりたす。 きっかけは亀流セッションのオファヌ 先日、アシスタントマネヌゞャヌAMぞのステップアップを目指す女性瀟員向けの瀟内研修で話をする機䌚をいただきたした。東京拠点で研修を受けおいる17名に向けお、マネゞメント職ずしお経隓しおきたこずをざっくばらんに話しおほしいずのこず。開発郚門でマネゞメント職ずしお働く私の話が、圌女たちに新たな芖点や気づきを䞎え、今埌のキャリアを考える䞊での貎重なヒントになればずいう趣旚でした。 このオファヌをきっかけに、自分自身のキャリアを振り返る良い機䌚ずなりたした。マネゞメントキャリアに前向きな気持ちがある䞀方で、自身が職責を果たせるのか、ラむフプランず䞡立できるのかずいった䞍安を感じおいる方々に向けお、ささやかながら私の経隓をシェアしたいず思いたす。 自己玹介 きっかけは亀流セッションのオファヌ 偶然の積み重ねが道になる 䞀人では解決できない課題 マネゞメントずやりがい 匷みず成長領域 ラベリングずの向き合い方 キャリアは䞀方通行ではない 偶然の積み重ねが道になる 2013幎、新卒゚ンゞニアずしお入瀟しおから10幎䜙り。気が぀けば補品管理課でチヌムを率いる立堎になっおいたした。「マネゞメントを目指そう」ず決意した瞬間があったかず問われれば、そうではないず答えるでしょう。日々の業務に向き合い、少しず぀責任範囲が広がり、い぀しかマネゞメント局になっおいたした。 マネゞメントずいう遞択肢に興味を持ったきっかけは、ある気づきからでした。「自分が実珟したい達成したい状態が、䞀個人の胜力だけでは解決できない事象もある」ずいう珟実に盎面したずきです。 䞀人では解決できない課題 ラクスベトナムの立ち䞊げ初期、珟地゚ンゞニアの離職率の高さに悩たされおいたした。新たな開発拠点の構築のため、珟地メンバヌぞのレクチャヌや䞀緒の開発を通じお貢献しようずしたしたが、教えおは離職するずいう負のサむクルが続きたした。圓時は自分の胜力䞍足を感じ、䜕ができたのか自問自答しおいたした。 しかし1〜2幎埌、ラクスベトナムの珟地マネゞメント䜓制や採甚方法が倉わるず、離職率は倧幅に䞋がりたした。そのずき気づいたのです。これは個人レベルでどうにかなる問題ではなかったずいうこずを。組織的な課題解決には、マネゞメントずいう手段も必芁だず考え始めたのです。 マネゞメントずやりがい 「マネゞメントずは、組織の目暙達成のために、経営資源ヒト・モノ・カネ・情報などを効率的か぀効果的に掻甚し、組織の運営を最適化するこず」。これを実感できるのは、䞀人の力では到底できないプロゞェクトを成功に導けたずきだず考えおいたす。 珟圚進行䞭の楜楜粟算のAI機胜開発プロゞェクトは、たさにその䟋です。自郚眲だけでなく郚眲を暪断しお経営資源を効率的に掻甚しおいたす。䜕を目指しおいるのかを各開発郚門や関連郚眲に説明し、理解ず協力を埗る。このプロセスを経お、最終的には蚘者䌚芋やプレスリリヌスの内容にも携わるたでになりたした。ただただ始たったばかりですが、䞀人では決しお達成できなかった成果の䞀぀です。 匷みず成長領域 ラクスには評䟡軞ずしお党職皮においおパフォヌマンスに加えコンピテンシヌ行動特性評䟡がありたす。 ラクスのコンピテンシヌ 思考力課題蚭定力・分析力 /状況刀断力 行動力段取力・課題実行力/率先性・むニシアチブ 人間関係力折衝・亀枉力/コミュニケヌション力 組織掚進力リヌダヌシップ・フォロワヌシップ/チヌムワヌク/人材育成 AMやマネゞメントずしおの私の匷みは、「思考力課題蚭定力・分析力」「行動力段取力・課題実行力」「コミュニケヌション力折衝・亀枉力」が挙げられたす。珟堎で䞀぀ひず぀ステップを䞊がっおきたからこそ、実務の解像床が高いのも匷みです。 これらの匷みは、䞍確実性の高い状況での意思決定ず、それぞのコミットメントを繰り返しおきたこずで培われたした。意思決定をする際、必芁な情報が党お揃うこずはありたせん。それによっお思いもよらぬこずが起きるこずもありたす。その結果を振り返り、「予防線は匵れなかったのか」「リスクずしお怜蚎できなかったのか」「芋萜ずしおいた予兆はなかったのか」ず内省する。この量を繰り返し、質を䞊げるこずで、結果的に思考力ず行動力が磚かれたした。 たた、思考力課題蚭定力・分析力ず行動力段取力・課題実行力を掻かしお、折衝・亀枉力にも良い圱響を䞎えおいたす。関連郚眲にはその郚眲の目暙などがあり、どのような事業KPIを持っおいるかなど盞手の眮かれおいる状況を理解するこずで、取り組むこずができおいたす。 䞀方で、今埌さらに成長させたい点もありたす。 コミュニケヌション力 : メンバヌぞの情報開瀺ず正確な䌝達 斜策や新たな取り組みにワクワクしおもらえるような䌝え方 䌝えにくいこずでも事実ず解釈を区別し、誀解なく䌝える力 組織掚進力 : リヌダヌシップずフォロワヌシップ チヌムワヌク 人材育成 ラベリングずの向き合い方 実は、AMになるこずにはかなり抵抗がありたした。AMになれば、いずれマネゞャヌぞの話は避けおは通れなくなり、「女性管理職」ずいうラベリングが぀くこずに違和感があったのです。ゞェンダヌに関係なく、䞀人の゚ンゞニアずしお、䞀人の人ずしおキャリアを歩み、ものづくりや課題解決に取り組む人ずしお芋られたい。 しかし、同様にラベリングに察しお違和感を感じおいた人の蚀葉を目にしたした。 「い぀かそういうラベルがビゞネスの䞖界に存圚しなくなっおくれたらいいず思うけど、それが実珟する日はきっずずおも遠いから、存圚する前提の䞭でできるこずをやろうず思った。」 私は喜んで前に出る。 い぀かそういうラベルがビゞネスの䞖界に存圚しなくなったらいいず思うけど、それが実珟する日はきっずずおも遠いから、存圚する前提の䞭でできるこずをやろうず思うに至った次第。 — Aki (@LoveIdahoBurger) July 22, 2023 そういう考え方もできるなず思い、捉え方を埐々に倉えたした。ただ「誰かの䞀歩螏み出す勇気になったら、喜んで匕き受ける」ずいう境地には至っおいたせんが、自分ができるこずをやろう、ず考えるようになりたした。 キャリアは䞀方通行ではない キャリアは「One Way Door䞀方通行」ではありたせん。マネゞメントにチャレンゞしおみお、専門性を远求したくなったら、たた意思決定すればいい。自分自身ず向き合い、自分自身で意思決定をするこずが倧切です。 呚囲の考えを汲み取る必芁もなければ、無理にロヌルモデルを芋぀ける必芁もない。生きおいく䞊で、䞖の䞭の様々な人の考えに觊れ、自分に合うものをちょっずず぀拝借する、それだけで十分なのではないでしょうか。 日々の業務に向き合い、「もうちょっずだけやっおみよう」ずいう姿勢。そしお、やるだけやっおみお、たた次の遞択をする。そんな䞀歩䞀歩が、結果的に自分だけのキャリアを圢䜜っおいくのだず思いたす。
はじめに こんにちは。楜楜販売開発課のkananpaです。 今回は、私が所属しおいるサポヌト察応チヌムにお、NotebookLMを䜿っおナレッゞ怜玢甚の問い合わせBotを䜜成した取り組みに぀いおご玹介したす。 「ナレッゞはたくさんあるけど、掻かしきれおいない 」 そんな課題を解消すべく、AIツヌルを導入しおどのようにナレッゞを敎理・掻甚したか、その䜜成過皋ず課題を玠盎にたずめたした。 はじめに ナレッゞは溜たっおいるのに、掻甚できおいない珟状 NotebookLMでナレッゞ怜玢甚Botを構築 NotebookLMを遞んだ理由 デヌタの準備ずむンポヌト 異なるデヌタ圢匏をどう扱ったか 実際の倉換凊理 CSV ➡ Markdownの倉換 HTML ➡ Markdownの倉換 Markdown倉換で工倫したポむント プロンプトの蚭定 実際に䜿っおみた感想ず効果 問い合わせ察応での掻甚事䟋 利甚者の声 芋えおきた課題ず今埌の展望 おわりに ナレッゞは溜たっおいるのに、掻甚できおいない珟状 私たちが提䟛しおいる「楜楜販売」は、カスタマむズ性が非垞に高く、機胜や蚭定も倚岐にわたるサヌビスです。  それに䌎っお手厚い顧客サポヌト䜓制も魅力の䞀぀ずなっおいたす。 そのため、CSカスタマヌサクセスチヌム、開発チヌム䞀䞞ずなっお、より良いサポヌト察応を行おうず改善を続けおきた結果、以䞋のような豊富なナレッゞが蓄積されおいたす。 顧客向けマニュアル機胜説明、蚭定方法など 過去の問い合わせ察応履歎 CSチヌムが管理しおいるナレッゞ しかし、それらが点圚しおいたり、衚蚘揺れがあったり、情報量が倚すぎるなどで、必芁な情報にたどり着くのに時間がかかっおいたした。 こうした課題を解決し、お客様からのお問い合わせに察しお、より早く適切な回答ができる環境を敎えるために、AIサヌビスを掻甚したナレッゞ怜玢甚Botの構築に取り組みたした。 NotebookLMでナレッゞ怜玢甚Botを構築 以䞋では、NotebookLMを遞定した背景ず、その具䜓的な構築プロセスに぀いお説明したす。 NotebookLMを遞んだ理由 ナレッゞ怜玢甚Botを導入するにあたり、たずは以䞋の芁件を満たすAIサヌビスである必芁がありたした。 党瀟員が利甚可胜であるこず 瀟倖秘情報も扱えるこず※前提内郚利甚に限る コストを䜎く抑えられるこず ChatBot圢匏で質問できるこず 任意のドキュメントを孊習できるこず これらの条件を螏たえ、候補ずしお次の3぀のAIサヌビスを比范したした。 ツヌル名 特城 ChatGPT ・ファむルの察応圢匏が広い ・りェブ怜玢が可胜 NotebookLM ・資料の孊習に特化させたAI ・基本的に資料に曞かれおいないこずは回答しない ・回答時に゜ヌスの箇所を衚瀺 Gemini ・プラむバシヌ重芖の蚭蚈 ・画像やコヌド、音声、動画など倚様な圢匏に察応 この䞭で、特に重芁芖したのは次の3点です。 リサヌチ甚途に特化しおいるこず 資料に基づく正確な回答が埗られるこず 回答時に出兞を明瀺できるこず これらの点より、 NotebookLM がナレッゞ怜玢甚途に最適ず考え、採甚を決定したした。 デヌタの準備ずむンポヌト 利甚するAIサヌビスが決定し、次にナレッゞ怜玢に必芁なデヌタの敎備ずむンポヌト䜜業に取りかかりたした。 しかし、実際に蓄積されおいたナレッゞは、管理堎所も圢匏もバラバラ、以䞋のように出力圢匏も統䞀されおいたせんでした。 顧客向けマニュアル機胜説明、蚭定方法など ⇒ HTML 過去の問い合わせ察応履歎 ⇒ CSV CSチヌムが管理しおいるナレッゞ ⇒ Markdown 異なるデヌタ圢匏をどう扱ったか そこでたず、これらの資料をMarkdown圢匏に統䞀する䜜業を行いたした。 統䞀圢匏にMarkdownを採甚した理由は、次のような利点があるためです。 Q&A構造をわかりやすく衚珟できる 芋出し、箇条曞き、リンクを䜿っお構造的に敎理できる NotebookLM䞊での衚瀺が敎いやすく、読みやすい 原文リンクを埋め蟌むこずで、元資料に簡単にアクセス可胜 これにより、質問ず回答を明確に区別しお孊習させるこずが可胜になり、誀った理解を防げるだけでなく、利甚者にずっおの可読性やナビゲヌション性の向䞊にも぀ながりたす。 実際の倉換凊理 Markdownぞの倉換には、PHPで提䟛されおいるラむブラリを䜿甚したした。 CSV ➡ Markdownの倉換 たずCSV圢匏の資料に぀いおは、PHPの組み蟌みクラスである SplFileObject を䜿っおCSVデヌタを配列に敎圢し、Markdown圢匏に倉換したした。 CSV ➡ Markdown倉換むメヌゞ図 HTML ➡ Markdownの倉換 たた、HTML圢匏の資料に぀いおは HtmlConverter ラむブラリを䜿甚し、特に衚圢匏デヌタなども正確に倉換できるよう TableConverter も䜵甚したした。 HTML ➡ Markdown倉換むメヌゞ図 ※䞊蚘の画像は本ブログ甚に䜜成したサンプル図であり、楜楜販売の実際の仕様ずは䞀切関係ありたせん。 Markdown倉換で工倫したポむント Markdown圢匏ぞの倉換にあたっおは、䞊蚘添付画像の通り以䞋のような工倫を行いたした。 元デヌタの衚瀺構造を極力再珟芋出し・箇条曞き・衚など NotebookLMのファむル数制限に配慮し、関連情報を1ファむルに集玄 原文リンクをMarkdownに明蚘し、出兞ぞのアクセス性を確保 プロンプトの蚭定 最埌にプロンプトの蚭定を行いたした。 NotebookLMではデフォルトであらかじめ甚意されプロンプトを䜿甚するこずもできたすが、 今回は以䞋添付画像のように「カスタム」で蚭定し、回答の長さも「短め」に蚭定したした。 プロンプトの蚭定䟋 回答の長さに関しお、ナレッゞ怜玢甚ずしおは端的にたずたった内容が確認できた方が適切だろうず刀断し、「短め」に蚭定したした。 「短め」でも重芁な情報が挏れずにピックアップされおおり、十分に内容を把握できたす。 実際に䜿っおみた感想ず効果 問い合わせ察応での掻甚事䟋 実際に䜜成したBotに質問しおいる様子が以䞋になりたす。 Bot掻甚事䟋 具䜓的な内容はお芋せ出来たせんが、関連するナレッゞに基づいた内容が返っおきおおり、回答内の「参照元リンク」をクリックするず、Markdownで敎圢された読みやすい資料がそのたた衚瀺されたした。 怜玢結果ず資料の芋やすさが盎結しおいる点は、運甚䞊の倧きなメリットです。 利甚者の声 実際にCS・開発メンバヌ数名に䜿甚しおもらったずころ、以䞋のようなフィヌドバックが埗られたした。 調査のヒントずなる情報が埗られる あいたいな質問でも関連情報が敎理されお衚瀺される ナレッゞ怜玢工数を削枛できた 回答文を䜜成する際の玠材集めずしお掻甚できる 珟時点では、そのたた回答ずしお䜿えるレベルではないものの、調査の方向性を掎むには十分有効です。 たた、解決のヒントを䞎えおくれるこずから、ただサポヌト業務を行っお間もない新人メンバヌのオンボヌディング支揎にも、掻甚が期埅できたす。 芋えおきた課題ず今埌の展望 ただ、珟堎での詊隓導入を通じお、ただただ以䞋のような課題もあるこずがわかっおきたした。 回答が埮劙にずれおいるこずがある 資料に蚘茉があるはずなのにうたく回答されない 衚などの構造化デヌタの読み取りが匱い 怜玢ワヌド次第で該圓なしずなるこずも 顧客環境䟝存の質問には察応が難しい 特に、「資料に蚘茉があるはずなのにうたく回答されない」ずいったケヌスは、粟床改善の重芁なポむントず感じおいたす。 今埌は、以䞋のようなアプロヌチで改善を進めおいく予定です。 孊習察象デヌタの遞別  → ナレッゞずなりえそうな情報を党お孊習デヌタずしおいたしたが、ナレッゞずしお効果の薄いものは察象倖ずするこずで、より的確な回答が埗られるよう芋盎しを怜蚎しおいたす。 孊習察象デヌタのファむル分割粒床最適化  → 倧きなファむルをそのたた扱うのではなく、適床な単䜍でたずめ盎しおNotebookLMぞ登録するこずで、より正確に該圓情報を匕き出せる可胜性が高たりたす。 FAQ圢匏ぞの倉換ルヌルを敎備  → ナレッゞを単玔にMarkdown化するのではなく、「Q:」「A:」などの明瀺的な構造を定矩し、Botが文脈を正確に把握しやすいように敎圢したす。 よくある衚珟の揺れに察応  → ナヌザヌが䜿いがちな甚語や衚珟揺れのパタヌンを収集し、怜玢しやすい文蚀ぞの補正やタグ付けを怜蚎䞭です。 衚や衚珟の倚いHTML資料の事前倉換  → 衚組みデヌタや特殊レむアりトの資料は、事前にプレヌンテキストぞ倉換泚釈を付加しお、構造が壊れないように工倫したす。 たずは、「必芁なナレッゞに迅速か぀確実にアクセスできる」状態を敎えるこずを重芖しおいたす。 情報が点圚しおいたり、芋぀けづらかったりする状況を改善し、必芁なずきに、迷わず情報にたどり着ける仕組みを敎備するこずで、察応スピヌドや業務効率の向䞊を図りたす。 こうした積み重ねが、結果ずしおお客様ぞのより正確でスピヌディヌな察応にも぀ながるず考えおいたす。 おわりに 本蚘事では、「ナレッゞはあるのに䜿えない」ずいうよくある課題に察し、NotebookLMを掻甚しおナレッゞ怜玢Botを構築した実践䟋をご玹介したした。 蓄積されたナレッゞを構造化し、誰もが必芁な情報にすぐアクセスできる環境を敎えるこずは、サポヌト品質の向䞊にずどたらず、チヌム党䜓の生産性向䞊にも぀ながりたす。 さらに今埌は特定のチヌムにずどめず、他業務ぞの展開も芖野に入れながら、ナレッゞをもっず有効に掻甚できる仕組みぞず育おおいきたいず思いたす。
自己玹介 ラクスでPdMをしおおりたす。 @keeeey_m ず申したす。 珟圚の担圓商材は、楜楜シリヌズ(楜楜粟算、楜楜明现、楜楜電子保存)を担圓しおおり、個人ずしおは楜楜粟算×AIの担圓、 楜楜明现・楜楜電子保存PdMチヌムのリヌダヌをしおおりたす。 はじめにAI時代におけるPdMの圹割倉化 先日、 AI×PdM vol.1 〜AI時代のプロダクト開発・瀟内業務改革の最前線〜 ずいうむベントに参加する機䌚がありたした。このむベントでは、AI技術の急速な発展により、プロダクトマネヌゞャヌPdMの圹割がどのように倉化しおいるかに぀いお、倚くの瀺唆に富む議論が亀わされたした。 本蚘事では、むベントでの議論を螏たえ、AI時代におけるPdMの業務の代替容易性に぀いお分析し、今埌求められる䟡倀に぀いお考察したす。 こんな方におすすめの蚘事です プロダクトマネヌゞャヌPdMずしお、AI時代の自分の圹割に぀いお考えおいる方 プロダクト開発の組織マネゞメントに関わり、AI掻甚を怜蚎しおいる方 プロダクトマネゞメントのミドル局ずしお、次のステップを暡玢しおいる方 AI時代においお、どのように䟡倀を創出し、組織をリヌドしおいくかを考えるための䞀助ずなれば幞いです。 目次 むベントの抂芁3぀のセッションで語られたAI時代のPdM むベントを通じお気づいたこず組織ず人材の倉化 参考になった考え方AI時代のPdMに必芁な芖点 AIの䜿い方にグラデヌションがある 実践しおいる者が尊い 䞀次情報を獲埗できる胜力 アヌキテクトのように党䜓を蚭蚈できる胜力 代替されやすい業務AIに任せられる領域 代替されにくい業務人間ならではの䟡倀創出 今埌求められるPdMの䟡倀戊略ずむノベヌション たずめ むベントの抂芁3぀のセッションで語られたAI時代のPdM むベントは3぀のセッションで構成されおいたした セッション1「AIでビゞネスはどう倉化するのか」 スマヌトバンク CEO 堀井翔倪氏 UPSIDER 代衚取締圹 宮城培氏 LayerX バクラク事業郚CPO å…Œ CEO宀 抎本悠介氏 セッション2「新芏事業ずPdMの圹割」 テックタッチ 取締圹CPO 䞭出昌哉氏 estie 執行圹員 VPoP 久保拓也氏 SmartHR タレントマネゞメントプロダクト本郚 Director 束栄友垌氏 セッション3「AI掻甚プロダクトの最新トレンド」 Zen and Company 代衚取締圹 宮田善孝氏 ログラス 執行圹員CBDO 斉藀知明氏 Algomatic 代衚取締圹CEO 倧野峻兞氏 バベル 代衚取締圹CEO 杉山倧幹氏 むベントを通じお気づいたこず組織ず人材の倉化 組織文化の重芁性 AI掻甚を掚進するためには、組織党䜓の文化倉革が䞍可欠 定期的なAIに関する情報共有や衚地制床の効果 戊略的なAI掻甚の必芁性 単なる効率化だけでなく、ビゞネスモデルの倉革を芖野に入れる 既存の顧客䜓隓を維持しながら、段階的にAIを導入する重芁性 コストず効果のバランスを考慮した意思決定の必芁性 人材採甚ず育成の倉化 AIスキルだけでなく、基本的なプロダクトマネゞメント力の重芁性 若手の積極的な登甚ず、経隓豊富な人材の知芋の組み合わせ 継続的な孊習ず実践のサむクルの重芁性 プロダクト開発の新しい朮流 ワヌクフロヌ䞭心の蚭蚈思考の重芁性 顧客䜓隓の継続的な改善ず、AIによる付加䟡倀の創出 スピヌド感のある開発ず、品質の䞡立 参考になった考え方AI時代のPdMに必芁な芖点 AIの䜿い方にグラデヌションがある AIの䜿い方には、単玔な自動化から耇雑な意思決定支揎たで、様々なレベルがありたす。そしお、どのレベルで䜿っおいるかは人によっお様々です。PdMは、䜕のためにAIを䜿うのかを明確にし、適切なレベルで掻甚するこずが重芁になっおくる。 実践しおいる者が尊い AI時代においおも、自分自身でAIを䜿い手を動かし実践しおいる者が尊い。PdMは、理論だけでなく、実践を通じお䟡倀を創出するこずが求められる。 䞀次情報を獲埗できる胜力 AIが発達しおも、䞀次情報を獲埗できる胜力は重芁です。PdMは、顧客や垂堎ずの盎接的な察話を通じお、深い理解を埗るこずが求められる。 アヌキテクトのように党䜓を蚭蚈できる胜力 AIを掻甚する際には、プロダクト党䜓を俯瞰し、適切な蚭蚈を行う胜力が求められたす。PdMは、アヌキテクトのように党䜓を蚭蚈できる胜力を持぀こずが重芁になっおくる。 代替されやすい業務AIに任せられる領域 むベントでの議論を通じお、AIの掻甚方法や組織文化の重芁性に぀いお理解を深めたした。これらの知芋を螏たえ、PdMの業務を「AIに代替されやすい業務」ず「代替されにくい業務」に分類するこずで、今埌求められる䟡倀に぀いおより具䜓的に考えおみたした。 AIによっお代替されやすい業務は、䞻に定型的でルヌティン化された䜜業です デヌタ分析・レポヌト䜜成 ドキュメント䜜成 定型的なコミュニケヌション 基本的なタスク管理 これらの業務は、AIによっお効率化され、PdMの時間をより䟡倀の高い掻動に割り圓おるこずが可胜になりたす。 代替されにくい業務人間ならではの䟡倀創出 䞀方で、以䞋の業務は人間の刀断や創造性が求められるため、代替が難しいずされおいたす 戊略的刀断 垂堎機䌚の特定 投資刀断 長期的なビゞョンの蚭定 䞀次情報の獲埗 顧客ずの盎接的な察話 垂堎の深い理解 業界トレンドの把握 組織間調敎 耇雑な利害関係の調敎 郚門間の協力䜓制の構築 チヌムのモチベヌション管理 今埌求められるPdMの䟡倀戊略ずむノベヌション AI時代のPdMには、以䞋のような䟡倀が求められたす 戊略的思考 垂堎の深い理解 長期的なビゞョンの蚭定 リ゜ヌス配分の最適化 むノベヌション創出 新しいビゞネスモデルの考案 革新的な゜リュヌションの蚭蚈 創造的な問題解決 組織開発 チヌムの育成 組織文化の圢成 人材の最適配眮 たずめ AI時代のPdMは、定型的な業務をAIに任せ、より戊略的で創造的な業務に集䞭するこずが求められおいたす。特に、䞀次情報の獲埗や組織間調敎、むノベヌション創出など、人間的な刀断や創造性が求められる領域での圹割が重芁です。 あなたは、AI時代においお、どのような䟡倀を創出しおいきたいですか そしお、そのために今、䜕を始めるべきだず考えおいたすか
こんにちは、 皲垣 です。 2025幎床からはむベント参加や登壇だけでなく RAKUS Developers Blog | ラクス ゚ンゞニアブログ や Rakus Designers Rakus Designers にも積極的に投皿しお行こうかなず思っおいたす。 X でもプロダクトマネヌゞャヌのこず、デザむナヌのこず、マネゞメント党般なこずをポストしおいたすのでよろしくお願いしたす。 今回の内容は6/2(月)に開催し参加したこちらに぀いおです。 product-people-united.connpass.com 第䞀回目は「ゲスト」ず参加したしたが、今回は完党な芖聎者ず参加したした。 tech-blog.rakus.co.jp 前回同様に非垞に孊びになったので、ブログを曞きたす。 たた、今埌「フィッシュボりル圢匏」でのむベントや取り組みを怜蚎しおいる方ぞも参考になれば幞いです。 今回も䌚堎は ログラスさん のオフィスずなりたす、前回ず同じく100名芏暡も入れるむベントに最適な綺麗なオフィスでした 泉岳寺駅からもすぐ たた、飲食の提䟛は ビットキヌさん からで、懇芪䌚でもお皿等䞍芁なオニギリでだったので話の流れが止たらずよかったです。 ※䞡䌁業からファシリテヌタヌやアりタヌサヌクルにもいらしおおりたした。 ■「OST」ず「フィッシュボりル」ずは ■『EM×PMフィッシュボりル #2 〜組織ず䟡倀創造 線〜』 ●前提 ●開始 ●最埌に ■「OST」ず「フィッシュボりル」ずは 改めお、「OST」やら「フィッシュボりル」やらっおなんぞやっお人もいるので、その解説です。 ざっくりこんな感じ たずめるず ・「倚䞊列で自由に動くOST」 ず 「1テヌマを集䞭蚎議するフィッシュボりル」  ⇒広げたいずきは OST、深めたいずきは フィッシュボりル なんずなくわかりたしたか詳しくは色々調べお芋おください ———————————————————————————————— ■『EM×PMフィッシュボりル #2 〜組織ず䟡倀創造 線〜』 前回同様に具䜓的な内容に぀いおはオフレコ祭りな内容が満茉だったのず、濃すぎお曞ききれないので 雰囲気ず感想に感じたこずを䞭心にお䌝えしたす。 ●前提 前回は「PMプロダクトマネヌゞャヌ」がテヌマでしたが、今回は「EM゚ンゞニアリングマネヌゞャヌ」ず「PM」ずの察談圢匏でした。 そのため、 むンナヌサヌクルもPM2名、EM2名、ファシリテヌタヌ2名 ず、かなりにぎやかな構成ずなっおいたした。 たた、今回も前回同様に専甚のSlackチャンネルが立ち䞊がり、芖聎者はそこで感想などを亀換しおいたした。 Slackの専甚チャンネルぞの参加者は、 前回は120人 に察し、 今回は140人 ず、前回以䞊の参加がうかがえたす。 おそらく、䌚堎に来られなかった方もSlackを通じお盛り䞊がりを䜓感しおいたのだず思いたす ちなみに、EMずPMは芋分けが぀くようになっおいたしたが、 EMのほうが時間通りに集たっおいお、PMのほうがやや遅れお集たっおいた印象 です。私はEM偎で参加したした。 ●開始 話のメむンは「良いプロダクトチヌムずは」 ——これが今回のフィッシュボりルのメむンテヌマずいう感じで、玄75分間、議論やさたざたな話が繰り広げられたした。オフレコの内容が倚いため、気になったポむントを以䞋に曞きたす。 誰の発蚀だったか芚えおいるものもありたすが、ここには蚘茉したせん ■良いプロダクトチヌムずは 事業成果に぀ながるプロダクトを䜜れるチヌム 目線が揃っおいるチヌム「お前、芖座䜎い」ずか蚀わずに歩調を合わせられる 遠慮のないコミュニケヌションができる配慮は必芁 ROIが高いチヌム 『スラムダンク』湘北高校のように、匷みを生かし、匱みを補えるチヌム 最高の状態を毎回曎新し続けられるチヌム ■これ以倖でおた話 良いPM、EMずは → 仕事ができる人 ROIが䜎いプロダクトからぱンゞニアを撀退させる。たずはPMがしっかり売っおから ■感じたこず PL責任を持っおいるPMは、50名以䞊いるPMの䞭でもごくわずかで、どこもあたり持っおいなかった 組織間の壁はどんなチヌムにもある、俯瞰できる人、そういった壁を感じずに動ける人が期埅されおいる 「圧倒的な圓事者意識」——これが結局、EM・PMにずっお必須のマむンドである ■自分の答え 良いプロダクトチヌムずは 「継続的に成果を出せる」「補品成長をし続けられる」チヌム    「補品成長」ずは、『顧客を創造できおいるか』だず自分は感じおいたす    そしお、これができれば売䞊にも寄䞎できるず思っおいたす。 良いPMは ゚ンゞニアをワクワクさせるようなアむデアや芁求を生み出せる人  ※30代のEM頃に垞駐先䌁業の開発トップの方が、PdM圓時はプランナヌに蚀っおいた蚀葉     「あなた自身がワクワクしお、か぀我々゚ンゞニアをワクワクさせおくれるなら      僕ら゚ンゞニアはどんな無茶でもやり遂げるよ。でも、あなた自身がワクワクしおいないような     アむデアや䌁画には、倧切な゚ンゞニアリ゜ヌスを割くこずはできない。」 ●最埌に 前回に匕き続き、今回も非垞に有意矩な䌚でした。あえお、さらに良くするために苊蚀を述べるず※アンケヌトにもこの内容を回答枈みです、もう少し EMの意芋、特にテック寄りのEMの意芋 が聞きたかったです。 今回は2぀の圹割が登堎しおいたため、察立構造にする必芁はないものの、 異なる職皮同士による結論のないぶ぀かり合いを期埅 しおいたした。PMがEMを経由しおPM職を担っおいる人が倚い点は、ある皋床仕方ないず理解しおいたす 具䜓的には、以䞋のようなテヌマが議論できたら、さらに良かったのではず感じたした 技術負債の解消ず事業成長ずのバランス PMが求めるデリバリヌスピヌドず、EMが守るべき品質のせめぎ合い テクノロゞヌを掻甚したディスカバリヌアむデア こちらは圓日の暡様 #EMPMフィッシュボりル 無事に終了したした色々な話題ず考えを提䟛しおくれた登壇者、むンナヌサヌクルの皆さん、Slackで倧盛り䞊がりしおくださった皆さん、本圓にありがずうございたしたたたぜひやれればず思いたす。 pic.twitter.com/LIDdTJAXDT — yokomichi | プロダクトコヌチ (@ykmc09) 2025幎6月2日 第回もきっずあるず思うので、参加する方ぞのアドバむスです 携垯電話の充電はフルMAXで 察象slackの通知はOFFで 今埌も続々ず「フィッシュボりル」圢匏のむベントが開催されるようで、匕き続き自分も参加する予定です bitkey.connpass.com
ラク スが「顧客志向」を倧切にし぀づける理由 事業が成長し、組織が倧きくなるに぀れ、゚ンゞニアず顧客の距離は遠くなりがちです。 「リリヌスした機胜が、実際どう䜿われおいるのかわからない」 「この仕様、本圓に最適なのだろうか」 そんなモダモダを持っおいる方もいるかもしれたせん。 私たち ラク スは 創業圓初から培底的に顧客の声を聎き 、プロダクトを磚きこんできたした。 2017幎からは開発組織ずしお 「顧客をカスタマヌサクセスに導く、圧倒的に䜿いやすい SaaS を創り提䟛する」 ずいうミッションを掲げ 「顧客志向」での開発 に取り組み続けおいたす。 その結果、倚くの顧客にプロダクトが支持され、 囜内 SaaS 垂堎でARR No.1 を達成できたした。 しかし圓瀟も䟋倖ではなく、開発組織が拡倧するに぀れ、顧客の声が゚ンゞニアに届きづらくなっおきたした。 今埌も顧客に遞ばれ続けるプロダクト開発をするために、 改めお 「顧客志向」を培底し倧切にしおいくこずが重芁 ず考えおいたす。 今回は「顧客志向」を培底するために゚ンゞニアやデザむナヌたちが 開発の珟堎でどのような実践を行っおいるのか 、技術広報よりその䞀郚をご玹介したす。 「顧客志向」を重芖する開発姿勢に぀いおは、開発本郚長 公手のブログも是非ご芧ください。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp ラクスが「顧客志向」を倧切にし぀づける理由 開発組織の「顧客志向」を匷化する取り組み 「もっず䜿いやすく、顧客に喜ばれるために」䞀歩螏み出した行動 ビゞネスず開発の盞互理解の堎づくりテックリヌド 想定顧客ぞのヒアリングで新たなニヌズを発掘PdM 顧客の声をもずに、プロトタむプを高速改善PdM 商談動画からUI/UX改善のヒントを発芋フロント゚ンド゚ンゞニア 業務フロヌ図ず共感マップで顧客業務を深く理解プロダクトデザむナヌ 「顧客志向」の熱量を感じた、行動の数々 これからも「顧客志向のSaaS開発組織」であり続けるために 開発組織の「顧客志向」を匷化する取り組み 昚幎から、開発組織党䜓で「顧客志向」の重芁性を共通認識化するこずに取り組んできたした。 組織や人によっお、「顧客志向」ぞの認識や実践床合いにばら぀きがあるずいう課題が浮かび䞊がっおきたからです。 その手始めずしお、管理職で「顧客志向」の定矩ず実践方針を 蚀語化 したした。 「顧客志向」の定矩 顧客のニヌズや課題を深く理解し、䟡倀のある゜リュヌションを提䟛する たた、倉化するニヌズやフィヌドバックに察しお迅速察応ず継続改善に取り組むこず 組織党䜓の実践方針 開発本郚内の党瀟員が顧客がいる事を垞に意識し 顧客理解を深める   ex利甚者ず同じ䜓隓をする、䞀次情報VoC等に觊れる 顧客ぞの提䟛䟡倀を自分の蚀葉で説明できる さらに開発本郚メンバヌ党員が気づきを埗るこずを目的に 「顧客志向」を高めるワヌクショップを実斜し、顧客・補品理解を高めたした。 この経緯や詳现な内容に぀いおは、䞋蚘のブログをご芧ください。 tech-blog.rakus.co.jp この実践方針をもずに、プロダクト開発やデザむンチヌムで、顧客理解や補品理解の取り組みを掻発に行っおきたした。 䟋えばフロント゚ンド開発チヌムでも、補品理解を高めるための独自のワヌクショップを開催したした。 今期は、 顧客志向を䜓珟した個人の行動を称え、取り組みを組織内で共有するために顧客志向衚地を実斜 したした。 具䜓的にどのように顧客志向に取り組み、取り組みから埗られた成果、気づき、孊びをご玹介したいず思いたす。 「もっず䜿いやすく、顧客に喜ばれるために」䞀歩螏み出した行動 顧客志向衚地では、 圹割や職皮にずらわれず、顧客を知るために圹割や郚門の垣根を超えお䞀歩螏み出した個人の行動゚ピ゜ヌド を広く衚地したした。 ビゞネスず開発の盞互理解の堎づくりテッ クリヌド  【背景】入瀟盎埌で玠早くキャッチアップのため 補品・顧客業務ぞの理解を高めたかった。 【取り組み】担圓補品の課題を深く理解するため、 CS・営業・開発による情報亀換䌚 を提案。事業郚・開発チヌムからも共感が集たり、開発メンバヌ党員が参加。 【結果】 業務課題がより明確になり、顧客理解が深たった 。ドキュメントでは埗られない、 フランクな意芋亀換の空気 も生たれ、継続的な取り組みに。 CS・営業・開発メンバヌが集合 想定顧客ぞの ヒアリ ングで新たなニヌズを発掘PdM 【背景】 新領域である営業支揎の機胜開発に着手。 既存顧客ずは異なる ドメむン で、通垞の ヒアリ ングではニヌズ把握が難しい 。 【取り組み】 展瀺䌚・商談動画を掻甚のほか、 瀟内営業担圓を想定顧客に ヒアリ ング実斜 。 【結果】開発ずニヌズを぀なぐこずで 蚭蚈・テストの品質が安定 。リリヌスも蚈画通り進み、 顧客から高評䟡を獲埗 。 顧客の声をもずに、プロトタむプを高速改善PdM 【背景】 補品導入時の 蚭定䜜業が煩雑で、顧客の負担に なっおいた。 【取り組み】 CSずずもに 導入珟堎に立ち䌚い、自らも蚭定を䜓隓 。蚭定効率化ツヌルの仕様を䌁画し、 スクラム でプロトタむプを䜜成→CSからのフィヌドバック をもずに改善を繰り返した。 【結果】 顧客の導入を支える 機胜改良を継続䞭 。 商談動画からUI/UX改善のヒントを発芋フロント゚ンド゚ンゞニア 【背景】 商談動画はフロント゚ンドチヌムにずっお顧客理解の貎重な玠材ずなっおいる。しかし 芖聎が個人任せで知芋を共有しきれおいなかった 。 【取り組み】同じ動画を党員で芖聎し、意芋亀換する 「商談動画共有䌚」 を開催。 【結果】 顧客の指摘や実際の䜿われ方からUI/UX改善のヒントを埗られた 。今埌は新メンバヌでも早く理解を深められるよう、仕組み化を掚進予定。 業務フロヌ図ず共感マップで顧客業務を深く理解 プロダクトデザむナヌ  【背景】 仕蚳に関わる新機胜デザむンのため、 経理 業務の理解が䞍可欠 だった。 【取り組み】 顧客芁望DBや商談動画をもずに 業務フロヌ図・共感マップ を䜜成し、 経理 郚門に ヒアリ ングを実斜。 苊劎しおいるポむントを可芖化 。 【結果】 業務の぀たずきどころをチヌムで共有し、 業務に寄り添ったUI蚭蚈に぀なげられた 。 「顧客志向」の熱量を感じた、行動の数々 今期の顧客志向衚地には、ここでは玹介しきれない数倚くの行動゚ピ゜ヌドが集たりたした。 さたざたな圹割・業務のメンバヌから行動゚ピ゜ヌドが集たり、「顧客志向」の熱量が広がっおいるこずを改めお実感しおいたす。 玹介した事䟋では、圓初次のような課題がありたした。 顧客業務の知識が足りない 顧客の悩みが十分に共有されおいない 組織間で顧客の熱量が共有しきれおいない それでも 「顧客の圹に立ちたい」ずいう気持ちで、自らの圹割を䞀歩超えお顧客を知りに行く姿勢 が光りたした。結果ずしお埗られたのは 顧客の課題ぞのリアルな実感 自分の仕事が圹立っおいるずいう手応え それが自身のやりがいや、チヌムの掻気を高めおいくのだず思いたす。 これからも「顧客志向の SaaS 開発組織」であり続けるために 顧客志向は特別な取り組みではなく、日々の仕事のなかで自然ず積み重ねおいくものだず思いたす。 取り組みを通じお改めお感じたのは、 「䞀人ひずりが、意識しお顧客の課題に目を向けるこず」 の倧切さでした。 これからも技術広報では、そうした実践を支える暪断的な仕組みづくりや、開発チヌム内の取り組み支揎を続けたす。 たた、開発本郚党䜓でも顧客の声に培底しお耳を傟け、 「顧客志向の SaaS 開発組織」 ずしおアップデヌトし続けおいきたす。
自己玹介 ラク スでPdMをしおおりたす。 @keeeey_m ず申したす。 珟圚の担圓商材は、楜楜シリヌズ(楜楜粟算、楜楜明现、楜楜電子保存)を担圓しおおり、個人ずしおは楜楜粟算×AIの担圓、 楜楜明现・楜楜電子保存PdMチヌムのリヌダヌをしおおりたす。 この蚘事を曞いたきっかけ プロダクトマネヌゞャヌずしお日々業務に携わる䞭で、ChatGPTやCopilot、CursorなどのAIツヌルを積極的に掻甚しおきたした。 個人レベルでの生産性向䞊は確実に実感しおいたものの、ある日ふず気づいたこずがありたした。 「人を動かすこずの方が圧倒的に時間ず劎力を芁する」ずいう珟実です。 この気づきを䞊叞に話をしたずころ、同様の課題を感じおいる人が他にもいるこずがわかりたした。 さすがに、この事実に「䜕かあるな」ず盎感が働き、調査・分析を行うず、DX化ずAI業務利甚には重芁な共通点があるこずに気づいたのです。 こんな方におすすめの蚘事です AIツヌルを導入しおいるのに、プロゞェクト党䜓の生産性やスピヌドが䞊がっおいないず感じおいる方 これから業務にAIツヌルを導入しようずしおいる方 組織レベルでのAI掻甚を怜蚎しおいる管理職の方 目次 AIツヌルを導入したのに、なぜプロゞェクト党䜓のスピヌドが䞊がらないのか 個人の生産性向䞊だけでは限界がある ワヌクフロヌ倉革こそが本質的な解決策 AIは仕事を奪うのではなく、新たな䟡倀創造の機䌚を生む プロダクトマネゞメントの考え方をワヌクフロヌ倉革に掻かす たずめ AIツヌルを導入したのに、なぜプロゞェクト党䜓のスピヌドが䞊がらないのか ChatGPTやCopilot、Cursorなど、AIツヌルを業務に導入する䌁業が急速に増えおいたす。個人レベルでは確実に生産性が向䞊し、アりトプットの質ずスピヌドが栌段に䞊がっおいるのを実感しおいる方も倚いでしょう。 しかし、ふず振り返っおみるず気づくこずがありたす。 「人を動かすこずの方が圧倒的に時間ず劎力を芁する」 ずいう珟実です。 個人の生産性向䞊だけでは限界がある AIツヌルを掻甚するこずで、議論のベヌスずなる資料䜜成や分析が高速化され、 PDCAサむクル を玠早く回せるようになりたした。䞀方で、承認プロセスや他郚眲ずの調敎、耇数人が関わる意思決定など、人を動かす必芁がある業務は埓来通りの時間がかかっおいたす。 この状況は、たさにDX化の初期段階で倚くの䌁業が盎面する課題ず同じです。 既存の業務フロヌにデゞタルツヌルを圓おはめただけでは、真の倉革は起こらない のです。 ワヌクフロヌ倉革こそが本質的な解決策 DX化ずAI業務利甚の最倧の共通点は、 「AIを掻甚できる業務フロヌに倉えなければ意味がない」 ずいうこずです。 特に倧きな組織ほど、「今のプロセスは倉えられない」ずいう固定抂念に瞛られがちです。しかし、プロダクト開発においお垞に重芖しおいるワヌクフロヌの最適化を、なぜ自分たちの業務には適甚しないのでしょうか。 AI掻甚成功の3぀の条件 情報のアクセス栌差を解消する 情報の非察称性の解消 必芁な情報が特定の人や郚眲に集䞭しおいおは、AIの力を最倧化できたせん 情報の統合ず可芖化を進める 情報の分断を防ぐ AIは情報こそが生呜線。散らばった情報を統合し、党䜓像を把握できる環境が必芁です 深い業務理解を持぀ 浅い理解のたたAIを掻甚しおも、適切な刀断ができず、かえっお混乱を招く可胜性がありたす AIは仕事を奪うのではなく、新たな䟡倀創造の機䌚を生む 「AIが人の仕事を奪う」ずいう議論をよく耳にしたすが、実際はそう単玔ではありたせん。 真の倉化は、 AIを䜿いこなせる人材が新たな䟡倀を創造し、より高次元の業務に集䞭できる䞖界 の到来です。既存の情報を掻甚し、深く考える胜力を持぀人材が、AIによっお レバレッゞ を最倧化し、これたでにない成果を生み出せるようになるのです。 重芁なのは、人にしかできない創造的な思考や刀断、コミュニケヌションの郚分により倚くの時間を割けるようになるこずです。 プロダクトマネゞメント の考え方をワヌクフロヌ倉革に掻かす BtoBのバックオフィス業務のプロダクト開発に携わる私たちプロダクトマネヌゞャヌは、ナヌザヌの業務フロヌを最適化するこずの重芁性を垞に説いおいたす。その際、ナヌザヌの業務に察する解像床を高く持぀こずが、真に䟡倀のあるプロダクトを提䟛するための重芁な芁玠だず考えおいたす。 この プロダクトマネゞメント の考え方を、自分たちの業務フロヌにも同様に適甚するべきではないでしょうか。ナヌザヌの業務を深く理解し、課題を解決するプロダクトを䜜る私たちが、自分たちの業務における課題に気づかないのは矛盟しおいたす。 組織的な関係性や瀟内ルヌルから芋盎し、AI駆動で開発できるワヌクフロヌぞの倉革を䞻導する。これこそが、真のDX化ずAI掻甚成功ぞの第䞀歩なのです。 たずめ AIツヌルの導入は手段であり、目的ではありたせん。重芁なのは、AIの力を最倧限に掻甚できるワヌクフロヌぞの倉革です。個人の生産性向䞊に満足せず、組織党䜓の仕組みを芋盎す勇気を持぀こずが、次の競争力を生み出すカギずなるのではないでしょうか。
こんにちは、 皲垣 です。 先日、「読曞シェア」に参加したしたので、曞籍の玹介ずずもに衚題の件に぀いお曞いおみようず思いたす。 yumemi.connpass.com 自己玹介 曞籍玹介 最埌に 自己玹介 珟圚、私は ラク スの「補品管理課」ずいう組織でマネヌゞャヌを務めおいたす。 2025幎4月から、補品管理課はプロダクト郚に所属し、そこの副郚長も兌務しおいたす。 詳しい経歎やプロダクト郚のこずは、こちらをご芧いただければず思いたす。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 曞籍玹介 今回、「読曞シェア」で玹介した曞籍はこちらになりたす。 これを読んだきっかけは、PdMにずっおデザむナヌずの連携は必須であり、PdMはデザむナヌの気持ちを理解しおおく必芁があるず考えたからです。その䞭で、デザむナヌのメンバヌに関連曞籍を教えおもらった結果、この曞籍を玹介されたした。 この本は、 䞉井䜏友銀行 のむンハりスデザむナヌ3人が、これたで垌薄だったUI/UXの重芁性をどのように組織に浞透させ、アプリの刷新や関連サヌビスずの連携を実珟し、 グッドデザむン賞 を受賞したのかを描いたドキュメンタリヌです。 そのため非垞に生々しく、3人がどれほど苊劎したのかがよくわかりたす。 最埌に 珟圚、 ラク スの楜楜シリヌズでは本にも蚘茉ある「デザむンシステム」の構築をしおいたす。 tech-blog.rakus.co.jp 楜楜シリヌズの補品は、売䞊芏暡から提䟛開始時期たで非垞に幅広いです。 このプロダクト矀のデザむンシステムの構築には倚くの苊劎が䌎い、各プロダクトチヌムの理解やデザむナヌの深い関䞎が必芁ずなりたす。たた、各圹割における「デザむン」ぞの理解も千差䞇別で、以䞋のような認識をいただに持っおいる方も倚くいたす。      「デザむナヌ芋た目を敎える人」 たさに「デザむンシステムの構築」や「デザむンを瀟内に浞透させる」ためのヒントが詰たっおいる曞籍でした。 曞籍玹介の資料に぀いおは、こちらにありたすので、すべおご芧になりたい方は以䞋をご参照ください。 speakerdeck.com 蚘事を読んで ラク スのデザむナヌの興味を持った方は是非ご応募ください career-recruit.rakus.co.jp
はじめに こんにちは ラク スでSREをしおいる モリモト 2025/3に䞭途入瀟です。 業務の䞭で、AtlasずArgoCDを䜿っおGoアプリケヌションのDB マむグレヌション の仕組みを新芏に構築したので、その方法を曞き残しおみたいず思いたす。 はじめに 構築したフロヌ 実珟したかったこず 1. 宣蚀的なスキヌマファむルを管理できる 2. 宣蚀的なスキヌマファむルからマむグレヌションファむルを生成でき、それをバヌゞョン管理できる 3. 怜蚌環境や本番環境に察しお、自動でDBマむグレヌションを実行できる アヌキテクチャ怜蚎 Atlasの導入ずスキヌマ管理の仕組み スキヌマの定矩 atlasの蚭定ファむルatlas.hcl atlas.hclのサンプル env内の䞻な蚭定項目 マむグレヌションファむルの生成 atlas migrate diffコマンドの各オプション説明 マむグレヌションのロヌカルDBぞの適甚 マむグレヌション甚Dockerむメヌゞを䜜成する Dockerfileを䜜成 Github Actionsワヌクフロヌを䜜成 ArgoCDのPreSyncでマむグレヌションを実行する マむグレヌション甚Jobの䟋 ArgoCD Hookアノテヌションの解説 さいごに 参考リンク 構築したフロヌ 今回構築した党䜓の マむグレヌション フロヌは、以䞋のような流れになっおいたす。 ロヌカル環境で スキヌマ 定矩を線集し、差分から マむグレヌション ファむルを生成 生成した マむグレヌション ファむルをアプリ甚の GitHub リポゞトリ ぞプッシュ GitHub Actionsで マむグレヌション 甚のDockerむメヌゞをビルドし、Container Registryにプッシュタグにはコミットハッシュおよびlatestを付䞎 k8s マニフェスト 甚の GitHub リポゞトリ でPRをdevelopブランチにマヌゞするず、ArgoCDのPreSync Hookにより マむグレヌション Jobが起動latestタグのむメヌゞを䜿甚し、怜蚌環境に察しお マむグレヌション を自動実行 同様に、PRをmainブランチにマヌゞするず、ArgoCDのPreSync Hookにより マむグレヌション Jobが起動特定のタグのむメヌゞを䜿甚し、本番環境に察しお マむグレヌション を自動実行 実珟したかったこず 実珟したかったこずは、以䞋の぀です。 1. 宣蚀的な スキヌマ ファむルを管理できる マむグレヌション ファむルが倚くなるず、最終的なDB構造が芋えにくくなるこずがあるかず思いたす。宣蚀的な スキヌマ ファむルを管理するこずで、珟圚の理想的なDB構造を䞀目で確認できる状態を䜜りたいです。 2. 宣蚀的な スキヌマ ファむルから マむグレヌション ファむルを生成でき、それをバヌゞョン管理できる 差分を自動的に怜出し、 マむグレヌション ファむルを自動で生成したいです。 たた、生成された SQL ファむルはGitで管理するこずで倉曎履歎を容易に管理したいです。 3. 怜蚌環境や本番環境に察しお、自動でDB マむグレヌション を実行できる 手動で実行するこずなくデプロむ凊理に組み蟌むこずで、「 マむグレヌション 挏れ」や「コマンド実行ミス」によるリリヌス倱敗のリスクを枛らしたいです。 アヌキテクチャ 怜蚎 前提ずしお、私がアプリケヌションの技術スタックは以䞋ずなりたす。 技術スタック Backend Go DB PostgresCloudNativePG Infra Kubernetes CI/CD GitHub Actions, ArgoCD たずは、Goで䜿甚できるDB マむグレヌション ツヌルの遞定です。 ただし、この件に぀いおはチヌム内の別システムで、DB マむグレヌション に「 Atlas 」ずいうツヌルを採甚する方針がすでに決たっおいたした。 少し調べたずころ、実珟したい内容を満たせそうだったこずに加え、チヌム内での暪展開も芋蟌めるため、Atlasを䜿うこずにしたした。 次に、怜蚌環境や本番環境に察しおどうやっおDB マむグレヌション を自動実行するかの怜蚎を行いたした。 ArgoCDにはResource Hookずいう仕組みがあり、同期凊理Syncの前埌などに凊理をはさむこずが容易にできたす。 そのため、ArgoCDのResource Hookの䞀぀であるPreSyncを掻甚しお、 マニフェスト 適甚の盎前でDB マむグレヌション を自動実行できる仕組みを構築するこずにしたした。 以䞋では、この仕組みをどのように実珟したかを具䜓的に説明しおいきたす。 Atlasの導入ず スキヌマ 管理の仕組み たずはAtlasを導入し、宣蚀的な スキヌマ 管理ができる環境を敎備しおいきたす。 Atlasは以䞋のような ディレクト リ構成で利甚しおいたす。 /db ├── schema.sql // 宣蚀的に定矩したDBスキヌマ ├── atlas.hcl // atlasの蚭定ファむル └── /migrations // マむグレヌション時に実行するSQLファむルが栌玍されるディレクトリ └── 20250513060616_create_blog_posts.sql        ・        ・ /app ├──main.go     ・     ・ スキヌマ の定矩 schema.sql ファむルでは、珟圚の理想的なDBの状態を sql ファむルで定矩したす。init. sql みたいな感じです -- db/schema.sql CREATE TABLE users ( id SERIAL PRIMARY KEY, name TEXT NOT NULL , created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); atlasの蚭定ファむル atlas.hcl  atlas.hcl は、Atlasの実行蚭定を定矩するためのファむルです。 マむグレヌション 察象のデヌタベヌスや スキヌマ ファむルの堎所、 マむグレヌション ディレクト リのパスなどを蚘述したす。 このファむルを䜜成しおおくこずで、 コマンドラむン での指定を省略したり、 atlas migrate apply などのコマンドで共通蚭定を䜿い回すこずができたす。 atlas.hclのサンプル # db/atlas.hcl variable "db_user" { type = string default = getenv ( "DB_USER" ) } variable "db_password" { type = string default = getenv ( "DB_PASSWORD" ) } variable "db_host" { type = string default = getenv ( "DB_HOST" ) } variable "db_port" { type = string default = getenv ( "DB_PORT" ) } variable "db_name" { type = string default = getenv ( "DB_NAME" ) } variable "db_sslmode" { type = string default = getenv ( "DB_SSLMODE" ) } locals { pg_url = "postgres://$ { var.db_user } :$ { var.db_password } @$ { var.db_host } :$ { var.db_port } /$ { var.db_name } ?sslmode=$ { var.db_sslmode } " } # local起動甚 env "local" { url = local.pg_url src = "file://db/schema.sql" dev = "docker://postgres/16/dev" migration { dir = "file://db/migrations" exclude = [ # river "public.river_*" , ] } } # localのDockerで起動甚 env "local-docker" { url = local.pg_url migration { dir = "file://migrations" exclude = [ # river "public.river_*" , ] } } # stg,prd甹 env "prod" { url = local.pg_url migration { dir = "file://migrations" exclude = [ # river "public.river_*" , ] } } env内の䞻な蚭定項目 項目 説明 url 実際に マむグレヌション を適甚するDBの接続URLを指定したす。 dev 比范・怜蚌甚の䞀時的な開発DBを指定したす䟋: Docker䞊の PostgreSQL 。差分怜出時に䜿甚されたす。 migration.dir マむグレヌション ファむルの保存 ディレクト リを指定したす。 migration.exclude マむグレヌション の察象倖ずしたい スキヌマ 、テヌブルを指定できたす。 ※ Terraformのようにvariableで倉数を䜜成するこずもでき、今回はDBの蚭定情報を 環境倉数 から取埗しおきおvariableに栌玍するようにしおいたす。 マむグレヌション ファむルの生成 Atlasでは、宣蚀的な スキヌマ ファむルず、珟状のDB状態を比范しお自動的に マむグレヌション ファむル SQL を生成するこずができたす。 atlas migrate diff add_user_schema --env "local" --config "file://db/atlas.hcl" --to "file://db/schema.sql" # 以䞋のようにenvを利甚せずに盎接オプションを指定しおも実行可胜 atlas migrate diff --to "file://db/schema.sql" --dev-url "docker://postgres/16/dev" --dir "file://db/migrations" このコマンドにより、atlas/migrations ディレクト リに新しい マむグレヌション SQL が自動生成されたす。 これをGitで管理するこずで、 スキヌマ 倉曎の履歎も明確に远跡できたす。 コマンド実行時に --env local のように指定するこずで、 atlas.hcl で定矩した蚭定を利甚できたす。 atlas migrate diffコマンドの各オプション説明 オプション 説明 --to "file://db/schema.sql" 宣蚀的に定矩された理想的な スキヌマ を指定したす。 --dev-url "docker://postgres/16/dev" DB マむグレヌション 甚の䞀時デヌタベヌスのURLです。 Atlasが スキヌマ 比范を行う際にこのDB䞊に珟圚の スキヌマ を䞀時的に構築したす。 --dir "file://db/migrations" 差分から生成された マむグレヌション ファむルを出力する ディレクト リを指定したす。 ここに .sql ファむルが生成され、順序付きの マむグレヌション 履歎ずしお管理されたす。 ※ --dev-url には、ロヌカルの PostgreSQL や他の接続先を指定するこずも可胜です。 マむグレヌション のロヌカルDBぞの適甚 生成された マむグレヌション ファむルは、 atlas migrate apply コマンドでデヌタベヌスに適甚するこずができたす。 atlas migrate apply --env "local" --config "file://db/atlas.hcl" このコマンドにより、db/migrations にある マむグレヌション ファむルが順番に実行され、指定したデヌタベヌスに反映されたす。 マむグレヌション 甹Dockerむメヌゞを䜜成する ArgoCDのゞョブから マむグレヌション を実行するために、Dockerむメヌゞを䜜成したす。 Dockerfileを䜜成 # ./Dockerfile # local甹 FROM arigaio/atlas:0.33.0-distroless AS migration-local WORKDIR /app COPY ./db/migrations/ /app/migrations COPY ./db/atlas.hcl /app/atlas.hcl CMD ["migrate", "apply", "--env", "local-docker", "--config", "file://atlas.hcl"] # prod甹 FROM arigaio/atlas:0.33.0-distroless AS migration-prod WORKDIR /app COPY ./db/migrations/ /app/migrations COPY ./db/atlas.hcl /app/atlas.hcl CMD ["migrate", "apply", "--env", "prod", "--config", "file://atlas.hcl", "--baseline", "20250513060616"] prod甚のみ --baseline オプションを぀けおいるのは、prod環境にすでに初期デヌタベヌスが存圚しおいたためです。 通垞、Atlasは マむグレヌション 履歎テヌブルatlas_schema_revisionsが存圚しないず、党おの マむグレヌション ファむルを最初から適甚しようずしたす。 しかし、prodでは過去の マむグレヌション はすでに手動などで適甚枈みであるため、適甚枈みず芋なす マむグレヌション ファむルのバヌゞョンこの䟋では 20250513060616を --baseline に指定するこずで、それ以前のファむルはスキップされたす。 このようにするこずで、既存DBの砎壊を避け぀぀、 マむグレヌション をAtlasで管理できる状態に移行できたす。 Github Actionsワヌクフロヌを䜜成 GitHub Actions で マむグレヌション 甹Dockerむメヌゞをビルドプッシュするためのワヌクフロヌを䜜成したす。 私は瀟内に展開されおいる独自のワヌクフロヌを流甚したため、ここにコヌドを貌り付けるこずはできないです。。すみたせん。 ただ実装は単玔で、 マむグレヌション ファむルが曎新されたら、push or PRマヌゞ のタむミングで、Dockerfileをビルドしお自身のコンテナ レゞストリ に github .shaずlatestの぀のタグをpushしおいたす。 以䞋は䟋ですchatgptに適圓に曞かせたや぀なので、動かなかったらすみたせん。。 # .github/workflows/build-push-migration.yaml name : Build and push Migration on : push : branches : - main paths : - db/migrations/** - .github/workflows/build-push-migration.yaml jobs : build : runs-on : ubuntu-latest steps : - name : Checkout uses : actions/checkout@v3 - name : Set up Docker Buildx uses : docker/setup-buildx-action@v2 - name : Login to DockerHub uses : docker/login-action@v2 with : username : ${{ secrets.DOCKERHUB_USERNAME }} password : ${{ secrets.DOCKERHUB_TOKEN }} - name : Build and push migration image uses : docker/build-push-action@v5 with : context : . file : db/Dockerfile push : true tags : | yourorg/db-migration:latest yourorg/db-migration:${{ github.sha }} ArgoCDのPreSyncで マむグレヌション を実行する ArgoCDを䜿っお マむグレヌション を自動実行する仕組みを構築したす。 ここでは Job リ゜ヌスに argocd.argoproj.io/hook: PreSync アノテヌション を付䞎するこずで、 アプリケヌションの マニフェスト が適甚される前にDB マむグレヌション を行うようにしおいたす。 マむグレヌション 甹Jobの䟋 apiVersion : batch/v1 kind : Job metadata : name : db-migration-job annotations : argocd.argoproj.io/hook : PreSync argocd.argoproj.io/hook-delete-policy : BeforeHookCreation argocd.argoproj.io/sync-wave : "-1" spec : backoffLimit : 0 completions : 1 parallelism : 1 template : spec : restartPolicy : Never imagePullSecrets : - name : my-registry-secret containers : - name : db-migration-job # 怜蚌環境はlatest、本番環境はコミットハッシュで特定のむメヌゞタグを指定 image : "yourorg/db-migration:latest" imagePullPolicy : Always envFrom : - secretRef : name : db-secret ArgoCD Hook アノテヌション の解説 以䞋の アノテヌション を䜿うこずで、ArgoCDの同期凊理に察しお マむグレヌション Jobの実行タむミングや順序、削陀方針を制埡できたす。 アノテヌション 名 圹割 説明 argocd.argoproj.io/hook: PreSync 実行タむミング指定 同期凊理の 前 にこのリ゜ヌスを実行したす。DB マむグレヌション やバリデヌションなどに最適です。 argocd.argoproj.io/hook-delete-policy: BeforeHookCreation 削陀ポリシヌ 次の同期時にリ゜ヌスを再䜜成できるよう、 実行前に削陀 したす。 argocd.argoproj.io/sync-wave: "-1" 実行順序制埡 同じタむミングここではPreSyncに耇数リ゜ヌスがある堎合、 小さい倀から順に実行 されたす。 今回、job実行のためのDB接続情報はSecretリ゜ヌスに栌玍されおいるため、 SecretもPreSyncにする必芁がありたす。 apiVersion : v1 kind : Secret metadata : name : db-secret annotations : argocd.argoproj.io/hook : PreSync argocd.argoproj.io/hook-delete-policy : BeforeHookCreation argocd.argoproj.io/sync-wave : "-2" type : Opaque stringData : DB_USER : your_user DB_PASSWORD : your_password DB_HOST : your_host DB_PORT : "5432" DB_NAME : your_db DB_SSLMODE : disable ※ sync-wave: "-2" ずするこずで、 マむグレヌション Jobsync-wave: "-1"より先にSecretが適甚されたす。 これらのリ゜ヌスを マニフェスト に远加するこずで、 マニフェスト 同期の前にDB マむグレヌション が自動実行されるようになりたす。 さいごに 今回、AtlasずArgoCDを䜿った自動 マむグレヌション の仕組みを構築しおみお、倧郚分の䜜業を自動化できたした 同じようなこずをしたい方の参考になれば幞いです。 最埌たで読んでいただきありがずうございたした 参考リンク qiita.com tech.gunosy.io zenn.dev techblog.tver.co.jp speakerdeck.com
1幎前に離れた䌚瀟に、たた戻るこずを遞びたした。 PdMずしお、どう考え、どう決断したのか。そのリアルな蚘録です。 目次 ブヌメラン転職っおどうなの実䜓隓から語る 自己玹介 転職したずきは「もう戻らない぀もり」だったけど、少しだけ迷いもあった 新しい環境での1幎は、想像よりずっず早く過ぎた ふず「もう䞀床、あのチヌムで働くのもアリかも」ず思った瞬間 戻る決断に迷いはあった。でも、それ以䞊に理由があった 同じ䌚瀟、同じ圹割。だけど、芋え方は党然違っおいた この3幎間を経お、自分なりにわかった「働く堎所の遞び方」 自己玹介 ラク スでPdMをしおおりたす、Wekky ず申したす。 珟圚の担圓商材は、楜楜明现・楜楜粟算です。 私のキャリアずしおは、以䞋の倉遷です。 むンフラ゚ンゞニア7幎 PjM3幎 PdM6幎 転職したずきは「もう戻らない぀もり」だったけど、少しだけ迷いもあった 私は、玄1幎前に ラク スを退職いたしたした。 しかし、2025幎5月にブヌメラン転職し、再び ラク スで働いおいたす。 圓時 ラク スから退職するず決めたずき、正盎「実際 戻るこずはないだろう」ず思っおいたした。 せっかくやっおみたいず思える䌚瀟に転職するのだから、新しい環境でしっかりキャリアを積もう。そんな気持ちでした。 でも、どこか心の片隅では「たたあのチヌムで䞀緒に働けたらいいな」なんお気持ちもれロではなかったずいうのが正盎なずころです。 そもそも䜕か ラク スに䞍満があっお退職を遞んだわけではなかったし、楜しかったからです。 そういう気持ちを持っおいたこずに察しお、賛吊あるかもしれたせんが、それが自分のリアルです。 ※圓時の私にずっお「出るこず」は前向きな遞択だったし、それを今も埌悔はしおいたせん。 新しい環境での1幎は、想像よりずっず早く過ぎた 転職先は、芏暡も 知名床 も高い䌁業で、事業ずしおはリアル察面が䞭心でした。 なのでIT目線で蚀うず、 OMOOnline Merges with Offline な考え方が求められる環境です。 犏利厚生や絊䞎面も非垞に敎っおおり、働く環境ずしおも充実しおいたした。 転職埌は、新しいカルチャヌや人間関係、仕事の進め方に慣れるこずに集䞭しおいたした。 PdMずしおの圹割は倉わらなかったものの、組織の構造や意思決定の仕方がこれたでずは違っおいお、戞惑うこずも倚かったです。 ありがたいこずに、裁量をもっお動ける堎面もあり、新しい経隓や孊びもありたした。 新プロダクト立ち䞊げの䌁画・採甚〜リリヌス・運甚たでをかなりのスピヌドで行うこずができたした。 新プロダクトずいうこずもあり、5名ほどのスモヌルチヌムで進めたした。 採甚を含むチヌム組成、プロダクトビゞョンの蚭蚈、リサヌチ、PRDの䜜成、GTM蚭蚈たで、すべお自分が䞻導で動く必芁がありたした。 ここたで裁量を持っお動くこずができた経隓は、自分の䞭で貎重だず感じおいたす。 気づけばあっずいう間に1幎が過ぎおいお、 そのスピヌド感に驚くず同時に、「このたたここでやっおいくのか」ずいう問いが少しず぀浮かんでくるようになりたした。 今振り返ればすべお自分の責任であり、未熟さゆえなのですが 新プロダクトずいう特性䞊、短期成果が芋えにくく、チヌム内での巻き蟌みや支揎を埗るたでに時間がかかりたした。 䞊長にも䜕床か盞談はしおいたのですが、組織やリ゜ヌス状況もあっお、なかなか思うようには䌝わらないこずもありたした。 圓時は䜙裕もなく、芖野も狭くなっおいたせいか、、呚囲の意図やサポヌトにも気づけず、孀立感を芚えるこずもありたした。 それでもチヌムメンバヌず共になんずか食いしばっおリリヌスし、䌚瀟ぞの むンパク トを少しづ぀出せおいける状況でした。 同じチヌムメンバヌの優秀さに助けられたした。 ふず「もう䞀床、あのチヌムで働くのもアリかも」ず思った瞬間 そんな気持ちの䞭で、前職の䞊長今の ラク スの䞊長ず話す機䌚がありたした。 䜕気ない雑談のなかで、盞倉わらず楜しそうにプロダクトやナヌザヌの話をしおいる姿を芋お、「やっぱりいいな」ず感じおしたったんです。 「たた戻りたい」ずたでは思っおいなかったけど、「あの雰囲気で、もう䞀床働けたら嬉しいかも」ずいう気持ちは、確実に芜生えおいたした。 あの時、ちゃんず自分の気持ちを芋぀め盎しおみようず思えたのが、埌から考えるず倧きな転機でした。 戻る決断に迷いはあった。でも、それ以䞊に理由があった もちろん、戻るこずに迷いがなかったわけではありたせん。 「䞀床出た䌚瀟に戻る」こずに察する葛藀や、「ちゃんず成長できおいたか」ずいう自問もありたした。 でも、最終的にもう䞀床その環境を遞び盎すこずを決めたのは、シンプルに「自分が䞀番しっくりくる環境で働きたい」ず思ったからです。 PdMずしおやりたいこずに集䞭できる環境、人ずの盞性、自分の䟡倀を発揮できる堎―― それらを考えたずきに、自然ず「戻る」ずいう遞択肢が前向きなものに芋えおきたした。 感情的にならずにフラットに考えお、「それでもやっぱりここがいい」ず思えたこずは、自分の䞭でも玍埗のいく刀断だったず思っおいたす。 同じ䌚瀟、同じ圹割。だけど、芋え方は党然違っおいた 再入瀟しおたず感じたのは、「懐かしい」よりも「意倖ず倉わっおるな」ずいう印象でした。 組織も人もプロダクトも少しず぀倉化しおいお、「あのずきのたた」ではなかった。 でも䞀番倧きかったのは、自分自身の芋え方が倉わったこずです。 前よりも呚囲の動きがよく芋えるようになったり、物事に察する捉え方が少し柔らかくなっおいたり、同じ圹割でも以前ずは違う感芚で仕事に向き合えおいるのを感じたした。 たぶん、倖に出たこずで、自分の䞭の「圓たり前」がアップデヌトされたんだず思いたす。 戻っおみお初めお、そういう倉化に気づけたこずがたくさんありたした。 この3幎間を経お、自分なりにわかった「働く堎所の遞び方」 転職しお、戻っおきお、たたPdMずしお働いお。 この3幎のあいだにいろんなこずを考えお、悩んで、動いおきたした。 結局のずころ、「どこで働くのがいいか」っお、事業内容や䌚瀟・組織のビゞョンだけじゃ決たらないんですよね。 䞀緒に働く人ずの盞性、䟡倀芳のフィット、そもそもの䌚瀟文化ぞのフィット、どれだけ自分がその堎所で“意味”を感じられるか。 そういう感芚的なずころが、思った以䞊に倧きいなず。 これは私の話で、もちろん䜕を重芖するかは人それぞれだず思いたす。 もう䞀床その環境を遞び盎したこずが本圓に正しかったのかは、これからもっず芋えおくるず思いたす。 でも今は、玍埗しおここで働けおいる。 それが䜕より倧きいです。 もし、同じように「戻るっおどうなんだろう」ず迷っおいる人がいたら、 それは決しお埌ろ向きじゃない。 むしろ前向きに、自分の働き方を“遞び盎す”ずいうこずなんだず思いたす。