アプリを作る際の方法論ではなく手順論
方法論は色々あると思うが、手順のみということで手順論を示していこうと思う。この手順に沿っていないと人的リソースの出入りでアプリ開発のノウハウが散逸してしまうのでそれを防止するためである。今のこのエントリーではまだとりあえずの私見としての草稿段階である。しかし、手順についての有用な手法を持っていない人には役に立つであろう。
１．コーディング規約を決める。
例：
・オブジェクト指向で作る。『インターフェース』と『共通の機能は基底クラス』、『派生クラス』の分離を行なっておくこと。
・実装を変える際は正常に動いているものは残しておいて、別のクラスに実装して入れ替える。（すなわちストラテジーパターン）
・状態遷移はアクセプタFSMをベースにする。
・エラー処理の方法「VM言語の場合は処理速度的に例外でエラーを返した方が良い。Native言語の場合はアーキテクチャに寄るが、C++の場合は処理速度的には基本的に戻り値でエラーを返す。」
・ビジネスロジック部（アプリ固有の状態遷移部）とライブラリ部（アプリで使用する機能、その他共通する機能群）の分け方を明確にする。
・ビジネスロジックの実装はストラテジーパターンで簡単に入れ替えが出来るようにしておく。
・コメントは〜〜のように書くなど（英語か？日本語か？）doxygenやjavadocスタイルに準拠させるか？など 特にifやswitchなどの条件分岐の理由をコメントで残しておくとソースコードがぐっと見やすくなる。
２．簡単な仕様書をドキュメントとして残す、書いておく
例：
・テスト環境、本番環境、コーディング環境などの作り方、設定方法などのノウハウ。（これら３つの事を丁寧、親切に記していないとかなりのタイムロスが起こる事がある。）
・必要な機能と実装優先度
・ユーザー側からの操作の詳細
・エラーが起こった際のチェックする所やエラー原因の特定方法、ログファイルのパス名など
・コード内の構造やソースコードファイルの説明など
・Subversionやgitなどのコード共有場所など
・アプリに使用する機能のついての所感や多数のソリューションがある中での採用理由、メリットデメリットなど
以下３〜５は必要に応じて横断的に行う。
３．テストケースの実装
・要するにTest Driven Developmentである。正しいテストケースの無いプロジェクトは人的リソースの出入りによって炎上する。
・フルスクラッチの場合このテストケースを作る際にインターフェースとエラーチェックの機能を実装する事が多い。
４．機能の実装
・要するにライブラリ作りである。ライブラリを作り終わったら前に作ったテストケースを用いてテストして不具合やバグが無くなるまでしっかり作ろう
６．ユーザー視点からのテスト
ユーザーが使う視点から実際にアプリを起動させて動作確認をしよう！動作確認リストをこの時に作ったほうが良い。（３・４・５のうちに色々あって２で作ったユーザー視点での動作確認リストは時代遅れになっている可能性が高いから）
エンドユーザーにテストしてもらって色々と改善箇所を洗い出そう。
７．ユーザー用、開発者用のマニュアルを作ろう
・マニュアルがなければどんなに高機能なアプリでも意味もワケも分からない無用の長物に成り果ててしまうでしょう。
・ユーザー側は画面の画像と矢印などを使って懇切丁寧に
・開発者側は別の言語や開発環境を使っている人が見ても分かるように書いておく。既知のバグリストと決定稿の仕様書もつけておく。
・６のエンドユーザーのテスト結果を元に厳密な仕様書とテストケースを作る。必要があれば３〜５に戻って改修、作り直し
８．厳密なテストケースを通過したらリリース
７で洗いだした厳密なテストケースを通過したらリリース可能なクオリティーになっているのであとはリリースを待つだけ！
