スクラッチ開発とは？メリット・デメリットとパッケージ開発との選び方を解説！

システム開発の構築方法の一つ、スクラッチ開発についてある程度知っていても、自社のプロジェクトに最適な方法なのか、判断に迷っている企業担当者の方もいるでしょう。本記事では、スクラッチ開発とはどんな手法なのか、概要と特徴を解説し、パッケージ開発との違い、開発の進め方、開発手法を選ぶポイントなどについても解説します。

ハイブリッドテクノロジーズの
開発サービスはこちら

スクラッチ開発とは？

スクラッチ開発とは、ゼロからシステムを作り出す手法です。「スクラッチ」という言葉には「最初から」という意味があるように、既存のパッケージソフトなどを使わずに、文字どおり一からシステムを作り上げることから、このように呼ばれます。

完全なオーダーメイドとなるため、機能はもちろん、管理画面の構成、デザインまで要望を反映できます。既存システムにはない、独自性の高い機能を実装する場合に力を発揮する開発手法です。有名な例として、JRの座席件予約システム「MARS（マルス）」の初期のようなシステムが挙げられます。

ただし、スクラッチ開発は一から作り上げていくわけですから、コストも時間もかかってしまうことがデメリットです。そのため、費用やスピード感を重視する企業にとっては適さない方法といえます。

スクラッチ開発の著作権の帰属先について

著作物を法律で保護するために、成果物を作成した著作者に与えられる権利が著作権です。システム開発では、プログラムも著作物になります。

著作権は、成果物を作成した人、または組織に帰属する権利ですので、プログラムを作成した技術者、あるいは開発会社が著作権を持つことになるわけです。つまり、システム開発会社がシステムをゼロから作った場合、発注側が開発の費用を負担したといっても、著作権が発注者に譲渡されるのではありません。著作権は発注者側の支払いの有無とは関係ないのです。

楽曲の著作権の帰属先がアーティストであることと同じです。CDの製作費用をレコード会社が負担しても、レコード会社に著作権は譲渡されません。

では、発注者側には何の権利もないのかと思われるかと思いますが、著作権法の第61条により、その全部または一部の譲渡が可能とされています。ただし使用の許諾を著作者から受ける必要があります。つまり合意のうえで契約を締結し、プログラムの著作権を第三者（例えば発注者）へ譲渡することもできるわけです。著作権を譲渡してもらうには、契約書に譲渡の規定を明記する必要があるため、契約時の取り決めがポイントになります。

著作権のトラブルは裁判にまで発展することがあります。それは、プログラムのソースコードで利益が大きく動くからです。著作権に関する知識は、技術者自身を守ることにもつながります。著作権について後に揉めないためにも、著作権の帰属先がどこなのかを契約書できちんと明記することが重要です。

パッケージ開発との違い

パッケージ開発もよく耳にする開発手法ですが、スクラッチ開発との違いを確認しておきましょう。以下の表にまとめましたので参照してください。

スクラッチ開発は特殊な業務フローや手順のシステム化が可能なため、新規事業やサービスのシステム開発に向いているといえます。ただし、コストが高くつく傾向があることと、開発期間が長期化する点を考慮する必要があります。スクラッチ開発を行うには、プロジェクトの予算と納期にある程度余裕があることが条件といえるでしょう。

一方、予算に制限があり、納期もタイトなプロジェクトの場合は、パッケージ開発が向いています。元になるシステムがあるため、開発時間が短く済み、コストも安価に抑えられる点はメリットですが、既存のシステムから大幅に外れたものを作ることはできません。

スクラッチ開発の手順

要件定義

要件定義は、システムで何を実現したいのか、システムに必要な機能や技術などの要件を明らかにします。要件定義が曖昧であると、開発の意図が正しく伝わらず、予想以上に時間がかかる可能性があります。ユーザーがほとんど使わないような機能が散見されるなど、最終的に希望していたものとかけ離れたものになりかねません。機能数過多になり、無駄な開発費用が発生するリスクもあります。要件定義はプロジェクトの成否に関わる工程です。開発の意図をしっかりと固め、開発会社と綿密に打ち合わせを行うことが重要です。

基本設計

基本設計とは、要件定義書を基に搭載する機能を決める工程で、要件定義とともに重要な部分です。基本設計では発注者と開発者とで意見のすり合わせを行うため、開発が始まる前に発注側が関われる最後の工程となります。そのため、両者間の認識のズレをゼロにしておく必要があります。

基本設計で行う作業は、機能の洗い出し、データの整理、画面のレイアウトなどです。発注者は開発会社が作成した基本設計書に対してフィードバックすることが大切です。完成イメージを描き、開発イメージ像を伝え、開発会社とのすり合わせをしっかりと行いましょう。

詳細設計

詳細設計とは、DD（Detail Design）という略称で呼ばれている、プログラマーへの設計図を作成する指示書です。基本設計で決定した機能を実装するための開発工程であり、発注側に開示されることはほぼありません。そのため、内容について詳しく理解する必要はありませんが、基本設計のあとにある作業として覚えておきましょう。

開発

詳細設計書を基にプログラミングを行い、実装していきます。プログラミングは、モジュール単位（機能単位）で進め、各モジュールを一つに結合してシステムを完成させます。プログラミングは、さまざまな言語にもとづいて記述（コーディング）しますが、発注者がプログラミング言語の特徴について詳細に知っておく必要はありません。しかし、多少でも言語の知識があると開発会社とコミュニケーションしやすい場合もあります。

テスト公開

プログラミングが終わると、開発したシステムが実際に動くかテストを行います。テストは以下の4段階に分けて実施します。

①単体テスト：機能ごとにテスト
②結合テスト：他の機能と連結させ、機能単位でテスト
③総合テスト：システム全体をテスト
④受入れテスト（ユーザーテスト）：発注者側は完成したシステムが要件を満たしているか、納品前に確認

テスト段階でバグが見つかった場合は、1つ前の工程に戻り修正して再度テストを行います。設計段階まで戻らなければならないケースもあります。

本番公開

テストで動作を検証して品質に問題がなければ、リリース（公開）となります。ビジネス戦略として、すべての機能を一度に公開するのではなく、段階的に公開する場合もあります。

また、導入時点で開発会社側が初期設定を行う場合が多く、その際には操作マニュアルの作成や、操作方法の説明会を実施します。旧システムを活用する場合はシステム移行が必要です。

メンテナンス

システム開発は公開したら終わりではなく、リリース後も継続的に安定した状態で稼働できるように、運用や保守が必要です。実際にリリース後に何らかのトラブルが発生するケースが多いため、メンテナンスも依頼しておくのが無難といえます。開発に携わった会社の方が、プログラミング設計やセキュリティ対策の状態などについて詳しく把握しているからです。そのため開発会社を選ぶときには、メンテナンスまで対応可能な会社に依頼するとよいでしょう。

関連リンク：アプリ開発の手順とは？手法別の注意点も解説！

スクラッチ開発のメリット

独自性の高いシステムを開発できる

スクラッチ開発は、既存のシステムを使わず、一から作り上げるので、自由度の高い、独自性のあるシステム開発が可能です。競合他社との差別化を図る意味でも、他社がまだ行っていないような斬新な事業を立ち上げる際に最適の方法でしょう。また、自社の業務フローにマッチしたものを作れるため、理想のシステムを構築したい場合にも利点があります。

長期にわたり利用できるシステムを開発できる

パッケージ開発の場合、ソフトのサポート終了に伴い、システムが使用できなくなる場合があることが懸念されます。一方、スクラッチ開発で構築されたシステムは、企業の倒産やサポート打ち切りなどの理由で終了になるリスクはありません。システム開発部門がある場合や、システム開発会社の協力が得られる体制があれば、迅速にシステム改修を行うことができるため、結果的に長期間システムを使い続けることが可能です。

最小限の要件に絞って開発できる

パッケージ開発の場合、需要度の高い機能を優先して搭載しているため、自社にとって不要な機能も含まれています。しかし、スクラッチ開発の場合は要件定義の段階で必要な機能のみを取り入れています。自由度が高いので、自社が必要とする機能のみに絞ったシステムを開発できることは大きなメリットです。スクラッチ開発で一から作り上げた方が、利便性の高い、使いやすいシステムを構築できます。

拡張性を持って開発できる

スクラッチ開発では、開発の方向性を柔軟に決められるため、将来的な拡張性を見据えて開発を進められるという点もメリットです。例えば、新規事業やサービスなどを始める際には、必要最小限の機能でスタートし、ユーザーの反応に応じて機能を拡張していくことができます。これは開発当初の方針が問題ですが、最初にリリースするときはスモールスタートし、その後のユーザー数の増加などを見ながら徐々に機能を拡張していくことを前提とする開発が可能です。

スクラッチ開発のデメリット

開発費用がかかりやすい

スクラッチ開発は、多くの工数がかかり、費用が高額になることが大きなデメリットです。予算を自由に使えるのであれば良いですが、通常は限られた予算内でシステムを構築することが求められているため、コストを検討する段階で除外されるケースがしばしばあるようです。

特に、難易度の高いシステムの開発では、人件費も高くなるため、納品時の初期費用は、高額にのぼり、数千万円以上かかるケースもあります。会社の根幹となるような、何十年も使用する基幹システムの開発であれば、費用をかけても価値はあるでしょう。しかし、大企業でもないと、システム開発に多額の予算を投じるケースは多くはありません。

開発期間が長くなりやすい

スクラッチ開発では、利用する既存のシステムはなく、ゼロの状態から設計や開発をスタートするため時間を要します。通常は半年から数年となるため、スクラッチで構築する場合は、開発期間に猶予を持たせて依頼しましょう。

また、開発期間が長期にわたると、その間にビジネス環境が変わり、業務プロセスが変化する可能性があります。そうなると当初の要件定義からずれてしまうというリスクが懸念されます。スピード感が求められている現代、特にトレンドが移り変わりやすい分野でのシステム開発では、採用しにくい開発手法です。

開発会社とのコミュニケーションを密に取る必要がある

スクラッチ開発は、自由度が高い分、開発会社にこちらの要望を細かく伝えなければ希望のアプリにはならないため、開発会社との密なコミュニケーションが必須です。どのようなシステムがどのような部分に必要なのかを綿密に打ち合わせ、要件定義、設計、開発という流れで進めていきますが、開発過程では両者間の伝達不足が起きやすいものです。
コミュニケーション不足がそのまま続くと、結果的に開発したかったものとはかけ離れたシステムになるリスクがあります。コミュニケーションを密に取ることは大切ですが、開発側だけでなく、発注側の担当者にも負担がかかることはデメリットです。

スクラッチ開発に向いている開発システム

パッケージでは実現できない特殊な手順のシステム

スクラッチ開発は独自性の高いシステム開発に向いています。ただし、自社で独自性が高いと思っていても、パッケージが存在する場合もあるため、まずパッケージ製品をリサーチすることをおすすめします。調べた結果、パッケージとして売られていない、または似ているパッケージはあるけれど重要な機能が搭載されていない場合は、スクラッチ開発をおすすめします。

顧客向けの店舗アプリなどは、パッケージが販売されていますが、機能やデザインが似ているものが多いため、差別化を図るのは難しいでしょう。スクラッチ開発なら独自の機能を実装できます。

セキュリティなどの特殊な要件を満たすシステム

スクラッチ開発は、先述した通り、要件定義、設計、開発、テストという流れで進みます。最初の要件定義では、システム開発の目的とゴールを明確にし、現状の課題を洗い出し、必要な機能要件と非機能要件をまとめます。この非機能要件とは、システムの稼働率、性能・拡張性、コンプライアンスやセキュリティなどの機能以外にシステムに求める特殊な要件のことです。非機能要件はシステム導入後に安定的な運用を続けるために欠かせません。スクラッチ開発はこのような要件を満たすシステムに向いています。

新規サービスで設計するシステム

ゼロから開発するスクラッチ開発は、これまでになかったような新しい事業やサービスのシステムを開発するのに向いています。自由度が高く、将来的な拡張性も確保しやすいため、新規事業やサービスのシステム開発に有利に働きます。スモールスタートで始め、ユーザーの反応を見ながら徐々に機能を拡張していくことなどが可能です。

パッケージ開発のメリット

開発費用をおさえられる

既存システムを利用するパッケージは、費用をおさえられることがメリットです。すべての機能を一から開発していくスクラッチと異なり、自社の業務へのマッチ度が高いパッケージがあれば、必要な機能だけをカスタマイズすればよいので、コストを最小化できます。また、余った予算をPR費用などに有効活用することもできるでしょう。システム開発に大きな予算を確保できない場合、パッケージ開発がおすすめです。

開発期間を短くおさえやすい

パッケージ開発は、開発期間が短いこともメリットです。スクラッチ開発の場合は何から何まで構築しなければならないため、どうしても開発時間がかかってきます。既存システムを使うパッケージ開発なら、スピード感のある構築が可能です。パッケージ開発の場合でも、カスタマイズすると時間はそれなりにかかりますが、スクラッチ開発よりは開発期間を短縮することができます。時間をあまりかけずにシステム構築をしたい方は、パッケージ開発を検討されると良いでしょう。

パッケージ開発のデメリット

業務フローをパッケージに合わせる必要がある

パッケージ開発はカスタマイズも可能ですが、既製品がベースとなるため限界があります。そのため自社の業務フローを運用システムに合わせて変更して適合させることが必要です。業務フローの変更にあたっては、自社の社員がシステムに慣れるのに時間がかかったり、生産性が一時的に落ちたり、などの弊害が生じる可能性もあるでしょう。柔軟に対応できるスクラッチ開発と比べると、この点はパッケージ開発のデメリットといえます。

追加機能を実装する際に高額になる可能性がある

パッケージ開発では、完全オリジナルの開発は不可能です。そのため、カスタマイズの難易度によっては、追加機能を実装する際に予想外に費用がかかる可能性があります。求めるニーズによっては、スクラッチ開発とあまり差がなかったり、むしろパッケージ開発の方がコスト高くなったりするケースも少なくありません。システムの細部までこだわりたいという場合には、デメリットとなるでしょう。

パッケージ開発に向いている開発システム

型化することが可能なシステム

パッケージ開発は、すでに開発されたテンプレートのようなものを活かして開発を行う手法のため、自社の機能要件にかなうパッケージが見つかれば有効です。ただし、デザインなどがすでに決まっているため、システムの型に業務フローを合わせる必要があります。とはいえ、早く導入でき、コストもおさえられるというメリットもあるため、自社の課題解決にマッチするパッケージ開発が明確なプロジェクトには向いています。

開発手法を選ぶポイント

システムを開発する目的・ゴールを整理する

まずシステム開発を検討している自社業務を見直すことから始めます。開発手法は、開発する目的・ゴールを達成するために適切な方法であることが重要です。そこで第一にやるべきことは、自社が抱えている業務の課題は何であるかを見直して、システム開発の目的とゴールを整理して明確にすることです。

具体的には、業務フローの現状と求める理想の状況から、そのギャップを埋めるために適した方法を導き出していきます。新規の事業やサービスであれば、競合他社の状況を把握し、自社の強みを明確にして差別化を図ります。また、課題解決にシステム化が最善の方法なのかも含めて、できるだけ多くの選択肢を検討してみることが重要です。

課題を整理したら、システム開発の目的とゴールを設定しましょう。開発会社の得意分野はそれぞれ異なり、システム開発の目的で依頼する開発会社が変わってきます。そのため、目的とゴールを曖昧にしておくと、見当外れの会社に依頼してしまう可能性があるので注意が必要です。

システムの要件を満たすパッケージがあるかを確認する

目的とゴールを設定したら、つぎに必要な機能を整理します。求める機能要件が明確になったら、その機能要件を含むパッケージ製品がないか調べてみましょう。機能要件とは、業務フローの現状とゴールとのギャップを埋める機能、もしくは他社のサービスと差別化を図るために求められる機能のことです。

機能要件を満たすパッケージが見つかれば、あえてスクラッチ開発をする必要がありません。既存のパッケージ製品でも優秀なものがあり、パッケージ開発で対応可能であれば、費用と納期の面から考えても、パッケージ開発がおすすめです。独自性が高いと思っていた自社の業務フローの開発が、実はパッケージ開発で実現できる場合もあります。求める要件をクリアできるパッケージがない場合は、スクラッチ開発を検討しましょう。

開発する際に優先したいポイントを決める

開発手法を選択する際の決め手のポイントの一つが優先順位です。①業務への適合性、②開発コスト、③納期という3つの項目を軸に決めていきましょう。

限られた予算内でできるだけ早く開発したいということであれば、既存のパッケージを利用することがおすすめです。ただし、パッケージ開発の場合はパッケージのシステムに自社の業務フローを合わせる必要があります。業務への適合性を優先させるならスクラッチ開発になりますが、開発コストは高くなり、期間も長期にわたることを想定しなければなりません。システム開発を急いでいる場合、スクラッチ開発は不向きといえます。

基幹システムはパッケージ製品で十分対応できるケースも多いですが、システムに独自性を求めるのであれば、開発期間に折り合いをつけざるをえないかもしれません。

システム開発ですべての要望を実現できることがベストですが、基本的にすべての要件を満たすことは難しいということを認識しておく必要があります。すべての要望が実現できないからこそ、プロジェクトを開始する段階で、プロジェクトのゴールを明確にして、開発で優先したい項目の優先順位を決めておくことが大切です。どちらの開発手法を取るかは、自社の実態を検討し、どの項目を優先させるかを決めて判断しましょう。

ハイブリッドテクノロジーズの提供サービス

ハイブリッドテクノロジーズでは、ビジネスデザイン、UIUXデザイン、設計、実装、テスト、リリース、運用、保守まで一気通貫してサービスを提供しております。500名以上の経験豊富なエンジニアにより、迅速かつ高品質なシステム開発が可能です。 アジャイル開発、ウォーターウォール開発、ハイブリッド開発と言った様々な開発手法に対応しており、契約形態に関しましてもラボ型契約と受託型契約の2つから選択いただけます。お客様の状況や開発内容に応じて、開発手法と契約形態を柔軟にご指定いただけますが、それぞれの開発手法、契約形態の特徴の親和性から、アジャイル開発ではラボ型契約が、ウォーターウォール開発とハイブリッド開発では受託型契約を選択されるクライアント様が多数を占めます。

ラボ型開発について： ラボ型開発 サービス

受託型開発について： 受託開発 サービス

ハイブリッドテクノロジーズが選ばれる理由

弊社ではクライアント企業様及びエンドユーザー様の声を聞き、UIUXを意識したビジネスデザインを行なっております。 テーマを決めて分析し、仮説を立ててビジネスデザインを行い、プロトタイピング、検証、フィードバックを受け、再度分析から始める。 この一連の流れを、アジャイルスクラム開発に精通した500名以上のエンジニアが高速で回していくことにより、最速でより良いものを実現していきます。 ハイブリッドテクノロジーズには市場の声を現実にするための仕組みとメンバーが揃っています。

システム開発の成功事例

システム開発での成功事例をご紹介します。

OfferGate（株式会社リフト）

サービス内容

⼈材紹介会社、派遣会社を通さずに、⾃社の条件や要件に合った外国⼈材求職者へ直接アプローチできる外国⼈材の採⽤マッチングプラットフォーム

サービス上の課題/目指したいサービス

課題
外国⼈材の採⽤には、求⼈ポータル形式や⼈材紹介会社を通して⾏われるケースが多く、互いにコミュニケーションが困難なため、外国⼈求職者と企業側のミスマッチが起こるケースがあること

目指したいサービス
今回構築する採⽤マッチングプラットフォームを介することで、外国⼈求職者と直接コミュニケーションを取れようになり、ミスマッチを減らして企業の外国⼈材受け⼊れを促進すること

当社を選択していただいた理由

サービス対象が外国人であるため、当社のベトナム人を織り交ぜた開発体制はユーザー視点を取り入れることが可能になるという点と開発体制をリフト様では内製で保持しておらずサービス開発の体制が組めないため、サービス開発知見の多い当社をパートナーに選択していただいた。

当社ご提案内容

ターゲット層であるベトナム⼈視点のUI/UX設計から保守改修までのワンストップでのハイブリッド型サービスの提供

補助金クラウド(株式会社Stayway) サービスURL：https://www.hojyokincloud.jp/

サービス内容

補助金活用を検討する企業が、専門家に採択可能性や申請できる補助金の種別などの相談をすることができるWEBプラットフォーム

サービス上の課題/目指したいサービス

課題
コロナ発生以降、既存事業の立て直し、新規事業の創出が重要になった世の中に対して、行政が支援している補助金活用のニーズが増加している。 エンドユーザー側は多くの企業に行政書士などの専門家が不在のため各企業のニーズが満たされる補助金の種類や可能性が相談できる場面がなく、一から探すのもかなりの工数がかかっている状態が発生している。 金融機関/士業/事業会社おいても、補助金活用ニーズのある顧客との商談を円滑に進めるのが難しいという課題も存在している。

目指したいサービス
今回提供する補助金クラウドにより、エンドユーザー、士業事業経営をしている企業において以下の価値を提供が可能に。 エンドユーザーは、気軽にどの補助金が活用できるか、支援してくれる士業者とのマッチング、補助金採択の可能性を上げる申請相談が可能になります。 金融機関/士業/事業会社は、有効顧客の発掘、最新の補助金情報の入手、申請サポートによる採択率の増加が可能になり、売上増加が見込めます。

クライアント課題/要望

・新規事業の立ち上げ体制のリソースが不足
・UI/UX、システムの要件定義などの上流工程から体制構築したい
・自社の開発チームと組み合わせながら、擬似内製チームを構築したい
・事業状況に応じて柔軟にリソースを調整したい

当社ご提案内容

日本人によるUI/UXデザイナーの設計から運用保守まで一気通貫で対応できるハイブリッド型サービス ストックサービス

大手物流会社

サービス内容

窓口相談を事前に予約できるWebアプリ
窓口での相談日時を利用者が事前に予約できるようにし、企業と顧客双方にとって利便性を向上するWebアプリの開発案件です。

サービス上の課題/目指したいサービス

課題
利用者からの問い合わせは、常に窓口で対応している背景があり、
窓口で順に受け付けていたが、待ち時間が長く、顧客から不満の声が上がっていた。

目指したいサービス
・顧客の利便性（満足度）を向上すること。
・システム導入の周知により金融相談業務の認知度を向上させること
・システム導入による効率的な要員配置を目的として、顧客がWeb 上で事前に金融商品に関する相談日時を予約できるシステムを新たに構築すること

クライアントの課題/要望

・社内で開発体制を保持していないこと
・Salesforceを業務の基幹システムとして利用されているため、Saleforceでの機能開発が必須
・金額をミニマムに抑えながら安定的な運用を実現したい

当社を選択していただいた理由

・日本国内での開発より大きな価格メリットがあったこと

当社ご提案内容

受託型開発（フロー）にて提案
1.Salesforceを活用し、ミニマムコストでスピード感を持った機能開発

Salesforceを活用することで0からインフラを構築せずに素早く開発環境を作成することが出来ます。Salesforceの標準機能を基に必要な機能をカスタマイズして開発することで、スピーディな開発〜実装を可能としました。

2.プログラム実装前にプロトタイプ作成し、スピードを保ちつつ認識ギャップを防止

プログラム実装前にプロトタイプを作成することで、リリースというゴールまでスピード感を保ち、的確にコミュニケーションをおこないながら、認識ずれが生じないよう努めました。

3.Salesforce準拠のセキュリティ基準を担保

開発と合わせ、Salesforce準拠のテストコードを作成し、テストを実施することで、リリース後の不具合が発生しにくく、運用保守コストも抑えることができます。またすでにクライアント様が使用されているSalesforceの機能拡張のため、セキュリティー面は今までと同様のものが担保されます。安心感を持ってシステムをご使用いただき、クライアント様、エンドユーザー様双方からご好評いただいています。

まぐまぐ！リーダーアプリ (株式会社まぐまぐ)    https://www.mag2.com/app/reader/

サービス内容

まぐまぐ!で登録したメルマガコンテンツとまぐまぐ社が運営するメディアを手軽かつシームレスに閲覧できるスマートフォンアプリ「まぐまぐリーダー」

サービス上の課題/目指したいサービス

課題
メルマガはメールのみ、メディアもそれぞれ独自のWebを持っているためユーザービリティが良くない点

目指したいサービス
まぐまぐ!で登録したメルマガコンテンツとまぐまぐ社が提供する4つのニュースメディアを横断して手軽かつシームレスに閲覧できるサービス

クライアントの課題/要望

・新規アプリ開発リソースの不足

当社を選択していただいた理由

内製での開発リソースを保持されていないことと、当社の幅広いリソースとスピード感を持った開発体制が、まぐまぐ様の開発ニーズに合致したため、当社を選ばれました。

当社ご提案内容

ラボ型（ストック）開発＋保守にて提案
1.メルマガやニュースメディアといった多様なユースケースに、細やかに対応する開発体制

メールマガジン配信プラットフォーム事業の理解と学習から始まり、要件定義・設計・開発までをアジャイルスクラム開発で担当し、1週間ごとにクライアント様と成果物のレビュー会を行うことで、フィードバックを早いサイクルで受けることで、ユーザーの期待を超える価値体験を追求いたしました。 記事を読むという観点ではニュースサイトなどのメディアに分類されるサービスではありますが、既存の媒体がメールであるためにユースケースには多様性がありました。

2.毎日読む情報収集アプリとしてのファインダビリティとユーザービリティを考慮したUX・UI設計

メールアプリで閲覧するものだったメルマガをスマートフォンアプリで軽快に閲覧できる機能と、まぐまぐ社が提供する4つのニュースメディアを横断して閲覧できる機能を両立しつつ、スムーズに情報収集を行えるUX・UI設計を行いました。メインペルソナである多忙なサラリーマンの方の情報収集アプリとして、短時間での閲覧でも読みやすい視認性や可読性を重視した白基調の配色とタイポグラフィの設定を行い、ボタン類のアクション要素は見落とされない配色設計や、押しやすいサイズ設計、リアルタイムデータベースを使用した同期的な処理、まとめ読みや読み返しが快適にできるようにローカルデータベースを使用したオフラインファーストな設計をすることで既存サービスのユーザー体験をスマートフォンアプリでも損なわないように配慮しました。

まとめ

スクラッチ開発は、既存のシステムを利用しないで、一からすべてのシステムを作り上げていく方法です。独自性のあるシステム作りが実現できますが、開発にかかる費用と時間が気になるところです。既存のシステムやパッケージを利用するパッケージ開発であれば、コストをおさえられ、時間も短縮できますが、オリジナリティにこだわったシステムづくりは難しくなります。

どちらの開発手法にもメリット・デメリットが存在するため、企業の開発担当者の方にとっては悩みどころかもしれません。本記事をぜひ参考にして、自社が開発したいシステムにどちらの手法が適しているのかをよく検討してから、システム開発をスタートしてください。