アプリケーション開発の作業工程について解説します。
作業工程がわかれば、どこまで作業が進んだか、
どの作業が遅れているか等、進み具合がわかりやすくなります。
※長文なので、結論だけ見たい方は「まとめ」をご覧ください。
１．提案書(企画書)作成
提案書とは、顧客や自社の課題解決に必要な提案内容をまとめた資料のことです。自分や組織のアイデアやプランを相手方に提示し、理解や賛同を得ることが目的となります。
引用元：https://biz.moneyforward.com/work-efficiency/basic/2134/
開発してほしいアプリケーションを
どうやって実現するか説明するための資料です。
依頼者と私との認識を共有して円滑に開発を進めるのに重宝します。
提案書は私からだけでなく、依頼者からもどんどん意見を言って頂いて、双方が納得できるまで打ち合わせができれば、より良いもの(ブラッシュアップしたもの)ができあがります。
企画書とは、新規プロジェクトなどのアイデアや、やりたいことを実現するために、誰が見てもわかるようにまとめた文書のことです。
提案書だけでも十分ですが、
企画書の場合は仕様書に書くような、具体的に実行可能な方法まで記載します。
不要な場合は省略可能です。
依頼者側で最初から用意されている事も多いですね。
依頼者側で用意されていた場合は、逆に企画書を基に提案書を作成して依頼者と私との認識を共有、
必要に応じて企画書の修正を行っていきます。
２．仕様書作成
「仕様書」は、システムが備えるべき機能や性能などを記載した文書のことです。システムを開発する際など、システムのあるべき姿を示し、「何を作るのか」を文や図で表現しています。
仕様書は一度決定したら内容の変更が困難です。
こちらも依頼者側で最初から用意されている事があります。
仕様書は提案書を基に、開発するアプリケーションへ実装される機能の詳細をまとめた資料になります。
依頼者側で用意されていた場合は、逆に仕様書を基に提案書を作成して依頼者と私との認識を共有、
必要に応じて仕様書の修正を行っていきます。
また、仕様書に書かれていない事項は一切考慮されていないので、
抜けていたり追加したい事項があれば早めに指摘しないと作業の遅れが発生する原因になります。
最も困る事は、途中で仕様を変更する事です。
開発日数が伸びるだけでなく、無駄になってしまった日数分の料金も発生してしまいます。
仕様の追加は許容範囲
仕様の変更は双方デメリット多数
急ぎで無いのであれば仕様書の確認は最重要事項です。
３．工数見積書作成
仕様書を基に、アプリケーションが完成するまでに必要な作業項目と、おおよその日数を資料にまとめます。
合計工数でアプリケーション開発に必要な料金や完成日が見えてきます。(確定では無いです)
この資料で、予算内か、期日に間に合うか等が判断しやすくなります。
予算オーバーや期日に間に合わない等で開発を中止する場合は、
提案書や仕様書作成分の料金を請求する場合があります。
資料作成だけでもお金取るんですか?
あ、はい。
依頼者を疑いたくはないのですが、
提案書等で出した私のアイデアだけ盗んで、
こっそり別の方へ依頼するという可能性を考えています。
「示談金」に近い請求かもしれません。
「示談」（じだん）とは、トラブルの当事者同士が互いに譲歩して、争いをやめる合意をすることをいい、民法上の「和解」に当たります。
例えば交通事故、刑事事件、契約違反（債務不履行）、近隣トラブルなどについて、当事者間で示談が行われることがあります。
簡単にまとめると、
「示談金」を頂けたら、作成した資料は自由に使ってもらって良いですよ。
という感じでしょうか。
トラブルを回避するための手段としてご理解いただけますと幸いです。
４．モックアップ作成(省略可)
モックアップの本来の意味は「模型」です。まだ機能が実装されておらず、実際に使うことはできないものの、外面の完成イメージを把握できるサンプルと捉えてください。
アプリ開発においては、アプリ完成後のデザイン・イメージを検証する目的で作られたビジュアル・サンプルをモックアップと呼びます。
アプリケーションの見た目だけでなく、操作感の確認に使われます。
アプリケーションの開発を急いでいたり、機能に重点が置かれている場合は、
モックアップの作成を省略する事もあります。
モックアップは提案書と同様に、依頼者と私との認識を共有して円滑に開発を進めるのに重宝します。
例えば、依頼者が「思っていたものと違う」といった認識違いを未然に防ぐ事ができます。
アプリケーションに使用するボタンの画像等は、
予め依頼者側で用意してもらえると非常に助かります。
もちろん用意していなくても、
開発環境標準の画像で作成可能なので問題はありません。
また、この段階であれば「仕様の追加、変更」は、工数の増減は発生しますが他は特に問題はありません。
５．アプリケーション開発
プログラマーの主業務です。
アプリケーションに実装する機能が多い場合は、
細分化して進捗等がわかりやすくなるようにします。
例．「Chattering_Controller」の実装機能項目の細分化と開発工数の表
| 親項目 | 子項目 | 孫項目 | 工数(日) |
|---|---|---|---|
| 基本画面 | ユーザーインターフェース | 1 | |
| チャタリング制御 | マウスのクリックイベント取得 | 4 | |
| マウスのクリックイベントを基に チャタリングを判別 | 4 | ||
| チャタリング発生時の処理 | 4 | ||
| 確認用のログ出力処理 | 1 | ||
| ログ表示 | チャタリング制御のログを表示 | 1 | |
| アプリ説明画面 | ユーザーインターフェース | マークダウンデータの表示 | 1 |
| 権利表記画面 | ユーザーインターフェース | 1 | |
| 表示項目の取得 | アプリケーションに使われた 外部パッケージ情報の取得 | 1 | |
| タスクトレイ表示 | 1 | ||
| 管理者権限で実行 | 全てのマウスイベント取得用 | 1 | |
| 多重起動防止 | 1 | ||
| スタートアップ制御※ | 管理者権限でも動作させる | 2 | |
| インストーラー | インストール | アプリケーションの導入簡略化用 | 1 |
| アンインストール | 設定ファイル等の削除 | 1 | |
| 工数合計 | 25 |
この表は工数見積書に書く内容と殆ど同じです。
ちなみに工数見積書にはさらに、
各種資料作成、モックアップ、デバッグの工数等
アプリケーション完成に必要な項目が全て書かれます。
あと、開発期間が長期となる場合、週又は月毎に開発費用を請求する事があります。
これは、アプリケーションが完成するまで私の収入が0になる事を防ぐためなので、どうかご了承ください。
６．デバッグ(省略可)
デバッグとは、ソフトウェアのバグ（問題）を特定し、取り除く作業のことです。実際にソフトウェアを実行しながら、正しく動作するかチェックします。バグが見つかった場合の原因調査や修正、再チェックもデバッグに含まれる重要なプロセスです。
デバッグは英語で「debug」と表記します。この英語は、虫を意味する「bug」に、「除去」を意味する「de」を付けたものです。つまり、デバッグは「ソフトウェアの虫（バグ）を除去する」といった意味合いになります。
私やデバッグ専門の方(デバッガー)がアプリケーションの動作確認を行い、
不具合の発見と修正を行います。
「アルファテスト」と言われる事もあります。
作業を省略することも可能ですが、怠った場合に発生した不具合の修正は、余計な負担やトラブルの原因になりやすいのでご注意ください。
７．動作テスト(省略可)
デバッグは私やデバッグ専門の方(デバッガー)が行う作業ですが、
動作テストは依頼者やアプリケーションの利用者に動作確認していただく作業です。
「ベータテスト」と言われる事もあります。
こちらも省略可能ですが、実際にアプリケーションを使用する際に不具合が発生したら、私は責任が取れない場合があるので省略はお勧めできません。
８．アプリケーション完成
お疲れ様でした!
依頼されたアプリケーションが完成しました。
ここで実際に掛かった工数と作業項目をまとめて、請求書を作成します。
※もちろん完成までに既に支払われた開発費用についても、支払い済みとして記載されます。
開発費用については、以前にまとめた記事がありますので、よろしければそちらもご確認ください。
９．保守(省略可)
アプリケーション完成で終わりでは無いです。
アプリケーションを使っている中で、デバッグや動作テストで見つけられなかった不具合が見つかった場合、保守期間の間であればすぐに修正対応が可能です。
家電製品で言うとサポート(保障)期間のようなものです。
期間外だと修正対応できない場合があるので、その点にはご注意ください。
アプリケーションの利用開始を急いでいる場合、不具合発生を許容できるなら動作テストは省略して、
不具合が見つかったら保守で修正してもらうという手段がよく使われます。
１０．機能の追加、変更(バージョンアップ)
既存のアプリケーションに新しい機能を追加したり、機能を変更したりする場合は、
内容が小規模であれば工程を省略可能ですが、基本的には新規のアプリケーション開発と同じように提案書作成から作業が開始されます。
別の方が作成されたアプリケーションに対して
機能の追加、変更を行う場合も同じ作業です。
まとめ
アプリケーションが完成するまでの作業工程を表でまとめました。
| 作業工程 | yokiの作業 | 依頼者の作業 |
|---|---|---|
| １．提案書(企画書)作成 | 〇 | △or〇 (確認、提案、事前準備) |
| ２．仕様書作成 | ● | △or〇 (確認、事前準備) |
| ３．工数見積書作成 | 〇 | △ (確認) |
| ４．モックアップ作成(省略可) | 〇 | △ (確認) |
| ５．アプリケーション開発 | ● | △ (進捗確認) |
| ６．デバッグ(省略可) | 〇 | – |
| ７．動作テスト(省略可) | △ (不具合修正) | 〇 |
| ８．アプリケーション完成 | △ (請求書作成) | – |
| ９．保守(省略可) | △ (不具合修正) | – |
| １０．機能の追加、変更(バージョンアップ) | 作業工程1から | 作業工程1から |
他に聞きたい事があれば、気軽にお問い合わせください。
匿名の場合は、この記事か別の記事で回答します。
誤字、脱字、誤表記のご指摘も歓迎です。
