私たちについて

私たちは、内部監査人が直面する構造的な問題——監査需要が監査人の対応能力を慢性的に上回り続ける状況——に対し、準拠性監査の自動化によって解消を目指すAI-Nativeプロダクトを開発しています。

チームはプロダクト事業責任者（CEO）1名、プロダクトマネージャー1名、エンジニア4名、パートタイムのUIデザイナー1名の少人数構成です。プロダクト事業としては0→1の後半にあり、「1」を確立することにチャレンジしています。プロダクトは、日本を代表するナショナルクライアントや新興Fintech事業者にも利用頂いており、その先の1→10も視野に入りつつある段階です。

このポジションのミッション

なぜ今、このポジションが必要なのか

これまで当社のプロダクト開発は、チームの経験と直感に基づいて進めてきました。しかし、0→1を確立し1→10へ進むにあたり、「たまたまユーザーに響く機能を提供する」のではなく、ユーザーの問題を深く理解し、科学的に再現可能な方法で、問題の発見と解消を繰り返せる体制をつくりたいと考えています。そのために、リサーチと仮説検証を中心に据えてプロダクトのデザインを推進できる方を迎えたいと考えています。

期待する成果

入社後6〜12ヶ月で、以下の状態をチームと一緒につくることを期待しています。

Opportunity Solution Treeというプロダクトディスカバリーの方法論に基づいて、ユーザーリサーチを行い、主要なオポチュニティを特定し、仮説を検証しながら顧客価値を探索するというサイクルが、特定の個人に属人化せず、チームの習慣として定着すること。

具体的な業務内容

1. ユーザーインタビューや行動観察などの定性リサーチを計画・実施し、内部監査人が実際に抱えている課題やニーズを特定します。監査業務は専門性の高い領域ですが、ユーザーの言葉を丁寧に聴き、その背景にある業務文脈を理解することがプロダクトの方向性を左右します。
2. リサーチで得られた情報を分析・統合し、チームがデザインや開発の意思決定に使えるインサイトとして構造化します。ペルソナ、ジャーニーマップ、ジョブストーリーなどの手法を用い、知見をチーム全員がアクセスできる形で蓄積していきます。
3. ユーザーフローや情報設計を通じて、プロダクトの構造と振る舞いを定義します。探索フェーズであるため、最初から完璧な設計を目指すのではなく、検証可能な仮説として設計し、素早くフィードバックを得ることを重視します。リサーチと検証の結果に基づいて、何を「つくる」かだけでなく、何を「つくらない」かの判断にも主体的に関わります。
4. プロトタイプを作成し、ユーザビリティテストなどの手法でデザイン仮説を検証します。ローファイなプロトタイプで素早く複数のアプローチを試し、ユーザーの反応から学ぶサイクルを日常的に回します。プロトタイプを渡して終わりではなく、エンジニアの実装中のデザインレビュー、リリース後のデータ検証まで、デザインの品質と意図に対して最後まで主導権を持って関わります。
5. プロダクトマネージャーやエンジニアと日常的に協働し、要件定義や仕様策定、技術的制約の調整を行います。少人数のチームのため、職種の境界は柔軟です。デザインの意思決定の根拠をチームに共有し、合意形成を行うことも重要な業務です。

• HCD（Human Centered Design）あるいはそれに類する方法論に基づいたユーザーリサーチの計画・実施・分析の実務経験。 インタビュー設計、行動観察、ユーザビリティテストのいずれかを通じて、ユーザーの課題を特定し、デザインの意思決定に活用した経験があること。探索フェーズでは「何をつくるか」の根拠をリサーチから導く必要があります。
• ユーザーフロー・情報設計を通じて、プロダクトの構造を定義した経験。 画面の見た目ではなく、ユーザーがプロダクトをどう理解し、どう操作するかという「構造」を設計する力が必要です。探索フェーズではローファイで十分ですが、構造設計力がなければプロトタイプの検証自体が成立しません。
• 仮説検証のサイクル（課題定義→プロトタイプ→検証→学習）を、自ら推進した経験。 何を検証すべきか自体が曖昧な環境で、自ら仮説を立て、検証し、チームに学びを還元できることが求められます。
• エンジニアやプロダクトマネージャーなど、異なる職種のメンバーとデザインの根拠を共有し、合意形成を行った経験。 少人数チームでは、デザインが孤立すると探索の成果が実装につながりません。
• 正解のない状況で仮説を立てて前に進む姿勢と、新しい領域の知識や手法を素早く吸収する力。 当社はプロダクトデザインの考え方自体を組織に導入するフェーズにあります。内部監査という専門領域のドメイン知識も、入社後にキャッチアップしていく必要があります。

以下のいずれかに該当する方を歓迎します。すべてを満たす必要はありません。

• Figmaを用いたハイフィデリティUIデザインやコンポーネント管理の経験
• タイポグラフィ、色彩、レイアウトなどビジュアルデザインの基礎知識
• WCAG等のアクセシビリティ基準の知識
• HTML/CSS/JavaScriptの基礎的な理解（コードを書く必要はありませんが、技術的な制約を理解できると協働がスムーズです）
• アナリティクスツールやA/Bテストを活用したデータに基づくデザイン改善の経験
• デザインシステムの構築・運用経験
• プロダクトマネジメントの基礎知識（仮説検証サイクル、優先順位付けフレームワーク等）
• チームの仕事の進め方を構造化し、再現可能なプロトコルとして定着させた経験

以下のような困難を挑戦として歓迎できる方を求めております。

この仕事の難しさ・挑戦

当社は0→1の確立、そして1→10の拡大にチャレンジしている段階にあり、このポジションには以下のような挑戦があります。

1. プロダクト開発の考え方自体が発展途上です。 組織として真摯にプロダクト開発能力を獲得しようとしていますが、まだ道半ばです。整備されたフレームワークがあるわけではなく、不格好ながらにつくり上げてきたものがベースになります。「すでに確立されたデザインプロセスの中で仕事をしたい」という方には合いません。一方で、リサーチの仕組みから仮説検証のプロトコルまで、プロダクト開発の「型」そのものを自分の手で設計できる環境です。
2. 候補者様が1人目の専任プロダクトデザイナーです。 パートタイムのUIUXデザイナーが整備したデザインシステムやカラーコードなどの資産はありますが、リサーチや仮説検証の仕組みはこれから構築する段階です。社内のチーム全員が、プロダクトデザインについて真摯に学んでいますが、ロールモデルは居りません。自ら学び、組織に知見を還元していく必要があります。その分、チームと直接議論しながらデザインの意思決定に関わることができ、プロダクトの方向性にダイレクトに反映されます。
3. チーム全体が学習の途上にあります。 責任者、プロダクトマネージャー、エンジニアもプロダクト組織のあるべき形を学びんでいます。全員が成長しようとしている環境ですが、現状維持を好む方には向きません。常に「今のやり方で本当に良いか」を問い直す姿勢が求められます。一方で「こうしたほうがいい」という提案を歓迎し、一緒に変わろうとするチームであり、全員で手を取り合う習慣があります。