受注開発のシステムで、受注から納期まで１〜２ヶ月程度、開発担当者は基本的に1名のプロジェクトに最もふさわしいと思われる開発プロセス、およびプロジェクト管理手法は何だと思いますか？もしかしてどっちも不用？
作成が必須なドキュメントはSRS（様の文書）、および取扱説明書のみとします。
根拠なくても構いません。説得力があれば！
思う存分持論を展開して欲しいです！！
よろしくお願いします！！
No.1
3784
185
20pt
バージョン管理システム CVS を使う
http://subversion.bluegate.org/doc/book.html
Subversion によるバージョン管理
一人ですよねえ…。だとしたらプロセスもへったくれもないような。
ソース管理だけはCVSでもSubversionでもVisual SourceSafeでもいいのでしっかりしておいて、あとはto do listベースのスケジュール管理でいいんじゃないでしょうか。
いわゆる「紙にやることリストを書いておいて終わったら×つけていく」やりかた。
あと
・要件管理も開発担当が行う？
・ユーザーさんへの進捗報告は？
・ドキュメントの作成は誰が？(ライターさんだったらかなり前倒しで〆切があるはず)
などによって作業量や必要なリソース、ずらせない日程などが変わってくるのでそこまで見通しをたててスケジュールをたてておくのがまずはじめの一歩でしょう。
No.2
33225
20pt
http://www.ogis-swe.jp/process/am-res/am/
アジャイルモデリング(AM)ホームページ
プロジェクト管理をしないことです。
そもそも、何故プロジェクト管理をするかいうと、認識を合わせる為です。
規模が大きいプロジェクトほど参加する人間が多くなり、伝言ゲームが発生し、各人で認識がずれる為にさまざまな開発手法、管理方法が発明されてきたのです。
今回は一人なので社内での認識合わせをするのは無駄です。無駄なことは極力排除しましょう。
ただし、顧客との認識を合わせる為の管理は必要です。
例えば、要求の管理、成果物の管理、進捗の管理は行う必要があるでしょう。
ご回答ありがとうございます！
顧客との認識を合わせる為の要求の管理、成果物の管理、進捗の管理は行う必要あり！
その他、基本的にはプロジェクト管理は不要！
やっぱ無いのかな〜
この手法をこんな感じで軽量化すればいいんじゃない？みたいなのないでしょうか…
No.3
3784185
20pt
http://www.atmarkit.co.jp/aig/04biz/wbs.html
WBS（work breakdown structure） − ＠IT情報マネジメント用語事典
基本的にはdev_zer0さんに同意ですね。
開発プロセスの定義やプロジェクト管理はちょっと乱暴ですが、複数の人間が好き勝手に動くのを縛ることが目的と言えます。
したがって一人で開発する場合はそういったことよりも自分で理解できる形に作業を分析して重そうなところはどこかとかリソースを使いそうなところはどこかとか(例えばテストサーバを使うとなれば環境を借りるなりセットアップするなりの時間を食うし、お客さんに説明するときは会議室というリソースを食う、なども含めると結構いろいろある)をチェックする作業のほうが重要だと考えます。URLはちょっと大げさですけど業務分析用語のひとつです(Microsoft Projectなどもこの考え方に乗っかっています)。
今回やったことを作業手順書にまとめるとか開発環境を整備して誰でもすぐ使えるようにするとかプログラミングスタイルを工夫して決めていくとかそういうことだけでも新人が来たときには役に立ちますよ。そういう地道な社内標準化が大事だと思います。
http://www.amazon.co.jp/exec/obidos/ASIN/4795296758
Amazon.co.jp： 人月の神話―狼人間を撃つ銀の弾はない: 本: フレデリック・P,Jr. ブルックス,Frederick Phillips,Jr. Brooks,滝沢 徹,富沢 昇,牧野 祐子
プロジェクト管理に興味があるならまずこの古典を読んでみては。
ここに書かれている「銀の弾丸はない」という言葉の意味は重いです。(この本では「人員を突っ込んだからといってそれだけで開発がうまくいくわけではない」という意味ですが、「人」を「あるプロジェクト管理手法」や「高級な開発ツール」に置き換えても同じことが言えますからね)
再回答ありがとうございます！待ってました！
WBSって聞いたことあるな〜って思って調べてみたら、RUPの方向づけフェーズとかで作ったりするやつですね。ってそれしか知りませんでした。
RUPの本も持ってないので詳細は知りませんでしたが、WBS自体独立していて、もっと歴史があるんですね〜。URLは参考になりました。
ちょっと調べてみようと思います。
人月の神話！
『今さら人を投入したところで工数も増えるし不具合を作りこむリスクも増えるしいいこと無いですよ！』って何度言ってきたことか…。そしてしぶしぶ納得って顔をされる…。
う〜ん、実務をこなしていくという観点においては、やっぱり開発プロセスやプロジェクト管理は不要って感じですかね〜
そこまで大袈裟なものではなくて、いくつかのツールの組み合わせで充分そうですかね〜
であればなんかそういったツールを紹介して欲しいな〜
新人を教育していくという観点においては、本当は一般的なプロセスとか管理とかを教えてあげたいんですよね〜。その新人さんがエンジニアとしてソフトウェアの世界で生きていけるように。
まあ、そこまで考えてあげる必要は無いのかもしれませんけどね。
これはちょっと矛盾した要求ですね。
No.4
50
20pt
dev_zer0さんが的確に答えていますので、蛇足です。
開発プロセスはマニュアルではありません。自分の仕事に合う物を選択して育てる物です。
言語のライブラリの様な物と言った方が分かり易いかもしれません。
必要な物だけを組み合わせて使いますが、理解していなければ組み合わせ様もありません。
新しい開発プロセスを導入するというのは、会社を構造改革する事です。
早くて２・３年後、普通５年後を考えて育てるものです。
私も１年くらい勉強していて、使えそうな所が分かって来たので、そろそろ出来る所から使ってみようと思っている所です。
ご回答ありがとうございます！
会社を構造改革！！
それは色々とありまして2年前に断念しました〜すみません〜
今はとりあえず自分のチーム内のみに適用するものを検討しています…。
おっしゃる通りですね〜
そのまま何らかの開発プロセスをあてはめることは考えてなくて、何かベースになるものとか無いかな〜って思ってます。
それがなかなか難しいんですよね…質問の条件のようなプロジェクトだと。
それにしても思うのですが、そもそも質問の条件にあるような業務をこなすちっさな会社って、ウチだけじゃなくていっぱいありますよね、きっと？
そういう会社（プロジェクト）向けの開発プロセスとかプロジェクト管理の手法、あるいは指針でもいいんですけど、あってもいいんじゃないかと思うんですよね。
例えそれが既存のツールの寄せ集めであったとしてもいいと思うんです。
確かに開発期間１〜２ヶ月のプロジェクトには、一般的な開発プロセスとかの運用の為のコストは、はっきり言って無いです。いかにライトウェイトなプロセスと言えども。
ドキュメンテーションって言ったって最低限のドキュメントを作成する時間しか確保できないです。
でも最低限の品質を維持していくためにも最低限の“何か”が必要になるわけで、それをちっさな会社では必要としていると思うんですよね〜
ちっさな会社だとこのへんの知識や技術が会社には蓄積されにくいです。大きな会社よりもずっと個人に依存しがちです。
なのにそれを自分たちで考えて取捨選択しなきゃならない現状って、厳しいと思うんですよね。
自分も考えてはいますが、なにぶん一人きりなので…。広くご意見を伺って見たかったんです。
甘いと叱られるかもしれませんけど、せめてはてなでは甘えさせてっ！！
あ、これ以降、同じようなちっさな会社にお勤めの方に限り、御社の設計手法・管理についての回答も受け付けたいと思います。ちょっと趣旨が変わっちゃうけど。
No.5
50
20pt
http://www.amazon.co.jp/exec/obidos/ASIN/489100455X/250-8145385-...
Amazon.co.jp： Code Complete第2版〈上〉―完全なプログラミングを目指して: 本: スティーブ マコネル,Steve McConnell,クイープ
プログラムを組む事に関しては、この本以上にノウハウを蓄積させた物は無いのではないでしょうか？
私も10年遅れで今読んでいます。
ご回答ありがとうございます！
コードコンプリート！
私の所有する技術書の中で一番分厚い本です。全然読んでません！！（そんなのばっかり…）
今パラパラと見てみましたが、確かに有用なトピックとかツールになり得る情報が沢山入ってますね〜
しかも実践的だし。
必要としているのは確かにこの辺の情報なのかも知れません。
ちょ、ちょっと…読んで…みようかな…
----------------------------------
結論までは至りませんでしたが、質問を終了させていただきます。
のっかり頂いた匿名様はご満足いただけましたでしょうか…。
44
44
2
1
2
ご回答ありがとうございます！
プロセス不要！
とりあえずソースのバージョン管理は怠るな！ということですね！？
あとはスケジュールを立ててマイルストーンを見極めたら細かいことは気にせずどんどん作るべし！って感じでしょうか。
・要件管理も開発担当が行う？
→はい、開発担当者が！
・ユーザーさんへの進捗報告は？
→これも開発担当者が！
・ドキュメントの作成は誰が？
→もちろん開発担(ry
つまり、ちっさなソフト会社でってのがベースにあります。
そういう会社では、一人でなんでもしちゃうんです。それこそ営業から保守まで！！
大きい会社だとその会社なりのやりかたって、ドキュメンテーション含めて大体決まってたりすると思うんですけど、ちっさい会社って無かったりするし。
そもそもふさわしいと思われる手法ってあるのかな？ってのがこの質問の主旨です。
それともう一つ、こういう小さな会社にも新卒の新入社員とか入ってくるんですよっ！あぁぁ…！
彼らにソフト開発・管理を教えて育てていくのにも、ベースになるようなプロセスとか管理手法とか必要だと思うんですよね！