まず「測る」ことを設計した 「使わない」には、それぞれの理由があった AI活用は確かに進んだ。でも、浸透しきってはいない 顧客に届けるための、AI活用標準化 今期進める4つの取り組み 「エンジニア非稼働時間帯でも開発が進む」を目指して こんにちは、ラクス技術広報です。 AIツールが開発現場に届いたあと、何が起きているのか。ChatGPT EnterpriseやGitHub Copilotが展開されてしばらく経ったころ、ラクスの開発本部横断組織「開発管理課」はある問いに詰まっていました。ツールは使えている。使っているエンジニアもいる。でも組織として本当に生産性が上がっているのか、確かめる手段がなかった。 実際に声を集めてみると、大きく個人差が開いている状況でした。AIを使いこなしてどんどん先へ進む人と、今まで通りのやり方を続ける人。「チームによって開発スピードに差が出てきている。個人の問題というより、組織として型がないことが課題だと感じていた」と担当者は言います。 ラクスは楽楽精算・楽楽明細・楽楽自動応対など複数のクラウドサービスを展開しており、開発組織は商材ごとに独立したチームで構成されています。チームが独立しているぶん、AI活用のやり方も自然と各チーム任せになりやすく、活用度にムラが出やすい環境でもあります。このムラをどう埋め、組織全体に浸透させるか。開発管理課がどう向き合っているのかを、担当者に語ってもらいました。 まず「測る」ことを設計した 「浸透しているかどうかが見えない」問題を解くために、開発管理課が最初に選んだ一手は計測の仕組みを作ることでした。 参考にしたのはSalesforceが実施していた48項目にわたるAI浸透度調査。ただ、そのまま導入するのは規模が大きすぎる。削り込んでいっても20問ほどになってしまい、それでもまだ多い。さらにラクス特有の難しさがありました。ラクスの開発組織は商材ごとにチームが独立しており、技術スタックも文化も異なる。単一組織向けに設計されたサーベイをそのまま当てはめても、実態を正しく測れない。加えて「どのツールを使っていますか」「その機能は使っていますか」という質問は、ツールや機能が変わるたびに使えなくなる。「変わらない計測軸で、AI導入を継続的に観測するにはどうすればいいか」という問いに、担当者は上長と二人で揉みに揉みました。 行き着いたのが「プロセス別AIコミット度」という設計軸です。実装・テスト・設計・要件定義といった各開発フェーズで、どれだけAIを活用しているかを問う。ツールの名前ではなく「工程への組み込み度合い」を問うことで、環境が変わっても変わらない比較軸を持てるようになりました。これにより、管理職への相談も「感覚値」から「数値に基づく議論」に変わっていきました。 第1回サーベイを実施すると「一歩目を踏み出せていない人が一定数いる」ということが数字としてはっきりしてきました。次の問いは「なぜ使われていないのか」でした。 具体的な計測設計については、2026年1月開催のイベントで詳しく発表しています。 speakerdeck.com 「使わない」には、それぞれの理由があった サーベイを取りながら、担当者は管理職や現場メンバーへのヒアリングも重ねていました。すると、「使わない」には想像以上に多様な事情があることが見えてきました。 担当者の印象に残っているのは、こんな声でした。 「"AI活用してます"とは言いにくい」 エンジニア文化特有の謙遜として、「AIちょっとできます」と名乗ること自体への抵抗感がある。「使っている」と言うのが気恥ずかしく、結果として使っていないように見えてしまう人が一定数いた。 「ハルシネーションでテストが増えて、むしろ手間が増える」 AIを入れると今まで動いていたコードがずれてしまい、テストの修正コストが上回る。「わざわざAIに作り直させると余計に手間が増える」と感じている人がいた。 「試行錯誤の時間が取れない」 高負荷な業務を抱えながら、AIを自分の業務にフィットさせる時間が取れない。「失敗したらまた手直しもしなきゃいけない。片手間でなんとかするのは難しい」という声もあった。 「AIとチャットはするけど、開発業務で効率的に使う方法がわからない」 AIとやりとりすること自体はしている。でも、実際の開発のどの場面でどう使えばいいかイメージが持てず、業務への組み込みは試せていない。気づけば「使っていない人」になっていた。 こうした声を踏まえ、「まず一歩目を踏み出せていない人をケアする」という方針で勉強会を設計しました。GitHub Copilotのベンダー開発者を招いたQA付きセッション、社内のAI推進者によるClaudeの活用ハンズオン。ハンズオンでは「AIとチャットするだけでなく、実際の業務にどう組み込むか」にフォーカスしたプレゼンを行い、参加できなかったメンバーのために動画も社内に公開しました。「特にあまりAIに触れていなかった方々からは『ためになりました』という声が届きました」と担当者は振り返ります。 AI活用は確かに進んだ。でも、浸透しきってはいない 2025年9月の第1回から約5ヶ月後、2026年2月の第2回サーベイでは、開発本部全体のAI生成比率が約15ポイント上昇（43.3% → 58.3%）。「生成比率75〜100%」と回答したエンジニアの割合も30%から50%以上に増加し、AI活用が個人の試みから組織的な広がりに変わってきた手応えがあります。 一部のチームでは、より具体的な成果が出ています。 コミットからマージまでのサイクルタイムが、以前の数分の1以下に短縮された 実装工程の大部分をAIが生成するようになった（実装工程のAI生成比率は60%台から70〜90%台に到達） リリース頻度が倍近くに上がった 「仕様駆動開発（SDD）」の導入で、ある工程の工数が半分以下になった テスト項目書からE2Eテストを自動生成する取り組みで、テスト工程も大幅に削減できた 楽楽明細・楽楽自動応対チームなど一部チームでは、要件定義・概要設計といった上流工程でのAI活用率も20%台から50〜60%超に向上。設計フェーズでもAIが機能する段階に入ってきています ただ、組織全体を見渡すと、AIはまだ浸透しきっていません。商材や個人のスキルによって、活用度にムラがあります。AI活用が進んでいるチームのやり方は、そのチームメンバーの体に染み込んだ暗黙知になっており、「隣のチームでも再現したい」となったとき、そのままでは届きません。「何ができるか」を検証するフェーズは超えた。「組織全体にどう行き渡らせるか」が、今期のスタート地点です。 顧客に届けるための、AI活用標準化 なぜAI活用を組織として標準化するのか。答えは「開発を速くしたいから」だけではありません。 ラクスの開発組織が最も重視している価値観は「顧客志向」です。顧客が抱える業務課題を深く理解し、それを解決するプロダクトを届けること。個人のAI活用では、顧客への価値提供スピードを「組織として」上げるには不十分です。一部のチームの開発スピードが上がっても、全体が変わらなければ、顧客が受け取る価値の差分は限定的です。だからAI活用を「組織の標準」にする必要があります。 AI活用が進んでいるチームを観察すると、スキルや知識だけでなく「どの工程で・どんなインプットを渡せばAIが機能するか」という設計が体に染み込んでいます。これは情報共有だけでは伝わりません。型化の優先順位は「顧客価値に最も直結する工程」から決めています。 今期進める4つの取り組み 以下の4つの取り組みを通じて、全商材で高速かつ高品質な開発プロセスを再現性のある形で確立していきます。 ① AI駆動開発手法の標準化 設計・実装・レビュー・テストで、なるべくエンジニアの介入が要らないAI活用の「型」を統一します。成果が出ているチームの事例を収集済み。仕様駆動開発の型化が進行中。 ② 商材特性に応じた最適化 各工程でのAI駆動開発を磨き込み、より精度の高いAIワークフローを実現します。商材・技術特性に応じて使い方を順次アップデートしていきます。 ③ ナレッジの体系化・横展開 成功・失敗を含む実務レベルの知見をガイド化し、誰でもアクセス可能な形で集約します。キャッチアップの土台を整備し、勉強会支援や情報共有の場も整えていきます。 直近のハンズオン会アンケートでは、「他チームとの密接な情報共有がほしい」という声が50%に上り、事前に最多と予想されていた「技術的なトレーニングやワークショップが必要」と同数でした。知識を増やすことと同じくらい、「隣のチームが何をしているか」を知ることが求められています。 ④ AI活用の浸透度・生産性の可視化 「測れないものは改善できない」という考えから、AI活用の推進状況を可視化する仕組みを整備しました。開発・インフラ・QA・PdM・PDを対象に、各工程でのAI活用状況を定義した「AI活用実践カタログ」です。定性的な「なんとなく進んでいる」から、「ここが遅れている、だから次はこうする」という定量的な議論への転換を目指しています。 「エンジニア非稼働時間帯でも開発が進む」を目指して 一部のチームでは、エンジニアが設計に集中している間にAIが実装を進める状態が見えてきています。非稼働時間帯も開発が動く。そのゴールの射程が、ようやくリアルになってきました。 ただ正直に言うと、型が定まっていない領域はまだ多く、ナレッジの体系化も道半ばです。それでも「組織全体にどう行き渡らせるか」という問いに正面から向き合えるタイミングになってきた、と感じています。 この取り組みについて、もう少し詳しく聞いてみたいという方には、7月15日（水）開催のオンラインイベントの視聴をご検討ください。CTOや執行役員をはじめ複数のエンジニアが、複数プロダクト組織でのAIネイティブ化の実践をリアルに語る場です。無料・オンラインで参加できます。 「CTO登壇」RAKUS AI Conference 2026 Summer

はじめに 楽楽シリーズUI統一プロジェクトとは フェーズ1: AIに任せられない領域 フェーズ2: 規模がもたらした新たな課題 AI活用の勘所: 実装ルールをAIに翻訳する なぜ「セルフチェック」だったか Cursor Rulesという仕組み 運用してみての手応え 振り返って見えたパターン 作業の性質とAI活用の相性 AI活用は、人間の作業との連携で成立する おわりに はじめに こんにちは。楽楽販売の開発を担当しているn-chocolatteです。 「AIを活用しよう」とはよく言われますが、いざ自分の現場に当てはめようとすると、「結局、どの作業に使えばいいのか」で手が止まってしまう。そんな経験のある開発者の方は、少なくないのではないでしょうか。 先にお伝えしておくと、今回私たちがAIを使ったのは 実装そのものではなく、実装後のセルフチェック工程 でした。 なぜそこに使ったのか——その判断の過程を、日々の開発にAIをどう取り込むか模索している方のヒントになればと思い、共有します。 本記事でご紹介するのは、ラクスが掲げる「AIネイティブな開発組織」という方針のもと、楽楽販売開発チームが「楽楽シリーズUI統一プロジェクト」の中で実践したAI活用の一例です。 テーマは「 作業の性質を見極めて、AIの勘所を押さえる 」。 AIに任せられる作業と、人間が責任を持つべき作業を見極め、適切な領域にAIを投入する。 今回のプロジェクトは、そうした判断の積み重ねの記録でした。 楽楽シリーズUI統一プロジェクトとは 「楽楽シリーズUI統一プロジェクト」は、楽楽シリーズの全商材でデザインを統一する、シリーズ横断の大規模な取り組みです。 きっかけはお客様の体験でした。 楽楽精算など他商材をお使いのお客様が新たに楽楽販売を導入された際、見た目や操作感が全く違うと、それだけで戸惑いの原因になります。 同じシリーズなのにデザインがばらついていて使いづらい――この見えない障壁を取り払うのが目的です。 実装としては、各商材が共通のデザインシステムに準拠する形でUIを再構築していきました。 楽楽販売では、特有のコンポーネントが必要な場面はデザイナーと相談しながら詰めていきました。 プロジェクトはチームで分担し、複数のフェーズに分けて進めました。 フェーズ1とフェーズ2の二段階に分かれており、それぞれ性質の異なる画面群を対象にしています。 フェーズ1: AIに任せられない領域 フェーズ1の対象は一般ユーザ向け画面です。 お客様が日常的に操作する、楽楽販売の中心的な画面群です。 このフェーズでは、56画面を約1年かけて対応しました。 想定以上に時間がかかったのは、 対象の画面の作りが非常に複雑だった からです。 長年運用されてきた楽楽販売のコア画面は、既存のデザインやJavaScriptが複雑に絡み合っており、一つ手を入れると別の部分が壊れる(いわゆるデグレが発生する)リスクが常にありました。 UI統一とはいえ、見た目だけを揃えれば良いわけではなく、既存の挙動を維持しながら慎重に改修を進める必要があったのです。 このフェーズで、私たちはAIによる自動実装をほぼ使いませんでした。 理由は単純で、 自動化に任せると既存実装を壊すリスクが大きすぎたから です。 画面ごとに個々の微妙な事情があり、汎用的なルールで一律に変換できる作業ではありませんでした。 人間が一つひとつのコードを丁寧に読み解き、責任を持って実装する。それがフェーズ1で必要なことでした。 このフェーズで得たのは、「 AIに任せられない領域が確かにある 」という現場の体感でした。 この感覚が、次のフェーズでの判断に繋がっていきます。 フェーズ2: 規模がもたらした新たな課題 フェーズ2の対象は設定系画面です。 管理者設定やDB設定など、お客様の日常操作からは少し離れた位置にある画面群です。 フェーズ1とフェーズ2の実績を、下の表で対比してみます。 フェーズ1(一般ユーザ向け画面) フェーズ2(設定系画面) 画面数 56 350 開発期間 約1年 約半年 AI活用 なし Cursor Rulesによるセルフチェック 画面数が約6倍に増えたにもかかわらず、開発期間は半分に収まっている ——この点にご注目ください。 ただ、これはAI活用だけによる結果ではありません。 対象画面の性質や実装ルールの明確さといった要因が大きく、後述するAIの役割はそのうちの品質担保を支えた一要素にすぎません。 両フェーズの作業の性質の違いが、この差に表れています。 フェーズ1が、複雑な画面ゆえに何度も手戻りを繰り返す作業だったのに対し、フェーズ2は、設定系画面の比較的シンプルな作りに加え、明確な実装ルールがあったことで、基本的に一画面の対応を一度で完結させられました。 フェーズ1ほど手戻りが発生せず、安定したペースで進められたのです。 フェーズ2では進め方も変えました。 350画面を半年で完遂するため、 チームで手分けして大量の画面を並列に実装していく 形に切り替えたのです。 ここで生まれたのが、新たな課題でした。 大量の並列実装を、どうやって品質を担保しながら捌くか 。 実装そのものは機械的な作業なので、進めること自体は可能です。問題はその後のレビューでした。 350画面分のレビュー依頼が次々と上がってくる中で、レビュアーが毎回「アイコンが置換されているか」「不要なクラスが消えているか」「パンくず構造が揃っているか」を目視で確認していくのは、現実的ではありません。 一方で、レビューで本当に確認したいのは、 UI崩れが起きていないか、特殊ケースで挙動が壊れないか、ユーザ体験として問題ないか といった、人間の判断が必要な部分です。 ルール遵守の機械的なチェックに時間を取られ、肝心の「人間の判断が必要な部分」に目がいかない。 これが、作業規模の拡大によって向き合うことになった課題でした。 なお、フェーズ2の実装を機械的に行えるようにするため、私たちは事前にチーム内で詳細な実装ルールを整理していました。 「z-indexの削除」「特定のCSSクラスから別のクラスへの置換」「 <i class="fa ..."> 形式のアイコンから <span class="material-symbols-rounded"> 形式への置換」など、変換パターンが網羅的にドキュメント化されていたのです。 このドキュメントの存在が、次に紹介するAI活用の前提条件になりました。 AI活用の勘所: 実装ルールをAIに翻訳する なぜ「セルフチェック」だったか 私たちがAIを投入した先は、 実装そのものではなく、実装ルールに沿っているかのセルフチェック でした。 実装そのものをAIに任せる選択肢もありました。 ただ、フェーズ1で痛感したように、AIに任せると壊れる領域があります。 フェーズ2の画面は比較的シンプルとはいえ、リスクがゼロというわけではありません。 だからこそ、実装は引き続き人間が責任を持って行い、AIにはチェックを支援してもらう。 この役割分担が、フェーズ2の作業の性質に合っていた のです。 セルフチェックを支援する仕組みがあれば、実装者自身が手元で「ルールに沿っているか」を確認できます。 レビュー依頼が来る段階では、ルール遵守の観点でのチェックが一通り済んでいる状態になる。 レビュアーは、 人間でなければ判断できない部分 にレビューの労力を集中させられるようになります。 Cursor Rulesという仕組み 当時、楽楽販売開発チームではAIコードエディタとしてCursorを採用していました。 Cursorには「Rules」という機能があり、プロジェクトのルートディレクトリに特定の形式でルールファイルを置いておくと、AIが回答を生成する際にそのルールを常に参照してくれます。 このRules機能に、先ほどの実装ルールを記述しました。日本語で書かれた実装ルールを、AIが扱える形のルールファイルに整形する作業です。 完成したファイルは、変換パターンが before / after の具体例つきで章立てされたものでした。下記のような構造です。 ## 不要なアイコン要素の削除 - 不要なアイコンは削除しなければならない - サンプル - before: (元のHTML) - after: (修正後のHTML) 観点のカテゴリとしては、以下のようなものがありました(具体的なクラス名やタグ名は伏せています)。 不要な装飾要素の削除ルール アイコン体系の置換ルール パンくず構造の修正ルール メッセージ表示パターンの置換ルール ページネーション構造の置換ルール パネル構造の追加・調整ルール JavaScript関数名の置換ルール 実装者は改修作業を終えた後、AIに「このルールに沿っているか確認してください」と依頼します。 すると、変更されたコードがルールに照らしてチェックされ、不足や誤りがある箇所を指摘してくれます。 これがフェーズ2の運用の中核でした。 ここで「決まったルールに沿っているかの確認なら、LinterやFormatterのような静的解析ツールで十分では？」と思われるかもしれません。 実際、不要なクラスの削除のような単純な置換であれば、その通りです。 ただ今回のルールには、パンくずやパネルの構造変更、メッセージ表示パターンの置換など、 HTMLの文脈や画面全体の構成を踏まえないと正しく判定できない観点 が多く含まれていました。 「どの位置にどの要素を足すべきか」は画面ごとに事情が異なり、機械的なパターンマッチだけでは拾いきれません。 変更内容の意味を汲んで柔軟に判断してもらえる点が、LLMにチェックを任せた理由でした。 ちなみに、現在ではチームのメインツールはVSCode + Claude Codeに移っています。 ツールは流動的に変わっていきますが、 プロジェクト固有のルールをAIに与えるという考え方は、ツールが変わっても通用する普遍的なアプローチ だと感じています。 運用してみての手応え 正直に申し上げますと、このAI活用によって「具体的に〇時間短縮された」「レビュー工数が〇パーセント減った」といった定量データは、私たちの手元にはありません。 それでも、現場での体感としていくつかの手応えがありました。 ひとつは、 人間の目視という不確定要素が減ったこと です。 実装ルールが大量にあると、人間がレビューで全てを抜け漏れなくチェックするのは難しい。 AIによる事前チェックが入ることで、この見落としリスクが大きく下がりました。 実際、フェーズ2全体を通じて、手戻りは少なかったという体感があります。 そしてもうひとつ、 人間でなければ気づけないところに力を割けたこと です。 ルール遵守のチェックをAIに任せられた分、レビュアーである私たちは「この画面の使い勝手はこれで本当に良いのか」「特殊なケースで挙動が崩れないか」といった、人間の判断が必要な観点に集中できるようになりました。 結果として、350画面の改修を約半年で完遂できました。 これはAI活用だけによるものではなく、対象画面の性質や並列開発しやすい構造、事前のルール整備など複数の要因が重なった結果です。 物量だけ見れば、フェーズ1のペースのまま単純計算すると何年もかかる規模です。 AIにセルフチェックを任せ、人間が本質的なレビューに集中できる体制を作れたことが、この規模を半年で進める支えになりました。 正直に言えば、大量の画面をさばき続ける作業は、地道でなかなか骨が折れるものでした。 それでも、無事に完遂できたときの安堵と達成感は大きかったです！ 振り返って見えたパターン プロジェクトを終えてから振り返ると、いくつか一般化できそうな学びが見えてきました。 作業の性質とAI活用の相性 フェーズ1とフェーズ2の対比からは、 作業の性質によってAIの勘所が変わる ことがはっきり見えました。 複雑で固有性が高い作業は人間が向き合う方が結果的に効率が良く、機械的でルール化でき量も多い作業はAI支援の効果が出やすい。 ただ、この見極めは机上では難しく、 現場で手を動かして得られる感覚 だと思います。 フェーズ1で複雑な画面と格闘したからこそ、フェーズ2でAIを投入する判断ができたのです。 AI活用は、人間の作業との連携で成立する もう一つ、振り返って気づいたことがあります。 「AI活用」は単独のアクションではなく、人間の作業と組み合わさったワークフロー全体である 、ということです。 今回のプロジェクトを工程ごとに分解してみると、こうなります。 実装ルールを決める(人間の作業) ルールをAIが扱える形に翻訳する(人間の作業) AIによるセルフチェック実行(AIの作業) 人間でなければ気づけない部分に集中してレビュー(人間の作業) このうち、純粋に「AIの仕事」と呼べるのは3だけです。それ以外は全て人間が行っています。 それでも、3を組み込むことで全体の効率と品質が大きく変わる。 特に2の「翻訳作業」は肝になる工程でした。AIが解釈しやすい構造に整え、具体例を添え、抜け漏れなく記述する。 今回うまくいったのは、AIが優秀だったからではなく、AIが判断できる形までルールを整えたから だと感じています。 少なくとも今回のケースでは、成否を分けたのはモデルの性能そのものよりも、「AIに何を、どう渡すか」という設計の方でした。 渡す側でどれだけ作り込めるかは、これからのAI活用でも軽視できないポイントだと思います。 そう考えると、今回行ったことは「AIに仕事を任せた」というより、 AIが得意な領域へ仕事を再分配した 、と言うのが近い気がします。 大量のルールを機械的に適用していくところはAIへ。 ルールを定義すること、ルール化できない例外を判断すること、最終的な品質に責任を持つことは、引き続き人間へ。 私たちがAIに任せたのは「セルフチェック」だった——その一点に、この再分配の線引きが表れています。 おわりに 楽楽販売開発チームが楽楽シリーズUI統一プロジェクトで実践したAI活用について、なるべく等身大にお伝えしてきました。 派手な成果や劇的なBefore/Afterはない記事だったかもしれません。 それでも、こうした地に足のついた判断の積み重ねこそが、AIネイティブな開発組織の実像なのだと思っています。 ツールはこれからも変わっていくでしょうが、 AIをどこに使うかを考え続けること 、その姿勢は変わらないはずです。 本記事が、同じように現場でAIと向き合う開発者の方々の参考になれば嬉しいです。 最後までお読みいただき、ありがとうございました。

はじめに 登壇資料 登壇内容 発表の背景 なぜ全部自動化しなかったのか 作成したCLIの概要 半自動設計のポイント 細かいTips LLMに渡す範囲を狭くする 読み取りを自作ツールで行う ツールを絞る Claude Code標準プロンプトは必要な場所だけ使う 登壇してみて まとめ はじめに こんにちは！ エンジニア４年目のTKDです！ 今回は、2026年5月12日に開催されたClaude Code Meetup Japan #5で「Claude Agent SDKを活用した脆弱性調査自動化」というタイトルで登壇してきたので、その内容を紹介します。 この記事は、LLMを使った業務効率化に興味がある方や、セキュリティ運用の自動化で悩んでいる方に向けた記事です。 今回の発表では、脆弱性調査において、調査やレポート作成をLLMに任せる半自動化について話しました。 このようなLLMを利用した取り組みで、定常業務に割く工数を減らすことで、より本質的な課題に取り組める時間を増やし迅速にプロダクトの価値を顧客に届ける状態を目指しました。 登壇資料 登壇資料はこちらです。 Claude Agent SDKによる脆弱性調査 by @7328957 登壇内容 今回の発表では、Claude Agent SDKを使って脆弱性調査を半自動化した取り組みについて紹介しました。 主に以下の内容について話しました。 手作業で行っていた脆弱性棚卸しの流れ Claude Agent SDKを使ったCLIの構成 半自動化するときの判断ポイント LLMを安全かつ安く扱うためのTips 先に結論を述べると、AIに全部任せなくても十分役に立つという話です。 APIの制約や安全性から面倒で曖昧な調査をAIに任せ、管理ツールへの最終記入や判断は人間側に残す形にしました。 発表の背景 普段の脆弱性棚卸しでは、いろいろなツールや画面を行き来する必要がありました。 手作業では、ざっくり以下のような流れになります。 yamoryからSlackに脆弱性通知が届く yamoryをブラウザで開いて未対応項目の詳細を確認する エディタとClaude Codeで対象コードベースで使っているか調べる 影響と対応方針を考える GitHub Discussionsに脆弱性詳細や影響調査内容を書き、対象サービスのラベルを付ける yamoryに調査内容、対応期限、対応方針を書いてステータスを変更する 毎回同じような確認も多いですが、逐一調査対象のコードや外部情報も見に行く必要があります。 そこで、調査と調査レポート作成の部分をClaude Agent SDKで自動化できないか試しました。 なぜ全部自動化しなかったのか 今回は、検知から投稿までをすべて自動化するのではなく、CLIで実行できる半自動の形にしました。 理由は主に以下です。 脆弱性自体の危険度はyamoryのSlack通知で確認できる 緊急対応か定常業務内での対応かは、人間が一目で振り分けられる yamoryのAPIがReadのみで、Writeに対応していない 担当者のローカル実行にすることで、Claudeのサブスクプランを使える 個人的には、こういった対応を間違えるとまずい業務では、いきなりE2Eの全自動を目指さなくてもよいと思っています。 今回はAPIの制約や安全性を総合的に考えて半自動にしました。 実際の感じからも、手動実行できるCLIレベルでも十分便利でした。 作成したCLIの概要 今回作成したCLIでは、ざっくり以下の流れで処理しています。 yamory APIから、期間やステータスで絞り込んだ脆弱性一覧を取得する 既存のGitHub Discussionsタイトルを確認する CREATE / COMMENT / SKIP の処理判定を行う Claude Agent SDKでコード調査、草案作成、ラベル付けを行う 調査結果とyamory記入例をGitHub Discussionsへ投稿する 必要に応じてSlackに通知する このCLIによって、体感では1件あたり5分から10分ほどかかっていた作業が、 バックグラウンド処理込みで体感約2分程度で進められるようになりました。 半自動設計のポイント 今回意識したのは、決定論的に処理できる部分と、LLMに任せる部分を分けることです。 コードで記述している部分は以下です。 yamoryからの一覧取得、検索、詳細取得 既存Discussion検索によるCREATE / COMMENT / SKIP判定 安全性ガードレール GitHub Discussionsへの投稿 一方で、LLMが担当している部分は以下です。 CVE、PoC、修正済みバージョンなどの外部情報調査 現環境での悪用可能性や影響評価 推奨対応方針の下書き Discussionへのラベル付け 判断材料を集めるところはAIに寄せつつ、判断を間違えると危険な部分は人間が確認するようにしました。 この線引きをしておくと、他のLLMを必要とする業務にも応用しやすいと思います。 細かいTips LLMに渡す範囲を狭くする まず、LLMに何でも渡さないようにしました。 期間や状態の絞り込み、重複判定、冪等性、共有ON/OFFのような部分はコードで固定しています。 LLMには、利用状況の調査、影響評価の下書き、推奨対応方針の下書き、記入例の作成を任せました。 これにより、お得で安全にLLMを扱いやすくなります。 読み取りを自作ツールで行う 次に、対象リポジトリの読み取りは自作ツールで行うようにしました。 自作ツールでは、read onlyにしたうえで、ファイルサイズ、拡張子、ファイルパスを解析的に検査しています。 repo外のファイル、secret、巨大ファイル、バイナリなどを拒否することで、安全性を確保しています。 Claude Agent SDKでは、 @tool アノテーションでツール化できるので、このあたりも実装しやすかったです。 ツールを絞る Claude Agentに渡すツールも絞りました。 脆弱性調査では、WebSearchと読み取り専用のrepo検索、repoファイル読み取りツールだけを許可しています。 読み取りを自作ツール以外からできないようにすることで、意図しないアクセスを防ぎやすくしました。 Claude Code標準プロンプトは必要な場所だけ使う Claude Codeの標準プロンプトは、コード探索のようにClaude Codeのハーネスとしての強みがほしい場所だけで使いました。 たとえば、脆弱性調査ではClaude Code標準プロンプトに脆弱性調査用の追加指示を加えています。 一方で、GitHubのラベル付けのような小さい判定では、候補ラベルから選ぶ小さな構造化タスクとしてAgentを分けました。 広い調査と小さい判定でAgentを分けるのは、個人的に扱いやすい設計だと思っています。 登壇してみて 今回登壇してみて、想像以上に多くの方の前で発表することになり非常に緊張する発表でした！ また、作るときは壁打ちや制約で自然に半自動になったのですが、発表資料を作る中で、全自動化を目指すのではなく、人間とコードとLLMで役割を分けることの重要性を改めて考える機会になりました。 まとめ 今回は、Claude Code Meetup Japan #5で「Claude Agent SDKを活用した脆弱性調査自動化」について登壇した内容を紹介しました。 今回紹介した流れは、脆弱性調査以外にも使えると思っています。 明日から使えるポイントとしては、以下の3つです。 無理にE2Eの全自動にせず、半自動を狙う LLMが得意とする情報集めや例文作成をメインに使う 最終記入、冪等性、確認導線は人間とコードで設計する 興味がある方は、ぜひ参考にしてみてください！ ここまで読んでいただきありがとうございました！

はじめに JJUG CCCとは 登壇スライド 外部発信のモチベーション 登壇を通じて得られた気付き 振り返り はじめに 登壇直前に地元バスケクラブが準優勝し、かなりのダメージを負っていた楽楽債権管理チームの冨澤です。 2026年5月30日に行われたJJUG CCC 2026 Springで初登壇してきました。 本記事は、そのレポートとなります。 JJUG CCCとは JJUG CCCは、日本最大のJavaコミュニティイベントです。 日本Javaユーザグループ（JJUG） / Japan Java User Group (JJUG) が主催しており、今回は春に開催されたカンファレンスです。 （秋にもあります！2026年11月28日開催予定） ccc2026spring.java-users.jp 登壇スライド speakerdeck.com 外部発信のモチベーション なぜCIを速くしたいかは登壇スライドに書いているので、なぜ外部発信をしたのかについて少し書いておこうと思います。 1つ目は、取り組みを始めた当時、自分が調べた範囲ではJava関連プロダクトのCI時間削減の記事が少なかったからです。 RailsやGo、フロントエンド関連のCI時間削減の記事は多かったのですが、Java関連の記事はあまり見つかりませんでした。 そのため、成功でも失敗でも何かしら貢献ができるのではないかと考え、最初の取り組みを以下のテックブログに書きました。 tech-blog.rakus.co.jp ちなみにこのやり方は、Goのテスト実行における「パッケージ単位で実行を分け、パッケージ内のテストは必要に応じて t.Parallel() で並列化する」という考え方から着想を得ました。 2つ目は、外部からのフィードバックを得たかったからです。 これは今回JJUG CCCに登壇したかった理由でもあります。発表後や懇親会の場で社外の方とお話しする中で、新しいフィードバックや気付きを得られたらよいなと考えていました。 こうした機会は自分から動かないと得られないと思い、CfPを提出しました。 また、上記のテックブログの内容からさらに改善を行ったので、その取り組みも紹介したいと考えていました。 登壇を通じて得られた気付き 何名かの方とお話しする中で、共通して話題に挙がったのが「PRごとに毎回すべての単体テストを実行しているのか？」という点でした。 これは本当におっしゃるとおりで、今回の取り組みでCI時間を約50％削減できたものの、それでもまだテスト実行に約10分かかっています。 デグレの早期検知や安心材料としてすべての単体テストを実行しているのか、もっと速くできないか、すべて実行する必要は本当にあるのか。そうした会話を通じて、「そもそも何のためにこれをやっているのか？」という重要な問いに何度か立ち返ることができました。 自分たちのプロダクトにとって本当に大事なことは何か。逆に、何をトレードオフとして選ばないのか、あるいは優先度を下げられるのか。そうした視点の重要性に改めて気付くことができました。 例えば、より速くPRをマージしたいのであれば、変更の影響範囲に絞ってテストを実行し、夜間にすべてのテストを実行するという選択肢があります。逆に、速さよりもデグレの早期検知を重視するのであれば、毎回のPRですべてのテストを実行する判断になるかもしれません。 目の前の作業だけに没頭するのではなく、時折立ち止まって目的を見直す姿勢が大事なのだと改めて感じました。 振り返り CfP採択の結果連絡が来た時は、非常に嬉しかったです。 採択されたことが信じられず、社内の方にも本当に採択されたのか確認を取ったほどでした。 登壇直前までかなりバタバタしており、とても緊張していましたが、何名かの同僚が来てくれており非常に心強かったです。 登壇直後、次に発表される方からの質問や廊下での立ち話、懇親会での会話など、様々な場面で社外の方と交流することができました。「E2EやAPIテストなど他のテストとの役割分担はどうしてる？」「コーディングエージェントにテストをうまく書かせる工夫は？」「開発組織で取り組んでいる工夫は？」など、話題は多岐にわたり、どれもとても楽しい時間でした。 当初の想定どおり、たくさんの方と交流でき、そこで得たものを今後の業務に活かしていきたいと思います。 今後もこうした登壇の機会があれば、ぜひ続けていきたいです。 登壇者・参加者・企画・運営の皆さま、素敵な場をつくっていただき本当にありがとうございました！

はじめに 給与計算オプションの開発で最初に困ったこと なぜ開発部だけでなく事業部にも給与計算の知識が必要だったのか まず、初心者向けの課題図書を選んだ MVP開発に必要な知識に絞って、学習コンテンツを作った 仕様説明では、「なぜその機能が必要なのか」まで説明した リリースまで進めるうえで大事だったこと 1. 自分だけが詳しい状態にしない 2. 開発部・事業部が必要な知識を持てるようにする 3. すべてを学ぶのではなく、今回必要な範囲に絞る 4. 仕様の背景や目的まで伝える まとめ はじめに 楽楽勤怠のプロダクトマネジメントをしている @k0First です。 2026年4月に、楽楽勤怠から給与計算オプションをリリースしました。 www.rakus.co.jp 給与計算オプションの開発で難しかったことの一つが、給与計算というドメインの理解でした。 私は前職で給与計算システムの開発経験があり、一定のドメイン知識を持っていました。 一方で、今回の開発では、自分以外の開発部・事業部メンバーの多くが、給与計算の知識をほとんど持っていない状態からのスタートでした。 給与計算は、勤怠データや賃金規定、各種手当、控除、割増計算、端数処理など、さまざまな要素が絡み合う複雑なドメインです。 しかも、最終的に扱うのは「給与」です。 「だいたい合っていそう」では済まされません。 PdM/POである自分だけが理解していればよい、というものではありませんでした。 開発部が仕様の背景を理解して設計・実装できること。 事業部がリリースに向けた説明やマニュアル作成を進められること。 そのためには、関係者がそれぞれの役割に必要な範囲で、給与計算を理解している必要がありました。 給与計算オプションは、2025年7月に開発を開始し、2026年4月にリリースしました。 この期間でリリースまで進められた理由の一つは、早い段階から開発部・事業部のドメイン知識を底上げし、関係者が自分の役割の中で判断しやすい状態を作れたことだと思っています。 この記事では、給与計算を知らないメンバーと給与計算オプションをリリースするために、どのようにドメイン知識を身につけてもらったのかを書いていきます。 給与計算オプションの開発で最初に困ったこと 給与計算オプションの開発で最初にぶつかった壁は、給与計算というドメインそのものの難しさです。 給与計算は、単に勤怠時間を集計して金額を出せば終わり、というものではありません。 会社ごとの賃金規定に基づいて、基本給、各種手当、控除、割増賃金、端数処理などを組み合わせて計算します。 さらに、会社によってルールや運用が異なります。 ある会社では当たり前の計算方法が、別の会社ではまったく違う。 そんなことも普通に起こります。 つまり、給与計算オプションを作るには、画面や機能の仕様を理解するだけでは足りません。 その裏側にある業務や、 「なぜその計算が必要なのか」 まで理解する必要があります。 私は前職で給与計算システムの開発経験があったため、ある程度の前提知識を持っていました。 しかし、自分以外の開発部・事業部メンバーは、給与計算の知識がほとんどない状態です。 このまま開発を進めると、何が起きるか。 開発部からは、こんな確認が出てきます。 この項目はなぜ必要なのか この計算ルールはどの業務に使われるのか この仕様で、どこまでのケースに対応できるのか こうした質問に答えること自体は、PdM/POの大事な役割です。 ただ、すべての確認や判断が自分に集まる状態になると、開発のスピードが落ちてしまいます。 さらに、リリースに向けた説明やマニュアル作成を進めるときにも、毎回自分が説明しないと前に進まない状態になってしまいます。 ここで最初に考えたのは、 「自分がもっと詳しく説明できるようにしよう」 ではありませんでした。 それよりも、 みんなが自分の役割に必要な範囲で、給与計算を理解できる状態を作らないといけない ということでした。 給与計算オプションをリリースまで進めるためには、自分だけが詳しい状態から抜け出す必要がありました。 なぜ開発部だけでなく事業部にも給与計算の知識が必要だったのか 最初は、開発部のメンバーに給与計算の知識を身につけてもらうことが重要だと考えていました。 開発部が仕様の背景を理解していないと、設計や実装の判断が難しくなります。 例えば、以下のような判断です。 ある計算ルールをどう表現するか どこまで設定で変更できるようにするか どのような条件でエラーを返すべきか こうした判断は、仕様書に書かれている内容だけでは決めきれません。 給与計算の業務背景を理解しているからこそ、判断できることがあります。 ただ、開発を進める中で気づきました。 「あれ、これは開発部だけの話じゃないぞ・・・？」 今回の開発では、事業部もリリースに向けて重要な役割を担っていました。 例えば、マニュアル作成です。 操作手順だけを書けばよいなら、画面を見ればある程度進められるかもしれません。 でも実際には、それだけでは足りません。 なぜこの設定が必要なのか この項目を設定すると、どの計算に影響するのか お客様はどの場面でこの機能を使うのか こうした背景がわからないと、マニュアルの説明も薄くなってしまいます。 お客様にリリース内容を説明する場合も同じです。 今回の給与計算オプションで何ができるのか。 どのような業務を支援する機能なのか。 どこまでが対象で、どこから先は対象外なのか。 これらを説明するには、事業部側にも給与計算の基本的な理解が必要でした。 つまり、給与計算オプションをリリースするには、開発部だけでなく事業部にもドメイン知識が必要だったのです。 開発部が実装を進める。 事業部がお客様に向けた説明やマニュアルを準備する。 そして、リリースに向けてそれぞれの立場で判断していく。 その流れを止めないためには、関係者がそれぞれの役割に必要な範囲で、給与計算を理解している必要がありました。 まず、初心者向けの課題図書を選んだ 最初に取り組んだのは、初心者向けの課題図書を選ぶことです。 給与計算について学べる本はたくさんあります。 ただ、実際に探してみるとけっこう大変でした。 専門的すぎる本もあります。 法律や制度の説明が中心の本もあります。 実務担当者向けに、かなり細かい手続きまで書かれている本もあります。 もちろん、どれも重要な知識です。 ただ、今回の目的は、開発部・事業部のメンバーを給与計算の専門家にすることではありません。 必要だったのは、給与計算の基本的な考え方を理解し、仕様やリリース内容を理解できるようになることです。 そこで、本屋や図書館に行き、実際に本を手に取って選びました。 このとき見ていたポイントは、主に次のようなものです。 給与計算の全体像がつかみやすいか 初心者でも読み進めやすいか 専門用語が多すぎないか 実務の流れをイメージしやすいか 開発部・事業部のどちらが読んでも役立ちそうか いくつか本を見比べながら、「最初に読むならこれがよさそうだな」という本を選びました。 ここは、思った以上に大事な工程でした。 最初に触れる情報が難しすぎると、 「給与計算ってよくわからない」「自分には関係なさそう」 と感じてしまいます。 逆に、最初の一冊で全体像がつかめると、その後の仕様説明や議論がかなり進めやすくなります。 選んだ本は、開発部・事業部共通の課題図書として指定し、事前に読んでもらいました。 ただ、いきなり課題図書を読んでもらうだけでは、少しハードルが高いとも感じていました。 給与計算をまったく知らない状態だと、本を読み始めても、最初の用語や業務の流れでつまずく可能性があります。 そこで、超初心者向けに 給与計算の超概略資料 も作成しました。 この資料では、細かい制度や計算方法には踏み込みすぎず、まずは以下のような全体像をつかめるようにしました。 給与計算とは何をする業務なのか 勤怠情報と給与計算がどうつながるのか 支給、控除、割増といった基本的な考え方 賃金規定が給与計算にどう関係するのか まずは概略資料でざっくり全体像をつかむ。 そのうえで課題図書を読む。 この流れにすることで、学習のハードルを下げることを意識しました。 課題図書を共通にしたのは、全員に同じレベルの知識を求めたかったからではありません。 まずは、 「給与計算ってこういうものなんだ」 という感覚を持ってもらいたかったからです。 例えば、「賃金規定」「割増賃金」「控除」「支給項目」といった言葉を聞いたときに、まったくイメージが湧かない状態と、なんとなくでも意味がわかる状態では、その後の理解度が大きく変わります。 まずは、給与計算の世界に入るための入口を作る。 課題図書と超概略資料には、そんな役割を持たせていました。 MVP開発に必要な知識に絞って、学習コンテンツを作った 課題図書を読んでもらうことで、給与計算の基本的な考え方に触れてもらうことはできました。 ただ、 一度読んだだけで身につくものでもありません。 給与計算の範囲はとても広いです。 全部をちゃんと学ぼうとすると、本当に終わりが見えません。 一方で、開発は前に進めなければなりません。 全員が給与計算のすべてを理解するまで待っていたら、開発速度が落ちてしまいます。 そこで考えたのが、 今回のMVP開発に本当に必要な知識を、まず最初に身につけてもらう ということでした。 必要だったのは、給与計算のすべてを理解してもらうことではありません。 給与計算オプションのMVP開発に必要な知識 仕様を理解し、判断するために必要な知識 リリースに向けた説明やマニュアル作成に必要な知識 この範囲に絞って、学習コンテンツを作成しました。 ここで大事にした狙いは、主に2つあります。 1つ目は、 本当に必要な知識から先に身につけてもらうこと です。 給与計算の知識をすべて網羅しようとすると、どうしても時間がかかります。 もちろん深い理解は大事ですが、今回まず必要だったのは、開発やリリース準備を進めるための最低限の理解でした。 そのため、MVP開発に関係する内容を中心に整理し、優先的に学べるようにしました。 2つ目は、 本を読むだけではなく、別の形で復習できるようにすること です。 本を読んだだけだと、どうしても理解が曖昧なまま残る部分があります。 一度読んで「わかった気がする」と思っても、仕様説明や実際の議論の場になると、うまく結びつかないこともあります。 そこで、読むだけではなく、聞いたり、確認したりできる形にすることで、理解度を高められるようにしました。 この学習コンテンツ作成に活用したのが、Google NotebookLMです。 具体的には、自分で整理した内容や、業務上扱える情報をもとに、音声解説や理解度確認テストの作成に活用しました。 Google NotebookLMを使ってよかったのは、知識を 「読むもの」だけでなく、「聞けるもの」「確認できるもの」 に変えられたことです。 音声解説では、給与計算の基本的な考え方や、今回の給与計算オプションで扱う範囲について、初心者でも理解しやすいように説明をチューニングしました。 理解度確認テストでは、ただ読んだり聞いたりするだけではなく、自分がどこまで理解できているかを確認できるようにしました。 ここで特に気をつけたのは、説明の粒度です。 給与計算に詳しい人向けなら、専門用語を使えば短く説明できます。 でも、今回の対象は給与計算をほとんど知らないメンバーです。 いきなり専門用語から入ると、そこで止まってしまいます。 そのため、 なぜその考え方が必要なのか どんな業務に関係するのか 今回の仕様ではどこに関わるのか という流れで理解できるようにしました。 また、あえて説明しすぎないことも意識しました。 給与計算のすべてを詰め込むと、情報量が多すぎて、かえって大事なことが見えにくくなります。 今回は、MVP開発に必要な知識に絞る。 その範囲ではしっかり理解できるようにする。 この割り切りが、かなり重要だったと思います。 「給与計算を全部学ぶ」のではなく、「今回の開発を前に進めるために必要な知識を身につける」。 この目的をはっきりさせたことで、学習コンテンツの方向性も定まりました。 仕様説明では、「なぜその機能が必要なのか」まで説明した ドメイン知識を身につけてもらう取り組みと並行して、仕様説明のやり方も変えました。 給与計算オプションの仕様は、画面や機能だけを見るとかなり複雑です。 入力項目も多く、設定する内容も多岐にわたります。 そのため、「この画面ではこの項目を設定します」という説明だけでは、なかなか理解しきれません。 むしろ大事なのは、その先です。 なぜこの画面が必要なのか なぜこの設定項目が必要なのか この機能は、どの給与計算業務を支えるものなのか MVPではどこまで対応し、どこから先は対象外にするのか ここまで説明して、ようやく仕様が立体的に見えてきます。 例えば、ある設定項目を説明するときも、単に「ここに値を入力します」とは言いません。 この項目は、こういう賃金規定を表現するために必要です この設定によって、この計算結果が変わります 今回のMVPでは、まずこの範囲に対応します というように、業務上の意味や判断の背景をセットで伝えるようにしました。 すると、少しずつ会話の質が変わっていきました。 単なる仕様確認だけではなく、 このケースも考慮したほうがよさそう この表現だと、お客様には伝わりにくいかも ここはMVPでは割り切ってもよさそう といった会話が出るようになってきました。 これは、とても大きな変化でした。 自分が一方的に説明し続けるのではなく、開発部・事業部がそれぞれの視点で考え、判断しようとしてくれる。 その状態に近づいていったことで、開発もリリース準備も進めやすくなりました。 仕様を伝えるだけでは足りません。 特に複雑なドメインでは、 「なぜその仕様なのか」 まで伝えることが大事だと改めて感じました。 リリースまで進めるうえで大事だったこと 今回の開発を振り返ると、リリースまで進めるうえで大事だったことは、大きく4つあります。 1. 自分だけが詳しい状態にしない PdM/POがドメイン知識を持っていることは重要です。 ただ、それだけでは開発は進みません。 特に給与計算のような複雑なドメインでは、開発部・事業部がそれぞれの役割の中で判断できる状態を作る必要があります。 2. 開発部・事業部が必要な知識を持てるようにする 開発部には、仕様の背景を理解したうえで設計・実装するための知識が必要です。 事業部には、顧客説明やマニュアル作成を進めるための知識が必要です。 役割は違っても、リリースに向かううえで必要な知識は重なります。 3. すべてを学ぶのではなく、今回必要な範囲に絞る 給与計算の知識は本当に広いです。 全部理解してから進めようとすると、かなり時間がかかります。 だからこそ、今回のMVP開発に必要な知識に絞りました。 概略資料で全体像をつかみ、課題図書で基本を押さえ、学習コンテンツで今回必要な知識を補う。 この進め方は、現実的で効果的だったと思います。 4. 仕様の背景や目的まで伝える 仕様書や画面だけでは、なぜその機能が必要なのかまでは伝わりにくいです。 その機能がどの業務課題を解決するのか。 なぜその項目が必要なのか。 どこまでをMVPで扱うのか。 こうした背景や目的を説明することで、関係者が自分の役割の中で判断しやすくなります。 振り返ると、今回の開発では「仕様を作ること」だけでなく、 「理解できる状態を作ること」 にかなり時間を使いました。 最初は遠回りに見えるかもしれません。 でも、複雑なドメインでは、この遠回りが結果的に近道になることがあります。 関係者が理解し、自分の役割で判断できるようになると、開発やリリース準備が止まりにくくなるからです。 まとめ 給与計算オプションの開発では、給与計算という複雑なドメインに向き合う必要がありました。 今回あらためて感じたのは、複雑な業務ドメインのプロダクト開発では、PdM/POが詳しいだけでは不十分だということです。 開発部が仕様の背景を理解して設計・実装できること。 事業部がリリースに向けた説明やマニュアル作成を進められること。 そのためには、それぞれの役割に必要な範囲で、ドメイン知識を身につけてもらう必要があります。 課題図書、超概略資料、学習コンテンツ、Google NotebookLMを使った音声解説や理解度確認テストなど、やったことはいくつかあります。 ただ、一番大事だったのは、 自分の中にある知識を、関係者が理解しやすい形に変えて届けること だったと思います。 2025年7月に開発を開始し、2026年4月にリリースまで進められた背景には、こうした取り組みによって、開発部・事業部がそれぞれの役割で動きやすくなったことがありました。 何を作るかを考えることと同じくらい、誰がどこまで理解している状態を作るかも大事。 今回の開発を通じて、そんなことを強く感じました。

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） 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