（新しいタブで開きます）

こんにちは。サイト制作や EC構築から、UI/UX、ブランディングなどを強みとするスパイスファクトリー株式会社です。
ホームページは、もはやユーザーと企業を結ぶ玄関口、会社の顔とも言える存在であり、時代の流れやトレンドに応じてリニューアルをする必要があります。
しかし、ホームページのリニューアルをする必要性を感じているものの、制作会社をどのような基準で選べばよいかわからず困っている企業の web担当者様は多いのではないでしょうか？
そこで今回は、企業の web担当者向けに、ホームページリニューアルを依頼する際の制作会社を選定する流れや選ぶ際に懸念すべきポイントについてお伝えします。

ホームページ制作会社を選定するまでの流れ

最初に、制作会社を決定するまでの流れをご紹介します。
選定するまでに正しいステップを踏むと、以下の画像のような流れになります。（画像右側の社数はイメージです。）

企業規模や予算によって全てのステップを踏めるか否かは異なるかと思いますが、丁寧に正しいプロセスを踏むことでベンダー選定の失敗を回避することにつながります。
この項では、各プロセスの詳細説明を通して具体的な進め方やイメージを掴んでいただきたいと思います。

①ホームページの制作目的や要求事項の整理

ホームページ制作の前提事項として、制作する目的や要求事項などの整理を実施します。
このフェーズでの決定事項が、後述する RFP を形作る土台となります。

まずは、ホームページの制作目的を定義します。企業ブランディングの強化や問い合わせのさらなる獲得など、なぜホームページを制作するのかを明確化することで、以降のブレを減らすことができます。併せて、決定した目的から逆算してターゲットを決めることも重要です。

また、ホームページに求める要求事項についても整理します。
たとえば企業ブランディングを目的としたコーポレートサイトの制作であれば、自社のコーポレートカラーに合わせたデザインや自社の実績を紹介するコンテンツなどが必要となるでしょう。

こういったホームページに対する要望は、担当部門のみならず、社内の複数部署からもニーズがあることが多いです。そのため、社内の各関係部門にホームページに求めることや要望などをヒアリングする必要もあります。

②依頼先候補のピックアップ

目的と要求事項が整理できたら、依頼先の候補となる制作会社を探します。
この段階では、10社程度を目安として候補をピックアップするとよいでしょう。数が少ないと良い会社に巡り合える可能性が下がりますが、あまり多くの会社にアプローチすると対応が困難となります。
既に取引のある制作会社に加え、Web上の評判などを参考にしつつ候補を探します。

③RFIの提出

RFI（Request For Information）とは、日本語で「情報依頼書」と呼ばれる書類です。
依頼先候補に対して問い合わせを行い、ホームページ制作の目的や要求事項を説明の上、対応可否や各社の技術力の確認などを行います。
このフェーズのゴールは、RFI の情報を基にコンペに呼ぶ会社を選定することとなります。
後述する RFP と比較してあまり一般的ではない RFI ですが、RFI を提出することには以下のようなメリットがあります。

• 自社の要件に合う企業をスクリーニングできる
• RFP を配布する前に各社の情報を収集することで、制作会社選定のミスマッチを防げる
• 予算面からみて非現実的な要求がないかなど、ホームページの要求事項をブラッシュアップしできる

RFI は、会社を選定する際のチェックリストとしても活用することができます。当社では、実際の使用を目的とした RFI のテンプレートをご用意しています。テンプレートはこちらからダウンロードできますので、お困りの際はご利用ください。

（新しいタブで開きます）

④RFPの提出

RFP（Request For Proposal）とは、簡単に言うと発注側がベンダーに対して提案して欲しいことをまとめた文書のことです。要望や依頼事項を整理して記載することで、各社共通の条件で提案書と見積を取得できます。
RFP は、上述の「①ホームページの制作目的や要求事項の整理」でまとめた内容や、RFI によりブラッシュアップした要求事項をもとに制作します。

あまり多くの会社に依頼をすると対応が困難となるため、RFI を通して 5社ほどに絞り込んだうえで RFP を提出するとよいでしょう。
具体的に、RFP には以下のような項目を記載します。

• システム化の概要（背景、目的、スケジュール、予算など）
• 必要な画面や機能の一覧
• 非機能要件（データ量や想定アクセス数、求めるセキュリティレベル、可用性、バックアップの必要性など）

また、RFP の提出にあたっては、事前に評価項目を定めておくことをおすすめします。要求事項が満たされているか、技術力やデザイン力があるかなど、評価観点を洗い出し、どの項目を重視するかを決めます。場合により、各観点（デザイン・プロジェクトマネジメントなど）に点数をつけ、数値で評価する方法も有効でしょう。
当社では、ホームページを制作したいと考えている方に向けて、RFP のテンプレートをご用意しています。テンプレートはこちらからダウンロードできますので、お困りの際はご利用ください。

https://spice-factory.co.jp/web/tips-template-rfp

⑤オリエンテーションの開催とRFPの配布

提案を受けたい企業の候補が決まったら、一般的にはオリエンテーションを実施して、候補となる各社にRFPの内容を説明します。
オリエンテーションは、提案を依頼したい会社を対象に同時開催することもあります。各社合同で実施することで情報を公平に提供しつつ、実施側の負荷を下げます。ただし、日程が合わないケースなどでは、個別対応を実施することもあります。

オリエンテーションにて RFP を配布した後、各社は提案の準備を行います。各社から質問があるケースも想定されるため、あらかじめ質問の締め切り期日と回答方法を決めておきます。各社から挙がった質問であっても、全ての会社に対して質問内容と回答を共有することで、各社が持っている情報を公平にすることができます。
繰り返しになりますが、この項でのポイントは提案を受ける企業に対して公平に情報を共有することです。公平な情報を提供することは各社への情報格差を無くすだけでなく、同じ条件下で提案を受けることで各社の実力を公平に評価することができます。

⑥提案書の受領

各社から提案書を収集します。

同時期に収集するために、RFP には提案書の提出期限も記載しておきましょう。前項と同様、同じ日にオリエンテーションを実施し、同じ日に提案書を受領することで同条件下で公平なパートナー選定ができることがポイントです。

提案書が集まったら、あらかじめ定めた評価項目に沿ってプレゼンテーションに進む会社を選定します。この時点で 3社〜4社程度まで絞り込むとよいでしょう。

⑦プレゼンテーション

一般的には、提案書のみで各社を評価するのではなく、プレゼンテーションを通して最終的な評価を実施します。
プレゼンテーションは、基本的に各社からの説明時間と自社メンバーからの質問時間で構成します。できるだけ質問時間を多くとることで、各社の技術力や信頼度を測りやすくなるでしょう。
プレゼンテーションは 1度のみ開催することもありますし、現場レベルで 1次プレゼンを行い会社を絞り込んだのちに、幹部層も含めて 2次プレゼンを実施することもあります。

⑧依頼先の選定

RFP の内容を受け、依頼先を絞り込みます。依頼先の選定においては、あらかじめ定めた評価基準に沿って、各社の提案内容を比較します。技術力やコスト面に加え、要件に対する実現可能性、社風、プロジェクトの体制などを踏まえ、最も優れた制作会社を選びます。

選定における制作会社の比較ポイント

次に、制作会社の選定における比較ポイントを紹介します。

同じ業界の実績があるか

制作会社選定においては、実績が重要です。特に、同業他社の制作実績があると、スムーズに制作が進みます。
同業種の実績があるということは、その業界の商習慣やビジネスモデルを理解していると考えられるため、自社と制作会社の間で齟齬なく意思疎通でき、コミュニケーションコストが抑えられることや、自社で把握していなかったところに対しても制作会社からアドバイスがもらえる等が期待できます。
そのため、まずは実績面の確認を行うとよいでしょう。

対応できる制作規模

制作会社によっては、大規模な制作に対応できないケースもあります。
制作するページ数の整理などを通して、制作規模がどのくらいになるのかを把握しつつ、候補にあがっている依頼先が対応できるか確認しましょう。
また、複雑なシステムを必要とするホームページを制作したい場合にも、依頼に対応できる技術力を持った制作会社を選ばなくてはなりません。

費用

制作会社によって費用はピンキリです。特に技術を必要とする複雑なホームページ、拡張性の高いホームページ制作を依頼する場合には費用が高くなりやすいといえます。
自社で決定した予算と実現したい内容を踏まえ、その土俵に上がる会社のなかで選定すべきでしょう。

対応範囲

ホームページ制作の目的を踏まえ、どこまでのスキルセットを持ち合わせた会社であるかを見ることが重要です。たとえば、企業ブランディングを強化したい場合や、公開後のホームページの集客の支援を検討している場合は、ブランディングディレクターやマーケターが在籍している制作会社が好ましいでしょう。
また、制作後の運用面も重要です。運用フェーズでどこまで対応してもらえるかも確認しましょう。ホームページ公開後の情報更新や、軽微な改修などの運用保守までしっかりサポートしてくれるかなどをチェックします。

デザイン力

ホームページは企業や製品・サービスの顔となりますので、デザイン性が重要です。制作会社のデザイン力を確認する上では、チーム体制や意見の吸い上げ、UIとUXの両者の視点から対応できるかなどの観点で確認するとよいでしょう。

当社を例にとると、「ペアデザイン」と呼ばれるエンジニアとデザイナーがペアとなる体制を採用しています。このような体制により、迅速かつクオリティの高いホームページ制作が可能となります。

https://spice-factory.co.jp/design/pairing_design_engineering-designer

また、自分たちの意見をうまく吸い上げてくれるかもポイントです。ワークショップの開催や綿密なミーティングなど、意見吸い上げのための取り組みを行ってくれる会社を選ぶとよいでしょう。

加えて、UIデザインのスキルのみならずユーザーテストなど実施を通したユーザビリティ改善にも対応できるかを確認します。
ホームページ制作においては、一度固めたユーザビリティ設計を机上の空論にしないためにも、適宜ユーザーテストを実施し、軌道修正を行うことが大切です。

（新しいタブで開きます）

よくある3つのケース別：選定において重要視すべきポイント

ここでは、ケース別に、特に重要視すべきポイントについてお伝えしていきます。ここでは、よくあるニーズや状況を踏まえ 3つのケースに絞って具体的に説明します。

プロジェクトマネジメントも含めてお任せしたい

ホームページの目的や目標の整理など、プロジェクトマネジメントも含めて制作会社に依頼したいケースもあるかと思います。会社によっては、ホームページの制作のみを業務範囲とし、プロジェクトマネジメントは請け負わないというケースもあります。各社が対応できる業務範囲について、あらかじめ確認することをおすすめします。
成果物の品質はもちろんのこと、適切なコミュニケーションもプロジェクトを成功させるためには重要です。実際に、プロジェクトマネジメントの教本ともいえる PMBOK においても、成果物の品質と同じレベルでコミュニケーションの品質を重視しています。プロジェクトマネジメントを依頼する場合は、PM となる方のコミュニケーション能力にも注目してみるとよいでしょう。

デザイン性が高いホームページにしたい

「最新のデザインを用いたかっこいいホームページを作りたい」と、担当者のだれもが願っています。
しかし、広義な意味でのデザインには、表層的な見た目だけでなく、利用者にとっての利便性やホームページを使うことによる満足度も含まれることを忘れてはいけません。
見た目のデザイン性が高いことは重要ですが、情報が整理されていなかったり、導線が整備されていないなどユーザビリティ面で配慮が欠けているとユーザーが離脱してしまったり企業イメージが悪くなることもあります。
ユーザビリティに強い制作会社を選ぶ際のポイントは「UXデザイナーがいるか」と「UX の実績があるか」の 2点です。UXデザイナーがプロジェクトに参画することで、ユーザビリティテストやアンケートの計画・実施などを通したユーザー体験を向上させるアクションを取ることができるでしょう。
このように、表面的な外観のデザインはもちろん、その内部に設計されているユーザビリティ、いわゆる UI と UX の2軸で高いデザイン性を獲得できるかを確認する必要があります。
また、実績から類似のホームページのデザイン経験があるか、過去に制作したホームページはデザイン性やユーザー体験が優れているかをチェックすることで、制作会社やデザイナーの実力を把握することができます。
※関連記事：ユーザビリティテストの手法・工程とは？事例を基にご紹介
https://spice-factory.co.jp/design/usability-test/（新しいタブで開きます）

CMSを導入し自社で運用できるホームページを作りたい

ホームページ導入後の運用作業は、思いのほか負荷がかかります。また、数名の担当者が属人的に運用を行っているケースや、運用を別会社に委託しているため更新に手間がかかるといった声もよく聞かれます。
このような課題を解決し、自社で簡単にホームページを運用できる体制を作りたいと考えている場合、ホームページ運用に関して知見のある制作会社を選びましょう。以下の観点をチェックすることで、制作会社の力量が見えてきます。

• 制作会社に CMS の開発者が在籍しているか
• 依頼したいホームページと類似する案件の実績があるか
• 開発したい CMS の機能をよく理解しているか

特にコーポレートサイトであれば、開発する機能はほぼ定型的なものです。「コーポレートサイトの型」を知っているかも確認ポイントです。
また、どの CMS ツールを導入するか悩んでいる場合は、複数の CMS を対応している会社に多角的に提案してもらうことをおすすめします。

最適なホームページ制作会社の選定によりプロジェクト成功へ

本記事ではホームページ制作会社の選び方について詳細に解説させていただきました。

（新しいタブで開きます）記事中でご紹介した通り、ホームページ制作会社を選ぶポイントとしては、以下の 4点が重要です。

• 対応できる制作規模
• 費用
• 対応範囲
• デザイン力

また、当社では、高度な開発力や UI/UXデザイン、ブランディング、マーケティングと幅広い知見を活かしたホームページ制作を強みとしています。ホームページの新規制作やリニューアルをご検討の場合は、ぜひ（新しいタブで開きます）下さい。
弊社のホームページ制作サービスに関しましては以下URL からご確認いただけます。

https://spice-factory.co.jp/service/web-corporate/

 

アジャイルなシステム開発、デザイン、ブランディング、マーケティングを得意とし、全方位から企業のDXを支援するスパイスファクトリー株式会社です。

• 基幹業務システムが使いづらく、作業に手間がかかる
• サービスを展開しているが、離脱率やアクティブ率に課題を感じている
• Webサイトのパフォーマンスが低く、お問い合わせや申込みなどのCVが伸び悩んでいる

上記のようなお悩みを抱える企業は少なくありません。
このような問題を解決するためにはUI/UXデザインの観点から分析し、改善を検討・実施する必要があります。

この記事では、なぜデザインが重要なのか、どのタイミングでUI/UXデザイン改善が必要になるのか、具体的にどのような改善方法があるのか等をお伝えしていきます。

※ UIデザインとはユーザーとサービス・プロダクトの接点となるインターフェースの設計のことを、UXデザインはユーザーがサービス等を通じて得られる体験の設計のことを指します。

なぜ今“デザイン”が重要なのか

「デザイン」と聞くと頭に何が思い浮かびますか？

多くの人は、「綺麗な色使い」や「イケてるレイアウト」などが頭に浮かぶかもしれませんが、実はこれらはデザインのほんの一部分に過ぎません。

デザインは英語で「設計」。解決すべき課題と新たに創出する価値を定義した上で、ユーザーに適切に伝えるプロセスそのものを「デザイン」といいます。

つまり、デザインは「ユーザーとサービス（システム・アプリなど）を繋ぐコミュニケーション」であり、表層的な見た目を整えることは、作り手の意図を伝えるための手段の一つに過ぎないのです。

どれだけビジュアル面で美しくても、開発された機能が素晴らしくても、作り手が熱い想いを抱いていたとしても、届けるべき相手（ユーザー）に価値を伝えられなくては意味がありません。

そして、サービス作りにおいて本質的なデザインを重視することはもはや常識。
InVisionが提供しているThe New Design Frontierによると、65%以上の企業が世界的に開発や経営に対して積極的にデザイン的思考を活用しているそうです。
日本国内においても、成長企業はデザイン思考の実践に積極的であるというデータが公表されています。
さらに、経産省・特許庁は日本企業の産業競争力を向上すべく、2018年より「デザイン経営」を推進。デザインを重視した経営の実践を呼びかけているのです。

デザインの意義は見た目の調整だけではなく、自社のサービスの課題を解決し、ユーザーにサービスの価値・本質を伝え、使い続けてもらうための重要なプロセスといえるでしょう。

本記事では、サービス改善に主に関わってくる「UI/UXデザイン改善」に焦点を当てて解説します。

UI/UX改善が必要となるケース

デザインが世間的に重視されているとはいえ、「自社の課題が本当にデザインで解決できるの？」と疑問に思われる方もいるでしょう。
そこでUI/UX改善が必要な「あるある」ケースについて、サービスの種類ごとにご紹介していきます。

業務システムの場合

業務を効率よく遂行する上で欠かせない業務システム。
毎日多くの社員が利用しますが、「使えればいい」という理由で、ユーザーの利便性は無視されることが多々あります。
中には、システムのリプレイス（入れ替え）の煩雑さを理由に、古い業務システムを長年使っているような企業も……。

その結果、以下のような問題が発生するケースが考えられます。

• 業務システムの操作性が悪いため、ミスが発生しやすい
• 管理や作業に人的コストがかかる
• 必要最低限のデフォルト機能しか存在しないため、システムのみでは対応できない範囲が発生し、結果人力で行うコストがかかる
• 業務システムが古いことによる情報セキュリティ上の漏洩リスク

業務システムの改修を図る場合、機能やオペレーション改善だけではなく、UI/UX視点でのデザイン変更を行いましょう。
ユーザー視点での使いやすさを考えた設計に変えることで、作業効率が上がり、結果人的コストの削減に繋がります。

アプリの場合

アプリサービスを展開している企業でよくあるお悩みとして、以下のようなケースが挙げられます。

• App Store、Google Playストアなどでのユーザー評価が低い
• インストール数は一定数あるが、MAUや離脱率の数値が悪い
• 購買（コンバージョン）などのビジネス目標が達成されていない

これらも実は、ユーザー視点でのデザインになっていない点が要因の一つです。
iPhoneやAndroidなど、使いやすく設計されたデバイスの操作に慣れきったユーザーはUI/UXデザインにとても敏感。触っていて少しでもストレスがあるアプリは敬遠する傾向があります。

ユーザーに愛されるアプリを作るためには、ユーザーにとって使いやすいか、ユーザーの動きが想定された設計になっているかなど、UI/UXデザインの観点を持つことが重要です。

Webサイトの場合

自社のWebサイトといってもいろいろな種類があります。ここでは種類別によくあるお悩みをご紹介します。

• コーポレートサイトのお悩み
  • 10年近く同じコーポレートサイトを使用しており、古い感じがする
• ECサイトのお悩み
  • サイトの売上が上がらず、ビジネス目標が達成されない
• LP（ランディングページ）のお悩み
  • コンバージョンが伸びない

これらの問題を解決するうえでも、UI/UXデザインの観点が欠かせません。
デザインにも流行り廃りがあるので、いつまでも古いデザイン手法が用いられているとユーザーや取引先、求職者に「考え方が古い企業なのかな？」とネガティブな印象を与えてしまいかねないので注意が必要です。

また、Googleは2020年5月に「ページエクスペリエンスシグナル」という指標を公式に導入しました。これは「検索エンジンではなく、ユーザーの利便性を最優先に考慮してページを作成する」という基本方針で、GoogleがWebサイトのUI/UXデザインを重視していることがわかります。
Googleからの評価が得られなければ、検索順位や流入は当然下がります。売上やコンバージョンの達成のためには、いまやマーケティング視点だけではなくUI/UXデザイン視点も必要なのです。

ここまで読んでくださった方は、UI/UXデザイン改善の必要性について十分理解していただけたのではないでしょうか。
ところが、いざ改善をしようとなったときにぶつかるのが「UI/UXデザイナー不足の壁」です。
UI/UXデザインを改善しようと試みても、以下のようなケースに直面することがあります。

• UIUXの観点から業務システムを改善したいが自社にデザイナーがおらず、システムをブラッシュアップできる体制がない
• 常駐のベンダーに依頼したが、思うような改善が見られなかった

UI/UXデザイナーは高い専門性だけでなく、問題の本質を見極める洞察力や他職種と連携するコミュニケーションスキル、プロジェクトを成功に導くためのプロジェクトマネジメントスキルが求められる職種。高まる需要に反して人材が不足しているのが現状です。
そこで、開発やUI/UXデザインの実績がある専門の会社を選定し依頼することをおすすめします。

必要な体制やリソース・知識がない状態で進めるのではなく、外部の専門家と連携して必要なプロジェクト体制を整えていきましょう。

UI/UX改善の流れ・方法

いよいよ本題のUI/UX改善を行うステップについてお伝えします。
UXデザイン改善をうたう企業は数多く存在しますが、玉石混交。正しいステップを知ることで、プロジェクトを成功に導ける企業の選定に活かしてください。
なお、目的や状況によって適切なプロセスや手法が変わるため、ここではもっともスタンダードな改善ステップを紹介します。

ヒアリング

まずはヒアリングを通してUI/UXデザイン改善プロジェクトの目的を確認。
事業目標、具体的な人物像（ペルソナ）、想定される利用文脈（ユースケース）など全体に関わる要件を整理していきます。

問題点の洗い出し・課題発見

現在のサービス・プロダクトの問題点を洗い出し、改善すべき課題を発見していきます。
代表的な手法として、ブレインストーミングや社内・顧客アンケート、フレームワークを使った分析、競合分析などがありますが、UI/UX改善ではより専門的な視点が必要になります。ここではUI/UX改善でよく用いられる２つの手法を紹介します。

専門家によるレビュー

対象サービスが本当に使いやすいのか、ユーザーにとって価値のある体験を提供できているのか？ 現状を正しく認識するためには、専門的知識があり、かつ客観的にサービスを俯瞰できるUI/UXデザイナーのデザインレビューが必要です。
具体的には、ユーザーの立場でサービスを使ってみて、分かりづらい・使いづらい部分を洗い出してもらいます。

主観に偏らない判断をするため、認知心理学や人間工学の法則を活用したり、「ヒューリスティック評価」などの客観的評価を用いたユーザビリティ検査を用いたりすることもあります。

また、ユーザー体験を向上させる要因として、ページの表示スピード、導線設計、ライティングなども挙げられます。UI/UXデザイナーだけではなく、エンジニア・UXリサーチャー・マーケターなど様々な職種のメンバーの意見を集めることで問題点を幅広く洗い出せます。
改善効果を上げるためにも、各スペシャリストの知見を活かして全体最適できる体制づくりが望ましいといえるでしょう。

ユーザーインタビュー

ユーザーの本質的なニーズを知るうえで効果的な手法として、ユーザーインタビューが挙げられます。ここでいうユーザーとは、実際のユーザー自身かペルソナに近い人物のことを指します。
注意点は、形式的に話を聞くだけでは、ユーザーの個人的な不満や要望を聞く場になってしまうことです。個人の不満を解消して一件でも多く売上を伸ばしたい・解約阻止に繋げたい、と思ってしまいますが、ユーザー自身も気づいていない潜在的ニーズを引き出すことがユーザーインタビューの意義です。
前述の「専門家によるレビュー」と掛け合わせて、定量・定性の両面から課題を洗い出しましょう。

ユーザーインタビューの事前準備で行うことは以下です。

• 目的の設定
• リクルーティング・日程調整
• インタビュー手法・流れの決定
• 役割分担

リクルーティングする際は、インタビューの目的に基づいて対象者と人数を検討しましょう。
対象者を絞り込むため、必要に応じてアンケートを実施します。謝礼の準備も忘れずに。

対象者が決まったら、インタビュー手法や結果の活用方法などの大枠を決めていきます。
インタビューの進め方としては、スクリプトを完璧に決めて行う「構造化インタビュー」や、基本アドリブで進める「非構造化インタビュー」、その中間の「半構造化インタビュー」などがあります。
ユーザーの本音を引き出すためには、自然に話を展開していくことが大事ですが、インタビューの目的によっては定量的な情報を得るほうが効果的な場合もあるでしょう。
インタビュー手法の詳細については以下の記事でも詳しく記載しています。

https://spice-factory.co.jp/design/usability-test

また、インタビュー参加者の役割分担も決めていきましょう。
インタビュアー側は、インタビュアー1人、議事録1人の2人体制が望ましいです。
インタビュアーにはUXの知見が豊富で、かつ分析スキルの高いUXリサーチャーをアサインしましょう。ユーザーを深く理解できるので、サービス・プロダクトの価値向上に繋がる調査が可能になります。

課題の整理／改善案の検討

レビューやインタビューで洗い出した課題を整理していきます。
実施する際はUIデザイナー・UXデザイナー・マーケター・エンジニアなど、専門知識を持つメンバーを集めたワークショップ形式での実施がおすすめです。

ワークショップでは課題の認識合わせや因果関係の整理を行います。
すべての課題を一挙に解決できることがもちろん理想ですが、予算やリソース、プロジェクト期間など現実的な条件も加味し、項目ごとの優先度もここで決めておきましょう。全体を俯瞰して幅広く課題を洗い出せている場合、予算やリソースを抑えて改善できるケースもあります。
作業量をなるべく正確に見積もるためにも、デザインや開発の工程を理解しているメンバーに声をかけましょう。

課題の整理が終わったところで、いよいよ改善案の検討に移ります。ただ議論をするだけではなく、その場で簡単なデザインや骨子（ワイヤーフレーム）に落とし込んでいきます。
改善案を見える化することで、ワークショップメンバー同士の認識齟齬を防ぐことができます。
また、日頃デザイン業務に携わっていないメンバーがプロトタイピングに参加したり、UI/UXデザイナーの手元を直接見たりすることは、デザイン思考の社内浸透にも効果的。

ワークショップの場で課題整理だけでなく改善案の検討までを一気に行うことで、スピーディーなUI/UX改善を実現できます。

実装

いよいよ改善案を実装していきます。UI/UXデザイナーからエンジニアにバトンが渡されることになりますが、実現可能性の検討が十分になされていないと、開発に膨大な工数がかかって納期が遅れてしまったり、最悪プロジェクトが頓挫してしまったりするケースもあります。
改善プロジェクトを行う際は、レビューなど初期のフェーズからエンジニアに参画してもらい、実装を考慮したUI/UX改善を心がけましょう。
エンジニアやデザイナーが密に連携することで、意思決定やプロジェクト全体のスピードを上げることができます。
詳しくは下記記事をご確認ください。

https://spice-factory.co.jp/design/pairing_design_engineering-designer

正しい手順でUI/UX改善を実行し、サービスの利便性・成果を向上させよう

サービス・プロダクトの課題を解決するための手法であるUI/UXデザイン改善についてお伝えしてきました。

UI/UX改善に課題を感じる企業は多いですが、ただ見た目を改善するだけでは解決できないことがほとんど。リソースのない状態で進めるのではなく、ユーザーを深く理解できるUI/UXデザイナーの力を借りましょう。

サービスに関わるメンバーを巻き込んで、齟齬なくプロジェクトを進めることも重要です。
まずは、そもそもUI/UX改善自体が必要な状態なのか、専門の会社に診断してもらいましょう。

スパイスファクトリー株式会社には、UIデザイナー・UXデザイナー・ブランディングディレクター・エンジニア・マーケターなど、UI/UXデザイン改善に必要な知見を持った高度専門人材が在籍しています。貴社の課題を多角的にとらえ、スピーディーなUI/UXデザイン改善に向けたご支援が可能です。

些細なことでもぜひ（新しいタブで開きます）下さい。

https://spice-factory.co.jp/service/uiuxgrowth/

 

社内やチームにて新たなビジネスアイデアに対する PoC を行おうとしている場合、具体的に PoC の計画を立案する必要があります。しかし、何から計画すればよいか、何を確認すべきか分からないと悩まれている方は多いのではないでしょうか。

そこで、この記事ではPoCの計画にあたり事前に押さえるべき8つの項目についてそれぞれご説明します。

弊社では、PoC 支援のサービスも展開しております。クライアント企業様のPoCプロジェクトにおいて、プロトタイプ開発から検証、さらにその先の本開発まで一気通貫でサポートをしています。

詳しいサービス内容は（新しいタブで開きます）をご覧ください。

また、弊社スパイスファクトリーには豊富な実績があります。弊社の概要やサービスプラン、過去の導入実績などをまとめた資料をご用意しました。気になる方はこちらからダウンロードしてください。

PoC の計画にあたり押さえるべき8つの項目

PoC は新規事業やビジネスアイデアに対して、試作と検証実験を行い、持続的な有益性があるかを検討します。
アイデアだけで終わらせず、新規事業や新たなプロダクトが会社の利益と発展につながるかを検証する、重要な実証実験です。

このような PoC プロジェクトを成功させるために、どのような点を押さえて計画するべきか。
絶対に押さえておくべき項目は以下 8つの項目になります。

• ①目的・ゴール
• ②KPI
• ③スコープ
• ④ターゲット
• ⑤プロトタイプ種別
• ⑥体制・役割
• ⑦スケジュール
• ⑧予算

次項から各項目についての詳細をお伝えします。

①目的・ゴール

PoC を行うにあたり、まずは PoC の目的を整理することが重要です。
この目的・ゴールの項目では、PoC の目的を明確にすることと PoC を通して何をやるのか、大筋の流れを計画します。また、PoC の次に進むべきアクションも事前に仮説を立てて整理する必要があります。

PoC は、実際のシステム開発や事業開発とは異なるため、事前にきちんとやるべきことを整理しておかなければ手段が目的化するリスクがあります。
最近では、無意味な検証を実施しお金をどぶに捨ててしまう行為を指す「PoC死」という言葉も出てきており、注意が必要です。

また、企業規模が大きくなればなるほど「PoC をする」という会社の方針は決まっているが、実際にプロジェクトを担当する当のメンバー達が「何をどうすればいいかわからない」と目的が不明瞭になっている事態が起こりやすいです。
その場合は、PoC の目的整理などから DX や PoC をサポートしてくれるベンダーに伴走してもらうのも一つの手です。

②KPI

次に PoCプロジェクトの KPI を事前に整理しておくとよいでしょう。
KPI を定めることで、社内で次のアクションを進める際の指標になります。その指標がユーザビリティをはかるものだと、PoC 前後の KPI数値を比較できるため効果測定の幅を広げることにもつながるでしょう。

ちなみに UX に関する KPI には、行動KPI と態度KPI の 2種類があります。

行動KPI とは、ユーザーの行動を数値化したもので、タスク成功率やタスク処理時間などを指します。
態度KPI は、ユーザーが利用後にどのように感じているのかを数値で測定するもので、システムユーザビリティスケール（SUS）、ネットプロモータースコア（NPS）、顧客満足度（CSAT）などを指します。

上記の KPI については以下の記事で詳しく紹介していますので、あわせてご覧ください。

https://spice-factory.co.jp/design/poc_step/

③スコープ

PoC の目的とゴールを決めたら、次は PoC の対応範囲を明らかにしていきます。
スコープは欲張りすぎず、目的達成できる最小限の範囲で決めていくのがおすすめです。ここで欲張りすぎると、リスク低減や開発コスト削減といった本来の PoC のメリットが得られなくなる恐れがあります。

PoC にどのようなメリットがあるかについては下記記事が参考になります。

https://spice-factory.co.jp/design/what_is_poc/

既存システムのリニューアルやフィジビリティスタディですでに現状課題がある程度ある場合は、その課題に対して必要なアプローチを検討していきます。PoCでどこまで何をやるかなどスコープを明確にすると、課題に対するアクションを絞りやすいでしょう。

自社で新しいサービスの PoC を行う場合、欲張らずそのサービスのメイン機能やこれから注力したいところに絞るのも一つです。

④ターゲット

PoC の目的とゴール、スコープを決めたら、次はターゲットを明確にしましょう。
今回のプロダクトは誰が利用するのか、それはどういう人なのかを事前に整理する必要があります。

PoCプロジェクトが始まったからといって急にプロトタイプの開発に着手するのは危険です。プロジェクト開始の前に、ターゲットユーザーを理解するというフェーズがありますので、以下のような手法を用いて実際に理解を進めていきましょう。

• デプスインタビュー
• エスノグラフィー調査
• 競合調査

このタイミングで、ターゲットはある程度明確にしておきましょう。

⑤プロトタイプ種別

PoC では、検証に使用するプロトタイプを作成する事が多いので、どういったプロトタイプをつくるかを明確にしておくと今後の体制や予算について考えやすくなります。
参考：システム開発におけるプロトタイプ・モデルのメリットと注意点（新しいタブで開きます）

PoC の外注を考えている場合は、このあたりを含めていくつかのベンダーに相談してみるのもよいでしょう。

（新しいタブで開きます）

プロトタイプ種別は以下の通りです。

• ファンクショナルプロトタイプ
• デザインプロトタイプ
• コンテクスチュアルプロトタイプ

それぞれ解説していきます。

ファンクショナルプロトタイプ

ファンクショナルプロトタイプは、サービスの一連の導線を確認することができるプロトタイプです。紙で設計してテストするペーパープロトタイプなどを使い、デザインのアイデアを画面レイアウトやコンテンツに落とし込みます。

ファンクショナルプロトタイプを選ぶメリットは、比較的スピーディかつ安価で作成でき、サービスの流れをユーザーに確認できる点です。また、検証で出た課題を素早く反映し、検証サイクルを繰り返し回すことも容易です。

デザインプロトタイプ

デザインプロトタイプは、Figma・Sketch・Adobe XD などのプロトタイピングツールを使ったリアリティを持たせたプロトタイプです。ファンクショナルプロトタイプに具体的な色や形、動きを加えた試作で、見た目をより完成品に近付けたものとなります。

デザインプロトタイプを選ぶメリットとしては、機能に加えてデザイン面も完成形に近づけるので、機能面のチェックに加えて視認性も確認できることです。また、本開発に近いレベルまで解像度を上げることは、操作性などユーザーの「感性・感覚」までを含めた検証を可能とします。

コンテクスチュアルプロトタイプ

コンテクスチュアルプロトタイプは、文脈的なプロトタイプを意味します。ユーザーに製品の利用時のイメージを抱いてもらうためのプロトタイプという理解をしていただくとよいでしょう。
たとえば、アプリを実際に使用している様子を動画で撮影し、ユーザーへ公開するといったイメージです。

コンテクスチュアルプロトタイプを選ぶメリットとしては、ユーザーに疑似体験をしてもらうことで、実体験のように体感した感覚で新しい製品の良し悪しがわかることです。

⑥体制・役割

プロトタイプの方針を決めたら、次はチーム体制を考えましょう。
PoC の目的や KPI、スコープなどが見えてきたらアサインすべき最適なメンバーが判断できるようになります。

考えられるアサインメンバーは、ビジネスディベロップメント・マーケター・UI/UXデザイナー・UXリサーチャー・エンジニアなどです。

PoC を社内で進める場合は、関連部門などもあわせて体制を整えてください。
社外に依頼する場合は、この時点で細かく決めずともある程度提案してもらえると考えてよいでしょう。

⑦スケジュール

チーム体制を考えたら、次に PoC のスケジュールを決めましょう。
PoC の納期を区切るだけでなく、PoC の準備フェーズや PoC 後の流れも踏まえてある程度大筋を整理する必要があります。

PoC の準備フェーズでは、ユーザーリサーチやコアバリュー策定などで最短でも1か月ほどかかります。
PoC 実施では、実際にプロトタイプ開発を実施し、検証を行います。選択したプロトタイプの種別によってスケジュール感は大きく変わってきますが、ここも最低でも1か月はかかることが多いです。
PoC 後の流れというのは、PoC の実施後の本開発などを指します。この段階で詳細なスケジュールを決める必要はありませんが、PoC がうまくいった場合はその次にどう進めていくのかをざっくりで良いので考えておきましょう。
実際のプロダクトローンチの期限がある程度予測できるのであれば、今後の PoC のスケジュールにも大きくかかわってくるため明文化しておいた方がよいでしょう。

また、PoC 後そのまま本開発に入りたい場合は、極力本開発の際の実現可能性を踏まえて進めてください。

具体的には、実際の本開発で実装できるかどうかという観点でエンジニアレビューを入れたり、問題がある場合は即座に解決方法を探したりと持続的に実現可能なプロダクトなのかを判断します。
プロトタイプ段階でエンジニアによるレビューを入れることで、本開発に進んだ際の手戻りを防げます。実現可能性や費用対効果をみながら検証することが重要です。

そうすること、スピーディに PoC から開発へ進めることが可能です。

当社、スパイスファクトリーは、PoC から本開発までの一気通貫支援を強みとしています。PoC や開発まわりでお悩みの方はぜひください。

⑧予算

スケジュールを立てる際に、会社の予算が決まっている場合はそこに合わせて計画を立てていく必要があります。
特に予算が決まっていない場合で、他部署が PoC や DX に関する取り組みをしている場合はその際の予算や実施内容をひとつの参考にするのもよいでしょう。

また、一般的に PoC の予算相場は、サービス内容や開発期間にもよりますが、100万円〜数百万円となります。
すでに構築しているものをカスタマイズして開発する場合は、費用が安くなる場合もあります。
逆に一から開発を行う新規プロダクトの場合は、相場より高くなる場合もあります。

正しい計画の立て方を実践し、PoCプロジェクトの成功へ

PoC の計画を立てるにあたって、押さえるべき項目をお伝えしてきました。
少しでも、あなたのビジネスのお役に立てましたら幸いです。PoC の計画を立てる際はもちろん、計画書や RFP 作成にもお役立てください。

また、本記事の中でご不明点などございましたら、お気軽にご相談くださいませ。

当社は PoC から本開発までの一気通貫支援や、最短2か月でのPoC 実施が可能です。
弊社の詳しいサービス内容は（新しいタブで開きます）をご覧ください。
PoC やシステム開発、新規ソフトウェアの開発についてお悩みがありましたら、ぜひください。

また、弊社スパイスファクトリーは豊富な実績を持ち、これらのプロセスを効率的に進めるためのサポートを提供いたします。

詳細を知りたい方は、こちらからサービス紹介資料をダウンロードしてください。

スパイスファクトリー株式会社アプリエンジニアの木村です。
この記事では、ネイティブアプリ開発経験者がFlutter開発に取り組んだ上で見えてきた、Flutter開発の特徴や気を付けるべきポイントなどをまとめます。
また弊社ではクライアント企業のＤＸを推進しております。詳しいサービス内容は（新しいタブで開きます）をご覧ください。

Flutterとは

Flutter とは、Googleが開発したアプリケーションフレームワークです。
クロスプラットフォームに対応しており、単一のコードで各プラットフォーム(iOS,Android,Web)のアプリを同時に制作することが可能です。

手前味噌ですが、当社ではFlutter開発の相談も承っていますので、是非お気軽に問い合わせください。

 

Flutterの特徴

Flutter は以下のような特徴を持ちます。

標準Widgetの種類が豊富

標準で用意されている Widget の種類が豊富で表示パターンが複雑化してもある程度は標準のWidgetで賄えます。さらに、Android・iOSの出し分けが必要だとしても、どちらのレイアウトも簡単に作成できます。

アプリがクラッシュする頻度が減る

これをメリットと捉えるかどうかは人それぞれだと思いますが、Flutter はrenderingを自身で行います。そのため各プラットフォームに依存せず、例外エラーでアプリがクラッシュする確率が下がります。ただし、例外エラーが発生すると赤い画面が表示されるので例外処理は必須にはなります。

開発言語はDart

言語はDartを使用して記述します。JavaやJavaScriptに文法も似ているのでwebアプリ開発経験者がモバイル開発をする上でもインプットしやすいです。
またDartはGoogleが開発しているので安心して使用できるという期待もあります。
※2021/6現在では主にiOS/Androidでの開発が他のプラットフォームより活発になっています。

Flutter 開発に実際に取り組んだ上での気づき

先述したような特徴をもつ Flutter ですが、私自身が実際に開発を進めた上での気づきは以下です。

iOS/Android両方のアプリの品質を担保できる

従来のアプリ開発は、1つのアプリを開発する為に、iOSエンジニアとAndroidエンジニアそれぞれが開発を進めていました。そのため、同じ機能を開発するにしても、各OSへの落とし込みの段階で差異が生まれることがあります。

その点、Flutter を使えば1コードでの開発が可能なので、同じ品質を担保できるメリットがあると感じました。

工数が純粋に2分の1になるわけではない

一方で、純粋に開発工数が半分になるかというとそうでもありません。Flutter で開発を始める前は、Flutter が1コードで開発できるのであれば純粋に工数も半分になるのかと思っていましたが、そのようにはなりませんでした。

簡単なアプリであれば、工数を半分に抑えられることもあるかと思いますが、プッシュ通知機能、カメラ、位置情報等を活用するリッチなアプリを開発する場合はネイティブ開発と比較し4分の3程度の工数の着地を見込んでおくといいかもしれません。
パーミッションやビルドセッティングについては、1回で終わりではなく、各OSの設定を行う必要があり、一概に2分の1にはならないというのが私自身の所感です。
また、Flutter がカバーしていない部分については各OS側でプログラムを書く必要もあり、特に時間がかかるポイントかもしれません。

Auto layoutを使用せずに開発できる為、UI作成の負担が少ない

Flutterは、Auto layoutを使用せずに開発できる為UI作成の負担が少ないのも大きなメリットだと、開発していて感じました。
以下、コード例になります。

【コード】

dart
　Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        centerTitle: true,
        title: const Text(
          'テスト',
          style: TextStyle(color: Colors.black),
        ),
      ),
      body: Center(
        child: Container(
          color: Colors.red.shade50,
          // Widgetの縦並び
          child: Column(
            mainAxisSize: MainAxisSize.min,
            children: [
              Text('コンテンツ1'),
              // Widgetの横並び
              Row(
                mainAxisSize: MainAxisSize.min,
                children: [
                  Text('コンテンツ2'),
                  Text('コンテンツ3'),
                ],
              ),
              Text('コンテンツ4'),
            ],
          ),
        ),
      ),
    );
  }

 

View

比較的Android寄りのUIのため、iOSのデザイン調整が必要なことがある

Flutter はMaterial Designを採用しており、Android寄りのUIになっています。
そのため、iOSユーザーにとってはあまり見慣れないデザインになってしまうことがあります。要所要所で各OSのデザインを作成する必要があります。
ちなみに、MVCで言うViewの部分を Flutter では Widget と呼びます。
この Widget の書き方がネスト構造なので、iOS開発している方ははじめは見慣れないかもしれません。実際、私自身もdialogを各OSで分ける対応をしました。

Android	iOS
https://api.flutter.dev/flutter/material/AlertDialog-class.html	https://flutter.dev/docs/development/ui/widgets/cupertino

公式ドキュメントが充実しており、技術記事も豊富なので課題解決までがスムーズ

公式ドキュメントが充実しており、これだけでも、ある程度開発を進めることが可能です。
Flutter 界隈も動きが比較的活発で英語であれば技術記事も豊富なので、Flutter に関しての不明点は、検索すればある程度解決出来ると感じています。

Flutter習得の難易度について

Flutter の習得の難易度についてですが、ネイティブ開発経験者から見ると比較的易しいという印象です。
ネストについては最初は慣れが必要ですが、UIはネイティブで書くより簡単でコード自体も短くなる為、取り組みのハードルはおそらく低いです。
また、ネイティブ開発未経験者から見ると易しくはありませんが、難しいという程でもないです。
前述の通り、Flutter 界隈がかなり活発なのでエラーで検索すれば英語にはなりますがある程度解決策は見つかります。
日本語の記事は出てこないことの方が多いですが、英語の情報も読む数をこなせば慣れてきます。
ただし、webと違う点を抑える必要があります。

• ライフサイクル
• プッシュ通知
• オフラインでも起動可能

特に JavaScript と記法が似ているため JavaScript 経験者はコードを読みやすいと思います。

Flutterの特徴やポイントを押さえれば、品質を担保しながら効率の良い開発が可能に

ネイティブアプリ開発経験者からみてFlutter開発に移行してみた所感を書きました。
Flutter の特徴やポイントを押さえれば、品質を担保しながら効率の良い開発が可能になります。
また、弊社では開発からサービスの運用まで、幅広くご支援させていただいております。詳しいサービス内容に関しては、当社ホームページの（新しいタブで開きます）をご参照ください。

当社では現在 Flutter を重要なコア技術とみなして複数の案件の開発に採用しています。
Flutter を用いた開発に興味をお持ちの方、一緒に仕事をしませんか！

採用に関してはこちら

 

スパイスファクトリー株式会社の古茶です。
コロナ禍で一層デジタル化が進む中、Webサイト上でのユーザー体験はより重要度を増してきています。デザインの見やすさから機能面での使いやすさまで、様々な要素が Web 上でのユーザー体験を形作ります。
そこで今回は、デザインから開発まで一気通貫で支援を行う当社が取り組んでいる「ペアデザイン」についてご紹介します。また弊社の詳しいサービス内容は（新しいタブで開きます）をご覧ください。

エンジニアとデザイナーによるペアデザインとは

まず、ペアデザインとは何かについてご説明していきます。

ペアデザインとは、2 人以上で同じデザインタスクを行うことです。

一般的な開発手法では、デザインはデザイナーのみで進め、開発はエンジニアのみで進めるケースが多いです。
よって、ペアデザインはデザイナー同士で行うことがほとんどです。

しかし、この場合デザイナーとエンジニアの役割が分断されてしまい、プロジェクトの進行やプロダクトの開発自体に様々な弊害が生じる可能性があります。

そのため、スパイスファクトリーでは、デザイナー同士のみでなくデザイナーとエンジニアでもペアデザインを行っています。
エンジニアとデザイナーが同時にデザイン設計に入り密にコミュニケーションをとることで、エンジニア・デザイナー両者の視点を取り入れながらプロダクトを製作していくことができます。これがプロダクトのクオリティ最大化につながるのです。

なぜペアデザインをやるのか

ペアデザインを行う理由は大きく分けて2つあります。

より良い顧客体験の実現

冒頭でも述べた通り、良い Webサービスを作るためには、ユーザーにいかに優れた体験を提供するかという UI/UX の視点が欠かせない時代になってきました。

そこで、デザイナーだけでなくエンジニアにもユーザー体験設計プロセスに入ってもらうことで、より良い顧客体験を実現できるWebサービス制作が可能になります。良いWebサービス制作にはエンジニアとデザイナーの協業は必要不可欠になるのです。

作業工程の効率化

エンジニアとデザイナーで作業工程が分かれていることにより発生する問題を防ぐため、というのが大きな理由です。

一般的に、デザイナーは良いユーザー体験ができることを考え、エンジニアはそのデザインが実現可能かを考えます。このように作業が分断される中で起こりうる問題は以下のようなものです。

 

• 意思疎通が上手くいかず、スムーズに課題の解決が進まない
• お互いの高度なスキルを最大限活かしきれない
• ゴールへの考え方や価値観が異なり、開発過程で行き違いが起こる

 

 

デザイナーがせっかく良いデザインを考えたのに、実現が不可能だったら意味がないし時間の無駄になってしまいすよね。
このような問題が起きないようにするためにも、設計フェーズからエンジニアとデザイナーが共にペアデザインを行う必要があります。
デザイナーとエンジニアが同時にデザインの作業工程を進めることで、スムーズに開発を進められるのです。

よって、エンジニアとデザイナーのペアデザインは実現可能な範囲でより良いユーザー体験を考える方法だと言えます。
（新しいタブで開きます）

ペアデザインの流れ

今回は、当社で行っているペアデザインの進め方について説明していきます。フローは以下の通りです。

• 1. エンジニア・UIデザイナー・UXデザイナー・場合によってはクライアントが共同でフローチャートやユーザーストーリーを書く
  2. 共同で「サービス内でユーザーができうる全ての行動」をユーザー視点で洗い出す
  3. UXデザイナーが体験設計を検討する
  4. UIデザイナーが体験設計に合ったインターフェイスを検討し用意する
  5. エンジニアが実現可能性を検討し、デザイナーの設計にレビューを入れる

通常、ペアデザインでは、作業をする人とその人にアドバイスをする人、という2つの役割を置きデザインを行います。しかし、当社では必ずしもそれらの役割を明確に設ける必要はないと考えています。

エンジニアとデザイナーが別観点で意見交換をすることをメインの目的とし、ペアデザインを導入している場合は、常に意見交換をしながら作業を進めていけば良いのです。

ペアデザインをすることのメリット

ここでペアデザインを行うことのメリットをご紹介していきます。

相手のスキル・思考法を学ぶことができる

異なる知見や価値観をもったエンジニアとデザイナーが共にデザインタスクを行うことで、相手のスキルや思考法を学ぶことができます。また、1人では解決できなかったこともスピーディーに解決することができるでしょう。

知識を共有し合うことで、新たな視点を互いに取り入れることが可能になり、全社的なスキルアップにも繋がります。

意思決定や開発全体のスピードがあがる

ペアデザインでは、エンジニアとデザイナーが 2人以上ですり合わせをしながら設計を行っていきます。
そのため、ウォーターフォール型の開発にありがちな「実装負担を無視した実現性のないデザイン」が出来上がることを避けることができ、結果的に意思決定や開発全体のスピードが上がります。

また、お互いにリカバリーし合いながら開発を進めることで意思決定時の個人への負担が軽減され、アジャイル思考で開発を進めていくことができます。

ウォーターフォール型開発とアジャイル開発についての詳細はこちら（新しいタブで開きます）をご覧ください。

早い段階でプロトタイプができる

ペアデザインで開発を進めることで、プロジェクトの初期段階から比較的解像度の高いプロトタイプ（デザインの作りこみや画面遷移などが設定されているデモ環境）を作成することができます。

これにより、早い段階でユーザビリティテストを実施することができます。つまり、クライアントやユーザーにも早い段階でプロダクトの具体的なイメージを持ってもらうことができるのです。

このようにペアデザインは、社内にもお客様にもメリットの大きい手法となっています。

ペアデザインでクオリティを最大化する

以上、ペアデザインについて、概要や進め方、メリットをご紹介しました。
ペアデザインを行うことは、プロジェクト全体の工数削減のみならず、プロダクトのクオリティの向上にもつながります。

スパイスファクトリーでは、最新テクノロジー、UIUX、アート、マーケティングなどあらゆる技術・メソッドを用いてクライアントのデジタルトランスフォーメーションを支援しています。

デザインや開発についてお悩みやご質問をお持ちの方は、是非一度ください。
また弊社の詳しいサービス内容は（新しいタブで開きます）をご覧ください。

 

最新テクノロジー、UIUX、アート、マーケティングなどあらゆる技術・メソッドを用いてクライアントのデジタルトランスフォーメーションを支援しているスパイスファクトリー株式会社です。

こちらの記事では、当社で数多く支援してきた経験をもとにWEBサイト制作プロジェクトの進め方を解説いたします。

WEBサイト制作とは

WEBサイトの制作方法にはいくつかの種類が存在します。まずはその種類から見ていきましょう。
たとえば以下のようなパターンがあります。

• WordPressを利用する
• ホームページ作成サービスを利用する
• ブログサービスを利用する
• ゼロからコードを書く

どの手法も一長一短がありますが、オリジナルのデザインにしたい場合など、本格的にサイトを制作したいのであればWordPressを用いる、もしくはゼロからコードを書いて作成する方法が適しています。
WordPressを用いる場合も、ゼロからコードを書く場合もHTMLやCSS、PHPといったプログラミングの専門知識が必要になるため、社内や自分自身にノウハウがない場合はサイト制作のプロに依頼して作成してもらうのが一般的です。
当社では主にWordPressを用いたサイト制作を行っています。本記事ではWordPressを用いたサイト制作プロジェクトを想定して解説をしていきます。

WEBサイト制作の工程

この章では、当社が実際に行ってきたWEBサイト制作の事例にもとづいて、WEBサイト制作の工程を順にご紹介します。

サイト制作の目的整理

サイト制作のプロジェクトではいきなりサイトを作り始めるといったことはほとんどありません。
まずは、サイトを制作する目的を整理します。
たとえば、採用サイトであれば優秀な候補者が応募してくれること、ECサイトであれば商品の販売ができ、大きな売上を作るといったことが目的として考えられます。
作成したい理由や、クライアントの抱えている課題によっても目的は異なりますが、サイトが完成した後に「こんなはずじゃなかった」といったことにならないためにもプロジェクトメンバーが目的を共有することは非常に重要な工程です。

競合調査

競合他社のサイトの調査・解析を行います。
基本的には同業他社のサイトなどを参考にすることが多いですが、デザインや情報の見せ方などの参考として無関係の業界や海外のサイトを参考にする場合もあります。
他社サイトの良い点、悪い点を洗い出し、自分たちのサイト制作プロジェクトに活かします。

ペルソナ・カスタマージャーニーの策定

次にサイトのペルソナを作成します。
ペルソナとは、サービスやユーザーのターゲットとなる人物像を具体化したものです。年齢や性別、家族構成やライフスタイルに至るまで本当にその人物がいるかのように人物像を設定します。
プロジェクトに関わるメンバーがペルソナを共有することで、サイトを使うユーザーがどんな情報を必要としているか、情報の優先順位や伝える順番、使用する単語はどうするべきかといった課題をスムーズに解決することができます。

また、このタイミングでカスタマージャーニーマップもあわせて作成します。
カスタマージャーニーは、作成したペルソナが実際にサイトに訪問してから離脱するまでに取る行動や思考、感情を時系列で表したものです。
カスタマージャーニーマップを作成することで、ペルソナがサイト内で取る行動のどこに課題が生じるか、どんなタイミングでどんな情報を欲しているかを把握しやすくなります。
ペルソナ・カスタマージャーニーの作成にあたっては、ユーザーの理解を深めるためにアンケート調査やユーザーインタビューなどの調査を実施する場合もあります。

カスタマージャーニーについては以下の記事が参考になります（外部サイト）↓
カスタマージャーニーとは？ジャーニーマップの作り方や具体的な事例をご紹介（新しいタブで開きます）
ペルソナについてはついては以下の記事が参考になります（外部サイト）↓
今さら聞けない「ペルソナ」とは。意味やマーケティングでの活用方法、作り方も解説！（新しいタブで開きます）

ユーザー目線の導線設計

ユーザーにとって適切な導線設計（サイト内のリンクや案内の設計）を行います。あるページに来たユーザーが次に欲しい情報にスムーズにアクセスできるように、ペルソナ・カスタマージャーニーを踏まえて考えていきます。
関連性が深いコンテンツに関しては、双方向での行き来が可能となるようにリンクを設計することも重要です。

ワイヤーフレーム作成

ワイヤーフレームやペーパープロトタイプなどのプロトタイプを作成して、どのようなUI（ユーザーインターフェース）が有効かを検討します。
ワイヤーフレームとは、ページのレイアウトを決めるために作成する設計図のようなものです。
ユーザー目線の導線設計のフェーズで決めた導線を実現するために、ページのどこにリンクを設置するか、どのページにどんな情報をどんな順番で配置するかなど、要件や骨格の検討を繰り返し、UIの具体化を行います。
ワイヤーフレームについては以下の記事が参考になります（外部サイト）↓
ワイヤーフレームとは何か？webサイト制作に重要なページ設計図を理解しよう！（新しいタブで開きます）

デザインヒアリング・トンマナ策定

サイトの目的やブランドのコンセプト、ユーザーに与えたい印象などをヒアリングした上で、ページ全体のトンマナ（トーンアンドマナー）を決定します。
トンマナはデザインをする際の色調や文字フォント、デザイン様式などのルールのことを指します。トンマナに沿ってデザインすることで、サイト全体にわたってデザインの統一感を保つことができます。
具体的には、デザインのキーワード、カラー、ムードボードといったものを決定・作成してルールを共有していきます。

ビジュアルデザイン作成

ワイヤーフレームを元に、表層のデザインや画面遷移を施したデザインカンプ（デザインの完成イメージ）を作成します。
この段階までくると見た目のデザインに関してはかなり完成品に近いものとなっています。デザインカンプを作成することによって、実際の操作性やサービスを通して得られる体験といったユーザーの「感性・感覚」までチェックすることができます。

コーディング・CMS構築

ビジュアルデザインが決定したら、コーディングをしてWEBサイトを作成していきます。この工程はWEBエンジニアが担当します。
具体的には以下のような作業を行います。

• HTML,CSS,JavaScript等コーディング
• CMS設計・構築
• 各デバイスへの表示対応（レスポンシブ）
• SEO対策

CMS については以下の記事が参考になります（外部サイト）↓
CMSとは？初心者でもわかるCMSの基礎知識とメリット、導入事例（新しいタブで開きます）

多言語機能実装

プロジェクトの内容にもよりますが、日本語だけでなく、英語などの多言語での表示が可能になるように設計することもあります。
プログラムで実装することも可能ですが、WordPressではプラグインを用いて比較的簡単に実装することができます。

セキュリティ対策

不正アクセスによる WEBサイトの改ざんや情報漏洩の被害が近年急増しています。
そのため、WEBサイトのセキュリティ対策は必須です。

企業にとって甚大な被害を引き起こしてしまう前に、セキュリティ対策をすることが大切です。

WEBサイトにはさまざまな脆弱性が存在し、そこを狙って悪意のある人物が攻撃を仕掛けます。
たとえば、以下のようなものをあげることができます。

• SQLインジェクション
• OSコマンドインジェクション
• ディレクトリトラバーサル
• クロスサイトスクリプティング
• バッファオーバーフロー

上記のように脆弱性を狙った攻撃パターンは多岐に渡ります。加えて、サイバー攻撃の手段は日々巧妙化・多様化しています。
こうした脅威からWEBサイトを守るためにも、以下のような取り組みを行うことが大切です。

• 定期的なアップデート
• 不要なファイルやページを公開しない
• 不要なアカウントを削除する
• ログの管理・保管を行う
• （WordPressの場合）セキュリティプラグインを使用する

以上のような比較的取り組みやすい対策はもちろんのこと、より専門的な対策をするとさらに安全が高まります。
専門的な対策としては、以下のような例をあげることができます。

• ファイアウォールの活用
• IPS（侵入防止システム）の活用

これらの対策はこの後ご紹介するサーバーの選定の際に対策が可能です。

サーバ選定

WEBサイトのデータを格納するサーバーを選定します。
クライアントが用意しているサーバーを使用する場合もありますが、当社ではサイト公開後の運用保守やセキュリティおよびメンテナンスにまで携わらせていただくことを考慮してレンタルサーバーをご提案することが多いです。前の項で述べたファイヤーウォールやIPSといったセキュリティ対策についても、レンタルサーバーの企業側で対応してくれることが多いため安全性の担保もできます。

また、海外でのサイト公開時には海外専用のサーバーで対応するケースもあります。
たとえば中国でWEBを公開する場合、現地企業の限定されたICP登録が必要です。
そのため、国内レンタルサーバーを使用することができません。
このような場合、AWS中国リージョンアカウントを現地運用会社およびプロバイダーに依頼して立ち上げる、のような対応をする必要があります。
目的や要望に合わせて適切なサーバ選定を行います。

テスト・リリース

リリース前には対象デバイス、ブラウザでの表示テストや、フォームテスト、境界値テスト、ブラックボックステストなどの各種テストを行います。
PC・スマホ・タブレットなど、異なるデバイスで見やすく正常に表示されることや、画面サイズが変化しても表示が崩れないか、リンクの遷移先が正しいかなどを総合的にチェックしていきます。
そして、テスト完了後にリリースします。

運用保守

リリースができたら、いよいよサイト運用開始です。
リリースはサイト制作の一旦のゴールではありますが、ビジネスとしてはサイトの完成はむしろスタートといえるでしょう。リリース後もサイトが安定して稼働し、制作の目的に合致した運用ができるように運用保守を行います。
リリース後は通常、サイト解析などを行い、ユーザーがサイトの目的に合った行動を取れているかを確認します。課題が見つかればデザインや導線修正をしたり、コンテンツの追加をしたりします。
具体的には以下のようなことを行い、サイトをより良いものにしていきます。

• Google AnalyticsなどのWEB解析ツールでサイト解析をする
• バグが発見された場合の修正
• デザインテンプレートの追加
• 追加コンテンツの作成
• CMS追加機能のカスタマイズ
• （WordPressの場合）バックアップやアップデート対応

WEBサイト制作はプロに任せる選択肢もある

以上、WEBサイトの制作工程についてお伝えしてきました。
WEBサイト制作にはやることがたくさんありますが、目的をぶらさず一つひとつの工程を丁寧に実施することで着実に良いサイトになっていきます。
システムやデザインの知識など、専門性が必要な部分もあるので、ノウハウがない場合はプロに任せることも選択肢の一つです。
当社、スパイスファクトリーでも上流工程からデザイン、運用保守まで一貫してサイト制作をすることが可能です。
何かお困りのことや弊社に対するご質問がございましたら（新しいタブで開きます）ください。
また、詳しいサービス内容に関しては、当社ホームページの（新しいタブで開きます）をご参照ください。

参考文献

執筆にあたり、以下の記事を参考にさせていただきました。

Webサイトを作る4種類のおすすめ方法の比較！（新しいタブで開きます）
Webサイト立ち上げ時にやるべきセキュリティ対策
webセキュリティとは？基礎知識やWebサイトを守るための対策法について紹介！

 

クライアント企業のDXを推進しているスパイスファクトリー株式会社、Ruby on Rails エンジニアの田中です。弊社の詳しいサービス内容は（新しいタブで開きます）をご覧ください。

今回は、クラスメソッドを定義する時に用いる class << self; end の記法について、この記述でクラスメソッドを定義できる理由を説明したいと思います。
私自身が Ruby を学び始めた時に理解につまずいた部分でもあるため、この記事が同じような悩みをお持ちの方にとって参考になれば幸いです。

Ruby ではクラスもオブジェクトとして扱われる

Ruby 3.0.0 リファレンスマニュアル（新しいタブで開きます）で述べられる通り、「Ruby で扱える全ての値はオブジェクト」であるという前提をまずは理解する必要があります。
これはつまり、クラス自身もオブジェクトであるということです。

例えば、以下の2種類のクラス定義はほとんど同義と言えます。

# class を用いる場合
class Human
  def hello
    puts 'hello'
  end
end
human = Human.new
human.hello #=> hello

 

# Class クラスのインスタンスを生成し、定数 Human に保有させる場合
Human = Class.new do
  def hello
    puts 'hello'
  end
end
human = Human.new
human.hello #=> hello

 

全てのインスタンスには必ず特異クラス（シングルトンクラス）が存在

次に、Ruby では、どんなインスタンスにも必ず特異クラスが存在するということを理解する必要があります。

そもそも、この「特異クラス」とは何でしょうか。
特異クラスとは、特定のインスタンスのみに適用されるクラスの事を指します。
そしてクラスメソッドというのは、あるクラスの特異クラスに定義されたメソッドのことを指しているのです。

より深く理解するために、特異クラスとインスタンスやクラスがどんな関係にあるのかをみていきましょう。

まずはごく単純に、インスタンスとクラスの関係を考えてみます。
これらの関係は下図のようになっています。
child インスタンスの class が Child クラスということです。

コードにすると次のようになります。

class Child
  def child_method
    puts 'This method is "child_method"'
  end
end
child = Child.new

puts child.class #=> Child
puts Child.instance_methods(false) #=> child_method

 

次に親クラスを導入してみます。
これらの関係は下図のようになっています。
Child クラスの superclass が Parent クラスということです。

コードにすると次のようになります。

class Parent
  def parent_method
    puts 'This method is "parent_method"'
  end
end
parent = Parent.new

class Child < Parent 
　def child_method 
　　puts 'This method is "child_method"' 
　end 
end 
child = Child.new
 
puts parent.class #=> Parent
puts Parent.instance_methods(false) #=> parent_method

puts child.class #=> Child
puts Child.superclass #=> Parent
puts Child.instance_methods #=> child_method, parent_method, ・・・（省略）

 

最後に、特異クラスを導入してみます。特異クラスには以下の特徴があります。

• シングルトンクラスとも言われ、1つのインスタンスしか持たない。
• Rubyでは、どんなインスタンスにも必ず特異クラスが存在する

言葉で表現すると分かりにくいですが、つまりは次の図のようになっているということです。

コードにすると次のようになります。

class Parent
 # （省略）
end
parent = Parent.new
 
class Child < Parent
 # （省略）
end 
child = Child.new
 
puts child.singleton_class #=> <Class:#<Child:0x00007fb3e9aa7338>> ( #<Child:0x00007fb3e9aa7338> は「 Child クラスのインスタンス」を表す )
puts child.singleton_class.superclass #=> Child
 
puts Child.singleton_class #=> <Class:Child>
puts Child.singleton_class.superclass #=> <Class:Parent>
 
puts Parent.singleton_class #=> <Class:Parent>

 

特異クラスとは何か、インスタンスやクラスとどんな関係にあるのか、ご理解いただけたでしょうか。

class < <object; end 内のメソッド定義 = object の特異クラスへのメソッド定義

ここまで、Rubyではクラスもオブジェクトであることや、全てのインスタンスには必ず特異クラス（シングルトンクラス）が存在することを説明してきました。

ここからは、class << object; end のスコープにメソッド定義することで、 object の特異クラスにメソッド定義できることについて説明していきます。

まず基本的な話ですが、メソッドはクラスに保有されていきます。

例えばクラス内で def; end を用いて定義したメソッドは、そのクラスのインスタンスメソッドとして定義されます。

そしてこれがこの記事の本題なのですが、 class << object; end のスコープ内にメソッド定義すると、その object の特異クラスにメソッドが定義されます。

つまり以下であるということです。

class Child
  # Child クラスのインスタンスメソッドを定義
  def child_method
    puts 'This method ("child_method") is instance_method'
  end
end
child = Child.new
child2 = Child.new

# class << object; end の記法で、 child2 の特異クラスのインスタンスメソッドを定義
class << child2 
  def child2_method 
    puts 'This method ("child2_method") is singleton_method, which is only accessible from child2'
  end 
end 

child.child_method #=> This method ("child_method") is instance_method
# child からはアクセスできない
child.child2_method #=> undefined method `child2_method' for # (NoMethodError)

child2.child_method #=> This method ("child_method") is instance_method
# child2 からはアクセスできる
child2.child2_method #=> This method ("child2_method") is singleton_method, which is only accessible from child2

puts Child.instance_methods(false) #=> child_method
puts child2.singleton_class.instance_methods(false) #=> child2_method

 

先程、クラスもオブジェクトであるという事をお伝えしました。
さらにクラス定義における self は、例えば Child クラスの場合「Class クラスのインスタンスである Child オブジェクト自身」を指しています。

以上の2点を踏まえると、 class << object; end の記法を用いて、次のようにクラスメソッドを定義できます。

class Child
  def child_method
    puts 'This method ("child_method") is instance_method'
  end

  # object の部分に self を使用
  # class << Child でも同義であるが、一般的に self も用いた記述が好まれる
  class << self 
    def child_class_method
      puts 'This method ("child_class_method") is class_method'
    end 
  end 
end 
child = Child.new
 
child.child_method #=> This method ("child_method") is instance_method
Child.child_class_method #=> This method ("child_class_method") is class_method

 

このようにして、class << self; end を用いてクラスメソッドを定義することができました。

最後に

以上が class << self; end でクラスメソッドを定義できる理由の説明です。
拙い記事を最後まで読んでいただきありがとうございました。この記事が少しでも理解の助けになれば幸いです。

また、弊社では開発からサービスの運用まで、幅広くご支援させていただいております。詳しいサービス内容に関しては、当社ホームページの（新しいタブで開きます）をご参照ください。

 

補足：クラスメソッド定義には self.method; end という記述もある

1点補足として、クラスメソッド定義には self.method; end という記法もあります。
どちらの記法が良いかについては色んな意見があるようなので、気になる方は調べてみてください。

# この記事で説明した記法（「特異クラス形式」と呼ばれる）
class Child
  （省略）

  class << self
    def child_class_method
      （省略）
    end
  end
end

# self.method; end を用いた記法（「特異メソッド形式」と呼ばれる）
class Child
  （省略）

  def self.child_class_method
    （省略）
  end
end

 

スパイスファクトリー株式会社マーケターの小松です。

こちらの記事では、主にECサイトの立ち上げを検討されている方を対象に、Shopify 構築を開発会社に依頼するメリットついてお伝えしていきます。

Shopifyとは

Shopify（新しいタブで開きます） とは、ECサイトの構築・運営を行えるプラットフォームです。ECサイト構築プラットフォームでは世界シェアNo.1を誇り、1,700,000件を超えるビジネスで利用されています。また、昨今のコロナ禍によるECサイト需要の高まりで、ますます注目されているサービスです。
Shopifyについてさらに詳しく知りたい方は以下の記事も参考にしてみてください。

https://spice-factory.co.jp/shopify/about-shopify/

Shopifyが難しいと感じる理由

Shopify は多言語・多通貨に対応しているほか、比較的低コストで導入できるといったメリットがあります。しかし、一方で「自分で立ち上げ・運営するのは難しい」といった声も多く耳にします。難しいと感じる理由としてよく挙げられるのが、以下の通りです。

• 機能が多すぎて使いこなせない
• 日本語表記に対応していない部分が多い
• プログラミングの知識がなく、細かな調整ができない
• 立ち上げたはいいがグロースさせる方法がわからない

Shopify開発を依頼するメリット

Shopifyは個人で開発・運用をしている人もいるサービスですが、開発会社に依頼することもできます。
Shopifyの開発を依頼することで、前述のようなデメリットを解消することができます。ここではさらに、具体的な利用イメージをもとに開発会社ならではメリットについて解説します。

上流から下流までまるっとお任せできる

開発会社の高い技術力を活用し、上流から下流まで一括して依頼することができます。基幹システムとの連携や独自アプリの開発など、技術力が求められる、より高度な連携も可能になります。
ECサイトそのものの構築はもちろんですが、物流・配送面の管理なども相談可能です。
Shopifyとの連携サービスを展開している物流事業者もあり、こうした事業者との連携も含めたサポートをお任せできる点は大きなメリットといえるでしょう。
参考：https://service.openlogi.com/shopify-lp/（新しいタブで開きます）

カスタマイズ性が高く、要件に合わせた開発が可能

個人のニーズに合わせて、必要な箇所のみ開発を依頼することも可能です。多種多様なカスタマイズが可能な Shopify だからこそ、知識経験の豊富な開発会社に依頼することで、それぞれの要件を満たす最適なカスタマイズを選択し効果的な運用をすることができます。
どんなカスタマイズが可能なのか、イメージを膨らませたい方は以下の記事を参考にしてみてください。
Shopifyテーマ開発をチームで行う仕組みづくり（新しいタブで開きます）

開発後のブランド育成までサポート

開発会社にもよりますが、構築後の運用サポートまで依頼することができます。ただECサイトを立ち上げただけでは、ブランドを大きくしていくことはできません。
売上を伸ばしていくための集客や顧客フォローにはマーケティングの知識が必要ですし、ブランドとしての体験価値を高めるにはブランディングの視点も欠かせません。
しかし、そこには専門的な知識と実践での経験が必要になります。開発会社の技術目線での立ち上げ支援はもちろん、ECサイトの運用フェーズでのブランド育成サポートにより、その後のサービス拡大を踏まえた中長期的な成長を目指すことができます。
たとえば、以下の記事のようにSNSツールやMA（マーケティングオートメーション）ツールを連携させることで運用の幅を広げることがShopifyでは可能です。
ShopifyとInstagramの連携方法とおすすめ管理アプリ9選！（新しいタブで開きます）
戦略の幅が広がる！ShopifyとHubSpotの連携方法とメリット（新しいタブで開きます）

本当にやりたいことに専念する手段としての、開発委託

Shopify の開発を委託する上での、開発会社ならではのメリットについてお伝えしてきました。高い技術力をもった開発会社に開発を依頼することで、自分自身はブランドの育成に全力を注ぐことができるでしょう。
また、開発会社にShopify開発をお願いするならShopify Expertsの会社がおすすめです。
Shopify ExpertsとはShopify公認のEC制作パートナー企業のことを指します。
Shopifyが公式に認定している開発会社ですので、知見や開発事例も豊富に持っている会社が多く、運用面での相談にも乗ってもらいやすいと思います。
参考：日本のShopify ExpertsとShopify Plus Partnersの一覧（新しいタブで開きます）

スパイスファクトリーは、「開発力」に強みをもつ Shopify Experts として Shopify でのECサイト構築・運営をサポートしています。また、これまで培ってきたUIUXデザインのノウハウと実績をもとに、ブランドの世界観を理想的なインターフェイスに落とし込み、コミュニケーション設計を含めたブランド育成支援を通し貴社のブランドに貢献いたします。
ECサイト構築・運営をご検討中の方、ぜひご相談ください。

https://spice-factory.co.jp/contact/

 

スパイスファクトリー株式会社でエンジニアとして働いている平川です。
現在は主に TypeScript, React, PHP 等を用いてWebアプリやモバイルアプリの開発を担当しています。
弊社の詳しいサービスは（新しいタブで開きます）をご覧ください。

最近 Flutter（新しいタブで開きます） を数カ月間利用してモバイルアプリ開発を行う機会がありました。Flutterを扱うのは初めてでしたが、私のようなReact（新しいタブで開きます） 経験者にとって Flutter は習得しやすいと感じました。

その理由を考察してみたいと思います。

弊社スパイスファクトリーでは様々な開発において豊富な実績があります。

弊社の概要やサービスプラン、過去の導入実績などをまとめた資料をご用意しました。気になる方はこちらからダウンロードしてください。

Flutterとは

Flutter とは、近年注目を集めている Google 製クロスプラットフォームUI開発ツールキットです。
公式サイト（新しいタブで開きます）には下記のような記載があります。

Flutter is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, desktop, and embedded devices from a single codebase.

Google翻訳

Flutter は、単一のコードベースからモバイル、ウェブ、デスクトップ、組み込みデバイス向けにネイティブにコンパイルされた美しいアプリケーションを構築するためのGoogleのUIツールキットです。

コードを1つ書けば、AndroidとiOS、更にwebアプリもFlutterが作ってくれるという事なので、とても簡単そうです。

実際、Webアプリと全く同じ感覚でアプリを作る事が可能です。

$ flutter create myapp
$ cd myapp
$ flutter run

これだけでエミューレーター又はUSBで接続した物理端末でアプリが立ち上がります。（下の画像。2021年7月現在）

更にソースコードを編集した際にはホットリロードによって変更が即座に反映できるなど、Web開発に近い、良好な開発体験です。

もちろん実際には事前に Flutter 本体と最低でも「Android Studio」をインストールする必要がありますが、一度セットアップしてしまえば上記のように手軽に開発を始めることができます。未体験の方は公式ドキュメント（新しいタブで開きます）を参照して Android Studio と Flutter をインストールし、ひとまず試してみるのも良いでしょう。

ちなみに、Android StudioやXcodeはビルド時にSDKが必須であるだけで付属のIDE自体は必ずしも使用する必要はありません。
好みに応じて使い慣れたエディタ(但しLSP (Language Server Protocol)対応は必須)とFlutter CLIだけで快適に開発できるのもWebエンジニアとして持っている経験を大きく活用できる点で嬉しいところです。

Flutter習得をしてみて

個人的な感想になりますが、私は Flutter の習得は比較的スムーズに進めることができました。
理由は当時私が React をメインに開発していて、かつ Flutter のUIコードが React と似ていたことだと思っています。

このあとは、 Flutter と React が似ていると思ったポイントを考察していきたいと思います。

具体的には、以下の点について触れていきます。

• Flutter のUI表現構造が JSX と似ている。そもそも HTML とも似ている
• Dart と JavaScript (ES6以降) の文法が似ている
• 「状態管理」や「イベント・ドリブン」など重要な概念が共通している

FlutterとReactの類似点

先述した Flutter と React の類似点についてそれぞれ説明していきます。

1. UIの表現構造

まずは Flutter のコード構造がJSXが似ている点ですが、下記の Flutter コードを御覧ください。

Center(
  child: Column(
    mainAxisAlignment: MainAxisAlignment.center,
    children: [
      Text(
        'You have pushed the button this many times:',
      ),
      Text(
        '$_counter',
        style: Theme.of(context).textTheme.headline4,
      ),
    ],
  ),
);

React に慣れている方であれば Flutter を知らなくても、しばらく眺めていれば出力がどうなるか想像できるかもしれません。

上記のFlutterコードをJSXで書いてみると下記のようになります。
(<Center>, <Column> , <Text>等はどこか他の場所で定義してあるとします。)

<Center>
  <Column style="align-items: center">
    <Text>You have pushed the button this many times:</Text>
    <Text class="headline4">{counter}</Text>
  </Column>
</Center>

上記の Flutter とJSXを見比べてみると、記法に少し差があるだけで大枠での構造は同じだと思いませんか?
HTML では UI を階層構造として捉え、それを表現するのに要素を「入れ子」にしていますが、Flutter でもchildやchildrenという明示的なパラメータが必要なものの同様に要素の入れ子で表現しています。
スタイルなども HTML の属性で指定するのと同じ様に、Dart関数の引数に指定する形を取っています。

この構造が同じなので、例えば Flutter でWidget(~ ReactにおけるComponent)を作る際も React を記述するのと同じつもりで記述するだけで、概ね Flutter の流儀に沿ったものが書けてしまいます。

2. DartとJavaScript

Flutter はDart（新しいタブで開きます） という言語で書かれますが、この言語の文法は JavaScript (ES6)とよく似ています。
更に Dart には型付や型推論がありますが、記法は異なるものの TypeScript をマスターしていれば戸惑うことは少なくなります。

下記はDart言語の例です。

Stream computePi({int batch = 100000}) async* {
  var total = 0; // Inferred to be of type int
  var count = 0;
  while (true) {
    final points = generateRandom().take(batch);
    final inside = points.where((p) => p.isInsideUnitCircle);

    total += batch;
    count += inside.length;
    final ratio = count / total;

    yield ratio * 4;
  }
}

Allow function, Generator, var, async, await, 制御文, 配列やObject (Dartではmapと呼びます)、変数のスコープなどかなりの部分がJavaScriptと似ているため、細部を無視すれば概ねコードの意味を掴むことが可能です。
更に言うと TypeScript との文法上の差分を押さえていくだけでも、かなり記述力を高める事ができます。

Dart言語は Google が JavaScript の代替としてクライアントサイドのweb言語として開発しているものです。
そのためか、Dart の文法自体は JavaScript と似ており、更に TypeScript と同様に型安全であったり、開発時期が同時期だったこともあり TypeScript と文法上は似たものになっています。

TypeScript と Dart を両方利用していると感じますが、TypeScriptの型定義しやすさと型推論の強さはDartを凌駕しています。
ただし Google のサービスの一部は Angular を Dart で記述する AngularDart を利用しているとの情報（新しいタブで開きます）があるなど、web開発分野でもDartの動向から目が離せません。

3. 両者に共通する概念

React など Web UIの開発で重要な「コンポーネント」、「状態」、「イベント・ドリブン」などの概念はやはり Flutter でも重要です。
これらは慣れていないと結構難しい概念なので、多少なりとも似ているのは React 経験者にとって非常に嬉しいところです。

「状態」についてすこし具体的に考えてみます。React は「状態」をどの様な「見た目」で表現するか?、という考えを非常にはっきりさせる API を有しています。

少し分かりづらいと思うので、具体的なコードで考えます。

例えば下記のコードを見てみます。

const CountButton: React.FC = () => {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(prev => prev + 1)}>{count}</button>;
};

このコードは React 経験者ならすぐに理解できるでしょう。
それは勿論「JSXが読める」とか「hooks APIを知っている」からという理由もあるかと思います。
ただ、個人的にはそれ以上に React 流の状態と見た目の分離の仕方が身についているという点が大きいのではないかと考えています。

これをFlutterで書くと、概ね下記のようになります。

class _CountButtonState extends State {
  int _counter = 0;
  @override
  Widget build(BuildContext context) {
    return TextButton(
      child: Text('$_counter'),
      onPressed: () {
        setState(() {
          _counter++;
        });
      },
    );
  }
}

記法の差はあるものの、コードの意味や、setStateが必要な理由などは理解できると思います。
もし React など類似のフレームワークの開発経験が無ければ理解に時間を要することでしょう。

React経験者には「React Native」の方がいいのではないか?

ここまで Flutter の紹介をしてきましたが、React 使いが始める Android / iOSアプリ開発といえば、真っ先に思いつくものに React Native（新しいタブで開きます） があります。当然のことながら Flutter より更に学習コストは低くできます。
また React Native 上に構築されたフレームワーク Expo（新しいタブで開きます） を使えば、驚くべきことに Android Studio や Xcode をインストールせずに実デバイスで動作確認しながらアプリ開発をスタートできます。
Reduxなどの状態管理ライブラリもそのまま利用可能ですし、既存のwebアプリのコードを変更なしで流用したりもできるでしょう。
UIもJSX (TSX)とCSSで記述することが可能です。

以上のように React Native はとても魅力的ではありますが、それでも個人的には React Native に挑戦する前に Flutter も検討すべきだと思っています。
実は過去に私も React Native で開発を行ったことがありますが、今回の Flutter 習得と比較してみるとUI記述の学習コストには大きな差がないと感じました。
React Native はプラットフォームがブラウザからアプリに変わるので、HTMLタグが全てそのまま使えるわけではない点も学習コストの差を縮めています。
また設計思想の違いからか、画面遷移など含めモバイルアプリで「よくある」UIを実現するには Flutter の方が遥かに簡単な印象です。

Web開発者でもFlutterならアプリ開発にスムーズに入れる可能性が高い

React 開発経験者の私が、Flutte rでの開発業務に数ヶ月携わった経験を元に、Flutter と React との比較を書いてみました。
Web開発者でも Flutter ならアプリ開発にスムーズに入れる可能性があると感じていただければ幸いです。

当社では、ネイティブでのアプリ開発を極めたエンジニアと私のような Webエンジニアが共同で Flutter を使い開発を行う機会がありました。近年のアプリはWebバックエンドとの連携が必須です。Webエンジニアがアプリのコードベースに直接手を入れることで、Webネイティブの視点からアプリエンジニアが気づかなかった問題提起や解決を行うなど、相補的に協力しながら仕事を進めることができたと感じています。

当社では現在 React 、Flutter を重要なコア技術とみなして複数の案件の開発に採用しています。

弊社スパイスファクトリーは豊富な実績を持ち、これらのプロセスを効率的に進めるためのサポートを提供いたします。

詳細を知りたい方は、こちらからサービス紹介資料をダウンロードしてください。

最新テクノロジー、UIUX、アート、マーケティングなどあらゆる技術・メソッドを用いてクライアントのデジタルトランスフォーメーションを支援しているスパイスファクトリー株式会社です。
不確実性の高い世の中といわれる昨今、新しい価値を生みだすために新規事業に挑戦する企業も多いと思います。

一口に「新規事業」と言っても色々なアイデアが存在すると思いますが、DX（デジタルトランスフォーメーション）を意識するとスマホアプリやWEBサービスなど、何かしらシステム開発が必要なアイデアを考えている方が多いのではないでしょうか？そんな方にぜひ参考にしていただきたい、新たなアイデアを形にしていくのに最適な開発手法があります。それが「アジャイル開発」です。
本記事ではアジャイル開発の概要となぜアジャイル開発が新規事業立ち上げと相性が良いのかについてご説明いたします。
また弊社の詳しいサービス内容は（新しいタブで開きます）をご覧ください。

（新しいタブで開きます）

アジャイル開発とは

そもそも、アジャイル開発とは何なのかについて簡単に説明します。メリットやデメリットについてより詳しく知りたい方は以下の記事をご覧ください。
アジャイル開発とは？ – システム開発を発注する時に知っておきたい開発手法の話（新しいタブで開きます）

アジャイル開発の概要

アジャイル開発はプロダクトを開発する上での開発の進め方の一つです。
最大の特徴としては、最低限動くシステムをなるべく早く開発するということが挙げられます。
アジャイル開発では作りたいシステムを機能ごとに小さく分割し、その小さな機能単位に要件定義、設計、実装、テストといった工程を進め、リリースをしたら次の機能の開発に取り掛かる…という流れを繰り返していきます。
最低限必要な機能に絞れば、数か月程度で実際に動いて触ることのできるシステムを作ることが可能です。

アジャイル開発と比較されることの多い手法として、日本で古くから一般的な開発手法として知られるウォーターフォール型の開発というものがあります。
ウォーターフォール型開発は、システム全体の要件定義をする。終わったらシステム全体の設計、それが終わったら全体の実装…というように最終的にリリースしたい全ての機能をあらかじめ決めて一度に開発していきます。

ウォーターフォール型の開発では、プロダクトがすべて完成してリリースするまでに数か月から数年かかります。また、システム全体が完成しないと実際に動いているシステムに触ることはできません。

機能ごとに開発をしていくアジャイル開発とはこの点が大きな違いとなります。

アジャイル開発の特徴をまとめると

1. 必要性の高い機能から機能ごとに開発を繰り返す
2. 完成した機能は実際に触ることができるので、他の手法に比べると早い段階で動くシステムに触ることができる

ということになります。

新規事業でのシステム開発時のポイント

続いて、新規事業を成功させるためにシステム開発に求められるポイントについて説明します。

自分達のプロダクトが本当に必要とされているかを素早く判断する必要がある

新規事業を立ち上げる際、ターゲットとなる顧客の課題やニーズが不確かであることが想定されます。
そのため「アンケートでは感触が良かったけれど、いざプロダクトをリリースしてみたら顧客のニーズと違っていた」ということは新規事業ではよくあります。
開発に多大な時間とお金をかけてリリースしたものの、ニーズがズレていたために売上を確保することができなかった場合、損失が大きく事業継続が困難になる可能性もあります。これは新規事業を進める際の非常に大きなリスクです。

このリスクを小さくするためには、以下の3点が重要となります。

• • 新しいプロダクトをリリースするまでの期間は短くする
  • 可能な限り少ないコストで開発を行う
  • 自分達のプロダクトが必要とされているのかを素早く判断する

つまり、リリースまでの期間を短くコストを抑えるために、必要最小限の機能だけを開発をして事業を小さく始めるのです。この最小限の機能を搭載したプロダクトを MVP（Minimum Viable Product）（新しいタブで開きます）と呼ぶ場合もあります。
MVP を開発、リリースした後に想定していた顧客のニーズと実際のニーズに差異があった場合、それに応じて素早く機能を修正・追加していきます。

変化に柔軟に対応できる開発をする必要がある

日経コンピュータが行った調査によると、開発プロジェクトで当初の予算を超過してしまった理由の筆頭として、「追加の開発作業が発生してしまったこと」、スケジュールを守れなかった理由の筆頭として、「システムの相次ぐ仕様変更」が挙げられました。このように、開発を進めていくと当初の想定とは異なる作業がしばしば発生します。
参考：日経 xTECH／日経コンピュータ 「システム開発はなぜ予算オーバーに陥るのか」（新しいタブで開きます）

顧客のニーズが不確定のまま進む新規事業プロジェクトであれば、なおさら方針転換や軌道修正が生じるケースは多いでしょう。そのような場合には都度、要件定義や設計に立ち戻りそれらを修正する必要があります。

新規事業プロジェクトにおいては、「修正が起きないように入念に準備する」よりも「仮説のずれや方針転換はどこかで絶対に起きるもの」と考え、当初決定した要件や設計に変更があった場合、ある程度柔軟に対応できる体制であることが求められます。

新規事業とアジャイル開発の相性が良い理由

アジャイル開発は、新規事業開発時のポイントで挙げた「自分達のプロダクトが本当に必要とされているかを素早く判断する必要がある」や「変化に柔軟に対応できる開発をする必要がある」といった要素を満たすことができる、新規事業と相性が良い開発手法です。以下でその理由を見ていきましょう。

早い段階で動くシステムができるので検証などがしやすい

新規事業は「やってみないとわからない」要素が大きいプロジェクトです。そのためプロダクトを素早くリリースして顧客の反応を見ることが求められます。

前述したウォーターフォール型の開発ではすべての機能を開発しきらないとリリースできませんが、アジャイル開発では機能をそぎ落とし、最短で最初のリリースを目指すため、検証に必要なコア機能だけを先に作って比較的に素早くリリースすることができます。
完全な状態でなくとも、プロジェクトの早い段階で目指している方向性がユーザーの求めているものとずれていないかテスト・検証することが可能です。

プロジェクトの方向転換にも柔軟に対応できる

「ユーザーテストやインタビューを行ってみたら仮説と違った」「当初想定していなかった新しいニーズが見つかった」
そのような場合でも、アジャイル開発であれば小さな単位で開発を進めているため、状況の変化があった時にもそれに合わせてシステムの軌道修正を行いやすいというメリットがあります。
実際のユーザーの反応を伺いながら柔軟に方針を決めていくことができるのは、新規事業の担当者にとっても嬉しい点ではないでしょうか。

必要な機能を必要になった時に開発する

新規事業では、プロジェクトの開始当初から必要なシステムの完成形が精緻に想像できていることはかなり少ないと思います。
前述のウォーターフォール型開発は最初に実施する要件定義で必要な機能をすべて決めてから開発を進める手法であるため、要件や設計に修正が発生した場合には手戻りが発生し、多大な時間がかかってしまいます。

アジャイル開発の場合、新たな機能や修正が必要だと判断された時点で開発を行なっていきます。
前項で述べたように、プロジェクトの最中の方針転換にも対応しやすいですし、そもそもの新規事業の進め方としてまずは必要最小限のプロダクトを作って事業を小さく始め、仮説の検証を繰り返しながら必要に応じて機能を追加して一歩ずつグロースさせていくことができます。

新規事業×アジャイル開発を成功に導くカギ

ここまで、新規事業を進める際のアジャイル開発のメリットをお伝えしてきました。とはいえアジャイル開発さえ採用すればすべて解決！というわけではなく、プロジェクトを成功させるために注意するべきポイントがあります。この章ではそのポイントを解説します。

必要な機能の精査

アジャイル開発では、必要な機能を短いスパンで開発していくことが大きな強みです。
この強みを活かすためには、プロジェクト初期から一貫して開発したい機能の優先順位付けを迅速かつ的確に行なっていくことが重要です。
自分たちの事業の持っている仮説を検証するのに最低限必要な機能は何なのか、しっかりと見極めましょう。
開発する機能の絞り込みができずに、一度に色んな機能を追加しようとしてしまうと素早いリリースが行えなくなり、ユーザーのニーズとのギャップが広がり、アジャイル開発のメリットを失ってしまうことになります。

発注者と開発者の密なコミュニケーション

アジャイル開発では、リリースするまでのスパンも短いため、発注者と開発者の間でタイムリーなコミュニケーションが求められます。開発会社側はもちろんですが、依頼する側の協力もプロジェクトの成功には非常に重要な要素です。
このことを双方が理解してプロジェクトを進めていかないと、スケジュールの遅延や出来上がったプロダクトが発注者の想定と異なるなどといった問題が発生します。
発注者側も、通常業務と並行しながら開発者とコミュニケーションを取っていくために、十分な時間の確保が必要でしょう。

システム開発が必要な新規事業なら、アジャイル開発を選択肢に

今回は新規事業の開発とアジャイル開発の関係性についてお伝えしました。
これから、新規事業のシステム開発を行う方にとって少しでも参考になりましたら幸いです。