Dev の求人一覧 - DIGGLE株式会社

＜事業概要＞コラボラティブ経営管理サービス「DIGGLE」の開発・提供経営管理領域における課題解決、および組織の意思決定スピードを加速させるプラットフォームの展開を行っています。 ・市場背景と課題 　└経営管理業務は個別性が高く複雑であるため、長らくExcelによる属人的な運用が常態化していました。しかし、バックオフィスDXの進展に伴い、重要業務をExcelに依存するリスク（情報の分断・ミス・遅延）が顕在化。現在、システム化需要が急拡大しています。 ・提供価値 　└単なる管理ツールの置き換えではなく、経営層と現場が共通の数値（ファクト）を用いて議論・連携する「コラボレーション」機能により、質の高い意思決定を支援します。＜提供サービス＞経営管理SaaS「DIGGLE」および導入コンサルティング「組織の距離を縮め、企業の未来の質を上げる。」をプロダクトビジョンに掲げ、以下のソリューションを提供しています。 ・経営管理プラットフォーム 　└使いやすいUIと高機能を両立し、経営管理業務の効率化・自動化を実現。全社的な情報流通を円滑化し、迅速なアクションへ繋げます。 ・カスタマーサクセスによる伴走支援 　└プロダクト提供に加え、数値管理に精通したカスタマーサクセスが運用定着・コンサルティング支援を行い、顧客ごとのベストプラクティスの実現と事業部を巻き込むカルチャー醸成を行います。＜Mission＞「Dig the Potential　テクノロジーで、企業の成長可能性を掘り起こす。」「経営」と「現場」の情報流通におけるボトルネック（分断）を解消し、企業成長におけるポテンシャルを最大化することを指針としています。 ・情報のインフラ構築 　└現場のリアリティある情報を経営へ、経営の意思を現場へ、双方向に正しく届ける仕組みを構築します。 ・経営管理のアップデート 　└前時代的な経営管理体制を刷新し、全社員が迷いなく事業成長へ向かえる「新しい経営の当たり前」を社会に実装します。＜募集背景：なぜ今、あなたが必要なのか＞DIGGLEは2024年にシリーズBで17.5億円の資金調達を実施し、累計調達額は約27.5億円となりました。 これまで主力製品「DIGGLE 予実管理」で培った強固な顧客基盤とドメイン知識を武器に、「ヒト・モノ・カネ」の全領域を統合するマルチプロダクト戦略（コンパウンド・スタートアップ化）へと舵を切ります。2025〜2027年にかけて、「人員管理」「売上予実管理」など複数の新規プロダクトを連続的に立ち上げるフェーズに突入しました。 これに伴い、既存のRails基盤を活用しつつも、独立性と拡張性を担保した新たなプロダクトのアーキテクチャ設計から実装、PMFまでをリードできる「技術と事業の越境者」を求めています。＜業務内容＞・新規事業（例：人員管理、投資管理など）の立ち上げにおける、技術領域の全責任を負います。 - 0→1フェーズの技術リード: - MVP（Minimum Viable Product）の開発および最短でのリリース。・ドメインモデリングと実装: - 「経営×ヒト/モノ」の複雑な業務フローを解析し、プロダクトへ落とし込む。 - Ruby on Rails, React/TypeScriptを用いたフルスタック開発。・顧客フィードバックのループ構築: - 事業責任者、CSやセールスと共に顧客の声を聞き、即座にプロダクトへ反映させる「Forward Deployed Engineering」的な動き。＜主要な開発環境・技術スタック＞・Backend: Ruby (Ruby on Rails) ・Frontend: TypeScript, React＜ポジションの魅力・得られる経験＞・経営/事業責任者と二人三脚でプロダクトを作り、最初のビジネス成果を上げる経験 - 最初は事業責任者と当該ポジションメンバーの二人でプロダクトを作っていくことになります。「事業に資するプロダクト」を作るため、顧客の課題・ニーズを理解し、バリュープロポジションを定義、事業計画を達成させていくための戦略立案まで深く入り込んでプロダクトを作るプロセスを経験し、成果を上げていくことができます・「How（どう作るか）」だけでなく「What（何を作るか）」を主導できる経験 - 仕様書は降りてきません。事業責任者や顧客と直接対話し、「顧客の課題は何か」「それを解決する最短の機能（MVP）は何か」を自ら定義し、実装まで落とし込みます。 - アーキテクチャ設計、DBスキーマ設計など、当該プロダクトの根幹に関わる全ての技術的意思決定権を持ちます。・ビジネス成果に最速で寄与するプロダクト作りの経験 - 新規事業フェーズのため、既存事業で適用している「20%ルール（リファクタリング時間の確保）」などの制約をあえて外し、「PMFのための速度」を最優先します。 - 「綺麗なコード」よりも「売れるプロダクト」「使われる機能」を追求し、市場からのフィードバックを即座にコードに反映させるアジリティが求められます。・コンパウンド・スタートアップにおける「全体設計」への挑戦 - 単独のアプリを作るだけではありません。既存の「DIGGLE」基盤とどう連携し、データや認証をどう統合するか。将来的なマルチプロダクト展開を見据えた、難易度の高いアーキテクチャ設計に挑戦できます。・「Forward Deployed Engineer」としてのキャリア - 開発室に閉じこもるのではなく、商談への同席や顧客ヒアリングへ事業責任者と一緒に行くことを推奨しています。顧客の生の声を聞き、それをエンジニアリングでどう解決するかを即座に提案・実装する、「ビジネスに強いエンジニア」としてのキャリアを確立できます。＜技術戦略と開発体制の特徴＞① 経営陣との「共創」体制事業責任者との「二人三脚」: 開発チームは「依頼されたものを作る」下請けではありません。事業責任者（執行役員クラス）と同じテーブルにつき、「今のフェーズで技術的に検証すべき仮説は何か」「最短で価値を届ける手段は何か」をゼロベースで議論し、仕様決定のを一緒に進めていきます② 「巨人の肩」に乗り、コア価値に集中する技術戦略「面倒な足回り」は既存基盤を活用: 既存のDIGGLE基盤を最大限活用することで、立ち上げ時から「車輪の再発明」を避け、リソースの大部分を「そのプロダクト独自の価値（機能開発）」に注力できる環境を用意しています。領域を切り出した「独立した開発環境」: 既存基盤に乗りつつも、新規プロダクトの領域（ドメイン）は明確に分離されています。そのため、既存コードの影響を過度に気にすることなく、新規事業に最適な設計や技術チャレンジが可能です。③ 手段を選ばない「高速考動」の実践フェーズに合わせた最適な技術選定: 「最初からRailsで完璧に作る」ことには固執しません。実例: 直近の人員管理プロダクトの立ち上げでは、仮説検証の初期フェーズにあえてノーコードツール（Bubble）やAIプロトタイピングツール（v0）を活用したりする例もあります。