開発を進めていく場合、いくつかの重要なポイントがあります。
メンバー間のコミュニケーションは重要です。互いの認識にずれがあると、仕様どおりでないものが出来上がったりし、統一の取れていないものができあがったりします。その訂正のための工数がかかります。また互いの仕事を把握していれば、作ったものを共有化したり、使いまわしたりすることができます。また、わからない点を教え合うことで、開発の速度も上がります。それからメンタルなものも重要です。
仕様を決める際に、プロトタイプを作って、動作を模擬的に確認するのは、顧客との仕様の食い違いを防ぐために必要なことです。プロトタイプを使い捨てにしないために、プロトタイプで確認したものをそのまま開発で使えるようにすると工数を減らすことができます。
通常、要件定義、設計、実装と進んでいき、プログラマは実装の段階から入るのが多いのですが、実際、開発を始めるには仕様を理解しておく必要があるため、できれば仕様策定の段階から加わるのがいいです。また数人は、要件定義の段階から加わり、技術的な問題点をつぶし、開発のためのフレームワークの選択や規約の策定をして、開発の準備をしたほうがいいです。
開発の方針や規約を決めておきます。Strutsなど既存のフレームワークを使う場合でも、さらにその中で枠組みを決め、共通クラスを作ったり、コーディングの仕方を決める必要があります。
そして、そのフレームワークの仕組みとソースの実装方法は、後から入った人でもわかるように、きちんと開発手順書という形で文書化しておきます。
フレームワークについては、こちらでも述べています。
未経験の分野は、何かとネックとなる可能性があります。できれば仕様詰めをしている間に、技術的な問題はつぶしておきます。というのは、仕様が決まってから、技術的に不可能だったり、やたらと工数がかかることがわかっても、後戻りできないからです。仕様詰めをしている最中であれば、そのネックとなる部分の仕様を変更することも可能ですし、工数を見積もることもできます。
この辺は、優秀なプログラマを割り当てて調査させるといいでしょう。
ある機能を実現するとき、できることなら自前で用意するよりも既存のライブラリを利用する方がよいです。利用実績があればあるほど信頼度が高く、非正常系についても十分考慮されています。しかし中には結構貧弱なものもあります。あってもよさそうな機能がなかったりします。その場合自分で作成します。ただすでに同様のものがあるのに自分で作った場合はあまりいい評価を受けません。できるだけ既存のものを使い、使い勝手が悪い場合は、プロジェクトの中で使いやすいように、ラッパーで包みます。
あと他のライブラリのごく一部のみを使いたいとき、全体をインポートするには大きすぎる場合があります。そういう場合は、オープンソースであれば、必要な部分だけ切り出して持ってくるというのもいいかもしれません。
時々、大きなプロジェクトで驚かされるのは、あるべきドキュメントがないことです。中には平気でうちはドキュメントレスの会社だと言ってくる会社もあります。設計に関する知識はすべて人の頭の中にある、ということになり、新しい人は、聞くか、あるいは知らずに作るしかありません。
また大きなプロジェクトで、その中でいくつかのチームに分けられ、それぞれがドキュメントを管理している場合があります。それらのチームの成果物の間に連携がなければいいのですが、共通部分が大きいにも関わらず、ドキュメントが一元管理されていないことがあります。
またドキュメントの書き方もいい加減で、実装段階で変えられてしまっているものもあります。
ＤＢ設計のＥＲ図や画面設計の画面遷移図などは全体を俯瞰する上で必要なものですが、そういうものを全く作っていないプロジェクトもあって驚かされます。
開発する上で必要最小限のドキュメントはそろえておく必要があり、一元管理しておく必要があります。
プログラムが設計どおりに作られることはまずありません。それは技術上の問題で、その通りには組めなかったり、その通りにすると問題が発生するなどで、実装が変更になる場合もあれば、追加・修正要件が入って、修正する場合などがあります。
ドキュメントはデータベースではないので、データの正規化は図られていません。同じことが複数のドキュメントに記載してあれば、一個一個すべて直していく必要があります。
ドキュメントの修正は厄介な作業です。開発中にいちいち同期を取る作業を行っていたら、いくら時間があっても足りません。仕様書や設計書は、仕様や設計を決めるための、使い捨てのメモ書きに過ぎないと考えて、修正は保留します。ある程度の仕様が固まったら、仕様の変更履歴のドキュメントに追記していくようにして、元のファイルは修正しないようにします。途中で客から提示を求められても、元ファイルと差分のみを示します。そして最終的に、製品が完成し、これ以上仕様に変更は入らないとなった段階で、変更分をドキュメントに反映させるのです。ただこの作業はあまりにも厄介なので、記述漏れがどうしても出てきます。「ドキュメントには嘘が書かれている。ソースを読め」と言われるのも、こんなところに原因があるのでしょう。
できれば、仕様は、データベースに入れられるのがいいのですが、そういうアプリケーションもあるようですが、あまり広まっていないところを見ると、適用が難しいのでしょう。
ドキュメントについては、こちらでも述べています。
ＸＰのプラクティスによると、週40時間労働がよいそうです。残業をせず、きちんとリフレッシュして、仕事をした方がよい仕事ができるということです。とはいえ、なかなかこの原則を守るのは難しいです。アプリケーションの設定やバグの調査であっという間に数時間は簡単に経ってしまうからです。またリリースまでまだ余裕があるからといって、マイペースで定時帰りをしていると、後のシステムの結合の段階で問題が発覚して、途端に終電帰り・徹夜ということになりかねません。定時帰りでプロジェクトを予定通りに完了させるというのはなかなか難しいことです。
開発環境で正常に動いていたものが、運用環境に入れた途端全く動かなくなったというのはよくあることです。単なる設定の問題もあれば、OSやハードウエアに依存する問題もあります。同じアプリケーションでもOSが違えば動作が変わる場合もあります。
開発の環境は、運用環境と合わせることが重要です。Javaを使っていても微妙なところでは依存する部分があります。ハードウエアを同じものをそろえるのは難しいでしょうが、OSは同じものを入れたいものです。x86で動かないOSはなかなか予算の関係上入手するのが難しいかもしれません。UNIX系はLinuxである程度代用することができるかもしれませんが、可能な限り合わせるようにします。
ソースは、CVSやVisual Source Safeを使って共有します。共有したファイルは、担当者を中心に更新していきますが、開発前に全最新ファイルをダウンロードしてきてから行います。この際、上書きされないように、ローカルの自分の担当のファイルはアーカイブしておきます。開発中他の更新ファイルに問題がある場合は、前のバージョンに差し戻します。不用意な更新が行われないようにルールを決めておくのがいいでしょう。リリース時のバージョンは別途取得して、アーカイブしておきます。
各人が使い慣れたものを使うのもいいのですが、できるだけ統一した方が環境を容易に移せるので便利です。できるなら、配置するディレクトリの位置などもきちんと決めておいた方がいろいろな設定も共通化できて便利です。Mavenなどのツールを使うのもいいかもしれません。
もとがWindows系の人はGUI、UNIX系の人はCUIを好みます。GUIは扱いやすくいろいろと便利なのですが、開発者やインフラ構築する人にとっては、テキストベースの方がよかったりします。というのは似たようなコードや設定を行うためにコピーアンドペーストを多用するからです。設定情報を簡単にバックアップを取れて、編集もエディタでできるのもCUIのいいところです。もちろん、GUIでも、インポート、エクスポートやテンプレートの登録などが充実しているならGUIの方が扱いやすいです。GUIは見易さ、入力ミスを減らす、設定を覚えていなくても設定できる、などのメリットがあります。一方テキストは柔軟性に優れているし、最終的にプログラムが参照するものに対して直接的です。要は、どちらが効率がよいかです。
ただ概して、Windowsの設定のように最初からGUIが提供され、基本的にGUIを通してのみ設定をするような場合はいいのですが、最初テキストで出ていて後からGUIで便利に設定できるようなツールが出てきた場合は要注意です。結構貧弱でバグがあって、GUI上からは修復できなかったり、設定できない項目があったりするからです。こういう場合、最初テキストで覚えて、GUIが便利であるならGUIを使えばいいでしょう。