自費出版サービス「しまうま出版」への新商材「出版ポスカ」追加開発

自費出版フォトブック編集サービス「しまうま出版」は、写真集やイラスト集、漫画、小説といった商材を扱う既存サービスです。そこに新たな商材カテゴリとして、葉書サイズの印刷物「出版ポスカ（ポストカード）」を追加する開発を担当し、2026年7月27日に本番リリースを迎えました。

複数システムをまたぐ拡張

出版ポスカの追加には、編集アプリケーション（PC/SP）、ポータル、注文フロー、サーバーサイドAPIという複数のシステムを横断した対応が必要でした。

• 既存の編集アプリケーション基盤（PC版とSP版）を拡張し、出版ポスカ用の画面と処理を新規実装
• ポータルサイトに、出版ポスカの注文導線ページと仕様紹介ページを下層ページとして新設し、デザインとフロントエンド実装を担当
• カート取得APIと価格計算APIが返す商品情報を、ポスカのサイズや加工仕様に対応させる改修
• 注文フローは旧基盤の運用を継続しながら、新基盤への移行も並行して進行

編集アプリケーションへの新カテゴリ追加

編集アプリケーションのPC版とSP版それぞれに、プロジェクトの初期処理、作業内容の復元処理、一覧画面、編集画面を新規に実装しました。出版ポスカは、既存商材とは作品の点数も作り方も異なる新しいカテゴリです。編集画面のUIは、デザイン案の作成とレビューを重ねながら仕様を固めていきました。

• 初回訪問時にはチュートリアルダイアログを表示し、説明したい要素以外を暗くする表現で操作を案内します。同じサービスのモバイル版編集アプリと表現を揃え、商材が変わっても体験がぶれないようにしました
• ダイアログの高さは、説明ステップのうち最も要素の多いものに合わせて固定しました。余白は増えますが、ステップを進めるたびにボタンの位置が動かないことを優先した判断です
• 当初は別々に検討していたヘルプダイアログとチュートリアルダイアログを一本化し、操作説明の入り口を1つに整理しました
• 画像を登録したあとの仕上げ選択モーダルでは、仕上げをあらかじめ選ばれた状態にせず、使い手自身に選んでもらう仕様としました。未選択のまま先へ進もうとした場合は確定ボタンを押せない状態にし、選択が必要であることをその場で伝えます

カードの登録フローの設計

カードの登録フローには、複数の画像をまとめてアップロードしてカードを一括生成する案と、先にプロジェクトを作ってからその中でカードを1枚ずつ作っていく案の2つがありました。採用したのは後者の「プロジェクト作成先行型」です。

決め手になったのは、想定する使い手との相性でした。出版ポスカで見込まれるのは、フォトブックを作るほどの作品数には至っていない作り手です。扱う点数がそもそも多くないため一括登録の効率が活きにくく、まとめて登録すると裏面印刷の指定も分かりにくくなります。登録の手数を減らすことよりも、迷いにくい導線を優先しました。一括登録は要望が高まった段階で追加すればよいという段階的な進め方に整理しています。

注文フローとの結合デバッグ

編集画面で作ったものが注文まで滞りなく通ることを、検証環境で操作しながら確かめました。注文ボタンを押したときのプロジェクト登録、注文情報の確認画面に表示する商品情報、価格計算APIによる金額の算出という一連の連携について、フロントエンドとサーバーサイドの担当者が並走して不整合を洗い出し、解消しています。

既存資産の再利用

転用できるものは既存の仕組みを使う方針で進めました。

• 編集アプリケーションはPC/SPともに既存の基盤コードベースを拡張する形で新商材に対応
• 決済のセキュリティ対応（3Dセキュア）は、フォトカレンダー編集機能で実装済みのロジックを転用
• フロントエンドとサーバーサイドの担当者が連携しながら、実装状況を継続的に棚卸しし、抜け漏れのない開発を推進

体制

進行管理者のもとで、デザイン（編集画面のUI、ポータル下層ページ）、フロントエンド実装（編集画面、注文画面、ポータル）、サーバーサイド実装（価格計算APIなど）を分担するチーム体制で開発を進めました。本番リリースを経て、既存の長期パートナーシップの中で、新商材の立ち上げから運用という新しいフェーズにも継続して対応しています。