ID:61852さん

■チーム構成・規模 プロダクトオーナー兼出版社営業：１ 開発責任者：１ デザイナー兼PM：１ サーバサイドエンジニア：２ フロントエンドエンジニア：１ オペレーター：１ ■チーム内の自身の役割 上記のような構成の中で私は開発責任者として参加しました。 ■概要 大きく分けて３つの機能 ・無料漫画サービス ・有料漫画ストアサービス ・掲示板のようなCGM機能 を持った大きめなアプリケーションでした。 開発の全工程は企画期間を含めると10ヶ月ほどありました。 その内開発工程に使えたのが8ヶ月くらいだったのですが、事業計画達成のため要件の調整やエンジニア人員の追加などうまく調整して目標通りの開発スケジュールを達成し約束どおりの期日にリリースができました。 大きな機能がそれぞれ絡み合う複雑な要求だったのでMVC分離だけでは足りずDDDを導入しました。 実案件への導入は初めてだったのですが、strictな責任分離と依存管理を実現する上でレイヤ構造とVOによる値仕様の分離がうまく効いて取り回しがしやすく、設計としてはうまくいったと感じています。 一方で可用性の面では課題が多く、対応するより先にトラフィックが増えてしまい500吐きながらビューワサーバを分離したりSQLチューニングしたりを走りながら最適化していくような対応になってしまったという反省もあったプロジェクトでした。 開発・実装① 【概要】 書誌情報API連携実装 【どのような機能の開発・実装か】 提携したコンテンツを卸してくれる事業者提供のAPIからコンテンツ情報の取得やコンテンツ本体であるepubファイルの取得を行い、ビューワプログラムに合わせてスクランブル化した画像をS3に設置したのちビューワ（JavaScript）から参照できるようにコンテンツ配信サーバへ配置するといった一連のコンテンツ情報取り込みの実装 【課題・問題点】 ・自サービスで閲覧、販売可能なコンテンツが出版社営業の進捗によって出版社単位でどんどん増えていくためコンテンツの取り込みに時間がかかりうまく処理できなければせっかく獲得したコンテンツに待ちが発生してしまうこと ・多様なクライアントデバイスに対応するため複数のサイズや形式で画像を保持することで余計増大するストレージ使用率に対応していかなければならないこと ・コンテンツファイルのストレージとしてS3ではコンテンツ配信サーバで現実的なパフォーマンスが出せず、コンテンツのストレージングの仕方に模索が必要だったこと 【打ち手・使用した技術】 ・コンテンツ取り込み〜コンテンツ公開を並列処理で実装し、新規コンテンツが発生したそばから変換、公開していくec2インスタンスを多い時で9台ほど運用して解決した。 ・インフラチームと相談してNFSという形式を採用し、EC2にEBSを複数追加可能にしたものをコンテンツ配信サーバでマウントする形で対応した。 開発・実装② 【概要】サービス内通貨の実装 【どのような機能の開発・実装か】 毎月一定額を自動購入する月額コースと個別で500コイン、1000コインなど選択して購入できるようなサービス内通貨の実装。コンテンツの閲覧権利購入をこのサービス内通貨にて行う。 【課題・問題点】 通常購入の通貨（コイン）とキャンペーンやイベントなどで付与される通貨（ボーナスコイン）、ログインボーナスなどで無料で付与される通貨（無料ポイント）、1日1枚付与される通貨（チケット）、、、 と今思い返してもなんだこの複雑な仕様と思うほど無駄に通貨の種類が多かったこと。 【打ち手・使用した技術】 丁寧にクラス設計してこのサービスにおける「通貨」をオブジェクトで慎重に表現することで通貨ごとの共通仕様、独自仕様の管理を行なったのと、ユニットテストでカバレッジ100%を維持した。 開発、デザイン、マーケ、運用、オーナーとそれぞれのコミュニケーションで言語の揺れが発生しないよう気をつけてそれぞれのワードを運用した。 ただこの件に関しては複雑な要件が課題というよりもサービスのコアバリューをしっかり定義してそこに集中投資するということをせず手数に走り無駄な機能を色々つけていってしまったことが問題であって、そのことにより副次的に発生した二次災害のようなものなので反省するとしたらサービスデザイン、プロダクトデザインみたいな部分をきちんとやれなかった、選択と集中ができなかった、というところと考えている。