アプリ開発にあたり、コーディングの前にやること

Question

いままで何回か、開発したいアプリのイメージはあるけど、特に準備をせずに行き当たりばったりでコーディングして、いずれも途中でごちゃごちゃになって挫折してきました。

もちろんコーディング=アプリ開発ではないことはわかっていますが、具体的に何をすればいいかピンときていません。

アプリの画面遷移、クラス図以外だとなにをすればいいんでしょうか？

みなさんはどんなことをするんですが？

Answer 1

一番重要なのは利用者が何をしたいのか、具体的に言うとどのようなインプットをしたらどのようなアウトプットが得られるか、を正確に把握することだと思います。
要件定義ですね。

もう少し話が進むと、画面構成とデータ構成の決定でしょうか。
いずれも一度決めたものを後から変えるのはコストがかかります。
特に画面構成は早い段階でモックでもよいので利用者に提示してあげた方が良いです。
後になってから「こんなはずじゃない」「使いにくい」と言われがちです。
※GUIアプリでなければ入力方法/項目と出力方法/項目。

加えて、ビジネスロジックの整理も必要です。
おおむねソフトウェアは何かしらの入力を処理して何かしらの出力をする訳ですが、その過程の処理は利用者でないと分からないことが多いです。
利用者であっても分かっていないかもしれないです。
利用者が分かっていなければ、一緒になって考えてあげる必要があるかもしれません。
その時「処理する」「管理する」という言葉は使わないようにすべきだと思います。
この２つの単語、何か分かった気になるようで実は何も意味してなかったりするので。

そこまでできれば、自然とコーディングの方向性は決まっていくような気がします。
よく「利用者(客)が後から仕様変更してきて…」なんて話を聞きますが、その多くは最初にきちんと話ができていな事が原因だと思っています。

Answer 2

私は、ナントカ図とかナントカチャートとか、まともに書いたことがありませんので、そういうのは無しで回答してみたいと思います。

趣味で作るなら行き当たりばったりなのも悪くないと思います。思い付きでガリガリとコーディングするのも楽しいもんです。

yubaさんもチラっと書いてますが、モノがどうであれ「完成させる」という体験は非常に重要で、どこまで作り込むか、何を切り捨てるかといった決断力・判断力が必要ですし、一つのものとしてまとめあげるパワーも必要です。

完成させた後で、使いにくい部分は改良し、足りないものは追加すればいいだけです。
機能的には変わらなくても、より良いコードに書き直すのもプログラミングの楽しみの一つだと思います。

最初は、機能を絞って小さなものから作ってみてはどうでしょうか？

Answer 3

特に準備をせずに行き当たりばったりでコーディングして、
いずれも途中でごちゃごちゃになって挫折してきました

「解決済」ですけど、質問文からうかがえない考え方を言いますね。

---

ご質問は（事前）設計についてですが、アジャイルの観点から言いますと、
事前設計を過剰にするより、事後的な再設計もする方が有効だと思います。

つまり、「リファクタリング」が重要です。部分的に書き直します。
「途中でごちゃごちゃになって」きたら、リファクタリングします。

テストも書きます。リファクタリングとテストは車の両輪です。
テストで動作を保証すれば、安心してリファクタできます。

そのほか例外処理なども書きますし、UMLも書きます。
リファクタリングしたときには、UMLやドキュメントも同期させます。

そのように、プログラムを一度作ったら終わりではなく、
畑のように継続的に耕し続けるものだと考えます。

すると、1本のソフトにかかる時間は増えるでしょうが、
そこでソフトの価値を考えて、作るものを絞り込みます。
そして、最終的なアウトプット（売上等）が増えれば良しとします。

Comments

[akamakku]

解決済みになっているのに回答ありがとうございます！
どうやら間違ってBAのボタンを押してしまったようです。(以前は取り消すボタンがあった気がしたんですが見当たらない…)
太字の使い方が上手でとても読みやすい回答でした。
事後のことは頭にありませんでしたがそちらも考えて見ようと思います！

[fuzzball]

「✔ベストアンサー」の右横に無いでしょうか？

Answer 4

業務で使うとか他人のために書くっていうならそのあたりのことはいろいろ必要ですが、
個人の趣味であれば、そのへんの事はエクセルでちょっとまとめるだけで十分だと思います。
下手に凝った事をしだすと、余計に管理に手間がかかって時間もモチベーションも消費していく一方だと思います。

個人の趣味で何か作るときに必要なことは、その成果で何かしらの利益を得られる算段を立てる事です。
この場合の利益は、もちろんお金でもいいですし、それ以外でもいいですが、
漠然とした満足感とか知識とかそういうのはやめた方がいいです。

スマホ開発なら、今は個人でも販売まで持っていけますから、実際に販売してあわよくばそこそこの収入を得るなんて目標を立てておくと開発にも力が入ります。
ただし、この場合、あまり儲けようとすることに目がいきすぎると開発の本質と遠ざかって疲れてしまうので、あくまで、あわよくばくらいに留めておくのが無難です。
もちろん、実際に販売できる環境にある人は一部（会社が副業禁止とかなら当然NGなので）なのであくまで一例です。

Comments

[akamakku]

ishi9さんはエクセルに何をまとめるんですか？

[ishi9]

恥ずかしながら、本当に大した事を書いてませんし特に決まった書き方もしていません。
軽く作りたいものの設計というか、やりたいことをある程度具体化するときにやります。
書き方は強いて言えばWBSっぽい書き方することが多いですね。まず大まかに分類して、それぞれの作業や問題点をもうちょっと細かく分解してって感じで。
締め切りは気分で書いてみたり守らなかったり、本当に適当です。
参考URL
http://www.aerith.net/design/wbs/wbs5-j.html

こんなにちゃんとは書きません。色とかも別に塗らないし、分類も3段階とかじゃないですし。単に考えている事を一つ一つ掘り下げていく時にこういう階層的な書き方が合っているってだけです。もちろん、私個人の話ですし、書き方や書くことそのものはさして重要ではないと思っています。（まぁこういうメモ書きはなんだかんだでやっぱり必要にはなると思いますが）

[akamakku]

なるほど〜
自分にあった方法を見つけていきます！

Answer 5

ごちゃごちゃになって挫折した経験は決して無駄ではありません。
ごちゃごちゃになりつつも完成まで持っていった経験もあるとさらに良いですが。
そういう重ねた経験を踏まえて、それこそクラス図だとかシーケンス図だとかのソフトウェア設計の理論を勉強すると、ああ、こうだったのかと体で理解できて、それで初めて「まずはしっかり設計するところから」と始められると思います。

その境地に至るまでにどうやってとりあえず完成させるかですが、ごく簡単なアドバイスとしては、

• そのアプリ特有のプログラムコード
• 環境（iOSだったりAndroidだったりWindowsだったり）特有のプログラムコード

を分けることから考えてみませんか。
例えばObjective-Cで書くとしたらそれはもうiOS専用のプログラムであるのは自明なのですが、それでもCococaフレームワークの仕様に関連した部分と、自分のアプリの動作というものに関連した部分をきっちり分けようということです。
開発言語がもしC++かC#であれば、「自分のアプリの動作」を記述した部分はiOSでもAndroidでもWindowsでも使えるということになります。そういう姿を目指してみる、というのを提案します。

「モデル」「ビュー」「コントローラ」という言葉はもう見聞きしたことはありますか。そういう、自分のアプリの動作を記述したオブジェクトがざっくりと「モデル」に当たります。