0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

契約アプリ開発ってどんな感じ?プロセスを解説

Posted at

契約アプリ開発ってどんな感じ?プロセスを解説

契約でお仕事としてアプリを開発するのって、ちょっと特別で、すごくやりがいがあるんです。技術的なスキルはもちろん大切だけど、それ以上にクライアントさんとのコミュニケーションをしっかり取ったり、お仕事の範囲(スコープ)をちゃんと管理したり、クライアントさんの「こんなアプリにしたい!」っていう想いや、お仕事でどんな風に使いたいのかを深く理解することがすごく重要になってきます。このドキュメントでは、私たち開発チームがどんな風に契約アプリ開発を進めていくのか、その典型的な流れと、それぞれの段階で気をつけたいポイントをまとめてみました!

1. プロジェクトスタート!何を作るか決めよう(プロジェクト開始とスコープ定義)

ここは、これから作るアプリの目的や、どんな機能が必要か、どこまでを私たちがお手伝いするのか(スコープ)を決める、とっても大事な最初のステップです。後から「あれ?思ってたのと違う…」とか「これもお願いできますか?」みたいなことにならないように、クライアントさんとしっかりお話しして、細かいところまでドキュメントに残しておくのがポイントです!

  • まずは相談!どんなアプリにしたいか教えてください(初期相談と要件収集): クライアントさんとお話しして、どんなお仕事をしていて、誰にアプリを使ってほしいか、アプリで何を達成したいか、そして「こんな機能があったらいいな」というアイデアを聞かせてもらいます。ぼんやりしているところも、質問しながら一緒にハッキリさせていきますね。
  • 「これ、技術的にできるかな?」をチェック!(実現可能性調査と技術評価): クライアントさんの要望が、技術的に実現できるかを確認します。もしかしたら難しいところや、新しく挑戦しないといけない技術、他のサービスと連携する必要があるかなどを調べます。
  • どこまでやるか、ハッキリさせよう!(スコープ定義): 要望をもとに、プロジェクトで「これはやります!」という範囲と、「今回は含みません」という範囲を明確に決めます。どんな機能を作るか、どの端末で動くようにするか、どんな成果物をお渡しするかなどをリストアップして、ちゃんとドキュメントに残します。
  • どれくらい時間がかかるかな?(見積もり): 決まったスコープをもとに、どれくらいの時間や人手が必要かを見積もります。作業を細かく分けて、それぞれのタスクにどれくらいかかるかを考えます。難しい機能があるか、特別なスキルが必要か、何か他のものに影響されるかなども考慮して、見積もりの根拠も正直にお伝えしますね。
  • お約束事を決めよう!(提案と契約): 決まったスコープや見積もり、いつまでに何をするか、お支払いのタイミング、作ったものの権利など、お仕事を進める上での大切なお約束事をまとめた提案書と契約書を作成します。お互いに内容をしっかり確認して、「これでOK!」となってから次に進みます。
  • どうやって連絡を取り合う?(クライアントコミュニケーション計画): クライアントさんと、どんな方法で、どれくらいの頻度で連絡を取り合うかを決めます。進捗報告の方法(例えば、毎週の打ち合わせや報告書など)や、誰に連絡すればいいかもハッキリさせておきます。

2. どんなアプリにするか、もっと具体的に考えよう!(計画と設計)

スコープが決まったら、次はもっと具体的にアプリの中身や見た目を考えていきます。技術的な設計や、使う人が「使いやすいな」って思えるデザインを考えるステップです。

  • 要望をさらに詳しく!(詳細な要件分析): 最初にもらった要望を、もっともっと細かく具体的にしていきます。どんな時にどんな動きをするか、みたいなところまでしっかり決めます。
  • アプリの見た目と動きをデザイン!(UX/UI設計): アプリの画面の移り変わりや、ボタンの配置、色合いなどをデザインします。ワイヤーフレームやモックアップ、実際に触れるプロトタイプ(Figmaとかで作ります)を作って、「こんな感じになりますよ!」とクライアントさんに見てもらいます。開発に入る前に、デザインのOKをもらいます。
  • アプリの中身をどう作るか設計!(技術設計とアーキテクチャ): アプリの骨組みをどうするか、どんなプログラミング言語やツールを使うか、データの保存方法、他のサービスとの連携方法などを技術的に設計します。
  • 開発の準備をしよう!(開発環境セットアップ): アプリを作るためのパソコンの設定や、テストをする場所、実際にアプリを公開する場所などを準備します。コードの書き方のルールを決めたり、みんなでコードを管理する方法(Gitを使ったり)、書いたコードをチェックする仕組みも作ります。
  • 自動でアプリをチェック&公開!(CI/CDパイプライン): アプリを作る、テストする、公開するという流れを自動でできるように仕組みを作ります。最初からこれをしておくと、後々すごく楽になります。
  • テストの計画を立てよう!(テスト計画): アプリがちゃんと動くか、色々なテストをするための計画を立てます。プログラムの小さい部分のテスト、機能同士が連携するテスト、そしてクライアントさんに実際に使ってもらってのテスト(UAT)の基準なども決めます。

3. いよいよアプリを作り始めます!(開発)

ここでは、決まったデザインや設計をもとに、実際にアプリのコードを書いていきます。契約開発では、クライアントさんにこまめに進捗を見てもらいながら進めることが多いです。

  • 少しずつ作って見てもらおう!(反復開発): アプリを一度に全部作るのではなく、いくつかの期間(スプリント)に分けて、動く機能を少しずつ作ってクライアントさんに見てもらいます。
  • できたところを見てもらう会(定期的なクライアントデモ): 作った機能がどんな風に動くかを、定期的にクライアントさんに見てもらいます。「イメージ通りかな?」とか「ここはこうしてほしいな」といったフィードバックを早めにもらえます。
  • 「今、こんな感じです!」を報告(コミュニケーションと進捗報告): クライアントさんには、今どこまで進んでいるか、何か困っていることはないか、計画からずれているところはないかなどを、こまめに報告します。
  • 「やっぱりここを変えたいな」に対応(変更要求の処理): クライアントさんから「ここをこう変えたい」という要望があった場合、それをどう進めるかのルールを決めておきます。変更することで、お仕事の範囲や期間、費用がどう変わるかを伝えて、クライアントさんのOKをもらってから作業します。
  • みんなでコードをチェック!(コードレビューと品質): チーム内で書いたコードをお互いにチェックし合って、コードの質を高く保ったり、書き方を統一したり、問題がないかを確認します。
  • 自分たちでもしっかりテスト!(内部テスト): アプリを作っている間も、プログラムの小さい部分や、機能が連携するところなど、色々なテストを自分たちで行います。

4. アプリがちゃんと動くか、よーくチェック!(テストと品質保証)

アプリをクライアントさんに渡す前に、アプリがしっかり動いて、問題がないかを確認する、とっても大切なステップです。

  • 色々な角度からテスト!(包括的なテスト): アプリの機能がちゃんと動くか、たくさんの人が使っても大丈夫か(パフォーマンステスト)、情報が漏れたりしないか(セキュリティテスト)、色々なスマホやタブレットで使えるか(互換性テスト)など、色々なテストを計画通りに行います。
  • 見つかった問題は直そう!(バグ修正): テストで見つかった「あれ?おかしいな」というところ(バグ)を直します。
  • クライアントさんに使ってもらおう!(クライアントユーザー受け入れテスト(UAT)): クライアントさんに、実際にアプリを触ってもらって、問題がないか確認してもらいます。テストのやり方を説明したり、フィードバックをもらったりします。
  • クライアントさんの意見を聞いて直そう!(UATフィードバックへの対応): クライアントさんから「ここを直してほしい」という意見や、見つかった問題に優先順位をつけて対応します。クライアントさんが「これで大丈夫!」とOKを出してくれたら、このステップは完了です。
  • セキュリティとか、専門家にも見てもらおう!(セキュリティ&負荷テストの調整): 契約によっては、セキュリティの専門家や、たくさんの人が使った時にどうなるかをテストする専門家にお願いすることもあります。その場合、彼らが見つけた問題にもちゃんと対応します。

5. アプリを公開して、クライアントさんにお渡し!(デプロイと引き渡し)

アプリのテストが終わって、クライアントさんのOKが出たら、いよいよアプリを世の中に公開したり、クライアントさんにアプリの全てをお渡しするステップです。

  • 公開の準備をしよう!(デプロイ計画): アプリを公開するための準備をします。アプリを動かすサーバーの設定をしたり、アプリがちゃんと動いているかを見守る仕組みを作ったりします。
  • アプリストアに出そう!(App Store Submission): もしスマホアプリなら、AppleのApp StoreやGoogle Play Storeにアプリを出すための準備をします。アプリの説明文や、画面のスクリーンショット、どんなところが新しくなったかなどをまとめます。クライアントさんのアカウント情報や、公開のOKをもらうための調整もします。
  • いざ、公開!(デプロイ実行): 準備ができたら、アプリを公開したり、アプリストアに申請したりします。
  • アプリの取り扱い説明書!(ドキュメント): アプリの技術的なことや、使い方、クライアントさんのチームがアプリを管理するために必要な情報などをまとめたドキュメントを作成します。
  • アプリの使い方を教えよう!(トレーニング): 必要であれば、クライアントさんのチームにアプリの使い方や管理方法を教えるトレーニングを行います。
  • 「はい、どうぞ!」(引き渡し): 作ったアプリのコードや、ドキュメント、アプリを動かすための情報など、プロジェクトで作ったものを正式にクライアントさんにお渡しします。

6. アプリを公開した後もサポート!(メンテナンスとサポート)

アプリを公開した後も、しばらくの間、何か問題がないか見守ったり、困ったことがあったら助けたりする期間が含まれることが多いです。

  • 公開後に見つかった問題に対応&アップデート!(バグ修正&アップデート): アプリを公開した後に見つかった問題(バグ)を直したり、必要に応じてアプリを新しくしたりします。
  • アプリがちゃんと動いているか見守ろう!(監視とパフォーマンス): アプリがスムーズに動いているか、何か問題が起きていないかなどを常にチェックします。
  • 困った時の対応スピードのお約束(SLA遵守): もし何か問題が起きた時に、「これくらいの時間内に対応しますね」というお約束(SLA)があれば、それを守ります。
  • これからも連絡を取り合おう!(継続的なコミュニケーション): アプリが公開された後も、アプリの調子はどうかな?使っている人からの意見はどうかな?これからもっと良くしていくにはどうしたらいいかな?といったことをクライアントさんとお話しし続けます。

7. 契約開発で特に気をつけたいこと

契約でお仕事をする時に、特に大切にしてほしいポイントがいくつかあります。

  • 契約内容と請求は明確に!(明確な契約と請求): 契約書に、何を作るか、いつまでに何をするか、いつお支払いするかなどがハッキリ書かれているか確認しましょう。お支払いのスケジュールもきちんと守ります。
  • お仕事の範囲はしっかり管理!(スコープ管理と変更管理): 最初にお約束したお仕事の範囲(スコープ)が、いつの間にか広がってしまう(スコープクリープ)ことがないように気をつけます。もし、やっぱりここを変えたい!という要望があったら、それがお仕事の範囲や期間、費用にどう影響するかを伝えて、クライアントさんのOKをもらってから進める、というルールをちゃんと守ります。
  • クライアントさんとのコミュニケーションが一番大事!(コミュニケーションは鍵): クライアントさんに「今、こんな状況ですよ」「こんな問題がありそうです」といったことを、隠さず、早めに伝えることが、クライアントさんの安心につながり、信頼関係を築く上でとっても大切です。
  • 作ったものの権利は誰のもの?(知的財産): 作ったアプリのコードやデザインなどが、誰のものになるのかを契約書でハッキリさせておきます。
  • クライアントさんはパートナー!(関係構築): クライアントさんを単なるお客様としてではなく、一緒にアプリを作り上げるパートナーとして考えましょう。良い関係を築くことができれば、また次のお仕事につながることもあります。

このプロセスは、契約アプリ開発をスムーズに進めるための基本的な流れです。もちろん、プロジェクトやクライアントさんによって色々な状況があるので、この流れを基本に、柔軟に対応していくことも大切ですよ!

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?