1
/
5

アシアルの中の人が技術と想いのたけをつづるブログ。開発会社に案件・見積もりを依頼する際に気を付けるとよいこと

こんにちは、アシアルの鴨田です。
今回はアシアルを含む開発会社へ開発をご依頼される際に、気に留めておいていただくと、スムーズに案件が進むと思われる事柄について、ご紹介いたします。
弊社の営業担当である海原との共作となります。

はじめに

アシアルではお客様が抱える経営や業務における課題のうち、ITの力を駆使して解決できる課題について、お客様と一つのチームを構成して検討させて頂くという取り組みをしております。
とりわけスマートフォンやタブレットにてアプリを提供することによる業務効率向上による省力化、また価値の最大化を見つけ出す役割を担います。

一般には、経営方針や現場の課題整理までを行う工程を経て、具体的なアプリ像が明らかになってきます。反対に、こういうアプリがあれば価値提供出来るというところまで考えられるお客様からのご相談も非常に多くなっています。これは他社の事例や実績をベースに発想されたり、日々のプライベートなスマホアプリ利用から、自らの業務課題解決に結びつけて構想されることが一般的な流れだと考えます。しかし、業務系アプリについては実績として公表しにくい事例が殆どであるためにナレッジが共有されにくい状況でもあります。私たちは構想をより具体化するためにご助力させて頂くことも職務に含みますが、いわゆる要件定義や設計といった工程にかかるエンジニアの価値は高価であるため、お客様自身による構想の具体化は、実現に向けての最短距離であると考えます。

そこで今日は、私たちが依頼を受けるときに事前に整理されていると非常にスムーズに開発まで着手できる内容について整理して紹介します。アプリ開発を依頼する側に限らず、これからアプリ開発分野に拡大していこうと考えている開発企業の営業・企画担当の方々にも参考にして頂けると幸いです。

背景と目的を整理して、誰にでも共感を得られるようにする

なぜこのアプリが必要で、どのような課題を解決するか、そしてその課題が解決された先に、アプリを利用している人々が笑顔である想像をします。

この想像を文章や図にして、開発する全ての人に共有して共感を得られるとなお良いです。開発企業や開発者は常に、自分が開発しているものが世の中のどのようなことに貢献しているかを芯から理解しながらしなければ本当に良いものができません。

プロジェクトに携わるメンバー全員が、そのアプリやシステムが社会にどのように貢献するかを理解していないと、「だれがこんなシステム使うんだ」という気持ちで携わる形になってしまうと、機械的な作業で機転が効かなくなってしまうなど、良いことは一つもありません。

アプリが解決する課題における目標を設定する

開発で費用をかけたからには、その費用を回収できるだけのビジネスとなっている必要があります。単に「こんなアプリがあったら便利だな」というだけでは昨今非常に貴重かつ高価なエンジニアに開発してもらうことが困難な世情となっています。

そのアプリがどれほど社会に役に立ったか次第で収益力が変化するでしょう。アプリリリースさせてから1年後、2年後にかけるプロモーション費用や業務浸透を計算し、課題が解決された先にどれだけ利益が出そうかということについて、十分な検討が必要でしょう。それは具体的な金額でなくとも、ダウンロード数や利用者数などでも測ることが可能です。

そのアプリが対象利用者にとって無くてはならない存在となる必要があるため、課題を考えるプロセスでは想像力を必要とします。脳内を早回ししながら時間を進め、リリース直後からの施策を含めてより多くの利用者が便利に感じ、日常、あるいは業務がとても効率的だと感じているところのイメージがとても重要です。

                                  (弊社の営業担当である海原)

類似システムや競合状況を知っておく

既に類似アプリやプロダクトはあるか、競合となるサービスや代替品はないか、目標とする類似アプリは何かを知る必要があります。業界が異なっても、使いやすさを例に取ることも開発者やデザイナーにとっては非常に参考となります。

一般にファイブフォース分析(https://ja.wikipedia.org/wiki/ファイブフォース分析)と言われる考え方があり、検討しているアプリがこれらの脅威に晒されても生き残れるかについて思考を巡らせることの価値が高いので、このような分析を行うことは重要です。

特に外部サービスと連携する場合は要注意です。プラットフォーマーの仕様変更や規制によってアプリそのものの存続が不可能となるケースも考慮にいれてください。例えば、私たちの手掛けたアプリやシステムで利用した中では、Google MapやYouTube、Facebookの提供するAPIはある時を境に変化することがあり、それに追従してアップデートが必要になります。

スケジュールを調整する

仮に10人月という仕事量を例に取った場合、1人で10ヶ月かけて進行することは易いのですが、10名が関与しても1ヶ月では終わりません。人々が連携する仕事は一般にスケジュールが短い程効率が低下します。

また、開発の請負業者やSIerなどは、エンジニアの稼働を埋めるという業態を取ることが一般的であるため。今すぐに開発に着手できるケースは偶然性が必要です。開発の打診を行って、すぐに開発を行えるケースは非常にレアなケースです。通常でも2~3か月、人気のある開発会社によっては、半年先までリソースが埋まっていることもあります。いくつかの開発企業の状況を把握しながらリリースまでの計画を行うと良いでしょう。

作業の実施範囲、責任範囲を考える

システム業界では作業範囲をスコープと呼び、この言葉をシステム開発会社は多用します。一般的なプロジェクトの流れは、要件定義・画面設計・デザイン・開発・テスト・リリース・保守となります。例えば別のデザイン業者にデザインコンセプトをお願いしたいなどの希望がある場合に同時並行での調整が必要となります。

また、サーバー、ネットワーク、ドメインの契約、サーバーOSやミドルウェアは誰がいつまで責任を持つかを考慮する必要があります。ここで一番注意が必要なことは、システムやアプリ全体において複数業者が関与する場合は綿密にスコ-プを分解して、漏れや不足、あるいは重複がないようにします。

インフラ構成の検討

例えば小さなシステムであれば、APP兼WEBサーバー1台+バックアップ用ストレージで済んでしまうように思われます。しかし例えばそのWebサイトのURLがテレビで紹介された瞬間に膨大なアクセスが来た場合、サーバーは一瞬にしてダウンします。

このようなケースに対応しなければならないと多くのサーバー機器と太いネットワークが必要になりますが、キリを考えるとお金がいくらあっても足りません。現在では多少高価ではありますが、アクセス数に応じて自動的にサーバーをコピーして増やす(オートスケール)機能も有効です。

また、開発会社からの希望としては、サーバーやネットワークは是非とも依頼側の企業様にて契約をいただき、ご支給頂けると助かります。

その他、バックアップや監視は必要かという点については、予算次第ではありますが、最低限の運用保守はつけて頂いた方が良いかと思います。いざというときの復旧速度に関わってくるためです。

納品後の検収要件

開発会社から納品がなされましたら、発注した通りの条件が満たされているかのチェックをお客様自身で行う必要があります。これを検収と呼ぶことが多く、また、この検収を行う期間を検収期間といいます。

検収期間中に見つかった不具合については、もちろん開発会社の責任において、修正を行います。ただし、検収後に見つかった不具合について、どこまで対応するかについては契約にもよりますので、検収および検収期間はとても大事なものであるということを頭に留めておいてください。



開発依頼時に伝えるといいこと

箇条書きでもよいので、以下の要件に当てはまるものは、依頼時に伝えると精度の高い見積もりを作成することができます。

〇機能概要
・ユーザー・管理者の利用フロー
・想定されるユーザー機能
・想定される管理機能
・本システムを担うアクター

〇推進体制
・プロジェクトのシステム構造や既存ベンダー
・別のシステムが絡む場合の既存ベンダーの協力を得られるかどうか

〇利用機種
・対応端末
・OSバージョン
・ブラウザバージョン
・特にアプリの場合、iOS/Android/両方の対応が必要かどうか

〇納入物
・開発上必要になる一般的なドキュメント以外の特殊なドキュメントが必要かどうか
(要件定義書、基本設計書、詳細設計書、DB図、デザイン一式、ソースコード、テスト設計書・結果報告書以外のドキュメント)

〇保守体制
・ローンチ直後は手厚く保守を入れておくと吉
・それ以外でも保守体制を組んでおくと、問題が起こった時の初動が早くなる

〇緊急時の対応
・高額を投じてベテラン集団がプロジェクトを手掛け、超高品質なシステムだと思われるシステムでも、必ず予期せぬ不具合は起こるもの
・このためシステムでも未来の予測能力やや不確実に対する態度がとても重要
・特に夜間や正月など、人々の休息時に起こるような緊急対応も検討

〇個人情報
・ユーザーの個人情報やデータを扱うか
・すでに会員データはあり、連携をするかどうか

〇ログイン
・ユーザー登録が必要かどうか
・SNSアカウントでログインするかどうか

〇課金決済
・既存の決済システムを使用する
・決済システムを新たにつくるかどうか

〇デザイン
・デザインの制作も依頼するか
・既存のデザインのトーン&マナーを踏襲する
・新規のデザインコンセプトから制作する
・デザインは自分たちで行い支給する

〇他社ツール、データ連携
Googleマップなど、他社のツールを使用するかどうか

〇その他の機能の実装
・メッセンジャー機能
・カメラ機能
・ソーシャル連携
・音声解析
・プッシュ通知
・動画プレイヤー
・ビーコン連携
・GPS連携
など

以上、開発依頼から検収まで、かいつまんで大体の流れと気を付けることでした。

これらはもちろん開発依頼時に伝えて頂けるととても助かりますが、開発依頼を頂ければ、開発会社から同じことをヒアリングされるかと思いますので、まずはお問い合わせいただければと思います。

また要件定義や設計時も何度となくお聞かせいただくことになりますので、必然と開発が進むにつれ、これらのことを意識することになるのではないかと思っております。

長文となりましたが、ここまでお読みいただきありがとうございました。


アシアルの中の人が技術と想いのたけをつづるブログ https://blog.asial.co.jp/2214

アシアル株式会社's job postings
1 Likes
1 Likes

Weekly ranking

Show other rankings
Like Rena Shimada's Story
Let Rena Shimada's company know you're interested in their content