ケーススタディ：スイス連邦政府機関のラジオ番組分析アプリ

ウェブ開発ソリューションの世界は広大です。そのため、技術の道に留まる必要はありません。簡単に言えば、新しいアプローチを模索して学ぶことで、人としても開発者としても成長し、進化していくのです。

 

LINK Instituteと協力してRadio Program Analysisのアプリを構築したことは、チームが未知の領域に踏み込み、アプリ作成のさまざまなアプローチを模索し、その結果、大きな喜びと報酬を得ることができた輝かしいプロジェクトの内のひとつです。

 

先にお断りしておきますが、これはJamstackの別のケーススタディではありません。

通常のウォークスルー型のケーススタディではなく、異なる方法で今回は行いたいと考えました。そこで、LINK InstituteのIT開発部門の責任者であるKai Wasternack氏に、ラジオ番組分析アプリのプロジェクトにおいて、直面した問題、楽しかったこと、見つけた解決策などについて話を聞きました。

 

 

こんにちはカイ。早速ですが、何を担当されていますか／あなたの会社は何をしていますか？

 

リンク・インスティテュートは、市場調査と社会調査におけるスイスのマーケットリーダーです。私の所属するIT開発部門では、必要に応じてソフトウェアを提供し、研究者をサポートしています。IT開発の責任者である私は、ソフトウェアの企画・設計を決定し、3人の同僚と一緒にコードを書いています。

 

ラジオ番組分析アプリのプロジェクトとは何ですか？

 

クライアントの一人は、スイスのラジオ番組の詳細な分析を実行・維持したいと考えており、簡単で魅力的なソリューションを必要としていました。このプロジェクトには、録音と分析の2つの側面がありました。録音には、1年の内、ランダムに選ばれた録音日に、5つの公共放送局のラジオ番組を追跡するオプションが必要でした。

 

分析では、録音を聞き、情報を順守し、あらかじめ設定されたカテゴリー（ニュース、天気、音楽など）に分類して行いました。各カテゴリーには固有のサブカテゴリーがあり、それらの間には複雑な依存関係のルールがあります。

 

このプロジェクトを担当したリンク研究員は、録音を再生し、異なる（サブ）カテゴリーを表示し、それらの相互依存関係を管理するユーザーインターフェースを提供すると共に、分析プロセスをサポートするソフトウェアを構築するようにIT部門に依頼を行いました。

 

アプリを一から作ったのですか？

 

いいえ。この調査は、過去にデスクトップアプリケーションに依存した別のプロバイダーに実施よってされました。それも悪くはない方法だったのですが、私たちはWebアプリケーションの方がはるかに優れたアプローチであり、彼らが経験した多くの問題を解決できると確信していました。

 

さらに、ブラウザに依存しないWebアプリケーションをベースにしたソリューションは、リリースのロールアウトに悩まされることがないため、ITサポートにとってメリットが多くなります。

 

ラジオ番組の解析という複雑な作業を行うためには、できるだけ無駄のないユーザーインターフェースが絶対に必要です。そして、ユーザーのパーミッションを扱うための簡単なソリューションも必要でした。

 

このプロジェクトでの私たちの役割は？

 

Webアプリケーションの決定は非常に早い段階で行われました。一方で、フロントエンドとバックエンドを同時に実装するための社内の開発チームに十分なリソースがないこともわかっていました。

 

私たちの開発チームはC#とSQLの知識が豊富で、反対にあなた方はWebフロントエンドの設計と実装、特にReactベースのものについて素晴らしい知識を持っていたので、私たちの決断は明確でした。

 

データストレージにはSQL Serverを、フロントエンド技術にはReactを使用します。フロントエンドとバックエンドの間の通信は、C#で実装されたRESTサービスによって行われます。

 

そうですね。大部分は、拡張可能なエンタープライズレベルのフロントエンドアプリケーションフレームワークであるUmi.js上に構築されたReactアプリです。また、グローバルステートソリューションであるdva.jsは、Umi.jsのコンポーネントであるため、これも使用しました。ビジュアルレイヤーにはAnt Designを使用しました。このReact UIフレームワークにはすでに多くのコンポーネントが用意されており、多くのスタイルを記述する必要がありませんでした。

 

苦労した点はありますか？

 

一番苦労したのは、ラジオビューでのコーディング部分です。このビューでは、Media PlayerとTable of Logを接続する必要がありました。このプロセスを理解するために、主なワークフローについて説明します。

 

各メディアファイル（通常は5時間の記録）には、ログのリストがあります。ログは、開始時間、終了時間、および各フォームフィールドの値に関するいくつかのデータを含むメディアレコードフラグメントです。メディアファイルの再生中、適切なログに到達すると、テーブル側で自動的にこのログにマークが付けられるため、結果、フォームのすべてのフィールドに入力していく必要が発生します。

 

内部的には多くの子コンポーネントを持つ巨大なReactコンポーネントです。ご想像のとおり、多くのプロップ、Reduxアクション、および内部状態があります。これらの小さなコンポーネントが何度も再レンダリングされるため、パフォーマンスをいかに節約するかが主な問題でした。

 

もうひとつの問題は、フォームのバリデーションルールをバックエンド側に残すという考え方でした。これらの検証ルールを処理した後、各フォームフィールドの再レンダリング（値の更新処理）で大きな問題にぶつかりました。この検証のアイデアは、コンポーネントの構造を構築した後に出てきたものなので、コード構造のリファクタリングが多く、その他のレンダリング／リフレッシュの問題にも対処しなければなりませんでした。

 

確かに、もっとうまくできたかもしれません。再レンダリングの回数を減らすためには、コード構造全体を改善／リファクタリングする箇所がたくさんあると思います。

 

私の話は一旦置いといて、結果はどうなったんですか？

 

アナリストへの教育は、開発が開始されてから6ヶ月後に始まりました。現在、20人のアナリストが350時間のラジオ放送に同時に取り組んでいます。

 

ゲームをプレイするとき、最大の目標はそれをクリアすることです。しかし、あなたが受けるサブクエスト、つまりクリアするために上を目指すようなサブクエストは、ゲームをより良いものにしてくれます。

 

アプリ作りの荒野に足を踏み入れたことは、私たちにとってまさにそのサブクエストでした。