こんにちは、プロダクト部 部長の稲垣です。(自己紹介やこれまでのキャリアについて↓をご覧ください。) tech-blog.rakus.co.jp 今回は、私が作った「PdMタイプ診断」という取り組みについてご紹介します。 この診断は、既存の性格診断をそのまま用いたものではなく、 PdMとしての思考や行動の傾向を整理するために、認知スタイルに関する考え方をヒントに独自に設計したもの です。 診断の仕組みと、ラクスの開発組織で実施して見えてきたことをレポートします。 なぜ作ったのか 診断の仕組み:3つの軸、8つのタイプ 軸① コミュニケーション 軸② 価値の方向性 軸③ 志向性 ラクス社内で試してみた 開発組織全体の傾向:「Logic × UX × Discovery」が最多 プロダクト部の特徴:「Discovery」が際立って高く、2つのタイプが拮抗 この結果をどう受け取るか まとめ おわりに なぜ作ったのか きっかけは、小さな課題感からでした。 PdMのイベントや社外の方と話すとき、「どんなPdMですか?」という問いにうまく答えるのが難しいと感じることがありました。 職種名だけでは伝わらないですし、スキルセットを並べても、その人らしさまではなかなか見えてきません。 もう一つ感じていたのが、チームづくりの場面で、 このメンバーはどんな場面で力を発揮しやすいのか を共通言語で話しにくいことでした。 もちろん、人の適性や可能性は診断だけで決まるものではありません。 ただ、対話のきっかけになる整理軸があるだけでも、お互いの理解は進めやすくなります。 そこで、PdMとしての思考・行動スタイルを3つの軸で整理し、8つのタイプに分類する診断を作ってみました。 初対面のPdM同士で話すきっかけにしたり、チーム内で自分や他者の強みを言語化したりするための、 参考情報の一つ として使えることを期待しています。また今回の整理にあたっては、設問やタイプ説明のたたき台を考える過程で、生成AIも補助的に活用しました。 人が考えるべき軸や解釈を前提にしつつ、表現の幅を広げたり、説明文を磨いたりするうえで、AIは良い壁打ち相手になると感じています。 診断の仕組み:3つの軸、8つのタイプ 診断は、3つの軸の組み合わせでPdMのタイプを分類します。 軸① コミュニケーション Logic(理詰め型)/ Emotion(共感型) チームや関係者をどう巻き込むかを見る軸です。 データや論理で動かす傾向が強いのか、共感や関係性を起点に動かす傾向が強いのかを見ます。 軸② 価値の方向性 UX(ユーザー価値重視)/ BV(ビジネス価値重視) どの成果をより重視しやすいかを見る軸です。 顧客体験を起点に考えるのか、事業成長や収益性を起点に考えるのか、その傾向を整理します。 軸③ 志向性 Discovery(探索志向)/ Delivery(実行志向) どのフェーズでモチベーションを感じやすいかを見る軸です。 まだ見ぬ課題を発見することに惹かれるのか、価値を着実に届けることに手応えを感じるのかを見ます。 この3軸の組み合わせで、8つのタイプになります。 ※本記事では、診断の詳細な設問内容や公開方法そのものの案内は割愛します。 ラクス社内で試してみた せっかく作ったので、ラクスの開発組織でも試してみました。 プロダクト部のメンバーだけでなく、楽楽シリーズの開発に携わるエンジニア、QA、インフラ、管理職まで、幅広く参加してもらいました。 ここで紹介するのは、個人を評価したり決めつけたりするためのものではなく、 組織の傾向を俯瞰して見るための集計結果 です。 「どのタイプが優れているか」を見るものではなく、「どんな視点が集まっているか」を知るための材料として扱っています。 そのうえで、いくつか興味深い傾向が見えてきました。 開発組織全体の傾向:「Logic × UX × Discovery」が最多 開発組織全体を見ると、もっとも多かったのは サイエンティスト(Logic × UX × Discovery)タイプ でした。 各軸の全体比率は次のとおりです。 論理的に考え、ユーザー価値を重視し、探索や発見にモチベーションを感じる人が多い。 これが、開発組織全体の大まかな傾向でした。 実際、日々のプロダクト開発でも、 「顧客課題をより深く理解したい」 「仮説を立てて検証したい」 という姿勢を持つメンバーが多いと感じています。この傾向は、顧客にとって本当に価値のある機能や体験を考えるうえで、ラクスの開発組織らしさの一つかもしれません。 プロダクト部の特徴:「Discovery」が際立って高く、2つのタイプが拮抗 プロダクト部に絞ると、また少し違った顔が見えてきました。 プロダクト部の各軸比率は次のとおりです。 特に目を引いたのは、志向性です。 全体でも67%がDiscovery型でしたが、プロダクト部では 79% とさらに高くなっていました。まだ答えのない問いを探索することが好きな人、発見のフェーズにエネルギーが湧く人が多い組織だと言えそうです。 さらに興味深かったのが、タイプの分布です。 プロダクト部で最多だったのは、 ビジョナリー(Emotion × UX × Discovery) と ストラテジスト(Logic × BV × Discovery) の同率首位でした。 一方は、共感から未来の体験を描くタイプ。 もう一方は、構造から勝ち筋を見出すタイプです。 アプローチは対照的ですが、どちらも「Discovery(探索)」に強く向いているという共通点があります。 感性寄りの人と論理寄りの人、ユーザー価値を強く見る人とビジネス価値を強く見る人が混在している。 その多様さが、ラクスのプロダクト部の特徴の一つなのかもしれません。 この結果をどう受け取るか 「タイプが違うと、摩擦が生まれるのでは」と感じる方もいるかもしれません。 私は、むしろ逆だと思っています。 たとえばビジョナリーとストラテジストは、それぞれ異なる強みを持っています。 共感から体験を描く力と、構造から事業の勝ち筋を考える力は、どちらもプロダクトづくりに欠かせません。 大切なのは、「あなたはこのタイプだからこうあるべき」と決めることではなく、 このチームにはどんな視点が集まっているのか を知ることだと思っています。 その視点の違いを理解できると、 顧客課題の見立てに偏りがないか 意思決定の観点が足りているか 誰がどの場面で力を発揮しやすいか といったことを、より建設的に話しやすくなります。 実際、この診断をきっかけに、ラクスのプロダクト部でも 「自分はどういう場面で力を出しやすいか」 「チームとして見ると、どの視点が強くて、どの視点が薄いか」 を話題にしやすくなった感覚があります。 その結果として、顧客にとっての価値の捉え方や、プロダクトづくりにおける役割分担の解像度が少し上がったように感じています。 まとめ 「PdMタイプ診断」は、まだ発展途上のツールです。 型にはめることが目的ではなく、 共通言語を通じて、自分やチームの傾向を理解するための出発点 として使ってもらえたらと思っています。 PdMとして、あるいはプロダクトづくりに関わる一人として、 「自分はどんな場面で力を発揮しやすいのか」 「チームの中でどんな視点を持ち込みやすいのか」 を考えるきっかけになれば、作った甲斐があります。 そして、こうした相互理解は、よりよいチームづくりだけでなく、 顧客課題を多面的に捉え、より価値あるクラウドサービスを届けることにもつながるはずです。 興味を持っていただけたら、ぜひ一度試してみてください。 おわりに ラクスのプロダクト部では、さまざまなタイプのPdMやデザイナーが一緒に働いています。 違いを面白がりながら、顧客にとってよりよい価値を考え続けたい方と、ご一緒できたらうれしいです。 採用情報は、ぜひこちらからご覧ください。 career-recruit.rakus.co.jp speakerdeck.com
はじめに 本イベントについて 登壇内容の解説 他の方のLT登壇 まとめ はじめに 今年はまだ1回もK-POPのライブに行けてない、楽楽債権管理チームの冨澤です。 3月末に行われたサイバーエージェントさんとOpenAI Japanさんが主催するCodex Userコミュニティイベントで、LT登壇をしてきました! cyberagent.connpass.com 本記事ではLT内容の解説と学んだ内容をお届けします。 本イベントについて OpenAIのコーディングエージェントである「Codex」に関連する発表を通じて、実践知の共有を行うことが目的のイベントです。 詳細や登壇資料はこちらからご覧ください。 イベント資料一覧 登壇内容の解説 まずは私のLT内容の解説から。 資料はこちら↓ speakerdeck.com 詳細はスライドに譲りますが、チーム内で比較的実装が簡単なCRUD API 5本をCodex CLIでどう実装できるだろう、という疑問から検証を始めました。 実は既に他のコーディングエージェントを利用して同様の検証を行なっていたんですが、Codexの強みや違いなどを明確にし、開発時におけるより適切なツールの選択や運用ができるのではないかとも考えていました。 スライドの最初の失敗から学んだこと、改善、運用の工夫の大部分は、特定のコーディングエージェントに限らない内容だなと、検証を通じて理解することができました。 特に「明確な完了条件」は自己ループ的にエージェントが改善できるようになるので、必須で取り入れるべき工夫だと感じました。この工夫の前後だと全く違う品質のアウトプットが出てくるので、まだ違いを感じたことのない方は是非試してみてください。 コンテキストエンジニアリング本の第3章の指示プロンプト開発の基礎にも同様のことが書かれており、私はこの内容を参考にプロンプトを考えていました。 他のコーディングエージェントとの違いは、承認系で顕著に見られました。 Codex CLIはapproval_policyやsandboxの思想が操作感としても表れており、ここは苦戦しました。個人的にCodexは与えられた閉じた環境で大活躍する性格かなと感じています。 今回は検証利用だったので都度承認を行いましたが、例えばこれがもっと並列数が増えると開発や管理が難しくなるので、設定も含め開発環境整備は必須事項だなと思いました。 またSubAgentsの動きを細かく確認する目的でCodex appを利用しましたがかなり使いやすく、変にCLIにこだわるより、こうしたエコシステムを上手く活用する方が健全だと感じました。 他の方のLT登壇 まずトップバッターの瀬良さんの発表では、ワークフローを管理するための手段としてSkillを活用した話がありました。( 事例紹介記事 ) 特定の作業を整理したSkillを用意して、適切なタイミングで呼び出すことで小規模な改善をより迅速にリリースできるようになったそうです。 実は今回の自分の検証でもSkillを利用して、実装後のフォーマットやテスト実行、差分比較した上でのレビューまでを一気に行いました。 このように整備しておくことで、Codexが作業を終えた時点である程度の品質を担保できている状態にまで持っていくことができました。この体験が凄く良いです。 また今回は検証できませんでしたが、いずれはAPI実装時は並行してAPIテストを作成することでより良い開発になるのではないかと考えていました。 そしてまさに、瀬良さんも同様の取り組みを行なっており、検証品質向上のSkillを作成してワークフローに組み込んでいるという話もしていました。 SDKとクラウドサービスのバックエンドAPIという少し性質が違う話かと思いますが、自己検証できる材料を丁寧に増やしより品質を高める仕組みを構築する、という観点では同じ考えができるんだなと学びになりました。 他にもKuuさんの確定申告、鈴木さんの開発フロー改善、鷹雄さんのサイバーエージェントさんでのCodex導入についての話があり、丁度自分の情報収集の仕組みや、個人開発の進め方、加えてラクス社内のAI活用が上手な人の事例をもっと知りたかったので、様々な視点での発表がとても学びになりました! まとめ 今回の検証で、Codexはローカルでインタラクティブに開発を進める形式よりも、クラウドなど閉じた環境を整備し、そこで自由に動いてもらう方が効果を発揮しやすいのかなと感じました。 もちろんCodex appなど他のエコシステムも今後充実していくと思います!どんな進化が待っているか楽しみです! そして、私にとって初めての外部登壇でしたが、会社からも応援が来ていて大変心強かったです! 懇親会でお話しした方と経験したことや成功/失敗したことを共有し合えて、登壇以外でも学びになることが多く、チャンスがあれば是非継続していきいたいなと感じました。 スタッフの皆さま、登壇者の皆さま、企画運営本当にありがとうございました!
こんにちは!ラクスのエンジニア採用担当です。 今回はラクスのエンジニア職のサマーインターン 「RAKUS Tech Lab」 を紹介します。 このインターンシップは、単にコードを書く体験ではありません。 チームで開発を進めながら、「何を作るべきか」から考えるプロセスを体験していただくプログラムです。 ラクスのエンジニアがどのようにプロダクト開発に向き合っているのか。 その一端を、3日間で感じていただけます。 インターンで大切にしている考えや、実際の流れ、参加いただいた方の声を紹介します。 ラクスが大切にしている「顧客志向」 インターンシップ「RAKUS Tech Lab」について 3日間の流れ Day1:顧客理解と開発スタート Day2:開発と改善の繰り返し Day3:成果のまとめと発表 RAKUS Tech Lab 2026 プログラム日程詳細 RAKUS Tech Labを通して得られる経験とスキル AI開発×顧客志向の開発体験 チームで成果を発揮する開発体験 実務に近いフィードバック 実際に参加した学生の声 インターンシップでお会いしましょう! ラクスが大切にしている「顧客志向」 ラクスでは、開発を「機能を作ること」だけとは考えていません。 大切にしているのは、「誰のどんな課題を、なぜ解決するのか」を「顧客志向」を起点に考えることです。 (こちらの記事で実際の取り組みを紹介しています。) tech-blog.rakus.co.jp たとえば新しい機能を作るときも、 どのユーザーにとっての課題なのか その課題は本当に解くべきものなのか なぜその実装や設計を選ぶのか といった前提を整理したうえで、開発を進めていきます。 また、AIを活用した開発が広がる中で、 「速く作る」だけではなく、 AIの提案をそのまま使わずに検証すること なぜその実装にしたのかを説明できること も、重要な力だと考えています。 このインターンでは、こうした開発の考え方を実際に体験していただきます。 インターンシップ「RAKUS Tech Lab」について 4~5名のチームでWebアプリケーションの企画から実装までを行う、短期集中型の開発インターンです。 ラクスでは、Claude CodeやGitHub Copilot等のAI開発ツールを積極的に開発に取り入れています。 本プログラムでは、それらツールを使いながら、単に実装を進めるだけでなく、生成された内容を検証し、適切な意思決定を行う開発プロセスを体験していただけます。 開発中は、社員メンターがビジネス視点や設計思想についてフィードバックを行います。 技術力を高めるだけでなく、「ユーザーに使われるサービス」をどう生み出すか。 ラクスが実践する「AIを活用しながら、顧客課題に向き合い、意思決定する開発」を、持ち帰っていただけるプログラムです。 3日間の流れ Day1:顧客理解と開発スタート 顧客ヒアリングを実施し、チームで課題設定・方向性を決め、開発に着手します。 各チームに社員メンターがつき、方針や設計についてフィードバックを行います。 Day2:開発と改善の繰り返し 実装を進めながら、チームで議論し、必要に応じて方向性を見直します。 技術面だけでなく、価値や設計の妥当性についてもレビューを行います。 Day3:成果のまとめと発表 完成したアプリの発表を行います。 現役エンジニアから、実際の開発現場と同じ視点でフィードバックを受けていただきます。 RAKUS Tech Lab 2026 プログラム日程詳細 ■開催日程 ●東京①コース:8/5(水)、8/6(木)、8/7(金) ●東京②コース:9/2(水)、9/3(木)、9/4(金) ●大阪コース :8/26(水)、8/27(木)、8/28(金) ■各日開催時間 ●1日目/10:00~18:00 オリエンテーション、チーム開発 ●2日目/10:00~18:00 チーム開発 ●3日目/10:00~18:00 チーム開発、成果発表、懇親会 RAKUS Tech Labを通して得られる経験とスキル AI開発×顧客志向の開発体験 単に実装を進めるのではなく、「何を作るべきか」「なぜその実装にするのか」を考えながら開発を進めます。AIツールも活用しつつ、生成された内容をそのまま使うのではなく、顧客視点に立って検証し、適切な選択を行います。 ラクスが大切にしている「AI開発と顧客志向を掛け合わせた開発」を体験いただきます。 チームで成果を発揮する開発体験 開発は個人で完結するものではなく、チームで進めていくものです。 ラクスではひとり一人が力を発揮し、チームに貢献することや互いに助け合うことを大切にしています。 本インターンでは、メンバー同士で議論しながら方針を決め、実装を進めていきます。 意見が分かれたり、進め方に迷う場面もありますが、 そうしたプロセスを通じて、チームで開発を進める難しさと面白さの両方を体験いただきます。 実務に近いフィードバック 開発中は、社員メンターが技術面だけでなく、設計や価値の観点からフィードバックを行います。「なぜこの実装にしたのか」 「他に選択肢はなかったのか」といった問いを通じて、実際の開発現場に近い視点を学ぶことができます。 実際に参加した学生の声 実際に参加いただいた方の声をご紹介します! 国内最大級のエンジニア学生のデータベースを持つ株式会社サポーターズ社発表、「参加してよかったエンジニアサマーインターンシップランキング2025」TOP26位にランクインしました! biz.supporterz.jp インターンシップでお会いしましょう! RAKUS Tech Labでは、AIを活用しながら、顧客視点に立ち 「何を作るべきか」を考え、選択し、その理由を言語化する。 そんな開発の進め方に、向き合っていただきます。 実際の開発現場に近い環境で、ラクスのエンジニアの働き方もぜひ体感してください。 エントリーの詳細は以下からご覧いただけます。 https://rakus-newgraduate.snar.jp/jobboard/detail.aspx?id=lTWVvD66xME 少しでも興味を持っていただけた方は、ぜひご応募ください。 みなさんとお会いできることを楽しみにしています!
1. はじめに なぜ改善が必要だったか どんな改善をした? 2. バージョンアップ運用フロー 2-1. CIによる機械的チェック(GitHub Actions) ①helm templateコマンドによるレンダリングチェック 実装詳細 ②PlutoによるKubernetes API互換性チェック 実装詳細 ③HelmChart展開後のマニフェスト差分把握 実装詳細 2-2. AIによる影響調査 AIレビューコメント例 なぜラベル起動にしたか プロンプト なぜDevinを選定したのか 3. 導入後の効果 4. 今後の展望 5. まとめ 参考文献 1. はじめに こんにちは!SRE課のモリモトです。 本記事では、CIとAIでKubernetesエコシステムのバージョンアップ運用を改善した事例をご紹介します。 なぜ改善が必要だったか SREチームでは、Kubernetesエコシステムの多数のOSSを社内共通Helm Chartとして管理し、各プロダクトチームへ提供しています。 バージョンの更新検知にはRenovateを利用していますが、バージョンアップPRを継続的に処理する運用が確立されておらず、PRが滞留している状態でした。 その結果、差分がますます大きくなり動作確認や影響調査のコストが増大し、脆弱性対応等の緊急性の高いもの以外は対応できておりませんでした。 この状況を解消するため、バージョンアップ作業の効率化とチーム全員で継続的に対応できる仕組みづくりを行う必要がありました。 どんな改善をした? まずCIで機械的に判定できるリスクを先に落とし、次にAIでリリースノート確認や影響調査を行い、人間は動作確認と最終判断を行うのみとすることでバージョンアップ対応を効率化しました。 2. バージョンアップ運用フロー 今回構築した運用フローは以下の6ステップです。 Step 自動化レベル 内容 1 自動 Renovate PRが作成される 2 自動 CIによる機械的チェック 3 半自動 PRに対して review-renovate-pr ラベル付与することで、AIレビューを起動 4 手動 人間がAIチェックレポートを確認し、マージ可否を判断 5 手動 develop ブランチにマージし、検証用クラスタで動作確認 6 手動 main ブランチにマージ Renovateによる自動検知から始まり、CIとAIによるチェックを経て、最終的に人間が判断・検証を行う「自動化と安全性のバランス」を重視したフローになっています。 ここから、Step2とStep3の中身について紹介していきます。 2-1. CIによる機械的チェック(GitHub Actions) RenovateによってHelm ChartのバージョンアップPRが作成された際に、3種類の機械的なチェックを実行することで明らかにマージ不可なものを振り落としていきます。 ①helm templateコマンドによるレンダリングチェック バージョンアップによってHelmテンプレートの構文エラーや必須パラメータの欠落が発生し、マニフェストが正常に出力できなくなる事態を未然に防ぐために、レンダリングチェックを行っています。 実装詳細 リポジトリに存在するすべてのChartを毎回チェックするとCIの実行時間が増大してしまうため、まずは git diff を用いて変更があったChartのディレクトリのみを抽出し、動的にテストマトリクスを生成します。 # 変更されたHelmチャートを検出してマトリックスを作成 set-matrix : run : | # 変更があったファイルのパスを抽出(例: charts/app-name/values.yaml) targets=$(git diff --diff-filter=AMR --name-only \ "${{ github.event.pull_request.base.sha }}" \ "${{ github.event.pull_request.head.sha }}" \ -- "${{ inputs.chart_dir }}" ) if [ -z "${targets}" ] ; then targets=$(jq -nc '[]' ) else # ディレクトリ階層を整理して重複を排除し、JSON配列に変換 # 例: 'charts/app-a/values.yaml' -> 'charts/app-a' のように抽出 # ※注意:リポジトリのディレクトリ構成に合わせて cut の階層 (-f 1,2) は適宜変更してください targets=$(printf '%s\n' "${targets}" | cut -d '/' -f 1 , 2 | sort -u | jq -R | jq -sc) fi echo "value=${targets}" >> "$GITHUB_OUTPUT" その上で、抽出された各Chartに対して以下のチェックを行います。 依存関係の解決: helm dependency update を実行し、サブチャートを含めて正しく依存関係が解決できるか確認。 環境ごとの網羅的チェック: values/ ディレクトリ配下に配置された各環境用(開発・本番など)のvaluesファイルをループ処理し、ベースの values.yaml と組み合わせて helm template が成功するかを確認。 # Helm dependency update if [[ -f " $CHART_PATH /Chart.yaml " ]] ; then echo " Running helm dependency update... " helm dependency update " $CHART_PATH " 2 >& 1 fi # values/ ディレクトリ内の全valuesファイルでテンプレート実行 VALUES_DIR = " $CHART_PATH /values " if [[ -d " $VALUES_DIR " ]] ; then for values_file in " $VALUES_DIR " /*.yaml ; do # ベースのvalues.yamlと環境特有のvalues.yamlをマージしてテスト helm template " $CHART_NAME " " $CHART_PATH " \ -f " $CHART_PATH /values.yaml " \ -f " $values_file " > /dev/null 2 >& 1 if [[ $? -eq 0 ]] ; then echo " ✅ Successfully rendered with $( basename " $values_file " ) " else echo " ::error::Failed to render $CHART_PATH with values: $( basename " $values_file " ) " exit 1 fi done fi これにより、「一部の環境のvaluesファイルとの組み合わせでのみテンプレートのレンダリングに失敗する」といった状況を早期に検知・除外できます。 ②PlutoによるKubernetes API互換性チェック 非推奨または削除されたAPIを利用しているマニフェストが原因で障害が起きることは避けたいので、 Pluto を用いてk8s APIの互換性チェックを組み込んでいます。 実装詳細 pluto detect-files を実行し、Helm Chart内に非推奨APIや削除予定のAPIが含まれていないかをスキャンします。(チェック対象のk8sバージョンは現在のk8sクラスタのバージョンに設定) pluto detect-files -d " ${CHART_PATH} " \ -o wide \ --target-versions " k8s= ${ { inputs.target_k 8 s_version } } " ③HelmChart展開後のマニフェスト差分把握 Helm Chartのバージョンアップの際に、「Chartのバージョンが上がったことで、最終的に出力されるKubernetesマニフェストにどのような変化が起きるのか?影響のある値の変更が入っているか?」を把握するのが非常に面倒でした。 そこで、 マニフェストの差分(Diff)を自動生成してPRにコメントを投稿する仕組みを組み込みました。 ※以下の例は現在弊社で使用しているバージョンではありません。 PRコメントの例 実装詳細 まずは、git worktreeを活用してCI内で一時ディレクトリを作成し、PRの base(変更前)と head(変更後)のコードツリーを同時に展開します。 そして、それぞれのツリーで対象のvaluesファイルを適用して helm template を実行し、出力された展開後のマニフェスト同士を diff コマンドで比較します。 # 一時ディレクトリを作成(例: /tmp/tmp.xxxxx) WORK_DIR = $( mktemp -d ) # 1. PRの変更前(base)と変更後(head)のコードを別々のディレクトリに展開 git worktree add --detach " $WORK_DIR /base " " ${ { github.event.pull_request.base.sha } } " git worktree add --detach " $WORK_DIR /head " " ${ { github.event.pull_request.head.sha } } " # 2. 変更前(base)のソースからマニフェストをレンダリングして保存 helm template " ${CHART_NAME} " " $WORK_DIR /base/ ${CHART_PATH} " \ -f " $WORK_DIR /base/ ${CHART_PATH} /values.yaml " \ -f " $WORK_DIR /base/ ${CHART_PATH} /values/main.yaml " \ --output-dir " $WORK_DIR /rendered-base " # 3. 変更後(head)のソースからマニフェストをレンダリングして保存 helm template " ${CHART_NAME} " " $WORK_DIR /head/ ${CHART_PATH} " \ -f " $WORK_DIR /head/ ${CHART_PATH} /values.yaml " \ -f " $WORK_DIR /head/ ${CHART_PATH} /values/main.yaml " \ --output-dir " $WORK_DIR /rendered-head " # 4. レンダリング結果のディレクトリ同士を比較し、差分ファイルを出力 diff -r -U 3 -N " $WORK_DIR /rendered-base/ " " $WORK_DIR /rendered-head/ " > /tmp/helm-diff.txt || true その後、出力された差分をgh cliを使ってPRに投稿します。 差分が200行を超える大規模な変更だった場合はPRコメントの文字数制限にひっかからないように、表示するのは先頭200行のみでそれ以降は「以下省略。詳細はGitHub Actionsのログをご確認ください」というメッセージと共に該当ActionログへのURLを案内する工夫を入れています。 ※もっと綺麗に書ける気がします。汚くてすみません。。 DIFF_OUTPUT = $( cat " $DIFF_FILE " || echo "" ) LINE_COUNT = $( echo " $DIFF_OUTPUT " | wc -l ) # 差分が長すぎる(200行超)場合は丸める処理 if [ " $LINE_COUNT " -gt 200 ]; then DIFF_OUTPUT = $( echo " $DIFF_OUTPUT " | head -200 ) JOB_ID = $( gh api " /repos/ ${GH_REPOSITORY} /actions/runs/ ${GH_ACTIONS_RUN_ID} /jobs " \ --jq " .jobs[] | select(.name == \" diff-helm-charts ( $CHART_PATH ) \" ) | .id " ) ACTIONS_URL = " ${GH_SERVER_URL} / ${GH_REPOSITORY} /actions/runs/ ${GH_ACTIONS_RUN_ID} /job/ ${JOB_ID} " DIFF_OUTPUT = " ${DIFF_OUTPUT} ... 以下省略。詳細はGitHub Actionsのログをご確認ください。 ${ACTIONS_URL} " fi # PRに投稿するコメントボディを作成 if [ -z " $DIFF_OUTPUT " ]; then BODY = " ### ✅ Diff: \` ${CHART_PATH} \` 差分は検出されませんでした。 ※ \` ${VALUES_FILES_TEXT} \` を適用し、HelmChart展開後のマニフェスト差分をバージョンアップ前後で確認 " else # 改行とバッククォートの間の空白を完全に削除 BODY = " ### ⚠️ Diff: \` ${CHART_PATH} \` 差分が検出されました。 ※ \` ${VALUES_FILES_TEXT} \` を適用し、HelmChart展開後のマニフェスト差分をバージョンアップ前後で確認 以下は差分内容です。 \`\` \ `diff ${DIFF_OUTPUT} \`\`\` " fi # PRへコメント投稿 gh pr comment " ${GH_PR_NUMBER} " \ --repo " ${GH_REPOSITORY} " \ --body " $BODY " 展開後の差分を可視化することにより、レビュアー(人間)はもちろん、この後に解説する AIもマニフェストの差分を把握することができるので、影響調査の精度を向上させることができます。 2-2. AIによる影響調査 リリースノートをすべて確認して影響調査をするのが非常に手間がかかる作業だったので、AIを活用して改善しました。 仕組みとしては、RenovatePRに review-renovate-pr ラベルを付与することでGitHub Actionsが起動し、GitHub ActionsからDevinのPlaybookを起動することでバージョンアップ調査・レビュー用セッションを起動する仕組みを構築しました。 AIレビューコメント例 バージョンアップによる変更点が一覧化され、それが既存のコードに影響があるのかをAIがチェックしてくれています。 ※以下の例は現在弊社で使用しているバージョンではありません。 AIレビューコメント① AIレビューコメント② なぜラベル起動にしたか すべてのRenovate PRに対してAIレビューを常時起動させることも可能ですが、AIのコストが膨れ上がってしまうことを懸念し、あえて「人間のラベル付与」をトリガーとして必要なときのみに起動するようにしました。 プロンプト AIに以下の内容をチェックさせるためのプロンプトを渡しています。 対象OSSの公式リリースノートやChangelogを確認し、破壊的変更や非推奨になったパラメータがないか リポジトリ内の既存コード(k8sマニフェスト、アプリケーションコード等)に対する影響がないか プロンプトについては、以下ブログに記載されているものを大いに参考にさせていただいております🙇♂️🙇♂️ ありがとうございます🙇♂️🙇♂️ tech.uzabase.com **重要**: メジャーおよびマイナー更新では、**各バージョンごとに個別に評価**すること という指示を与えているのでリリースノートの読み飛ばしを防ぐことができ、高い精度で調査してくれているなと感じています。 ## 概要 Renovateによって自動生成されたプルリクエスト(PR)をレビューし、ライブラリ(helm chartやイメージバージョン)のアップデートに伴う変更点の調査、エビデンスに基づく差分分析、コードへの影響評価、および推奨するアクションの提示を実施します。 ## ユーザーに必要なもの - レビュー対象のRenovateのプルリクエストのURL ## 手順 1. 指定されたRenovateのプルリクエストを開き、以下を正確に特定してください。 - アップデート対象ライブラリ名 - 旧バージョン → 新バージョン - メジャー / マイナー / パッチの種別 2. アップデート対象となった各ライブラリの公式ドキュメント、リリースノート、変更履歴(changelog)などを参照し、バージョン間の主要な変更点(新機能、非推奨機能、破壊的変更、バグ修正など)を特定してください。単に「旧→新」を比較するのではなく、以下を必ず実施してください。 2-1. 更新タイプの分類 - メジャー(1.x → 2.x):高リスク、破壊的変更の可能性大 - マイナー(1.1 → 1.2):中リスク、新機能 - パッチ(1.1.1 → 1.1.2):低リスク、バグ修正 2-2. メジャー・マイナーバージョン更新時の評価方法 - **重要**: メジャーおよびマイナー更新では、**各バージョンごとに個別に評価**すること - 例: v1.5.0 → v1.7.0 の場合 - v1.5.0 → v1.6.0 の変更を評価 - v1.6.0 → v1.7.0 の変更を評価 - それぞれのバージョンの変更内容を明記 - パッチバージョン更新は集約して評価可能 2-3. 複数バージョンジャンプの場合(例:3.18.2→3.19.0) - すべての中間バージョンを分析 - バージョン間の変更を集約 - 累積的な影響を強調 3. 特定したライブラリの変更点を、元のRenovateのプルリクエストにGitHubのコメント機能を使用して、「ライブラリ変更点の概要」として記載してください。その際に以下のルールを必ず守ってください。 - コメントタイトル: **ライブラリ変更点の概要** - 破壊的変更やCRD変更、対応必須と思われるものについては特に明記 - 各変更点について、必ずエビデンス(一次情報)を明示 4. ライブラリの変更点を踏まえ、リポジトリ内の既存コード(k8sマニフェスト、アプリケーションコード等)への影響範囲を調査してください。具体的には、以下のような点を確認してください。 - 調査観点 - 廃止されたAPIや変更されたAPIの使用箇所 - 廃止されたパラメータや変更されたパラメータの使用箇所 - 仕様変更に伴い、修正が必要となるロジック - アップデートによる潜在的なバグやパフォーマンスへの影響 - 推奨機能を使用していない箇所、非推奨機能の使用箇所 5. 調査したコードへの影響範囲と、推奨される修正対応について、元のRenovateのプルリクエストにGitHubのコメント機能を使用して、「コードへの影響と推奨アクション」として記載してください。その際に以下のルールを必ず守ってください。 - コメントタイトル: **コードへの影響と推奨アクション** - コメントの最初に、以下のような**評価サマリ**を記述すること。 - リスクレベル(低・中・高) - マージ判定(マージ可能、条件付きでマージ可能、このままではマージ不可) - 各調査結果について、必ずエビデンス(一次情報)を明示すること。「影響がない」と判断する場合も、その根拠を明示すること。 ## 仕様 1. Renovate PR には以下がコメントとして記載されていること。 - 「ライブラリ変更点の概要」 - 「コードへの影響と推奨アクション」 2. いずれのPRも、レビュー承認なしにマージされていないこと。 ## アドバイスとポイント 1. ライブラリの変更点を調査する際は、公式ドキュメントやリリースノートを最優先の情報源としてください。フォーラムやIssue Trackerの情報は補助的に使用してください。 2. コードへの影響調査は、直接的な利用箇所だけでなく、間接的な影響や全体的な動作への影響も考慮に入れてください。 3. GitHubへのコメントやプルリクエストの説明文は、他の開発者が変更の意図と内容を迅速に理解できるよう、明確かつ簡潔に記述してください。 4. 「差分が小さい」「影響は軽微」という表現は、必ず理由とURLを伴わせてください。 5. 大規模な変更や判断に迷う場合は、理由を明記した上で「判断保留」と明示してください。 ## 禁止事項 1. レビュアーの承認なしでのマージ禁止 2. エビデンスなしの断定禁止 3. 元のRenovate PR ブランチへの直接コミット禁止 なぜDevinを選定したのか 今回Devinを選択した理由は「とにかく早く形にして検証を回したかったから」です。 社内でDevinをCIから利用した事例があることを把握していたため、すぐ試せそうだったからという理由で選択しただけなので強いこだわりはありません。 GitHub Actions上からサブスク枠のClaudeやCodexを使う方法があるのであればそちらに変えたいなあと考えています。 3. 導入後の効果 個人的な体感で、 バージョンアップ対応1回あたりで1時間程度の短縮ができた と思っています。 特に、今までだと脆弱性対応以外のバージョンアップが滞っていたこともありバージョン差異が大きく、 膨大な量のリリースノートを確認して影響調査を行う必要があったため非常に大変でしたが、そこをAIが代替してくれる のでかなりの時間が短縮できました。 また、詳細は説明していないですが、動作確認用のk8sクラスタを整備して develop ブランチにマージするだけで即座に反映される環境を用意したことで、 動作確認にかかる時間も短縮することができました 。 また、現在進行中ですが動作確認手順の整備やAI活用も進んでいけばさらに短縮できると考えています。 4. 今後の展望 今後、時間があるときに以下のような箇所を改善・対応していきたいです。 リリースノートや影響の調査に利用しているAIの選定(コスト面、性能面) AIを利用した動作確認の自動化 この仕組みを他チームへ横展開 5. まとめ 日々増え続けるk8sエコシステムの運用改善に少しでもお役に立てたら嬉しいです。 最後までお読みいただきありがとうございました! 参考文献 zenn.dev zenn.dev tech.uzabase.com zenn.dev zenn.dev
こんにちは。SRE課のtaku_76です! 今回はKubernetesマニフェスト内の非推奨API / 削除済みAPIを継続的に検知する仕組みについて紹介します。 PlutoとGitHub Actionsを使い、定期実行から検出結果の更新まで自動で行うようにしました。 他チームにも使ってもらうことを想定していたため、Plutoを実行するだけでなく導入方法や検知結果の確認方法まで含めて運用に乗せる形にしています。 はじめに 仕組みを作成した目的 全体像 利用者の負担を減らすために工夫したこと Issueを作るだけで管理対象に追加できるようにした 結果確認をIssueに集約した READMEを自動生成して対象一覧を確認しやすくした 管理対象からの除外もIssue Close起点にした Actionsの設計 repos.jsonをmatrixに展開して複数リポジトリをチェックする helm templateでレンダリングしてからPlutoに渡す リポジトリごとのvalues差分を吸収する まとめ はじめに 仕組みを作成した目的 これまではKubernetesマニフェスト内の非推奨API / 削除済みAPIを定期的に確認する仕組みがありませんでした。 そのため、Kubernetesのバージョンアップ時に対象リポジトリを都度確認する必要があり、確認漏れがあるとアップデート後にリソースが適用できなくなる可能性があります。 このリスクを減らすために非推奨API / 削除済みAPIの利用状況を継続的に検知・追跡できる仕組みを作成しました。 また、対象リポジトリは複数ありそれぞれマニフェストの構成も少しずつ異なります。 そのため継続的に検知できるだけでなく利用者ができるだけ少ない手間で導入・確認できる形にすることも重視しました。 全体像 今回作成した仕組みでは、Kubernetesマニフェストを管理しているリポジトリを対象に非推奨API / 削除済みAPIが含まれていないかを定期的にチェックします。 検知にはPlutoを利用しました。PlutoはKubernetesマニフェストやHelm Chartなどに含まれる非推奨API / 削除済みAPIを検出できるツールです。 詳細は割愛しますが、対象のKubernetesバージョンを指定して実行することでそのバージョンで問題になるAPIを確認できます。 今回のworkflowでは、チェック対象のKubernetesバージョンとして実行時点のstableバージョンを取得してPlutoに渡しています。 そのため、Kubernetesのstableバージョンが更新された場合も次回実行時には新しいバージョンを基準に検知できます。 運用の流れは以下のようになります。 この記事では、リポジトリごとの検知結果を更新するIssueを管理用Issueと呼びます。 利用者側で必要な作業は、基本的に管理用Issueを作成することだけです。 運用の流れ 利用者の負担を減らすために工夫したこと Issueを作るだけで管理対象に追加できるようにした チェック対象のリポジトリはJSONファイルで管理しています。 JSONを直接編集してもらうこともできますが、利用者側に余計な作業を増やしたくありませんでした。 また、記載ミスや手順のばらつきも起きやすくなります。 そのため管理対象への追加はIssueを起点にすることにしました。 利用者はIssueテンプレートに沿って、以下の情報を入力します。 チェック対象リポジトリ チェック対象ブランチ values/ 配下で利用するvaluesファイル issue Issueが作成されるとGitHub Actionsが起動し、入力内容をもとにJSONファイルを更新するPull Requestを自動作成します。 最終的な反映は管理者がPull Requestを確認してから行うため、利用者の作業を減らしつつ追加内容も確認できる形にしています。 結果確認をIssueに集約した Plutoの検出結果は対象リポジトリごとに紐づいたIssueに更新しています。 以下のような運用は利用者の手間になるので避けました。 Actionsのログで結果を確認する 日次チェックの結果ごとに新しいIssueを作成する リポジトリごとに管理用Issueを用意し、チェック結果でIssue本文を上書き更新する形にしました。 Issueのイメージは以下です。 結果 検出結果がない場合は「検出なし」として更新します。 これによりチェックが実行されていないのか、問題が検出されなかったのかを区別できます。 READMEを自動生成して対象一覧を確認しやすくした 管理対象の一覧はJSONをもとにREADMEへ自動反映しています。 対象が増えてくると、どのIssueでどのリポジトリをチェックしているのか追いづらくなるためREADMEで一覧を可視化しました。 表示内容は対象リポジトリ・ブランチ・valuesファイル・管理用Issueへのリンクです。 これによりチェック対象と確認先のIssueをすぐ確認できます。 ↓イメージ readme 管理対象からの除外もIssue Close起点にした 管理対象から外す場合も、JSONファイルを直接編集するのではなく対象の管理用IssueをCloseする運用にしました。 IssueがCloseされるとGitHub Actionsが起動し、対象のIssueに紐づく情報をJSONファイルから削除するPull Requestを作成します。 これにより利用者はIssueをCloseするだけで管理対象からの除外を依頼できます。 Actionsの設計 ここからはGitHub Actions側でどのように複数リポジトリをチェックしているかを紹介します。 この仕組みではチェック対象のリポジトリ情報を .github/repos.json で管理しています。 GitHub Actionsでは、このJSONに登録された情報をもとにリポジトリごとにチェックを実行しています。 repos.jsonをmatrixに展開して複数リポジトリをチェックする チェック対象のリポジトリ情報は .github/repos.json にまとめています。 例えば1つの対象リポジトリは以下のような形式で管理しています。 { " repo ": " example-manifests ", " branch ": " main ", " valuesFile ": " prd-001.yaml ", " issue ": 123 } 各項目には、対象リポジトリ、ブランチ、valuesファイル、更新対象Issue番号を持たせています。 複数リポジトリを扱う前提だったため、workflowにリポジトリ情報を直接書くのではなく repos.json でまとめることにしました。 日次チェック用のworkflowでは、この repos.json を jq -c で1行のJSONに変換し、GitHub Actionsの fromJSON を使ってmatrixに展開しています。 matrixに展開することで、登録されているリポジトリごとに同じチェック処理を実行できます。 対象を追加する場合も repos.json にリポジトリ情報を追加すれば次回のチェックから対象に含まれるため、workflow本体を修正せずに済みます。 実際のチェック処理はreusable workflowにまとめており、以下の処理を行っています。 ワークフロー helm templateでレンダリングしてからPlutoに渡す 対象リポジトリではKubernetesマニフェストをHelm Chartとして管理しています。 そのためPlutoにChartのテンプレートファイルをそのまま渡すのではなく、まず helm template でvaluesを反映したKubernetesマニフェストを生成しています。 チェック処理では、対象リポジトリの manifests/* 配下を見て Chart.yaml があるディレクトリをHelm Chartとして扱います。 処理としては以下の流れになります。 チェック処理 Plutoはレンダリング後のマニフェストを確認するため、実際に適用される内容に近い状態で非推奨API / 削除済みAPIを検知できます。 また、Helm Chartの crds/ 配下にあるCRDも出力に含めるため helm template では --include-crds を指定しています。 リポジトリごとのvalues差分を吸収する 基本的には、各Chartに対して以下のvaluesファイルを指定して helm template を実行しています。 values.yaml values/<valuesFile> ただし、リポジトリによってはこれだけではレンダリングに必要な値が足りない場合があります。 例えばあるChartが別のChart用のvaluesを参照していたり、共通設定を別ファイルに分けていたりするケースです。 そのため、 .github/repos.json には任意でChartごとの追加valuesファイルを指定できるようにしました。 以下イメージです。 { " repo ": " example-app-manifests ", " branch ": " main ", " valuesFile ": " test.yaml ", " issue ": 123 , " valueFiles ": { " app-a ": [ " common/values.yaml ", " database/values/prd.yaml " ] } } workflow側にリポジトリごとの例外を増やしていくと管理がつらくなるため、差分は repos.json 側に寄せるようにしました。 これによりworkflow側は共通のままリポジトリごとのvalues構成に対応できます。 まとめ 今回は、PlutoとGitHub Actionsを使って、Kubernetesマニフェスト内の非推奨API / 削除済みAPIを継続的に検知する仕組みを作成しました。 Issueを起点に管理対象の追加や結果確認を行うことで、利用者の作業をできるだけ増やさずに継続的に確認できる形を意識しました。 今後は運用しながら課題が見つかれば改善していきたいと考えています。
はじめに 開発部と事業部では、見ているものが少し違う 開発観点だけで判断を閉じると、議論が進みにくくなる 議論が噛み合わなくなるのは、「必要性」と「実現性」が混ざるとき 要望をそのまま受け取らず、課題として整理する 「やるか・やらないか」ではなく、スコープを分ける 仕様だけでなく、届け方まで含めて考える まとめ はじめに 楽楽勤怠のプロダクトマネジメントをしている @k0First です。 PdMとして仕事をしていると、開発部と事業部の相談MTGで、同じテーマについて話しているはずなのに、少し議論が噛み合わないと感じることがあります。 もちろん、どちらかが間違っているわけではありません。 ただ、議論がうまく前に進まないときは、見ている論点や重視している判断軸が少しずれていることが多いように思います。 そこで、開発部と事業部の相談MTGで扱ってきた相談ごとと、その顛末をまとめたシートをもとに、ChatGPTで内容を整理・分析してみました。 どんな相談があり、最終的にどう着地したのかを振り返りながら、開発部と事業部がそれぞれどのような観点で判断しているのかを見える化した、というイメージです。 その整理を通して見えてきたのが、開発部と事業部では、同じテーマを見ていても重視するポイントが少し違うということでした。 そして、その違いを前提に論点を整理できると、議論はかなり進めやすくなります。 この記事では、シートの分析から見えてきた「開発部と事業部の判断軸の違い」と、そこからPdMとして意識したい論点整理のポイントをまとめます。 開発部と事業部では、見ているものが少し違う 相談内容とその顛末を見返してみると、開発部と事業部では、意思決定の際に重視している観点に違いがありました。 観点 開発部 事業部 基本スタンス 安全に実現できるか 顧客・事業に価値があるか まず見ること 実装難易度、保守性、既存仕様との整合 顧客影響、売上影響、現場運用への効果 重視するリスク 不具合、性能悪化、複雑化、運用事故 顧客混乱、失注、問い合わせ増、周知漏れ 優先順位の付け方 工数対効果、スコープ分割、MVP化 顧客影響度、案件重要度、Must/Better判断 仕様判断の軸 一貫性があるか、例外を増やさないか 現場で説明・運用できるか、売れるか こうして並べてみると、開発部は 実現性・整合性・保守性 を、事業部は 顧客価値・事業インパクト・運用性 を重視していることがわかります。 これは、どちらが正しいという話ではありません。 役割が違えば、自然と重視するものも変わります。 むしろ、この違いがあるからこそ、プロダクトにとって健全な議論ができるとも言えます。 一方で、この違いが言語化されていないまま話し始めると、「なんとなく話が噛み合わない」という感覚だけが残りやすくなります。 PdMとしては、この違いを整理して、議論しやすい形に変換することに価値があると感じています。 開発観点だけで判断を閉じると、議論が進みにくくなる 楽楽勤怠のPdMは開発の近くで仕事をすることが多いため、自然と「安全に作れるか」「既存仕様と矛盾しないか」「保守で困らないか」といった観点で考えやすくなります。 これはとても大事な視点ですし、プロダクトを継続的に育てていくためには欠かせません。 ただ、それだけで判断を閉じてしまうと、事業部が見ている価値が議論から抜け落ちやすくなります。 たとえば、事業部は次のようなことを見ています。 顧客にとって本当に重要か 売上や受注、失注防止にどれくらい効くか 現場で説明しやすいか 運用負荷を下げられるか 周知や移行で混乱が起きないか この観点をどう議論に乗せるかは、PdMの役割のひとつです。 開発部の観点を理解したうえで、事業部が見ている価値も議論の土台に置く。 このひと手間があるだけで、意思決定の納得感はかなり変わります。 議論が噛み合わなくなるのは、「必要性」と「実現性」が混ざるとき シートを見返していて特に多かったのが、必要性と実現性が同時に話されているケースでした。 たとえば、事業部は「顧客に必要だからやりたい」と話しているのに対して、開発部は「そのやり方だと複雑になる」「保守が厳しい」と返す、という場面です。 表面的には反対意見のように見えますが、実際には別の論点を話しているだけ、ということが少なくありません。 そのため、PdMとしては少なくとも次の2つを分けて整理しておくと、議論を前に進めやすくなります。 論点 主な内容 必要性 顧客影響、事業インパクト、売上影響、運用改善効果 実現性 実装難易度、既存仕様との整合、保守性、性能・障害リスク この整理があるだけで、 必要性は高いが、この形だと実現性が低い 実現はできるが、そこまで強い必要性はない といった形で話しやすくなります。 PdMとしては、答えを急いで出すことよりも、まず論点を揃えることのほうが大事だと感じています。 要望をそのまま受け取らず、課題として整理する 相談ごとは、要望や仕様案の形で入ってくることが多いです。 ただ、開発側が本当に知りたいのは「何を作るか」だけではなく、「何を解決したいのか」です。 そのため、PdMとしては要望をそのまま受け渡すのではなく、まず次のような形で整理してから議論に持ち込むようにしています。 誰が困っているのか 何に困っているのか 今はどう回避しているのか Mustなのか、Betterなのか 実現できた場合に何が改善するのか このひと手間があるだけで、開発部は「では別の実現方法もありそうだ」と考えやすくなります。 要望を課題に翻訳することは、PdMが価値を出しやすいポイントのひとつです。 「やるか・やらないか」ではなく、スコープを分ける シートを見返していて、議論が前に進んでいた相談ほど、「全部やるかどうか」ではなく、「どこまでを1stでやるか」が整理されていました。 たとえば、こんな分け方です。 1stリリースで必須のもの あると望ましいが後続でもよいもの 当面は運用回避でしのげるもの 今回はやらないが、将来の検討対象として残すもの この分解があると、開発部にとっては現実的に考えやすくなりますし、事業部にとっても「全部ダメだった」ではなく「何なら今できるか」で話せるようになります。 PdMとしては、この着地点を一緒に探していくことに大きな価値があると思っています。 仕様だけでなく、届け方まで含めて考える 相談の顛末を見ていると、仕様としては成立していても、実際にリリースして現場で回るかまで含めると判断が変わるケースがありました。 たとえば、次のような観点です。 顧客への説明は難しくないか FAQやマニュアル改修は大きくないか CSや導入支援の案内負荷は高くないか UI変更による混乱はないか リリース時期と周知時期は噛み合っているか 「作れること」と「ちゃんと届けられること」は別です。 PdMとしては、この後者まで視野に入れて論点を整理することが、よりよい意思決定につながると考えています。 まとめ 開発部と事業部の相談MTGで扱ってきた相談ごとと顛末を整理してみると、開発部は実現性・整合性・保守性を重視し、事業部は顧客価値・事業インパクト・運用性を重視していることが見えてきました。 PdMとして重要なのは、開発観点だけで判断を閉じないことです。 実現性・整合性・保守性をベースにしながら、事業部ならどう見るかも踏まえて論点を整理することで、議論は前に進めやすくなります。 特に、実務の中では次の4つを意識しています。 要望を課題として整理する 必要性と実現性を分けて考える スコープを分けて提案する 判断材料を揃えて議論に持ち込む 開発部と事業部のあいだで少し噛み合わなさを感じたときこそ、PdMが整理役として価値を出せる場面です。 これからも、こうした違いを前向きに捉えながら、議論を進めやすい形に整えていきたいと思っています。
こんにちは、CTOの公手です。 この4月から、ラクスの新しい中期経営計画がスタートしました。 前中期経営計画の5年間、私たちは「ハイグロース」を掲げ、売上・組織規模ともに約4倍という急成長を遂げました。次なる3年で私たちが目指すのは「クオリティグロース(質の高い成長)」です。AIを駆使して組織をより筋肉質に変え、真の意味で「強い」組織へと進化させるフェーズに入ります。 この方針のもと、次の中期経営計画で開発本部が推進する3つのプロダクト戦略と、それを実現するために不可欠な3つの変革について、簡単ではありますが共有できればと思います。 3つのプロダクト戦略:顧客体験の変革と領域の拡大 1. AI機能実装によるユーザー体験の変革 2. エンタープライズ市場への本格参入 3. 統合型ベストオブブリードへの進化 これらを実現するための3つの変革 AIネイティブ開発プロセスへの変革 クラウドネイティブオンプレミス(CNOP)の強力な推進 グローバルボーダレス開発 変わらない価値観:結局、それを支えるのは「顧客志向」 3つのプロダクト戦略:顧客体験の変革と領域の拡大 1. AI機能実装によるユーザー体験の変革 単なるUIの追加ではなく、AIがユーザーの意図を汲み取り先回りして処理を完結させる 「AIエージェント」 を全主要サービスへ展開します。目指すのは、顧客の業務工数を根本から削減すること。ユーザー操作自体を大幅に削減していく方向へ舵を切ります。また、AIエージェントから利用しやすいようにOpenAPIやMCP(Model Context Protocol)サーバーの展開も進めていきます。必要に応じてAI時代に適した技術刷新を厭わず推進していく方針です。 2. エンタープライズ市場への本格参入 中堅・中小企業市場で培った強みを武器に、大手企業市場へ本格参入します。大規模トラフィックへの耐性、膨大なデータハンドリング、権限管理や監査ログなどの高度なガバナンス要件、エンタープライズ特有の複雑な業務要件に対し、機能レベル、アーキテクチャレベルでもしっかりと対応を強化します。 3. 統合型ベストオブブリードへの進化 楽楽シリーズをさらにシームレスに繋ぎます。前中期経営計画で実現したUI統一や楽楽従業員ポータルの取り組みを、さらに推し進めていきます。従業員ポータルをハブとしたデータ連携を深化させ、顧客が「最高の個別製品(ベストオブブリード)」と「統合された利便性」を同時に享受できる状態を技術的に実現します。 これらを実現するための3つの変革 上記のプロダクト戦略はいずれも難易度が高く、これまでの開発プロセスの延長線上では達成できません。そこで、私たちは以下の3つの変革を断行します。 AIネイティブ開発プロセスへの変革 ここ数年のAI駆動開発の進化はめざましく、単なる補助ツールではなくなりました。すでにラクスでも、チームや機能によってはコード生成率が90%を超える事例が出始めており、平均しても50%程度のコーディング時間の削減は実現できています。しかしながら、生成AIの真価はコーディングの効率化にとどまりません。エンジニア自身がAIの特性と限界を誰よりも理解し、 「生成AIが開発の全プロセス(要件定義、設計、コーディング、テスト、デプロイ)を効率化すること」を前提としたプロセス へと作り変える必要性が出てきています。 まずは、コード生成率を極限まで高め、人間が「ゼロから書く」時間を削減します。これにより、エンジニアの工数を「AIのコントロール」や「より高度な全体設計」、そして「顧客の真の課題解決」へとシフトさせます。AIを活用して開発速度を上げることは、そのまま顧客への価値提供サイクルを速めることに直結します。 クラウドネイティブオンプレミス(CNOP)の強力な推進 私たちが考えるCNOP基盤とは、オンプレミスのコスト効率とパブリッククラウドの技術・思想(コンテナ、K8sなど)を融合させ、高いアジリティを実現するものです。また、パブリッククラウドとのハイブリッド構成も容易にし、ワークロードに応じた最適な環境選択を可能にするものでもあります。 具体的に推進することは、一部のサービスで実現できている、オンプレミスのコストメリットを維持しつつ、Kubernetes(K8s)を中心としたコンテナ基盤運用の全面的な導入です。 さらに、自社製マネージドサービスを構築するなど、パブリッククラウドに匹敵する開発の容易性とリリース速度(アジリティ)の実現を目指します。 自社インフラならではの高品質・高可用性を実現することで、エンタープライズ顧客の高度な要求に応えられるインフラ基盤を提供します。 グローバルボーダレス開発 ラクスには、一つのSaaS企業に匹敵する規模のサービスが複数存在し、サービスの総数は10を超えます。これらのサービス群において、この3つのプロダクト戦略をスピーディに実現するには、必然的に開発ボリュームが増大します。これを国内リソースだけで賄うのは現実的ではなく、海外のエンジニアと「一つのチーム」として機能する体制が不可欠です。 特に、 生成AIの進化により、言語の壁やドメイン知識の壁は劇的に低くなっています 。この技術を最大限に活用し、ベトナムやインドネシアなどの海外拠点を、単なる受託先ではなく、同じ品質基準と設計思想を共有する真のパートナーとして統合していきます。拠点の違いを意識することなく、仕様の同期と開発の加速を可能にする「ボーダレスな共創体制」を実現します。また、多様な視点を持つグローバルな組織力が、この進化の激しい開発現場において、強力な革新性をもって変革を推し進める助けになると考えています。 変わらない価値観:結局、それを支えるのは「顧客志向」 これからの時代、エンジニアの働き方は劇的に変わります。AIネイティブ開発による「超シフトレフト」が進み、技術の自動化が進むほど、エンジニアに求められるのは「何を作るべきか」という判断力と顧客への深い理解です。 ラクスのプロダクトをご利用いただいているのは、日々オフィス業務をこなしている実務担当者の方々です。その方たちが「あ、楽になった」「もっと重要な仕事に時間を使えた」と感じてくれる瞬間のために、私たちは仕事をしています。 どれだけ技術やプロセスが変わろうとも、私たちの根底にある価値観は創業当初から一切ぶれません。それは 「顧客志向」 です。技術はあくまで手段であり、目的は常にお客様のペイン(課題・痛み)を解消することにあります。 このシンプルな原則を胸に、私たちは次の中期経営計画を実現していきます。 今回は概要の説明にとどまり、やや抽象的な内容となりましたが、また機会があれば、それぞれについてより具体的に説明したいと考えています。 AIの台頭に不安を感じる声は、社内でもよく聞かれます。しかし私は、変化の大きい時代だからこそ、「技術の自己目的化を排し、顧客価値を届けることに全力を注げるエンジニア・デザイナー」が最も強いと確信しています。この軸がある人は、どんな新しいツールや手法が出てきても乗りこなせると思っています。ラクスを、そのようなエンジニア・デザイナーが集まる組織にしていきたいと思っています。 まだ完璧ではありませんし、泥臭い課題も山積みです。しかし、その壁を共に壊し、この新しい挑戦に、 一緒に楽しみながら 取り組んでくれる仲間を募集しています。
楽楽明細、楽楽電子保存、楽楽債権管理と複数プロダクトのプロダクトマネジメントを担当しています。 紀井 です。 4月より、この複数プロダクトのプロダクトマネジメントを担う組織の課長に就任しました。所信表明も踏まえて、私がプロダクトマネジメントを意識するようになったきっかけと、今考えていることについてお話しします。 「Whyのない開発」が、私にプロダクトマネジメントを教えた PMFしたら、終わり?違う。そこからが、始まり ラクスのプロダクトマネージャーが目指すこと あなたの原動力は、なんですか? 最後に 「Whyのない開発」が、私にプロダクトマネジメントを教えた 新卒でエンジニアとしてキャリアをスタートし、プロジェクトマネージャーとして開発を回していた頃、私はずっと「仕様を正確に実現すること」に全力を注いでいました。 品質、コスト、納期。QCDを守ることが仕事だと信じていました。 でも、あるとき気づいたんです。 「なぜこの機能が必要なのか」を誰も説明できないまま、私たちは何ヶ月もかけて開発し、リリースしていた、と。 機能は動く。仕様通りだ。でもユーザーは使っているのか?喜んでいるお客様の顔が、見えない。 仕様通りに作ることは、価値を届けるための手段のはずだった。それがいつしか、目的になっていた。 その事実に気づいたとき、「プロダクトマネジメント」という考え方に興味を持ちました。 2021年にPdMに転身した後は、「Why」を起点にすることを自分の核にしてきました。 インボイス制度対応のような大規模プロジェクトでも、MVPを定義し、「やらないことを決める」ことでチーム全体のリソースを価値に直結させる。 その結果として、お客様の業務が確実に前に進むことを意識してきました。 PMFしたら、終わり?違う。そこからが、始まり この10年、クラウドサービスが業務の当たり前になっていく過程を、最前線で見てきました。 「楽楽精算」が市場に受け入れられ、多くの企業に使われるプロダクトへと成長していく様子を、開発者として、PdMとして、肌身で感じてきました。BtoBプロダクトでシェアNo.1になるというのは、家族や友人、勉強会などで交流した人など、自身の身の回りの人達がプロダクトのユーザーになることが日常になっていきます。街ですれ違う人が、自分が担当するプロダクトのユーザーかもしれない、そんなことを思うようになります。 そんな経験をしながらも、1つ肝に銘じていることがあります。 No.1になっても、解決できていないお客様のペインは、まだ山ほど残っている。 長く使われ続けるプロダクトであるためには、プロダクトマネジメント思考が不可欠です。これは、PdMだけでなく、プロダクト開発に携わるすべての人に必要なものだと思っています。 PMFしたら終わりではない。また新たなフェーズが始まる。 市場も、顧客も、競合も、すべて変わり続けるものです。 ラクスの提供するプロダクトはまだまだ未完成です。 もし「うちのプロダクトは完成されている」と感じているなら、その前提は一度、問い直してみた方がよいでしょう。 AIが業務に溶け込み始めた今、また大きな変化の波が来ています。 「守り」から「攻め」へ。法改正対応から、AIによる業務変革へ。 AIは開発を置き換えるものではなく、お客様の課題の解決を加速させる手段です。 この変化を、チームと一緒に乗りこなしていきたいと考えています。 ラクスのプロダクトマネージャーが目指すこと 顧客・ビジネス・技術、三者の声に等しく向き合い、統合する。 圧倒的な実行力でプロダクトマネジメントを遂行する。 PdMは、誰か一方の代理人であるべきではないと考えています。 エンジニア側の事情をそのままビジネス側に伝えるだけの人でもなく、ビジネスの要望をそのまま開発に渡すだけの人でもない。 顧客の課題を中心に据えながら、ビジネスの論理と技術の現実を、自分の判断で統合できる人間でありたい。 動くものを作る。見せる。試す。 そのサイクルを、AIやツールも使いながら、できる限り速く回す。 そうした動きが自然にできるチームをつくりたいと思っています。 あなたの原動力は、なんですか? 問題解決を行う手段としてプロダクト開発を生業とするのであれば、スキルと意欲、どちらも大事です。 でも正直に言うと、私が一番気にするのは「原動力」です。 なぜ、プロダクトマネジメントを自分の軸に据えたいのか。 その理由が、自分の中で言語化できている人と一緒に難題を解いていきたい。 「仕様通りに作ったのに、誰にも使われなかった」 「エンジニアとビジネスの間で、何度もすり減った」 「顧客の声が、どこにも届いていないと感じた」 そういう違和感や痛みを、自分の中で放置しなかった人。 複雑な課題に向き合い続けることが難しくなる場面もあります。 原動力はそんな時、踏ん張れる、そして立ち上がる一歩を助けてくれると思っています。 最後に プロダクトマネージャーを募集しています。 ラクスの提供するプロダクトは、まだまだ未完成です。 だからこそ、一緒に磨き続けてくれる方と出会いたいと思っています。 少しでも興味を持たれた方はこちらもどうぞ! note.com
こんにちは、プロダクト部 部長の稲垣です。(自己紹介やこれまでのキャリアについて↓をご覧ください。) tech-blog.rakus.co.jp 2027年3月期の初日ということで、自組織でもキックオフMTGを先月実施しました。プロダクト部が組成されてちょうど1年経ちましたので、昨年度の振り返りと今期の取り組みや今後とその先について、今考えていることをまとめてみました。 ※本記事は、プロダクト部の取り組みを紹介する目的で、執筆時点の考えを整理したものです。状況や学びに応じて、方針や進め方はアップデートしていきます。 2026年3月期の振り返り(確かな歩みと見えてきた本質) 組織強化という「Good」な成果 「More」から見えた本質的な課題:製品貢献度確認アンケートの真意 下期表彰:進化を体現したメンバーたち 次中期方針(変わらない軸と、目指すべき組織の姿) プロダクト部のMissionとVision 戦略ゴールのポイント 組織として目指すべき状態:全メンバーの上流への染み出し 【プロダクト部】役割/責務/活動領域と「UX志向の行動」 2027年3月期上期 重点取り組み事項(進化を加速させるアクション) スローガン:「一言」でまとめると 組織体制の大枠 各役割で重要視する「AI×上流シフト」 実現を目指す3つのプロダクト戦略 2026年3月期の振り返り(確かな歩みと見えてきた本質) まずは直近1年間の振り返りです。組織としての成長と、次へ向かうための課題が明確になった期間でした。 組織強化という「Good」な成果 昨年度の最も大きな成果は、なんといっても組織の基盤が強固になったことです。プロダクト部は現在、30名を超える組織へと拡大し、デザイナー、プロダクトマネージャー(PdM)ともに大幅な増員と組織強化を実現することができました。マネジメントやリーダー、シニア層も複数名増え、体制がより盤石になってきています。 この成長は決して自然に起こったものではありません。各マネージャーの献身的な頑張りはもちろんのこと、現場のメンバー一人ひとりが採用活動や社外への発信に積極的に協力してくれた結果です。チーム全員で組織を創り上げているという実感があり、この場を借りてメンバー全員に心からの感謝を伝えたいと思います。 また、スキルや役割の面でも良い変化が起きています。デザイナーはより深いUXの領域へ、PdMはプロダクト戦略やPMM(プロダクトマーケティングマネージャー)の領域へと、それぞれが「上流への領域染み出し」を順調に進めてくれています。単なる「作る人」から「価値を定義し、届ける人」へと、組織全体の意識が確実に変化してきているのを感じています。 「More」から見えた本質的な課題:製品貢献度確認アンケートの真意 一方で、課題(More)も明確になりました。私たちが定期的に実施している「製品貢献度確認アンケート」において、改善傾向は見られた一方で、まだ伸びしろもあります。ただ、点数以上に“定性の声”から重要な示唆が得られました。 ※このアンケートは、点数そのものを結論にするのではなく、「なぜそう感じたのか」の背景(自由記述)から論点を抽出するために活用しています。 メンバーの声を分析すると、全員が「上流工程からの参画」「一次情報の獲得(顧客や営業・CSの声)」「リリース後の効果検証」を強く求めていることがわかりました。これは「もっと手前の課題定義から関わりたい」「自分が作ったものがどう役立っているのかを知りたい」という、非常に健全で高いモチベーションの表れです。 裏を返せば、要件の解像度を早い段階で揃えきれないまま開発に入ってしまうケースがあり、協働の難易度が上がることがありました。これは個人の能力ではなく、プロセス設計で改善できる課題だと捉えています。貢献実感が得られるのは「偶発的にフィードバックが得られた時」に限られてしまっています。これは個人の能力の問題ではなく、プロセスや仕組みの問題です。メンバーが「もっと製品の成長に寄与したい」と熱望しているからこそ、このアンケート結果は組織が次に乗り越えるべき「プロセス改革」という本質的な課題を浮き彫りにしてくれました。 下期表彰:進化を体現したメンバーたち このような環境下でも、圧倒的な成果を出してくれたメンバーがいます。 2名の成果をピックアップします。 ■AI推進の体現者(シニアPdMメンバー) 一人目は、シニアPdMメンバーによる「AI推進」の圧倒的な成果です。 そのメンバーはバイブコーディング(生成AIを活用したプロトタイピング/実装支援)を活用し、「顧客価値の早期検証」と「AIによる営業DX」を見事に両立させました。自律的なプロトタイプ開発を短期間で行い、開発着手前の仮説検証(ディスカバリー)を強力に主導しました。さらに、属人化していた商談ノウハウをAIで可視化・型化し、組織全体の提案スキルを底上げする仕組みまで構築しました。 ビジネスインパクトとプロダクト成長の両面で、まさに私たちが目指すPdMの理想形を体現してくれました。 ■スピードUPの体現者(新卒入社の1年目のデザイナー) 二人目は、新卒で入社して間もないデザイナーによる「スピードUP」への多大な貢献です。 そのメンバーはリリースプロセスの効率化と自動化に果敢に取り組みました。動作確認シナリオの見直しや、並列アップデート化、監視の自動化などを推進し、結果としてマイナーリリース作業全体にかかる時間を約半分まで削減するという驚異的な成果を叩き出しました。 入社年次に関わらず、自らの視点で課題を発見し、プロセスそのものを変革する行動力は、組織全体に大きな刺激を与えてくれました。 次中期方針(変わらない軸と、目指すべき組織の姿) ここからは未来のお話です。2026年4月から2029年3月末までの次の中期方針についてです。 プロダクト部のMissionとVision 次の中期に向けてはこのようなMissionとVisionを掲げています。 Mission: 「プロダクトの機能と活用の価値創出に責任を持つ」 Vision: 「プロダクト連携とAI搭載でプロダクト価値を向上させ、売上成長に直接貢献する」 役割と責務や活動領域についてはこれまで変更はありません。 ※ The Product Management Triangle Posted by Dan Schmidt , Product Logic ラクスのプロダクト部向けにカスタマイズ 戦略ゴールのポイント 2029年3月末に向けてのゴールにおいて、具体的な数値はここでは割愛しますが、重要なポイントは以下の3点に集約されます。 プロダクト間連携の推進 :単体のシステムではなく、シリーズ全体でお客様の業務を滑らかに繋ぐ体験を提供します。具体的には二重入力や部門間の手戻りが減り、日々のオペレーションが滑らかになると考えています エンタープライズ(大口)顧客向け機能の強化 :主要サービスにおいて、より大規模で複雑な要件を持つお客様にも満足いただける機能と改善を実現します。 プロダクトへのAI搭載 :AIを特別なものではなく、当たり前の機能として各プロダクトに組み込み、お客様の業務効率を飛躍的に高めます。 ※詳細は 2026年2月13日 2026年3月期第3四半期決算説明資料 「P.42 次期中計に向けた成長戦略」 を参照ください 組織として目指すべき状態:全メンバーの上流への染み出し これらの戦略を実現するためには、組織のあり方そのものを進化させる必要があります。私たちが目指すのは、以下の状態です。 ※これもプロダクト部 組成時から掲げている ものと変わりはなし まず、 プロダクト戦略の策定と、その実行(戦術)を主導できている状態 です。これは、事業部から降りてきた要件をただ形にするのではなく、デザイナーやPdMが戦略策定の初期段階から関与し、開発組織としての専門的な知見を方針に反映させることを意味します。 次に、 製品に対する「解像度」が全社の中で最も高い状態 です。営業やCSからのまた聞きではなく、自らお客様にインタビューを行い、一次情報を獲得することで、自分の言葉で顧客の課題を言語化できる組織になります。 そして何より、 プロダクト部の全員が製品の成長に寄与していると心から実感できる状態 を作ります。定性・定量の両面から、自分の仕事がどう売上や顧客満足度に繋がったかを語れる環境を整備します。 【プロダクト部】役割/責務/活動領域と「UX志向の行動」 プロダクト部は、第一開発統括部のプロダクトマネジメントと、ラクス全体のプロダクトデザインを担うという非常に重要な役割を持っています。私たちの責務は、社内外の関係者と連携し、製品価値を創出・提供し続けることで、お客様の満足と利益を生み出す「循環」を創ることです。そのために最も重要な行動指針が「UX志向の行動」です。 これは継続して変わらない私たちのコアバリューですが、改めて強調させてください。最高のUXを提供するためには、自身の役割や立場にとらわれてはいけません。 顕在化しているニーズをファクトに基づいて把握することは当然として、市場や競合の動向、そして未来の潜在的なニーズに対しても、仮説検証を繰り返して不確実性に挑戦していく姿勢が求められます。安易なトレードオフ(二者択一)に逃げるのではなく、短期的な成果と中長期的な価値の両立(AND)を泥臭く模索し続けること。これこそが、私たちが体現すべきプロフェッショナリズムです。 2027年3月期上期 重点取り組み事項(進化を加速させるアクション) 最後に、今期(2027年3月期上期)の具体的な重点取り組みについてお話しします。 スローガン:「一言」でまとめると 今期の私たちのスタンスは、この一言に尽きます。 「『確かな手応え』と『スピード感』を持ってのプロダクト強化 〜早く価値のあるものを提供します〜」 どんなに素晴らしい戦略も、スピードが伴わなければ意味がありません。お客様が今直面している課題に対して、最速で価値を届け、かつ「それが本当に役立っているか」という確かな手応え(検証とフィードバック)を得ながら進んでいく。これが今期のテーマです。 ここで言う「スピード」は、作業を急ぐことではなく、お客様の課題仮説を置いてから価値検証までのリードタイムを短くすることです。早く届けるほど学びが増えますが、同時に品質リスクも増えます。だからこそ私たちは、検証サイクルを速めつつ、品質を落とさないための仕組み(テスト/監視/レビュー)もセットで強化します。「早い」と「確かな手応え」を両立させる。これが今期のテーマです。 組織体制の大枠 このスローガンを実現するために、組織体制もアップデートします。プロダクトマネジメント課とプロダクトデザイン課をそれぞれ複数課(1課・2課)の体制とし、専門性とアジリティを高めます。現在30名超の組織ですが、今期は体制をさらに拡充しつつ、体制が大きくなってもスピード感を失わないよう、権限委譲と各課の自律的な運営を推進していきます。 各役割で重要視する「AI×上流シフト」 今期、各役割において特に重要視し、徹底的に強化したいのが以下の2点です。 ■デザイナー:デザインガイドライン×AIで業務の中心をPdM領域へ デザイナーには、単なるUIの作成から「体験の設計者」へと完全にシフトしてもらいます。私たちの社内のデザインガイドラインとAIツール(例:Cursor/Claude等)を掛け合わせることで、UIモックアップの作成などの作業工数を劇的に削減します。そして、そこで浮いたリソースの全てを、UXリサーチ、顧客インタビュー、そしてPdM領域(課題定義や要求整理)への染み出しに投資します。AIを駆使することで、デザイナーが事業の意思決定のど真ん中に立つ組織を作ります。 ※AI活用の基本的な前提 AIの出力は“たたき台”として扱い、最終判断・対外説明は必ず人が責任を持ちます。 個人情報/顧客情報/機密情報は入力しません(必要な場合は匿名化・要約して扱います)。 仕様やリサーチの結論は、一次情報や根拠と突合してから採用します。 ■プロダクトマネージャー:PdM×AIでGTMを前提にしたディスカバリーとソリューション提案 PdMには、仕様を決めるだけでなく「どう市場に届けるか」までを担うPMM(プロダクトマーケティング)の視点を強く求めます。ここでもAIを徹底活用し、PRD(要求仕様書)の作成や仕様検討プロセスを「型化」して圧倒的なスピードアップを図ります。その上で、GTM(Go-to-Market)を前提とした仮説検証(ディスカバリー)を行い、プロダクト開発にとどまらない広範なソリューション提案でお客様の課題解決をリードしてもらいます。 ※PRD生成は「早く書くこと」自体が目的ではなく、論点の抜け漏れを減らし、仮説検証を速く回すための補助線として使います。AIの提案が置いている前提や根拠が妥当かは、必ず一定レベルの人がレビューします。 実現を目指す3つのプロダクト戦略 デザイナーとPdMが上記のようにAIを武器にして上流へとシフトし、組織としての力を最大化した上で、私たちは以下の3つの大きなプロダクト戦略の実現を目指します。 1. 「エンタープライズ(大口)領域の強化」 (企業が大きくなっても長く利用し続けてもらえるプロダクトへ) 私たちのプロダクトを導入してくださったお客様が、事業を成長させ、企業規模が大きくなったとしても「やっぱりこのシステムを使い続けたい」と思っていただける深い価値を提供します。複雑な権限設定や大規模なデータ処理など、エンタープライズならではの高い要求水準に応えるプロダクトへと進化させます。 2. 「プロダクトへのAI標準搭載及びAIからも利用されるプロダクトへ」 AIはもはや特別な機能ではなく、インフラです。ここで言う「AI」は魔法の自動化ではなく、入力補助・要約・確認などの“細かな手間”を減らして、ユーザーが本来向き合うべき業務に集中できる状態を作るための道具だと捉えています。一方で、生成AIには誤りや意図しない出力のリスクもあるため、業務影響が大きい領域ほど「人の最終確認」「権限」「監査」を前提に、段階的に適用範囲を広げていきます。 プロダクト内にAIを標準搭載し、入力補助・要約・確認など日々の“細かな手間”を減らすことで、お客様が本来向き合うべき仕事に集中できる状態を作ります。さらに将来的には、私たちのプロダクト自体が外部のAIアシスタント/AIエージェントから安全に呼び出され、業務の流れに自然に組み込まれる存在(API化・MCP化)になることも見据えています。そのために、権限管理・監査ログ・レート制限など、エンタープライズ品質のガードレールを前提に設計していきます。また、API化・MCP化は“将来的な方向性”であり、お客様のセキュリティ要件や運用実態を踏まえて検証しながら進めます。 ※MCP(Model Context Protocol)は、AIと外部データ/ツールをつなぐための共通規格の一つで、AIエージェントが外部システムを安全に呼び出すためのインターフェースを標準化する動きです 3. 「統合型ベストオブブリード戦略」 (プロダクト間連携によるお客様の便益や価値向上) 単一の優れたプロダクト(ベストオブブリード)を提供するだけでなく、それらがシームレスに連携し合う「統合された体験」を提供します。例えば、あるプロダクトで入力したデータが自動的に別のプロダクトに反映されるなど、システム間の摩擦を極限まで減らし、お客様の業務全体の生産性を飛躍的に向上させます。 おわりに プロダクト部が立ち上がってからの1年間は、ゼロから基盤を作り上げる激動の期間でした。そしてこれからの1年は、その基盤の上に「確かな手応え」と「圧倒的なスピード感」をもって、市場に大きな価値を打ち出していくフェーズになります。 私たちには優秀なデザイナーとPdMが揃っており、さらにAIという強力な武器があります。全員が上流に染み出し、顧客の一次情報に触れながら、最高のUXを追求していく。このプロセスを妥協なくやり抜くことで、日本のクラウドサービスで存在感を高められるよう、挑戦を続けていきます。今のラクスでのプロダクト開発は最高に刺激的で面白いフェーズにあります。これからのプロダクト部の挑戦に、ぜひご期待ください。 私たちと一緒に、数年後、数十年後も顧客に愛され、価値を残し続ける最高のプロダクトを作りませんか? 皆さんとお話しできる日を、心から楽しみにしています。本記事を読んで興味を持たれた方は、まずはカジュアル面談からご応募ください。 career-recruit.rakus.co.jp
2026年1月、株式会社ラクスに技術広報として入社した髙須賀(たかすか)と申します。 早いもので入社から3か月が経過しました。新年度という区切りを迎え、これまでの振り返りと、これから私たちが目指す姿についてお伝えできればと思います。 1. 自己紹介 2. ラクスの開発組織の魅力について 3. 入社後の取り組みについて ヒアリングと施策立案 顧客志向表彰の実施 ブログの執筆 社内向け記事の執筆 商談動画のまとめ その他 4. 今後の展望:発信を楽にする環境づくり 5. おわりに 1. 自己紹介 私自身はエンジニアとしての経験はありませんが、前職ではITエンジニア向けの技術イベントの企画・運営に従事していました。 当時から大切にしているのは、「ITエンジニアの皆さんと共通言語で会話ができるようにすること」です。 IPA試験の受験、技術書、社外の技術イベントへの参加などを通して技術への理解を深めてきました。 ラクスの技術広報となった今、より深く自社の技術スタックを理解する必要性を感じており、日々学習を続けています。 2. ラクスの開発組織の魅力について 技術広報の重要なミッションの一つは、自社の開発組織の魅力を外部に伝えることです。ここでは、私が実際に勤務して感じたラクスの魅力をご紹介します。 最大の特長は、徹底した顧客志向です。 ラクスではあらゆる役割のメンバーがお客様への価値提供に向けて日々業務に取り組んでいます。 開発組織は主に技術の力を使って価値を生み出しますが、ラクスでは常に「それはお客様のためになるか」を重要な判断軸に置いています。そのため、自分たちの書いたコードが企業の成長を支え、そこで働く方々を「楽」にしているという実感を強く持つことができます。 「楽楽精算」や「楽楽明細」をはじめとするサービスでお客様の業務の課題を解決し、社会の効率化に貢献したい。そんな技術の社会実装に喜びを感じるエンジニアにとって、ラクスの環境は非常に魅力的だと感じています。 3. 入社後の取り組みについて この3か月間、現状の把握と改善に向けて、社内外で様々な施策を実行してきました。 ヒアリングと施策立案 この3か月を通して数十名の社員の方にインタビューをさせていただき、現状感じている課題などをヒアリングいたしました。このインタビューやアンケートの結果をもとに、組織全体をよりよくするための戦略を立てました。 顧客志向表彰の実施 「今期、特に顧客志向を体現した事例は何か?」を開発組織の全管理職から推薦いただき、投票・表彰するイベントを実施しました。 今後も素晴らしい事例が埋もれず、組織の誇りとして可視化される仕組みを目指しています。 ブログの執筆 RAKUS AI Meetup Vol.2のレポート 社内テックカンファレンスのレポート tech-blog.rakus.co.jp 社内向け記事の執筆 開発統括部長へのインタビュー記事 他部門との情報交換会レポート3本 商談動画のまとめ 開発メンバーがお客様への理解をより深められるよう、顧客のリアルな声が分かる商談動画のアーカイブや営業資料、顧客満足度調査などを一箇所に集約・共有しました。 その他 社内交流イベント「ビアバッシュ」の企画運営、エンジニア情報ポータルサイトの更新、外部登壇の支援、社外向けアンケートや社内向けアンケートの集計・分析、生成AIを用いた業務効率化などを実施しました。 career-recruit.rakus.co.jp 4. 今後の展望:発信を楽にする環境づくり 今後は、ラクスの開発組織の強みをさらに高い解像度で整理し、一貫性のあるメッセージとして社内外へ浸透させていきます。なかでも、着実に実績が増えているAI活用の取り組みについては今後力強く発信していく予定です。 情報発信においては、エンジニアの皆さんの力が不可欠です。しかし、日々の開発業務と並行して技術発信を行うことは決して簡単ではありません。 だからこそ、アウトプットしやすい環境を整備し、組織全体の技術発信のハードルを下げ、発信活動そのものを「楽」にしていきます。 また、私自身もブログなどのオンライン施策にとどまらず、オフラインの技術イベントへの参加回数を増やし、コミュニティにおけるラクスの存在感を高めていきたいと考えています。 5. おわりに 技術広報のミッションは、単なる情報発信ではありません。 エンジニア組織の価値を最大化し、その結果として、お客様により良い価値が届くサイクルを加速させることだと思います。 これまでの知見をもとに、ラクス開発組織の魅力をしっかり届けていきます。 イベントや勉強会の会場で見かけた際は、ぜひお気軽に声をかけていただけると嬉しいです。 皆さま、これからどうぞよろしくお願いいたします!
こんにちは、プロダクト部 部長の稲垣です。(自己紹介やこれまでのキャリアについて↓をご覧ください。) tech-blog.rakus.co.jp デザイナーとプロダクトマネージャー(PdM)が同じ組織になってもうすぐ1年が経ちますので、その挑戦、苦労、変化について書こうと思います。ラクスは3月末決算のため4月には来期に向けて取り組みを書こうと思いますが本記事は厚めに振り返ります。 組織図を書き換え、デザインを解放する なぜ統合が必要だったのか:「上流×一次情報×検証」が欠けると、協働は痩せていく デザインの再定義:それは「問題を解決するための設計」である 壁を壊すだけでは足りない:一次情報・意思決定・効果検証を「仕組み」にする プロセスの磨き込みが、思考の余白を生む(AIは黒子) PdMとデザイナーの共鳴:信頼が戦略を加速させる UX志向のガードレール:越境は「自由」ではなく「責任」 リアルな壁:未経験の荒野と「固定観念」との戦い(アンケートで見えた“本質”) おわりに:各自が「+1」の越境を止めない 組織図を書き換え、デザインを解放する 「デザイナーとプロダクトマネージャー(PdM)を、同じ組織にする。」 この決断は、単なる管理上の変更ではありませんでした。 それは、プロダクト開発における「役割」という名の聖域を取り払い、全員が「ユーザー価値」という一点に向き合うための、静かな、けれど野心的な挑戦の始まりでした。 これまでのラクスの開発現場では、「仕様を作る人(PdM)」と「形にする人(デザイナー)」という分断が、あたかも効率的な分業であるかのように受け入れられてきました。 しかし、その境界線はときに、情報の劣化や責任の押し付け合いを生む「見えない壁」となって立ちはだかります。 この1年で私たちが目指したのは、デザインを「UI(見た目)を整える業務」から、「事業課題を解決するための設計・計画全般」へと解放すること。 その決断が、いかにしてプロダクトの質と、チームの魂を変えていったのか。今、私たちが感じている「統合の真の価値」を言語化してみたいと思います。 なぜ統合が必要だったのか:「上流×一次情報×検証」が欠けると、協働は痩せていく 先に結論を言うと、統合は“仲良くするため”ではありません。 プロダクト開発に必要な情報と責任が、上流から検証まで一本で繋がる状態 をつくるためでした。 私たちが日々向き合うプロダクト開発は、不確実性の塊です。だからこそ、チームが手応えを感じる瞬間は、完成した成果物そのものよりも、 不確実性が下がった 意思決定が前に進んだ 手戻りや無駄が減った リリース後の反応が見えた ……といった「前に進んだ感覚」に宿ります。 逆に言えば、一次情報に触れられず、上流での仮説設計に関われず、リリース後の効果検証も回らない状態だと、仕事は“調整と吸収”に寄り、協働は痩せていく。 これは個人の能力の問題というより、フィードバック周期が長すぎる設計のサインでした。 だから私たちは、役割の境界線を越える前に、まず 「上流×一次情報×検証」を“チームの標準装備”にする方向へ舵を切りました。 デザインの再定義:それは「問題を解決するための設計」である かつて、デザイナーの仕事の主戦場は「画面の中(UI)」でした。 しかし今、私たちの組織ではその定義が劇的に変わりつつあります。 デザインとは、ユーザーの深層にある痛みを見つけ出し、それを解決するための「設計・計画」そのものです。 この定義の変化を象徴するのが、デザイナーによる「UX領域への染み出し」です。 デザイナーが自らユーザーインタビューの場を設計し、実査を主導する。そこで得た生々しい一次情報をもとに、PdMと肩を並べて「この機能は本当にユーザーのためになるのか?」という本質的な議論を戦わせる。 デザイナーが「体験の責任者」として上流から関わることで、プロダクトの骨格は以前よりもずっと強固になりました。単に「使いやすい画面」を作るのではなく、「なぜそれを作るのか」という問いに対して、デザインの観点から明確な解を持つようになったのです。 そして何より、ここで重要なのは“美しい理想論”ではなく、 顧客価値に直結する現実 です。 インタビューで課題設定がズレていることが分かり、手戻りを未然に防げた。あるいは、現場の声を根拠に提案が通り、商談上の不安材料を消せた。そういう小さな勝利の積み重ねが、プロダクトの勝率を静かに上げていきました。 壁を壊すだけでは足りない:一次情報・意思決定・効果検証を「仕組み」にする 統合して気づいたのは、組織図を変えただけでは、人は簡単に変わらないということです。 必要なのは「気合」ではなく、 情報と責任の流れを変える仕組み だと思っています。 私たちが意識して整えているのは、大きく3つです。 1) 一次情報を“取りに行く”のを、当たり前にする 顧客・営業・CS・現場の声は、伝言ゲームを経由した瞬間に痩せていきます。だからこそ、一次情報に触れることを「一部の職種の仕事」から、「チームの呼吸」へ。デザイナーもPdMも、必要なら自分で取りに行く。その姿勢をチームの文化として育てています。 2) 上流から入る(要求の背景と検討経緯を共有する) 「要求が遅い・曖昧」を開発側が吸収して納期を守る構造は、短期的には優しい。でも長期的には、品質・士気・優先順位付けを劣化させます。そこで、要求の背景(なぜ今これが必要なのか)や検討経緯(なぜこの案を選んだのか)を、できるだけチームに残す。意思決定の“証跡”を共有する。これだけで、同じ議論を何度も繰り返す無駄が減り、腹落ちの深さが変わっていきます。 3) リリース後の効果検証を“デフォルト”にする 作って終わりにしない。 KPIの推移だけでなく、VOCや現場の反応も含めて、どんな変化が起きたのかを回収し、次の意思決定に繋げる。 ここが回り始めると、チームは「前に進んだ感覚」を取り戻し、協働の質が一段上がります。(ここはまだまだできていないことが多い) プロセスの磨き込みが、思考の余白を生む(AIは黒子) もちろん、デザイナーが上流工程に染み出すためには、これまでの業務をどこかで効率化しなければなりません。そこで私たちは、制作プロセスに工夫を凝らそうとしています。 UI制作における細かなルーチンワークや共通パーツの管理、さらにはインタビュー後の膨大な文字起こしや情報の整理といった「作業」の部分に、最新のテクノロジーやAIを黒子として組み込もうとしています。 目的は、デザイナーを「作業」から解放し、その脳を「思考」へとシフトさせることです。 この実現のために「デザインガイドライン」の策定と浸透は重要な役割を担っています。(デザインガイドラインの苦労は以下のnoteをご覧ください) note.com note.com 浮いた時間で、デザイナーはユーザーの隣に座り、感情の機微を読み取る。そして、そのインサイトを戦略へと昇華させる。技術によって生み出された「余白」が、皮肉にも私たちの開発プロセスをより人間中心(ヒューマンセンタード)なものへと変えていければよいなと思います。 PdMとデザイナーの共鳴:信頼が戦略を加速させる この体制が生んだ最大の資産は、PdMとデザイナーの間に生まれた「深い信頼の土壌」です。 デザイナーがUXの解像度を究極まで高め、現場をリードしてくれる。その確信があるからこそ、PdMは現場の細部をデザイナーに「預ける」ことができるように少しずつなってきています。 これはPdMにとって、単なるタスクの委譲ではありません。UXの重責をパートナーに託したことで、PdMは自身の専門領域である「プロダクト戦略」や「GTM(市場投入戦略)」など、事業成長に直結するマクロな動きに全神経を注げるようにするためです。 この「相互の越境」は、目に見える実績としても現れ始めています。 複数サービス利用推進の加速:デザイナーが横断組織になったことで、サービス間の垣根を超えたデザインガイドラインが浸透 コミュニケーションの高速化:別組織ゆえの「合意形成のための儀式」が消え、価値を「ツクル→伝える」までのスピードが上がった ここで大事なのは、スピードそのものではなく、スピードが生む“余白”です。余白があるから、仮説検証ができる。一次情報に触れられる。効果検証まで責任を持てる。結果として、プロダクトが「説明できる意思」を持ちはじめます。 UX志向のガードレール:越境は「自由」ではなく「責任」 一方で、越境は万能薬でもありません。 境界線を溶かすほど、意思決定が曖昧になったり、声の大きい人が勝ったりする危険もあります。だからこそ、私たちは「UX志向」を 行動原則(ガードレール) として明文化し、何度もすり合わせました。たとえば、 製品の本質的価値から逆算して行動する 事実(ファクト)に基づき、仮説検証を繰り返す 提供したUXへのフィードバックを収集し、改善に繋げる 短期と中長期をORにせず、ANDで両立する道を探す ステークホルダーに敬意を払い、説明責任を果たす そして同時に、「やらないこと」も決めます。憶測だけで決めない。フィードバックを放置しない。政治や保身を優先しない。 この“当たり前”を言語化しておくことで、越境は「自由」ではなく「責任」として機能し始めます。 リアルな壁:未経験の荒野と「固定観念」との戦い(アンケートで見えた“本質”) しかし、理想ばかりを語るわけにはいきません。現在進行形の課題も山積みです。 まず、UXを深く担った経験のあるデザイナーはまだ少数派です。UIという安全圏を抜け出し、正解のない「戦略や設計」に踏み込むのは、想像以上に怖いし、体力も要ります。 ここで半期ごとに実施している「製品貢献実感」のアンケートが、壁の正体をはっきり映しました。貢献実感が強い瞬間は、成果物そのものよりも「前に進めた感覚」——認識齟齬を潰して手戻りを減らせた、意思決定が進んだ、リリース後の反応が見えた、といった場面に集まりやすい。逆に言うと、 一次情報に触れられない/上流に入れない/効果検証まで見えない 状態が続くほど、貢献実感は痩せていきます。これは個人の能力ではなく、フィードバック周期が長い(設計されていない)ことが原因になりがちです。 さらに厄介なのが固定観念です。「デザイナー=UIを作る人」「PdM=要望を捌く人」という見え方が残ると、一次情報や検証に踏み込もうとした瞬間に、善意の期待で引き戻されます——「いいから早く画面を」「まずは間に合わせて」。 だから私たちは、気合ではなく仕組みで解くことにしました。一次情報・意思決定の背景・効果検証を“標準装備”にし、小さくても「前に進んだ証拠」が返ってくるループを短く回す。固定観念は議論で倒すより、 実績で上書き するほうが早い。未経験の荒野と戦う鍵は、個人の頑張りではなく「前進が可視化される設計」にあると感じています。 おわりに:各自が「+1」の越境を止めない 私たちが目指すのは、職能というラベルに縛られない、真のプロフェッショナル集団です。 デザイナーはより戦略的に、PdMはより体験に寄り添う。それぞれが自分の領域から「+1」の越境を続けることで、プロダクトには強い「意志」が宿ります。 組織図の壁を壊し、デザインを解放した先に見える景色。それは、作り手が誰よりもプロダクトの可能性を信じ、楽しみながら価値を生み出し続ける、そんな組織の姿です。私たちの挑戦は、まだ始まったばかりです。 記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー/PdM の方 は、ぜひカジュアル面談からご応募ください。 ※プロダクトマネージャーのカジュアル面談は、基本的に私(稲垣)が担当します! ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー https://career-recruit.rakus.co.jp/engineer_jobs/uidesigner_tokyo/ career-recruit.rakus.co.jp
こんにちは、ラクスの技術広報です。 2026年2月20日(金)、ラクスの社内テックカンファレンス「Rakus Tech Conference for Us 2026」 を開催いたしました。 組織が拡大し、それぞれのプロダクトや職種の専門性が高まる中で、いかに「横の繋がり」を強め、新たな価値を生み出すか。熱気に包まれた当日の様子をレポートします。 開催の背景とテーマ:『Synergies』(シナジー) 多彩な8セッション:技術の先にある「協働」を語る 発表内容 【セッションラインナップ】 イベント後に寄せられた感想(抜粋) アフターイベント:東京・大阪の2拠点で同時開催 開催を終えて 開催の背景とテーマ:『Synergies』(シナジー) 今年のカンファレンスのテーマは 『Synergies』(シナジー) 。 コンセプトとして 「境界を越え、相乗効果を生み出す」 を掲げました。 現在、ラクスでは『楽楽精算』や『楽楽明細』をはじめとする数多くのプロダクトを展開しています。事業の拡大に伴い、多様な技術スタックや専門知が組織内に着実に蓄積されているという手応えがある一方、組織が大きくなるにつれ、隣のチームの知見が届きにくくなるリスクも大きくなっていました。 そこで、エンジニア、PdM、デザイナー、SRE、QAといった職種の壁、そしてプロダクトの壁を越えて進められた 実プロジェクトの成果や知見を共有し、 互いの強みを知り、頼り合える関係性をさらに広げる場として、本カンファレンスを企画しました。 多彩な8セッション:技術の先にある「協働」を語る 本編では、合計8つのプロダクトチームから登壇者が集結しました。 今回の発表基準は、単なる技術解説に留まらず、 「Context & Collaboration(背景と連携)」 に焦点を当てることです。 発表内容 今回のテーマである職種の壁を越えたシナジーを軸に、顧客志向、スピードアップを体現した素晴らしい事例が共有されました! どのセッションも、「自分たちの業務にも活かせそう!」「あのチームのあの人に後で詳しく聞きに行こう」と思わせる、実践的な知見が詰まった内容でした。 さらに、今回は「AIネイティブ」な開発姿勢を象徴する事例も数多く共有されました。 AIツールを前提とした開発フローの最適化や、プロダクトへのAI組み込みにおける試行錯誤など、AIをエンジニアの強力なパートナーとして使いこなすための具体的なナレッジが飛び交っていたのが非常に印象的でした。 【セッションラインナップ】 ※公開にあたり、一部タイトルを調整しています。 ウォーターフォール開発からアジャイル開発へ~○○案件の知見共有 「1機能」から変える。○○が○○を呼び起こす「○○」の始まり 「楽楽債権管理」開発スピードUPのために、○○と○○を変えてみた 「楽楽販売」 ○○プロジェクト:デザイナーと開発者の協業モデル 「楽楽明細」○○機能開発 挑戦と学びの記録 「楽楽請求」への○○導入の裏側 〜SREチームが支える社内プラットフォーム〜 「阿吽の呼吸」をアップデートせよ。10人の壁を越え、チーム全員で「○○」を共有する挑戦 ○○を振り切る。社内資産を活かして辿り着いた、最速の新機能開発 イベント後に寄せられた感想(抜粋) 他のプロダクト開発チームが直面している課題やその解決の取り組みについて、生々しい情報を解像度高く得られ、大変有意義でした。 担当中のプロジェクトの課題に対して、解決策のヒントを得ることができました。 同じような悩みを抱えてるなという部分と、商材が変わるとそんな苦労があるのか!という発見があった 既存の枠組みに囚われないチャレンジの重要性を認識した。 アフターイベント:東京・大阪の2拠点で同時開催 カンファレンス終了後は東京拠点と大阪拠点でビデオ会議でつないでアフターパーティを開催! 「Ask the Speaker」 ブースでは、登壇者を囲んでさらに深い技術議論や裏話が交わされ、耳までチーズが入ったピザやビールを片手に部署を越えた交流が夜まで続きました。 開催を終えて ラクスでは、こうした社内交流を通じて、個々の技術力だけでなく、組織としての解決力を高める文化を大切にしています。 今回の『Synergies』で生まれた繋がりが、より高速で高品質な価値をお客様に届けるためのエンジンとなり、今後のプロダクト開発において大きな相乗効果を生み出すことを確信しています。
目次 目次 0. はじめに 1. レビューされる側だった頃の問題点 2. レビューと設計の関係性 2.1 なぜレビューが必要なのか 2.2 なぜ「設計」が関係するのか 3. コードレビュー指摘の傾向から学んだこと 3.1. 様々な設計原則 3.2. 設計指摘を具体的に理解する 3.3. 設計指摘をものにするためには? 4. before / after で見る設計指摘の具体例 4.1. SRP: 「責務が多い」と言われたケース before: 1つのクラスに複数の責務がある after: 責務ごとに分離する 4.2. OCP: 「将来増えそう」と言われたケース before: 条件分岐で処理を切り替えている after: 振る舞いを分離する 4.3. DRY: 「共通化できそう」と言われたケース before: 同じコードが複数箇所にある after 其ノ壱: 知識を一箇所に集約 after 其ノ弐: 処理を一箇所に集約 4.4. before / after から学んだこと 5. 実装時に持つべき視点 6. 同じ立場の人たちへ 7. まとめ 0. はじめに はじめまして。新卒一年目の楽楽販売開発エンジニアです。 ほとんど開発経験がない状態で入社し、数ヶ月の研修を経て実務に入りましたが、最初はコードレビューで受けた指摘の意図や直し方が分からず戸惑うことばかりでした。 例えば、コードレビューでこんな指摘を受けたことはないでしょうか。 「このクラス、責務が多くないですか?」 「将来 if が増えそうですね」 「共通の処理が他にもあります」 私はまさにこのようなコードの設計に関する指摘をたくさん受けてきました。 ただ当時は「これらはなぜ必要なのか?結局どう直せばいいのか?」と思っていました。 私が書いたコードは要件通りに動くし、これらの指摘はどこか抽象的で、実装とどう結びついているのかが分からなかったからです。 それでもレビューで指摘を受けては実装を直し、学習を重ねるうちに、次第に なぜその指摘が出てくるのか どこを直せばよいのか が、以前よりもはっきりしてきました。そこから実装やレビューの時に意識するべきポイントを見出すことができました。 この記事ではコード設計に関する指摘に焦点を当て、これまでの私の変化と学びを元に 実装やレビューの時に気をつけると良いこと について述べます。 ここで紹介されるポイントを理解し実践することで、実装やレビューの質を上げていってほしいです。 コーディング経験が浅い人やこれからレビューを受ける人、これからレビューを始める人の参考になれば嬉しいです。 1. レビューされる側だった頃の問題点 最初の頃の私は、個人でコードを書いている感覚のまま、チーム開発をしていました。 とりあえず要件を満たして動けばOK 保守性・可読性は「なんとなく」意識する程度 それに加えて重要な設計原則を知らず、気にしていなかったです。 このような状態だったので、レビューで多くの指摘を受けていました。 今だからこそ言えることですが、以下のような具体的な観点を実装時に持っていなかったことが原因の1つでした。 どこまでを1つの責務と考えるのか 将来どんな変更が入りそうか 他の人が読んだときに意図が伝わるか いつも一貫した考えのもとで実装をしていなかったため、「指摘されてはその場で修正する」の繰り返しでした。 つまり、 再現性のある判断基準を持てていなかった のです。 なお、上記のような観点の詳細やその重要性については 3 節以降で述べます。 2. レビューと設計の関係性 2.1 なぜレビューが必要なのか ここで「レビューの必要性」について少し述べておきます。当初の私は、「レビューはバグを見つけるためのもの」だと考えていましたが、実際は違いました。 一般に、バグを見つけるのはテストでできるからこそ、中長期的な品質や保守性を担保するためにレビューを行います。 チーム開発には、 自分以外の人がコードを読む 複数人で継続的に機能追加や修正を行う という特徴があるため、できるだけ早い段階で複雑さが増えにくい形にコードを整えておくことが重要になります。 これを実現するためにレビューが必要なのです。 つまりレビューは、 「今の正しさ」だけでなく「将来も扱いやすいか」 を確認するためにあると言えます。 また、結果としてそれは お客様に価値を早く、継続的に届けるための投資 になります。 2.2 なぜ「設計」が関係するのか レビューが「将来の扱いやすさ」を見る場だとすると、「では、その扱いやすさは何で決まるのか?」と疑問に感じるでしょう。 そこで出てくるのが「コード設計」です。 責務の分け方 変更理由の整理 依存関係の持ち方 etc. レビューでコード設計の話が出てくるのは、それが中長期的な保守性を大きく左右するからです。 3. コードレビュー指摘の傾向から学んだこと ここではレビューで多かった指摘を振り返り、設計原則との関係を見ていきます。 また「コード設計に関する指摘」をもう少し具体的にします。 当時よくもらっていたのは、例えば次のような指摘です。 責務が多い 同じような処理が増えていきそう 同じような処理が他にもある 変更時の影響範囲が広そう これらを別々の指摘として受け取っていた当初は、「なぜ指摘されるのか」「どうすれば指摘されなくなるか」を根本から理解できていませんでした。 後から整理すると、表現は違えど、これらはどれも 将来の変更に弱い ことを指摘していました。 これがまさに将来の扱いやすさに言及する「コード設計に関する指摘」(以降「設計指摘」)だったのです。 したがって、設計指摘とは「将来困りそうか?」を様々な観点から判断してなされる指摘だと言えます。 3.1. 様々な設計原則 設計指摘を具体的に理解するために、まずは私が受けた設計指摘に大いに関係していた設計原則を3つ紹介します。 SRP(Single Responsibility Principle: 単一責任原則) 1つのクラスやメソッドには1つの責務のみを与えるべし OCP(Open-Closed Principle: 開放閉鎖原則) 既存コードの修正なしで拡張可能にするべし DRY(Don't Repeat Yourself) 重複を排除するべし 設計原則はどれも、将来の変更に対して壊れにくく、修正しやすく、ミスが入りにくい構造をあらかじめ作るための考え方です。 つまり、レビュワーが考えることはまさに設計原則そのものなのです。 それゆえ、レビューでは設計原則に基づいた指摘、すなわち設計指摘が頻出します。 3.2. 設計指摘を具体的に理解する 設計原則を知るともらった指摘の根底にある考えが分かるので、それらをより具体的に理解できます。 例えば、 「責務が多い」 → SRP の観点で、変更理由が増えそう 「同じような処理が増えそう」 → OCP / DRY の観点で、修正漏れが起きそう 「影響範囲が広い」 → 依存関係が整理されておらず、防御しにくい。あるいは DRY を守れていない こうして、当時は抽象的に思えた指摘をやや具体的に理解することができました。 3.3. 設計指摘をものにするためには? 設計指摘の根底にある考えは「このままでは将来が不安である」というものでした。 これだと抽象的に思えますが、実はある程度定まった基準が存在しており、それが設計原則でした。 設計原則を知り、実際のコードに応用できるようになれば、設計指摘で悩むことはなくなると思っています。 そういうわけで、次節では設計指摘を受けるコードとはどんなものなのかを見ていきます。 設計指摘を受ける理由やどのように直せば良いのかをまとめ、更に理解を進めます。 4. before / after で見る設計指摘の具体例 ここまで読めば、設計指摘の意味やその根底にある考えが分かってきたと思います。 4 節ではサンプルコードを用いて、実際にどんなコードがどんな理由で指摘され、どう直すべきなのかを before / after の形で見ていきます。 4.1. SRP: 「責務が多い」と言われたケース まずは SRP(単一責任原則) の例です。 当時の私は以下のように、1つのクラスで色々な処理をしようとしていました。 before: 1つのクラスに複数の責務がある public class UserService { public void register(User user) { validate(user); save(user); sendNotification(user); } private void validate(User user) { // 入力チェック } private void save(User user) { // データベースに保存 } private void sendNotification(User user) { // 通知メール送信 } } このコードの問題点は、「ユーザー登録」というユースケースの中に、複数の責務が押し込まれていることです。 以下のような別々の変更理由によって、コードの同じ箇所が変更される可能性があります。 入力チェックの仕様が変わる データベースへの保存方法が変わる 通知手段が増える / 変わる after: 責務ごとに分離する public class UserService { private final UserValidator validator; private final UserRepository repository; private final NotificationService notificationService; public void register(User user) { validator.validate(user); repository.save(user); notificationService.notify(user); } } 処理の流れ自体は変わっていませんが、 入力チェック データベースへの保存 通知 が、それぞれ独立した責務として切り出されています。 この変更によって、 仕様変更時の影響範囲が限定される テストしやすくなる 実装意図が読み取りやすくなる といった効果があります。 「責務が多い」という SRP に基づく指摘は、 将来の変更理由が1箇所に集まりすぎている 、すなわち 一人で色々やりすぎ という意味であると理解できます。 4.2. OCP: 「将来増えそう」と言われたケース 次は OCP(開放閉鎖原則)の例です。当時は以下のように、分岐を増やして処理を追加していました。 before: 条件分岐で処理を切り替えている public class PriceCalculator { public int calculate(Order order) { if (order.getType() == OrderType.NORMAL) { return order.getBasePrice(); } else if (order.getType() == OrderType.DISCOUNT) { return order.getBasePrice() * 9 / 10 ; } else if (order.getType() == OrderType.SPECIAL) { return order.getBasePrice() * 8 / 10 ; } throw new IllegalArgumentException(); } } このようなコードは「将来 if が増えそうですね」などと指摘を受けるでしょう。 そして当時の私なら「今はこれで動くし十分では?」と思ったに違いありません。 このコードの問題点は、 注文種別が増えるたびに if が増える 修正のたびにこのクラスを触る必要がある 変更漏れのリスクが高くなる 「今動くかどうか」ではなく「将来どうなり得るか」が問題です。 そもそも設計指摘とはそういうものでした。 after: 振る舞いを分離する public interface PriceStrategy { int calculate(Order order); } public class NormalPriceStrategy implements PriceStrategy { public int calculate(Order order) { return order.getBasePrice(); } } public class DiscountPriceStrategy implements PriceStrategy { public int calculate(Order order) { return order.getBasePrice() * 9 / 10 ; } } public class PriceCalculator { private final PriceStrategy strategy; public int calculate(Order order) { return strategy.calculate(order); } } この形にすると、 新しい価格計算ルールを追加しても既存コードをほぼ触らない 条件分岐が増えない 振る舞いごとに責務が分かれる という状態になります。 「将来増えそう」という OCP に基づく指摘は、将来変更が入る時にコードがどう修正されるかを見ていたのだと分かりました。 変更する時に既存のコードは変更せず、新たにコードを追加するだけで対応できるようにするべきである という OCP の意味が理解できました。 4.3. DRY: 「共通化できそう」と言われたケース 次は DRY の例です。当時は以下のように、コードの複数箇所に同じことを書いていました。 なお DRY には "知識" と "処理" に注目する2パターンがあるので、それぞれ紹介します。 before: 同じコードが複数箇所にある public class OrderService { public int calculateTotal(Order order) { int subtotal = order.getSubtotal(); int tax = subtotal * 10 / 100 ; return subtotal + tax; } public int calculateRefund(Order order) { int subtotal = order.getSubtotal(); int tax = subtotal * 10 / 100 ; return subtotal - tax; } } このコードの問題点を "知識" に注目して挙げると、 税率10%という "知識" が二箇所に書かれている 税率変更時に両方修正が必要 これにより修正漏れのリスクが高くなっています。 after 其ノ壱: 知識を一箇所に集約 public class TaxCalculator { private static final int TAX_RATE = 10 ; public static int calculate( int amount) { return amount * TAX_RATE / 100 ; } } public class OrderService { public int calculateTotal(Order order) { int subtotal = order.getSubtotal(); return subtotal + TaxCalculator.calculate(subtotal); } public int calculateRefund(Order order) { int subtotal = order.getSubtotal(); return subtotal - TaxCalculator.calculate(subtotal); } } こうすれば、例えば税率を8%に変える時、 TaxCalculator の冒頭一箇所のみを修正すれば済みます。 元のコードに比べて修正漏れのリスクが低くなっています。 一方で元のコードの問題点を "処理" に注目して挙げると、 税金計算ロジックが二箇所に書かれている 変更時に両方修正が必要 これらを解決するには、"知識" の場合にならって "処理" を一箇所にまとめれば良いです。 after 其ノ弐: 処理を一箇所に集約 public class OrderService { public int calculateTotal(Order order) { int tax = calculateTax(order.getSubtotal()); return order.getSubtotal() + tax; } public int calculateRefund(Order order) { int tax = calculateTax(order.getSubtotal()); return order.getSubtotal() - tax; } private int calculateTax( int subtotal) { return subtotal * 10 / 100 ; } } 重複していた税計算処理が一箇所のみになるので、この場合も元のコードに比べて修正漏れのリスクが低くなります。 DRY 原則を守るとは、 同じコードをまとめ、修正箇所を減らす ことだと分かりました。 4.4. before / after から学んだこと これらの例から、設計指摘を受けるコードの特徴や改善方法がイメージできたと思います。 またコードの問題点を before / after を通して見ることで、設計が、2 節で述べた「中長期的な保守性」に大きな影響を与えることも分かったと思います。 このような経験から、私は設計指摘が出てしまう原因には実装者とレビュワーの視点の違いがあると考えています。 実装者としては、 仕様を満たしているか テストが通っているか に目が行きがちです。 実際、before のコードはどれも「今の要件」だけを見れば問題ありません。 一方レビュワーは、 機能追加や仕様変更 別の人が触る未来 を考えています。設計指摘はこれらを事前に想像したうえで出されていました。 この視点の違いこそ、レビューで指摘が出る理由です。 それゆえ実装時には 1.2 節で述べたような観点を持つことが重要なのだと思います。 5. 実装時に持つべき視点 設計指摘の意味が分かると、以前とは異なり、実装時点でレビュー視点を持てるようになりました。 実装中に自然と次のような問いを立てるようになりました。 このクラスは、何のために存在しているのか 変更理由は1つに収まっているか 将来どんな仕様変更が入りそうか そのときどこを直すことになりそうか これらは全てこれまでレビューで指摘されてきたポイントであり、別の言い方をすれば、設計原則が言おうとしていることでした。 その結果、レビューで指摘されそうな点に早い段階で気づけるようになりました。 こうして実装時に色々な観点を持てるようになりました。 自分の実装の良し悪しを常に同じ判断基準で考えることができるので、実装のたびにブレることが少なくなったと思います。 もしレビューで設計指摘を受けたときは、これらの観点で一度コードを見直してみてください。 「今動くか」ではなく「将来どう変わるか」を考えるだけで、見えるものが大きく変わると思います。 また、最近から私はレビューする側にも回っています。 レビューされる側として多くの指摘を受けてきた経験は、レビューをする時でも大いに役立っていると感じます。 自分なりに着眼点を持ち、「今の実装が動くかどうか」だけでなく、将来のことを考えてレビューをしています。 6. 同じ立場の人たちへ 実装時あるいはレビュー時に、本記事で挙げたような観点を持っているのといないのでは差があります。 おさらいすると、 クラスや関数の責務は1つか 将来どんな変更が入りそうか そのときどこを直すことになりそうか 修正する箇所は少ないか 他の人が読んだときに意図が伝わるか などであり、重要なのは、これらはどれも「今」ではなく「将来」を見ているということです。 常に同じ判断基準を持ち、経験とともにそれを磨き、増やしていけば、実装やレビューの質は確実に上がると思っています。 7. まとめ この記事では、 なぜレビューやコード設計が重要なのか 抽象的に思える設計指摘の意味や直し方 を、私自身の変化を軸に整理してきました。 コード設計が中長期的な保守性に大きな影響を与えるので、 将来の変更に耐えられるか という視点から設計指摘がなされるのでした。 そして具体的なコードを見て設計への理解をより深め、実装やレビューの時に持つと良い視点としてまとめることができました。 レビューで設計指摘を受けている人やこれからレビューを始める人にはぜひ意識してもらいたいです。 この記事がそのような人の助けになれば嬉しいです。
こんにちは、プロダクト部 部長の稲垣です。(自己紹介やこれまでのキャリアについて↓をご覧ください。) tech-blog.rakus.co.jp お客様を知らないといけないので、「もっと深く考えて」と言われた瞬間に、急に手が止まることがあります。 フレームワークや知識は増えているのに、いざ実務だと「機能の足し算」しか出てこない——。 これ、能力の問題というより “鍛え方の種類” の問題だと思っています。 今日提案したいのは、名作を使った超シンプルな思考トレーニングです。 同じ作品を「読む→聴く→観る」の3回、メディア違いで摂取する。 それだけで、ユーザー理解に必要な「論理/情緒/直感」を行き来できるようになります。 この記事で得られること なぜ「同じ作品を3回」なのか 実践:3メディア分解(所要:合計2〜4時間) 1回目:読む(活字)—「構造」を立ち上げる 2回目:聴く(音声)—「温度」を拾う 3回目:観る(映像)—「引き算」を学ぶ 深掘り:強いプロダクトは「80%で止める」 余白設計のコツ このトレーニングを「ユーザー理解」に接続するコツ(仕事への落とし込み) もう一段伸ばす:あえて「アウェイ」に行く AIで“振り返り”を加速する(※安全に) 結び:日常のすべては、思考の実験場 参考:このトレーニングをする時のおすすめ作品 海外の作品 日本の作品 この記事で得られること ユーザーが 言語化できる情報 と 言語化できない感情 を分けて捉えるコツ 画面を「足す」よりも、価値を「残す」ための 引き算の設計 思考が詰まった時に、発想を動かす 具体的な手順 なぜ「同じ作品を3回」なのか 脳はラクをしたがるので、つい “慣れた窓” から世界を見ます。 ビジネス書ばかり読んでいると、何でもビジネスロジックの窓で解釈してしまう。 すると、ユーザーの温度感や迷い、言葉にならない「違和感」を取りこぼしやすくなります。 そこで効くのが、 同一題材のメディア切り替え です。 同じ物語でも、活字・音・映像で、脳に届く情報の種類が変わる。 =思考の筋肉を、強制的に“別の角度”から使えるようになります。 実践:3メディア分解(所要:合計2〜4時間) 題材は何でもOKですが、最初はメディア展開が豊富な作品がやりやすいです(例:『 星の王子さま 』)。 ※作品名・サービス名はあくまで例です。特定の企業やサービスを推奨する意図はありません。入手しやすい方法(紙・電子・図書館・音声・配信など)でOKです。 1回目:読む(活字)—「構造」を立ち上げる 狙い:論理構築力/情報設計(IA)寄りの筋肉 読みながら、次のメモだけ取ります(全部書かなくてOK)。 登場人物(または要素)の関係は? 物語の転換点はどこ? “作者が言ってないこと”は何?(空白はどこ?) ここでやっているのは、文章から「骨格」を立てる練習です。 プロダクトで言えば、ユーザー行動の前後関係や、要件の構造化に近い。 2回目:聴く(音声)—「温度」を拾う 狙い:共感/リズム感/体験設計(UX)寄りの筋肉 オーディオブックや朗読、ラジオドラマなどで聴きます。 ポイントは「意味」ではなく「揺れ」を拾うこと。 どこで声が強くなる? どこで間が空く? 自分の感情が動いたのはどの場面? “言葉にできない”けど残った余韻は? ユーザーインタビューでも、言葉より 間・言い淀み・声のトーン に価値が乗ることがあります。 聴く練習は、そこを拾う感度を上げます。 3回目:観る(映像)—「引き算」を学ぶ 狙い:直感/審美眼/表現の取捨選択(UI)寄りの筋肉 映像は情報量が多いぶん、作り手の“選択”が見えます。 何を見せ、何を見せなかった? 1秒で伝えるために、何を捨てた? 「正解」を提示しすぎていない? ここで得たいのは、 足し算ではなく“残し方” の感覚です。 深掘り:強いプロダクトは「80%で止める」 私も経験が浅い頃ほど、不安から「全部説明したくなる」瞬間がありました。でも、体験が強いプロダクトほど、実は 余白 があります。 余白設計のコツ 説明を 80%で止める 残り20%を、ユーザーが「自分の言葉/自分の意味」で埋められるようにする ユーザーが“自分でわかった”瞬間、プロダクトは「誰かのもの」から「自分のもの」になります。 この手触りが、継続利用や愛着(ブランド)につながります。 このトレーニングを「ユーザー理解」に接続するコツ(仕事への落とし込み) 3回やったら、最後にメモを1枚にまとめて、次の3つだけ作ります。 ユーザーの“言語化された要望”(読むで拾った骨格) ユーザーの“温度・揺れ”(聴くで拾った違和感) 体験としての“残し方”(観るで見えた取捨選択) そして、プロダクト改善の形に変換します。 「ユーザーは何に迷っている?(迷いの正体)」 「その迷いを減らす“最初の一歩”は何?(オンボーディングの1手目)」 「説明を増やす代わりに、何を消せる?(余白設計)」 この3つが揃うと、「機能の足し算」ではなく 価値の設計 に思考が寄ります。 もう一段伸ばす:あえて「アウェイ」に行く 3メディア分解に慣れたら、次は 自分が避けがちなジャンルで同じ実験をします。違和感が強いほど、思考の回路が増えます。 ロジック派なら:感情や熱量が主役の作品(例:『火花』) リアリストなら:抽象度が高い作品(例:『銀河鉄道の夜』) AIで“振り返り”を加速する(※安全に) AIは答えを出す道具というより、思考の壁打ち相手にすると効きます。 各回のあと、メモを短く貼って以下を聞くだけでもOKです。 「この作品の論点を3つに要約して。根拠になった描写も添えて」 「反対意見(別解釈)を2つ出して」 「プロダクト改善に置き換えるなら、どんな仮説と検証案になる?」 結び:日常のすべては、思考の実験場 「思考力が弱い」と落ち込む必要はありません。 鍛え方を少し変えるだけで、視点はちゃんと増えます。 まずは手元の作品を、これまでと違うメディアで1回だけ。思考のOSは、そこから静かに更新され始めます。 参考:このトレーニングをする時のおすすめ作品 ※「音声化/映像化されているとやりやすい」という観点の例です(特定サービス推奨ではありません)。 海外の作品 『ハリー・ポッターと賢者の石』(J.K.ローリング)— Audibleあり/映画化(2001) 『指輪物語 旅の仲間』(J.R.R.トールキン)— Audibleあり/映画化(2001) 『アルジャーノンに花束を』(ダニエル・キイス)— Audibleあり/映画化『まごころを君に』(1968) 『三体』(劉慈欣)— Audibleあり/Netflixドラマ化(2024) 『ダ・ヴィンチ・コード(上)』(ダン・ブラウン)— Audibleあり/映画化(2006) 『そして誰もいなくなった』(アガサ・クリスティ)— Audibleあり/ドラマ化(2015) 『サピエンス全史(上)』(ユヴァル・ノア・ハラリ)— Audibleあり/ドキュメンタリー化(制作進行中) 日本の作品 『こころ』(夏目漱石)— Audibleあり/映画化(1955) 『人間失格』(太宰治)— Audibleあり/映画化(2010) 『雪国』(川端康成)— Audibleあり/映画化(1957) 『沈黙』(遠藤周作)— Audibleあり/映画化『沈黙 -サイレンス-』(2016) 『銀河鉄道の夜』(宮沢賢治)— Audibleあり/映画化(1985) 『ノルウェイの森(上)』(村上春樹)— Audibleあり/映画化(2010) 『白夜行』(東野圭吾)— Audibleあり/映画化(2011) 『告白』(湊かなえ)— Audibleあり/映画化(2010) 『嫌われる勇気』(岸見一郎、古賀史健)— Audibleあり/ドラマ化(2017) 『火花』(又吉直樹)— Audibleあり/Netflixドラマ化(2016) 『屍人荘の殺人』(今村昌弘)— Audibleあり/映画化(2019) 『かがみの孤城』(辻村深月)— Audibleあり/アニメ映画化(2022) 記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー/PdM の方 は、ぜひカジュアル面談からご応募ください。 ※プロダクトマネージャーのカジュアル面談は、基本的に私(稲垣)が担当します! ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー https://career-recruit.rakus.co.jp/engineer_jobs/uidesigner_tokyo/ career-recruit.rakus.co.jp
こんにちは、プロダクト部 部長の稲垣です。(自己紹介やこれまでのキャリアについて↓をご覧ください。) tech-blog.rakus.co.jp マネージャーの役割を一言で言うなら、私は「管理」ではなく “支援” だと思っています。 現場の専門性を信じ、意思決定の質を上げ、チームが成果を出しやすい状態をつくること。 この記事では、そのために私が意識している2つの視点を紹介します。 コト(成果・意思決定)には解像度を上げる支援 人(成長・キャリア)には未来を描く支援 ※前提として、最適な距離感はチームの成熟度・状況・業務特性で変わります。ここでは「私の経験ではこうすると機能しやすかった」という一例として読んでください うまくいっている“ように見えた”チームで、手戻りが起きた話 コトの解像度を上げる=「詰める」ではなく「迷いを減らす」 1) “目的” をそろえる支援(何のためにやるのか) 2) “事実” を共有しやすくする支援(いま何が起きているのか) 3) “意思決定” を軽くする支援(決めるのが怖くない状態) 「現場を分かれ」ではなく「現場が強くなる」ための関わり方 人には「未来」を:日々のフィードバックを“支援”に変える 未来が共有できると、指摘が「評価」ではなく「投資」になる 情報の流れを整える:支援が届きやすいチームにする AIで解像度を上げる(ただし守るべきものは守る) まとめ:解像度は、現場への敬意を形にする手段 うまくいっている“ように見えた”チームで、手戻りが起きた話 以前、関係性が良く、議論も穏やかで、進捗も「順調」と共有されているチームを見て、私は安心していました。 「信じて任せよう。口を挟みすぎないようにしよう」と。ただ、あるタイミングで出来上がったものを見て、違和感が残りました。 仕様は満たしている。でも「なぜこの形なのか」の説明が弱い トレードオフが曖昧で、「誰の課題をどう解いたか」が語れない 結果として、手戻りの議論が後ろ倒しになる 原因は、メンバーの能力不足ではありませんでした。 “支援の仕組み” が足りていなかったのだと思います。 私は、任せることに意識が向きすぎて、 「何を事実として見て、どこで意思決定し、何を残すか」という “解像度を上げる支援” を設計できていませんでした。 そこから考え方を変えました。 現場を疑うのではなく、現場が強くなるために “解像度を上げる支援” をする。 その支援があると、任せることがむしろ加速します。 コトの解像度を上げる=「詰める」ではなく「迷いを減らす」 解像度を上げるというと、「細かく口を出す」「監視する」と誤解されがちです。 私がやりたいのは真逆で、 チームの迷い・手戻り・不毛な摩擦を減らす ことです。 そのために、私がよく使うのは次の3つの支援です。 1) “目的” をそろえる支援(何のためにやるのか) プロダクト開発では、判断が割れた時に「どっちが正しいか」になりがちです。 でも本質は「目的に照らすとどっちが良いか」です。 だから私は、最初にここを揃える支援をします。 今回の変更で、ユーザーの何が楽になる?(誰のどんな負担が減る?) それを “良くなった” と判断する指標は何?(完了率、離脱、問い合わせ等) 今回は “何をやらない” と決める?(守る範囲を明確にする) 目的が揃うと、現場の議論は速くなり、任せやすくなります。 2) “事実” を共有しやすくする支援(いま何が起きているのか) 「順調です」という共有自体は悪くありません。 ただ、意思決定を強くするには、順調の“根拠”が必要です。 ここでも私は「見せてください」ではなく、 “一緒に見よう” のスタンスを取ります。 今回の仮説を裏付けるログや数値はどれ? 逆の可能性(失敗パターン)を疑うなら、何を見れば早く気づける? 定量だけで見えないなら、ユーザーの声・問い合わせ・営業/CSの肌感も合わせてみよう ポイントは、現場の専門性を奪わないことです。 私は答えを決めにいくのではなく、 判断材料が揃う状態をつくる ことに集中します。 3) “意思決定” を軽くする支援(決めるのが怖くない状態) 現場が抱えがちなストレスは、「決めたあとに責められること」だったりします。 ここを放置すると、合意形成が過剰に重くなり、前に進まなくなります。 だから私は、意思決定の仕組みをできるだけシンプルにします。 決める人(Decision owner)を明確にする 迷ったときの判断軸(優先順位)を先に置く 決めた理由を短く残す(後で責めるためではなく、学ぶため) こういう “支援の設計” があると、現場は安心して攻められるようになります。 「現場を分かれ」ではなく「現場が強くなる」ための関わり方 ここまでの話は、現場の仕事に介入したいからではありません。 むしろ逆で、 現場が自分たちで決めて進められる状態を増やしたい からです。 私が自戒しているのは次の2つです。 マネージャーが「正解」を持っている前提で話さない 現場の専門性に敬意を払い、判断に必要な材料を揃える側に回る 解像度を上げる支援は、現場を縛るためではなく、現場の裁量を増やすためにあります。 人には「未来」を:日々のフィードバックを“支援”に変える コトの解像度だけを上げると、どうしても「厳しい人」に見えやすいです。 だから私は、必ず “人の未来” とセットで扱うようにしています。 月1回、進捗ではなく「未来の話だけ」をする 私は、業務の進捗とは別に、月に1回はキャリアの話だけをする時間を取ります。 ここでは「今のタスクが遅い/早い」みたいな話はしません。 代わりに、次の3つをゆっくり話します。 いま気になっていること(興味・違和感でもOK) できるようになりたいこと(3ヶ月〜1年くらいの距離感でもOK) そのために、次に経験したいこと(挑戦したい役割・場面) 未来は固定しません。変わっていい。 ただ、言語化の回数が増えるほど、本人も周囲も支援しやすくなります。 未来が共有できると、指摘が「評価」ではなく「投資」になる たとえば設計の議論で深掘りする時も、 「詰める」ではなく「あなたの未来にとって重要だから一緒に考えたい」という形に変わります。 将来こういう領域をやりたいなら、今この視点は武器になる そのために、この判断のトレードオフを言語化してみよう 私も責任を持って一緒に腹落ちさせたい こうなると、コトの解像度を上げる関わりは、監視ではなく 伴走 に近づきます。 情報の流れを整える:支援が届きやすいチームにする 最後に、やり方の話です。 支援のつもりでも、マネージャーが“都度呼び出す”形だと、結局重たくなります。 だから私は、情報の流れをこう整えるようにしています。 「私への報告」ではなく「チームに共有」する(事実が溜まる場所を作る) 早めに共有すると得をする(手戻りが減る/調整が早い/判断が速い)体験を作る 報告を義務にしない。 支援が早く届く “仕組み” として設計する。これだけで、現場のストレスはかなり減ります。 AIで解像度を上げる(ただし守るべきものは守る) 最近はAIで、情報整理のコストを下げられるようになりました。たとえば、 議事録や議論ログの要約(論点・未決・次アクション) 問い合わせ/不具合の一次分類(まず「何が起きているか」を掴む) 判断材料の洗い出し(見るべきログ・指標候補の列挙) 一方で、個人情報やセンシティブな情報は扱いに注意が必要です。 AIを使う場合は、社内ルールに沿った範囲で、秘匿情報を投入しない前提で運用します。 まとめ:解像度は、現場への敬意を形にする手段 コトには、迷いを減らすために解像度を上げる支援をする 人には、未来を言語化して支援が届く状態をつくる この2つが揃うと、マネージャーの関わりは「管理」ではなく「支援」になります。 現場の専門性を信じることと、解像度を上げることは両立できます。 むしろ、支援の設計があるほど、現場はより自由に、より強く動けるようになります。 また、記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー/PdMの方 は、ぜひカジュアル面談からご応募ください。 ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー career-recruit.rakus.co.jp
こんにちは、プロダクト部 部長の稲垣です。(自己紹介やこれまでのキャリアについて↓をご覧ください。) tech-blog.rakus.co.jp 社内で口癖のように使っている「製品解像度」と「UX志向」について自分の思考の整理もかねて記事にまとめてみました。 はじめに:私たちは「誰」を見ているのか? 「製品解像度」とは何か? まず押さえたい:製品解像度が低いと起きる“あるある” なぜ「お客様解像度」だけでは不十分なのか? 質の高いアウトプットを生む土壌 UX志向を支える「意思決定」の力 「OR」ではなく「AND」を模索する 「架け橋」としての役割 ラクス プロダクト部としての「UX志向」 製品解像度を高めるために 1. 「越境」を恐れない 2. 「なぜ?」を問い続ける 3. プロダクトの「歴史」と「未来」を知る 製品解像度が上がると何が起きるか:アウトプットの質が変わる 1) 要求仕様が“外れにくくなる” 2) トレードオフの説明責任が果たせる 3) 「事実に基づく」文化が回りやすくなる 4) “作って終わり”から“学習して伸ばす”に変わる おまけ:製品解像度を上げるための「10の問い」(会議で使える) おわりに:最高のUXへの近道 はじめに:私たちは「誰」を見ているのか? 「UX(ユーザーエクスペリエンス)志向」 「ユーザー中心設計」 「顧客視点」プロダクト開発の現場にいると、これらの言葉を聞かない日はありません。私たちプロダクトに関わるメンバーは、常にお客様のことを考え、彼らの課題に寄り添い、最高の体験を届けようと日々奮闘しています。しかし、ここで一度立ち止まって考えてみたい問いがあります。 「お客様のことさえ深く理解していれば、本当に優れたプロダクトは作れるのだろうか?」 という問いです。自分としての結論は“お客様理解だけでは足りない”です。 もちろん、お客様を理解することは不可欠です。しかし、それだけでは「良いプロダクト」を継続的に生み出し、育てていくことはできません。 時に「お客様のため」を思うあまり、ビジネスとして成立しない機能を作ってしまったり、技術的に無理のある実装を強いてプロジェクトを破綻させてしまったりすることさえあります。 では、私たちには何が必要なのか? そこで私が提唱したいのが、 「製品解像度」 という概念です。 今回は、単なる「お客様解像度」を超え、真の意味でプロダクトを成功に導くための「製品解像度」について、その定義となぜそれが不可欠なのかを紐解いていきます。 「製品解像度」とは何か? まず、「解像度」という言葉についてです。自分の中では解像度は写真の比喩が一番しっくりきます。ピントが合っていない写真は、全体の雰囲気はわかるけれど、重要なディテール(表情・文字・境界線)が見えません。プロダクトでも同じで、解像度が低いと、議論が抽象的になり、判断が“気分”や“声の大きさ”に引っ張られます。逆に解像度が高いと、論点が具体になり、仮説と事実が整理され、意思決定が速くなる。 この「ピントの合い方」を、製品を取り巻く全体に広げたものが“製品解像度”として自分は定義しています。具体的には、次のような観点です。 お客様:誰が、どんな状況で、どんな目的で使っている/使おうとしているか (運用中・導入準備中・導入検討・未検討といったフェーズも含む) システム:制約、データの流れ、既存アーキテクチャ、運用条件 UI/UX:主要導線、つまずきポイント、体験の一貫性 ドメイン:業務知識、法令、慣習、現場の「当たり前」 自組織/他組織:意思決定構造、責任分界、依存関係、コミュニケーション経路 事業戦略:何を伸ばし、何を守り、何を捨てるのか(優先順位) 市場:競合、代替、ポジショニング、差別化要因 未来:中長期の方向性、ロードマップ上の“意味” 開発プロセス/役割:どう作り、どう届け、どう改善していくか 製品解像度とは、 プロダクトを取り巻くエコシステム(生態系)全体に対する理解の深さ を意味します。これら全てを網羅し、それぞれの要素がどう絡み合っているかを理解している状態こそが、「製品解像度が高い」状態と言えます。 まず押さえたい:製品解像度が低いと起きる“あるある” 製品解像度が低い状態は、努力不足というより「見えていないから判断できない」状態です。現場でよく起きる症状を挙げます。 顧客要望をそのまま機能要件に翻訳してしまい、根っこのジョブや制約を見落とす 「これが良さそう」という仮説だけで意思決定してしまい、後から前提が崩れて手戻りする “十分な検討のないトレードオフ”になり、関係者の納得が得られない リリース後、成果が測れず、改善が続かない(やりっぱなしになる) 部署間の認識がズレて、会議で「それは誰が決めるの?」が発生する どれも、個人の能力というより「判断材料が揃っていない」ことが原因です。だからこそ、解像度を上げることが、チームの再現性をつくります。 なぜ「お客様解像度」だけでは不十分なのか? 「お客様第一」は美しい言葉ですが、プロダクトマネジメントの現実はもっと複雑で泥臭いものです。なぜ「お客様解像度」だけでは戦えないのか、その理由を構造的に解説します。 The Product Management Triangle Posted by Dan Schmidt, Product Logic ※ラクスのプロダクト部向けにカスタマイズ プロダクト開発には有名な「プロダクトマネジメント・トライアングル」という概念があります。これは、プロダクトが以下の3つの要素のバランスで成り立っていることを示しています。 開発者(Developers) お客様(Customers) ビジネス(Business) この3つの頂点を繋ぐ辺(関係性)を見てみましょう。 お客様 × 開発者 = UX(ユーザー体験) お客様のニーズを技術でどう解決するか。ここから優れたUXが生まれます。 お客様 × ビジネス = 価値交換(収益) お客様への価値提供が、いかに対価としてビジネスに還元されるか。ここから利益が生まれます。 3. 開発者 × ビジネス = 実現可能性(デリバリー) ビジネスの要求を、限られたリソースと技術でどう実現するか。ここから製品が世に出ます。 もし、あなたが「お客様解像度」しか持っていない場合、見えるのは「1. UX」の領域だけです。 「お客様がこう言っているから機能を追加しよう」と提案しても、それがビジネス的に採算が合わない(2の視点の欠如)ものであれば却下されるでしょう。また、技術的に莫大なコストがかかる(3の視点の欠如)ものであれば、開発チームとの信頼関係を損なうかもしれません。 「製品解像度」を持つということは、このトライアングル全体を俯瞰し、3つの辺すべてを 健全に機能させる視点を持つ ということです。 質の高いアウトプットを生む土壌 「アウトプットの質」とは何でしょうか? 単に「見た目が美しいUI」や「バグのないコード」のことでしょうか? プロダクト開発における「質」とは 、「実現可能性(Feasibility)」と「事業性(Viability)」と「有用性(Desirability)」が高い次元で融合していること です。 お客様の要望(顕在ニーズ)に応えることは重要です。しかし、プロフェッショナルであるならば、その要望をそのまま形にするのではなく、「技術的に最も効率的で」「ビジネスとして持続可能で」「かつユーザーの課題を根本から解決する」ソリューションを導き出さなければなりません。 システム構造を知らなければ、非効率なUIを設計してしまうかもしれません。 事業戦略を知らなければ、来年には不要になる機能を作り込んでしまうかもしれません。製品解像度を高めることは、これら「見落とし」をなくし、手戻りを防ぎ、最初から精度の高いアウトプットを生み出すための必須条件だと考えています。 UX志向を支える「意思決定」の力 プロダクト開発は「意思決定」の連続です。 「Aという機能を優先するか、Bという改善を優先するか」 「リリースを早めるか、品質を高めるか」 こうした岐路に立ったとき、製品解像度の差が如実に現れます。 「OR」ではなく「AND」を模索する 解像度が低いと、安易なトレードオフ(ORの決断)に逃げがちです。 「ビジネス側の要求だから、UXは諦めよう(Business OR UX)」 「技術的に難しいから、仕様を落とそう(Tech OR UX)」 しかし、製品解像度が高い人は、各要素のつながりが見えているため、「AND」の解を模索できます。 「技術的にはこの制限があるが、UIの工夫でユーザーの負担は減らせるのではないか?」 「ビジネス目標のKPIは、この機能を少し簡略化しても達成できるのではないか?」 ビジネスの制約(利益・コスト)、技術的な制約、そしてお客様のニーズ。これら全てを深く理解しているからこそ、単なる妥協ではない、創造的な第三の案を生み出すことができるのです。 「架け橋」としての役割 プロダクト部のメンバーには、ビジネスチームと開発チームの「架け橋」としての役割が求められます。 通訳をイメージしてください。英語しか話せない人と日本語しか話せない人の間に入る通訳が、片方の言語しかわからなかったらどうなるでしょうか? 会話は成立しません。 これと同じです。 ビジネスサイドの言語(売上、KPI、市場シェア)と、開発サイドの言語(アーキテクチャ、工数、技術的負債)。そしてお客様の言語(使いやすさ、課題解決)。 これら全ての「言語」を理解し、翻訳できるのが「製品解像度が高い人」です。 ビジネスチームには「なぜこのUX改善が将来の売上につながるのか」をロジカルに説明し、開発チームには「なぜこのビジネス要件が重要で、どう実装するのが最適か」を技術背景を踏まえて相談する。 この動きができる人材こそが、組織の中で真に信頼されるプロダクトパーソンとなれるのです。 ラクス プロダクト部としての「UX志向」 プロダクト部では本組織が組成される前(PdM組織の頃)から、以下を提示して、メンバーや自分自身もこれに従うようにしています。 製品解像度を高めるために では、どうすれば製品解像度を高めることができるのでしょうか? 明日からできるアクションをいくつか提案します。 1. 「越境」を恐れない 自分の担当領域の外に出ましょう。デザイナーなら、売上の数字を見てみる。エンジニアなら、営業に同行してお客様の声を聞く。プロダクトマネージャーなら、システム構成図を書いてみる。 「それは私の仕事ではない」と線を引いた瞬間、解像度の上昇は止まります。 2. 「なぜ?」を問い続ける 仕様書や要件定義書を見たとき、そこに書かれていることの背景を想像してください。 「なぜこの機能が必要なのか?(ビジネス背景)」 「なぜこの実装方法なのか?(技術背景)」 「なぜ今なのか?(市場背景)」 わからないことは、その領域のプロフェッショナル(営業担当やエンジニア)に質問しましょう。彼らは自分の領域に関心を持ってくれる人を歓迎するはずです。 3. プロダクトの「歴史」と「未来」を知る 過去の意思決定の経緯(なぜこの機能があるのか)を知ることで、現在の制約の意味がわかります。そして、ロードマップ(未来の構想)を知ることで、今作るべきものの優先順位が見えてきます。点ではなく、線でプロダクトを捉えましょう。 製品解像度が上がると何が起きるか:アウトプットの質が変わる 製品解像度の価値は、抽象論ではなく、アウトプットに表れます。具体的には次の変化が起きます。 1) 要求仕様が“外れにくくなる” 解像度が高いと、論点の抜け漏れが減り、前提が揃うので、要求仕様(PRD)やデザインが当たりやすくなります。組織の重点取り組みでも「製品を取り巻く解像度を向上し、外れのない要求仕様を策定して開発に提供できる状態」を目指す、と明確に言語化されています。まさにここが、製品解像度が“成果”に変わる瞬間です。 2) トレードオフの説明責任が果たせる UXは必ずトレードオフの連続です。どれを捨て、どれを採るか。その判断が“十分な検討のないトレードオフ”になってしまうと、ステークホルダーは納得しないし、ユーザーも幸せにならない。製品解像度が高いチームは、制約を含めて説明できるので、合意形成が進みます。 3) 「事実に基づく」文化が回りやすくなる お客様の声、利用データ、市場情報、開発・運用の実態。これらを同じテーブルに乗せられるようになると、仮説と事実が区別され、議論の質が上がります。「なんとなくこう思う」から、「この事実があるからこう判断する」へ。UX志向の行動原理と相性が良いのはここです。 4) “作って終わり”から“学習して伸ばす”に変わる 解像度が高いチームは、指標(NSMや関連指標など)を置き、リリース後に成果を回収し、開発にも共有して次に活かします。改善が単発のイベントではなく、学習ループになります。 おまけ:製品解像度を上げるための「10の問い」(会議で使える) この問いは、答えを完璧に揃えるためというより、「ピントが合っていない領域」を早めに炙り出すために使ってもらえればと思います。 おわりに:最高のUXへの近道 「製品解像度を持つべきだ」という主張は、一見するとUX志向とは対極にある「ビジネス寄り」「システム寄り」の話に聞こえるかもしれません。 しかし、逆です。 本当に優れたUXを実現したいのであれば、製品解像度を高めることが一番の近道 なのです。 お客様のことしか見ていない「優しさ」は、時にプロダクトを脆弱にします。 ビジネスと技術という現実の厳しさも含めてプロダクトを愛し、理解する「強さ」こそが、長く愛され続けるサービスを育てる土壌となります。 私たちプロダクト部のメンバー一人ひとりが、お客様解像度だけでなく、この「製品解像度」という武器を持ったとき。私たちの組織は、ビジネスの要請にも、技術の進歩にも、そして何よりお客様の期待にも、かつてない高いレベルで応えられるようになるはずです。 まずは今日、隣の席の別職種のメンバーに、彼らが見ている「製品の景色」について聞いてみることから始めてみませんか? 製品解像度を上げることは、意思決定の質を上げるだけでなく、結果として“お客様の業務が止まらない/迷わない”体験に直結すると自分は思っています。 記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー/PdM の方 は、ぜひカジュアル面談からご応募ください。 ※プロダクトマネージャーのカジュアル面談は、基本的に私(稲垣)が担当します! ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー career-recruit.rakus.co.jp
こんにちは。 株式会社ラクスで、楽楽精算のプロダクトデザインチームのリーダーをしているimamuです。 ラクスでは現在、「ベストオブブリード」戦略から「統合型ベストオブブリード」戦略へ進化を目指し、製品開発を進めています。 www.rakus.co.jp www.rakus.co.jp 私たちプロダクトデザイン組織でも、デザインガイドラインの整備やUIリニューアルを行っています。 tech-blog.rakus.co.jp note.com その一環として、UXライティングガイドラインについても共通化と各製品への浸透を目指して取り組んでいます。 でも実はこのライティングガイドライン、私たち自身が楽楽精算のプロダクト開発に関わる中で感じていた、ごく個人的な実務上の困りごとから生まれたものでした。 この記事では、現場の小さな課題感が、どのように事業戦略をプロダクトに落とす取り組みへと広がっていったのか、そのプロセスをご紹介します。 楽楽精算でぶつかった「言葉」の課題 楽楽精算ライティングガイドラインの立ち上げ なぜライティングガイドラインなのか ライティングガイドラインの判断基準 ライティングガイドラインで何が変わったか 共通ガイドラインへの進化 製品戦略とライティングガイドライン 共通化と浸透に向けた取り組み 実務での活用状況 おわりに 楽楽精算でぶつかった「言葉」の課題 楽楽精算は17年以上の歴史を持ち、400画面以上、2万社以上のお客様に使われているプロダクトです。その時々のユーザーニーズや業務環境、技術的な制約、組織体制に合わせて、数多くのエンジニアやデザイナーが文言の決定に関わってきました。 そうした積み重ねの結果、機能や画面ごとに似た意味でも異なる用語が使われている、トーンが異なっているといった状況が多く発生していました。 表現揺れの例 〇〇をご確認のうえ、もう一度〜〜してください。 〇〇をご確認の上、再度〜〜して下さい。 〇〇を確認してから、改めて〜〜してください そのため、新しく文言を検討する際、どの表現を正として判断すれば良いのかが不明確で、担当者の経験や感覚に頼った議論となりがちでした。 このような状況が生み出すのは、単に検討や合意に時間がかかるという問題だけではありません。プロダクトとしてどんな体験を提供したいのか、ユーザーにどんな状態になってほしいのかといった意図を表現するという、デザイナーの価値提供そのものを難しくさせていると感じました。 そして、まずはプロダクトとして一貫した言葉を使える体制を作ろうと考えました。 楽楽精算ライティングガイドラインの立ち上げ なぜライティングガイドラインなのか 一貫した言葉を使うために、まず整理したのは既存文言の調査手法の確立でした。当時は現在のようなAIツールもなく、過去にどんな表現が使われているのかを確認するだけでも手間がかかり、デザイナー自身で完結できない場面も多くありました。その結果、十分に調べきれないまま判断せざるを得ないこともありました。 そのため、まずは私自身でコードを調べ、デザイナー自身が文言を調査できるよう、調査手順や資材の整備を行いました。 それにより文言検討のスピードや精度は一定改善しましたが、それだけでは根本的な解決にはなりませんでした。 過去の文言を参照できるようになっても、「これからどういう言葉を使っていくべきか」「どんな基準で判断するのか」は、依然として属人性が高いままでした。 そこで次に取り組んだのが、UXライティングガイドラインの策定です。当時、私はUI刷新プロジェクトの立ち上げと並行して携わり、チームメンバーと分担して検討を進めました。 ライティングガイドラインの判断基準 ライティングガイドラインの目的は、属人性の排除と品質の担保です。 それにより、デザイナーの検討コストを下げるとともに、サポートサイトを作成しているCSとの合意形成をより納得感を持ってスムーズに行える状況をつくりたいと考えていました。 そのため、ガイドラインは抽象的な指針ではなく、誰が見ても判断の拠り所として使えることを意識して信頼性の高いリソースを参照しました。 具体的には、社内のコミュニケーションガイドラインや、以下をはじめとした複数の書籍や公的機関によるガイドラインを参照しています。 書籍 UXライティングの教科書 日本語スタイルガイド(第3版) 公用文用字用語例集 ガイドライン 文化庁 公用文作成の考え方 文化庁 常用漢字表 この時点ではプロダクト横断で使うことを明確に見据えていたわけではありませんでしたが、結果として他のチームやプロダクトとも共有しやすい基準になりました。 初版はスプレッドシートでした ライティングガイドラインで何が変わったか ガイドラインを使い始めてまず変わったのは、文言検討やレビューの進め方でした。「この表現が正しいかどうか」を感覚で考えたり、過去事例を探し回ったりするのではなく、ガイドラインを参照しながら理由を説明できるようになりました。 その結果、レビューや議論の焦点が「わかりやすそう」といった個人の感覚から、「ガイドラインの考え方に沿っているか」「なぜわかりやすいと判断できるか」といった論点に移っていきました。特にCSとの文言調整においては、判断の根拠が明確になったことで、合意形成にかかるコストが大きく下がったと感じています。 また、デザイナー自身にとっても、毎回ゼロから考えなくてよくなったことで、検討のスピードが上がりました。文言に悩む時間が減った分、UIや体験の設計といった本来注力すべき検討に時間を割けるようになり、結果として担当できる案件や工程の幅が広がっていきました。 共通ガイドラインへの進化 製品戦略とライティングガイドライン ちょうどこの頃、会社としての製品戦略も「統合型ベストオブブリード」へと舵を切りました。その結果、プロダクト単体ではなく、シリーズ全体で一貫した体験を提供することが、より強く求められるようになっていきました。 それに応えて、UI刷新や共通デザインガイドラインの立ち上げといった取り組みもはじまり、UIコンポーネントやレイアウトについては一定の一貫性を担保できる仕組みができあがっていきました。 こうした中、次に課題として浮かび上がってきたのが「言葉」の扱いでした。UIの構造や使われ方が共通化されていく一方で、文言だけが個別最適のままでは、体験としての一貫性を保つことが難しくなります。 そこで、共通のライティングガイドラインを組み込み、UIコンポーネントやデザイン原則、デザインパターンと合わせて参照できる状態を目指しました。 共通化と浸透に向けた取り組み まず行ったのは、各製品におけるライティングの扱われ方や、ガイドラインの有無、運用状況を整理することです。製品ごとに歴史や体制、課題感が異なる中で、どこまでを共通化できそうか、どこは個別性を残すべきかを整理しました。また、共通化を進めるうえで、検討フローをどう設計すべきかも把握する必要がありました。 そうした整理を進める中で、楽楽精算のライティングガイドラインをベースとして選びました。信頼性の高いリソースに基づいていること、他職種との合意形成を前提にしていること、安定した運用実績があったことが理由です。 楽楽精算のガイドラインをたたき台として、プロダクト固有の要素を分離し、共通化できる観点や考え方を抽出しました。そして、各プロダクト固有の用語や言い回しは禁止するのではなく、それぞれ固有のガイドラインとして参照できる仕組みを作りました。 また、UI/UXの共通化をより組織に浸透させるため、楽楽精算のライティングガイドラインやデザイン原則、UIコンポーネントの策定に直接関わっていないメンバーにもライティングの共通化を推進してもらいました。 現在はさらにデザイナー全員が参照しやすいよう、AIによる可読性の向上やツール整備を進めています。 実務での活用状況 こうした取り組みの結果、楽楽従業員ポータルに代表される新規プロダクトでは、共通のガイドラインに基づいたコンポーネントやレイアウト、用語やトーンを使用し、統一感のある体験を提供できるようになりました。 今後はさらに既存プロダクトについても、既存の体験の良さを活かしつつ、統一感のある使いやすい体験を提供できるよう取り組みを進めています。 おわりに 振り返ってみると、この取り組みは最初から「事業戦略に貢献しよう」と考えて始めたものではありませんでした。出発点は、楽楽精算の実務の中で感じていた、言葉に関する小さな違和感でした。 デザイナーが事業戦略に関わる方法は、必ずしも大きな意思決定の場に直接参加することだけではありません。日々の実務で生まれる判断を構造化し、再現できる形にしていく。その積み重ねが、結果として事業戦略をプロダクトに落とし込むことにつながっていくのだと思います。 この記事で書いた取り組みや判断が、UI/UXデザイナーの事業的価値を考える際の参考になれば幸いです。 もしこの記事を読んで、ラクスでのプロダクトづくりやデザインの関わり方が気になったら、採用情報も覗いてみてください。まずは気軽に、カジュアルにお話しできたら嬉しいです。 career-recruit.rakus.co.jp
こんにちは、プロダクト部 部長の稲垣です。(自己紹介やこれまでのキャリアについて↓をご覧ください。) tech-blog.rakus.co.jp 昨年、「 オペレーショナル・エクセレンス――業務改革(BPR)の理論と実践 」を読み、2026年に入り、たまたまイベントで同じ話題があったので、自分なりに整理するために記事を書こうと思います。 www.docswell.com 1. はじめに 2. 優良企業が持つ「3つの価値基準」 1.プロダクト・イノベーション(Product Innovation) 2.カスタマー・インティマシー(Customer Intimacy) 3.オペレーショナル・エクセレンス(Operational Excellence) なぜ「3つ全て」を目指してはいけないのか 3. なぜPdMは「オペレーショナル・エクセレンス」を軽視するのか オペレーショナル・エクセレンスは「守り」ではなく「最強の攻め」 4. PdMが再定義すべき3つの戦略アプローチ ① オペレーショナル・エクセレンス戦略: ② カスタマー・インティマシー戦略: ③ プロダクト・イノベーション戦略: 5. プロダクトマネージャーは「機能」ではなく「利益構造」を作る 結論:オペレーショナル・エクセレンスはあらゆる現場で必要である 1. はじめに アメリカのコンサルタントであるマイケル・トレーシー氏とフレッド・ウィアセーマ氏が1995年に著書『 ナンバーワン企業の法則 』の中で提示されている、優良企業に共通する3つの戦略的指標として以下を挙げています。 カスタマー・インティマシー 良い顧客をつかむ プロダクト・イノベーション 良い製品を生む オペレーショナル・エクセレンス 業務で利益を生む 「プロダクトマネージャー(PdM)」という職種において、自分として憧れるのはいつだって「 プロダクト・イノベーション 」です。 iPhoneのような革命的なデバイス、あるいはChatGPTのような世界を変えるAI。誰も見たことのない機能を実装し、技術力で市場を圧倒する──。そんな「製品の力」で勝つストーリーは魅力的ですし、PdM冥利に尽きると感じています。しかし、あえて厳しい現実を直視するところから始めたいと思います。 今の日本の市場環境において、「プロダクト・イノベーション」だけで勝ち続けられる企業がどれだけあるでしょうか? 機能はすぐに模倣され、技術的な優位性は瞬く間にコモディティ化します。初期の先行者利益は、後発の大資本や、より効率的な組織にあっという間に差を詰められてしまうのが常です。 私はこれまでの経験を通じて、感じていることがあります。 事業を継続的に存続させ、さらに成長させるために真に必要なのは、派手なイノベーションよりも、「オペレーショナル・エクセレンス(業務の卓越性)」である、と。 今回は、書籍『 オペレーショナル・エクセレンス 』(田中陽一 著)などで語られる「3つの価値基準」というフレームワークを補助線に、これからのPdMが持っているとよいのでは?という考え方についてまとめます。 2. 優良企業が持つ「3つの価値基準」 まず、企業の競争優位性を語る上で欠かせない「3つの価値基準(The 3 Value Disciplines)」について整理してみます。マイケル・トレーシーらが提唱したこの理論では、市場のリーダー企業は以下の3つのうち「どれか1つ」に卓越しており、他の2つでも「業界平均以上の水準」を維持しているとされます。 1.プロダクト・イノベーション(Product Innovation) 価値: 「製品」そのものが最高であること。 特徴: 最新技術、革新的な機能、デザイン性。他社には作れない製品を市場に投入し続ける力。 2.カスタマー・インティマシー(Customer Intimacy) 価値: 「顧客との関係」が最高であること。 特徴: 顧客ごとの個別ニーズへの対応、手厚いサポート、長期的なパートナーシップ。「私のことを誰よりもわかってくれる」という信頼。 3.オペレーショナル・エクセレンス(Operational Excellence) 価値: 「業務プロセス」が最高であること。 特徴: 低コスト、便利、早い、正確、ストレスフリー。購入から利用までのプロセスが極限まで効率化・標準化されている状態。 なぜ「3つ全て」を目指してはいけないのか 「最高の製品を、最高のサポートで、最安値で提供する」。 一見理想的に見えますが、リソースが分散し、全てが中途半端になる「スタック・イン・ザ・ミドル(どっちつかず)」の状態に陥ります。ここで重要なのは、「自分たちの勝ち筋はどれか?」を明確に定義することだと感じています。 そして、多くのWebサービスやSaaS、B2Bプロダクトにおいて、最も再現性が高く、かつ強固な競合優位性となり得るのは「 オペレーショナル・エクセレンス」 なのではと感じています。 3. なぜPdMは「オペレーショナル・エクセレンス」を軽視するのか 多くのPdMは、どうしても「①プロダクト・イノベーション」にリソースを割きたいと感じますし、自分もこれまでそうでした。「新機能」「AI活用」「特許技術」といった言葉は魅力的です。 一方で、「オペレーショナル・エクセレンス」は地味です。 業務フローの標準化、マニュアルの整備、オンボーディングの自動化、問い合わせ削減、API連携の強化……。これらは「機能」としてプレスリリースを出しにくく、ユーザーの目にも止まりにくい。 しかし、顧客がサービスを選ぶ理由を因数分解してみます。 特にB2Bや実用系サービスの場合、顧客の本音はこうです。 「すごい機能はいらないから、迷わず使いたい」 「担当者と仲良くしたいわけじゃなく、面倒な業務を早く終わらせたい」 「導入コストが安くて、社内稟議が通りやすいものがいい」 これらは全て、製品の「革新性」ではなく、 提供プロセスの「卓越性(オペレーショナル・エクセレンス)」 に対するニーズです。 オペレーショナル・エクセレンスは「守り」ではなく「最強の攻め」 オペレーショナル・エクセレンスを「コスト削減(Cost Cut)」と混同してはいけないと感じています。オペレーショナル・エクセレンスとは、 「競合が模倣できない仕組み」 そのものです。 例えば、ある企業が素晴らしい新機能をリリースしたとします。競合他社は、その機能を3ヶ月あればコピーできるかもしれません。 しかし、その企業が持つ「誰が売っても売れる営業プロセス」「問い合わせが来ないほど洗練されたUI」「ミスが起きない開発フロー」といった 裏側のオペレーションをコピーするには、数年単位の組織変革が必要 になります。つまり、 オペレーショナル・エクセレンスこそが最も深い「Moat」 になるのでは?と思います。 4. PdMが再定義すべき3つの戦略アプローチ では、オペレーショナル・エクセレンスを軸に据えたとき、PdMは具体的にどう動くべきか? 「3つの価値基準」を再解釈し、PdMのアクションプランに落とし込んでみます。 ① オペレーショナル・エクセレンス戦略: テーマ: 「摩擦ゼロ(Frictionless)」と「標準化の強制」 ここでのPdMのミッションは、 「顧客が製品を知り、使い始め、定着するまでのコスト」を極限まで下げる ことです。 徹底した標準化(Config, not Custom): 顧客の「あれもこれもできる」という要望に応えるのは、一見親切に見えて、実はオペレーショナル・エクセレンスを破壊します。PdMは勇気を持って「No」と言わなければなりません。「業界のベストプラクティスはこれです」と提示し、顧客の業務をプロダクトに合わせて変えてもらう(標準化する)。これにより、開発・保守・サポートのコストを劇的に下げ、その分を価格や品質に還元するのです。 「自走型プロダクト」の実現: 営業やCSが説明しなくても使えるUI/UXを目指します。マニュアルを読まなくても直感的に操作できること。これが究極のオペレーショナル・エクセレンスです。「サポートが手厚い」ことよりも、「サポートがいらない」ことの方が、現代においては価値が高いと感じます。その状態において+αのサポートこそ武器となると感じています。 ② カスタマー・インティマシー戦略: テーマ:「スケーラブルな親密さ」 オペレーショナル・エクセレンス重視の場合、一対一のベタ付き対応(ハイタッチ)はコスト構造上できません。しかし、インティマシー(親密さ)を捨てるわけではありません。「データと仕組み」で代替するのです。 データドリブンな先回り: 「最近ログインしていない」「特定の設定で詰まっている」といった状況をデータで検知し、自動でフォローメールを送る、あるいは画面上にガイドを出す。人間が電話をかけるのではなく、プロダクトが「あなたのつまずきに気づいていますよ」と語りかける設計です。 コミュニティの活用: 顧客同士が助け合う場を作ること。これも、企業の工数をかけずに顧客満足度(所属感)を高める高度な戦略です。 ③ プロダクト・イノベーション戦略: テーマ:「入力ゼロ(Zero Input)への進化」 ここでのイノベーションは、「新しいことができる」ではなく「やらなくていい」を作るために使います。 「作業の消滅」を目指す: AIや新技術を導入する目的はただ一つ。「ユーザーの作業を減らすこと」です。 例えば、精度の高いAI-OCRを入れるのは、「すごい技術」を見せるためではなく、「手入力」という不快な作業を消し去るためです。 UXのモダナイゼーション: 機能表には載らない「サクサク動く」「スマホで見やすい」といった品質(非機能要件)への投資です。これは地味ですが、レガシーな競合に対する強力なイノベーションとなり得ます。 5. プロダクトマネージャーは「機能」ではなく「利益構造」を作る これからのPdMに求められるのは、単に「仕様書を書くこと」でも「アジャイル開発を回すこと」でもありません。 「プロダクト、顧客対応、業務プロセス、これら全て(End-to-End)を含めた『勝てる仕組み』を設計すること」 です。プロダクト・イノベーションだけで勝てる企業は、私が知る限りでは少ないように感じています。 一方で、オペレーショナル・エクセレンスを極め、そこに適切なインティマシーとイノベーションを組み合わせている企業は、不況下でも強く、利益を出し続けているように感じます。 結論:オペレーショナル・エクセレンスはあらゆる現場で必要である 「うちはイノベーションで売っているから関係ない」 そう思う現場こそ、私の経験上では危険なように思います。イノベーションで一時的に注目を集めても、それを顧客に届けるプロセスが非効率であれば、利益は出ません。サポートがパンクし、開発がバグ修正に追われ、やがて組織が疲弊します。 逆に、オペレーショナル・エクセレンスという強固な土台があれば、そこで生まれた余剰リソース(金・人・時間)を、次のイノベーションへの投資に回すことができます。オペレーショナル・エクセレンスは「守り」ではなく、 「次の攻め」を生み出すためのエンジン なのです。 もしあなたが今、PdMとして「次にどんな機能を作るべきか」悩んでいるなら、一度視点を変えてみるのもよいかもしれません。 「どうすれば、顧客がこの機能を『説明なし』で使えるようになるか?」 「どうすれば、社内の開発・運用プロセスがもっと『ラク』になるか?」その問いの先にこそ、持続可能なプロダクトの未来があるはずです。 地味で泥臭い「オペレーション」の中にこそ、プロダクトマネジメントの本質が眠っているように思います。 記事を読んでラクスのプロダクト部に興味を持ってくださった デザイナー/PdM の方 は、ぜひカジュアル面談からご応募ください。 ●採用情報 プロダクトマネージャー career-recruit.rakus.co.jp デザイナー career-recruit.rakus.co.jp
こんにちは、プロダクト部 部長の稲垣です。(自己紹介やこれまでのキャリアについて↓をご覧ください。) tech-blog.rakus.co.jp 以前は自社の戦略について書きましたが、今回は視点を変えてみます。 これまで大手・ベンチャー・外資など様々な企業で社内システムに触れてきたユーザーとしての経験、そして現在バックオフィス系SaaSに携わっている提供者としての知見。 これらを踏まえて、自分なりに整理してみました。 目次 はじめに:SaaSの普及と、残された「巨大な壁」 第1章:前提となる「企業の基幹システム」4つのアーキテクチャ 1. Fit to Standard(ERP一本足打法) 2. Two-Tier ERP(2層構造:ERP × SaaS) 3. Composable ERP(レゴブロック型) 4. SaaS Unbundling(脱SaaS・完全内製回帰) 第2章:なぜ「SI」や「AI × BPO」だけでは届かないのか SI(システムインテグレーション)の課題 ── 「要件定義」の壁 AI × BPOの課題 ── 「ブラックボックス化」の壁 第3章:現場を変える「専属シェフ」 ── Forward Deployed Engineer (FDE) 第4章:システムをつなぐ「万能翻訳機」 ── 中間システムとOntology 「データ」に「意味」を与える (Ontology) 異なる言語を翻訳する「万能翻訳機」 第5章:AI時代の新しいアーキテクチャ ── 「自律的AI」への道 AIが「働く」ための地図 おわりに:バックオフィス・プロダクトの解像度を高める はじめに:SaaSの普及と、残された「巨大な壁」 ここ10年で、日本のSaaS市場は劇的な進化を遂げました。クラウド上の優れたツールを契約し、IDを発行すれば、その日から最新のUI/UXで業務ができる──。これが「当たり前」となり、多くの企業で生産性が向上しました。しかし、この成功法則が通用しない領域が依然として存在します。それが、巨大な歴史と複雑な業務構造を持つ「エンタープライズ企業」の基幹業務領域です。 「SaaSを導入したけれど、既存の基幹システムとデータがつながらない」 「現場独自の複雑なオペレーションが、標準機能ではカバーしきれない」 「結局、CSVデータを手作業で加工してアップロードする業務が残った」こうした声は、SaaSベンダーとエンタープライズ企業の双方が抱える深い悩み(ペイン)です。なぜ、便利なSaaSが増えても、現場の苦しみはなくならないのか。その解像度を高めるためには、まず現在企業が置かれている「システム・アーキテクチャの現在地」を知る必要があると思っています。 本記事では、企業の基幹システムが辿ってきた自分なりに整理した「4つのアーキテクチャ」と、既存の「SIやBPO」が抱える課題を整理した上で、その全てを突破するために現れた新しいアプローチ──「専属シェフ(FDE)」と「万能翻訳機(中間システム)」について自分なりに市場の状況を踏まえて解説をまとめてみました。 これは単なるツールの話ではなく、これからのバックオフィスプロダクトが向かうべき、ひとつの進化系統樹の話と思ってもらえればと思います。 第1章:前提となる「企業の基幹システム」4つのアーキテクチャ 「専属シェフ」や「万能翻訳機」という新しい概念を理解するために、まずは現在、エンタープライズ企業がどのようなシステム構造の上に成り立っているのか、その類型を見ていきましょう。大きく4つのパターンに分類されます。 1. Fit to Standard(ERP一本足打法) 最も伝統的かつ、かつての「理想形」とされたモデルです。SAPやOracleといった巨大なERPを導入し、会計・人事・販売・在庫など、企業のあらゆるデータを一つの巨大なシステムで管理します。 特徴: 「業務をシステムに合わせる」思想。データが一元管理されるため、経営層には理想的です。 課題: 現場にとっては「使いにくさ」が壁になります。UI/UXよりもデータ整合性が優先されるため、単純な経費精算にも多大な工数がかかります。また、日本固有の商習慣に合わせるための追加開発(アドオン)により、保守コストが高騰しがちです。 2. Two-Tier ERP(2層構造:ERP × SaaS) 現在、多くの日本企業が採用している現実解です。「本社やコア業務(会計など)は重厚なERPで守り、現場業務(労務、SFAなど)は軽快なSaaSで攻める」というハイブリッド構成です。 特徴: 守りと攻めのバランス型。現場はモダンなSaaSを使えるため、生産性が上がります。 課題: 「データの分断」が最大のネックです。社員マスターがERPにもSaaSにも点在し、それらをつなぐために「月末にCSVを吐き出し、手加工して取り込む」というアナログ作業が残ります 3. Composable ERP(レゴブロック型) Two-Tierをさらに推し進め、巨大なERPを置かずに「各業務における最強のSaaS(Best of Breed)」をレゴブロックのように組み合わせてシステム群を構成する考え方です。 特徴: 「会計はfreee」「人事はSmartHR」「営業はSalesforce」のように最適解を選べ、変化に強い構成です。 課題: インテグレーションの難易度が極めて高い点です。API連携がうまくいかないとデータがサイロ化(孤立)し、全体が見えなくなります。強力な情シス(コーポレートエンジニア)組織が不可欠です。 4. SaaS Unbundling(脱SaaS・完全内製回帰) AIの進化により、近年テック企業を中心に注目され始めた「揺り戻し」です。「SaaSは機能過多で高い。AIを使えば自分たちで必要なシステムを安く作れるのではないか?」という発想です。 特徴: 汎用SaaSを使わず、自社DBの上にAI支援で独自アプリを構築します。コスト削減と業務への完全適合がメリットです。 課題: 「作った人しか直せない」という属人化リスクと、セキュリティや品質保証をすべて自社で担う重責が発生します。 欧州フィンテック大手Klarnaが有名な例です kigyolog.com 第2章:なぜ「SI」や「AI × BPO」だけでは届かないのか 上記の4つのアーキテクチャには、それぞれ一長一短があります。「あちらを立てればこちらが立たず」の状況です。 この課題を解決しようとする際、企業が次に検討するのは、 伝統的な「SI(システムインテグレーション)」か、あるいは近年台頭してきた「AI × BPO(AIを活用した業務委託)」 だと思います。しかし、エンタープライズの「ラストワンマイル」においては、これらもまた決定打になり得ない現実があるように思います。 SI(システムインテグレーション)の課題 ── 「要件定義」の壁 SIは「建物を建てる(=システムを作る)」ことには長けています。しかし、SIモデルの前提は「要件が固まっていること」です。 「今の業務をそのままシステム化してください」と依頼しても、現場の業務は複雑怪奇なマクロや暗黙知で動いており、誰も正解を知りません。結果、要件定義に半年かかり、完成した頃にはビジネス環境が変わっている──。これが「ウォーターフォール型の限界」です。 AI × BPOの課題 ── 「ブラックボックス化」の壁 一方で、「AIを使って業務ごとアウトソースする(AI × BPO)」というアプローチも増えています。これは即効性がありますが、本質的には「人の作業をAIに置き換えただけ」です。 業務プロセス自体がブラックボックス化し、社内にデータ資産やノウハウが蓄積されません。また、AIが誤った判断(ハルシネーション)をした際、背後にあるデータ構造(オントロジー)が整備されていないため、原因究明が困難になります。 「SIのように外から作る」のでもなく、「BPOのように外に出す」のでもない。 既存のSaaS群も、SIも、BPOも解決しきれなかった「断絶」。これを埋めるために必要なのが、 「内側に入り込み、業務を回しながらシステムを進化させる」 という、第3のアプローチがでてきています。 第3章:現場を変える「専属シェフ」 ── Forward Deployed Engineer (FDE) そこで登場するのが、 FDE(Forward Deployed Engineer) という概念です。 彼らは「SIer」とも「BPOスタッフ」とも異なります。あえて言うなら、 「エンジニアリング能力を持った、現場専属の解決請負人」 です。「調整」ではなく「実装」で解決する。 SIerが「仕様書」を作る間に、FDEは「プロトタイプ」を作ります。 BPOが「マニュアル通り」に作業する間に、FDEは「マニュアルを不要にする自動化」を行います。彼らは顧客のオフィスの最前線(Forward)に入り込み(Deployed)、以下のように動きます。 APIがない? → 「ならDBのダンプから直接データパイプラインを作ります」 現場のエクセルが複雑? → 「そのロジックをPythonで解析し、システムに移植します」 SIのような「納品して終わり」ではなく、BPOのような「作業代行」でもない。 既存の冷蔵庫(レガシーシステム)にある食材(データ)を、その場で極上の料理(モダンな業務フロー)に調理して提供する「専属シェフ」。このアジャイルなアプローチは、全体最適の大改修ではなく“詰まりやすい部分”から小さく改善を重ねることで、エンタープライズの組織・プロセスの制約下でも変革を進めやすくします。 第4章:システムをつなぐ「万能翻訳機」 ── 中間システムとOntology FDEという高度人材が活躍するためには、彼らが振るう「包丁」となるシステム基盤が必要です。それが「中間システム」であり、その核となる「Ontology(オントロジー)」です。 「データ」に「意味」を与える (Ontology) 従来のデータベースは「行と列」の羅列に過ぎません。SIで開発するシステムや、AI × BPOで使うツールも、往々にして「その業務専用のデータ定義」になりがちです。 しかし、中間システムにおけるOntologyは、データそのものではなく「業務の実体(Concept)」を中心にデータを再定義します。 従来: Table_A.col_1 と Table_B.id を結合(人間が都度判断) Ontology: Customer has many Contracts(データ自体が意味を持つ) 現実世界の業務の関わり合い(コンテキスト)をそのままデータ構造として定義することで、システムは裏側の複雑なDB構造を知らなくても、「顧客の契約状況を教えて」と問うだけで正しいデータを引き出せるようになります。 異なる言語を翻訳する「万能翻訳機」 エンタープライズには、SAPやOracle、野良エクセルなど、異なる言語(プロトコル)で話すシステムが乱立しています。 ここに「 中間概念(データやシステム)」を配置することで、レガシーとモダンをつなぐ「万能翻訳機」 としての役割を果たさせます。 入力(レガシー): 古いシステムからFDEがパイプラインでデータを吸い上げる。 処理(翻訳): 吸い上げたデータをOntologyに基づいて「意味のある情報」に変換・統合する。 出力(モダン): AIエージェントやSaaSが、整理されたデータにアクセスする。 この「中間概念(データやシステム)」が存在することで、企業は巨大な基幹システムをリプレイスすることなく(=冷蔵庫を買い替えることなく)、最新のAI活用(=プロの料理)を享受できるようになります。 第5章:AI時代の新しいアーキテクチャ ── 「自律的AI」への道 この 「FDE × 中間概念(Ontology)」 という構造は、これからのバックオフィスプロダクトにおいて、AIを活用するための必須条件となります。 AIが「働く」ための地図 生成AIやAIエージェントが実業務で機能するためには、コンテキスト(文脈)が必要です。単にマニュアルを学習させるだけでは不十分で、「今、この瞬間の会社の状態」を正確に把握していなければなりません。 中間システム上のOntologyは、まさに 「AIにとっての地図」になります。 「A社の請求書が遅れている」という事実だけでなく、「A社は重要顧客であり、過去に同様のケースでは担当者が電話でフォローしていた」という文脈をAIが理解できて初めて、AIは単なるツールを超え 、「自律的なエージェント」として機能します。 つまり、中間システムを構築することは、単なるデータ統合ではありません。 SIのように「箱」を作るのでもなく、BPOのように「人」で埋めるのでもなく、「企業そのものをデジタルツイン(デジタルの双子)化し、AIが自律的に働ける環境(ワークスペース)を整えること」なのです。 おわりに:バックオフィス・プロダクトの解像度を高める 「Fit to Standard」から「SaaS Unbundling」まで、企業のシステムは揺れ動いてきました。しかし、どの時代、どのアーキテクチャにおいても、「データをつなぎ、業務を流す」という本質的な課題は残されたままでした。 「専属シェフ(FDE)」と「万能翻訳機(中間システム)」のアプローチは、既存のSaaS群やSIモデルを否定するものではありません。むしろ、過去の遺産(レガシーデータ)と未来の技術(AI/SaaS)を、技術と泥臭さで接着する新しいアプローチなのではと思っています。 古い文字コードとの戦い、複雑怪奇な勘定科目のマッピング、例外だらけの承認フロー......。 そうした「泥臭い現実」を、高度な抽象化技術(Ontology)と実装力(FDE)で包み込み、ユーザーには「魔法のようなシンプルさ」として提供する。これこそが、この領域のプロダクトマネジメント、エンジニアリングの真の面白さであり、深淵なる魅力ではないでしょうか。 それを支える中間概念(Ontology)思考。 これらはまだ耳慣れない言葉かもしれませんが、数年後には企業のバックオフィス構造を支える、当たり前のインフラになっているかもしれないと感じています。 もし、こうした「複雑さを技術で解きほぐす」アプローチや、社会の基盤となるバックオフィスプロダクトの進化に興味を持っていただけたなら、ぜひこの広大なフィールドを一緒に探求していければと思います。 この記事を読んで、現在の場所を飛び出そうと思った方やラクスのプロダクト部に興味を持ってくださった デザイナー/PdM の方 は、ぜひカジュアル面談からご応募ください。※プロダクトマネージャーのカジュアル面談は、基本的に私(稲垣)が担当します! ●採用情報 デザイナー career-recruit.rakus.co.jp └ デザインマネージャー career-recruit.rakus.co.jp /アシスタントマネージャー career-recruit.rakus.co.jp
こんにちは。ラクス フロントエンド開発課 新卒2年目の持永です。 最近AI活用が進み、コードを書く速度は以前とは比較にならないほど上がりました。 そこで私は、 「AIに並列で実装を任せれば、複数の画面/機能を"爆速"で開発できるのでは?」 と考え、複数画面・複数機能を並列で進めるスタイルに挑戦しました。 並列開発の中で、工夫してうまくいった点もありました。 ただ、期待したほどの効率化には至らず、「手戻りの連鎖」と「レビュー負荷の増大」も招きました。 今回は、並列開発で工夫した点と誤算を整理し、そこから得た気づきを共有します。 1. 試したアプローチと結果 2. 工夫した点①:AI向けの仕様書と計画書を用意した 作成の流れ 効果 3. 工夫した点②:ローカル構成の整理 ポイント 効果 4. 誤算①:未確定要素による「手戻りの増加」 何が起きたか なぜ起きたか どうすべきだったか 5. 誤算②:並列ばかり意識して、レビューを含む全体最適を見失った 何が起きたか なぜ起きたか どうすべきだったか 6. まとめ 工夫した点 誤算 気づき さいごに 1. 試したアプローチと結果 使用したAIツールはCodexとClaude Codeです。 私が担当しているプロダクトのフロントエンド開発チームは二人体制で進めていました。 試したアプローチとしては、約1ヶ月半の実装期間で主に画面単位(一覧画面、詳細画面、編集画面など)でコンフリクトが起きない範囲を見極めつつ、4〜5画面を並列で進めました。 結論から言うと、直列で進める前提で立てていた見積もりを約1週間ほどオーバーしてしまいました。 2. 工夫した点①:AI向けの仕様書と計画書を用意した AIに正確に実装させるかつ人間側が進捗と作業範囲を把握することを目的に、AI向けの仕様書と実装計画書を用意しました。 作成の流れ 1. フロントエンド向け仕様書の作成 案件の情報(要求仕様や概要設計などの上流仕様書、Figmaのリンク、API定義)を材料に、フロントエンド実装に必要な情報だけを抽出した仕様書をAIで作成 2. 仕様書のレビュー・修正 AIが出力した仕様書を自分でレビューし、不足や誤りがあれば修正を指示して内容を整形 3. 実装計画書の作成 整形した仕様書をもとに、実装計画書をAIと共に作成 4. 計画書に沿った実装 実装計画書に沿って、AIに実装を進めてもらう 実装計画書(イメージ) - [x] 1. コンポーネントの基本構造を作成 - [x] 2. API呼び出し処理を実装 - [ ] 3. バリデーションロジックを追加 ← 今ここ - [ ] 4. エラーハンドリングを実装 - [ ] 5. ローディング状態の表示を追加 効果 計画書をチェックリスト形式にしたことで、AIが今どこを実装しているのかが一目でわかるようになりました。 並列で複数の機能を進めていても、それぞれの計画書を見れば「機能Aは3番目のステップ」「機能Bは5番目で完了間近」といった進捗を把握しやすくなりました。 結果として、作業を切り替えるたびに私が進捗を思い出したり確認したりする手間が減りました。 3. 工夫した点②:ローカル構成の整理 AIへの参照範囲の説明コストを下げつつ、並列開発の作業切り替えを分かりやすく素早く行うことを目的に、ローカルの資材配置を整理していました。 git worktree などで複数ブランチを同時に触ると、作業ディレクトリが増えていきます。 その状況でAIに、「案件や機能ごとに、現状のフロントエンド実装がバックエンド実装やAPI仕様と整合しているか」を確認させるとき、参照させる範囲や前提(どのブランチ/どの資材なのか)を的確に渡すための手間が増えてしまいます。 そこで、案件/機能ごとにフロントエンド/バックエンド/API仕様の資材をひとまとまりにしつつ、別途「バージョン確定時点の固定セット」も置く、という形にしていました。 この構成自体もAIに指示して組んでもらいました。 ローカルディレクトリ構成(イメージ) * 担当プロダクトはポリレポ構成(フロントエンド・バックエンド・API仕様がそれぞれ別リポジトリ)で開発されています。 workspace/ ├── vX.Y.Z/ │ ├── epic-1/ # 案件ごと │ │ ├── feature-a/ # 主に機能/画面ごと │ │ │ ├── AGENTS.md # ブランチ指定、役割等の説明 │ │ │ ├── CLAUDE.md # ブランチ指定、役割等の説明 │ │ │ ├── plan.md # 実装計画書 │ │ │ ├── frontend/ │ │ │ ├── backend/ │ │ │ └── api-spec/ # API定義 │ │ ├── feature-b/ │ │ │ └── ... │ │ └── spec-epic-1/ # 案件の仕様 │ └── fixed-vX.Y.Z/ # 確定資材(ブランチ/コミット固定) │ ├── frontend/ │ ├── backend/ │ └── api-spec/ └── templates/ └── spec_template.md #仕様書のテンプレート ポイント 各feature直下に配置したAGENTS.mdやCLAUDE.mdにて、「このブランチで作業すべき」「このディレクトリ内のapi-specは今回開発したい案件の確定済みのAPI定義である」といった前提情報をAIに伝えるようにしていたことで、AIによる意図しないブランチ変更や誤った参照を減らすことができました。 効果 この構成にしたことで、AIに依頼するときに「どこを見てほしいか」を一言で指定しやすく、横断的な参照もしてもらいやすくなりました。 例えば「このバージョンのこの範囲で、フロントエンド/バックエンド実装とAPI仕様の不整合箇所を見てほしい」といった依頼を、細かいブランチなどの指定を毎回することなく依頼できるようになりました。 結果として、開発中のAPI仕様や実装との整合性チェックや、バージョンごとの不具合調査における原因切り分けといった場面での横断的な分析で、この整理が役に立ちました。 4. 誤算①:未確定要素による「手戻りの増加」 開発段階では、画面の文言や共通仕様が完全には確定していないこともあります。 その状態で複数の機能を並列で進めていき、次のような事態が起きました。 何が起きたか 実装途中で「文言の変更」や「仕様の微調整」が発生 文言が少し変わるだけでも、実装計画書の該当箇所をすべて修正する必要があった 並列で実装していた他の機能にも同じ変更が関係する場合、そちらの計画書も修正が必要に 「資料の修正 → AIへの再依頼 → 生成物の差分確認」という往復が複数の作業で同時に発生し、手戻りが連鎖していきました。 なぜ起きたか AIになるべく正確に実装させようと実装計画書をAIと共に調整していく際に、細かく書きすぎていたことが主な原因でした。 並列で動かしているほど、確定していない要素の影響が広がりやすくなります。 細かすぎる実装計画書を作成したために小さな変更が入るだけで周辺資料の調整コストが積み上がり、結果として全体の効率が落ちてしまいました。 どうすべきだったか 並列開発そのものが悪いのではなく、「後で変わりやすいもの」と「早めに固めたいもの」を切り分けるべきだったと考えます。 具体的には、以下の点が挙げられます。 文言のように後で直せるものは差分を小さく保つか、Figma上の文言を正として計画書にはリンクのみを記載して参照先を分離しておく。 変更されやすい要素を最初から細かく指定しすぎず、揺れにくい部分(ロジックや設計)から先に積み上げる計画にする。 5. 誤算②:並列ばかり意識して、レビューを含む全体最適を見失った もう一つの問題は、並列で進めることに意識が向きすぎて、レビューまで含めた「全体としての進めやすさ」を考えきれていなかった点です。 何が起きたか 複数を並行して進めていたため、最初のPRを出すまでに時間がかかった その間、レビュワーはレビューできる対象がない状態が続いた 複数のレビュー依頼がほぼ同時期になり、レビュワーへの負荷が集中 指摘対応も同時期に重なる 自分以外から見ると進捗が把握しづらい状態に なぜ起きたか 自分としては「手を止めない」ことを優先して作業を積み上げがちになっていました。 AIを活用することで自分の実装ペースだけは維持できてしまうため、レビュワーとのペースのズレに気づきにくくなっていました。 どうすべきだったか 並列で進めるなら、なおさらPRの粒度・順番・レビュー依頼のタイミングを「自分の都合」だけで決めず、レビュワーと認識合わせした上で進めるべきでした。 具体的には、以下の点が挙げられます。 先に固めたいロジックや設計だけを小さく切って早めに見てもらうことを留意して、並列で進める優先順位を決める。 レビューが走っている間に次の作業を進めつつ、指摘対応が滞らない余白も確保する。 6. まとめ 工夫した点 AI向けの仕様書と計画書(チェックリスト形式)を用意したことで、並列で進めていても各機能の進捗状況が一目で把握できた。 AIが参照しやすいようにローカル構成を整理したことで、開発中のAPI仕様や実装との整合性チェックや、不具合の原因切り分けがやりやすくなった。 誤算 細かすぎる実装計画書を作成して並列で進めた結果、「資料修正 → AIへの再依頼 → 差分確認」の往復が連鎖した。 PRの粒度やタイミングが極端になり、レビュー負荷と待ちが増えた。 気づき 今回の経験を振り返ると、「手戻りを減らす計画」「レビュワーとの連携の意識」といった内容は、基本的なことばかりでした。 AIによって上がった実装スピードを過信して、その「当たり前」を見失っていたことに気づきました。 今回の挑戦を踏まえた反省点は以下の通りです。 計画書に変わりやすい要素を細かく書きすぎない 文言はFigmaを参照させるように指定したり、仕様に絡む部分は仕様書側に記載することで、仕様変更時の「資料修正 → 再依頼 → 差分確認」の往復を減らす。 並列で進める上での優先度を留意する レビューも含めて、どの粒度・順序で進めるべきかを着手前に計画/認識合わせしておく。 さいごに AIのおかげで、実装自体は確かに速くなりました。 ただ、「速く作れる」ことと「全体が早く終わる」ことは別だと、今回改めて実感しました。 仕様が揺れやすい部分は揺れる前提で切り分け、レビューが滞らない粒度と優先度で小さく出して、確実にマージしていく。 結果的にチーム全体の進みが良くなるような進め方を考える力は、AIで開発を行っていく上でも変わらず求められていくものだと考えます。 同じようにAI活用×並列開発を試している方の参考になれば幸いです。