中小企業向け事例集アプリケーション企画書作成.COMハイクオリティの企画書作成代行サービスを提供できるのが、株式会社DAWDYの強みです。2019.12.13中小企業向けの事例集アプリ開発!日本が元気になる基盤作りへ今回の企画書は、中小企業向けの事例集アプリ開発に関するものです。中小企業が日々悩んでいる課題について、参考になる解決事例の電子化・データ化は、当事者が自分の状況に近い事例を探し出し、解決イメージをシミュレーションすることで大きな産業発展の推進力になるのではないでしょうか。世の中に貢献するITとして、中小企業経営の成功事例の電子化は、非常にニーズの高いテーマだと思います。今回の企画書は、電子化による中小企業経営の成功ナレッジのシェア化がテーマです。ポイントとなるキーワードを、以下に記します。向けた事例集アプリケーション開発に係る調査事業』から学ぶでは、TC3株式会社が作成した企画書を以下具体的に見ていきましょう。経営課題の解決に向けた参考となることを想定し、様々な事業に係る事例集を作成してきている。とって必ずしも活用しやすい状況にあるとはいえない。そのため、当該事例集を電子化・データ化し一覧性を持たせると同時に、利用者の属性や関心に応じて例を検索・抽出できる適切な事例集の閲覧手法・媒体のあり方について調査を行い、電子化された事例集の閲覧・活用に当たっての課題とその解消方法を明らかにした上で、事例集の検索・閲覧が行いやすいアプリケーション(以下、「アプリ」という。)を試行的に開発し、事例集が中小企業等の経営課題の解決に一層寄与するものとなることが本事業の目的である。おける経営指導員等を主な利用者として想定しており、上記利用者が取り扱いやすいサービスデザインの実現に資するよう、アジャイル手法を用いる等、適切な手法を用いて設計する必要がある。中小企業庁はワンストップで中小企業支援サービスを提供できるプラットフォーム「中小企業支援プラットフォーム(仮称)」の構築を検討しているところ、当該アプリと当該プラットフォームとの連携方法について検討を行うこととする。想定される利用者の意見等を踏まえ、事例集の検索・活用を行うモデルとなるアプリを開発し、適切なアプリに求められる要件(アプリ利用者の利便性を考慮したデザイン、コンテンツ、機能等)のとりまとめを行うとともに、本開発プロセスを踏まえて、今後の中小企業等に関する事例集の更なる開発のあり方を提言する。中小企業庁等によって既に作成されている事例集に掲載されている事例を効率的に検索し、当該者の経営や経営相談対応等の参考として有効に活用されることを想定したアプリを開発する。アプリを開発する過程で、ユーザーにとって使いやすいような適切なデザイン、コンテンツ、機能等を整理し、ユーザーインターフェースデザイン案、アプリ構成案を複数案提示の上、中小企業庁デジタルトランスフォーメンション室様と協議し、モデルとなるアプリの開発を行う。Chrome上で動くことを要件とする。対面の会議以外でも、担当職員様とのコミュニケーションを円滑に行うために、プロジェクト管理ツールのBacklog(https://backlog.com/ja/)を導入した。これにより、以下のような様々な形態でのコミュニケーションをオンラインで行うことが可能になった。経営課題の解決のため各種事例の検索、閲覧を行うサービスである。現状の事例集における課題と目指すべき状況は以下の通り。プロジェクト方針/要件検討(1)プロジェクト方針について本プロジェクトは以下の方針をもとに実施した。本プロジェクトは、プロジェクト全体や他モジュールの開発状況に応じて機動的なプロジェクト推進を可能とするため、アプリケーション開発をUIデザイン、フロントエンド開発、バックエンド開発、ローカライズ開発・品質管理・デプロイ等の各種別に分類し、各分類の開発を数日~2週間程度の短い期間を単位としたサイクルを回す形式とする。検討とし、Topcoderサービスを利用することでUI/UXデザインを含めたアプリケーションの整理、具現化を実施していくこととする。【UI/UXデザイン及びアプリケーション開発】Topcoderサービスを利用し、コンテスト形式で行うこととする。これによりコミュニティから複数の成果物を得ることができ、より満足度の高いデザイン、品質の良いプログラムが採用可能となる。※Topcoderシステムは、数日から2週間程度のコンテストを繰り返し実施することで、アジャイルでクイックなプロジェクトの進行を可能とすることから、今回の事業目的を達成するために適切であると考え、利用することとした。Topcoderについての詳細はP72「.参考.Topcoderとは」参照。下記の流れに沿って、アプリケーション開発を遂行する。作成途中の成果物に対しフィードバックを行うことで、最終成果物を期待に沿った内容、品質となるように調整することを目的とする。個別のフィードバック→個別のフィードバックも全員が閲覧可能(個々の参加者とのプライベートなコミュニケーションは不可)。→5名の勝者を選出する。勝者にはそれぞれ賞金が支払われる→中間評価の賞金は最終成果物を提出しないと受け取ることができない。事例一覧は、もっと興味を引くような(且つ整理された)デザインが求められています。事例詳細は、もっと興味を引くようなデザインにできると思います。全ての情報を1ページに詰め込むだけでは良いアイデアとは言えないと思います。知りたい情報を探すのに苦労するようなものになってしまうでしょう。フォントサイズに注意してください。検索機能のデザインについてはじっくり検討して頂きたいと思います。開発コンテストにおけるレビュープロセス(1)開発コンテストにおけるレビューシステムについて開発コンテストでは、コンテストにレビュアーがアサインされ、評価プロセスは全てコンテスト内で実施される。各提出物は、コンテストスペックの内容と客観的評価基準に基づいてスコアが付けられ、スコアの高い提出物を出した参加者が勝者となる。・開発コンテストごとにレビュアーが1名~2名アサインされる・レビュアーは、評価基準(スコアカード)に沿って提出物をレビューを行いそれぞれにスコアをつける・レビュープロセスは2段階で行われる。レビュアーから最初のスコアが出ると、参加者はレビュー結果について抗議(アピール)を行うことができる・アピール内容に基づいてレビュアーがスコアの修正を行い、最終的なスコアが確定される。(レビュアーが複数の場合は平均点となる)・入賞には、一定以上のスコアを満たす必要がある。開発コンテストでは、コンテストという性質上、開発者の間で具体的なコードが共有されることは少なく、実装の詳細での種々の決定は各開発者に委ねることになる。各提出物に大きな差異が出てしまったり、或いは品質にむらが発生するのを防止するために、アーキテクチャを最小限にカバーする動作可能なコードを用意し、開発者に提供した。これにより、アーキテクチャの共有、成果物に求めるものの伝達をスムーズに行うことができた。ベースコードをビルドして動作させるためのビルド用スクリプトを提供した。これにより、開発者がアプリケーションコードの開発に集中できるようにした。ビルドプロセスが統一されることで、レビュー時間の短縮、インテグレーションの効率化において効果が得られた。バックエンド開発のベースコードには、以下のようなものを含めた。APIの設計を行い、その後、APIをベースに各コンポーネントの開発を進めていった。APIを先に規定することで、以下のことが実現された。・バックエンドコンテストの開発者はAPIの実装だけに専念することができ、フロントエンドの開発者はAPIの実装がなくてもUIの開発だけに専念することができた。開発コンテストのレビューフェーズは、詳細なテストを網羅的に実施するには期間が短かい。そのような中でも成果物の品質を保つために、開発工程にて以下のような施策を行うことで、品質を素早く検証できるようにした。・ユニットテストフレームワーク(JUnit等)を使用した自動テストの開発をコンテストの成果物に含めた・自動テストが無い、または失敗するテストを含む成果物はスコアが落とされるため、スクリーニングに寄与する・自動テストにより、後続の追加開発および修正において、コードのデグレードの発生の防止に役立った。開発コンテストで実施したプラクティス(4)自動ビルド・自動デプロイの構築ソースコードの更新に伴い自動化されたビルドプロセスを継続的に実行される仕組みを用意した。主要な変更については実行環境に自動でデプロイされるようにした。これにより、以下のような効果を得ることができた。・ビルドプロセスには、(単なるモジュールのビルドだけでなく)自動テストや静的コード解析チェックが実行される、欠陥の発生をすぐに検出し、欠陥がデプロイに混入することを防いだ。・デプロイ手順を自動化することで、デプロイのコストを大幅に削減し、成果物や修正を頻繁にデプロイして、実環境でテスト・レビューすることができた。coderのようなコミュニティによる開発を行う場合、ソースコードのオーナーを固定することは難しく、あるソースコードを複数の開発者が次々と修正していくことも頻繁に起こり得る。これらの仕組みにより、そのような開発においても、コードのデグレードやバグの混入を防ぐのに、非常に効果的であった。TC3で実施した開発タスク本開発において、以下のような観点によりコンテストで実施しない方が良いと判断した開発タスクは、TC3内部で実施した。・コンテスト形式が非効率になってしまう作業(テスト等)以下に、代表的なタスクを挙げる。(1)ユーザーインタフェースのローカライズ(日本語化)開発コンテストの成果物は英語がベースになるため、日本語化を行う必要があった。coderのようなグローバルなコミュニティで開発を行うにあたっては、ほとんどの場合、日本語(英語以外の言語)をベースにしての開発は難しい。日本人または日本語を十分に扱えるメンバーを探すことも可能ではあったが、リスク要因であるため、今回は内部で日本語化を行った。※日本語化作業のオーバーヘッドを削減する取り組みとして、フロントエンド開発コンテストにおいては、ローカライゼーションライブラリを使用を義務付けた。これにより、日本語化に伴うソースコード変更を最小限にすることができ、また、言語をスイッチしての開発を可能にした。Connectに対応した法人共通認証基盤によるSSO(シングルサインオン)をサポートする。IDプロバイダーとして透過的に利用することで、これを実現した。SSO用のボタンが用意されており、クリックするとOAuthベースの認証フローが開始される。法人共通認証基盤にログインされていれば、自動で事例検索アプリケーションにもログインされる。ログインすることで事例検索アプリケーションへのログインが行われる。本調査の実績を、「ソフトウェア開発データ白書2018-2019」を参考に総括する。参照する統計データは、各値の「中央値」を参考とするものとする。・P60「結合テスト・品質管理(テストケースサマリ)」及びP64「不具合件数と発生原因」により、結合テスト時のテストケース密度は、33.46件/KSLOCとなり、統計データ(35.70件/KSLOC)とほぼ同等。検出バグ密度は、P64「不具合件数と発生原因」により、1.257件/KSLOCとなり、統計データ(1.600件/KSLOC)を下回る結果となったがテストケースは各機能を網羅されているため、品質の問題はないと分析する。coderを利用している。各開発は、コンテスト形式で参加者を募って実施し、提出された中から上位の成果物を採用する方法とした。様要件が満たされているか否かだけでなく、セキュリティ、パフォーマンス、コーディング標準などを客観的かつ総合的に判定されるため結果、品質の良い成果物を得ることができた。・UI/UXデザインタスクについてもコンテスト形式でデザイン案を募り、中間評価、修正を経て最終デザイン案により順位を決定した。複数のデザイン案による比較、検討を行うことで、よりユーザエクスペリエンスの高いデザインを選択することができた。本調査の評価(2)コスト(工数)・Topcoderを利用しているプロジェクトの特性上、ウォーターフォール型との単純な比較はできない。テスト工期の内訳比率は、20:60:20となり、ウォーターフォール型の開発に比べ、製作工期の比率が他の工期に比べて非常に多い結果となった。これは、設計工期における設計作業、設計書の作成、レビューにかける工期を最低限とし、その分、製作工期において中間成果物による動作確認、フィードバックを繰り返すことで機能確認を実施することとした・各機能の製作が終了した時点で、結合テスト以降はウォーターフォール型と同様に実施した。◆提出物の少なかったコンテストがあった・2つの開発コンテストで成果物が1つだけだった・スコープが大き過ぎたため脱落者が出てしまった可能性が考えられる。coderのイベントとスケジュールが重なり、参加メンバーが積極的でなかった可能性が考えられる。・自動テストの実施は非常に効果があったが、プラクティスを完全にカバーできたわけではない・フロントエンドの開発では、ソースコードの安定度合いが見切れなかったため、自動テストは開発を行わなかった。現状はソースコードが十分安定しているため、自動テストの開発は十分可能である・ユニットテストのカバレッジ率については、レビュアーの目視確認で行った。自動化してビルドプロセスに組み込むことで、更に効率的に品質向上が目論める部分であると言える・結合テストはマニュアルで実施したためリソースを要した。そのため回帰テストを頻繁に実施できなかった。留意事項について(1)Auth0の利用について本開発では、ユーザー認証とその周辺機能を効率的に実現するためにAuth0を利用した。アカウントでのログイン・SNS(Facebook、Twitter)アカウントでのログインAuth0の利用範囲を独自実装に置き換える場合は、これらの項目の再実装を検討する必要がある。Auth0の利用プランにより、登録・管理できるユーザー数が異なるため、前提とするユーザー数およびAuth0使用によるコストの見積りを再度実施する必要がある。留意事項について(2)非機能要件について本開発においては、目的がプロトタイピング開発であり、また限られたユーザーへの公開という前提であるため、通常のシステム開発で必要となる要件を限定的にカバーした。本格的な運用を計画するにあたっては、本開発でカバーしていない要件(主に非機能要件)の検討を要する。・ドキュメンテーション(ユーザーマニュアル、運用手順書、など)・保守体制など※本調査においては、事例データ約350件で負荷試験を実施した。今後追加されるデータ量を想定した負荷試験を行う必要がある。Hughesは元々システム開発会社を運営。優秀な人材の確保に苦労。詳細へ詳細へ地域経済活性化のための経済指標と行政ヒアリング。企画書デザインどうする?企画書作成.COM株式会社DAWDYは、低価格で企画書作成代行サービスを提供しています。