こんにちは。Webアプリケーションエンジニアのid:vilagia です。

この記事は『Inside GigaViewer for Apps』連載11回目の記事です。今回は「GigaViewer for Apps」のバックエンドを担う「GigaViewer」のサーバサイド（以下 GigaViewer）において、開発がどのように進められているかについて紹介します。

GigaViewerは多くのサービスから利用されているマンガビューワです。サービスごとのマンガサイトやマンガアプリを提供する性質上、共通のしくみをお客様が利用されるだけではなく、個社個社のサービスのニーズに応じた開発も求められます。それでは、サービスのニーズはどのように咀嚼されて、最終的に実装されていくのでしょうか。この記事では、この点を重点的に解説していきます。

• 開発全体で注意が必要なこと
• 機能開発全体の流れ
• ケーススタディ
  • 開発着手まで
  • いよいよ開発開始
  • サーバサイド・アプリ開発の連携
  • デザイナーとの協業
  • 専門ユニットとの連携
  • お客様とのコミュニケーション
  • 社内での品質保証
  • お客様による最終確認
  • 本番リリースへ
  • ふり返り
  • 運用
• おわりに

開発全体で注意が必要なこと

GigaViewerにはいくつか特有の性質があります。この性質を背景として、私たちが開発を進める上で大切にしていることを紹介します。

GigaViewerは、非常に関係者の多いサービスです。

id:cateiruが様々なマンガアプリを素早く開発できる「GigaViewer for Apps」のしくみ バックエンド編 にて紹介している通り、マルチテナントなしくみであるということだけでなく、多くの立場の方が使うサービスです。

• サイト・アプリを企画運営する方
• サイト・アプリを運営するための運用を行う方
• サイト・アプリに掲載するマンガ等を制作する方
• サイト・アプリを閲覧する方

上記のような立場がサイト・アプリの数だけ存在します。このことは、開発しようとしている機能に直接触れるのは誰か、間接的に影響を受ける部分はないかなど、丁寧に検討することが必要であることを意味します。また、上掲の記事で紹介されている以下の特性も見逃せません。

バグやオペレーションミスなどでシステム障害が発生し、アクセスができなくなるとすべてのサービスに影響してしまいます。

まとめると、以下の点を踏まえて開発を進めることが必要です。

• 多くの立場のニーズを考慮する必要があり、要件の検討が難しい
• 影響範囲が大きいので、予期せぬ不具合を発生させないための工夫が必要

機能開発全体の流れ

開発はおおむね次のような流れで行われます。

1. お客様からの要望を受ける
2. 社内で要望を検討・概算見積もり
3. 開発が決定し、企画担当者が企画資料を作成
4. キックオフミーティングが開催され、開発開始
5. 開発が進行し、必要に応じて仕様の調整
6. 社内での動作確認
7. お客様の最終確認
8. 本番リリース
9. ふり返り
10. 運用

ケーススタディ

さて、ここからは実際の開発がどのように進行するのか、社外からの要望を受けて開発する架空のプロジェクトを例にとって紹介していきます*1。

このような開発の場合、企画担当者を中心とした数名のチームが編成されて開発が進められることになります。以下、チームが編成されたことを前提に、開発の流れを追っていきます。

開発着手まで

まずはお客様から要望をいただきます。たとえば、管理画面であるデータの状態がもっとわかりやすいようにしてほしい、ですとか、アプリ上でのマンガの表示形式を変更したい、などです*2。

関係者が多いこともあり、エンジニアが直接要望元の方とコミュニケーションする機会はさほど多くありません。企画担当者が要望を受けて、要件を検討し、エンジニアに相談するという形を取ることが多いです。

既存機能に基づく一日〜数日程度の稼働で済みそうと企画担当者の方が判断した場合、プロジェクトチームが編成されるに至らず、個別のエンジニアにアサインされることもあります。

一方、ある程度のボリューム感がありそうな場合、プロジェクトチームが編成されることになります。プロジェクトチームは固定的なものではなく、そのときの開発状況に応じて柔軟に編成されます。

いよいよ開発開始

プロジェクトチームが編成されると、キックオフミーティングが開かれます。ここで特別なことはなく、プロジェクトの目的や進め方、スケジュールなどについて確認します。ここまでは企画担当者がプロジェクトを前に進めますが、ここからはプロジェクトチーム、特にリードエンジニア*3が中心となって開発が進められます。

開発体制についてはリードエンジニアに一任されていますが、私が直近関わっているプロジェクトではスクラム開発の考え方が用いられており、2週間スプリントを淡々と進めていく形を取っています。毎朝のデイリースクラム、2週間に一度のペースでスプリントレビュー、スプリントレトロスペクティブ、スプリントプランニングを行っています。かなりの時間投資ですが、慣れや式次第の改善が進むにつれて所要時間は短縮されつつあり、現在は数時間程度の所要時間で済んでいます。終盤になるにつれベロシティも安定していきましたし、周辺環境の変化によって機敏な対応が求められる画面表示まわりのタスクにも柔軟に対応できました。掛けた時間以上の価値はあると感じています。他のプロジェクトも、スクラムに類する反復型開発プロセスを採用するのが一般的です。

サーバサイド・アプリ開発の連携

なお、サーバサイド・スマホアプリ両方の開発が必要な場合、サーバサイドエンジニアとアプリエンジニアが一体となって開発を進めるというよりは、それぞれのプロジェクトチームが編成されて、連携しながら開発を進める形が取られています。この場合、チーム間の連携を円滑にすることがとても重要ですが、この点、私たちは二つの工夫によって対応しています。

• 定期的に「同期会」と呼ばれる定例会合を開催することで、両チームの進捗や課題を共有する
• 開発スケジュール上の優先事項として「GraphQL APIの合意」を設け、両者の開発を疎結合にする

GraphQL APIをGigaViewer For Appsに採用した経緯については、Hatena Engineer Seminar #21「GraphQL 活用編」で、id:kouki_dan が、「はてなが作るマンガアプリのGraphQL導入から活用 ～ コミックDAYSからGigaViewer for Appsへ～」と題して発表していますので、そちらもぜひご覧ください。

デザイナーとの協業

画面要素の変更を含む場合、デザイナーがお客様とコミュニケーションを取って、適宜デザイン案を作成します。画面作成時にはデザイン案を元にデザイナーがコーディングまで行いますが、複雑なロジックが絡む部分はエンジニアが作成したり、ペアプログラミングによってデザイナーとエンジニアが協力して作成したりします。

なお、デザイナーがコーディングするにあたり、サーバサイドが前提データを用意する必要がある場合もあります。この場合、単発であればエンジニアが対応しますが、繰り返し作業が必要そうな場合、適宜スクリプトを用意してデザイナーが随時利用できるよう工夫することもあります。

専門ユニットとの連携

開発プロセスの中では、専門ユニット*4との連携も重要になります。インフラ構成は長期的な視点で不安ないか。パフォーマンス面の懸念をどう解消すれば良いかなど、専門ユニットのメンバーと連携しながら開発を進めていきます。このため、専門ユニットからは各ユニットの定例会に連絡要員が参加しており、気軽に相談できる体制を整えています。

お客様とのコミュニケーション

お客様とのコミュニケーションは、デザインに限らずこのフェーズでも続きます。キックオフまでに調整済みなのは全体的な要望に過ぎず、細部の仕様については、エンジニアが開発を進める中で詰めていく必要があるためです。

こうした仕様案の原案はエンジニアが主体となって作成しますが、実際のコミュニケーションは企画担当者が中心となって行います。原案をもとに企画担当者とエンジニアがコミュニケーションし、要件・技術的制約についての理解を深め合います。こうして完成した仕様案をお客様に提示し、適宜フィードバックをいただきながら、お客様の期待に添い、その機能の使い手にとって使いやすい、かつ、技術的にも筋の良い仕様に仕上げていきます。

社内での品質保証

開発も終盤に差し掛かると、社内での動作確認が行われます。ここまでの開発でもエンジニアたちは自分たちの開発した部分の動作確認は当然進めていますし、CIも整備されています。しかし、ここからは企画担当者が中心となって、開発した機能が要件を満たしているか。ソフトウェア全体と結合したときに問題がないか。リグレッションが発生していないか。などを確認します。

この工程は、大きく以下の手順で進められます*5。

1. 企画担当者とエンジニアが協力して確認観点を洗い出す
2. 企画担当者が確認観点に基づいて、テストケースを作成
3. 動作確認を実際に行う
   • 主な部分については、企画担当者が確認する
   • データベースを書き換えるなど複雑な手順を要する場合、例外的にエンジニアが確認する
4. 確認結果をエンジニアにフィードバックし、必要に応じて修正
5. 修正後、再度確認を行う
6. 全ての問題が修正されれば、お客様による確認へと進む

お客様による最終確認

いよいよお客様による最終確認です。機能上の不具合はここまでに発見・修正されているはずですが、お客様が想定した通りの動作をしているかや、ユーザビリティに問題がないかなどの最終確認をしていただきます。

ここで一発OKが出ることは大規模なプロジェクトになるほどまれになります。デザイン案として合意していても、上述の通り、もともと関係者が多いサービスですから、当初の検討では想定していなかったニーズが出ることは多いです。お客様からのフィードバックを受けて、必要に応じて修正します。

そのため、フィードバックを受けての修正を行いやすくするための工夫は随時行っていきます。GraphQLという柔軟性の高いインタフェースを採用しているのはその対策の一つですし、複雑な要件が予想される場合はモデルオブジェクトとビューの間に適宜デコレータ層を設けるなど、実装の各部で工夫しています。

お客様による最終確認で、リリース可能と判断されれば、いよいよ本番リリースへと進みます。

本番リリースへ

さて、いよいよ本番リリースです。リリースをどのように進めるかについて、私たちは大きく二つの方法を取っています。

• 機能フラグなどの手段で動作しないようにしたコードを段階的にリリースしていき、最後に機能を有効化するだけのリリースを行う
• 機能ブランチを用意しておき、一気に本番にリリースする

どちらの方法を取るかは、開発の初期段階でプロジェクトチームが相談して決めています。多くの場合は前者が採用されるイメージですが、決済周りの変更が含まれるなど、影響範囲の都合上前者の方法にリスクが高いと判断された場合などは、後者が採用されます。

後者を採用したケースで、しかも巨大なデータ移行を必要としたケースが、少年ジャンプ＋アプリの移行開発でした。これについては、id:masawadaが、「GigaViewer for Apps」に既存のテナントを受け入れるデータ移行: 少年ジャンプ＋の場合で詳しく紹介していますので、ぜひご覧ください。

ここまで来ると感無量であると同時に、無事に動いてほしいという期待と不安が入り交じった気持ちのまま一週間程度を過ごします。リリース後は、必要に応じて動作確認を行ったりして、問題がないことを確認したら、次のプロジェクトへと進んでいきます。

ふり返り

開発中にも、上に述べたようにスプリントレトロスペクティブを行っています。しかし、プロジェクト全体を通したふり返りも重要です。プロジェクトが終わった後には、プロジェクトチームでプロジェクト全体のふり返りを行います。ここでは、プロジェクトの進め方やコミュニケーションの取り方、開発の進捗などについて、何がうまくいったか、何がうまくいかなかったかを話し合います。初期の見積もりとのズレについてもここで検知し、次以降のスプリントで開発を予定しているタスクも見直していきます。見直しの結果としてスケジュール上の懸念が生じた場合、その重大さに応じてプロジェクト内外での調整を行います。

ここでは、GKPTという手法を用いることが多いです。GKPTとは、Good（うまくいったこと）、Keep（継続すべきこと）、Problem（問題点）、Try（次に試すべきこと）の頭文字を取ったもので、ふり返りの際に話し合う内容を整理するための手法です。話がまとまったら、Tryの部分をタスク化してユニットへと共有し、今後の開発に生かしていきます。

ふり返りについては一定の課題が残っているのが実情です。というのは、プロジェクト後というのは、新プロジェクトの立ち上げ期でもあり、ふり返りに割く時間と、新たなプロジェクトの準備に割く時間の間にトレードオフが発生してしまうからです。課題を完全に解決できているわけではありませんが、うまく時間を捻出して、ふり返りを行うようにしています。

運用

プロジェクトチームが解散したあとも、運用は続いていきます。運用専任のチームがあるわけではありませんので、開発した機能についてはプロジェクトチームにいたメンバーが引き続き一次受けとなり、徐々に知識をユニット全体に共有し、みんなで運用する体制に移行していきます。典型的には、以下のようなフローが作られています。

1. お客様からの問い合わせやSentryなどの監視手段起因で要調査事項が発生
2. エンジニアの輪番制である「サポート担当」が調査
3. 特定の機能開発の知識が必要そうと企画担当者が判断した場合、旧プロジェクトチームメンバーがアサインされ、調査
4. 調査結果をもとに、対処方針を立案
5. 対処
6. 不具合ならなるべく根本対応。根本対応が難しかったり、不具合ではないがエンジニア作業が必要な運用上のオペレーションであれば、対処内容をドキュメント化
7. 類似事例が発生したら、サポート担当が対応

ここではSentryやMackerelなどの監視ツールに加え、BIツールであるRedashが大活躍しています。ユーザーデータの状況確認なども含む複雑なケースはありますが、基本的には、以下の工程をたどることで対処方針は立案できています。

• Sentryによって、生じた不具合の原因となるエラーを特定
• Mackerelにより、エラーの背後にあるシステムの状態を確認
• Redashにより、エラーの原因となるデータの不具合や、その影響範囲を確認
• 上記の情報をドキュメントにまとめ、ユニットで協議して対処方針を策定

多くの場合には不具合対応は迅速に行う必要があります。こういうとき、ついついドキュメント化を省略する誘惑に駆られますが、ドキュメント化は非常に重要で、後から応援に駆けつけたメンバーに対してすばやく状況を伝えるため、また企画担当者がお客様に状況を説明するため、後日のふり返りのためなど、さまざまな場面で役立ちます。

このことは、はてなの在宅リモート中心の働き方を競争戦略で切り取るでid:yigarashiが紹介している、創業から続くテキスト文化とも通じるものがあるのではないかと思います。

おわりに

ここまでで、GigaViewerの開発がどのように進められているかについて紹介してきました。組織的な専門分化を極力避けた開発体制が設計されていることに気付かれたかもしれません。私見ですが、このことは、所属も立場も多様なお客様のニーズに応えるための広い視野を各人が持ちやすいというメリットがあるのかなと感じています。

本稿で、GigaViewerの開発の進め方について、少しでも興味を持っていただけたら幸いです。今後も、GigaViewerとその開発組織はお客様のニーズに応えるべく、日々進化していきますので、引き続きご注目ください。