アプリを作る前に。

早速アプリを作るよ！のその前に

アプリを作り始める前に、どんな手順で進めていくか決めておきます。
初めに決めておくと、後で「あれ？この後なにすれば良いんだ？」とならなくて楽なんです。

今回は、こんな手順で進めていくよ！

(1)アイデアを絞り込む
いわゆる企画段階。アプリの機能やアピールポイントなどを考える。商用なら採算が合うかというのも大事なポイントだよね。市場調査とか競合他社との比較とか。

(2)システム設計
絞り込んだアイデアを実現するために必要な仕組みやリソースを検討する。これで必要な経費とかが大体わかるかな。あと、将来性を見込んだり。見込まなかったら後で大惨事があることも。逆に見込みすぎてオーバースペックだったり。。。さじ加減大事。

(3)プロトタイピング
webで言うところのワイヤーフレームってやつですかね。ここで使い勝手とか大方のデザインとか決まるので、責任重大。最近ではUXとか言われる事もあるかな？ユーザビリティとかもここがポイントでしょうね。

(4)UIデザイン
プロトタイピングで決まった形に合わせて、デザインを決める。ブラッシュアップすると言った方がいいかな？最近の傾向だと、iOSとAndroidでUIを変えるのが良いみたい。まあ、ハードが違うから当然っちゃ当然か？標準UIも違うしね。

(5)詳細設計
UIデザインと並行でもいいんだけど、実装に必要な要素を確定する。APIの仕様だとかデータの形式だとか。ここでちゃんと決めておくと後々のプログラミングがすごく楽。設計書作るの面倒だからと、ここをすっ飛ばすと後々苦労するので、多少面倒でも設計書はあった方がいいと思う。便利なツールも色々あるしね。
何と言っても、作ってる最中に自分の決めた仕様忘れるから！覚え書きとしても必要なのですよ。

(6)実装
いわゆるプログラミングの部分。アプリ制作のメインでありながら地味な作業。
動作確認をしながら着々と進めることが大事。
ここで仕様変更あると、いろいろ大変なので、詳細設計で矛盾点とか洗い出しとくのも大事。

(7)動作テスト
テストには単体テスト（ユニットテストとも言う）と結合テストがあって、単体テストは実装しながらやっていくテスト。
機能単位とかメソッド単位とか、ちっさい単位でやっていった方がいいと思っている。
結合テストは総合テストというか、全体を通して動作の確認をする。

(8)リリース
テストで問題なければ、ようやくリリースですよ。リリースするにあたって、宣伝も大事だよね。
この辺のうまいやり方は私も知りたいところ。これをリリースするまでには調べておきたいところ。

わぉ。さらっと書いたつもりだったけど、結構満載になっちゃっいましたね。簡単なアプリと言えど、こんだけの手順が必要なんだ。。。
実際は(4)と(5)とか、(6)と(7)とか同時進行で進んでたりするけど、今回は一人で全部やる事になるから時間的にはあまり変わらないのね。

どうやって開発手順を決めたかと言うと

今までの経験をもとに考えてみたんだけど、開発手順にもトレンドがあって、日々進化してるのよね。ウォーターフォールだとかアジャイルだとか。
まあ、これが正解だ！みたいな便利は答えはないんでしょう。会社によって決まっている事も多いです。

少人数で進める場合（まあ、今回はぼっちで進めるわけですが。。。）、アジャイルのような手法がやりやすいと言われています。
アジャイルっていうのは、簡単に言うと短い期間を区切って、少しずつ完成させ、随時更新していく手法のこと。
誤解している人も多いけど、決して文書を作らず打ち合わせのみで、各自勝手にどんどん進めていくという手法では決してない。（こういうのを、カウボーイコーディングと言うらしい）
例え一人ぼっちであっても、最低限の仕様書などは必要なのです。だって、自分で決めたことでも時間が経つと忘れたり、勘違いして覚えてたりすることは多々あるからね！

しかし、考えてみると、ちゃんとしたアジャイル開発ってやったことない。。。
今回は、ウォーターフォールとアジャイルの良いとこ取りな感じで進めることにしようかな。

ウォーターフォールと言うのは、水が上から下に流れるように、決められた行程を順番に進めていく手法のことです。かなり昔ながらの手法で、廃れたと思われてる節もありますが、大きなプロジェクトではまだ多く使われています。

そこで、ウォーターフォールのようにある程度の行程を踏みつつ、実装の時は細かく細分化して、少しずつ作成していく感じで進めていくことにしました。

文書はプロトタイプとか仕様書、簡単な設計書は作ります。仕様書とか設計書とかは面倒がる人多いけど、作っておいて損はない。昨日の自分は他人だから、決めたことはすぐ忘れるのです。コードを書き始めた時に考えてたことと、書き終えるころに考えてることが一緒とは限らない！コーディング中に迷子になることは珍しくないんですよ。（もしかして私だけ？？？）

とは言え、時間ももったいないので、きちっとしたのではなくて、メモ程度で決めたことだけ羅列したものでも良いとは思いますが。
仕様はできればコードの中にも書き込んでおくと、修正時とかに一々仕様書を確認せずに済んでなおよし！ですよね。
今回のプロジェクトは、実験的な意味合いもあるので、今まで使ったことはないけど、便利そうなツールとか手法とかを積極的に試して行きますよ。

のんびり１年くらいで、できたらいいな〜。目標年内！とかにすると少しは気合い入るのかな？