中小企業向けの事例集アプリ開発!日本が元気になる基盤作りへ

今回の企画書は、中小企業向けの事例集アプリ開発に関するものです。

中小企業が日々悩んでいる課題について、参考になる解決事例の電子化・データ化は、当事者が自分の状況に近い事例を探し出し、解決イメージをシミュレーションすることで大きな産業発展の推進力になるのではないでしょうか。

世の中に貢献するITとして、中小企業経営の成功事例の電子化は、非常にニーズの高いテーマだと思います。

 

【目次】
1. 今回の企画書の特徴
2.『平成30年度中小企業・小規模事業者に向けた事例集アプリケーション開発に係る調査事業』から学ぶ
3.表紙
4.目次
5.事業の概要
6.システム概要
7.コンテストを活用したアプリケーション開発

 

1. 今回の企画書の特徴

今回の企画書は、電子化による中小企業経営の成功ナレッジのシェア化がテーマです。ポイントとなるキーワードを、以下に記します。

・中小企業の経営課題に対する解決事例の電子化・データ化
・検索・閲覧しやすいアプリケーションの開発
・アジャイル手法
・中小企業支援プラットフォームとの連携
・ユーザーインターフェースデザイン
・フロントエンド開発
・バックエンド開発
・インテグレーション開発
・統合・ローカライズ・品質管理
・フロントエンドアプリケーションとバックエンドAPIの連携
・Swaggerドキュメント

 

2. 『平成30年度中小企業・小規模事業者に向けた事例集アプリケーション開発に係る調査事業』から学ぶ

では、TC3株式会社が作成した企画書を以下具体的に見ていきましょう。

3. 表紙

4. 目次1

4. 目次2

4. 目次3

4. 目次4

4. 目次5

5. 事業概要1

1‐1. 事業の目的について

これまで中小企業庁をはじめ独立行政法人中小企業基盤整備機構等において、中小企業・小規模事業者(以下、「中小企業等」という。)や中小企業等支援事業者等の経営課題の解決に向けた参考となることを想定し、様々な事業に係る事例集を作成してきている。

一方で、事例集に記載されている事例が当該企業の属性に応じて検索することが必ずしも容易ではない、あるいは事例集間での連携がなされていないなど、中小企業等や中小企業等支援機関等にとって必ずしも活用しやすい状況にあるとはいえない。

そのため、当該事例集を電子化・データ化し一覧性を持たせると同時に、利用者の属性や関心に応じて例を検索・抽出できる適切な事例集の閲覧手法・媒体のあり方について調査を行い、電子化された事例集の閲覧・活用に当たっての課題とその解消方法を明らかにした上で、事例集の検索・閲覧が行いやすいアプリケーション(以下、「アプリ」という。)を試行的に開発し、事例集が中小企業等の経営課題の解決に一層寄与するものとなることが本事業の目的である。

当該アプリを設計するに当たっては、中小企業等の経営者等や中小企業等支援機関等における経営指導員等を主な利用者として想定しており、上記利用者が取り扱いやすいサービスデザインの実現に資するよう、アジャイル手法を用いる等、適切な手法を用いて設計する必要がある。

また、中小企業庁はワンストップで中小企業支援サービスを提供できるプラットフォーム「中小企業支援プラットフォーム(仮称)」の構築を検討しているところ、当該アプリと当該プラットフォームとの連携方法について検討を行うこととする。

5. 事業概要2

1‐2. 調査の内容について

事業目的に関する先行事業や事例検索に係る現状と課題、中小企業等の経営者等や中小企業等支援機関等の想定される利用者の意見等を踏まえ、事例集の検索・活用を行うモデルとなるアプリを開発し、適切なアプリに求められる要件(アプリ利用者の利便性を考慮したデザイン、コンテンツ、機能等)のとりまとめを行うとともに、本開発プロセスを踏まえて、今後の中小企業等に関する事例集の更なる開発のあり方を提言する。

(1)ユーザーにとって使いやすい事例の検索・閲覧のためのアプリ開発

ユーザーである中小企業経営者、中小企業支援機関等の職員、中小企業庁職員等が、中小企業庁等によって既に作成されている事例集に掲載されている事例を効率的に検索し、当該者の経営や経営相談対応等の参考として有効に活用されることを想定したアプリを開発する。

アプリを開発する過程で、ユーザーにとって使いやすいような適切なデザイン、コンテンツ、機能等を整理し、ユーザーインターフェースデザイン案、アプリ構成案を複数案提示の上、中小企業庁デジタルトランスフォーメンション室様と協議し、モデルとなるアプリの開発を行う。

アプリは、スマートフォン、タブレット、パーソナルコンピューター等において利用可能なウェブアプリケーションとし、レスポンシブかつGoogle Chrome上で動くことを要件とする。

5. 事業概要3

5. 事業概要4

5. 事業概要5

1‐4. 体制について

(2)プロジェクト進捗管理・担当職員とのコミュニケーションについて

Backlogの活用

対面の会議以外でも、担当職員様とのコミュニケーションを円滑に行うために、プロジェクト管理ツールのBacklog(https://backlog.com/ja/)を導入した。これにより、以下のような様々な形態でのコミュニケーションをオンラインで行うことが可能になった。

・タスクの管理および関連するディスカッション
・課題の管理および関連するディスカッション
・情報共有および関連するディスカッション
・ファイルの共有および関連するディスカッション

6. システム概要1

2‐1. 現状の課題と目指すべき状況

本サービスは、ワンストップで中小企業支援サービスを提供できるプラットフォーム「中小企業支援プラットフォーム(仮称)」のひとつとして位置づけられ中小企業・小規模事業者や中小企業等支援事業者等の経営課題の解決のため各種事例の検索、閲覧を行うサービスである。

尚、現状の事例集における課題と目指すべき状況は以下の通り。

◆ユーザにとっての現状と課題(As Is)
①自社に必要な事例集を見つけることができない(事例集が施策単位や表彰単位で複数サイトに点在)
②事例集の分量も多すぎて、参考になる情報がわからない、パートナーを探すことにも使えない
③仮によい事例を見つけられたとしても、該当施策の活用方法(公募情報等)や相談先がわからない

◆アプリ提供によって目指すべき状況(To be)
①個別に構築された事例集をとりまとめ、ニーズに応じた横断的検索が可能な仕組み
②施策単位や企業名の検索だけでなく、地域性や企業規模、業種等、自社に近い事例を探すことが可能な仕組み
③事例内で記載のある支援情報・支援機関にも簡単にアクセスできる仕組み
④最終的には、省庁横断、自治体、独法等を巻き込むとともに、連携を目指す

6. システム概要2

2‐2. システム概要図・開発範囲

6. システム概要3

6. システム概要4

6. システム概要5

6. システム概要6

6. システム概要7

8. コンテストを活用したアプリケーション開発1

3‐1. プロジェクト方針/要件検討

(1)プロジェクト方針について

本プロジェクトは以下の方針をもとに実施した。

【プロジェクト全体】
本プロジェクトは、プロジェクト全体や他モジュールの開発状況に応じて機動的なプロジェクト推進を可能とするため、アプリケーション開発をUIデザイン、フロントエンド開発、バックエンド開発、ローカライズ開発・品質管理・デプロイ等の各種別に分類し、各分類の開発を数日~2週間程度の短い期間を単位としたサイクルを回す形式とする。
また、必要に応じて中間成果物のフィードバック、コミュニケーションを実施し、機能の確認、修正に耐えうる方式で進めることとする。
【要件検討、確認】
必要最低限の検討とし、Topcoderサービスを利用することでUI/UXデザインを含めたアプリケーションの整理、具現化を実施していくこととする。
【UI/UXデザイン及びアプリケーション開発】
Topcoderサービスを利用し、コンテスト形式で行うこととする。これによりコミュニティから複数の成果物を得ることができ、より満足度の高いデザイン、品質の良いプログラムが採用可能となる。

※Topcoderシステムは、数日から2週間程度のコンテストを繰り返し実施することで、アジャイルでクイックなプロジェクトの進行を可能とすることから、今回の事業目的を達成するために適切であると考え、利用することとした。Topcoderについての詳細はP72「.参考.Topcoderとは」参照。

8. コンテストを活用したアプリケーション開発2

3‐1. プロジェクト方針/要件検討

(2)要件検討について

以下の「要件検討」「SPEC準備」についての確認、検討を実施した。

【要件検討】
現行の事例集(PDF等)をベースに、事例画面に表示する項目、内容を整理する
他システム共通の項目(データ)を洗い出し、データ構造、設定値を明確化する
システム化するにあたり、重要視する機能における仕様を検討する
(検索、コレクション等)
・事例分類などの検討
・事例項目の洗い出し
・データ定義
・機能一覧
・その他
【SPEC準備】
デザインコンテスト仕様を検討、まとめる
・ペルソナの定義
・サイトコンセプト検討
・デザイン機能の定義
・制約条件(画面サイズ等)
・判定基準
・その他

8. コンテストを活用したアプリケーション開発3

3-2. アプリケーション開発の進め方

下記の流れに沿って、アプリケーション開発を遂行する。

・Top coderコンテストにより、UIデザイン、フロントエンドアプリケーション、バックエンドAPIを短期間で高品質に開発する
・TC3により、Top coderサービスの管理、その成果物の統合/ローカライズ/品質管理を行う
・TC3により、プロジェクト管理を行う

8. コンテストを活用したアプリケーション開発4

3-3. UIデザインコンテスト実施報告

(1)コンテストの進め方

・デザインに求める要件を反映したコンテストスペックを作成し、コンテストを実施した
・中間チェックポイントを設け、中間レビューを実施した
・最終成果物に対する評価を実施し、最終成果物を獲得した

【スペック作成】
・TC3とTop coderコミュニティのコンテストマネージャにてコンテストへの要求事項(スペック)を作成
・担当職員様がスペックをレビュー
・スペックに記載する主要項目
◇プロジェクト全体像
→誰に対してどのような価値を提供するものか
→ワイヤーフレーム
→補足資料の説明
 →評価基準
 →成果物要件

【コンテスト開始】
・スペックが公開され、コンテストがスタート
・参加者の質問に対して一次解答をコンテストマネージャ、もしくはTC3が実施(必要に応じて担当職員様にご相談)

【中間評価】
・通常、コンテスト開始から4~6日後に中間評価の時間を設定し、中間評価タイミングから48時間後までを目安にフィードバック提供を実施
・方向性の修正
→成果物のサマリー・結論を確認
→指摘を各参加者へフィードバック

【成果物評価・最終調整】
・事前に提示した評価基準に沿ってTC3の協力の元、担当職員様が評価を行い順位を決定
・成果物は、想定アプリ画面の画像ファイル一式(Photoshop など)
・成果物に対しての微調整や軽微な修正が可能(ファイナルフィックス)

8. コンテストを活用したアプリケーション開発5

(2)コンテスト実施概要

◆コンテストページ
◇「METI – Case Studies Responsive Application Design Challenge」

◆コンテストスケジュール(実績)
◇実施期間: 9/7 ~ 9/25(約14日間)

◆登録者/成果物(実績)
◇登録: 35名
◇成果物: 9件

◆コンテスト対象画面
1. ログイン・ユーザー登録画面 (PC)
2. 事例一覧画面 (PC/スマートフォン)
3. 事例検索画面 (PC)
4. 新着事例表示画面 (PC)
5. 履歴表示画面 (PC)
6. 事例詳細表示画面 (PC/スマートフォン)
7. ブックマークした事例表示画面 (PC)
8. 事例新着画面 (PC)
9. ユーザー情報編集画面 (PC)

8. コンテストを活用したアプリケーション開発6

8. コンテストを活用したアプリケーション開発7

3-3. UIデザインコンテスト実施報告

(4)UIデザインコンテスト中間評価の目的と方法

作成途中の成果物に対しフィードバックを行うことで、最終成果物を期待に沿った内容、品質となるように調整することを目的とする。

◆評価にて実施すべきこと

1. 全体的なフィードバック(共通的な指針)
2. 個別のフィードバック
→個別のフィードバックも全員が閲覧可能(個々の参加者とのプライベートなコミュニケーションは不可)。また、ネタばらしのようなフィードバックは不可
3. 中間評価の勝者選出
→5名の勝者を選出する。勝者にはそれぞれ賞金が支払われる
→中間評価の賞金は最終成果物を提出しないと受け取ることができない。最終成果物を出して欲しい(期待している)成果を選出するようにする

8. コンテストを活用したアプリケーション開発8

8. コンテストを活用したアプリケーション開発9

8. コンテストを活用したアプリケーション開発10

8. コンテストを活用したアプリケーション開発11

8. コンテストを活用したアプリケーション開発12

3-3. UIデザインコンテスト実施報告

(6)中間評価結果のフィードバックについて

◆全般的なフィードバック(抜粋)
1. 包括的なデザインとなっているようですが、情報アーキテクチャの観点でより改善、つまりさまざまなデータを魅力的でわかりやすい方法で表示する方法が求められています
2. 事例一覧は、もっと興味を引くような(且つ整理された)デザインが求められています。画像をうまく活用してみてください
3. 事例詳細は、もっと興味を引くようなデザインにできると思います。単に全ての情報を1ページに詰め込むだけでは良いアイデアとは言えないと思います。知りたい情報を探すのに苦労するようなものになってしまうでしょう。コンテンツをうまく分割することを検討してください
4. フォントサイズに注意してください。ほとんどのデザインにおいて、年配の人が読むには文字が小さいように思えます
5. 検索機能のデザインについてはじっくり検討して頂きたいと思います。検索条件の指定の仕方についてのUXには、もっと良いアイデアを出してもらう必要があります

8. コンテストを活用したアプリケーション開発13

3-7. 開発コンテストにおけるレビュープロセス

(1)開発コンテストにおけるレビューシステムについて

開発コンテストでは、コンテストにレビュアーがアサインされ、評価プロセスは全てコンテスト内で実施される。各提出物は、コンテストスペックの内容と客観的評価基準に基づいてスコアが付けられ、スコアの高い提出物を出した参加者が勝者となる。

・開発コンテストごとにレビュアーが1名~2名アサインされる
・レビュアーは、評価基準(スコアカード)に沿って提出物をレビューを行いそれぞれにスコアをつける
・レビュープロセスは2段階で行われる。レビュアーから最初のスコアが出ると、参加者はレビュー結果について抗議(アピール)を行うことができる
・アピール内容に基づいてレビュアーがスコアの修正を行い、最終的なスコアが確定される。(レビュアーが複数の場合は平均点となる)
・入賞には、一定以上のスコアを満たす必要がある。これにより、低品質な提出物が入賞してしまうことが防止される

※Top coderコミュニティにおいて、当該分野で実績を積んだ開発者が、レビュアーとしてアサインされる

3-8. 開発コンテストで実施したプラクティス

(1)ベースコードの提供

開発コンテストでは、コンテストという性質上、開発者の間で具体的なコードが共有されることは少なく、実装の詳細での種々の決定は各開発者に委ねることになる。

各提出物に大きな差異が出てしまったり、或いは品質にむらが発生するのを防止するために、アーキテクチャを最小限にカバーする動作可能なコードを用意し、開発者に提供した。

これにより、アーキテクチャの共有、成果物に求めるものの伝達をスムーズに行うことができた。また、ベースコードをビルドして動作させるためのビルド用スクリプトを提供した。これにより、開発者がアプリケーションコードの開発に集中できるようにした。また、ビルドプロセスが統一されることで、レビュー時間の短縮、インテグレーションの効率化において効果が得られた。

バックエンド開発のベースコードには、以下のようなものを含めた。

・サンプルAPI実装(共通のロジックを含む最低限のAPI実装)
・ユニットテスト
・ビルドスクリプト(ビルドプロセスを全て実行できるスクリプト)
→コードのビルド
→自動テストの実行
→静的コード解析の実行

3-8. 開発コンテストで実施したプラクティス

(2)APIファーストの設計と開発

APIファーストの方針に則って、まずREST APIの設計を行い、その後、APIをベースに各コンポーネントの開発を進めていった。APIを先に規定することで、以下のことが実現された。

・バックエンドコンテストの開発者はAPIの実装だけに専念することができ、フロントエンドの開発者はAPIの実装がなくてもUIの開発だけに専念することができた。コンテスト参加者が自分の得意分野だけに注力することで効率よく高品質な成果物を得ることができた
・バックエンドの開発とフロントエンドの開発を並行して実施することが可能になり、工期を短縮できた

APIの設計書には、Swagger(OpenAPI 3.0)を利用した。Swaggerの利用によって以下のような利点があった

・APIの物理的な詳細(URL、パラメタ、項目名、項目のデータ型など)を効率よく記述することができた
・Top coderのコミュニティにて多くの開発者に親しまれており、形式について特別な説明無しに利用してもらうことができた
・ツールの利用により、開発者が劇的に開発効率を高めることができた(テストデータの作成やスタブの生成などの自動化)

3-8. 開発コンテストで実施したプラクティス

(3)品質保持のための施策

開発コンテストのレビューフェーズは、詳細なテストを網羅的に実施するには期間が短かい。そのような中でも成果物の品質を保つために、開発工程にて以下のような施策を行うことで、品質を素早く検証できるようにした。

◆自動テストの開発
・ユニットテストフレームワーク(JUnit等)を使用した自動テストの開発をコンテストの成果物に含めた
・自動テストが無い、または失敗するテストを含む成果物はスコアが落とされるため、スクリーニングに寄与する
・自動テストにより、後続の追加開発および修正において、コードのデグレードの発生の防止に役立った。特に、オリジナルのコードを開発したメンバーとは別のメンバーが開発するような場合に効果があった

◆静的コード解析ツールの導入
・Spot Bugsを導入し、自動的に潜在的なバグの検査を行った
・ビルドプロセスに組み込むことで、違反を含むソースコードが検出されると、ビルド自体が失敗するようにした
・ソースコードに違反を含む成果物はスコアが落とされるため、スクリーニングに寄与する

3-8. 開発コンテストで実施したプラクティス

(4)自動ビルド・自動デプロイの構築

ソースコードの更新に伴い自動化されたビルドプロセスを継続的に実行される仕組みを用意した。また、主要な変更については実行環境に自動でデプロイされるようにした。これにより、以下のような効果を得ることができた。

・ビルドプロセスには、(単なるモジュールのビルドだけでなく)自動テストや静的コード解析チェックが実行される、欠陥の発生をすぐに検出し、欠陥がデプロイに混入することを防いだ。

・デプロイ手順を自動化することで、デプロイのコストを大幅に削減し、成果物や修正を頻繁にデプロイして、実環境でテスト・レビューすることができた。

Top coderのようなコミュニティによる開発を行う場合、ソースコードのオーナーを固定することは難しく、あるソースコードを複数の開発者が次々と修正していくことも頻繁に起こり得る。これらの仕組みにより、そのような開発においても、コードのデグレードやバグの混入を防ぐのに、非常に効果的であった。

※本開発においては、これらを実現するために CircleCI を利用した

4-1. TC3で実施した開発タスク

本開発において、以下のような観点によりコンテストで実施しない方が良いと判断した開発タスクは、TC3内部で実施した。

・実施に必要なリソース(開発環境やツール・サービス等)を、多数の参加者に公平に提供できない作業
・日本語(英語以外の言語)をベースとした作業
・コンテスト形式が非効率になってしまう作業(テスト等)

以下に、代表的なタスクを挙げる。

(1)ユーザーインタフェースのローカライズ(日本語化)開発

コンテストの成果物は英語がベースになるため、日本語化を行う必要があった。Top coderのようなグローバルなコミュニティで開発を行うにあたっては、ほとんどの場合、日本語(英語以外の言語)をベースにしての開発は難しい。日本人または日本語を十分に扱えるメンバーを探すことも可能ではあったが、リスク要因であるため、今回は内部で日本語化を行った。

※日本語化作業のオーバーヘッドを削減する取り組みとして、フロントエンド開発コンテストにおいては、ローカライゼーションライブラリを使用を義務付けた。これにより、日本語化に伴うソースコード変更を最小限にすることができ、また、言語をスイッチしての開発を可能にした。

5-1. 認証基盤との連携

法人共通認証基盤との認証連携

事例検索アプリケーション(「事例ナビ」)は、 Open ID Connectに対応した法人共通認証基盤によるSSO(シングルサインオン)をサポートする。

本開発においては、Auth0 (https://auth0.com/) を拡張して、法人共通認証基盤をIDプロバイダーとして透過的に利用することで、これを実現した。

「事例ナビ」のログイン画面には、法人共通認証基盤SSO用のボタンが用意されており、クリックするとOAuthベースの認証フローが開始される。既に法人共通認証基盤にログインされていれば、自動で事例検索アプリケーションにもログインされる。

ログインされていなければ、法人共通認証基盤のログイン画面が表示される。法人共通認証基盤にログインすることで事例検索アプリケーションへのログインが行われる。

6-2. 本調査の評価

本調査の実績を、「ソフトウェア開発データ白書2018-2019」を参考に総括する。参照する統計データは、各値の「中央値」を参考とするものとする。(「平均値」は、極端に大きな値の影響を受けやすいため)

(1)品質
・P60「結合テスト・品質管理(テストケースサマリ)」及びP64「不具合件数と発生原因」により、結合テスト時のテストケース密度は、33.46件/KSLOCとなり、統計データ(35.70件/KSLOC)とほぼ同等。

また、検出バグ密度は、P64「不具合件数と発生原因」により、1.257件/KSLOCとなり、統計データ(1.600件/KSLOC)を下回る結果となったがテストケースは各機能を網羅されているため、品質の問題はないと分析する。

・本調査では、フロントエンド開発、バックエンド開発及び不具合改修等、製作のほとんどをTop coderを利用している。各開発は、コンテスト形式で参加者を募って実施し、提出された中から上位の成果物を採用する方法とした。各成果物の採点は、仕
様要件が満たされているか否かだけでなく、セキュリティ、パフォーマンス、コーディング標準などを客観的かつ総合的に判定されるため結果、品質の良い成果物を得ることができた。

・UI/UXデザインタスクについてもコンテスト形式でデザイン案を募り、中間評価、修正を経て最終デザイン案により順位を決定した。複数のデザイン案による比較、検討を行うことで、よりユーザエクスペリエンスの高いデザインを選択することができた。

6-2. 本調査の評価

(2)コスト(工数)

・Topcoderを利用しているプロジェクトの特性上、ウォーターフォール型との単純な比較はできない。そのため、製作工期に絞って生産性を評価することとする
・コンテスト形式での実施のため開発コンテストの期間及び単体テスト、不具合改修期間を製作時の工数として換算する
・P60「システムの開発言語、RDBMSとステップ数」及び上記工数より、製作工期の生産性は、約16SLOC/人時となり統計データ(14.5SLOC/人時)を上回る結果となった
・要件定義、設計工期(主に設計書作成及びレビュー)における追加要因を加味すると、全体工数としてはウォーターフォール型に比べ少ない工数で対応できたと推察する

6-2. 本調査の評価

(3)納期

・P64「開発フェーズ別の割合」により、設計工期、製作工期、テスト工期の内訳比率は、20:60:20となり、ウォーターフォール型の開発に比べ、製作工期の比率が他の工期に比べて非常に多い結果となった。これは、設計工期における設計作業、設計書の作成、レビューにかける工期を最低限とし、その分、製作工期において中間成果物による動作確認、フィードバックを繰り返すことで機能確認を実施することとした
・各機能の製作が終了した時点で、結合テスト以降はウォーターフォール型と同様に実施した。(品質向上のため)
・その結果、仕様の変更、追加や設計工期に起因する不具合の発生があったものの、全体のスケジュール(納期)に影響のない範囲での対応を完了することができた
・更に、「法人共通認証基盤」との認証連携にも対応できたため、今回の開発手法には一定の効果があったと考察する
(今回のスコープは、「法人共通認証基盤」との連携方法の検討まで)

6-2. 本調査の評価

(4)効果的だった点

◆コンテストのメリット
・複数の成果物から良いものを選択できる点
・次点の成果物の良い点を取り込むなど、他のデザイナー・開発者の成果を取り入れることができる点
◆設計書ベースではなく、成果物ベースでの確認・レビュー
・前者の方式に比べ情報量が豊富なため、意思決定を素早く行うことができた
・製造の手戻りのコストは製造工程の効率化により低減したため、スケジュール遅延を引き起こすことはなかった
◆製作工程の効率化
・開発コンテスト開催時にベースコードを提供したことで、アーキテクチャやビルド手順が統一された
・APIファーストの設計・Swaggerを活用したことで、開発の効率化がはかれた
・ユニットテストの義務化・静的コード解析チェックの導入により品質が向上した
・継続的なビルドとデプロイの導入により、成果物の評価を効率的に行うことができた
◆Backlogの活用
・高いセキュリティーを保ちながら大容量のファイルを簡単に共有できる点
・タスクや課題をチケット化することにより状況の共有、進捗が管理できる点

6-2. 本調査の評価

(5)改善すべき点

◆提出物の少なかったコンテストがあった
・2つの開発コンテストで成果物が1つだけだった
・スコープが大き過ぎたため脱落者が出てしまった可能性が考えられる。良い成果物を得るには、高めのゴール設定を行うことが重要であるが、高すぎた場合は調整を行う必要がある
・Top coderのイベントとスケジュールが重なり、参加メンバーが積極的でなかった可能性が考えられる。なるべくイベント開
催期を避けるか、リスクを前提としたスケジュールを組んでおく必要がある

◆テスト・品質管理におけるの改善点
・自動テストの実施は非常に効果があったが、プラクティスを完全にカバーできたわけではない
・フロントエンドの開発では、ソースコードの安定度合いが見切れなかったため、自動テストは開発を行わなかった。現状は
ソースコードが十分安定しているため、自動テストの開発は十分可能である
・ユニットテストのカバレッジ率については、レビュアーの目視確認で行った。自動化してビルドプロセスに組み込むことで、更に効率的に品質向上が目論める部分であると言える
・結合テストはマニュアルで実施したためリソースを要した。そのため回帰テストを頻繁に実施できなかった。自動化が可能
なケースについては自動化を行うことでより品質向上を強化できる

6-3. 留意事項について

(1)Auth0の利用について

本開発では、ユーザー認証とその周辺機能を効率的に実現するためにAuth0を利用した。

・ユーザー登録・メールアドレス検証(メール送信含む)
・ログイン画面・認証
・パスワード変更画面・パスワード変更変更フロー(メール送信含む)
・法人共通認証基盤アカウントでのログイン
・SNS(Facebook、Twitter)アカウントでのログイン

Auth0の利用範囲を独自実装に置き換える場合は、これらの項目の再実装を検討する必要がある。

また、Auth0の利用プランにより、登録・管理できるユーザー数が異なるため、前提とするユーザー数およびAuth0使用によるコストの見積りを再度実施する必要がある。

6-3. 留意事項について

(2)非機能要件について

本開発においては、目的がプロトタイピング開発であり、また限られたユーザーへの公開という前提であるため、通常のシステム開発で必要となる要件を限定的にカバーした。

更に本格的な運用を計画するにあたっては、本開発でカバーしていない要件(主に非機能要件)の検討を要する。

主な要検討項目

・SLA
・運用に関する要件(および設計と実装)
・サーバーのキャパシティ計画(再検討)
・上記項目を前提とした負荷試験
・ドキュメンテーション(ユーザーマニュアル、運用手順書、など)
・保守体制など

※本調査においては、事例データ約350件で負荷試験を実施した。今後追加されるデータ量を想定した負荷試験を行う必要がある。

◆参考.Topcoderとは
・競技プログラミング・コンテストをその出自とする独自のメソドロジーで質の高い成果物を開発するコミュニティと仕組みを持つ
・数日から 2週間程度のクイックなコンテストを繰り返し実施することによって、アジャイルでクイックなプロジェクト進行を可能にしている
【沿革】
・2001年 :競技プログラミングのコミュニティとして設立
・2003年 :初めての商用サービス開発プロジェクトを実施
・2016年 :TC3株式会社が日本市場でのサービス提供を開始
【Topcoder設立の背景】
・設立者のJack Hughesは元々システム開発会社を運営。優秀な人材の確保に苦労。人月ビジネスに疑問を感じていた
・稼働時間に対する支払いではなく 成果物に対する支払いを基本思想とする
【特長】
・「コンテスト」と呼ぶ競争形式を採用
・コンテスト形式により、優れた成果物のみを採用
・登録者数はグローバルで 130万人以上。日本人は約2万人でデータサイエンス分野に多い
【コンテスト】
・数日から 2週間程度に課題を切り分けた実行単位
・メンバーが一人で単独で行える大きさに設定
・個々のメンバーの得意領域へのフォーカスと敗北時の損失最小化を目的とする

おすすめ記事一覧