今回から、Technology Entrepreneurshipの具体的な講義内容についてご紹介します。本記事ではプロダクト開発を行う上で必要なRequirement（要件）、Design（デザイン）、Architecture（設計）の3つの観点について基本となる考えたや、実際に作成する上で役立つツールや参考記事を紹介していきます。
◆前回記事を読む⇒Technology Entrepreneurship①（講義概要）
【目次】
１．Requirement（要件）
1-1 Use Case
1-2 User Story
1-3 Flow Chart
1-4 Non-functional Requirements
２．Design（デザイン）
2-1 Technology Plaforms
2-2 UI (User Interface) / UX (User Experience)
2-3 Wire Frame
３．Architecture（設計）
１．Requirement（要件）
プロダクトを開発する上で、まず最初に必要な要件（機能など）を明らかにする必要があります。その為に、Use Case（ユースケース）、User Story（ユーザーストーリー）、フロー図を使うことで、自身の考えを容易に整理し見える可することができ、エンジニアの人にアイデアを伝えて、実際にコードを書いて貰う際にも役立ちます。それでは順に説明していきます。
システム（プロダクト）とその関係者間（Audiences/Actors）の関係を示す図です。誰が誰と何をやらなければならないかを整理するのに使われます。
システムの範囲で「できること・できないこと」を明確化し、
実際に作成するにあたって参考になったサイトが以下です。
◆若手エンジニア必読！超絶分かるユースケース図－全知識と書き方５ステップ
以下が実際に作成したUse Caseの例です。
「👤」ヒト型の図形がアクターと呼ばれるもので、システムを利用する人だけでなく、組織単位や外部システムも含まれます。
「〇」楕円上の図形がユースケースと呼ばれ、システムの利用例を意味します。線や矢印が各々関係性を表しており、それぞれ意味合いが異なります。
「－」単なる線は、アクターとユースケースを繋げる関連を示します。
「→」矢印線は、汎化関係（イコールのようなイメージ）を示します。「is a」で説明できる関係性だそうで、e.g. Firebase is a BaaS. のような感じです。
「⇢」点線になっている矢印線で<<include>>と書いてあるものが包含関係を表し、<<extend>>が拡張関係を表します。これらの関係はアクターとユースケース間では成り立ちません。例えば、ユーザーが美容師とチャットをするユースケースを利用するには、事前にログインしていることが前提なる場合、「ログイン」のユースケースは「美容師とチャットする」ユースケースにinclude（内包）されることになります。
Audiences（関係者）が各々、どんな動機でそのシステムを使うかを説明した内容を言語化したものです。
As a [User] I want to [do something] so that [derive a benefit]
「ユーザー」として、「ベネフィットを得る」 為に 、「～を」したい。
というフレームワークに当てはめて考えると分かり易いです。
e.g.
As a customer, I want to go to restaurant so that I can eat, spend time with friends and enjoy the experience.
プロセスなどをフロー図で示すことで、ユースケース毎に関係者がどの様なアクション・処理を行うかが時系列に沿って見える可されます。
実際に作成するにあたって参考になったサイトは以下です。
◆【業務フローの書き方】業務フローを書くために必要な図形とは？
また、以下が実際に作成したフロー図です。フロー図は色々な種類が存在しますが、私が作成したものはSwim Lane Chartと呼ばれるもので、プールのレーンの様にAudience別にフローの関連が示されたものです。個人的には、この図がプロセスを整理する上でも、説明する上でも分かり易いので気に入っています。前述のUse CaseやFlow Chartを作成する上で、draw.ioというフリーのサービスが実際に使ってみて、使い易いと感じました。
仕様を考える上で、見落とす可能性がある重要な要素が、Non-functional Requirement （NFR、非機能要件）です。Swim Lane Chart上には表れない機能ですが、重要な要素でありコストがかかってくる所でもあります。
大まかに、Security、Performance、Robustness、Localisation、Accessibility、Legislationなどの要素がNFRにあたります。例えば、Securityの観点でいうと、「ユーザーのデータを登録・編集・閲覧するには （IDとPWによる）ユーザー認証が必要である」とか、「PWの管理はどうするのか」などが考えられます。Performanceは、ユーザーが何かアクションを行った際に、「それに対するシステムの応答にかかる時間」や、「同時に処理できるTransactionの数」などがあたります。Legislation（法律）が要求するものはどの様なサービスを提供するかにも依りますが、絶対に対応しないといけない点ではあるのでイメージしやすいかと思います。例えば、EU圏ではGDPR（General Data Protection Regulation）という日本の個人情報保護法をもっと厳しくした様なものに則した対応が求められます。（※GDPR概要についてはこちらのサイトが分かり易いです。◆【5分で解説】いよいよ施行開始、「GDPR」で日本企業が対応すべきポイント）ちゃんとやらないと罰金が課せられたり、訴訟されたりするので、NFRでも最も大事な要素の一つです。
２．Design（デザイン）
仕様が決まったら今度はアプリケーションやサービスのデザインについて考えていきます。細かな所まで上げれば枚挙にいとまがないですが、主にどんなプラットフォーム（アプリ、Web？）で提供するのか、UI・UXを決める必要があります。その上で、それらを可視化するとどんな設計のアプリ・サービスになるのかを示した設計図（ワイヤーフレーム）を作ることが、考えなければいけない主な点です。
まずは、どんなプラットフォームを介してサービスを提供するかを決めます。大まかに、Native app（iPhoneやAndroidなど具体的なプラットフォーム向けにデザインされたもの）とWeb app（Web上のブラウザー向けにデザインされたもの）に分けられます。以下が両者を簡単に比較したものです。
前者はダウンロードしてしまえば、ネット環境が無くても動作したり、その端末にフィットした仕様にすることも可能です。一方、後者はレスポンシブデザイン（デバイスの画面サイズに合わせて表示を変更する様にサイトを構築すること）に対応させることで、ネット環境があれば端末に依存せずにサービスを提供することが可能です。
一長一短ありますが、総合的に見るとNative appの方が優れているとは言われます。ネット環境が無くても（一部機能が）動作することや、動作速度に関しても早いため、ユーザーの利便性が高まる傾向があるからです。しかし、Web appの方が開発コストや期間が短くなる傾向があり、幅広くユーザーにサービスを提供することが可能です。
UIはその名の通り、ユーザーとサービスとを繋ぐ入口（インターフェース）で、例えばボタンアイコンのデザイン（形や大きさ色）などもUI要素の一つです。ユーザーが意識せずにも操作できるようなシンプルで一貫性のある使いやすいものが良いUIになります。
一方、UXはユーザーがサービスを使って得ることの出来るエクスペリエンス（体験）を指します。ユーザーが実際に利用して感じたことが体験になるため非常に様々な要素がUXに影響してきます。UIもUXに影響する大きな要素の一つになりますが、高いUXには良いUIが伴うことになりますが、良いUIがあるからといって必ずしも高いUIが担保される訳ではありません。UIのフレームワークは様々存在していますが、有名なものはTwitterが提供しているBootstrapです。Bootstrapが提供するライブラリを利用すれば既に綺麗に統一デザインされたアイコンを使用することが出来ます。また、カラムという概念を使って簡単にレスポンシブデザインに対応させることも可能です。
ワイヤーフレームは前述の通り、Appの中に「何を、どこに、どの様に」配置するかを決める設計図の様なものです。実際にコーディングする必要なく、ボタンの配置などをコストをかけずに簡単に作成し、チームメンバーとイメージを共有することを目的としています。
Adobe XDが有名なツールの一つですが、極論は作れれば何でも問題ないです。紙とペンで書いても良いですし、エクセルとかでも図形を利用して作ることは出来ます。但し、色々なツールが存在するので、操作性や求める機能、コスト（最初は無料で利用したいなど）などの目的に合わせてツールを選ぶのが良いです。また、ネット上にテンプレートが多く存在するので、それらを活用するのもありです。
◆9 Free to Use Wire Framing Tools
３．Architecture（設計）
実際にどうやって作るかを決める要素です。RequirementやDesignの内容を踏まえて決まる設計図の様なものです。Wire Frameとの違いは、デザインだけでなく、サービス全体を設計する上でどの様なシステムを使い、コストはいくらかけるか等、より幅広い内容が含まれます。良いArchitectureは、より低コストで、変更が容易、保守・メンテが容易、拡張可能などが挙げられます。
基本的なArchitectureを構成する要素は、Hardware（e.g. Laptop等）、Operating System（e.g. Windows等）、Core Software（e.g. Server、Database等）、Integrated Software（e.g. Finance System、CRM等）、Business Continuity（e.g. Backup System等）、Interfaces（e.g. 外部APIs）などが挙げられます。
如何でしたでしょうか？自身が実際にコーディングせずとも、サービスとテックが切り離されることが殆ど無くなった昨今、基本となる考え方を知っておくだけでも、エンジニアとコミュニケーションをとり仕事をしていく上では、役立つものと思われます。私自身も知識ゼロだったので、授業の内容は非常に役立ちました。また、ちょうどテックアカデミーでの学習と併行して授業を受講していたので、Overlapする部分も多々あり、万国共通の考え方なのだと実感しました。
コメントを残す