お仕事紹介：Eightのアーキテクト

こんにちは、Eightのアーキテクトの大熊です。最近は家にいる時間が長いのでVRゲームにハマっています。直近やっていたのは「Journey of the Gods」です。

今回はEightのアーキテクトって何やってるの？という話をします。といっても、一言でまとめればQCDの改善です。良いものを効率良く早く世の中に出す、そのレベルを上げていくことが責務です。

解釈次第ではいろいろなことがQCD改善とも言えますが、私が特にフォーカスしているのは次の4つの領域です。

概念設計
QA
中長期の技術課題の解消
バックログ管理プロセスの設計

一つひとつ見ていきます。

概念設計

Eightが提供する価値は名刺管理だけではありません。プロフィールやフィードなどのビジネスSNSとしての機能もあります。また、個人での利用を超えて組織として使うための機能もあります。組織内での名刺共有や採用プラットフォームなどの法人向けのサービスです。最近では、オンラインでのビジネスミーティング需要に応えるべくオンライン名刺交換機能にも力を入れています。

jp.corp-sansan.com

各機能はそれぞれの世界観を持ちつつ、その他の機能とも依存関係を持っています。法人向けの名刺共有機能は個人の名刺管理機能の上に成り立っていますし、採用プラットフォームはプロフィールやフィード機能を利用します。したがって、開発者は自身が開発する機能の概念に加え、依存する機能に出てくる概念も正しく理解する必要があります。例えば法人向け名刺共有機能を開発するエンジニアであれば、名刺管理機能に出てくる「名刺」や「名刺管理」といった概念です。もし間違った理解をして開発を進めてしまうと、影響範囲を見誤ってバグにつながったり、途中で仕様が破綻していることに気づき大きな手戻りが発生するかもしれません。このような事態を防ぐのがアーキテクトの責務です。

名刺や名刺交換といったEightにとって重要な概念については、開発者だけでなくPMやQAエンジニアの間でも認識が揃うようにしています。図や文章で定義した概念設計のドキュメントをメンテナンスしていて、入社時の研修で共有する時間を用意しています。もちろん日々開発を進めていく中で認識の齟齬があるなと感じれば、改めて認識合わせの場を設けることもあります。

既存の概念自体に手が入る時や、Eight上で新しい概念が発生するような大きめの開発プロジェクトの時もアーキテクトとして関与しています。概念設計を自らやったり、あるいはチームによる設計をレビューすることで、サービスとして一貫した概念設計が保たれるようにしています。

QA

開発プロセスにおいて、リリース前のテストにかかっている時間は少なくありません。また、テスト自体の質はQCDのQualityに直結してきます。EightにはQAチームがあり、アーキテクトの私も一緒になってQAの改善に取り組んでいます。

QAと向き合うに当たって、「できるだけ手前で防ぐ」という方針を持っています。バグが開発プロセスの後ろで見つかるほど戻って修正するコストが大きいためです。以前は、実装者がQAエンジニアによるテスト設計を目にするのはテストの直前になってから、ということがしばしばありました。テスト設計の過程ではバグが出そうなポイントが分析されます。その内容は開発者が実装前に知っていて損することはありません。そこで、QAエンジニアがバグになりそうなポイントを開発者に早い段階でフィードバックできるようなフローを現在試しています。これは改善施策の一例ですが、基本的には「できるだけ手前で防ぐ」という方針に則っています。

品質が良くなっているか悪くなっているかを見るために、定量的な指標も見ています。いくつか指標を見ていますが、例をあげるとテスト実施時間とバグ修正時間です。ここでのテスト実施時間は、ある施策のための一連のテストを一通り回し切るまでの時間です。定量化することで、テスト対象の機能や開発を担当したチームによる違いが見えやすくなりますし、時系列での変化といった傾向もつかめます。例えば実施時間が長いテストがあれば、テスタビリティに課題があるのではと突っ込んでみることができます。あるいは、修正時間が長いバグの状況を詳しく追ってみると、開発者とQAエンジニアの間でテスト対象への認識がずれていた、という問題が見えることもあります。定量化する指標自体は正直まだ悩みながらではありますが、QA課題に対して定量的に見ていくことの重要性は変わらないと思っています。

中長期の技術課題の解消

各機能ドメインにおける技術課題ではなく、全体的な開発生産性向上につながるような課題と向き合っています。

どういった課題があるか、そもそも本当に課題なのかといった議論は、私と部内のエンジニア数名で構成されているワーキンググループでやっています。開発/運用上の困りごとやテストでのバグ率などの定量的なデータが課題を深く見ていくトリガーです。課題に対して、具体的に何に困っているか、放置するリスクは何か、対応するとして工数感はどれくらいか、といったことを考慮して対応方針を決めています。最近Eightはメインのwebアプリをコンテナ化したのですが、これもその議論の中で決まったものです。一方で、元々上がっていた課題が別の要因である程度解消されることもあります。課題を上から単に潰してくのではなく、常に開発の現状を見ながら意思決定するようにしています。

バックログ管理プロセスの設計

Eight上で展開される機能が増えてくるにつれ、バックログにアイテムを積む関係者も増えてきました。それに伴い、アイテムの優先度づけや計画自体が複雑になってきています。ある程度の期間の見通しを立てつつも、プロダクトへのフィードバックを受けて改善していくような柔軟性を持てる計画プロセスが必要です。今やろうとしていることを少しだけ紹介すると、スクラムの計画の考え方を四半期ごとに拡大したような計画プロセスを考えています。元々Eightではスクラムを導入しているチームが多いため、それを四半期レベルに拡大してみようという狙いです。これからまさに計画プロセス自体のPDCAを回そうとしているところです。