自己紹介 ラクスでPdMをしております。 @keeeey_m と申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存)を担当しており、個人としては楽楽精算×AIの担当、 楽楽明細・楽楽電子保存PdMチームのリーダーをしております。 こんな方におすすめ プロダクトマネージャーとして孤独感を感じている方 プロダクトマネージャーをマネジメントする立場の方 プロダクトマネージャーを目指している方 組織開発やチームマネジメントに携わる方 目次 はじめに：PdMの孤独という普遍的な課題 PdMが感じる孤独の本質 孤独と向き合う：個人としてのアプローチ 組織として何ができるか まとめ：孤独と健全に向き合う「場」を作る はじめに：PdMの孤独という普遍的な課題 先日、メンバーからのとある声を知り、プロダクトマネージャー（PdM）の孤独について深く考える機会がありました。この投稿は、私自身の経験とも重なり、多くのPdMが感じている普遍的な課題ではないかと感じました。 PdMという役割に就く人が感じる孤独感は、単なる職場での寂しさとは質が異なります。それは、役割の本質に根ざした、より深い次元の孤独です。 PdMが感じる孤独の本質 組織における立ち位置の特殊性 PdMは開発チーム、デザインチーム、マーケティング、営業、経営陣など様々なステークホルダーの間に立つ「ハブ」的な役割を担います。しかし、どの部門にも完全には属さないため、帰属意識を感じにくく、自分の居場所を見つけるのに苦労することがあります。 意思決定の重圧と責任 PdMは製品の方向性や優先順位等について重要な判断を下す必要があります。会社や製品のフェーズによってPdMの役割は異なったりするものの、PdMが下すその決定は往々にして誰かを失望させたり、トレードオフを伴います。最終的な責任を負う立場にいながら、直接的な権限は限られているというジレンマも抱えています。 解像度の格差による孤独 プロダクトマネジメント、プロジェクトマネジメント、さらに開発の設計部分まで理解できるPdMは、誰よりも早く問題や危機感を察知します。しかし、その複合的な視点から見えてくる問題を、特定の専門領域に特化した視点を持つ人に理解してもらうのは困難です。 孤独と向き合う：個人としてのアプローチ 孤独を力に変える この孤独感は必ずしも解決すべき問題ではないと、私は考えています。なぜなら、それは責任ある意思決定の証でもあるからです。重要な決断を下す時、最終的には一人で判断し、その結果に責任を持つ必要があります。他人の意見に左右されず、データと自分の信念に基づいて決断する瞬間には、必然的に孤独感が伴います。これは逃げられない、そして価値のある経験です。 客観性を保つための距離感 あらゆるステークホルダーと適度な距離を保つことで、どこかの部門に偏った判断をすることなく、プロダクト全体の最適化を図ることができます。この「中立的な立場」は、時として孤独を感じさせますが、PdMの重要な強みでもあります。 組織として何ができるか とはいえ、プロダクトマネジメント組織を率いるリーダーとして、適切なサポート体制を整える必要があると考えています。 実際に効果があったこと、試行錯誤しながら取り組んでいることです。 複数名体制による物理的・精神的な負荷の分散 私の経験では、PdMを複数名体制にすることで、孤独問題が大きく解消されました。同じ立場・役割で協業できるメンバーがいることで、物理的にも精神的にも負荷が下がります。特に、意思決定の重圧を共有できることは、大きな安心感につながります。 早期発見と迅速なサポート 過去の失敗経験から、メンバーが一人で問題を抱え込んでしまう前に、早期に気づき、サポートすることが重要だと学びました。 定期的な1on1ミーティングでの状況確認 普段の会話の中での変化の察知 「できない」という現状の言語化を促す 段階的なアプローチ 組織として以下のような段階的なアプローチを実践しています。 こまめな壁打ちの時間の確保 共感と理解を示すコミュニケーション メンバーからのアクションベースでの対応（マイクロマネジメントを避ける） 外部イベントのレポート共有など、情報共有の機会創出 実践的なアドバイス これらの取り組みを実施する上で、以下の点に注意しています。 過度な介入を避け、メンバーの主体性を尊重する 問題の早期発見のための観察力を磨く 共感を示しつつも、具体的な解決策を提示する 組織の規模や状況に応じて、柔軟にアプローチを調整する まとめ：孤独と健全に向き合う「場」を作る 私自身もPdMとして、複数の視点から同時に物事を見ることで生まれる内的葛藤や、解像度の高さゆえの孤独を経験してきました。その中で、理解を示してくれる人が一人でもいることの大切さも痛感しました。 だからこそ、組織としては孤独そのものを「悪」として排除しようとするのではなく、孤独と健全に向き合える場を用意することが重要だと考えています。これは単なる愚痴の吐き出し場ではなく、孤独感の意味を理解し、それを力に変えていくためのスペースです。 PdMという役割の本質を理解した上で、孤独を完全に取り除こうとするのではなく、それと健全に共存する方法を組織として支援する。これこそが、真にPdMを理解したリーダーのアプローチだと考えています。 PdMが「一人で戦っている」のではなく「組織に支えられながら、時には一人で決断する」という状態を作り出すこと。それが、プロダクトマネジメント組織のリーダーとして目指していることです。

はじめに こんにちは！ エンジニア３年目のTKDSです！ 今回はメタデータ管理をPostgresqlやMySQLなどのSQLデータベースが担う新しいOSSのLakehouseフォーマット、Ducklakeについて試してみました！ 今回はPostgresql+s3(minio)+DuckDBで構築してます。 はじめに Ducklakeの概要 準備 1. composeでPostgresqlとminioを起動 2. minioでバケットを作成する 3. DuckDB側の準備と起動 試す まとめ Ducklakeの概要 Ducklakeは公式HPの一文によるとSQLデータベースをカタログ置き場に、データをparquetファイルに保存する形式のLakehouseフォーマットだそうです。 DuckLake delivers advanced data lake features without traditional lakehouse complexity by using Parquet files and your SQL database. It's an open, standalone format from the DuckDB team. （Google翻訳） DuckLakeは、ParquetファイルとSQLデータベースを使用することで、従来のレイクハウスの複雑さを排除しながら、高度なデータレイク機能を提供します。DuckDBチームが提供するオープンなスタンドアロンフォーマットです。 簡単にLakehouseを使えると解釈しておきましょう！ では早速準備して使っていきます。 準備 今回、Postgresqlとminioをcomposeで建て、それぞれカタログ置き場、データ置き場として使います。 環境構築後、DuckDB CLIからクエリを打って操作していく形です 。 1. composeでPostgresqlとminioを起動 まず.envファイルにパスワード等を記載しておいてください。 Minioのパスワードは短いと以下のエラーでコンテナ起動できないので注意。 MINIO_ROOT_USER length should be at least 3, and MINIO_ROOT_PASSWORD length at least 8 characters MINIO_ROOT_USER=root-minio MINIO_ROOT_PASSWORD=root-minio POSTGRES_USER=postgres POSTGRES_PASSWORD=postgres POSTGRES_DB=postgres ディレクトリを作っておきます。 mkdir ./data/minio mkdir ./data/postgres 以下の内容でcomposeファイルを書きます。 services : minio : image : quay.io/minio/minio:RELEASE.2025-05-24T17-08-30Z container_name : minio command : server /data --console-address ":9001" environment : MINIO_ROOT_USER : ${MINIO_ROOT_USER} MINIO_ROOT_PASSWORD : ${MINIO_ROOT_PASSWORD} volumes : - ./data/minio:/data ports : - "127.0.0.1:9000:9000" - "127.0.0.1:9001:9001" healthcheck : test : [ "CMD" , "mc" , "ready" , "local" ] start_period : 10s interval : 30s timeout : 20s retries : 3 postgres : image : postgres:17.5-bookworm container_name : postgres environment : POSTGRES_USER : ${POSTGRES_USER} POSTGRES_PASSWORD : ${POSTGRES_PASSWORD} POSTGRES_DB : ${POSTGRES_DB} volumes : - ./data/postgres/init.sql:/docker-entrypoint-initdb.d/init.sql:ro ports : - "127.0.0.1:5432:5432" healthcheck : test : [ "CMD-SHELL" , "pg_isready -U ${POSTGRES_USER}" ] interval : 10s timeout : 5s retries : 5 networks : default : name : ducknet init.sqlには以下を記載します。 CREATE DATABASE ducklake; docker compose up で起動します。 2. minioでバケットを作成する 今回GUIから作りました。 http://localhost:9001/ にアクセスしてください。 ログインして、左側のCreate Bucketからバケットを作ります。 今回名前はducklake-pocにしました。 3. DuckDB側の準備と起動 DuckDBをインストールします。 今回はCLIのDuckDBを使います。 HPにあるコマンド curl https://install.duckdb.org | sh インストールできたか確認 $ duckdb -version v1.3.0 71c5c07cdd DuckDBに必要な拡張機能をインストールします。 duckdbコマンドでCLIを起動して以下のコマンドを打ってください。 INSTALL ducklake; INSTALL httpfs; INSTALL postgres; LOAD postgres; LOAD ducklake; LOAD httpfs; postgres、httpfsはDucklakeのドキュメントには書いてなかったですが、とりあえず関係してそうなのでインストールしておきました。 Postgresqlとオブジェクトストレージに接続し、アタッチしたカタログデータベースを使用状態にします。 まずs3接続用シークレットを作ります。 create secret (type s3, key_id 'root-minio', secret 'root-minio', endpoint 'localhost:9000', use_ssl false, url_style 'path'); では接続します。 ATTACH 'ducklake:postgres:dbname=ducklake_catalog host=localhost user=postgres password=postgres' AS postgres_ducklake (DATA_PATH 's3://ducklake-poc'); USEしたときにエラーでなければ成功です。 USE postgres_ducklake; Attachしたタイミングでテーブルが作成されます。 publicスキーマに作られてます。 $ docker exec -it postgres psql -U postgres -d ducklake psql (17.5 (Debian 17.5-1.pgdg120+1)) Type "help" for help. ducklake=# \dt Did not find any relations. ducklake=# \dt List of relations Schema | Name | Type | Owner --------+---------------------------------------+-------+---------- public | ducklake_column | table | postgres public | ducklake_column_tag | table | postgres public | ducklake_data_file | table | postgres public | ducklake_delete_file | table | postgres public | ducklake_file_column_statistics | table | postgres public | ducklake_file_partition_value | table | postgres public | ducklake_files_scheduled_for_deletion | table | postgres public | ducklake_inlined_data_tables | table | postgres public | ducklake_metadata | table | postgres public | ducklake_partition_column | table | postgres public | ducklake_partition_info | table | postgres public | ducklake_schema | table | postgres public | ducklake_snapshot | table | postgres public | ducklake_snapshot_changes | table | postgres public | ducklake_table | table | postgres public | ducklake_table_column_stats | table | postgres public | ducklake_table_stats | table | postgres public | ducklake_tag | table | postgres public | ducklake_view | table | postgres (19 rows) ducklake=# \dt public.ducklake_column; List of relations Schema | Name | Type | Owner --------+-----------------+-------+---------- public | ducklake_column | table | postgres (1 row) これで使う準備は完了です。 試す Introduction のサンプルを元に試しにやってみます。 Postgresqlとminioで環境構築してるので、一部を改変して実行してます。 ※色々横道それながらやってたので、一部オブジェクトファイルのファイル名違ったりしますが気にしないでください。 CREATE TABLE nl_train_stations AS FROM 'https://blobs.duckdb.org/nl_stations.csv'; これでCSVファイルからデータを読み込みテーブルが作成されます。 DBを見てみるとテーブルの情報が作成されてます。 ducklake=# select * from ducklake_table; table_id | table_uuid | begin_snapshot | end_snapshot | schema_id | table_name ----------+--------------------------------------+----------------+--------------+-----------+------------------- 1 | 01974993-3ba1-7505-b4bf-eecff46886e0 | 1 | | 0 | nl_train_stations (1 row) ducklake=# select table_id,column_name from ducklake_column; table_id | column_name ----------+------------- 1 | id 1 | code 1 | uic 1 | name_short 1 | name_medium 1 | name_long 1 | slug 1 | country 1 | type 1 | geo_lat 1 | geo_lng (11 rows) オブジェクトストレージ側にもparquetファイルが作成されます。 では続きをやっていきます。 以下コマンドはparquetファイルの情報を取得しています。 D FROM glob('s3://ducklake-poc/*') ; ┌─────────────────────────────────────────────────────────────────────────┐ │ file │ │ varchar │ ├─────────────────────────────────────────────────────────────────────────┤ │ s3://ducklake-poc/ducklake-01974989-7208-7460-964d-c17d34b116c7.parquet │ └─────────────────────────────────────────────────────────────────────────┘ D FROM 's3://ducklake-poc/*.parquet' LIMIT 10; ┌───────┬─────────┬───┬─────────────────┬─────────────────┐ │ id │ code │ … │ geo_lat │ geo_lng │ │ int64 │ varchar │ │ double │ double │ ├───────┼─────────┼───┼─────────────────┼─────────────────┤ │ 266 │ HT │ … │ 51.69048 │ 5.29362 │ │ 269 │ HTO │ … │ 51.700553894043 │ 5.3183331489563 │ │ 227 │ HDE │ … │ 52.4091682 │ 5.893611 │ │ 8 │ AHBF │ … │ 50.7678 │ 6.091499 │ │ 818 │ AW │ … │ 50.78036 │ 6.070715 │ │ 51 │ ATN │ … │ 51.921326524551 │ 6.5786272287369 │ │ 5 │ AC │ … │ 52.2785 │ 4.977 │ │ 550 │ EAHS │ … │ 52.079796120944 │ 7.0163583755493 │ │ 12 │ AIME │ … │ 45.55438 │ 6.64869 │ │ 819 │ ACDG │ … │ 49.004048 │ 2.571133 │ ├───────┴─────────┴───┴─────────────────┴─────────────────┤ │ 10 rows 11 columns (4 shown) │ └──────────────── チュートリアルの通りに変更を加えます。 UPDATE nl_train_stations SET name_long='Johan Cruijff ArenA' WHERE code = 'ASB'; 変更を加えるとファイルが増えてるのがわかります。 FROM glob('s3://ducklake-poc/*') ; ┌──────────────────────────────────────────────────────────────────────────────┐ │ file │ │ varchar │ ├──────────────────────────────────────────────────────────────────────────────┤ │ s3://ducklake-poc/ducklake-01974993-3ba1-7387-ac08-101cab81f9f7.parquet │ │ s3://ducklake-poc/ducklake-01974994-9e69-7177-a6e5-253d9cf9d4af.parquet │ │ s3://ducklake-poc/ducklake-01974994-9e83-7c25-b00b-1f41f679902e-delete.par… │ └────────────────────────────── 過去のデータの状態を記憶したsnapshot一覧も見ることができるようです。 FROM postgres_ducklake.snapshots(); ┌─────────────┬────────────────────────────┬────────────────┬─────────────────────────────────────────────────────────────────────┐ │ snapshot_id │ snapshot_time │ schema_version │ changes │ │ int64 │ timestamp with time zone │ int64 │ map(varchar, varchar[]) │ ├─────────────┼────────────────────────────┼────────────────┼─────────────────────────────────────────────────────────────────────┤ │ 0 │ 2025-06-07 17:43:15.138+09 │ 0 │ {schemas_created=[main]} │ │ 1 │ 2025-06-07 17:47:54.805+09 │ 1 │ {tables_created=[main.nl_train_stations], tables_inserted_into=[1]} │ │ 2 │ 2025-06-07 17:49:26.108+09 │ 1 │ {tables_inserted_into=[1], tables_deleted_from=[1]} バージョンごとに内容を確認可能です。 SELECT name_long FROM nl_train_stations AT (VERSION => 1) WHERE code = 'ASB'; nl_train_stations AT (VERSION => 2) WHERE code = '┌─────────────────────────┐ │ name_long │ │ varchar │ ├─────────────────────────┤ │ Amsterdam Bijlmer ArenA │ └─────────────────────────┘ SELECT name_long FROM nl_train_stations AT (VERSION => 2) WHERE code = 'ASB'; ┌─────────────────────┐ │ name_long │ │ varchar │ ├─────────────────────┤ │ Johan Cruijff ArenA │ └────────────── カタログからデタッチするには以下のコマンドを使います。 USE memory; DETACH postgres_ducklake; ここまでで色々試すことができました！ まとめ 今回はDucklakeをPostgresql + s3(Minio) + DuckDBで構築しました！ インターネット上に情報が少なくかなり苦労しましたが、動かせてよかったです！ データ本体はオブジェクトストレージに置く形式なので、低コストで大量のデータをおけるのではないでしょうか？ これからもちょくちょく触ってみたいと思いました。 ここまで読んでいただきありがとうございました！

自己紹介 ラクスでPdMをしております。 @keeeey_m と申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存)を担当しており、個人としては楽楽精算×AIの担当、 楽楽明細・楽楽電子保存PdMチームのリーダーをしております。 きっかけは交流セッションのオファー 先日、アシスタントマネージャー（AM）へのステップアップを目指す女性社員向けの社内研修で話をする機会をいただきました。東京拠点で研修を受けている17名に向けて、マネジメント職として経験してきたことをざっくばらんに話してほしいとのこと。開発部門でマネジメント職として働く私の話が、彼女たちに新たな視点や気づきを与え、今後のキャリアを考える上での貴重なヒントになればという趣旨でした。 このオファーをきっかけに、自分自身のキャリアを振り返る良い機会となりました。マネジメントキャリアに前向きな気持ちがある一方で、自身が職責を果たせるのか、ライフプランと両立できるのかといった不安を感じている方々に向けて、ささやかながら私の経験をシェアしたいと思います。 自己紹介 きっかけは交流セッションのオファー 偶然の積み重ねが道になる 一人では解決できない課題 マネジメントとやりがい 強みと成長領域 ラベリングとの向き合い方 キャリアは一方通行ではない 偶然の積み重ねが道になる 2013年、新卒エンジニアとして入社してから10年余り。気がつけば製品管理課でチームを率いる立場になっていました。「マネジメントを目指そう」と決意した瞬間があったかと問われれば、そうではないと答えるでしょう。日々の業務に向き合い、少しずつ責任範囲が広がり、いつしかマネジメント層になっていました。 マネジメントという選択肢に興味を持ったきっかけは、ある気づきからでした。「自分が実現したい（達成したい）状態が、一個人の能力だけでは解決できない事象もある」という現実に直面したときです。 一人では解決できない課題 ラクスベトナムの立ち上げ初期、現地エンジニアの離職率の高さに悩まされていました。新たな開発拠点の構築のため、現地メンバーへのレクチャーや一緒の開発を通じて貢献しようとしましたが、教えては離職するという負のサイクルが続きました。当時は自分の能力不足を感じ、何ができたのか自問自答していました。 しかし1〜2年後、ラクスベトナムの現地マネジメント体制や採用方法が変わると、離職率は大幅に下がりました。そのとき気づいたのです。これは個人レベルでどうにかなる問題ではなかったということを。組織的な課題解決には、マネジメントという手段も必要だと考え始めたのです。 マネジメントとやりがい 「マネジメントとは、組織の目標達成のために、経営資源（ヒト・モノ・カネ・情報など）を効率的かつ効果的に活用し、組織の運営を最適化すること」。これを実感できるのは、一人の力では到底できないプロジェクトを成功に導けたときだと考えています。 現在進行中の楽楽精算のAI機能開発プロジェクトは、まさにその例です。自部署だけでなく部署を横断して経営資源を効率的に活用しています。何を目指しているのかを各開発部門や関連部署に説明し、理解と協力を得る。このプロセスを経て、最終的には記者会見やプレスリリースの内容にも携わるまでになりました。まだまだ始まったばかりですが、一人では決して達成できなかった成果の一つです。 強みと成長領域 ラクスには評価軸として全職種においてパフォーマンスに加えコンピテンシー（行動特性）評価があります。 ラクスのコンピテンシー 思考力（課題設定力・分析力 /状況判断力） 行動力（段取力・課題実行力/率先性・イニシアチブ） 人間関係力（折衝・交渉力/コミュニケーション力） 組織推進力（リーダーシップ・フォロワーシップ/チームワーク/人材育成） AMやマネジメントとしての私の強みは、「思考力（課題設定力・分析力）」「行動力（段取力・課題実行力）」「コミュニケーション力（折衝・交渉力）」が挙げられます。現場で一つひとつステップを上がってきたからこそ、実務の解像度が高いのも強みです。 これらの強みは、不確実性の高い状況での意思決定と、それへのコミットメントを繰り返してきたことで培われました。意思決定をする際、必要な情報が全て揃うことはありません。それによって思いもよらぬことが起きることもあります。その結果を振り返り、「予防線は張れなかったのか」「リスクとして検討できなかったのか」「見落としていた予兆はなかったのか」と内省する。この量を繰り返し、質を上げることで、結果的に思考力と行動力が磨かれました。 また、思考力（課題設定力・分析力）と行動力（段取力・課題実行力）を活かして、折衝・交渉力にも良い影響を与えています。関連部署にはその部署の目標などがあり、どのような事業KPIを持っているかなど相手の置かれている状況を理解することで、取り組むことができています。 一方で、今後さらに成長させたい点もあります。 コミュニケーション力 : メンバーへの情報開示と正確な伝達 施策や新たな取り組みにワクワクしてもらえるような伝え方 伝えにくいことでも事実と解釈を区別し、誤解なく伝える力 組織推進力 : リーダーシップとフォロワーシップ チームワーク 人材育成 ラベリングとの向き合い方 実は、AMになることにはかなり抵抗がありました。AMになれば、いずれマネジャーへの話は避けては通れなくなり、「女性管理職」というラベリングがつくことに違和感があったのです。ジェンダーに関係なく、一人のエンジニアとして、一人の人としてキャリアを歩み、ものづくりや課題解決に取り組む人として見られたい。 しかし、同様にラベリングに対して違和感を感じていた人の言葉を目にしました。 「いつかそういうラベルがビジネスの世界に存在しなくなってくれたらいいと思うけど、それが実現する日はきっととても遠いから、存在する前提の中でできることをやろうと思った。」 私は喜んで前に出る。 いつかそういうラベルがビジネスの世界に存在しなくなったらいいと思うけど、それが実現する日はきっととても遠いから、存在する前提の中でできることをやろうと思うに至った次第。 — Aki (@LoveIdahoBurger) July 22, 2023 そういう考え方もできるなと思い、捉え方を徐々に変えました。まだ「誰かの一歩踏み出す勇気になったら、喜んで引き受ける」という境地には至っていませんが、自分ができることをやろう、と考えるようになりました。 キャリアは一方通行ではない キャリアは「One Way Door（一方通行）」ではありません。マネジメントにチャレンジしてみて、専門性を追求したくなったら、また意思決定すればいい。自分自身と向き合い、自分自身で意思決定をすることが大切です。 周囲の考えを汲み取る必要もなければ、無理にロールモデルを見つける必要もない。生きていく上で、世の中の様々な人の考えに触れ、自分に合うものをちょっとずつ拝借する、それだけで十分なのではないでしょうか。 日々の業務に向き合い、「もうちょっとだけやってみよう」という姿勢。そして、やるだけやってみて、また次の選択をする。そんな一歩一歩が、結果的に自分だけのキャリアを形作っていくのだと思います。

はじめに こんにちは。楽楽販売開発課のkananpaです。 今回は、私が所属しているサポート対応チームにて、NotebookLMを使ってナレッジ検索用の問い合わせBotを作成した取り組みについてご紹介します。 「ナレッジはたくさんあるけど、活かしきれていない…」 そんな課題を解消すべく、AIツールを導入してどのようにナレッジを整理・活用したか、その作成過程と課題を素直にまとめました。 はじめに ナレッジは溜まっているのに、活用できていない現状 NotebookLMでナレッジ検索用Botを構築 NotebookLMを選んだ理由 データの準備とインポート 異なるデータ形式をどう扱ったか 実際の変換処理 CSV ➡ Markdownの変換 HTML ➡ Markdownの変換 Markdown変換で工夫したポイント プロンプトの設定 実際に使ってみた感想と効果 問い合わせ対応での活用事例 利用者の声 見えてきた課題と今後の展望 おわりに ナレッジは溜まっているのに、活用できていない現状 私たちが提供している「楽楽販売」は、カスタマイズ性が非常に高く、機能や設定も多岐にわたるサービスです。　 それに伴って手厚い顧客サポート体制も魅力の一つとなっています。 そのため、CS（カスタマーサクセス）チーム、開発チーム一丸となって、より良いサポート対応を行おうと改善を続けてきた結果、以下のような豊富なナレッジが蓄積されています。 顧客向けマニュアル（機能説明、設定方法など） 過去の問い合わせ対応履歴 CSチームが管理しているナレッジ しかし、それらが点在していたり、表記揺れがあったり、情報量が多すぎるなどで、必要な情報にたどり着くのに時間がかかっていました。 こうした課題を解決し、お客様からのお問い合わせに対して、より早く適切な回答ができる環境を整えるために、AIサービスを活用したナレッジ検索用Botの構築に取り組みました。 NotebookLMでナレッジ検索用Botを構築 以下では、NotebookLMを選定した背景と、その具体的な構築プロセスについて説明します。 NotebookLMを選んだ理由 ナレッジ検索用Botを導入するにあたり、まずは以下の要件を満たすAIサービスである必要がありました。 全社員が利用可能であること 社外秘情報も扱えること（※前提：内部利用に限る） コストを低く抑えられること ChatBot形式で質問できること 任意のドキュメントを学習できること これらの条件を踏まえ、候補として次の3つのAIサービスを比較しました。 ツール名 特徴 ChatGPT ・ファイルの対応形式が広い ・ウェブ検索が可能 NotebookLM ・資料の学習に特化させたAI ・基本的に資料に書かれていないことは回答しない ・回答時にソースの箇所を表示 Gemini ・プライバシー重視の設計 ・画像やコード、音声、動画など多様な形式に対応 この中で、特に重要視したのは次の3点です。 リサーチ用途に特化していること 資料に基づく正確な回答が得られること 回答時に出典を明示できること これらの点より、 NotebookLM がナレッジ検索用途に最適と考え、採用を決定しました。 データの準備とインポート 利用するAIサービスが決定し、次にナレッジ検索に必要なデータの整備とインポート作業に取りかかりました。 しかし、実際に蓄積されていたナレッジは、管理場所も形式もバラバラ、以下のように出力形式も統一されていませんでした。 顧客向けマニュアル（機能説明、設定方法など） ⇒ HTML 過去の問い合わせ対応履歴 ⇒ CSV CSチームが管理しているナレッジ ⇒ Markdown 異なるデータ形式をどう扱ったか そこでまず、これらの資料をMarkdown形式に統一する作業を行いました。 統一形式にMarkdownを採用した理由は、次のような利点があるためです。 Q&A構造をわかりやすく表現できる 見出し、箇条書き、リンクを使って構造的に整理できる NotebookLM上での表示が整いやすく、読みやすい 原文リンクを埋め込むことで、元資料に簡単にアクセス可能 これにより、質問と回答を明確に区別して学習させることが可能になり、誤った理解を防げるだけでなく、利用者にとっての可読性やナビゲーション性の向上にもつながります。 実際の変換処理 Markdownへの変換には、PHPで提供されているライブラリを使用しました。 CSV ➡ Markdownの変換 まずCSV形式の資料については、PHPの組み込みクラスである SplFileObject を使ってCSVデータを配列に整形し、Markdown形式に変換しました。 CSV ➡ Markdown変換イメージ図 HTML ➡ Markdownの変換 また、HTML形式の資料については HtmlConverter ライブラリを使用し、特に表形式データなども正確に変換できるよう TableConverter も併用しました。 HTML ➡ Markdown変換イメージ図 ※上記の画像は本ブログ用に作成したサンプル図であり、楽楽販売の実際の仕様とは一切関係ありません。 Markdown変換で工夫したポイント Markdown形式への変換にあたっては、上記添付画像の通り以下のような工夫を行いました。 元データの表示構造を極力再現（見出し・箇条書き・表など） NotebookLMのファイル数制限に配慮し、関連情報を1ファイルに集約 原文リンクをMarkdownに明記し、出典へのアクセス性を確保 プロンプトの設定 最後にプロンプトの設定を行いました。 NotebookLMではデフォルトであらかじめ用意されプロンプトを使用することもできますが、 今回は以下添付画像のように「カスタム」で設定し、回答の長さも「短め」に設定しました。 プロンプトの設定例 回答の長さに関して、ナレッジ検索用としては端的にまとまった内容が確認できた方が適切だろうと判断し、「短め」に設定しました。 「短め」でも重要な情報が漏れずにピックアップされており、十分に内容を把握できます。 実際に使ってみた感想と効果 問い合わせ対応での活用事例 実際に作成したBotに質問している様子が以下になります。 Bot活用事例 具体的な内容はお見せ出来ませんが、関連するナレッジに基づいた内容が返ってきており、回答内の「参照元リンク」をクリックすると、Markdownで整形された読みやすい資料がそのまま表示されました。 検索結果と資料の見やすさが直結している点は、運用上の大きなメリットです。 利用者の声 実際にCS・開発メンバー数名に使用してもらったところ、以下のようなフィードバックが得られました。 調査のヒントとなる情報が得られる あいまいな質問でも関連情報が整理されて表示される ナレッジ検索工数を削減できた 回答文を作成する際の素材集めとして活用できる 現時点では、そのまま回答として使えるレベルではないものの、調査の方向性を掴むには十分有効です。 また、解決のヒントを与えてくれることから、まだサポート業務を行って間もない新人メンバーのオンボーディング支援にも、活用が期待できます。 見えてきた課題と今後の展望 ただ、現場での試験導入を通じて、まだまだ以下のような課題もあることがわかってきました。 回答が微妙にずれていることがある 資料に記載があるはずなのにうまく回答されない 表などの構造化データの読み取りが弱い 検索ワード次第で該当なしとなることも 顧客環境依存の質問には対応が難しい 特に、「資料に記載があるはずなのにうまく回答されない」といったケースは、精度改善の重要なポイントと感じています。 今後は、以下のようなアプローチで改善を進めていく予定です。 学習対象データの選別 　→ ナレッジとなりえそうな情報を全て学習データとしていましたが、ナレッジとして効果の薄いものは対象外とすることで、より的確な回答が得られるよう見直しを検討しています。 学習対象データのファイル分割粒度最適化 　→ 大きなファイルをそのまま扱うのではなく、適度な単位でまとめ直してNotebookLMへ登録することで、より正確に該当情報を引き出せる可能性が高まります。 FAQ形式への変換ルールを整備 　→ ナレッジを単純にMarkdown化するのではなく、「Q:」「A:」などの明示的な構造を定義し、Botが文脈を正確に把握しやすいように整形します。 よくある表現の揺れに対応 　→ ユーザーが使いがちな用語や表現揺れのパターンを収集し、検索しやすい文言への補正やタグ付けを検討中です。 表や表現の多いHTML資料の事前変換 　→ 表組みデータや特殊レイアウトの資料は、事前にプレーンテキストへ変換＋注釈を付加して、構造が壊れないように工夫します。 まずは、「必要なナレッジに迅速かつ確実にアクセスできる」状態を整えることを重視しています。 情報が点在していたり、見つけづらかったりする状況を改善し、必要なときに、迷わず情報にたどり着ける仕組みを整備することで、対応スピードや業務効率の向上を図ります。 こうした積み重ねが、結果としてお客様へのより正確でスピーディーな対応にもつながると考えています。 おわりに 本記事では、「ナレッジはあるのに使えない」というよくある課題に対し、NotebookLMを活用してナレッジ検索Botを構築した実践例をご紹介しました。 蓄積されたナレッジを構造化し、誰もが必要な情報にすぐアクセスできる環境を整えることは、サポート品質の向上にとどまらず、チーム全体の生産性向上にもつながります。 さらに今後は特定のチームにとどめず、他業務への展開も視野に入れながら、ナレッジをもっと有効に活用できる仕組みへと育てていきたいと思います。

自己紹介 ラクスでPdMをしております。 @keeeey_m と申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存)を担当しており、個人としては楽楽精算×AIの担当、 楽楽明細・楽楽電子保存PdMチームのリーダーをしております。 はじめに：AI時代におけるPdMの役割変化 先日、 AI×PdM vol.1 〜AI時代のプロダクト開発・社内業務改革の最前線〜 というイベントに参加する機会がありました。このイベントでは、AI技術の急速な発展により、プロダクトマネージャー（PdM）の役割がどのように変化しているかについて、多くの示唆に富む議論が交わされました。 本記事では、イベントでの議論を踏まえ、AI時代におけるPdMの業務の代替容易性について分析し、今後求められる価値について考察します。 こんな方におすすめの記事です プロダクトマネージャー（PdM）として、AI時代の自分の役割について考えている方 プロダクト開発の組織マネジメントに関わり、AI活用を検討している方 プロダクトマネジメントのミドル層として、次のステップを模索している方 AI時代において、どのように価値を創出し、組織をリードしていくかを考えるための一助となれば幸いです。 目次 イベントの概要：3つのセッションで語られたAI時代のPdM イベントを通じて気づいたこと：組織と人材の変化 参考になった考え方：AI時代のPdMに必要な視点 AIの使い方にグラデーションがある 実践している者が尊い 一次情報を獲得できる能力 アーキテクトのように全体を設計できる能力 代替されやすい業務：AIに任せられる領域 代替されにくい業務：人間ならではの価値創出 今後求められるPdMの価値：戦略とイノベーション まとめ イベントの概要：3つのセッションで語られたAI時代のPdM イベントは3つのセッションで構成されていました セッション1：「AIでビジネスはどう変化するのか」 スマートバンク CEO 堀井翔太氏 UPSIDER 代表取締役 宮城徹氏 LayerX バクラク事業部CPO 兼 CEO室 榎本悠介氏 セッション2：「新規事業とPdMの役割」 テックタッチ 取締役CPO 中出昌哉氏 estie 執行役員 VPoP 久保拓也氏 SmartHR タレントマネジメントプロダクト本部 Director 松栄友希氏 セッション3：「AI活用プロダクトの最新トレンド」 Zen and Company 代表取締役 宮田善孝氏 ログラス 執行役員CBDO 斉藤知明氏 Algomatic 代表取締役CEO 大野峻典氏 バベル 代表取締役CEO 杉山大幹氏 イベントを通じて気づいたこと：組織と人材の変化 組織文化の重要性 AI活用を推進するためには、組織全体の文化変革が不可欠 定期的なAIに関する情報共有や表彰制度の効果 戦略的なAI活用の必要性 単なる効率化だけでなく、ビジネスモデルの変革を視野に入れる 既存の顧客体験を維持しながら、段階的にAIを導入する重要性 コストと効果のバランスを考慮した意思決定の必要性 人材採用と育成の変化 AIスキルだけでなく、基本的なプロダクトマネジメント力の重要性 若手の積極的な登用と、経験豊富な人材の知見の組み合わせ 継続的な学習と実践のサイクルの重要性 プロダクト開発の新しい潮流 ワークフロー中心の設計思考の重要性 顧客体験の継続的な改善と、AIによる付加価値の創出 スピード感のある開発と、品質の両立 参考になった考え方：AI時代のPdMに必要な視点 AIの使い方にグラデーションがある AIの使い方には、単純な自動化から複雑な意思決定支援まで、様々なレベルがあります。そして、どのレベルで使っているかは人によって様々です。PdMは、何のためにAIを使うのかを明確にし、適切なレベルで活用することが重要になってくる。 実践している者が尊い AI時代においても、自分自身でAIを使い手を動かし実践している者が尊い。PdMは、理論だけでなく、実践を通じて価値を創出することが求められる。 一次情報を獲得できる能力 AIが発達しても、一次情報を獲得できる能力は重要です。PdMは、顧客や市場との直接的な対話を通じて、深い理解を得ることが求められる。 アーキテクトのように全体を設計できる能力 AIを活用する際には、プロダクト全体を俯瞰し、適切な設計を行う能力が求められます。PdMは、アーキテクトのように全体を設計できる能力を持つことが重要になってくる。 代替されやすい業務：AIに任せられる領域 イベントでの議論を通じて、AIの活用方法や組織文化の重要性について理解を深めました。これらの知見を踏まえ、PdMの業務を「AIに代替されやすい業務」と「代替されにくい業務」に分類することで、今後求められる価値についてより具体的に考えてみました。 AIによって代替されやすい業務は、主に定型的でルーティン化された作業です データ分析・レポート作成 ドキュメント作成 定型的なコミュニケーション 基本的なタスク管理 これらの業務は、AIによって効率化され、PdMの時間をより価値の高い活動に割り当てることが可能になります。 代替されにくい業務：人間ならではの価値創出 一方で、以下の業務は人間の判断や創造性が求められるため、代替が難しいとされています 戦略的判断 市場機会の特定 投資判断 長期的なビジョンの設定 一次情報の獲得 顧客との直接的な対話 市場の深い理解 業界トレンドの把握 組織間調整 複雑な利害関係の調整 部門間の協力体制の構築 チームのモチベーション管理 今後求められるPdMの価値：戦略とイノベーション AI時代のPdMには、以下のような価値が求められます 戦略的思考 市場の深い理解 長期的なビジョンの設定 リソース配分の最適化 イノベーション創出 新しいビジネスモデルの考案 革新的なソリューションの設計 創造的な問題解決 組織開発 チームの育成 組織文化の形成 人材の最適配置 まとめ AI時代のPdMは、定型的な業務をAIに任せ、より戦略的で創造的な業務に集中することが求められています。特に、一次情報の獲得や組織間調整、イノベーション創出など、人間的な判断や創造性が求められる領域での役割が重要です。 あなたは、AI時代において、どのような価値を創出していきたいですか？ そして、そのために今、何を始めるべきだと考えていますか？

こんにちは、 稲垣 です。 2025年度からはイベント参加や登壇だけでなく RAKUS Developers Blog | ラクス エンジニアブログ や Rakus Designers Rakus Designers にも積極的に投稿して行こうかなと思っています。 X でもプロダクトマネージャーのこと、デザイナーのこと、マネジメント全般なことをポストしていますのでよろしくお願いします。 今回の内容は6/2(月)に開催し参加したこちらについてです。 product-people-united.connpass.com 第一回目は「ゲスト」と参加しましたが、今回は完全な視聴者と参加しました。 tech-blog.rakus.co.jp 前回同様に非常に学びになったので、ブログを書きます。 また、今後「フィッシュボウル形式」でのイベントや取り組みを検討している方へも参考になれば幸いです。 今回も会場は ログラスさん のオフィスとなります、前回と同じく100名規模も入れるイベントに最適な綺麗なオフィスでした （泉岳寺駅からもすぐ！） また、飲食の提供は ビットキーさん からで、懇親会でもお皿等不要なオニギリでだったので話の流れが止まらずよかったです。 ※両企業からファシリテーターやアウターサークルにもいらしておりました。 ■「OST」と「フィッシュボウル」とは？ ■『EM×PMフィッシュボウル #2 〜組織と価値創造 編〜』 ●前提 ●開始 ●最後に ■「OST」と「フィッシュボウル」とは？ 改めて、「OST」やら「フィッシュボウル」やらってなんぞや？って人もいるので、その解説です。 ざっくりこんな感じ まとめると ・「多並列で自由に動くOST」 と 「1テーマを集中討議するフィッシュボウル」 　⇒広げたいときは OST、深めたいときは フィッシュボウル なんとなくわかりましたか？詳しくは色々調べて見てください ———————————————————————————————— ■『EM×PMフィッシュボウル #2 〜組織と価値創造 編〜』 前回同様に具体的な内容についてはオフレコ祭りな内容が満載だったのと、濃すぎて書ききれないので 雰囲気と感想に感じたことを中心にお伝えします。 ●前提 前回は「PM（プロダクトマネージャー）」がテーマでしたが、今回は「EM（エンジニアリングマネージャー）」と「PM」との対談形式でした。 そのため、 インナーサークルもPM2名、EM2名、ファシリテーター2名 と、かなりにぎやかな構成となっていました。 また、今回も前回同様に専用のSlackチャンネルが立ち上がり、視聴者はそこで感想などを交換していました。 Slackの専用チャンネルへの参加者は、 前回は120人 に対し、 今回は140人 と、前回以上の参加がうかがえます。 （おそらく、会場に来られなかった方もSlackを通じて盛り上がりを体感していたのだと思います） ちなみに、EMとPMは見分けがつくようになっていましたが、 EMのほうが時間通りに集まっていて、PMのほうがやや遅れて集まっていた印象 です。私はEM側で参加しました。 ●開始 話のメインは「良いプロダクトチームとは？」 ——これが今回のフィッシュボウルのメインテーマという感じで、約75分間、議論やさまざまな話が繰り広げられました。オフレコの内容が多いため、気になったポイントを以下に書きます。 （誰の発言だったか覚えているものもありますが、ここには記載しません） ■良いプロダクトチームとは？ 事業成果につながるプロダクトを作れるチーム 目線が揃っているチーム（「お前、視座低い」とか言わずに歩調を合わせられる） 遠慮のないコミュニケーションができる（配慮は必要） ROIが高いチーム 『スラムダンク』湘北高校のように、強みを生かし、弱みを補えるチーム 最高の状態を毎回更新し続けられるチーム ■これ以外でてた話 良いPM、EMとは？ → 仕事ができる人 ROIが低いプロダクトからはエンジニアを撤退させる。まずはPMがしっかり売ってから ■感じたこと PL責任を持っているPMは、50名以上いるPMの中でもごくわずかで、どこもあまり持っていなかった 組織間の壁はどんなチームにもある、俯瞰できる人、そういった壁を感じずに動ける人が期待されている 「圧倒的な当事者意識」——これが結局、EM・PMにとって必須のマインドである ■自分の答え 良いプロダクトチームとは？ 「継続的に成果を出せる」＝「製品成長をし続けられる」チーム 　　　「製品成長」とは、『顧客を創造できているか』だと自分は感じています 　　　そして、これができれば売上にも寄与できると思っています。 良いPMは？ エンジニアをワクワクさせるようなアイデアや要求を生み出せる人 　※30代のEM頃に常駐先企業の開発トップの方が、PdM（当時はプランナー）に言っていた言葉： 　　　　「あなた自身がワクワクして、かつ我々エンジニアをワクワクさせてくれるなら 　　　　 僕らエンジニアはどんな無茶でもやり遂げるよ。でも、あなた自身がワクワクしていないような 　　　　アイデアや企画には、大切なエンジニアリソースを割くことはできない。」 ●最後に 前回に引き続き、今回も非常に有意義な会でした。あえて、さらに良くするために苦言を述べると（※アンケートにもこの内容を回答済みです）、もう少し EMの意見、特にテック寄りのEMの意見 が聞きたかったです。 今回は2つの役割が登場していたため、対立構造にする必要はないものの、 異なる職種同士による結論のないぶつかり合いを期待 していました。（PMがEMを経由してPM職を担っている人が多い点は、ある程度仕方ないと理解しています） 具体的には、以下のようなテーマが議論できたら、さらに良かったのではと感じました： 技術負債の解消と事業成長とのバランス PMが求めるデリバリースピードと、EMが守るべき品質のせめぎ合い テクノロジーを活用したディスカバリーアイデア こちらは当日の模様 #EMPMフィッシュボウル 無事に終了しました！色々な話題と考えを提供してくれた登壇者、インナーサークルの皆さん、Slackで大盛り上がりしてくださった皆さん、本当にありがとうございました！またぜひやれればと思います。 pic.twitter.com/LIDdTJAXDT — yokomichi | プロダクトコーチ (@ykmc09) 2025年6月2日 第３回もきっとあると思うので、参加する方へのアドバイスです １．携帯電話の充電はフルMAXで ２．対象slackの通知はOFFで 今後も続々と「フィッシュボウル」形式のイベントが開催されるようで、引き続き自分も参加する予定です bitkey.connpass.com

ラク スが「顧客志向」を大切にしつづける理由 事業が成長し、組織が大きくなるにつれ、エンジニアと顧客の距離は遠くなりがちです。 「リリースした機能が、実際どう使われているのかわからない」 「この仕様、本当に最適なのだろうか？」 そんなモヤモヤを持っている方もいるかもしれません。 私たち ラク スは 創業当初から徹底的に顧客の声を聴き 、プロダクトを磨きこんできました。 2017年からは開発組織として 「顧客をカスタマーサクセスに導く、圧倒的に使いやすい SaaS を創り提供する」 というミッションを掲げ 「顧客志向」での開発 に取り組み続けています。 その結果、多くの顧客にプロダクトが支持され、 国内 SaaS 市場でARR No.1 を達成できました。 しかし当社も例外ではなく、開発組織が拡大するにつれ、顧客の声がエンジニアに届きづらくなってきました。 今後も顧客に選ばれ続けるプロダクト開発をするために、 改めて 「顧客志向」を徹底し大切にしていくことが重要 と考えています。 今回は「顧客志向」を徹底するためにエンジニアやデザイナーたちが 開発の現場でどのような実践を行っているのか 、技術広報よりその一部をご紹介します。 「顧客志向」を重視する開発姿勢については、開発本部長 公手のブログも是非ご覧ください。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp ラクスが「顧客志向」を大切にしつづける理由 開発組織の「顧客志向」を強化する取り組み 「もっと使いやすく、顧客に喜ばれるために」一歩踏み出した行動 ビジネスと開発の相互理解の場づくり（テックリード） 想定顧客へのヒアリングで新たなニーズを発掘（PdM） 顧客の声をもとに、プロトタイプを高速改善（PdM） 商談動画からUI/UX改善のヒントを発見（フロントエンドエンジニア） 業務フロー図と共感マップで顧客業務を深く理解（プロダクトデザイナー） 「顧客志向」の熱量を感じた、行動の数々 これからも「顧客志向のSaaS開発組織」であり続けるために 開発組織の「顧客志向」を強化する取り組み 昨年から、開発組織全体で「顧客志向」の重要性を共通認識化することに取り組んできました。 組織や人によって、「顧客志向」への認識や実践度合いにばらつきがあるという課題が浮かび上がってきたからです。 その手始めとして、管理職で「顧客志向」の定義と実践方針を 言語化 しました。 「顧客志向」の定義 顧客のニーズや課題を深く理解し、価値のあるソリューションを提供する また、変化するニーズやフィードバックに対して迅速対応と継続改善に取り組むこと 組織全体の実践方針 開発本部内の全社員が顧客がいる事を常に意識し 顧客理解を深める 　 ex）利用者と同じ体験をする、一次情報（VoC等）に触れる 顧客への提供価値を自分の言葉で説明できる さらに開発本部メンバー全員が気づきを得ることを目的に 「顧客志向」を高めるワークショップを実施し、顧客・製品理解を高めました。 この経緯や詳細な内容については、下記のブログをご覧ください。 tech-blog.rakus.co.jp この実践方針をもとに、プロダクト開発やデザインチームで、顧客理解や製品理解の取り組みを活発に行ってきました。 例えばフロントエンド開発チームでも、製品理解を高めるための独自のワークショップを開催しました。 今期は、 顧客志向を体現した個人の行動を称え、取り組みを組織内で共有するために顧客志向表彰を実施 しました。 具体的にどのように顧客志向に取り組み、取り組みから得られた成果、気づき、学びをご紹介したいと思います。 「もっと使いやすく、顧客に喜ばれるために」一歩踏み出した行動 顧客志向表彰では、 役割や職種にとらわれず、顧客を知るために役割や部門の垣根を超えて一歩踏み出した個人の行動エピソード を広く表彰しました。 ビジネスと開発の相互理解の場づくり（テッ クリード ） 【背景】入社直後で素早くキャッチアップのため 製品・顧客業務への理解を高めたかった。 【取り組み】担当製品の課題を深く理解するため、 CS・営業・開発による情報交換会 を提案。事業部・開発チームからも共感が集まり、開発メンバー全員が参加。 【結果】 業務課題がより明確になり、顧客理解が深まった 。ドキュメントでは得られない、 フランクな意見交換の空気 も生まれ、継続的な取り組みに。 CS・営業・開発メンバーが集合 想定顧客への ヒアリ ングで新たなニーズを発掘（PdM） 【背景】 新領域である営業支援の機能開発に着手。 既存顧客とは異なる ドメイン で、通常の ヒアリ ングではニーズ把握が難しい 。 【取り組み】 展示会・商談動画を活用のほか、 社内営業担当を想定顧客に ヒアリ ング実施 。 【結果】開発とニーズをつなぐことで 設計・テストの品質が安定 。リリースも計画通り進み、 顧客から高評価を獲得 。 顧客の声をもとに、プロトタイプを高速改善（PdM） 【背景】 製品導入時の 設定作業が煩雑で、顧客の負担に なっていた。 【取り組み】 CSとともに 導入現場に立ち会い、自らも設定を体験 。設定効率化ツールの仕様を企画し、 スクラム でプロトタイプを作成→CSからのフィードバック をもとに改善を繰り返した。 【結果】 顧客の導入を支える 機能改良を継続中 。 商談動画からUI/UX改善のヒントを発見（フロントエンドエンジニア） 【背景】 商談動画はフロントエンドチームにとって顧客理解の貴重な素材となっている。しかし 視聴が個人任せで知見を共有しきれていなかった 。 【取り組み】同じ動画を全員で視聴し、意見交換する 「商談動画共有会」 を開催。 【結果】 顧客の指摘や実際の使われ方からUI/UX改善のヒントを得られた 。今後は新メンバーでも早く理解を深められるよう、仕組み化を推進予定。 業務フロー図と共感マップで顧客業務を深く理解（ プロダクトデザイナー ） 【背景】 仕訳に関わる新機能デザインのため、 経理 業務の理解が不可欠 だった。 【取り組み】 顧客要望DBや商談動画をもとに 業務フロー図・共感マップ を作成し、 経理 部門に ヒアリ ングを実施。 苦労しているポイントを可視化 。 【結果】 業務のつまずきどころをチームで共有し、 業務に寄り添ったUI設計につなげられた 。 「顧客志向」の熱量を感じた、行動の数々 今期の顧客志向表彰には、ここでは紹介しきれない数多くの行動エピソードが集まりました。 さまざまな役割・業務のメンバーから行動エピソードが集まり、「顧客志向」の熱量が広がっていることを改めて実感しています。 紹介した事例では、当初次のような課題がありました。 顧客業務の知識が足りない 顧客の悩みが十分に共有されていない 組織間で顧客の熱量が共有しきれていない それでも 「顧客の役に立ちたい」という気持ちで、自らの役割を一歩超えて顧客を知りに行く姿勢 が光りました。結果として得られたのは 顧客の課題へのリアルな実感 自分の仕事が役立っているという手応え それが自身のやりがいや、チームの活気を高めていくのだと思います。 これからも「顧客志向の SaaS 開発組織」であり続けるために 顧客志向は特別な取り組みではなく、日々の仕事のなかで自然と積み重ねていくものだと思います。 取り組みを通じて改めて感じたのは、 「一人ひとりが、意識して顧客の課題に目を向けること」 の大切さでした。 これからも技術広報では、そうした実践を支える横断的な仕組みづくりや、開発チーム内の取り組み支援を続けます。 また、開発本部全体でも顧客の声に徹底して耳を傾け、 「顧客志向の SaaS 開発組織」 としてアップデートし続けていきます。

自己紹介 ラク スでPdMをしております。 @keeeey_m と申します。 現在の担当商材は、楽楽シリーズ(楽楽精算、楽楽明細、楽楽電子保存)を担当しており、個人としては楽楽精算×AIの担当、 楽楽明細・楽楽電子保存PdMチームのリーダーをしております。 この記事を書いたきっかけ プロダクトマネージャーとして日々業務に携わる中で、ChatGPTやCopilot、CursorなどのAIツールを積極的に活用してきました。 個人レベルでの生産性向上は確実に実感していたものの、ある日ふと気づいたことがありました。 「人を動かすことの方が圧倒的に時間と労力を要する」という現実です。 この気づきを上司に話をしたところ、同様の課題を感じている人が他にもいることがわかりました。 さすがに、この事実に「何かあるな」と直感が働き、調査・分析を行うと、DX化とAI業務利用には重要な共通点があることに気づいたのです。 こんな方におすすめの記事です AIツールを導入しているのに、プロジェクト全体の生産性やスピードが上がっていないと感じている方 これから業務にAIツールを導入しようとしている方 組織レベルでのAI活用を検討している管理職の方 目次 AIツールを導入したのに、なぜプロジェクト全体のスピードが上がらないのか？ 個人の生産性向上だけでは限界がある ワークフロー変革こそが本質的な解決策 AIは仕事を奪うのではなく、新たな価値創造の機会を生む プロダクトマネジメントの考え方をワークフロー変革に活かす まとめ AIツールを導入したのに、なぜプロジェクト全体のスピードが上がらないのか？ ChatGPTやCopilot、Cursorなど、AIツールを業務に導入する企業が急速に増えています。個人レベルでは確実に生産性が向上し、アウトプットの質とスピードが格段に上がっているのを実感している方も多いでしょう。 しかし、ふと振り返ってみると気づくことがあります。 「人を動かすことの方が圧倒的に時間と労力を要する」 という現実です。 個人の生産性向上だけでは限界がある AIツールを活用することで、議論のベースとなる資料作成や分析が高速化され、 PDCAサイクル を素早く回せるようになりました。一方で、承認プロセスや他部署との調整、複数人が関わる意思決定など、人を動かす必要がある業務は従来通りの時間がかかっています。 この状況は、まさにDX化の初期段階で多くの企業が直面する課題と同じです。 既存の業務フローにデジタルツールを当てはめただけでは、真の変革は起こらない のです。 ワークフロー変革こそが本質的な解決策 DX化とAI業務利用の最大の共通点は、 「AIを活用できる業務フローに変えなければ意味がない」 ということです。 特に大きな組織ほど、「今のプロセスは変えられない」という固定概念に縛られがちです。しかし、プロダクト開発において常に重視しているワークフローの最適化を、なぜ自分たちの業務には適用しないのでしょうか。 AI活用成功の3つの条件 情報のアクセス格差を解消する （情報の非対称性の解消） 必要な情報が特定の人や部署に集中していては、AIの力を最大化できません 情報の統合と可視化を進める （情報の分断を防ぐ） AIは情報こそが生命線。散らばった情報を統合し、全体像を把握できる環境が必要です 深い業務理解を持つ 浅い理解のままAIを活用しても、適切な判断ができず、かえって混乱を招く可能性があります AIは仕事を奪うのではなく、新たな価値創造の機会を生む 「AIが人の仕事を奪う」という議論をよく耳にしますが、実際はそう単純ではありません。 真の変化は、 AIを使いこなせる人材が新たな価値を創造し、より高次元の業務に集中できる世界 の到来です。既存の情報を活用し、深く考える能力を持つ人材が、AIによって レバレッジ を最大化し、これまでにない成果を生み出せるようになるのです。 重要なのは、人にしかできない創造的な思考や判断、コミュニケーションの部分により多くの時間を割けるようになることです。 プロダクトマネジメント の考え方をワークフロー変革に活かす BtoBのバックオフィス業務のプロダクト開発に携わる私たちプロダクトマネージャーは、ユーザーの業務フローを最適化することの重要性を常に説いています。その際、ユーザーの業務に対する解像度を高く持つことが、真に価値のあるプロダクトを提供するための重要な要素だと考えています。 この プロダクトマネジメント の考え方を、自分たちの業務フローにも同様に適用するべきではないでしょうか。ユーザーの業務を深く理解し、課題を解決するプロダクトを作る私たちが、自分たちの業務における課題に気づかないのは矛盾しています。 組織的な関係性や社内ルールから見直し、AI駆動で開発できるワークフローへの変革を主導する。これこそが、真のDX化とAI活用成功への第一歩なのです。 まとめ AIツールの導入は手段であり、目的ではありません。重要なのは、AIの力を最大限に活用できるワークフローへの変革です。個人の生産性向上に満足せず、組織全体の仕組みを見直す勇気を持つことが、次の競争力を生み出すカギとなるのではないでしょうか。

こんにちは、 稲垣 です。 先日、「読書シェア」に参加しましたので、書籍の紹介とともに表題の件について書いてみようと思います。 yumemi.connpass.com 自己紹介 書籍紹介 最後に 自己紹介 現在、私は ラク スの「製品管理課」という組織でマネージャーを務めています。 （2025年4月から、製品管理課はプロダクト部に所属し、そこの副部長も兼務しています。） 詳しい経歴やプロダクト部のことは、こちらをご覧いただければと思います。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 書籍紹介 今回、「読書シェア」で紹介した書籍はこちらになります。 これを読んだきっかけは、PdMにとってデザイナーとの連携は必須であり、PdMはデザイナーの気持ちを理解しておく必要があると考えたからです。その中で、デザイナーのメンバーに関連書籍を教えてもらった結果、この書籍を紹介されました。 この本は、 三井住友銀行 のインハウスデザイナー3人が、これまで希薄だったUI/UXの重要性をどのように組織に浸透させ、アプリの刷新や関連サービスとの連携を実現し、 グッドデザイン賞 を受賞したのかを描いたドキュメンタリーです。 そのため非常に生々しく、3人がどれほど苦労したのかがよくわかります。 最後に 現在、 ラク スの楽楽シリーズでは本にも記載ある「デザインシステム」の構築をしています。 tech-blog.rakus.co.jp 楽楽シリーズの製品は、売上規模から提供開始時期まで非常に幅広いです。 このプロダクト群のデザインシステムの構築には多くの苦労が伴い、各プロダクトチームの理解やデザイナーの深い関与が必要となります。また、各役割における「デザイン」への理解も千差万別で、以下のような認識をいまだに持っている方も多くいます。 　　　　 「デザイナー＝見た目を整える人」 まさに「デザインシステムの構築」や「デザインを社内に浸透させる」ためのヒントが詰まっている書籍でした。 書籍紹介の資料については、こちらにありますので、すべてご覧になりたい方は以下をご参照ください。 speakerdeck.com 記事を読んで ラク スのデザイナーの興味を持った方は是非ご応募ください！ career-recruit.rakus.co.jp

はじめに こんにちは！ ラク スでSREをしている モリモト （2025/3に中途入社）です。 業務の中で、AtlasとArgoCDを使ってGoアプリケーションのDB マイグレーション の仕組みを新規に構築したので、その方法を書き残してみたいと思います。 はじめに 構築したフロー 実現したかったこと 1. 宣言的なスキーマファイルを管理できる 2. 宣言的なスキーマファイルからマイグレーションファイルを生成でき、それをバージョン管理できる 3. 検証環境や本番環境に対して、自動でDBマイグレーションを実行できる アーキテクチャ検討 Atlasの導入とスキーマ管理の仕組み スキーマの定義 atlasの設定ファイル（atlas.hcl） atlas.hclのサンプル env内の主な設定項目 マイグレーションファイルの生成 atlas migrate diffコマンドの各オプション説明 マイグレーションのローカルDBへの適用 マイグレーション用Dockerイメージを作成する Dockerfileを作成 Github Actionsワークフローを作成 ArgoCDのPreSyncでマイグレーションを実行する マイグレーション用Jobの例 ArgoCD Hookアノテーションの解説 さいごに 参考リンク 構築したフロー 今回構築した全体の マイグレーション フローは、以下のような流れになっています。 ローカル環境で スキーマ 定義を編集し、差分から マイグレーション ファイルを生成 生成した マイグレーション ファイルをアプリ用の GitHub リポジトリ へプッシュ GitHub Actionsで マイグレーション 用のDockerイメージをビルドし、Container Registryにプッシュ（タグにはコミットハッシュおよびlatestを付与） k8s マニフェスト 用の GitHub リポジトリ でPRをdevelopブランチにマージすると、ArgoCDのPreSync Hookにより マイグレーション Jobが起動（latestタグのイメージを使用）し、検証環境に対して マイグレーション を自動実行 同様に、PRをmainブランチにマージすると、ArgoCDのPreSync Hookにより マイグレーション Jobが起動（特定のタグのイメージを使用）し、本番環境に対して マイグレーション を自動実行 実現したかったこと 実現したかったことは、以下の３つです。 1. 宣言的な スキーマ ファイルを管理できる マイグレーション ファイルが多くなると、最終的なDB構造が見えにくくなることがあるかと思います。宣言的な スキーマ ファイルを管理することで、現在の理想的なDB構造を一目で確認できる状態を作りたいです。 2. 宣言的な スキーマ ファイルから マイグレーション ファイルを生成でき、それをバージョン管理できる 差分を自動的に検出し、 マイグレーション ファイルを自動で生成したいです。 また、生成された SQL ファイルはGitで管理することで変更履歴を容易に管理したいです。 3. 検証環境や本番環境に対して、自動でDB マイグレーション を実行できる 手動で実行することなくデプロイ処理に組み込むことで、「 マイグレーション 漏れ」や「コマンド実行ミス」によるリリース失敗のリスクを減らしたいです。 アーキテクチャ 検討 前提として、私がアプリケーションの技術スタックは以下となります。 技術スタック Backend Go DB Postgres（CloudNativePG） Infra Kubernetes CI/CD GitHub Actions, ArgoCD まずは、Goで使用できるDB マイグレーション ツールの選定です。 ただし、この件についてはチーム内の別システムで、DB マイグレーション に「 Atlas 」というツールを採用する方針がすでに決まっていました。 少し調べたところ、実現したい内容を満たせそうだったことに加え、チーム内での横展開も見込めるため、Atlasを使うことにしました。 次に、検証環境や本番環境に対してどうやってDB マイグレーション を自動実行するかの検討を行いました。 ArgoCDにはResource Hookという仕組みがあり、同期処理（Sync）の前後などに処理をはさむことが容易にできます。 そのため、ArgoCDのResource Hookの一つであるPreSyncを活用して、 マニフェスト 適用の直前でDB マイグレーション を自動実行できる仕組みを構築することにしました。 以下では、この仕組みをどのように実現したかを具体的に説明していきます。 Atlasの導入と スキーマ 管理の仕組み まずはAtlasを導入し、宣言的な スキーマ 管理ができる環境を整備していきます。 Atlasは以下のような ディレクト リ構成で利用しています。 /db ├── schema.sql // 宣言的に定義したDBスキーマ ├── atlas.hcl // atlasの設定ファイル └── /migrations // マイグレーション時に実行するSQLファイルが格納されるディレクトリ └── 20250513060616_create_blog_posts.sql 　　　　　　　・ 　　　　　　　・ /app ├──main.go 　　　　・ 　　　　・ スキーマ の定義 schema.sql ファイルでは、現在の理想的なDBの状態を sql ファイルで定義します。（init. sql みたいな感じです） -- db/schema.sql CREATE TABLE users ( id SERIAL PRIMARY KEY, name TEXT NOT NULL , created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); atlasの設定ファイル（ atlas.hcl ） atlas.hcl は、Atlasの実行設定を定義するためのファイルです。 マイグレーション 対象のデータベースや スキーマ ファイルの場所、 マイグレーション ディレクト リのパスなどを記述します。 このファイルを作成しておくことで、 コマンドライン での指定を省略したり、 atlas migrate apply などのコマンドで共通設定を使い回すことができます。 atlas.hclのサンプル # db/atlas.hcl variable "db_user" { type = string default = getenv ( "DB_USER" ) } variable "db_password" { type = string default = getenv ( "DB_PASSWORD" ) } variable "db_host" { type = string default = getenv ( "DB_HOST" ) } variable "db_port" { type = string default = getenv ( "DB_PORT" ) } variable "db_name" { type = string default = getenv ( "DB_NAME" ) } variable "db_sslmode" { type = string default = getenv ( "DB_SSLMODE" ) } locals { pg_url = "postgres://$ { var.db_user } :$ { var.db_password } @$ { var.db_host } :$ { var.db_port } /$ { var.db_name } ?sslmode=$ { var.db_sslmode } " } # local起動用 env "local" { url = local.pg_url src = "file://db/schema.sql" dev = "docker://postgres/16/dev" migration { dir = "file://db/migrations" exclude = [ # river "public.river_*" , ] } } # localのDockerで起動用 env "local-docker" { url = local.pg_url migration { dir = "file://migrations" exclude = [ # river "public.river_*" , ] } } # stg,prd用 env "prod" { url = local.pg_url migration { dir = "file://migrations" exclude = [ # river "public.river_*" , ] } } env内の主な設定項目 項目 説明 url 実際に マイグレーション を適用するDBの接続URLを指定します。 dev 比較・検証用の一時的な開発DBを指定します（例: Docker上の PostgreSQL ）。差分検出時に使用されます。 migration.dir マイグレーション ファイルの保存 ディレクト リを指定します。 migration.exclude マイグレーション の対象外としたい スキーマ 、テーブルを指定できます。 ※ Terraformのようにvariableで変数を作成することもでき、今回はDBの設定情報を 環境変数 から取得してきてvariableに格納するようにしています。 マイグレーション ファイルの生成 Atlasでは、宣言的な スキーマ ファイルと、現状のDB状態を比較して自動的に マイグレーション ファイル（ SQL ）を生成することができます。 atlas migrate diff add_user_schema --env "local" --config "file://db/atlas.hcl" --to "file://db/schema.sql" # 以下のようにenvを利用せずに直接オプションを指定しても実行可能 atlas migrate diff --to "file://db/schema.sql" --dev-url "docker://postgres/16/dev" --dir "file://db/migrations" このコマンドにより、atlas/migrations ディレクト リに新しい マイグレーション SQL が自動生成されます。 これをGitで管理することで、 スキーマ 変更の履歴も明確に追跡できます。 コマンド実行時に --env local のように指定することで、 atlas.hcl で定義した設定を利用できます。 atlas migrate diffコマンドの各オプション説明 オプション 説明 --to "file://db/schema.sql" 宣言的に定義された理想的な スキーマ を指定します。 --dev-url "docker://postgres/16/dev" DB マイグレーション 用の一時データベースのURLです。 Atlasが スキーマ 比較を行う際にこのDB上に現在の スキーマ を一時的に構築します。 --dir "file://db/migrations" 差分から生成された マイグレーション ファイルを出力する ディレクト リを指定します。 ここに .sql ファイルが生成され、順序付きの マイグレーション 履歴として管理されます。 ※ --dev-url には、ローカルの PostgreSQL や他の接続先を指定することも可能です。 マイグレーション のローカルDBへの適用 生成された マイグレーション ファイルは、 atlas migrate apply コマンドでデータベースに適用することができます。 atlas migrate apply --env "local" --config "file://db/atlas.hcl" このコマンドにより、db/migrations にある マイグレーション ファイルが順番に実行され、指定したデータベースに反映されます。 マイグレーション 用Dockerイメージを作成する ArgoCDのジョブから マイグレーション を実行するために、Dockerイメージを作成します。 Dockerfileを作成 # ./Dockerfile # local用 FROM arigaio/atlas:0.33.0-distroless AS migration-local WORKDIR /app COPY ./db/migrations/ /app/migrations COPY ./db/atlas.hcl /app/atlas.hcl CMD ["migrate", "apply", "--env", "local-docker", "--config", "file://atlas.hcl"] # prod用 FROM arigaio/atlas:0.33.0-distroless AS migration-prod WORKDIR /app COPY ./db/migrations/ /app/migrations COPY ./db/atlas.hcl /app/atlas.hcl CMD ["migrate", "apply", "--env", "prod", "--config", "file://atlas.hcl", "--baseline", "20250513060616"] prod用のみ --baseline オプションをつけているのは、prod環境にすでに初期データベースが存在していたためです。 通常、Atlasは マイグレーション 履歴テーブル（atlas_schema_revisions）が存在しないと、全ての マイグレーション ファイルを最初から適用しようとします。 しかし、prodでは過去の マイグレーション はすでに手動などで適用済みであるため、適用済みと見なす マイグレーション ファイルのバージョン（この例では 20250513060616）を --baseline に指定することで、それ以前のファイルはスキップされます。 このようにすることで、既存DBの破壊を避けつつ、 マイグレーション をAtlasで管理できる状態に移行できます。 Github Actionsワークフローを作成 GitHub Actions で マイグレーション 用Dockerイメージをビルド＆プッシュするためのワークフローを作成します。 私は社内に展開されている独自のワークフローを流用したため、ここにコードを貼り付けることはできないです。。すみません。 ただ実装は単純で、 マイグレーション ファイルが更新されたら、push or PRマージ のタイミングで、Dockerfileをビルドして自身のコンテナ レジストリ に github .shaとlatestの２つのタグをpushしています。 以下は例です！（chatgptに適当に書かせたやつなので、動かなかったらすみません。。） # .github/workflows/build-push-migration.yaml name : Build and push Migration on : push : branches : - main paths : - db/migrations/** - .github/workflows/build-push-migration.yaml jobs : build : runs-on : ubuntu-latest steps : - name : Checkout uses : actions/checkout@v3 - name : Set up Docker Buildx uses : docker/setup-buildx-action@v2 - name : Login to DockerHub uses : docker/login-action@v2 with : username : ${{ secrets.DOCKERHUB_USERNAME }} password : ${{ secrets.DOCKERHUB_TOKEN }} - name : Build and push migration image uses : docker/build-push-action@v5 with : context : . file : db/Dockerfile push : true tags : | yourorg/db-migration:latest yourorg/db-migration:${{ github.sha }} ArgoCDのPreSyncで マイグレーション を実行する ArgoCDを使って マイグレーション を自動実行する仕組みを構築します。 ここでは Job リソースに argocd.argoproj.io/hook: PreSync アノテーション を付与することで、 アプリケーションの マニフェスト が適用される前にDB マイグレーション を行うようにしています。 マイグレーション 用Jobの例 apiVersion : batch/v1 kind : Job metadata : name : db-migration-job annotations : argocd.argoproj.io/hook : PreSync argocd.argoproj.io/hook-delete-policy : BeforeHookCreation argocd.argoproj.io/sync-wave : "-1" spec : backoffLimit : 0 completions : 1 parallelism : 1 template : spec : restartPolicy : Never imagePullSecrets : - name : my-registry-secret containers : - name : db-migration-job # 検証環境はlatest、本番環境はコミットハッシュで特定のイメージタグを指定 image : "yourorg/db-migration:latest" imagePullPolicy : Always envFrom : - secretRef : name : db-secret ArgoCD Hook アノテーション の解説 以下の アノテーション を使うことで、ArgoCDの同期処理に対して マイグレーション Jobの実行タイミングや順序、削除方針を制御できます。 アノテーション 名 役割 説明 argocd.argoproj.io/hook: PreSync 実行タイミング指定 同期処理の 前 にこのリソースを実行します。DB マイグレーション やバリデーションなどに最適です。 argocd.argoproj.io/hook-delete-policy: BeforeHookCreation 削除ポリシー 次の同期時にリソースを再作成できるよう、 実行前に削除 します。 argocd.argoproj.io/sync-wave: "-1" 実行順序制御 同じタイミング（ここではPreSync）に複数リソースがある場合、 小さい値から順に実行 されます。 今回、job実行のためのDB接続情報はSecretリソースに格納されているため、 SecretもPreSyncにする必要があります。 apiVersion : v1 kind : Secret metadata : name : db-secret annotations : argocd.argoproj.io/hook : PreSync argocd.argoproj.io/hook-delete-policy : BeforeHookCreation argocd.argoproj.io/sync-wave : "-2" type : Opaque stringData : DB_USER : your_user DB_PASSWORD : your_password DB_HOST : your_host DB_PORT : "5432" DB_NAME : your_db DB_SSLMODE : disable ※ sync-wave: "-2" とすることで、 マイグレーション Job（sync-wave: "-1"）より先にSecretが適用されます。 これらのリソースを マニフェスト に追加することで、 マニフェスト 同期の前にDB マイグレーション が自動実行されるようになります。 さいごに 今回、AtlasとArgoCDを使った自動 マイグレーション の仕組みを構築してみて、大部分の作業を自動化できました！ 同じようなことをしたい方の参考になれば幸いです。 最後まで読んでいただきありがとうございました！ 参考リンク qiita.com tech.gunosy.io zenn.dev techblog.tver.co.jp speakerdeck.com

1年前に離れた会社に、また戻ることを選びました。 PdMとして、どう考え、どう決断したのか。そのリアルな記録です。 目次 ブーメラン転職ってどうなの？実体験から語る 自己紹介 転職したときは「もう戻らないつもり」だった（けど、少しだけ迷いもあった） 新しい環境での1年は、想像よりずっと早く過ぎた ふと「もう一度、あのチームで働くのもアリかも」と思った瞬間 戻る決断に迷いはあった。でも、それ以上に理由があった 同じ会社、同じ役割。だけど、見え方は全然違っていた この3年間を経て、自分なりにわかった「働く場所の選び方」 自己紹介 ラク スでPdMをしております、Wekky と申します。 現在の担当商材は、楽楽明細・楽楽精算です。 私のキャリアとしては、以下の変遷です。 インフラエンジニア：7年 PjM：3年 PdM：6年 転職したときは「もう戻らないつもり」だった（けど、少しだけ迷いもあった） 私は、約1年前に ラク スを退職いたしました。 しかし、2025年5月にブーメラン転職し、再び ラク スで働いています。 当時 ラク スから退職すると決めたとき、正直「実際 戻ることはないだろう」と思っていました。 せっかくやってみたいと思える会社に転職するのだから、新しい環境でしっかりキャリアを積もう。そんな気持ちでした。 でも、どこか心の片隅では「またあのチームで一緒に働けたらいいな」なんて気持ちもゼロではなかったというのが正直なところです。 そもそも何か ラク スに不満があって退職を選んだわけではなかったし、楽しかったからです。 そういう気持ちを持っていたことに対して、賛否あるかもしれませんが、それが自分のリアルです。 ※当時の私にとって「出ること」は前向きな選択だったし、それを今も後悔はしていません。 新しい環境での1年は、想像よりずっと早く過ぎた 転職先は、規模も 知名度 も高い企業で、事業としてはリアル対面が中心でした。 なのでIT目線で言うと、 OMO（Online Merges with Offline） な考え方が求められる環境です。 福利厚生や給与面も非常に整っており、働く環境としても充実していました。 転職後は、新しいカルチャーや人間関係、仕事の進め方に慣れることに集中していました。 PdMとしての役割は変わらなかったものの、組織の構造や意思決定の仕方がこれまでとは違っていて、戸惑うことも多かったです。 ありがたいことに、裁量をもって動ける場面もあり、新しい経験や学びもありました。 新プロダクト立ち上げの企画・採用〜リリース・運用までをかなりのスピードで行うことができました。 新プロダクトということもあり、5名ほどのスモールチームで進めました。 採用を含むチーム組成、プロダクトビジョンの設計、リサーチ、PRDの作成、GTM設計まで、すべて自分が主導で動く必要がありました。 ここまで裁量を持って動くことができた経験は、自分の中で貴重だと感じています。 気づけばあっという間に1年が過ぎていて、 そのスピード感に驚くと同時に、「このままここでやっていくのか？」という問いが少しずつ浮かんでくるようになりました。 今振り返ればすべて自分の責任であり、未熟さゆえなのですが 新プロダクトという特性上、短期成果が見えにくく、チーム内での巻き込みや支援を得るまでに時間がかかりました。 上長にも何度か相談はしていたのですが、組織やリソース状況もあって、なかなか思うようには伝わらないこともありました。 当時は余裕もなく、視野も狭くなっていたせいか、、周囲の意図やサポートにも気づけず、孤立感を覚えることもありました。 それでもチームメンバーと共になんとか食いしばってリリースし、会社への インパク トを少しづつ出せていける状況でした。 同じチームメンバーの優秀さに助けられました。 ふと「もう一度、あのチームで働くのもアリかも」と思った瞬間 そんな気持ちの中で、前職の上長（今の ラク スの上長）と話す機会がありました。 何気ない雑談のなかで、相変わらず楽しそうにプロダクトやユーザーの話をしている姿を見て、「やっぱりいいな」と感じてしまったんです。 「また戻りたい」とまでは思っていなかったけど、「あの雰囲気で、もう一度働けたら嬉しいかも」という気持ちは、確実に芽生えていました。 あの時、ちゃんと自分の気持ちを見つめ直してみようと思えたのが、後から考えると大きな転機でした。 戻る決断に迷いはあった。でも、それ以上に理由があった もちろん、戻ることに迷いがなかったわけではありません。 「一度出た会社に戻る」ことに対する葛藤や、「ちゃんと成長できていたか？」という自問もありました。 でも、最終的にもう一度その環境を選び直すことを決めたのは、シンプルに「自分が一番しっくりくる環境で働きたい」と思ったからです。 PdMとしてやりたいことに集中できる環境、人との相性、自分の価値を発揮できる場―― それらを考えたときに、自然と「戻る」という選択肢が前向きなものに見えてきました。 感情的にならずにフラットに考えて、「それでもやっぱりここがいい」と思えたことは、自分の中でも納得のいく判断だったと思っています。 同じ会社、同じ役割。だけど、見え方は全然違っていた 再入社してまず感じたのは、「懐かしい」よりも「意外と変わってるな」という印象でした。 組織も人もプロダクトも少しずつ変化していて、「あのときのまま」ではなかった。 でも一番大きかったのは、自分自身の見え方が変わったことです。 前よりも周囲の動きがよく見えるようになったり、物事に対する捉え方が少し柔らかくなっていたり、同じ役割でも以前とは違う感覚で仕事に向き合えているのを感じました。 たぶん、外に出たことで、自分の中の「当たり前」がアップデートされたんだと思います。 戻ってみて初めて、そういう変化に気づけたことがたくさんありました。 この3年間を経て、自分なりにわかった「働く場所の選び方」 転職して、戻ってきて、またPdMとして働いて。 この3年のあいだにいろんなことを考えて、悩んで、動いてきました。 結局のところ、「どこで働くのがいいか」って、事業内容や会社・組織のビジョンだけじゃ決まらないんですよね。 一緒に働く人との相性、価値観のフィット、そもそもの会社文化へのフィット、どれだけ自分がその場所で“意味”を感じられるか。 そういう感覚的なところが、思った以上に大きいなと。 これは私の話で、もちろん何を重視するかは人それぞれだと思います。 もう一度その環境を選び直したことが本当に正しかったのかは、これからもっと見えてくると思います。 でも今は、納得してここで働けている。 それが何より大きいです。 もし、同じように「戻るってどうなんだろう？」と迷っている人がいたら、 それは決して後ろ向きじゃない。 むしろ前向きに、自分の働き方を“選び直す”ということなんだと思います。

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

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

はじめに こんにちは、エンジニア３年目のTKDSです！ 今回はpg_query_goについて調べてみました。 業務で使用したこともあるのですが、改めて個人的に使ってみたいと思い、使い方をさくっと調べて試しました。 はじめに pg_query_goとは 簡単なサンプル 事前準備 中身をチラ見 実用例：SQLの操作を抽出 実用例：SQL実行種別のガードレール まとめ pg_query_goとは 実際の PostgreSQL の SQL パーサーを使って SQL クエリをパースして返してくれるライブラリです。 Goでも簡単に SQL の操作の取得などができてとても便利です。 github.com 簡単なサンプル 簡単なサンプルを使って、pg_query_goについて紹介します。 事前準備 事前準備をしておきます。 go mod init <プロジェクト名> 下記のサンプルコードをmain.goに保存します。 package main import ( "fmt" "log" "reflect" pg_query "github.com/pganalyze/pg_query_go/v6" ) func main() { sql := `SELECT id, name FROM users WHERE active = true;INSERT INTO テーブル名 (列名1, 列名2) VALUES ('値1', '値2');` treeStruct, err := pg_query.Parse(sql) if err != nil { log.Fatalf( "Parse failed: %v" , err) } // fmt.Println(treeStruct) fmt.Println(treeStruct.Stmts) fmt.Println( len (treeStruct.Stmts)) // SQL文が増えると列数が増える fmt.Println(reflect.TypeOf(treeStruct.Stmts)) fmt.Println(reflect.TypeOf(treeStruct.Stmts[ 0 ].Stmt)) fmt.Println(reflect.TypeOf(treeStruct.Stmts[ 0 ].Stmt.Node)) fmt.Println(reflect.TypeOf(treeStruct.Stmts[ 0 ].Stmt.Node)) fmt.Println(treeStruct.Stmts[ 0 ].Stmt.Node) fmt.Println(reflect.TypeOf(treeStruct.Stmts)) fmt.Println(reflect.TypeOf(treeStruct.Stmts[ 1 ].Stmt)) fmt.Println(reflect.TypeOf(treeStruct.Stmts[ 0 ].Stmt.Node)) fmt.Println(reflect.TypeOf(treeStruct.Stmts[ 1 ].Stmt.Node)) fmt.Println(treeStruct.Stmts[ 1 ].Stmt.Node) } pg_query_goは、Parseメソッドで引数として受け取った SQL を解析できます。 メソッド シグネチャ は func pg_query.Parse(input string) (tree *pg_query.ParseResult, err error) となっており、 pg_query.ParseResult 型のポインタ型とエラーを返します。 pg_query.ParseResult は github .com/pganalyze/pg_query_go/v6@v6.1.0/pg_query.pb.goに定義されている型です。 .pb.goの拡張子なので、おそらく プロトコル バッファから生成された型のようです。 サンプルではこの構造体をたどっていくように出力しています。　　 出力の一部を記載します。 これは一番最初の fmt.Println(treeStruct.Stmts) の出力 結果です。 [stmt:{select_stmt:{target_list:{res_target:{val:{column_ref:{fields:{string:{sval:"id"}} location:7}} location:7}} target_list:{res_target:{val:{column_ref:{fields:{string:{sval:"name"}} location:11}} location:11}} from_clause:{range_var:{relname:"users" inh:true relpersistence:"p" location:21}} where_clause:{a_expr:{kind:AEXPR_OP name:{string:{sval:"="}} lexpr:{column_ref:{fields:{string:{sval:"active"}} location:33}} rexpr:{a_const:{boolval:{boolval:true} location:42}} location:40}} limit_option:LIMIT_OPTION_DEFAULT op:SETOP_NONE}} stmt_len:46 stmt:{insert_stmt:{relation:{relname:"テーブル名" inh:true relpersistence:"p" location:59} cols:{res_target:{name:"列名1" location:76}} cols:{res_target:{name:"列名2" location:85}} select_stmt:{select_stmt:{values_lists:{list:{items:{a_const:{sval:{sval:"値1"} location:102}} items:{a_const:{sval:{sval:"値2"} location:110}}}} limit_option:LIMIT_OPTION_DEFAULT op:SETOP_NONE}} override:OVERRIDING_NOT_SET}} stmt_location:47 stmt_len:70] select_stmt , insert_stmt などの記述からSELECT、INSERTなどの区別がしっかりつくように解析されているのがわかります。 さらに、 fmt.Println(reflect.TypeOf(treeStruct.Stmts[ 0 ].Stmt.Node)) fmt.Println(reflect.TypeOf(treeStruct.Stmts[ 1 ].Stmt.Node)) の実行結果からNodeの型が SQL 操作種別を表していることがわかります。 *pg_query.Node_SelectStmt *pg_query.Node_InsertStmt 中身をチラ見 次に中身をチラ見してみましょう。 単純に気になったのでみてみただけです。 pg_query.Parse( sql )からたどってみます。 func Parse(input string ) (tree *ParseResult, err error ) { protobufTree, err := parser.ParseToProtobuf(input) if err != nil { return } tree = &ParseResult{} err = proto.Unmarshal(protobufTree, tree) return } 中では、 parser.ParseToProtobuf 、 proto.Unmarshal を呼んでいるようです。 それぞれの関数の説明、 ParseToProtobuf - Parses the given SQL statement into a parse tree (Protobuf format) 、 Unmarshal parses the wire-format message in b and places the result in m. The provided message must be mutable (e.g., a non-nil pointer to a message). から前者は SQL をパースしてProtobuf形式で出力し、後者はそれを読めるようにして、 proto.Message に格納するようです。 まずは、 parser.ParseToProtobuf から見ていきます。 func ParseToProtobuf(input string ) (result [] byte , err error ) { inputC := C.CString(input) defer C.free( unsafe.Pointer (inputC)) resultC := C.pg_query_parse_protobuf(inputC) defer C.pg_query_free_protobuf_parse_result(resultC) if resultC. error != nil { err = newPgQueryError(resultC. error ) return } result = [] byte (C.GoStringN(resultC.parse_tree.data, C. int (resultC.parse_tree. len ))) return } 中身はCGOを呼び出すコードになってました。 C がCGOに紐付いたライブラリを呼び出しているコードのようです。 Cで扱えるようにGoの文字列を変換したあと、 C.pg_query_parse_protobuf で解析し、またGoで扱えるようにしていました。 ここでProtobufの形式でやりとりしていたので、後にUnmashalが必要になるのですね。 戻って、次は proto.Unmarshal です。これは受け取ったメッセージをtreeに書き込んでいます。 treeの引数の型部分にあった proto.Message はただのInterfaceなので、実装は ParseResult が持っていそうです。 ParseResultのあるファイルの中身を探しているとStringメソッドがありました。 func (x *ScanResult) String() string { return protoimpl.X.MessageStringOf(x) } 今回出力されてる結果はこのメソッドの出力だと検討がつきました。 満足したのでこの辺にしておきます。 次からは簡単な実用例を示します。 実用例： SQL の操作を抽出 以下のようにパースしたあとに型の判別を追加します。 前述のように ParseResult.Stmts.RawStmt.Stmt.Node の型が操作種別を表しているようです。 そこで、型によって処理を分岐させることで、操作を抽出してみましょう。 package main import ( "fmt" "log" "reflect" pg_query "github.com/pganalyze/pg_query_go/v6" ) func main() { sql := `SELECT id, name FROM users WHERE active = true;INSERT INTO テーブル名 (列名1, 列名2) VALUES ('値1', '値2');` treeStruct, err := pg_query.Parse(sql) if err != nil { log.Fatalf( "Parse failed: %v" , err) } var opeType string for _, stmt := range treeStruct.Stmts { node := stmt.Stmt.Node switch node.( type ) { case *pg_query.Node_SelectStmt: opeType = "SELECT" case *pg_query.Node_InsertStmt: opeType = "INSERT" case *pg_query.Node_UpdateStmt: opeType = "UPDATE" case *pg_query.Node_DeleteStmt: opeType = "DELETE" default : opeType = "UNKOWN" } fmt.Printf( "操作種別：%s, 型：%v \n " , opeType, reflect.TypeOf(node)) } } 実行結果は以下の通りです。 操作種別：SELECT, 型：*pg_query.Node_SelectStmt 操作種別：INSERT, 型：*pg_query.Node_InsertStmt みごと２つの文とも操作種別の抽出ができました！ 実用例： SQL 実行種別のガードレール 前項で操作種別の抽出が可能になりました。 ということは、許可したクエリのみ実行できるように制限することも可能です。 さらにロジックを追加します。 今回はSELECTのみ許可するようにしましょう。 fmt.Printf("操作種別：%s, 型：%v\n", opeType, reflect.TypeOf(node)) を削除して、以下のロジックを追加してください。 ↓追加ロジック if opeType == "SELECT" { fmt.Printf("操作種別：%s, 型：%v\n", opeType, reflect.TypeOf(node)) } 出力は以下の通りで、SELECTのときのみ出力されるようになりました。 操作種別：SELECT, 型：*pg_query.Node_SelectStmt 今回はPrint文でしたが、 SQL などの実行処理の前にこの操作チェックをおけば、実行のガードレールとして使用可能です。 まとめ 今回はpg_query_goについて紹介しました！ SQL の解析が簡単にできて便利です。 実用例の活用方法として、ユーザー入力の SQL を実行する MCP サーバーなど作る場合に使えそうです。 他にも地味にいいポイントが、Goなのでビルドしてしまえば簡単に配布ができます。 実行も go mod tidy → go run main.go だけなので非常に試しやすいです。 ぜひ興味もった方はご自身の環境でためしてみてください。 今後は、pg_queryにWASM版もあるらしいのでそちらも試してみたいです。 ここまで読んでいただきありがとうございました！

どうも、 稲垣 です。 先日、 PM、PdM向けイベントを0からみんなで作る会 に参加しました 参加のきっかけは、これまでとは少し違った雰囲気のイベントだったこと。それくらいの軽い気持ちでしたが、参加してみると、たくさんの気づきがありました。 せっかくなので、ブログにまとめてみようと思います。 思ったことを、感じたままに綴ります。読んでくださる皆さんにとって、何かしらの学びや気づきになれば嬉しいです。 前置きが長いですが是非！（イベントの内容については、ブログの後半でレポート） プロダクトマネージャーの解像度のあげ方 そもそもプロダクトマネージャーって何者？ 「我々は何者か？」を明らかにすること ラクス？楽楽精算って聞いたことあるけど、どんな課題があるの？ 「漫画」ができたら、次は？ イベント登壇・対談・参加の新たな価値 まとめ 「PM、PdM向けイベントを0からみんなで作る会」の参加レポート 最後に プロダクトマネージャーの解像度のあげ方 現在、私は ラク スの「製品管理課」という組織でマネージャーを務めています。これまでの経歴としては、エンジニアを軸にしながら、さまざまな業務に携わってきました。 実は「PdM（プロダクトマネージャー）」という役割を知ったのは ラク スに入社したタイミングが初めてでした。私が入社した当時、 ラク スにはPdMという役割は、まだなく「製品企画」というポジションが事業部側に存在していただけでした。 では、私（稲垣）がどのようにPdMという役割を理解していったのかをお話しします。 正直なところ、入社当初はPdMという役割についてあまり意識していませんでした。 というのも、当時の製品開発には明確な課題があり、それを解決することが最優先だったからです。 その課題解決に、まずは1〜2年ほど集中して取り組みました。 その後、「 PdMの採用 」に向き合う必要が出てきたことで、改めてPdMという役割を 正しく理解しなければと考えるようになりました。 そこで、まずは基礎から学ぶために、PdM関連の書籍を3冊、徹底的に読み込むことから始めました ※ プロダクトマネジメントのすべて / プロダクトマネージャーになりたい人のための本 / プロダクトマネージャーのしごと 第2版 正直に言うと、本を読んだ感想としては、 　「 マインドセット や考え方は、これまで自分がやってきたことと大きく変わらないな 」 と感じました。対して「 PdMの役割がいまいちよくわからない 」とも思いました。 PdMでの転職・採用経験がある方ならわかるかもしれませんが、PdMという職種は、 求職者によってイメージが大きく異なり ます。前職では、エンジニア、デザイナー、営業、CS、バックオフィス、物流、ほぼ全ての採用、面接を1年ほど担当していましたが、それと比較しても業務内容のイメージのばらつきが大きいです。 さきほど紹介した書籍は紛れもなく良書で、書いてある内容も素晴らしいです。 でも、正直に言って 「本に書かれているような役割を、そのまま実践できているPdM」はいない と思います。これまで100人以上のPdMとカジュアル面談をしてきた中で、はっきりとそう感じたからです。 ちなみに採用初期のころは、カジュアル面談をせずに、いきなり面接をしていました。 「業務内容のイメージのばらつき」のせいで、かなり苦労しました。 私が面接で質問すると、相手は「なぜそんなことを聞くんだろう？」という反応。 逆に相手からの質問に対して、私も「なんでそんな質問を？」と戸惑うことも多くありました。 今思えば、求職者の方にとっても失礼なことをしてしまっていたと思います。 そもそもプロダクトマネージャーって何者？ ある人は「 ゴジラ 」みたいに圧倒的な力でプロジェクトを引っ張る存在だと言い、 ある人は「ルフィ」みたいに仲間を巻き込んで進んでいく冒険家だと言う。 「 リプリー （エイリアン）」のように未知と戦う人もいれば、「 ドラえもん 」のように未来の道具で課題を解決する存在だと語る人もいる。炭治郎、アトム、ゴン、 ケンシロウ 、イーサン・ハント… 出てくるのは漫画・アニメ・映画・実写・人間・ロボット、何でもあり。 ──そう、 みんな「PdM像」がバラバラ だったんです。 だからまずやったのは、 「我々は何者か？」を明らかにすること これを明確にしなければ、役割も、期待も、採用も、評価も全部ズレてしまう。 じゃあ、どうやったのか？ 「PdM」が含まれるイベントに参加しまくり、カジュアル面談でひたすら語り、聞きました 。 「PdMとは何か」「 ラク スにおけるPdMとは何か」 「我々の物語はどう始まり、どう進んでいくのか」 まるで映画や漫画の「企画会議」のように、 ラク スのPdMという "キャ ラク ター"を 言語化 していきました。それを「カジュアル面談資料」という漫画に、約40スライド程度で内容をまとめました。そして、毎回約15〜20分間、稲垣がカジュアル面談を通じて全力で伝えています。 多くの応募者からは、「聞きたいことが全部聞けました」とお褒めの言葉を頂いています。 ちなみに、 ラク スに入社してほしいという訴求は一切行っていません。 「費用対効果が悪くない？」という疑問もありますが、このカジュアル面談には以下のようなメリットがあり、むしろ費用対効果はよいです。 自分の言葉で話すことで、自分自身のPdMとしての解像度が上がる こちらから全情報を提供するため、相手の質問を通じて新しいPdM像が明確になる 選考ではないものの、質問の質などで相手のレベルがある程度わかる 違うと感じても「 ラク スのPdMは面白そう」と他のPdMに口コミしてくれる しかし、これまで行っても採用にはあまり効果が出ませんでした。。1名が入社し、内定は出したものの承諾には至らず）。その理由は明確でした。 ラク ス？楽楽精算って聞いたことあるけど、どんな課題があるの？ ラク スは、国内 SaaS 業界でベスト3に入り、最近では ARRが400億円を突破 しました。また、「楽楽精算」は導入社数で1位を誇っています。 しかし 、PdMや製品デザイン・開発を担当する人々の認知度とは、これらの実績が直接的に関連していない ことに気づきました。実際、これは弊社の技術広報の調査でも明らかになっています。 「漫画」ができたら、次は？ やるべきは ラク スの開発・デザイン・PdM組織の認知 どんなに素晴らしい映画や漫画を作っても、認知されなければ意味がないのと同じです。 そこで、2023年の2月から積極的にイベントに参加・登壇し出しました。 結果として、 　 2024年度には 　　　イベント登壇・対談が14回、参加が約40回（EMなどのイベントも含む） となりました。（対談・登壇は弊社技術広報の多大なる支援の成果でもあります） この活動のおかげで 　 　　4名のPdMを採用、リーダークラスのPdMや ドメイン エキスパート候補など 採用が好転し、入社した方々は現在、活躍していただいています。 また、私たち ラク スに PdMがいること や、 開発組織が「顧客志向」を強みとしていること が、これまでよりもは伝わったのではないかと思います。 イベント登壇・対談・参加の新たな価値 当初の目的は「採用」でしたが、最近ではそれ以外の価値も得られるようになっています。 イベントで多くのPdMと深く話すことで、実際にその業務を行わなくても、そのプロダクトのPdMをしているような感覚になることがあります。多くのPdMは 言語化 が得意で、非常にわかりやすく話してくれるため、そうした会話が貴重な経験となります。 村上春樹 　「本を読むということは、他人の人生を 追体験 することだ。」 イベントで話したり、聞いたりすることで、他のPdMの経験を 追体験 できるのです。 成長には経験が不可欠 です。 読書で知識は増えます。知恵はその知識を実際の体験にすることで生まれます 。 だからこそ、今は採用だけでなく、知恵を得るためにもイベント登壇・対談・参加しています。 2025年度は イベント登壇・対談・参加は前年度の2倍（登壇・対談 20回 /参加 80回） を行動目標としています。 また、内容もPdMやEMだけでなく、UXや組織に関連するテーマでも登壇していこうと考えています。 （2025年度からプロダクト部となり、デザイナーと同組織になりました） tech-blog.rakus.co.jp ですので、もしそういった依頼等あれば気軽にご連絡ください。 まとめ ここまで読んで気付いた人もいると思いますが、ここまでの話のプロセスやアクションはそのまま 「 プロダクトマネジメント 」 なんです。 プロダクトの解像度をあげるためインタビューやリサーチで多面的に捉える プロダクトの価値や強み、未来も描き、誰もがわかるように言語・資料化する プロダクトを伝える・届けるためにターゲットを絞って伝えていく これらをひたすら実施し続けて、最高の状態であり続ける PdMって面白くないですか？ PdMになる一番の簡単な方法は 『自分はPdMだと名乗ること』 だと思っています。 ラク スの製品管理課にご応募頂ければPdMになれますので是非ご応募ください。 career-recruit.rakus.co.jp と、ここまでが前置きです（笑）ここからがイベントレポートです 「PM、PdM向けイベントを0からみんなで作る会」の参加レポート このイベントはPdMのイベント参加者で創ろうという会です。 ROSCA 技術広報の @ROSCA_kota さんが発起人で、PdMのイベントでも良くお見かけする @uekiyuta1991 さん、 @gimupop さんがコ アメンバー で参加されていました。 会場は ジーニー さんの新宿のオフィスで、開催されました。 30名程度があつまり、イベント企画を考えるというイベントです。４-6人でチームをつくり、全６チームで約50分で企画を考えて発表するというイベントです。 自分のチームは主催の @ROSCA_kota さんと ジー ニーのPdMの方３名の５人チームでした。50分かなり濃度の濃い話をできて満足でした。 そして、本チームで考えた 「PMのMBTIを作る」 でした。 今回各チームが考えたものを投票をする形式でしたが、僅差ですが、 一位 となりました。（自分はツクルの大変なのわかったので、別チームに票を入れました） このア イデア ですが、これが本ブログの前置きの話につながります。 漫画、映画という抽象度が話より、『 ゴジラ 』『ワンピース』『 鬼滅の刃 』って決まってた方が深い話ができますよね？ 私はイベントで対談する機会が多いのですが、そのたびに「当社のPdMの業務範囲はここです」といった前提の説明を必ず行うようにしています。 なぜなら、ロードマップや評価の話をする場合でも、前提となる業務領域が共有されていないと、「それが自分にとって参考になるのかどうか」が判断しづらいからです。 実際にPdMイベントに多く参加してきた中で、自分自身が感じた大きなペイン（課題）がこの「前提のズレ」でした。 要は、 これから『 ゴジラ 』の話をします！ にしたい。 （ちなみに2025年5月現在、38本の ゴジラ 映画があるみたいです） PdMってかなり後発の役割だと思ったので、ChatGPT先生に聞いたら、こんな回答でした 以前にもリサーチしていて、なるほど思ったんですが、基本は 　 マーケティング とモノづくり の観点から誕生しています。 自分の解釈では以下の 「各職種領域」の中の「各業務」の一部を担っている のがPdMだと感じています。 「各職種領域」の中の「各業務」の一部が違うのがPdMをわかりづらくしている根底だと思っています。例えば以下のイメージが沢山あるのではないかと思います。 各職種領域の中の各業務を１０個程度定義してみて、各PdMが自分がやっている業務に〇をつけてみる。すると大きく１０～15個くらいのタイプにわけられるのではないか？と思っています。 さらにそのタイプは「製品フェーズ」「組織規模」「会社文化」「製品特性」で一定の共通点もある、あるいは全くない（どっちでも興味深い）のでは？と思っています。 そして、これがわかっていると同じタイプのPdMと話せばこれまで以上に前提情報が少なくても盛り上がることができるのではないかなと思っています。 最後に どうでしょうか？皆さん、作ってみたくなりませんか？ 正直、これまで自分がやったアクションでは無理なんです。具体的なPdMの実務まではイベント等で聞くのは難しく、仮にできても膨大な時間がかかります。 ChatGPT先生によれば、 国内IT企業のPdMは1～3万人と推定 されるようです。 仮に2万人だとすると 信頼水準： 95% → 約370人 80% → 約160人 70% → 約25人 信頼水準70%くらいなら30人のイベントで実現できてしまいます。 是非、共感された方は「いいね」や本ブログをXで「 #PdM_MBTI 」 ハッシュタグ 付きで拡散してもらえればと思います。

こんにちは、 稲垣 です。 2025年度からはイベント参加や登壇だけでなく RAKUS Developers Blog | ラクス エンジニアブログ や Rakus Designers Rakus Designers にも積極的に投稿して行こうかなと思っています。 Xでもプロダクトマネージャーのこと、デザイナーのこと、マネジメント全般なことをポストしていますのでよろしくお願いします。 前回は「フィッシュボウル」参加について書きましたが、今回はその翌週に参加した「速読会」について書きます。 この会ですが、今PdMの中では話題になっています。参加した方々の声がブログにノートであがっています ● ログラスさんの速読会に参加してきた話 ● 4月30日にログラスさんの速読会に参加してきましたレポート ● 3時間で6冊読む！人生を100倍速にする「速読会」に参加しました ● 社内速読会を開催してみました 自分が参加したのは、4/30(水)の会です(上記、noteの tkt さんと同じ会です。) 参加のきっかけはＸ等でこの話題を見て、別のイベントでお会いした @tomosooon さんに声をかけてからです。 （ちなみに本イベントはconnpass等での募集はないです。） いざ速読会へその前に 速読会スタート ポイント 感想 今回速読会で読んだ他の本 最後に いざ速読会へその前に 準備としては、未読・ 積読 していた 紙の本を３冊 の用意が必要です。 自分は以下の３冊を用意しました。 ● カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則 ３６２ページ ● ユーザーストーリーマッピング ３27ページ ● 世界は感情で動く : 行動経済学からみる脳のトラップ 357ページ ページ数を書いてますが、本の内容によりますが300ページ超えると結構しんどいです 速読会スタート ざっくりは以下の流れです。 読みたい本の相手とペアになります(人数は偶数がいい) 自分の本を15分で読み切ります(とにかく読み切るのがポイントです) 読み切ったらペアの相手に2分半で本の内容を説明します 今度は相手の本を15分で読み切ります（説明を受けているので、少し読みやすいです） 読み切ったらペアの相手に2分半で本の内容を説明します 上記を３回繰り返しますので以下の通り約３時間です。 　約3時間 ＝１セット 40分×3冊(セットごとで休憩各15分) 　 └ 自分の本：15分+（2.5分×2） + 相手の本：15分+（2.5分×2） さらに最後に以下の時間で読んだ本を思い出しながらまとめます（携帯でもPCでも何でもOK） 　 12分 ＝６冊×2分 今回は全体で30名程度実施しました ポイント ・相手への説明しないといけない、このゴールがあるため、頭をフル回転します ・目次から読む、まえがき、あとがきにまとめが書いてある等もありますが、このあたりは工夫次第 ・本は300ページ以内くらいがおススメです ・とにかく読み切るを意識するとよさそう ・同じ職種でやると本被るので、そこは注意 感想 ・ @tomosooon さんが仕事終わりに集まってひたすら、黙々と３時間ただ本を読む変態的な会ですと 話していましたが、まさにその通りでしたが学びは大きいです ・皆さんは、自社に持ち帰っていろんな工夫をしてやっているそうで、それは確かにと思いました 例えばこんな感じ 　└ 今回はPdMだったが、他の職種と混合やってみる 　　　 ⇒職種の相互理解に効果がありそう 　└ 1冊の本だけを複数の職種で速読会をやってみる 　　　　⇒いろんな観点でまとめがでるため、本をより立体的に捉えられる ・さすがにしっかりは読み切れないので、「正読」するかの判断するために非常に良い ・自分では手に取らない本の発見にもなってりその点でも良い 今回速読会で読んだ他の本 ● マッチング理論とマーケットデザイン ２３３P └ダントツで難しかったが、自分では手に取らないので学びが大きかった ● サイゼリヤ おいしいから売れるのではない 売れているのがおいしい料理だ 212ページ └良かったので、自分で購入して正読する予定 ● チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 35４ページ └出たの時に買って読んで、その後再読してなかったので、再読予定 最後に @tomosooon さん及び会場を提供してくださった ログラス さんに感謝です また、一緒に参加したタイミーさんやログラスの皆さん、他の皆様も同じ学びができてよかったです 6月は抽選制でオープンに集めてやるようですので、まだ体験してない方は是非！ loglass-tech.connpass.com

こんにちは、 稲垣 です。 2025年度からはイベント参加や登壇だけでなく RAKUS Developers Blog | ラクス エンジニアブログ や Rakus Designers note にも積極的に投稿して行こうかなと思っています。 X でもプロダクトマネージャーのこと、デザイナーのこと、マネジメント全般なことをポストしていますのでよろしくお願いします。 今回の内容は4/23(水)に「ゲスト」で参加したこちらについてです。 ※ PMフィッシュボウル 〜組織デザインってむずくない？編〜 非常に学びと良い経験ができたイベントだったので、書いておきます。 また、今後「フィッシュボウル形式」でのイベントや取り組みを検討している方へも参考になれば幸いです。 自分は「フィッシュボウル形式」は初で、「 OST 形式」は前職で経験がありました。ただ、今振り返れば OST 形式だったんだという程度でした。 人数はともかく、360度人に囲まれて話すという経験も初体験です。 余談ですが、 ログラスさん の新オフィスも初（以前の三田オフィスへ 対談イベント でお邪魔したことがあった）でしたが 、イベントに最適な綺麗なオフィスでした（ 泉岳寺駅 からもすぐ！） ■「OST」と「フィッシュボウル」とは？ ■『PMフィッシュボウル 〜組織デザインってむずくない？編〜』 ●前日談 ●当日 ■「 OST 」と「フィッシュボウル」とは？ まず、そもそも「 OST 」や「フィッシュボウル」って何？って人もいるので、O3さんに教えてもらいます。 ざっくり、こんな感じです。 まとめると ・「多並列で自由に動く OST 」 と 「1テーマを集中討議するフィッシュボウル」 　⇒広げたいときは OST 、深めたいときは フィッシュボウル なんとなくわかりましたか？詳しくは色々調べて見てください ———————————————————————————————— ■『PMフィッシュボウル 〜組織デザインってむずくない？編〜』 では、実際の中身に入っていきます……と言いたいところですが、具体的な内容はオフレコな話題が満載だったため、濃すぎて書ききれません。 そこで今回は、雰囲気やゲスト・参加者としての感想、そして今回の進め方を中心にお伝えします。 ●前日談 折角なので、前日談からです。 まず始まりですが、開催日の1.5ヶ月前くらいにXのDMで Joeさん から、「公開 OST 登壇」の依頼を貰いました。 主催者と自分以外のゲストを教えて頂き、1分考えて快諾しました。その後、2週間後に30分程度オンラインミーティングして、当日に至ってます。 時期的に TVer さんも ラク スもPdM周りの組織に大きな変化があり、その話の情報交換をして、これ以上ここで話すと、これだけでイベントができそうなので、それを骨子にするで決まりました。 Joeさん と yokomichi さん 、は「 発散と発散で収束させず結論は出さない 」という話くらいでした ●当日 ラク スはこの時期、通年の評価時期でして、自分は評価ミーティング後、 ダッシュ で滑り込みで到着しました 入った直後に、 Joeさん にこの話をしたら、フィッシュボウルで後半では見事にその話になりました。そのくらいシナリオなしの感じでした。 当日は ラク スからは6名ほど参加（何の因果か元 ラク スの方も参加していた） 事前に参加者にはslackへの参加が案内され、そこでは質問やら何やら五月雨のような投稿が、、、 1時間足らずで1,000を超える投稿が、最初は見てたが諦めました 基本は司会の Joeさん とフォローの yokomichi さん に身を預けるスタイル 様々な会社のPdMが自社の話や自分の体験を話す（同時に複数のイベントのLTを聞いた感覚） 話は 　ミドルの上位からシニアや組織マネージャークラスのPdMの話 　かつ、 toB 、 toC 、規模や製品フェーズも違うわ、単一プロダクトからマルチプロダクト 様々 聞いているだけで、体力と知力の消耗が激しかったです。 そこから間髪入れずに懇親会へ。 参加者のレベルも高く、フィッシュボウルの話からそのまま懇親会に入ったため、会場のあちこちでミニフィッシュボウルが開催されているような状態でした。 何かよくわからない達成感のなかで、皆さん会場を後にされたと思います。 話せる範囲で内容を共有すると、大きくはこの2つのテーマでした PdMを取り巻く組織デザイン。PdMは開発側・事業側・その中間のどこに置くべきか？ PdMの評価はみんなどうしているのか？ こちらは当日の模様 ※ Xより ●感想 疲れるが、かなり心地よい疲れ。 発散、発散、また発散…なのに、不思議とモヤモヤが残らない。 準備はいらないが、「話す覚悟」は必要。 ファシリテーター の重要性と、そのキャスティングもかなり大事。 社内でやってみるのも面白そう。 ● ラク スから参加したPdMメンバーの感想 あんなにぶっちゃけた社内の事情は聴けない。とんでもない情報量で聞いて理解するのが精いっぱいだったが、組織のことをあんなに真剣に考えているもの、視座、視野の広さを知れたのは良かった。今後のマルチプロダクト構想に対して準備しておくことがわかった気がした プロダクトマネージャーの組織/立ち位置として、色々聞いてなんやかんか今のPdM-PMM体制自体は結構いいのではと思った。作る（開発）/届ける（事業部）で役割分担しやすいため。PdM-PMMが何らか共通のKPIを追う構図になっていれば、PMという共通の役割で動けるので更に良いかも（＋それぞれの責任範囲のプロセスや成果を評価）一方でレポートライン（事業責任者）が事業部側にいる都合一定の不均衡は起きる可能性はある（良し悪しではなく）　 第2回「EM/PMフィッシュボウル」編、6月2日(月)にやるそうです 6/2月、みなさん空けておいて下さい！ 前回の #PMフィッシュボウル の好評を受け、次回はパウリさん（ @pauli_agile ）と一緒に「EM/PMフィッシュボウル」を開催します！！ EMとPM、違う立場と視点から見た「組織デザイン（価値創造）」について、白熱の議論をぶち かまし ます！ 近日connpassは公開！ pic.twitter.com/KZ8RzcdSi4 — Joe Hirose | ログラス ProductHR (@JoE_HiRose) 2025年4月29日 是非、皆さん体験してみてください。（自分も参加予定です）

こんにちは。 株式会社 ラク スで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（ @moomooya ）です。 ラク スでは社内独自指標での開発生産性指標の計測を行ってきましたが、今年度からFindy Team+を開発本部全体に導入しFour Keysをベースとした計測 1 に切り替えてきました。 今回はFindy Team+導入に関する記事を書こうと思います。 導入と経緯 課題 経緯 ファインディ社との関わり 開発生産性カンファレンス 指標のハックについてはひとまず考えない Findy Team+ 検討、仮決定 内製でやるのは結構大変そう 試用期間 2チームでスモールスタート 全チーム本格導入 今後やっていきたいこと 導入と経緯 課題 ラク スではもともと 工数 見積もりをベースにした独自の生産性指標を利用していました。 ただしこの独自指標には以下のような問題が生まれていました。 見積もりを過大にすることで数値をハックできる 見積もり精度を高める取り組みは重視されていなかった 個人目標に利用されていた 特に1つ目については、見積もりを過大にすることで見かけの成果物の量が多くなり、見かけ上の指標値を良くすることができました。 指標値を良くするために過大見積もりを行う、というほど悪意のある行動はなかったかと思いますが、見積もりを小さくするための取り組み――技術的負債の低減、見積もり精度を上げて作業バッファを低減する、など――に対する取り組みが、数値上の成果に繋がらないため行いにくくなってしまっていました 2 。 経緯 そんな中、 DORA によって発表されていたState of DevOps Reportに出てくるFour Keys 3 が書籍『 LeanとDevOpsの科学 』の影響もあり注目されてきました。 LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ 作者: Nicole Forsgren Ph.D. , Jez Humble , Gene Kim , 武舎広幸 , 武舎るみ インプレス Amazon Four Keysを知った当初は、 ラク スのサービスがBtoBであることもあり、1日に何度も本番環境にデプロイするなどの状況がイメージできない 4 事もあって導入に関しては懐疑的でしたが、その後 SPACEフレームワーク の考え方を知ることで、「Four KeysもSPACEの（特にPerformance）を軸にした指標群の一例であり、成果物の産出量、レビュー数、割り込みの発生頻度（≒不具合発生頻度）など 複数の観点で計測することが重要で、これらがそれぞれカウンター指標として機能する 」という考えに至りました。 queue.acm.org これにより、自社で計測する指標としてFour Keysをベースとしながら、自社に合わせた指標にカスタマイズして採用していくことにしました。 オリジナルのFour Keysとの大きな違いは「本番環境へのデプロイ」を軸にするのではなく「開発者からの手離れ」を軸に置き換えています。 デプロイの頻度 本来は「変更を本番環境にデプロイした回数」 ラク スでは「コードレビューを終えて、メインブランチにマージされた回数」 変更のリードタイム 本来は「最初の変更コミットから本番環境にデプロイされるまでの所要時間」 ラク スでは「最初の変更コミットからメインブランチにマージされるまでの時間」 変更失敗率 本来は「デプロイに対して、本番環境で不具合が発生する割合」 ラク スでは「プルリク エス トに対して、不具合修正プルリク エス トの割合」 サービス復元時間 本来は「本番不具合発生から正常な状態に戻るまでの時間」 ラク スでは「不具合修正プルリク エス トがマージされるまでの時間」の予定 5 特に「デプロイの頻度」という項目ではフィーチャーフラグなどを駆使して、本番デプロイ回数の計測のままにしようかとも検討しましたが、フィーチャーフラグでオフにしているのであれば結局はユーザーへの価値提供はできていないため、ここにこだわる理由は見つけられませんでした 6 。 指標までは検討できたので、実際の計測基盤をどうするかという段階に話が進みます。 ファインディ社との関わり 開発生産性カンファレンス 多少時間は前後しますが、新たに開発生産性を計測していくにあたって2023年に開催されたファインディ社が主催する「開発生産性カンファレンス」に参加しました。 このカンファレンスで行われたニコール・フォースグレン博士の発表にて、当時はまだ今ほど知られていなかったSPACE フレームワーク について理解を深めることができました。今ならネットで検索したり、ChatGPTに聞けば教えてくれるはず。 指標のハックについてはひとまず考えない また社内で導入することを考えると指標のハックについても話題に上がることを考えて、カンファレンスの懇親会でお話させていただいた各社に実際の運用を聞いて回りました（話に付き合っていただいた皆様ありがとうございます）。 各社の運用を聞いていると 「ある程度ハックされることは想定しているが、あまり気にしないようにしている」 「極端なハックは逆に仕事がしにくくなると思うのである程度で抑制されると考えている」 といった回答が多かったです。 確かにマージ件数を増やすためにプルリク エス トを細分化すると言っても、1行ずつ分割してたらレビュアーに怒られると思いますし 7 、開発業務のオーバーヘッドは逆に増えて面倒になると思います。 Four KeysやSPACE フレームワーク の考え方の則って取り組む場合には、複数の指標を用いてそれらがある程度カウンター指標となることが考えられるので、ひとまずは余計なことは考えずに導入を進めることにしました。 Findy Team+ 検討、仮決定 というわけで自社でどんな計測を行いたいのかがある程度固まってきたので、計測ツールについての検討を始めました。いくつかの開発生産性計測サービスと内製によるシンプルな計測と比較していく中で Findy Team+ を提供するファインディ社にも問い合わせを行いました。 何社か話を聞いていく中で、コスト面で折り合いがつかなかったり、開発体制の厚さが ラク スの基準に合わなかったりという形で残ったのが、Findy社の Findy Team+ でした。 内製でやるのは結構大変そう 内製についても検討しましたが、 GitHub からデータを収集し、「マージ回数」「1日あたりマージ頻度」「PRあたりの平均リード時間」を算出するくらいまでは作成したものの、社内で運用保守していくにあたって 片手間でやるには大変で、専任メンバーを割り当てるのも悩ましい 8 ということがわかり、専任メンバーを当てるコストを考えたら クラウド 型の計測サービスの利用を優先的に考えたほうが良さそうだという判断を行いました。 組織がもっと大きくなり、専任のチームを設置できるくらいの規模であればできそうですが、 ラク スではまだ少し厳しそうです。 試用期間 Findy Team+の利用を仮決定したものの、実際に導入して（想定した運用の手間で）運用可能なのかという判断が必要になります。 Findy社に問い合わせて試用をお願いして、Team+を実際に触る機会をもらいました。 場合によっては内製化というパターンも完全には消えていないので、生産性計測に何が必要なのかという学習も兼ねて各機能を触っていきました。 ちょっと機能が豊富すぎて「オーバースペックかなぁ……」という感想は抱きましたが、一方で 主要指標で問題の芽を見つけたときに原因分析していくことを考えるとある程度細かく数値を取れていないと難しそう（＝ある程度の機能が必要） だな、という感想も持ちました。 また、試用期間中にも新機能のリリースが頻繁に行われており、なにか機能要望があったときの反映にも期待できそうだという感想を覚えました。 2チームでスモールスタート その後、比較的新しい2つのチームに対して、試験的にFindy Team+を導入しました。 これらのチームは開発生産性に興味を持っていたということに加えて、比較的モダンな 開発プロセス を採用しており、細かな開発ルールについても柔軟に改善できる段階にありました。指標をもとに議論を始めやすいフェーズと考え、導入効果が見えやすいのではという仮説のもと選出しました。 当初の見立てではチームに計測の概念が浸透し、実際のアクションや改善につながるまでには少なくとも半年はかかるだろうと予想していました。 しかし、導入から2ヶ月目あたりで早くもいくつかの数字に変化が現れ始め、3ヶ月目には改善効果として有意な差が見られるという予想以上のスピードでチーム内の行動が改善していることが観察されました。 具体的には プルリク エス トのサイズが小さくなり、プルリク エス トあたりのリードタイムが短縮 。プルリク エス トごとのレビュー難易度が低減されたため、 偏りのあったレビュアーが分散され、レビュー待ちの ボトルネック が解消される 、といった傾向が見られました。 全チーム本格導入 導入済みチームで数字に変化が現れ始めたことを受けて、社内へのさらなる展開を進めるためにフローの整備を始めました。 単にツールを導入するだけではなく、「なぜこのツールを使うのか」「どんな成果が期待できるのか」を社内にしっかり伝え、各チームの導入モチベーションを高めることが重要だと考えています。 そこで、まずは 導入済みチームで実際にどのような効果が出ているかを紹介する勉強会を企画 しました。 この勉強会では、Findy社にも全面的にご協力いただき、開発生産性の考え方や使い始めたときのコツ、導入済みチームで出ている成果を第 三者 視点から紹介してもらう機会を設けることができています。 プルリク エス ト作成数やプルリク エス トのレビュー時間などの具体的な改善事例を共有しつつ 数字をもとにした改善ポイントの見つけ方 改善サイクルの回し方 についても紹介してもらいました。 実際に成果が出ているチームの様子や、Findy社からのリアルな説明を受けたことで、「自分たちのチームでも試してみたい」「改善に役立てられそうだ」という前向きな反応を引き出すことができました。 この取り組みをきっかけに、興味を持ってくれるチームの導入モチベーションを刺激することができたと思います。 興味をもってくれているチームから順次導入する ことで社内文化として定着させ、スムーズに浸透させていければと考えています。 今後やっていきたいこと 現在、導入済みのチームでは指標上の数値が徐々に改善傾向を見せており、一定の成果は見え始めています。 ただし、数値が改善しているからといって必ずしも現場の体感としても「良くなった」と感じられているとは限りません。 今後はメンバーへの ヒアリ ングを実施し、主観的な働きやすさやチームの健康状態にも目を向けていく予定です。 特に SPACE フレームワーク における「S（Satisfaction and well-being）」の観点を意識し、数値だけでは拾いきれない現場の声を把握しながら指標と実態のズレがあれば、それを補正していきたい と考えています。 まだFindy Team+の導入が進んでいないチームに対しても、適切なタイミングでフォローを続けていく必要があります。 単なるツールの押し付けにならないよう、各チームの状況や課題感に寄り添いながら、必要性を一緒に整理していく支援を進めていきたいと思っています。 queue.acm.org Four Keysを元にしていますが、厳密にはFour Keysではありません。おおまかにはデプロイを基準にしている部分を、レビュー後のマージに置き換えた考え方で定義しています。当初は本来の定義を変えることに疑いがあったのですが、SPACE フレームワーク の考え方に則って考えれば問題ないだろうと判断しています。 ↩ 実際は各種改善は行われていましたが、用いていた生産性指標の上では成果が現れないため、評価者が個別に取り組みを評価する手間が発生していた。 ↩ Four Keysはソフトウェアデリバリーのパフォーマンスを表す4つの指標ですが、2022年版以降には追加の指標として運用パフォーマンスを表す「信頼性」が提唱されています。 ↩ サービス利用されている顧客の中には自社内で利用マニュアルを整備していることも多々あり、事前通知が必要だったり、頻繁な新機能リリースやデザイン変更はクレームの元になると考えています。 ↩ サービス復元時間の計測はまだ本格的には行えていません。 ↩ こまめにデプロイすることでデプロイを日常業務として効率化を図る、という観点は捨てがたいところもありましたが、これを実現するのは生産性計測の取り組みではなくデプロイの仕組みやデプロイフローの見直しを行うべきで、それが終わるまで開発生産性が上がらないというのも計測の意味がなくなるので現状はこのようにしています。もちろん毎日でもデプロイできる仕組みができたら計測の基準を見直すかもしれません。 ↩ 私も説教すると思います。マージ件数をカウントする意味とか、プルリク エス トを細分化する意味とか、レビュー効率の話とか、逆に長引くくらいに。 ↩ 社内に開発生産性のプロを抱えたいというわけではないので……。 ↩

はじめに こんにちは、エンジニア３年目のTKDSです！ 最近 MCP が盛り上がってます。 流れに乗ってGoでやる方法を調べて試してみました！ まず簡単に現在時刻を返す MCP サーバーを作ったあと、割と実用的に使えそうなファイルを連結して返す MCP サーバーを作っていきます。 今回書いたコードの リポジトリ です。 https://github.com/tkeshun/mcp はじめに MCPとは？ 今回使用するライブラリ 現在時刻を返すMCPサーバー 1. プロジェクトの準備 2.コード作成 3. パッケージのダウンロードとビルド 4. 試す 特定のディレクトリ以下のファイルを返すMCPサーバー まとめ MCP とは？ MCPのドキュメント によると MCP is an open protocol that standardizes how applications provide context to LLMs. 要するに、LLMが外部リソースとアクセスする約束事を決めてくれたみたいです。 MCP についての詳細はは他に詳しい記事がたくさんあると思うのでそちらに譲ります。 では早速つくっていきましょう！ 今回使用するライブラリ 今回使用するライブラリは mcp -goです。 github mcp server で使われてたので採用しました。 go.mod https://github.com/mark3labs/mcp-go では、実装に移っていきます。 現在時刻を返す MCP サーバー 今回はサーバー経由で計算して結果を返すのでtoolsを使います。 toolsには、利用可能なツール一覧を表示する tools/list と実際に叩かれるtools/callが必要なようです。 Discovery: Clients can list available tools through the tools/list endpoint Invocation: Tools are called using the tools/call endpoint, where servers perform the requested operation and return results mcp -goでは mcp .NewTool関数を使えば作れそうです。 では実際に作ってみましょう。 Goでの準備方法書いてますが知ってる人は飛ばしてOKです。 1. プロジェクトの準備 mkdir mcp-time-server go mod init mcp-time-server 2.コード作成 以下のような感じです。 サンプルを参考に書きました。 AddToolsの定義見た感じ、処理の関数はserver.ToolHandlerFunc型を満たしていればよさそうです。 まず、NewMCPServerで MCP サーバーを作ります。 次に、 mcp .NewToolで登録するtoolの素を作ります。 そして、s.AddToolでtoolと処理を紐付けて登録します。 最後に標準出力を受け付けるようにサーバー起動します。 package main import ( "context" "fmt" "time" "github.com/mark3labs/mcp-go/mcp" "github.com/mark3labs/mcp-go/server" ) func main() { s := server.NewMCPServer( "時刻答える君" , "0.0.1" ) currentTimeTool := mcp.NewTool( "current_time" , mcp.WithDescription( "現在時刻を返します" ), ) s.AddTool(currentTimeTool, func (ctx context.Context, req mcp.CallToolRequest) (*mcp.CallToolResult, error ) { jst := time.FixedZone( "Asia/Tokyo" , 9 * 60 * 60 ) now := time.Now().In(jst) message := fmt.Sprintf( "現在の時刻: %s" , now.Format( "2006-01-02 15:04:05" )) return mcp.NewToolResultText(message), nil }) if err := server.ServeStdio(s); err != nil { fmt.Printf( "サーバーエラー: %v \n " , err) } } 3. パッケージのダウンロードとビルド MCP サーバーを起動したときのPathの関係とかがよくわからないので、今回はビルドして MCP クライアントを起動する場所におきました！ go mod tidy go build -o current-time-server 4. 試す inspector を使います。 README.mdに載ってるconfig. json をもとに適当に書き換えました。 一回起動してみると、 everything が選択肢にあったのでおそらくそこがサーバー名です。なので、そこ以下の値を書き換えていきます。 項目は Github Copilot Chatの設定と変わらないので、特に迷うことはないと思います。 commandに起動するバイナリ名、argに引数、envに 環境変数 を書きます。項目名にちょっとDockerfileっぽさを感じます。 今回はcommandだけで大丈夫です。 { " mcpServers ": { " current-time ": { " command ": " current-time-server ", " args ": [] , " env ": { } } } } ファイルの配置はこんな感じです。 . - current-time-server(Goのバイナリ) | - config.json では起動します。 npx @modelcontextprotocol/inspector --config ./config.json --server current-time で起動できます。 ↓出力 $ npx @modelcontextprotocol/inspector --config ./config.json --server current-time Starting MCP inspector... ⚙️ Proxy server listening on port 6277 🔍 MCP Inspector is up and running at http://127.0.0.1:6274 🚀 起動するとこんな画面になります。 Connectを押して、List Toolsボタンを押すと、以下のような画面になります。 tools/listエンドポイントを叩いて、ツール一覧を取得してるようです。 表示されるメッセージは、 currentTimeTool := mcp.NewTool("current_time", mcp.WithDescription("現在時刻を返します"), ) に書いたやつなので、 mcp -goでは、 mcp .NewToolの宣言時に書いたものがlistで返される値になるようです。 current_timeを押すと、以下のようにRun Toolボタンが表示されます。 これを押すと mcp サーバーが実行されます。 無事現在時刻が表示されました！👏 以上が MCP サーバーの簡単な作り方でした。 特定の ディレクト リ以下のファイルを返す MCP サーバー AI Agent搭載エディターはファイル探してコンテキストに取り込んでくれたりしますよね？ ただ、探す時間が長かったり、検討違いしてたりするケースがままあります。 そこで、最初からほしいコードを返してくれる MCP サーバーがあればいいのでは？と思い、作ろうとしました。 ソースコード は以下に載せておきます。 指定した ディレクト リのファイルを検索し、返してくれる処理を実装してます。 設定ファイルを外出しして、Goプログラムをいじらずにエンドポイントを作れるようにしました！ package main import ( "context" "encoding/json" "fmt" "log/slog" "os" "path/filepath" "strings" "github.com/bmatcuk/doublestar/v4" "github.com/mark3labs/mcp-go/mcp" "github.com/mark3labs/mcp-go/server" ) type QueryConfig struct { Name string `json:"name"` // クエリ名 Description string `json:"description"` // MCP説明 Dir string `json:"dir"` // 環境変数ROOT_ENVからの相対パス PathPattern string `json:"path_pattern"` // パスパターン（glob） } func loadConfig(filename string ) ([]QueryConfig, error ) { file, err := os.ReadFile(filename) if err != nil { return nil , err } var cfg []QueryConfig err = json.Unmarshal(file, &cfg) return cfg, err } func concatFilesWithGlob(root, pattern string ) ( string , error ) { var builder strings.Builder matches, err := doublestar.Glob(os.DirFS(root), pattern) if err != nil { return "" , err } for _, match := range matches { fullPath := filepath.Join(root, match) data, err := os.ReadFile(fullPath) if err != nil { continue } builder.WriteString(fmt.Sprintf( "==== %s ==== \n " , match)) builder.Write(data) builder.WriteString( " \n\n " ) } return builder.String(), nil } func main() { // 環境変数取得 rootDir := os.Getenv( "ROOT_DIR" ) if rootDir == "" { panic ( "環境変数 ROOT_DIR が未設定です" ) } configPath := os.Getenv( "CONFIG_PATH" ) if configPath == "" { slog.Error( "CONFIG_PATHが未設定" ) } // MCPサーバー初期化 s := server.NewMCPServer( "Dynamic MCP Server" , "1.0.0" ) // 設定ファイル読み込み configs, err := loadConfig(configPath) if err != nil { slog.Error(fmt.Errorf( "設定ファイル読み込み失敗: %w" , err).Error()) } // 各ツールを登録 for _, cfg := range configs { tool := mcp.NewTool(cfg.Name, mcp.WithDescription(cfg.Description), ) localCfg := cfg // クロージャで固定 // rootDir + cfg.Dir に解決（再帰探索のベース） fullSearchRoot := filepath.Join(rootDir, localCfg.Dir) s.AddTool(tool, func (ctx context.Context, req mcp.CallToolRequest) (*mcp.CallToolResult, error ) { result, err := concatFilesWithGlob(fullSearchRoot, localCfg.PathPattern) if err != nil { return mcp.NewToolResultError(fmt.Sprintf( "ファイル探索エラー: %v" , err)), nil } return mcp.NewToolResultText(result), nil }) } // 起動 if err := server.ServeStdio(s); err != nil { fmt.Printf( "サーバーエラー: %v \n " , err) } } config. json は次のようになってます。 ROOT_DIRに対象にしたいプロジェクトのルート ディレクト リのパスを書きます。 GONFIG_PATHにはクエリや走査対象の ディレクト リを書きます ↓config. json { "mcpServers": { "current-time": { "command": "./current-time-server", "args": [], "env": { } }, "file-finder": { "command": "./mcp-file-finder", "args": [], "env": { "ROOT_DIR": "./test", "CONFIG_PATH": "./finder-config.json" } } } } GONFIG_PATHのほうにはエンドポイント名、LLMへの説明、走査対象 ディレクト リ、マッチさせるファイルパターンを書きます。 ↓finder-config. json [ { "name": "docs_query", "description": ".vscode以下の情報を取得します。vscodeなどの設定がほしい場合に使用してください", "dir": "./github-mcp-server/.vscode", "path_pattern": "**" }, { "name": "e2e_code_query", "description": "ソースコードファイルを読み込みます。E2Eテストのコードです。", "dir": "./github-mcp-server/e2e", "path_pattern": "**/*.go" } ] 実際に叩いてみると以下のようにファイル内容を取得できます。 まとめ 今回は MCP サーバーを２種類作ってみました！ mcp -goは非常に簡単に MCP サーバーを作れ、Goバイナリにできるため、配布・使用が非常に簡単です。 ２つ目のプログラムについては実用性も非常に高いと思います！ 記事を見た皆さんもぜひ試してみてください！

こんにちは、プロダクト部副部長の 稲垣 です。 2025年4月から、プロダクトデザインの組織とプロダクトマネージャーの組織が、同じ「プロダクト部」という部門に統合されました。 マルチプロダクトでサービスの開発・運用を行う企業にとって、「製品づくりの組織デザイン」をどう構築するかは、各社が試行錯誤を重ねているテーマだと思います。本記事が、少しでもその参考になれば幸いです。 この記事では、以下の4点について紹介します： ラク スにはどんな製品があり、どのような組織体制なのか デザイナーとプロダクトマネージャーは、これまでどのように連携してきたのか 今回、なぜ「プロダクト部」が立ち上がったのか 「プロダクト部」はどのような役割を担うのか ラク スはどんな製品を提供しているのか 2025年4月現在、 ラク スでは10個の製品を提供しています（ ラク スライト クラウド 提供の2製品を含む）。最も古い製品は2001年にリリースされ、最も新しい製品は2024年10月に提供を開始しました。製品ごとに成り立ちの時期には大きな差があります。そのうち半数の製品はARR（年間経常収益）で25億円を超えており、最大の製品では100億円を超える規模となっています。 どんな組織体制になっているのか ご覧のとおり、組織は大きく「開発部門」と「事業部門」に分かれており、その中に各商材ごとの組織が存在しています。 開発部門は主に拠点別（東京と大阪）に分かれており、それとは別に「横断開発部門」も設けられています。 PdM（プロダクトマネージャー）やQA（品質保証）は、商材ごとの開発組織内に数名配置されているケースもあれば、PdM・QAとして組織化されているケースもあります。プロダクトデザインについては横断開発部門内に集約されており、すべての商材を対象とした一つの組織として機能しています。 デザイナーとプロダクトマネージャーはこれまでどう連携をしていたのか プロダクトの4階層をベースに役割分担を定義すると、以下のようになります。 ここまできれいに分担されているケースは稀ですが、書籍や他社のプロダクトチームの役割分担を一般化すると、このような形になると考えています。 実際には、企業の組織体制や製品フェーズによって、一人が複数の役割を担うことも多く、以下のようなケースもよく見られます。 コア領域において、事業責任者がPMM（プロダクト マーケティング マネージャー）やリーダーPdM（プロダクトマネージャー）を兼任 ディスカバリー において、UXデザイナーが不在のためPdMがその役割を担う デリバリー（開発）において、PdMがPjM（プロジェクトマネージャー）を兼任 デリバリー（GTM：市場投入）において、PMMが不在でPdMがその役割を担う ラク スにおいても、役割分担は製品によって大きく異なるのが現状です。 PdM組織は2021年8月に新設され、「楽楽精算」を皮切りに本格的なPdMの組織化が始まり、約3年半が経過しました。 ※PdM組織（製品管理課）の新設については こちら をご覧ください（マルチプロダクトのPdMのリアルについては こちら ） PdM組織が立ち上がったことにより、 プロダクトデザイナー の役割も以下のように変化しました。 ——————————————————————————— ■PdM新設前 ・ ディスカバリー では、開発の上流やPMMと単独で連携 ・デリバリーでは、開発と直接連携 ■PdM新設後 ・ ディスカバリー では、デザイナーとPdMがPMMやCS／営業と連携しながら、お客様インタビューも実施 ・デリバリーでは、開発と連携（必要に応じてPdMがサポート） ——————————————————————————— PdM新設後、 プロダクトデザイナー はよりデザイン業務に集中したり、 ディスカバリー に積極的に参加したりできるようになりました。 その結果、理想とする役割分担の形に、少しずつ近づきつつあります。 今回、何故プロダクト部が立ち上がったのか 前置きが長くなりましたが、ここからが本題です。 今回、なぜこのタイミングで「プロダクト部」が新設されたのかについてご説明します。 まず前提としてお伝えしたいのは、たとえ組織（部）が別であっても、さまざまな取り組みを推進することは可能だということです。 実際に「楽楽精算」では、横断組織と拠点別の組織が別部門で運営されていましたが、それでも プロダクトデザイナー の役割分担の見直し・進化を実現できました。 ただし、これと同じ取り組みを同じ組織内で行っていたとすれば、より早く、スムーズに実現できた可能性があるとも考えています。 この考え方が、これから述べる「発足経緯」の前提になります。 この３つに集約されます。 １．複数サービス利用推進 楽楽シリーズではこれまで、バックオフィスのDX化に向けて「ベスト・オブ・ブリード型製品開発戦略」を採用してきました。 そして今後も、この戦略を継続していく方針です。 楽楽シリーズは、バックオフィス業務を効率化・DX化する製品を提供する中で、複数の製品をご利用いただくお客様が増えてきました。 シリーズには、従業員全体が利用するような「楽楽精算」や「楽楽勤怠」のような製品もあれば、特定の部門で使われる「楽楽販売」のような製品もあります。 これらの製品は、サービス開始時期が異なるだけでなく、「ベスト・オブ・ブリード型製品開発戦略」を採用したことにより、同じ楽楽シリーズであってもUXが各製品に最適化されすぎており、シリーズ全体としての一貫性に課題が生じるケースもあります。 また、 ラク スは2023年10月に以下のような発表を行いました。 「 ラクスが展開するバックオフィス向けクラウドサービス2023年10月よりブランド統一し、コミュニケーションを刷新 」 こうした背景を踏まえ、楽楽シリーズをご契約いただいているお客様や、これからご検討いただくお客様が、複数サービスをよりスムーズにご利用いただけるように、ブランド統一と、お客様のメンタルモデルを揃えるようなデザインへの移行が必要になってきました。 そのためには、デザイナーとPdMがこれまで以上に強く連携し、各製品間の連携もこれまで以上に意識して取り組んでいく必要があります。 これが、プロダクト部発足の経緯のひとつです。 2．UXの重要性 先に説明したとおり、 ラク スが提供している製品は、最も古いもので2001年、最も新しいもので2024年10月と、製品の成り立ちには大きな開きがあります。 また、各製品が属する市場の成熟度にも大きな差があります。 これは一般論ですが、 市場が成熟してくると、多くの製品の機能は コモディティ化 （機能の同質化）していきます。 そして、 コモディティ化 が進むと、価格競争が激化する傾向にあります。 ここでは価格競争そのものについては触れませんが、「製品価値」という観点で考えると、機能が同質化している状況下では「UX（ユーザー体験）」が差別化要因となり得ると感じています。 新しい機能を開発することももちろん重要ですが、UXを継続的に改善していくには、それを推進するためのリソース確保が不可欠です。 その際、デザイナーとPdMが同じ組織にいることで、お客様のUXに関わる課題を、同じ解像度で把握しやすくなります。 その結果、より高い価値を、より早く提供することが可能になります。 このような考えも、プロダクト部発足の背景の一つとなっています。 ３．AI x SaaS の推進 2023年3月にGPT-4を搭載したChatGPTが登場して以降、業務生産性の向上だけでなく、生成AIの製品活用も一気に加速しました。 それと同時に「AIエージェント」という概念も徐々に注目されはじめ、特に2024年以降は、「 Microsoft Copilot」「 Google Gemini」「Notion AI」など、業務支援を目的としたエージェントが本格的に実装され始めました。 さらに2024年3月に「Devin」が登場したことにより、AIエージェントへの関心は一層高まりました。 最近では、AIエージェントやツール同士がモデルとやり取りするための MCP （Model Context Protocol） が話題となり、Anthropic社が オープンソース として公開しています。 さらにそれを補完する形で、 Agent2Agent（A2A） プロトコル が2025年4月9日に Google 主導（50社以上のテク ノロ ジー パートナーと共に）で発表されました。 これにより、異なるAIエージェント間の相互運用性が実現され、複雑なタスクを協調して処理できる未来が現実味を帯びています。 つまり、今まさに以下のような未来が近づいています： MCP ： 一人の人間がさまざまなツールを使いこなし、何かを成し遂げる世界 A2A： 複数の“ツールを使いこなすAIエージェント”同士が協力し合い、人間を支援しながら何かを成し遂げる世界 前置きが長くなりましたが、このような世界において、 SaaS も「人間が使うツール」から「AIエージェントが利用するツール」へと役割が広がっていきます。それに伴い、これまでの「人間に最適化されたUX」だけでなく、「AIにフレンドリーなデザイン」も必要になってきます。 つまり、デザインの難易度がこれまで以上に高くなるということです。 当社の現在の製品管理課（PdM）は、エンジニア出身者が多く、テク ノロ ジー としてのAI理解に強みがあります。そのPdMとデザイナーが連携を取ることで、デザイナー自身のAIに対する理解や解像度も高まり、 人間とAIの双方に最適なデザインの提供 が可能になると考えています。 以上が、プロダクト部発足の経緯となります。 「プロダクト部」はどのような役割を担うのか こちらが、プロダクト部の ミッション 、 ビジョン 、そして 活動領域 です。 活動領域については、「 プロダクトマネジメント ・トライアングル」を用いて示しています。 先ほどご紹介した「一般的プロダクトチームの役割分担」において、 リーダーデザイナー／PdM 、 UXデザイナー／PdM は、 同じ活動領域 に属しているべきだと考えています。 Visonの（）記載にしている「UX志向」については以下のように推奨する行動と推奨しない行動を明文化をしています。 明文化することで、製品づくりにおける前提となる考え方をすり合わせることができ、その上で、互いの専門性をぶつけ合える関係性が築かれることを期待しています。 どんな組織体制になっているのか プロダクト部の組織体制は、以下のようになっています。 プロダクトデザイン課は、担当する商材に応じて3つの課に分かれており、 ラク スが展開する全10商材を担当しています。 一方、PdM（プロダクトマネージャー）は1つの課で4つの商材を担当しています。 「一般的プロダクトチームの役割分担」については、 ラク スにおいても製品の状況によって異なっており、製品管理課としてのPdMが関わっていない商材も多く存在します。 プロダクト部はどんなことをするのか 具体的な内容は製品戦略に関わるため、ここでは詳細をお伝えできませんが、これが立ち上げ初期に取り組んでいる内容になります。 すでにプロダクトデザイン組織については、別の記事で以下のような取り組みを進行中である旨を発信しております。 『ラクスのプロダクトデザイン組織紹介 ― 顧客価値を高める新たな挑戦』 『プロダクトデザインの継続的UX改善への道のり 〜お客様の業務課題を解決するUI/UXを提供しつづけるために〜』 これらの取り組みに加え、今後はさらに「重点取り組み事項」を追加し、推進していく予定です。 ラク スとして、これまで以上に「デザイン」と「テク ノロ ジー 」を融合させ、最高のUXを製品に提供し続けてまいりますので、ぜひご期待ください。