プログラマ専用SNS ミクプラ

とあるＩＴ系ニュースサイトでもあったのですが、
趣味のプロジェクトをきちんと仕上げるには、どのような心がけが必要でしょうか？

お金をもらってやるプロジェクトだと、完全なロードマップや納期もあるし、
プロジェクトに集中することになりますが、趣味でやっているプロジェクトは
完成したためしがなく、品質にも納得したことがないという風な始まりなのですが

私も、その一人です
どのようにしたらプロジェクトは完成しやすくできるでしょうか？
何か工夫や経験などあれば教えていただきたいです

私が作る場合は、完全に学習のための物を除くと、
殆どが自分で使える（遊べる）ものです。

最低限使えるものを作り、後は気が向いたときに
改良していきます。改良すべき点を思いついても
時間が無いときなどは、TODOリストに書くだけ。

完璧になったら完成だとすると、私は殆ど完成させていませんが、
自分のプログラムは常に改良中であると考えてはどうですか？

趣味のプロジェクトとして失敗・挫折する要因としては下記十箇条に当てはまるかもしれません。

1.ぶっつけ本番で始める（後で修正が効かなくなりやすい）
2.安易な機能追加を行う（統一性のない仕様になりやすい）
3.動けばいいやと思って作り始める（1.と似てるがこちらの場合は飽きやすい）
4.目標となる完成までのプロセスを見ていない（どこかで狂いが生じやすい）
5.後でソースを見直す際に配慮したコードを書いていない（修正が困難になる）
6.統一した処理をしていない（バグが起きやすく、また起きた時の原因がつかみづらい）
7.プロジェクトの仕様が定まっていない（後の機能追加や動作確認に支障が出る）
8.目的の機能を実装する知識・技術が定まっていない（プロジェクトの停滞・挫折につながる）
9.先を見据えすぎた仕様で書こうとする（難易度が高くなりやすく、挫折の原因に）
10.コメントが無い（見直したときにコードの状況を掴みづらくなり、無駄な時間を消費する）

特に、「ただの趣味だ」と軽い気持ちで始めると、
上記十箇条に引っ掛かりやすくなります。
（自分の経験からの十箇条なので、参考程度に）

一応、プロジェクトを完成しやすくするための対処としては、

1.メモでもなんでもいいので、案を書きとめておく（仕様書的なものでも可）
2.機能追加を想定するならそれに予測する（あるいは対処した）コードを書く
3.完成する意思を持つ
4.プログラムの制作段階を見据える（システム部分、UI部分などの区切りとかで）
5.適当なコードを書かない
6.同様の処理は関数化（C++ならクラス・モジュール化）する
7.何を作るのかを常に記憶する（趣味で作っていると横道にそれやすい）
8.事前に必要な機能の実装を試す
9.いったん完成となるバージョンでの機能に限定して作る
10.関数（クラス）毎にコメントを入れ、後で見てわからなくなりそうなところ（処理等）もコメントを入れる（doxygen の書式で書けばリファレンスも作れて一石二鳥）

長くなりましたがこんな感じでしょうかね。

因みに現在私のサイトで公開しているライブラリは 4 年の間に 6 回も作り直した結果のものです。
どれも作りなおした原因は上記の十箇条に当てはまっていました。

提案としては、ブログに開発状況を書く。ホームページに開発途中でもアルファ版として公開してしまうのはどうでしょうか？
ようは、完成させなければいけない気分にさせるんです(自分にプレッシャーを掛けるとも言います)。
みんなが公開しているフリー/シェアソフトも市販ソフトも完成しているわけではなく常にバージョンアップしています。完成や高い品質を求めるから挫折しているのかも知れません。
１．とりあえず公開する時点の仕様と時期を決める。
２．段階を追ってバージョンアップする機能を決めておく。
３．実装が可能か先にコアな機能を試しておく(インターフェイスも一緒に作ろうとすると挫折しやすいです)。
要するに自分で納期とロードマップを作ってしまうわけです。
ブログでそれを発表するのも効果的ですね。

たいちうさん 御津凪さん　zwiさん
回答ありがとうございます

御津凪さんの十箇条にほぼ９０％以上当てはまり
うわぁって自分でなってしまいました

たしかにこれで完成って決めてしまうのも優柔不断な私には難しい方法かもしれませんので
常に改良中という認識でプログラムに挑むというのもいいですね
開発手法としてはスパイラス開発方式が合っているかもしれませんね

意思決定がなかなかできない私ですので、色々本などをよみあさっています
そこで、ある本にて意思決定方法について書かれてる本がありました
その本によると

１．候補案を出す
２．選択基準をつくる
３．最適案を選択する
４．行動する

とあり、また、よくデキる人たちの思考特性として

物事を考えるときに何について考えるかを決めてから考える
どのような手順で考えるかを決める
手順をふんでいっときにあれこれ考えない
与えられた時間の中で、今日はどこまでを考えるかを決めてから考える
基本的には原因と結果の論理的なつながりを立証しようとしている
案の選択とは、将来の得たい結果に向けての今日の手段づくりである

とあり、頭では多少理解できてるのですが、実行はなかなか難しいですね

実を言うと、あまりにも悩んでいるので、精神科の先生に聞いてみたところ
「ザツでいいからやりなさい」とおっしゃってくれました

まずは完璧を目指さず、ゆっくりやっていきたいです

昨日雑談に参加したかったのですが、昨日忙しくて出来ませんでした。
全く参考にならない意見を言うDixqです、こんばんは（ぇ

私はとにかく「作りたいものから作る」「動いたり、目に見えて作った気がするものから作る」という酷いスタンスですf^_^;
作りたいと思って始めるからには、やはり目に見えてそれが出来る姿を早く見たいんですよね。
それを見ることでモチベーションも上がりますし、私にとっては酷いスタンスでも合っているような気がします。

このような事は外道だということが解った上で言いますが、
「モチベーションを完成まで維持する」ということは趣味のソフト作成には最重要なんじゃないかと思いますので、やり方は少し大袈裟ですが、
ある程度自分の気分のむくままにやるってのも大事なんじゃないかと思います。

（ちなみに私はバグさんのおっしゃった事にあてはまりまくりですf^_^;
　そして実際に仕事を始めてみて、自分のコーディングスタイルがいかに悪いかがわかりました（笑））

モチベーションさえ持ち続けたら、途中で少々軌道がずれたり沢山修正しないといけなくなっても、
ゴリゴリなんとかやりますし、
反対に、いくらスムーズに作れるレールが作れたとしても、モチベーションが下がってしまっては制作はとまってしまうと思います。
仕事なら嫌でもやるかもしれませんが、趣味だといやになるとやりませんからね・・。
無茶苦茶で気の向くままな計画でも、経験を積むうちに、やりたい事を先回しにしつつも
うまく進められる計画というのが立てられるようになっていくのだと思います。

そういう面でも仕事と趣味では作り方が違うのだと思います。

後、zwiさんが仰っていますが、アルファ版っていうのもいいモチベーションアップの材料になりますよね。
しかも意見を言ってもらえる分、リリースせずに完成させる時よりいいものが出来るように思います。
私も体験版なるものを出させて頂きましたが、あれが無かったら完成もしなかったと思うし、
出来も妥協の塊のようなものになっていたと思います（完成品もあの程度のクオリティではありますが＾＾；）

また、２ｃｈとか、自分のリリースしたものが批判されている書き込みがある所を見て回りました。
批判コメントっていうのは改善出来る資料の宝庫ですよね。
褒め言葉からはモチベーションを、批判コメントからは改善案を得ることが出来るので、
やはりアルファ版のリリースというのは良いことだと思います。

・・・という王道から外れた参考にならない書き込みでした＾＾；

まだまだ未熟者ですが、未熟者の立場でちょっと雑談に参加させてくださいな。

私もよく、趣味のプログラムが途中から進まなくなって頓挫してしまった、
ということがよくありました。
やはり、モチベーションが薄れてしまうようなことが起こるとそうなってしまいますね。
私はプロではないので「仕事でプログラムする」という経験は無いですが・・・。
皆さんのお話を聞いていると、まぁ当然なのかもしれませんが趣味と仕事じゃ結構
モチベーションや姿勢が違ってくるんですね、参考になります。

私は、とにかく「モチベーションを維持する」という一点を常に心がけてます。
何をどうやってモチベーションを維持する、といったような技術的・論理的なやり方ではなく、
「また途中で頓挫してたまるかぁ！！」と自分に活を入れて維持していることが多いです。

理屈っぽいところでは、
・コードが何をしているか後から見てわかるようにする
・コーディングに着手する前に、使用するデータ構造やアルゴリズムを明確にしておく
というのを心がけています。
何をしているのかわからないコードを読み解くのは非常にモチベーションを削られますし、
時間もかかりますし、何より面白くないですからね。
例えば関数なら「何を引数にして、何が返されるか」をちゃんとコメントしておきたいと思ってます。
しかし、変数の役割や関数の説明を上手くコメントに表せなくて、
結局後から見たときに何をしているものなのかがわからなくなる、ということが多々あります。
変数などの抽象的な役割をわかりやすくコメントにまとめるコツなどがあれば是非勉強したいところです。

御津凪さんの挙げた十ヶ条は非常～に参考になりました。
紙にメモして、パソコンの横の常に見えるところに貼り付けておきたいと考えています。
zwiさん、dicさん、そして管理人様のご意見も非常に参考になります。

私は、自分のソフトに対する批判コメントを読むのは非常～～～に億劫です・・・。
モチベーションをガリガリ削られてしまいますね、ネットは辛らつなものの言い方をする人が多くて（汗）
確かに、ソフトの改善すべき点がわかるのはいい事なのは頭ではわかるのですが、
ぼろくそに言われるとやはり傷ついてしまいます・・・。
ここはプログラムじゃなくてかなり個人的な問題なのでしょうけれど・・・。

それでは、私がプログラムを作っているときの過程を紹介します。
[Windowsアプリの場合]
１．アプリの機能を箇条書きにする。
２．アプリの画面デザインを紙の上に描く。
３．大雑把に必要なそうなモジュールやクラスとその機能を箇条書きする。
４．画面デザインを実際のＶＣ＋＋に設定する。
５．表示回りを最優先で作成する(やはり動いている事が分からないとプログラムを作るのが辛い)
６．機能を実装するのに必要なデータ構造を先に作成。
７．ソースコード上に実装する機能は先にコメントで出来るだけ細かく書いておく。同様に必要になりそうな関数も書いておく。
８．機能を実装、動かすを繰り返してバグを取りながら機能を盛り込んでいく。
９．１つのボタン、１つのコントールの機能を完成させてから次のボタン、コントールを完成させる。
って感じでしょうか。これから出かけるのでゲーム編も後でまた書きます。
まぁ、アプリとそう変わらないんですけどね。

ゲーム編で私なりの作り方です。書いてみるとアプリとだいぶ違いますかね。
[２Ｄゲームの場合]
１．ゲーム自体の企画を決める。
２．必要なツール、必要なデータ、必要な機能をざっくりまとめる。
３．ゲームに必要なデータファイルの構造を決める。
４．データを作成するツール、コンバータを作成する。
５．ゲーム本体の表示系を先に作成する。とりあえずキャラ表示優先。
６．まず自キャラ表示。続いてキー入力と自キャラの最低限移動。
７．背景マップの表示部分を作成。当たり判定とか背景のアニメとかは後回し。
８．背景の当たり判定やらスクロールの処理。アニメも入れれたら。
９．シューティングなら弾処理の作成、アクションなら自キャラ処理を作成。
１０．敵キャラの作成。敵キャラの行動パターンは後回しで簡単に動くもの。
１１．敵キャラとの当たり/ダメージ判定。
１２．敵キャラの攻撃処理。弾などの当たり判定を追加。
１３．敵キャラの行動パターンを必要に応じて追加。
１４．１ステージの完成を目標に雑魚ステージを完成させていく。
１５．ボスステージの作成。演出やボスは専用ルーチンで作成。
１ステージしか完成していませんが、ここで公開してみるのも手ですね。
あとは１３～１５を繰り返していくだけですが、作っていると基本機能の追加や手直しが途中で待っていたりします。そこをクリアするノウハウは数こなして覚えていくしかないのかなぁと思います。