楽楽明細、楽楽電子保存、楽楽債権管理と複数プロダクトのプロダクトマネジメントを担当しています。 紀井 です。 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

みなさん、こんにちは。AWS ソリューションアーキテクトの古屋です。 日々のお客様との会話の中で、「業務課題を解決するために新たな機能やシステムの開発が必要ではあるが、外部リソースを確保する余力もなく、自社に十分なエンジニアもいないため実現が難しい」というお声をいただきます。同様のお悩みをお持ちの方も少なくないのではないでしょうか。 近年、そういった状況に対して、 Amazon Bedrock や Amazon Q Developer をはじめとする AWS の生成 AI サービスの登場により、限られた開発リソースの中でも、業務を最もよく知る現場の担当者自身が課題解決の仕組みを構築できる環境が整いつつあります。 今回は、まさに生成 AI を活かし、非エンジニアのメンバーが中心となって契約書管理 AI エージェントを構築された大成株式会社様の事例をご紹介します。本事例では、Amazon Q Developer によりプログラミング経験が限られたメンバーでも AWS 上でのシステム構築が可能となり、さらに Amazon Bedrock を利用することでインフラ構築や運用管理なしに Claude のような高性能な基盤モデルを API 一つで呼び出せるため、従来手作業で数十分かかっていた情報抽出を数分に短縮する仕組みを短期間で実現いただきました。 お客様の状況と経緯 大成株式会社様（以下、大成様）は、「ビルトータルソリューション」を掲げ、ファシリティマネジメント、プロパティマネジメント、不動産投資事業、修繕工事や改修工事などの建築事業を展開する総合サービス企業です。 大成様のプロパティマネジメント業務では、ビルオーナー様やテナント様との間で締結される多数の契約書が業務の根幹をなしています。しかしながら、従来の契約書管理では、以下の課題が存在していました。 契約書の検索が手作業に依存しており、必要な情報を見つけるために複数の PDF を開いて目視で確認する必要がある テナント様ごとに契約内容の仕様が異なるため、ビル名やテナント名だけでは目的の契約書にたどり着けない場合がある ビルオーナー様からの問い合わせに対し、契約書の特定から情報確認、回答までに多くの時間を要し、迅速な顧客対応の妨げとなっている これらの課題を解決するため、業務改善やシステム利活用を担当している IT 戦略推進室が本取り組みに参加しました。大成様では社内 SE、内製開発を行うエンジニアを擁していないため、同部にて生成 AI を活用した契約書管理システムの構築を検討されることになりました。 ソリューション／構成内容 本プロジェクトでは、非エンジニアのプロジェクトマネージャーが中心となり、Amazon Q Developer の支援を受けながらシステムを構築しました。Amazon Q Developer は自然言語での指示に基づいてコードを生成する AI アシスタントであり、プログラミング経験が限られた担当者でも実用的なシステムを構築できます。 本システムでは、Amazon Bedrock、 AWS Lambda 、 Amazon S3 、 Amazon DynamoDB を組み合わせて活用しています。Amazon Bedrock は生成 AI の中核を担い、Anthropic 社の Claude AI モデルを通じて契約書 PDF の解析と重要情報の抽出を実行します。 Amazon Bedrock + Claude を採用したポイントとして、Claude の高度な文書理解能力が挙げられます。契約書は法的な専門用語を含む複雑な文書であり、テナント様ごとにフォーマットが異なりますが、Claude は PDF などの非構造化データから文脈を理解した上で必要な情報を正確に抽出できます。また、AWS Lambda を中心としたサーバーレスアーキテクチャにより、非エンジニアが中心のチームでもインフラ管理に煩わされることなくシステムを運用できる点、そして日常的に使用している Slack との統合が容易で導入時の移行障壁を低く抑えられる点も、AWS を選択された理由です。 導入効果 実際にご利用いただいた結果、以下のような効果が得られています。 契約書からの情報抽出にかかる作業時間を 約 70〜80% 削減 。従来 1 件あたり数十分を要していた作業が数分で完了 将来的には、CSV 形式でのデータ出力機能を実装し、契約書情報の一括管理および分析を可能とする仕組みの構築を検討 AI による解析で情報抽出の精度と一貫性が向上し、人手による見落としや誤読のリスクを低減 Slack 上のシンプルなワークフローにより、従業員の受け入れがスムーズに また、非エンジニアでも Amazon Q Developer の支援により AWS の各種サービスを組み合わせた実用的なシステムを構築できることが実証されたことにより、他の業務領域でも生成 AI を活用した業務改善の取り組みが始まるきっかけとなっています。 大成様では今回の成功を踏まえ、契約書の自動要約機能や自然言語での高速検索機能の追加を検討されています。さらに、施設管理報告書の自動生成やメンテナンス記録の分析など、プロパティマネジメント業務全般での AI 活用拡大も計画されています。 お客様の声 大成株式会社 IT 戦略推進室 石川 静華様からは、「AWS のサービスを使うことで非エンジニアでも実業務の課題を自らの手で解決できる喜びを実感しました。」とのコメントをいただいています。 まとめ 今回は大成様が Amazon Bedrock と Amazon Q Developer を活用し、非エンジニアの手で契約書管理 AI エージェントを構築された事例をご紹介しました。Claude の高度な文書理解能力とサーバーレスアーキテクチャの組み合わせにより、専門的な開発リソースがなくても実用的な業務改善システムを実現されています。スモールスタートで確実に成果を出すアプローチは、これから生成 AI 活用を検討される企業にとっても参考になる取り組みです。 生成 AI を活用した業務改善にご興味をお持ちのお客様は、ぜひ AWS までお問い合わせください。 大成様 IT 戦略推進室 推進課 課長　田島 宏美 IT 戦略推進室 戦略課 主任　石川 静華 IT 戦略推進室 推進課 主任　鎌倉 由佳 Account Team： ソリューションアーキテクト　森   瞭輔 アカウントマネージャー　植木　輝 記事執筆： ソリューションアーキテクト　古屋　楓

はじめに はじめまして。NTTデータでデータサイエンティストを務めております池野です。 本記事は、【前編】Databricks Assistantを活用して需要予測モデルを構築してみた 〜EDA編〜の後編です。 前編では、需要予測モデル構築における課題感の整理からスタートし、 Databricks Assistant の設定 データ読み込み EDA（探索的データ解析） 需要に影響を与える要因の仮説出し までを実施しました。 需要予測はビジネスインパクトの大きいテーマですが、実務では前処理やEDA、特徴量設計などに多くの時間がかかります。 そこで今回は、「Assistantを活用す