超短納期開発（再掲）

１年半ぐらい前に別のページで書いたことを再掲します。
最近、ある開発現場に１ＰＧとして入っており、ちょっと色々と思ったことがあるので、それ絡みでちょっと書いておきたいことがあったので。
今から考えると？な部分もあるのでそれも見直していこうかな、と。

２、３ヶ月が短納期というならば、２週間〜１ヶ月で作るのは何て言うんだろう？ それも一昔だったら半年かけて作るようなものなんですよ。 １、２人で作るものだったら、方法が確立･･･というか、師匠と弟子の関係になってガシガシ作ればそれで済むわけですが、とにかく人数を入れて納期を稼ごうとする場合･･･、 色々と手段はあると思うんですが、 1.何が重要かの見定め 結局、全ての案件が等しく可用性や納期を求められているわけではない。 何が重要か考えること。 (超短納期の場合は大概が納期ですけども) 2.納期優先 時間をかければ出来そうな機能も「とりあえず」切り捨てるしかない。 足りない機能はカットオーバ後に継ぎ足すことを想定する。 例えば、人月６０万だとして、客がプラス１週間分の機能（１５万）をその値段を払って追加したいと思っているのか？ （なんかこう書くと安い仕事しかしていないみたいだ）。 メール配信機能が欲しい？１万円を切る価格でシェアウェアが手に入るのだよ。既にある機能との組み合わせで何とかなるものさ。 3.スキル別作業 「難」と「易」で作業を分けられるようにする。 業務ロジック部分（難）、プレゼン部分（易）、仕様を考える（難）、仕様を文書におこす（易）。 当然、モジュールの構成もそれを実現するようなものにする。 逆に言えば、開発者のスキルがモジュールの構成への影響要素となる。 4.プロトタイプが大事 スキル別作業にも関係するが、プロトタイプの作成が非常に重要になる。 デザインパターンなどを参考にし、他の開発者が差分を量産できるようなスタイルに出来ればがベスト。 要はどこまで作業を単純化できるか？ということ。 5.ドキュメントは最低限度に XPとかでも言われていることだけども、やはり「不要な文書は作らない」ことは大事。 ･･･関数仕様書とかはいらないでしょ、この際。追跡性を維持するだけで時間がとられる。 文書も予算に入っているのなら･･･、提供する文書は納品後にゆっくり作りませんか？ 6.テストにも優先順をつける テストもやはり出来るものから優先して行うとしなければ間に合わない。 個人的には表示色がどうのこうのとか、表示文字が間違っているとか、そういうノンクリティカルなものは後回しでまー大丈夫だろう、って思うことにしている。非開発者がテストを行う･･･ブラックボックステストとかも大事だけども、「最も仕様を理解している」主開発者がテストケースを考え（難）、それをシートにおこさせて検証してもらう（易）のがあまり時間もかからなくていいのではないでしょうか？ 7.マイナーな技術は避けて歩く （使ってるけども）PHPのPEARとか、本屋に並んでいないような技術はあんまり使うべきじゃないんじゃない？って思っている。 つーか、PHPってあんまり人集まらないね（集まったとしてもスキルにばらつきがある）。C#もまだあまりいないようだし。 ちょっと適当書きすぎたかなぁ。。。