こんにちは。メディアサービス開発部Webアプリケーション開発課のnerikeshiです。
株式会社ブックウォーカーでは、株式会社一迅社様の一迅プラスの開発を請け負っています。本記事では、その連載プラットフォームで稼働中の管理ツールのエピソード編集機能のご紹介と、それをどのように開発したかについてご紹介します。
エピソード編集機能について
漫画連載プラットフォームの管理ツールにおいて、エピソードの編集機能（連載各話の原稿画像を管理したり、タイトルなどのメタ情報を更新したりする機能）は最も重要な機能だと考えます。今回新規に管理ツールを開発するにあたって、まずその重要なエピソード編集機能の開発からはじめることにしました。
開発着手、ヒアリング
弊社内には作品登録業務を専門に行うチームがあります。手を動かす前に、彼らに日々のエピソード登録業務をどのように行っているかをヒアリングすることにしました。ヒアリングを元にユーザーストーリーマッピングを作成しました。
ヒアリングした中で印象的だったのは「まず編集部から原稿画像が送られてきて、その後でその他のメタデータ（タイトルなど）が送られてくる」という普段の業務の流れです。つまり使う側にとっては、最初に画像登録をして次にタイトル等を入力するという作業の流れが自然に感じるということでした。
エンジニアとしてはページ画像モデルが作品モデルにぶら下がっているデータ構造を想像していたため、そこから素朴に作って「まず作品タイトルなどを入力し、それから原稿画像を登録していく」という、作業者の自然な感覚の流れに逆らったUIを想像してしまっていました。きちんとユーザーのヒアリングからはじめていてよかったと感じた点でした。
ワイヤーの作成
普段の弊社では、仕様を決めた後はデザイナーがワイヤーを作り、ワイヤーを元に他チームを交えて議論したあと、デザイナーがカンプを作り、最後にフロントエンドエンジニアが実装するような流れで開発しています。本案件では、仕様策定後のワイヤー作成をフロントエンドエンジニアが行いました。そのようにした理由は以下のようなものです。
- ヒアリングからフロントエンドエンジニア主導で行っていたため、その内容を文章でまとめてデザイナーに渡すよりは、ワイヤーを作って見せた方がその後の議論がスムーズに進むのではと考えた
- toBのデザインはtoCに比べると堅めに作れるため、デザインツールの熟練度が低いフロントエンジニアが経験を積む面でもちょうどよいテーマだった
- エピソード管理UIは動的要素が大きいUIになるため、フロントエンドエンジニアが最初の設計を考えた方が技術的な理由での差し戻しが減ると思われた
ここで作ったワイヤーは以下のようなものです。
カンプの作成と開発
できあがったワイヤーを元に各関係者と議論をし、最終的にデザイナーにカンプとしてまとめてもらいました。ワイヤーがあったことで議論を進めやすかったと感じています。
カンプが完成したあとはReactアプリケーションとして開発を進めました。本記事では技術的な詳細は割愛しますが、ヒアリングの時点からメインで関わっていたため、実装もスムーズに進めることができたと感じています。
おわりに
本記事では一迅プラスの管理ツール開発フローについてご紹介しました。
エピソードの編集機能についてはそれなりによいものができ、作業される方から好評いただけました。しかし、まだ全ての機能を網羅するには至っておらず、長い道のりが残っています。
株式会社ブックウォーカーでは、ユーザーの声を第一に考えたプロダクト作りを一緒に行っていけるフロントエンドエンジニアを募集しています。もしご興味がありましたら、採用ページからのエントリーをお待ちしております。
