年間4000件のソフトウェアテストのデータを活用するという構想
講演ではまず、プラットフォームを作る構想の全体像について、村上氏が説明した。村上氏はテスト管理ツール「CAT（Computer Aided Test）」のオンライン販売に向けて、プロジェクトマネージャとして活動している。
村上氏は、SHIFTがソフトウェアテストの受託などで蓄積してきた大量のデータがあり、それを活用したいという思いがプラットフォームを作る構想につながったと説明する。そのデータ量は年間4000プロジェクト、6000万ケース、113万の不具合、スマートフォン4100端末に達し、累計100万件の不具合を検出、900項目の標準テスト観点として整理してきた。
こうして蓄積してきたデータは、現状ではそれぞれのサービス（テスト管理、テスト設計、品質分析サービス、教育コンテンツ）で蓄積するだけになっている。そこで、個々のサービスが蓄積しているデータを引っ張り出して統合し、クレンジング、解析などの処理を加えて活用することで、より良いサービスを提供できると考えているわけだ。加えて、有効活用して得た成果を個々のサービスに還元することで、サービスの改良も進む。
ここで村上氏はSHIFTが目指す姿を描いた図を示した。プラットフォームでデータを一元管理し、APIとして細かい機能を提供し、その組み合わせでサービスができるという姿だ。APIとデータストアを部品化して統合することで、再利用しやすくなる。さらに、個々のユーザーがどのサービスを利用できるのかを統合管理するユーザー認証基盤、さらに課金決済、ライセンス管理基盤も備えたものになる。
この形にたどり着くには、認証基盤の整備、課金決済やライセンス管理の整備、データの正規化やAIソリューション適用、API化および認可基盤の整備といった段階を踏む必要がある。現時点では課金決済やライセンス管理の整備に取りかかっているところだ。
具体的にはCATのライセンスを販売するECストアを開発している。CATストアを認証、課金決済、ライセンス管理の基盤を使用して構築中だ。当初、CATはオンプレミスで使うだけのツールだったが、現在ではクラウドサービスとしても提供している。しかし、クラウドサービスのライセンスをECで販売することができていない。CATストアが成功したあかつきには、SHIFTのさまざまなコンテンツをECストアで売りたいという構想がある。現時点では、「汎用化を視野に入れつつ、まずはCATの販売に注力（村上氏）」といったところだ。
さらに、APIなどを部品化してプラットフォームとして統合できれば、新たなサービスの開発速度も上がると見込んでいる。しかし、すぐに理想を現実にできるわけではない。開発開始当初から人的リソースをふんだんに投入できるわけではないため、開発の歩みは遅くなっているそうだ。ここで片山氏にバトンタッチし、今回の構想の開発がどのように進んでいるのかという話が始まった。
片山氏も、開発開始当初から人的リソースがふんだんにあるわけではない点を指摘するが、プロジェクトが小さいままではないともいう。プロジェクトのメンバーは開発が進むにつれて少しずつ増えていくそうだ。そして、たとえスタートが少人数でも、後々の増員が期待できるプロジェクトでは、メンバーが増えた後のことを考えて準備することが重要になると強調する。
増員後を考えた準備にはいくつかあるが、片山氏が最初に挙げたのが開発プロセスの事前整備だ。静的解析やコードフォーマッティングを仕組み化し、半ば自動で実行されるようにするという。
小さく始める時こそ、大規模になった場合を考慮した技術選定を
片山氏は、「小規模なチームで開発を始めると、プロセスをあまり整備しなくてもメンバーが近いので、何となく開発できてしまう」と指摘し、そのままでは人員規模が大きくなっていったときに、「ある人はテストをするが、ある人がテストしないでコードをプッシュしてしまう」など後々のテストが上手くいかなくなる。
「静的解析やコードフォーマットのルールを後から適用しようとすると、すでにあるソースコードへの変更点が多くなりすぎて、結局できないといった例を見てきた（片山氏）」。こうしたことを防ぐために、少人数でスタートするときからプロセスを整備して仕組みにしてしまうことが大切だ。
さらに、サービスが動き始めた後に大規模改修が発生する可能性を潰しておくことも重要だ。よくある例としては、多言語対応が挙げられる。すでにサービスが動いている状態で多言語対応をすることはデータベースの整合性などの問題もあってなかなか難しい。「海外市場を見据えるなら多言語対応は欠かせないが、それができなくなるとプロダクトがスケールしていかない（片山氏）」。
そして、REST APIを開発する際には「APIの定義と実装がずれる」「API定義のフォーマットのあいまいさ、考慮漏れによる実装ミス」「APIごとのバリデーション実装」「APIの定義変更がAPI利用者側に影響」といった問題が発生しやすいと片山氏は指摘する。
この点でスケールした後のことを考えた結果、今回のプロジェクトではOpenAPI仕様を採用し、そのエコシステムを利用することに決めた。「スケールさせていくには自分たち独自の仕組みではなく、既存の優れたエコシステムを利用すべき」という考えからの結論だ。
OpenAPIはYAMLやJSONといった形式で記述できるので、エンジニアには扱いやすい。さらに、関係ツールが豊富にあることも利点だ。例えば「Stoplight Studio」というツールを使えば、GUIでOpenAPI仕様に沿ったYAMLやJSONを作成できる。さらに、「Redoc」というツールを使えば、YAMLやJSONからAPIリファレンスを生成できる。そのほかにも、入出力バリデーションに使える「express-openapi-validator」というツールや、自動テストに利用できる「Jest」というツールもある。今回のプロジェクトでは、以上のツールを採用して、ドキュメント管理とテストに費やす工数を最小化することに努めた。
開発に使用する言語も、プロジェクトが大きくなった後のことを考えて選んだ。候補としてはJavaScriptとTypeScriptがあったが、「新たに参加するメンバーの学習コストが低い点を評価して」JavaScriptを選んだ。「TypeScriptの利点は型がしっかりしていること。ライブラリで型が用意されていれば問題ない。しかし、ない場合は作らなければならない」と片山氏は両言語の得失について語った。
そしてJavaScriptを選んだ理由にはほかにも、「Vue 2.x」でTypeScriptが完全対応していない点や、UIライブラリの「Vuetify」を使いたいといった点がある。
最後に片山氏は現状を振り返って良かったこととして、静的解析を仕組みとして取り入れたことや、OpenAPIのエコシステムを利用できたことを挙げた。反対に良くなかったこととして、ライブラリの依存関係の問題で、最新バージョンを利用できなかったことと、OpenAPIのエコシステムが少々難しく、使いこなすために手間と時間がかかってしまった点を挙げ、セッションを終えた。
