自己紹介 こんにちは、 稲垣 です。ラクスの開発組織のプロダクト部 製品管理課の組織のマネージャーをしています。 　└ プロダクト部の紹介は コチラ / 製品管理課の紹介は コチラ / 私自身の経歴は コチラ こんな方におすすめ ・自身の提案が上司や必要な人に届いてないと感じてる方 ・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年のあいだにいろんなことを考えて、悩んで、動いてきました。 結局のところ、「どこで働くのがいいか」って、事業内容や会社・組織のビジョンだけじゃ決まらないんですよね。 一緒に働く人との相性、価値観のフィット、そもそもの会社文化へのフィット、どれだけ自分がその場所で“意味”を感じられるか。 そういう感覚的なところが、思った以上に大きいなと。 これは私の話で、もちろん何を重視するかは人それぞれだと思います。 もう一度その環境を選び直したことが本当に正しかったのかは、これからもっと見えてくると思います。 でも今は、納得してここで働けている。 それが何より大きいです。 もし、同じように「戻るってどうなんだろう？」と迷っている人がいたら、 それは決して後ろ向きじゃない。 むしろ前向きに、自分の働き方を“選び直す”ということなんだと思います。

はじめに 楽楽勤怠開発部でPdM（プロダクトマネージャー）をしている @k0First です。 私は、 ラク スが提供する「 楽楽勤怠 」のプロダクトマネージャー（PdM）として、日々企画・要件定義・開発推進を担当しています。 ラク スは 「ITサービスで企業の成長を継続的に支援します」 をミッションに掲げ、 SaaS プロダクトを通じて企業の業務効率化・生産性向上に貢献する会社です。 私たち ラク スが大切にしているのは、 「顧客視点で価値を生む機能開発」。 ですが実際の現場では、さまざまなリク エス トや要望が飛び交い、目の前の「作るべきもの」に引っ張られてしまうこともあります。 たとえば、 事業部からの要望をそのまま実現する 競合がやってるから同じ機能を実装する そんなふうに開発された機能が、結果あまり使われない…という経験、ありませんか？ だからこそ私たち楽楽勤怠開発部では、機能を"なんとなく"で作らないことを大切にしています。 「誰の」「どんな課題を」「なぜ」解決するのか。 これを要件定義の段階でしっかりと見極めることを意識しています。 この記事では、私たち楽楽勤怠開発部が実践している 「本当に必要な機能を見極めた上で開発を行うための顧客志向な要件定義」 についてご紹介します。 たとえば、 事業部からの要望にどう向き合うのか デザイナーとどう体験設計を進めるのか 開発メンバーにどう“目的”を伝えるのか こうした具体的な場面を通じて、単なる“仕様決め”にとどまらない、 顧客視点に立った「楽楽勤怠開発部流の要件定義」の考え方 を紐解いていきます。   はじめに 顧客志向とは何か なぜ顧客志向が必要なのか 本当に必要な機能を見極めるために大切にしていること 顧客要望を「課題」に翻訳する 顧客価値だけでなく事業価値も考える 顧客視点と事業視点を両立させる 「やる」「やらない」を決める基準 デザイナーも構想段階から巻き込む 体験を一緒に設計する コストの大きい開発案件は、ワイヤーフレームを作るところから 「コストと体験」のバランスも一緒に考える 開発メンバーには「Why」から伝える 仕様書ではなく、背景と目的から話す 開発メンバーからのフィードバックを歓迎する 仕様変更を恐れない姿勢 まとめ　「顧客志向な要件定義」は問い続ける姿勢     顧客志向とは何か 「顧客志向」という言葉をよく耳にするものの、「お客様の要望をそのまま実装すること」と誤解されているケースも少なくありません。 たとえば、 「勤務表の申請ボタンをもっと大きくしてほしい」 「打刻修正の理由欄を必須にしてほしい」 といった要望は一見もっともらしく聞こえますが、実際にはその裏に、 「毎月申請漏れが多く、管理者からの催促が発生している」 「修正理由が入力されていないことで 労務 チェックが止まってしまう」 といった、 業務上の根本的な困りごと が隠れていることが多くあります。 顧客志向の本質は、"要望に応える"ことではなく、 "困りごとの本質を見極めて、最も効果的な解決策を提供すること" です。 この視点に立つことで、「本当に使われる機能」「顧客の期待を超えた価値」を実現することができると私は考えています。 なぜ顧客志向が必要なのか 私たちが開発している「楽楽勤怠」は、全社員が日々の打刻や申請で使い、現場の責任者がそれを確認・修正し、さらに 労務 担当者が全体を集計・管理するというように、 複数の立場のユーザーに横断的に使われるプロダクト です。 この領域の難しさは、単に機能を実装することではなく、 ITに不慣れな現場の責任者にも、 直感的に使える操作性 部門や拠点ごとに異なる 就業ルールや申請フローへの柔軟な対応 毎日発生する リアルタイムな処理と確認作業の効率化 といった、 現場の実務に本当にフィットする体験をどう作るか にあります。 そんな中でお客様からの要望をそのまま実現してしまうと── 現場で本当に困っていることが解決されなかったり   別のユーザーには使いにくい仕様になってしまったり   ということが起こりがちです。 だからこそ私は、限られた開発リソースを本当に役立つ機能改善に使うために、 「要望」ではなく「課題」を見極めること を重視しています。 本当に必要な機能を見極めるために大切にしていること 楽楽勤怠開発部が大切にしているのは、 「要望」ではなく「課題」にフォーカスする姿勢 です。 お客様や事業部から「これが欲しい」と要望が上がってきたとき、PdMが最初にやるべきことは「なぜその機能が必要と感じているのか」を丁寧に聞くことです。 顧客要望を「課題」に翻訳する 楽楽勤怠開発部では、顧客からの要望を直接聞くことはなく、事業部から要望を収集して機能開発を行っています。 その際、事業部には次のような質問を投げかけます。 なぜこの機能が必要だと感じているのですか？（背景・文脈を ヒアリ ング） 今の運用でどんな手間がかかっていますか？（業務フローやオペレーションを理解する） この問題が解決されることで、どんな効果が期待できますか？（課題解決の確実性を確認する） 現状の代替手段や妥協点は何かありますか？（本当に"今"解決すべき課題かを見極める） この対話を通じて、お客様が本当に困っていること、解決すべき本質的な課題が明らかになります。 表面的な要望に引っ張られず、「その機能がなぜ必要なのか」を深掘りすることが、顧客志向な要件定義においては非常に重要です。 そうすることで、目的を逸脱した「使われない機能」の開発を防ぐことができます。 顧客価値だけでなく事業価値も考える 要件定義では、お客様のことを考えるだけでなく、事業部との調整も欠かせません。 事業部からは「売上拡大」「顧客獲得」といった目標を実現するための要望が上がってきます。 ここで大切にしているのは、「顧客価値」と「事業価値」の両方を論理的に整理し、合意形成することです。 顧客視点と事業視点を両立させる 楽楽勤怠開発部では、事業部と合意形成をするために、以下の内容を整理しています。 目的、背景、解決したい顧客の課題 なぜその機能を開発する必要があるのか それが事業に与える インパク ト 顧客単価UP、 顧客満足度 UP、解約防止など 必要な開発リソース 工数 ・コスト・スケジュール このように、感覚ではなく「数字と論理」で合意形成するようにしています。 最後に、その機能を実装するために必要なリソースと、見込まれるリターンのバランスを検討し、事業部と「もしこれをやるなら、どこに負荷がかかるか」「他の優先タスクにどんな影響が出るか」を具体的に議論します。 開発部と事業部では、それぞれ優先するものが異なるため、合意形成をスムーズに行うには、お互いのことを深く理解していなければなりません。 楽楽勤怠では、開発部と事業部の間に 信頼関係が築けている こともあり、お互いの立場を尊重した合意形成ができていると感じます。 「やる」「やらない」を決める基準 すべての要望を実現することはできません。 だからこそ、「やらないと決めること」もPdMの大切な仕事です。 私は以下のような基準で判断しています。 顧客にとって価値が高いか たくさんの顧客にメリットをもたらすか ある一部の顧客にとってしかメリットがないものになっていないか 今やるべきなのか 開発リソースは有限です。 「やるべき機能」を見極め、「やらないこと」を決断することこそが、真の顧客志向だと考えています。 こうして、開発ロードマップを作成し、機能開発の優先度を事業部と協議して決めています。 デザイナーも構想段階から巻き込む 楽楽勤怠開発部では、もともとデザイナーを「要件定義フェーズが終わってから参加してもらう」ようなスタンスで開発を進めていました。 ですが、現在では、 要件定義の構想段階から積極的に巻き込むことが重要 だと考えているため、一緒に要件定義を進めています。 なぜなら、顧客にとって「その機能がどう使われるのか」「どんな体験になるのか」は、仕様書だけでは表現しきれないからです。 体験を一緒に設計する 要件定義の段階で、デザイナーに共有するのは次のような情報です。 顧客の課題（なぜこれをやるのか） ユーザーがどんな業務フローの中で使うのか どうすれば迷わず、スムーズに使える体験になるのか この段階で、 PdMである私が頭の中で描いている「理想の顧客体験」を伝え、デザイナーの視点を加えてデザイン設計を行う ことが大切です。 例えば、 「この 動線 だと、ユーザーは何を期待してこのボタンを押すのか？」 「今の画面構成だと、どこでつまずくリスクがあるか？」 「業務の文脈を考えたとき、このタイミングでこの情報が必要か？」 といった様々な観点でディスカッションを重ねます。 コストの大きい開発案件は、 ワイヤーフレーム を作るところから 開発コストのかかる大きな案件は、まず、デザイナーが作る ワイヤーフレーム （下書き）をもとに議論を重ねます。 ここでいう ワイヤーフレーム は「完成品」として扱うのではなく、 “意思疎通のためのツール”として使う ことを意識しています。 PdMが考える「この機能で顧客はこう動くはず」という仮説 デザイナーが持つ「UXの原則」や「ユーザー心理」の知見 これらをPdM、デザイナー、事業部とすり合わせていくプロセス これが、顧客視点で価値を生む機能開発には欠かせません。 「コストと体験」のバランスも一緒に考える もちろん、理想的なUI/UXを追い求めるだけでは、開発リソースやスケジュールが追いつかないこともあります。 だからこそ、デザイナーとは「ここは妥協しても良い」「ここは死守したい」という優先順位を共有しながら、 “最適な着地点”を一緒に探ります 。 これが、楽楽勤怠開発部で実際におこなっている「顧客志向な要件定義」におけるデザイナーとの連携です。 開発メンバーには「Why」から伝える 次に重要なのが、開発メンバーとの連携です。 楽楽勤怠開発部では、開発チームを単なる“実装担当”として扱うことはありません。 PdMがやるべきは、 「なぜこの機能を作るのか」を開発メンバーにしっかり伝えること です。 仕様書ではなく、背景と目的から話す 私は開発メンバーに要件を伝える際、必ず次の順番で説明します。 背景 「この機能を要望された経緯」「顧客が直面している課題」を説明します。 目的 「この機能によって、どんな価値を届けたいのか」「どんな行動変化を期待しているのか」を共有します。 要件 そのうえで、「だからこういう仕様にしている」という理由付けをしながら要件を説明します。 これにより、開発メンバーは 「言われたものを作る」のではなく、「課題解決のために自分も考える」モード に入ってくれます。 私自身、過去に仕様書だけ渡してしまったことで認識ズレが生じ、開発がやり直しになった苦い経験があります。 その時痛感したのは、 「仕様そのもの」よりも「目的・背景」を伝える方が、はるかに重要 だということです。 なぜなら、「目的・背景」が伝われば、認識ズレを防ぐだけでなく、 私が考えた仕様よりももっと価値のある仕様を開発メンバーが考え付く可能性があるから です。 実際に、開発メンバーから「だったら、こうした方が早くて安全かも」という建設的な提案が自然と出てくるようになりました。 この双方向のコミュニケーションが、結果的に より良い顧客体験を実現する近道 だと考えています。 開発メンバーからのフィードバックを歓迎する 開発チームからは、仕様に対するさまざまなフィードバックが返ってきます。 技術的な実現可能性（もっと簡単な方法があるのでは？） 保守性やパフォーマンスへの影響 将来的な拡張性 セキュリティや障害対応の観点 これらをPdMが受け止め、 顧客価値を損なわずに、より良い形にブラッシュアップしていく のが理想の連携です。 仕様変更を恐れない姿勢 「Why」を共有したうえでのフィードバックであれば、仕様を変えることは決して「後戻り」ではありません。 むしろ、 開発チームが顧客志向で考えた結果としての改善提案 であれば、歓迎すべきことです。 楽楽勤怠開発部では、 スクラム 開発の中で、こうした対話を通じて 「チーム全体で顧客志向を実現する」 文化を根付かせていっています。 まとめ　「顧客志向な要件定義」は問い続ける姿勢 ここまで、楽楽勤怠開発部が実践する「顧客志向な要件定義」についてお話ししてきました。 お客様の“言ったこと”ではなく、“本質的な課題”を捉える 顧客価値と事業価値を両立させ、冷静に優先度を決める やらないことを決め、やるべきことに集中する デザイナーや開発メンバーと“Why”を共有し、一緒に考える これらは決して特別なことではありません。 重要なのは、 本当にこの機能は必要か？ 顧客にとって価値があるか？ を 問い続ける姿勢 です。 その積み重ねが、最終的に 「使われるプロダクト」「選ばれるプロダクト」 につながると、私は信じています。 楽楽勤怠開発部では、これからも愚直に「顧客志向」を追求し、企業の成長を支援するプロダクトを磨き続けていきます。

どうも、 稲垣 です。 先日、 株式会社翔泳社 ProductZine編集部主催のイベント に参加しました。 昨年に続き、今年も 神田明神 ホールで開催されました。 当日は晴天で、 神田明神 では『 神田神社 大祭』が催されており、活気にあふれていました。 神田明神 いつきても素敵だ 去年もここだったが良き 今日は 神田明神 でもイベントやってる #productzine pic.twitter.com/UWy89oT5tv — 稲垣 剛之(Takeshi Inagaki)｜ ラク ス (@ingktks7) 2025年5月15日 その中で以下のクロージングセッションが 【モデレーター】広瀬 丈［ログラス］/飯沼 亜紀［ウト］/斉藤 知明［ログラス］/横道 稔［Product People］ ラスト始まった PdMのキャリア、悩ましい 自分についてもだし、メンバーに対してもなので組織ヅクリに活かしたい 3割くらいがPdMかなあ ★多様化し変化していくなかで目指すべき、これからのプロダクトマネージャーのキャリア #productzine pic.twitter.com/MSBVumfpha — 稲垣 剛之(Takeshi Inagaki)｜ ラク ス (@ingktks7) 2025年5月15日 という、プロダクトマネージャーのキャリアについてのセッションでした。 その中で 「キャリアは偶発的ですか？計画的ですか？」 という問いがありました。 登壇者全員が「偶発的」 と答えていて、非常に印象深かったです。 改めて、こういったセッションでは「よい問い」こそが素晴らしい議論を生み出すのだと感じました。 計画的なのは「 大谷翔平 さん」くらいではないかという話もあり、おそらく多くの方が頷いていたと思います。 また、会場にいたすべての人が「自分はどうだろう」と考えていたことでしょう。ポストしている方も多数いました。 キャリアは偶発的ですか？計画的ですか？という問い。偶発性を「いきあたりばったり」と捉えるなら、多分登壇者含めてじつはほんとはそうじゃないきはする。 北極星 （こだわり）をもって、目の前に現れる様々なことを縦横無尽に利用してやりたいことにむかってる人がPMは多い気がする #productzine — みやっち | 生成AI エバンジェリスト @ 🇪 🇽 🇵 🇱 🇦 🇿 🇦 (@miyatti) 2025年5月15日 自分もそんな一人だったので、イベントのテーマに触発されて、これまでの自分のキャリアについて書いてみようと思います。 自分のキャリアは偶発的ですか？計画的ですか？ キャリアの変遷 前編 キャリアの変遷 後編 まとめ 自分のキャリアは偶発的ですか？計画的ですか？ 自己紹介と略歴はこんな感じです。 新卒で大手独立系 SIer 企業に何とか滑り込み、そこを含めて、現在の ラク スまでIT企業を6社経験しています。 イベントの問いにあった「キャリアは偶発的ですか？計画的ですか？」については、ずるい回答をすると、 　「偶発と計画の狭間」 にあります。 青の項目は、自らの意志で計画的にキャリアを変えたものです。 それ以外は、偶発的というか、働く中でチャンスがあったり、気がついたらそうなっていたキャリアです。 面白いのは、偶発的でも計画的でも、見事に失敗しているという点です。そのあたりについて、ここから書いていこうと思います。 キャリアの変遷 前編 「キャリア」（career）という言葉の起源は、中世 ラテン語 の「車道」にあり、英語では競馬場や競技場におけるコースや、そのトラック（行路、足跡）を意味するものだそうです。（登壇者のログラスの斉藤さんも「足跡」だと話されていました。） そんなわけで、自分のキャリア（足跡）を、いくつかのパートに分けて「出来事」と「その時感じたこと」という視点から振り返ってみることにします。 外部発信でここまで自己開示するのは珍しいと思いますが、読んでくださっている方の今後のキャリアに少しでも参考になれば幸いです。 ※なお、この「キャリア変遷」資料は本ブログのために作成したものではなく、前職で幹部育成の研修アドバイザーをしていた際、研修課題として提示されたものに対し、「面白そうだ」と思って自分も作成したものを、少し補正したものです。 これがキャリア前半の18年分です。ここでは、偶発的なキャリアを9年半で終え、初めての転職をしました（計画的）。 そして、この転職でひとつ大きな失敗を経験しました。その失敗の理由は、転職時に2つのことを同時に追い求めたことにあります。 この失敗を糧に、次の転職では「自分のやりたいことをとことんやろう」という軸で会社選びをしました。 このあたりから、「エンジニア」という枠組みをあまり意識しなくなり、「製品づくり」に直接関与し、製品の成長に貢献できれば、役割にはそれほどこだわらなくなりました。この考え方が、キャリア後半や現在のプロダクトマネージャーという役割につながっています。 キャリアの変遷 後編 これが、キャリア後半の7年間（2025年5月現在を含む）です。ここでは、大きな変化が2つあり、そのうちの一つは失敗でした。 最初の変化は、親会社のグループ化に伴い、携わっていた事業が分社化され、その会社の役員を務めることになったことです。 実は、役員就任前には当時の会社を辞めるか、別の事業への異動を希望していました。理由は、自分自身が成長を実感できなくなっていたからです。 事業立ち上げ直後から5年以上にわたって携わり、開発・企画・デザイン全般の責任者を務めていました。製品の成長は著しかったものの、その中での刺激が徐々に減っていきました（長くいると何かと楽ができてしまう）。また、各領域のリーダーたちも成長していたため、「そろそろ潮時かな」と思っていたところでした。 その最中で分社化の話が持ち上がり、代表と話し合った結果、少し迷いはあったものの、役員という貴重な経験ができる機会だと捉えて引き受けました。当初はプロダクト管掌の予定でしたが、急遽コーポレート部門も担当することになりました。 この2年間で以下のような経験をしました： 会社のビジョン・行動指針の策定 人事制度などの制度設計 オフィス移転に伴うオフィスづくり 全職種の新卒・ 中途採用 責任者 アメリ カ企業との提携交渉 訴訟対応や商標取得に関する弁護士・ 弁理士 との交渉 もしこのとき転職していたら、きっと経験できなかったことばかりだったと思います。 2つ目の変化は、役員退任後に「 外資 系企業」「技術サポートマネージャー」という、これまでまったく経験のなかった領域への転職です。 転職時には複数社から内定をもらっていましたが、そのほとんどは自社で製品づくりを行っている企業で、EM（エンジニア リングマ ネージャー）、システム企画、プロダクトマネージャーといった役割でした。なぜそれらの企業に行かなかったのか？ 理由は、「そこそこうまくやれそうな気がしたから」だったように思います。 逆に、最終的に選んだ企業は、「うまくできるか全く未知」だったからこそチャレンジしたかったのです。 ただし、1点だけ懸念がありました。それは、「製品づくり」に直接関われない点です。その企業でもプロダクト開発は行っていましたが、基本的には アメリ カ本社での開発が中心でした。社内異動で関与する道もありましたが、ハードルは高いものでした。 結果的に、この懸念が的中し、退職を決断しました。 業務自体は面白く、同僚マネージャーやメンバーのレベルも非常に高かったですし、会社の仕組みや文化も独特で、短期間ながら多くを学ぶことができました。そのため、この転職に後悔はありません。 まとめ というのが、これまでの自分のキャリア変遷となります。 キャリアの中でブレなかったのは、「 製品をツクルことが好き 」という気持ちでした。 前職では、面接時に求職者の方に以下の質問をよくしていました。 これには当然、正解はなく、おそらくこれら全部が好きだからこそ、製品づくりに携わっているのだと思います。ちなみに、当時なぜこの質問をしていたかというと、純粋にその人のタイプが知りたかっただけで、深い意味はなかったように思います。 （当時のメンバーに聞いてみたところ、見事に意見が分かれて面白かったですし、チーム編成の参考にもなりそうだと感じました） ちなみに、自分の第一位は以下のように変化してきました： ２．考えたものを実際にツクルこと ⇒ ３．ツクったものがお客様に届き反応があること ⇒ １．何をツクルか考えること 今はもう、めんどうなので順位はつけていません。 そして、キャリアについては、ここまで書いてきたように、偶発的でも計画的でも失敗します。だから今は、自分のキャリアについてはほとんど何も考えていません。 マネージャーとして組織の未来は描きますが、自分の未来を描くことはやめて、目の前のことを全力で楽しくやりきることにフォーカスしています。その代わり、「働く」ことに対してのビジョンは決めていて、そのビジョンに近づけるかどうかを軸にしています。 以上が、自分のキャリアの変遷や、キャリアについての考えです。 参考になったかはわかりませんが、少しでもこの内容を通じて、自分や自分が今所属している ラク スに興味を持ってもらえたら嬉しいです。 ちなみに、現在は以下の組織でPdM（プロダクトマネージャー）とデザイナーをリードしています。 tech-blog.rakus.co.jp 両方の役割とも採用募集中ですので、ぜひご応募ください！ career-recruit.rakus.co.jp career-recruit.rakus.co.jp