趣味のプロジェクトをきちんと仕上げるには? 68
ストーリー by soara
モチベーションがあるうちに短期決戦に持ち込む 部門より
モチベーションがあるうちに短期決戦に持ち込む 部門より
pinbou 曰く、
ベテラン・プログラマ、カルロス・タサダ氏のブログ記事「Is it possible to finish a hobby project?」が興味深い。いわく
金をもらってやるプロジェクトだと、完全なロードマップや納期もあるし、プロジェクトに集中することになる。しかし趣味でやっているプロジェクトは完成したためしがなく、品質にも納得したことがない。なぜだろう? 思うに以下のような問題がありそうだ。
- 自分に最もアピールする機能にばかり目が行って、他のところに手が回らない
- 落ち着いて作業できる時間、まとまった量の時間をプロジェクトに割けない
- 外部からのプレッシャーがない
- 新技術の練習として、実験的に同じプログラムを違う言語やライブラリで実装することが多い。よって、機能的には進歩がない
これに対する処方箋として次のようなものはどうだろうか。
- 最小限の機能セットを定義し、そこが終わるまでカッコいい機能の開発には取りかからない
- 休暇や週末など、まとまった時間を割ける時だけ手をつける
- 自分でデッドラインを設定して、達成したら自分にご褒美を出す
- 実験はほどほどにする
/.Jの諸氏は、彼と似たような問題を抱えていないだろうか? 何か工夫や経験談があればシェアしてほしい。
他人の目 (スコア:4, すばらしい洞察)
一番いいと経験上考えます。
他人の目は、フリーソフトとして公開できるところまで行かなくても、友人に
なんとなく見せるだけでも大丈夫です。
友人に見せることを前提にすると、どこがいい加減でよくて、どこが無いと
いけないかは自ずと決まってきます。枝葉が実装されてなくても言葉で説明できる
部分は説明で済ませても、見せたいものの本質は伝わりますし。
あとは、自分で再利用する場合を想定しても、手を抜けない部分がある程度
見えてくるかな。
タレコミの主旨とはずれるけれど、趣味の場合、キッチリ仕上がっている
必要はまったくないと思います。
Re: (スコア:0)
公開するとあーしろ、こーしろとうるさくないですか？
GPLと書いてあっても、自分でやらない人が多い。
この間なんか、コンパイルの仕方を教えろというメールが
しつこくきて、いやになった。
Re:他人の目 (スコア:1, 参考になる)
ダウンロードするところにも書いてあるから、来たメールは読まずに保存ボックス行きだね。
読むのは次回のアップデートの直前。
そしてフィルタリングソフトを通すからNGワードが入ってるのは読まずに削除。
あと、件数が多いメール元のも削除だな。スパム扱い。
Re: (スコア:0)
Re: (スコア:0)
＃でも、「こーだったらいーなー」くらいは許してね。
Re:他人の目 (スコア:1, 参考になる)
>よほど便利なものや「それしかない」ものを公開しないと、
>あーしろ、こーしろなんて言われないと思うんですが。
甘い。
「それしかない」のかどうかを探索する目が脆弱な人は、
いちど食いついたソフトに拘泥する。
「ほかのソフトに」欲しい機能を求める旅をやめ、
「そのソフトに」その機能が付くまで粘着する。
あと、それとは別の問題として、
Aにbという機能が無くて困っているとき、
逆にBにはaという機能が無いからBに乗り換えてもやっぱり困る、という場合も結構ある。
「aとbの両方を実装してるモノが欲しいな」と。
この場合
Aの作者に言うのと、Bの作者に言うのと、どっちがいいんだろうな？
(自分でCを作るとか誰かに作らせるとかって手も有るが、更にハードルは高いだろう)
>（どれくらいを「最低限」とするかは、まさしくソフトウェア本体の機能をどれくらいをもって「最低限」と定義するか、というのと全く同じ問題です）
私のドキュメントについての印象はちょっと違うな。
「親切なユーザ」というものが居るような気がする。
「親切なユーザ」はDocがオタクくさく記述不足でも自力で補完して読み取ってくれる。
そうでないユーザはやたらめったら懇切丁寧に「前提知識が皆無でも(おいおい無理言うな！)」わかるように書かないとキレるか使うのを止める。
自分の経験では困ったことに職場で後者に出くわすことが多かった。
業務(といってもソフト屋ですから周囲も専門家のはず)をちょいとだけ改善するようなものを自発的に作って(少なくともコア機能はきちんと動く状態で)出すということをよくやるんだが、
初心者かいな？と首をかしげるような要求ばかり突きつけられて、
そこまで作ってられんわ！という状況になることが多い。
結局業務は改善されんorz
「頭のおかしい人」は職場にも結構居たりする、と。
Re: (スコア:0)
>必要はまったくないと思います。
全くの余談ですが、これを読んで「天邪鬼なソフト」のアイデアがひとつ。
例：save機能の無いエディタ。(書ければいいじゃないか！と割り切る)
趣味に走るとこういうのもアリだな！っと。(w
Re:他人の目 (スコア:1, 興味深い)
意味もなく、アラビア語の勉強なんて始めてしまったり・・・。
それからすると、保存機能なんてゴミだな。
Re:他人の目 (スコア:1, おもしろおかしい)
飾り文字の種類やらを競っていたころ．一通り書けるけど，保存できませんってやつ．
あと，書いたソースやコードを保存できない統合開発環境お試し版もあった気もする．
いくらお試しでもプログラミングでそりゃ無いだろと思った．
Re: (スコア:0)
結構前からありますよ？ [xrea.com]それ。
出来たところが完成形 (スコア:2, すばらしい洞察)
Re: (スコア:0)
サブジェクトだけしか書いてないけど本当にそうかもしれないと思う
自分も趣味のプロダクトをいくつかやっているのだけど、完全な完成ってあり得ないとしか思えないんだ
作り終えたらそれをもっといじり倒したくなるというか、次を目指してしまうと、今完成した物が中途半端な物になっちゃう
実は仕事でもちょっとこの状況が発生することがあってものすごく悩んでる
プログラムに限らず、なにか設計を込みで作る物だと再設計とか改良って常に存在すると思うんだ(設計前の自分と製作後の自分の間の成長とかを勘案しても)
#自分が未熟なだけなのかもしれないけど、せめて自分が作成中に成長したと信じたいけどな
#生涯一学徒を胸張っていえる位すごいならいいんだけどなぁ
Re: (スコア:0)
>生涯一学徒を胸張って
まったくご尤も。
結局のところ多くの人は、
学徒でい続けるための十分なリソース(を産むための能力)が不足してるがために、
どこかの時期で学徒を「退学」せざるを得なくなってしまうんだよね。
悲しいことだが。
つまり生涯一学徒を貫くためには能力が必要。(それ以外にも色々ね)
ヘビーではあるが、男子が(女子も歓迎！)一生を賭けるに値する話ではあると思う。
要求仕様が不定だと完成も不定になる (スコア:0)
どのくらい一般的にそう言えるのかわかりませんが、個人的にソフトを書くきっかけって、
・「～をしたいけどできるソフトがない」という自分の需要（または知り合いの依頼）
・単に「～をするソフト」を作ってor勉強してみたかった
のどちらかが多いような気がします。
だとすると、前者のきっかけで始めた場合、需要とリソースを天秤にかけながら要求仕様を設定することが（実際に設定するかどうかは別として）でき、それを満たした時点で「完成」です（仕様変更がないとは限らないけど）。後者の場合は「ここまでできればOK」というラインが最初からありません。
あとはあれですね、他人の需要を満たすためのソフトとか、外部の仕様に従って動くソフトの場合、自分だけのために作る場合と比べて仕様変更が頻繁になりがちなので、逃げ水的に「いつまでたっても完成しない」可能性はありますね。画像をリサイズするソフトを作ったら減色もできるようにしてくれと言われた（対応しないのも手だけど）とか、ブラウザのアドオン作ったらブラウザの仕様が変わったとか。
#このコメントもt/oにした方が粋だったかしらね
仕事のプロジェクトはきちんと仕上がってる？ (スコア:2, おもしろおかしい)
タレコミを読んで
そうか、この人は仕事のプロジェクトはきちんと仕上げられてるんだ
と羨ましくなった奴は手を上げろ！
ﾉｼ
本職がデスマーチにならないこと (スコア:3, すばらしい洞察)
が必要条件だと真っ先に思いつきました。
そら日本発のオープンソース プロダクトが少なくなるわけだわ。。。。
Re: (スコア:0)
モチヲじゃあるまいし、趣味のプログラムとオープンソースに何の関係があるんですか。しかも隣のストーリーはLinuxカーネルの大部分は企業が開発している [srad.jp]だというのに。
Re:本職がデスマーチにならないこと (スコア:3, すばらしい洞察)
＞しかも隣のストーリーはLinuxカーネルの大部分は企業が開発しているだというのに。
その発言の裏は、「Linuxを開発しているのは企業ではないという固定観念がある」ということですね。
それに何よりLinus氏がLinuxを開発したのは趣味だし、Matz氏がRubyを開発したのも趣味だよねと。
ビジネスになった『後』なら企業も参入することは珍しくないけれど、
ビジネスになる『前』に開発者動かすを原動力は、「それが僕には楽しかったから」。/ [amazon.co.jp]
Re: (スコア:0)
>金をもらってやるプロジェクトだと、完全なロードマップや納期もあるし、プロジェクトに集中することになる。
なに言ってんだ？学生さんか？と思った人も挙手！
Re: (スコア:0)
（念の為に言うと税金ね、やることがなくぶらぶらしてた最低のプロジェクトだったのでうらやましいなどと言わないように）
オープンソースにすればいい (スコア:2, おもしろおかしい)
きっと誰かが完成させてくれる。
Re:オープンソースにすればいい (スコア:3, 興味深い)
オープンソースプロジェクトは、始めた人が「使えるレベル」まで自力でもっていかないと成功しない、とどこかで聞きました。
しかし、ソースコードを公開しておくことには意味があります。人の要望を却下するとき、「ソースコードは全部公開しているから、どうしてもというなら自分でやってね」という気持ちになれるのは、僕にとっては大きいです。興味がなくなったら、ソースコードが公開されていることを言い訳にして、いつでもやめるつもりですし。
それと、ソースコードを公開しておくと、ひょっとしたら誰かがこのコードを使ってすごいソフトを書いてくれるかも、という期待だけは持てます。今の僕にはこの方が、宝くじを買うよりよほど夢があって楽しいです。
は？ ムリムリ (スコア:2)
お金をもらって仕事してやっているプロジェクトすら満足にできないのに、
利益もでないようなことがまともに出来るはずがない。
と、自分のことを思い出してそう思った。
「完成形の一つ」を目指す (スコア:2)
趣味だから完成しなくても誰も怒らないんだけど、でも「完成」させたいってのはわかります。僕もそうです (大したプログラムも書いたことがないくせに偉そうに)。
小さい頃は、「完成」というのはこれ以上いじる点がないことだと思っていました。「まだいろいろ追加したいことはあるけど、ひとまず完成」なんてのは欺瞞だと思っていました。
でも、今の僕は「ひとまず完成」を受け入れるようになりました。改善するべき点があっても、ソフトウェア自体が成立していれば OK。僕が公開するソフトウェアではこの状態を目指しています。
僕は Firefox 用の拡張機能 [mozilla.org]を公開しています。追加したい機能はありますが、今のバージョンは機能の面では「ありうる完成形の一つ」だと思っています (実装にバグがあるのは別問題)。
このように今のところ完成させることができている要因には、次のようなものがあります。
一方、こっちの Greasemonkey スクリプト [userscripts.org]は、こちらも完成形の一つというつもりで公開したのですが、根本的に考えから抜け落ちていた部分があった上、簡単には直せないので、中途半端になってしまっています。「バグ」と呼んではいますが、実装のバグではなくて設計ミスです。完成していなくて良いというつもりで出したつもりではなかったのですが。まあ、直す方法を思いついたら直します。
目的を持つこと (スコア:1, 参考になる)
ＤＴＭだったら「ニコ動で公開する！」(笑)
目的を持てば達成はできるはず。これは私の体験談です。
え、応募＆公開した後の結果？ 聞かないでくださいよ、あはは……（苦笑い）
Re:目的を持つこと (スコア:2)
自分の場合、ちゃんと完成した趣味ソフトはどれも最初に仕様書を書いていました。
ゴールが明確になっていること、どんな機能を実装すべきか見えていること。
これ大事だと思います。
＃もっとも、最初に仕様書書いたけど完成しなかったソフトも多数。
Re: (スコア:0)
私が(ある意味で：ほかのプログラマに部品取りしてもらえたという意味で※)一番気に入ってるソフトは、ステートチャートを添付していました。これこれこうするとこういうふうに状態遷移するんだよ、というアレ。
チャートを描いたことがよかったかどうかは謎ですが、
チャートが綺麗に書けるくらいに状態の扱い(の構造)がきちんとしてたという点は、やっぱりプラスだったんだろうなと想像してます。
※もちろん、自己申告でそういうかたが居た数、でしかないですが。
>最初に仕様書を書いて
ところで仕様変更はどうしてます？
まさか趣味でもWaterFallみたいに「一度決めた仕様は変えない」な
テスト＆ドキュメントがめんどい！ (スコア:1)
ちょうど作ってる最中だけど、コーディングはともかくテストとドキュメント作成が面倒。
それに、ユーザがどの程度利用してくれるか解らないからモチベーションの維持が難しい。
モチベーション維持できたら来月中頃には完成すると思うので、良かったら見に来てください。
ちなみに致命的なバグがいくつか...
Web Database Mímisbrunnr [appspot.com]
Re:テスト＆ドキュメントがめんどい！ (スコア:1, おもしろおかしい)
私の場合 (スコア:1, 参考になる)
・第三者の意見が聞ける→適度なプレッシャーになる
・アドバイスがもらえる→サンデープログラマーなので技術が大分向上しました
・上と被りますが自分では考えもしなかった機能やアプローチを教えてもらえる
・感謝の言葉がもらえる→モチベーションが保てる
・デバッグ要員の確保→複数環境でのバグの洗い出しが無料!
・自サイトを持っている時に比べてクレクレや教えてが少ない→勝手に周りが叩いて減っていく
・メールアドレスを公開しないのでスパムがこない
殆どメリットばかりだったのですが、ある日無断かつパッケージを改変されて雑誌紹介+付録に収録され(しかも表紙に煽りコメント付き+広告を除いた2ページ目だか3ページ目の見開きカラー)「作者は出版社から金を貰ってる」や「雑誌向けに専用版を作ってる」などと嫌儲の方々に根拠の無い憶測で叩かれ嫌気がさしてコメントを残して一切の公開を辞めてしまいましたが・・・
だらだらと中身の無いことを書きましたが、結論としては外部から「適度」なプレッシャーをかけてもらうのが一番な気がします
余談ですが、過去いくつかのツールやソフトで数回雑誌掲載された中で匿名+無断で載ったその時が一番扱いが大きかったのは微妙に凹みました、ライターの意見も提灯記事なみに好意的な書き方だったのも追い打ちをかける始末・・・
Re:私の場合 (スコア:2)
法の素人です。
ライセンスで禁止と書かなくても、許諾していなければ複製権等の侵害だと思います。 #1627692 [srad.jp] の人もおっしゃるように、訴えて勝てるか以前に、普通は訴えるコストが大き過ぎるので訴えないわけですが。
公開した際に匿名であっても、後から被害届を出したり訴訟を起こしたりすることは可能です。自分が作ったことを証明できなければ「何言ってんだお前」で終わりでしょうけれど。
なお、著作権法違反は (今のところ) 親告罪なので、被害届なしでは警察は動きません。「匿名で公開していたソフトを雑誌に無断で改変・収録された」という場合に、被害届を出せば警察が動くかどうかとか、非親告罪化したら何もしなくても警察が動くかどうかは、別問題ですが。
何がしたいのかが問題 (スコア:1)
・コンピュータを使って「何か」をしたいが、それを達成するためのソフトがない(あるいはあっても高価)。だから自作する。
・プログラミングを楽しみたい。
もちろん両立する幸運な事態もあるとは思いますが...。
> 新技術の練習として、実験的に同じプログラムを違う言語やライブラリで実装することが多い。
これは明かに後者の態度ですよね。前者だけの目的には不要ですから。
個人的な経験から言わせて頂くと、前者の目的があれば完成できます。もちろん「自分にとっては使いやすい」という意味だけで他の人にとっては「謎の仕様」のソフトとなる可能性は大ですが。私の場合、誰にも公開していない「自分にとっては使える」という意味で「完成」したソフトが何本もあり、時折バージョンアップもしています。何を以って「完成」というかというのもありますが、完成させるためには「他人に見せる」のが重要ではないこともあります。
ちなみに、私が完成したことのあるソフトは特定の複数の種類のパズル作成支援ソフトです。自作のパズルに別解がないことを検証したりとか。ある条件を満す問題を検索したりとか。こう言った類のソフトは(詰将棋のような比較的多くの人が触れるパズルを除いては)普通ないので欲しければ完成するまで自作するしかありませんから。他には、アウトラインプロセッサ(アウトラインエディタ？)が欲しくて自作して、結構自分では使えると思うレベルまで行ったのですが、OmniOutlinerの存在を知って開発を辞めました。今ではOmniOutlinerを使ってます。
長々と書きましたが、「欲しいから作る」のか「作りたいから作る」のか、それが問題だと思います。
Best regards, でぃーすけ
Re: (スコア:0)
>長々と書きましたが、「欲しいから作る」のか「作りたいから作る」のか、それが問題だと思います。
結論は頭に持ってきてください。
長々と文章を書いている間に、
・書くべき事を忘れる
・結論を見失う
・他にレスを付けたいコメントを見つけてしまう
などのプロジェクト完遂の阻害要因が多く発生します。
結論だけ付けて書き始めればあとは何とでも締められますから。
私の場合 (スコア:1)
私の場合以下の3つに気をつけてプロジェクトをはじめました。
割とうまく言ってる気がしてます。
ブログに作業状況を書くこと。
自分にとって必要なものを作ること。
完成が遅れたとしても、時代遅れにならないものを作ること。
多分無理 (スコア:1)
最初からきちんと仕上がらない事を前提にしている時点で「既に無理」だと思います
「2chで宣言」するのはまあ効果的かもしれませんが、
それは運よく？話題になった時の話ですよね
でもまあやらないよりはマシなので、
・実名もしくはそれに近い名前で、当然トリップ付きで
・何年何月何日までにどういう機能を仕上げる
最低でもこの2点を明確に宣言すればいいと思います
要は「自分を追い込む」事ですね
＃ドラクエやFFだって延期しまくるんだから、期限の無い仕事なんて永久に終わりませんよ
別に何もしない (スコア:0)
そうでないのなら欲しいものじゃないってだけのこと。
つまり、そんなに欲しくないものなのだから、仕上げる必要なんてない。
ただ、経験した情報はその都度きちんとまとめておくと後から参照するのに便利。それは言える。
Re: (スコア:0)
アイデアの段階でつまらないので現実化するに従い興味が無くなる。
既存のモノでは満たせない(not= 高度)要素が1つ位は入っていないとモチベーションなど続く訳がない。
Re: (スコア:0)
つまりそれは本当に欲しいものではなく、漠然としたもの。
それだけのことだ。
趣味なんだもん (スコア:0)
楽しくデスマーチを続けさせてよ。
なぜ、気づかない (スコア:0)
おそらくそのソフトは自分にとって真に必要なものではない。
況や他の人をや。
そもそも「カッコいい機能」とか言ってる時点で終わっている。
そういったものは利便ではなく見栄を提供するものだからだ。
Re: (スコア:0)
「真に必要なもの」かどうか事前に知る方法を書いてくれたら生産的なんだけど。
Re: (スコア:0)
必要かどうかなんて当人にしかわからない。
昔はともかく近頃は趣味でやってるものなのに周りの目を気にする手合いが多い。
自分のためにやっているはずなのに、なぜか一般へ公開することが前提になっている。
それは妙な下心があるからだ。
そんなものが先行していたらうまく行かなくなるのも無理はあるまい。
Re: (スコア:0)
>妙な下心があるから
違うな。というかそういう面も有るがそういう面に限るものではない。
悟りの化け物って民話を知らない？
人間は「自分がしたいことすらナカナカ判らない」生き物なんだよ？
今まで自分についてソウいうことを感じたことが無いのだとしたら、
むしろ今までの自分(のやりかた)が「枠に収めるようにコジンマリ」していたことの証拠だ。
それは人としてはちょっと悲しい状態だよ。
>ご自分の胸に聞かれては
今の自分に聞いても無駄さ。
3日後の自分は他人っていうだろ？
3日後の自分はまた新たな答えを持っているものさ。
もちろん4日後もまた違う答え。
才能 (スコア:0)
才能がないやつはそういうところで迷わない
生まれ持った差だからあきらめれ
Re: (スコア:0)
途中で投げ出さないためにも (スコア:0)
明確なゴールと期限を定めるしかないんじゃないかな
マイルストーンでもいい
その時間で完成できるゴールを決める (スコア:0)
その都度成果が上がっていれば達成感が味わえますし、
そのぶんモチベーションも維持できます。
半端なところで中断していると、その時点でなに考えてたか忘れますし、
いつまでも形が見えてこないと、そのうち飽きてしまいます。
大きい作業は、ゴールを分割していきます。
私の場合、最初の立ち上げだけは時間を作ってとにかくなにか動くところまで一気にやってしまいます。
あとはちょっとずつ取れる時間の分だけ拡張してますね。
Re: (スコア:0)
年末年始、ゴールデンウィークがチャンスですね。
# プライベートでプログラムを組むなんて言うとバカじゃね？って顔する奴ばかりだなあ・・・はぁ
2chで宣言する (スコア:0)
これで後には引けない。
趣味だからそれでいいじゃん (スコア:0)
その処方箋みたいなことをしたら、「仕事みたいにつまらなく」なるのがオチじゃん。
忌避するに限るね。
アピールしたい機能以外なんていう退屈なもの、作りたくなくて当然じゃん。そのせいで実用性が下がったとしても「これはコンセプトモデルだ」と言えば済むこと。「このコンセプトを披露したいのだよ！」とね。
こういうチマチマした悩み方をするのは日本人ばかりであってラテン系は悩まないのかと思っていたが、案外世界はアレだな。
完成や品質については、それこそ「こまめにリリース」でいいじゃん。今日満足してなければ今晩書き足して明日満足すればいいんだよ。それでもダメならそのサイクルを毎日繰り返せばいいんだよ。
なお、この件についてもうちょっと言い添えるならば、
自分と他人の両方のタメにも、公開は単なるファイルアーカイブじゃなく、バージョン管理リポジトリ単位での公開とするほうがお洒落だぞ、と言いたい。
>最小限の機能セットを定義し
その定義という行為じたいが自分の快楽行動に直結してるなら、しても構わない(というか、しろ)。そうでないなら、そんなもん無視すべきだ。
そうでなければそれはもう趣味ではない。ただの苦役だ。
たとえば、オブジェクト指向設計(分析)は、多くの人にとってはビジネスライクな苦役でしかないようだが、俺個人にとっては「趣味」なので、趣味でもヤル。むしろ「このモデルいかすだろ！」とか一人でニヤニヤしながら考えたOOモデルを披露したいがために実装を作る節すらある。それで出来上がるものはいわゆる綺麗なクラス階層を持つOOフレームワークとかになる。
いっぽうネットワーク関係やWeb関係は全く趣味から外れるので、趣味プロでは一切やらない。
＃札幌のRuby逆引き本レシピ本紹介イベントにいってきたのでAC
＃ネットワーク関係のライブラリは、それを(趣味で)作ったかたがたのをありがたく使わせて頂くこととします。
>実験はほどほどにする
よくわからないな。
趣味は人それぞれといえばそれまでなんだが、俺の感覚だと、
実験が快楽行動になって「いない」人がプログラムつくりを趣味と呼べるんだろうか？と
疑問に思ってしまう。