私的なメモです。自分以外の人にとってはあまり役に立たないと思います。 メモというより独り言になっている部分もありますが、今更編集しなおすのも辛いので軽くスルーしてください。 また、同じような内容が繰り返し記述されている可能性もありますが、まとめる気力がないのでスルーしてください。
現在ナッシングです。
可能であれば、各画面の詳細設計書のレビューは関係者全員で行うべき。 関係者全員＝メンバー全員というわけではもちろんない。 関係者＝レビューに参加して意味がある人。 時間がないとかで最小限の人とかだけでレビューしたり、そもそもレビューしなかったりすると、後々大変なことになる（大抵作り終わってから）。 で、どうあがいても大抵全員不幸なことになる（こっちの画面の動きをそっちに合わせるとか、 大抵はコーディング前に分かってれば大したことないような事）。 関係者全員の意識合わせも兼ねて、詳細設計書のレビューは関係者全員で行うべき（コーディングに入る前に）。
後、全体の動きを合わせるのがアホらしいと言う意味では、共通化されていないソースも同様。 共通化できるコードは出来る限り共通化させるべき。 やることは一緒なのに各画面でバラバラに実装されていると普通は絶対に同じ動きにはならないし（コードが違うので当たり前と言えば当たり前だが）、 それを同じ動きにするために書き換えたとしても、後々の修正、メンテが超大変になる。 最初に書いた本人はある意味楽だけど（他のこと考えないで良いので）、そのコードをメンテする人はアホらしいほどの労力が必要となる。 また、共通化→個別化は比較的楽だけど、個別化→共通化は相当な労力が必要。 相当な労力が必要となる前に（実装する前に）、共通化できるコードかどうか検討すべき。 共通化で実装した後に個別化で対応しなければいけない状況になったら、 その時に（共通化のコードをコピペして使うなりなんなりして）個別化対応すれば良い。 ただ、汎用的な関数とかはプログラマーが共通化の判断をすることも可能だが、 画面ごとの共通な動き（あるいは画面自体が一緒だったり（処理するデータだけ違うとか））はプロジェクト全体の動きを把握している人 （リーダーとか）じゃないと厳しいかもしれない。
日報はめんどくさいけど、日々リーダーに提出すべき（させるべき）。 じゃないと、どこまで進捗が進んでるのか、遅れてるのか、どんな問題が発生しているのかなどがリアルタイムで分からない。 リアルタイムで分かっていないと言うことは、各人の進捗の進み具合に合わせて適切な仕事の配分が行えないし、フォローもできないと言うこと。 また、リーダーも今チームで抱えている問題が把握できていないと言う状況に陥る。これは良くない。 こういうのは早めに把握してるに越したことはない。 できれば各人の進捗具合や抱えている大きな問題などがチーム全員に公開されているほうが、 チームとしての団結力が上がるし各人のモチベーションも維持できる気がする。 まあ、全部公開されてるんだったらある意味日報の提出は不要かもしれないけど。
チームメンバーの日々の進捗確認は、人によって違うとは思うが直接聞くのではなく、 メールとかそういうのによって確認した方が良いような気がする。 いいづらい事もメールとかのほうが言いやすくなる気がする（まあこの辺りは人によるけど）。
本番でインプロセス以外の保存方法（ステートサービス or ステートデータベース）を使用する場合、 開発時からインプロセス以外の保存方法を利用する必要がある。 インプロセスで開発を行っていると、シリアル化不可なデータもセッションに格納している可能性があるのと （インプロセス以外はシリアル化可能が必須）、 インプロセスだとシリアライズ、デシリアライズ処理 （保存場所が他端末の場合はそれに加えてデータ転送も） が発生しないのでセッションに格納しているデータ量に問題があっても開発時には（本番機で発生する可能性のある） パフォーマンスの問題に気づきにくい恐れがある。
よって、本番でインプロセス以外の方法を利用する場合は開発時から同じ方法、 もしくは各開発端末ごとにステートサービスを立ち上げてそれぞれローカルで利用するのが望ましい。 可能であれば前者の方が良いかとは思うが、開発効率を考えると後者か。
詳細については開発技術大全Vol.3を参照。
データサイズが数100KBを超えるとシリアル化及びデータ転送にかなりの時間がかかるようになるらしい。 詳細については開発技術大全Vol.3を参照。
プロジェクト全体のタスクリスト、各メンバーの担当範囲、タスクリストなどはちゃんと文書化して管理する必要あり。 もちろん、スケジュールに関しても同様。 これないと、現在どんな状況なのかさっぱりわからない。
当たり前と言えば当たり前だけど、各サブシステムの設計やコーディングに入る前に、 それぞれシステム全体としての動きや共通化などを関係者全員で意識あわせ及びドキュメント化する必要がある。 普通、これやらないと各サブシステムの設計や実装に入れないし、 もし入るんだとしたらシステム全体としての共通的な認識を持たないまま、各自バラバラなものを作ることになる。
作業優先順位は以下の通り（上のほうが優先順位が高い）
これ守らない方が（作成するもののみに関して言えば）作る方は楽だけど（他の事は考えなくて良いので）、 全体的な統一について他の人とすりあわせを行った時に、破綻する。
プロジェクトの進行に必要なタスクリスト、担当者、期限、重要度を全てドキュメントに書き出しておく。 上記タスクが全てスケジュールに含まれているのであれば、 スケジュールを見ればわかるのでタスクリストは必要ないかもしれない（まあ実際問題、全てについて線を引くと言うのはちょっと非現実的だが）。 スケジュールもタスクリストもないプロジェクトはメンバーの管理が行われていないと言うことなので、非常に危険。 タスク、担当者、期限の不明確化を招き、ほぼ確実に、言った言わないの状態になる。 またそれに加え、作業指示が口頭ベースと言うこともありタスクの種類によってはスコープ（実作業範囲）も曖昧になったりする。 この場合、大抵指示した側より指示された側が認識しているスコープの方が狭いので、 「何であれやってないの」と言うことになる。 必要なタスクは全て挙げて明確にし、適切な割り振りを行い、進捗を管理する。
検索時に最大表示レコード数とかの制限をかけないと、 場合によっては数万件とか数十万件とかのレコードを引っ張ってくることになる。 実際にそういう検索が行われると色々と問題が出てくるとは思うけど・・・何らかの対応は必須。
どの方法がいいか？（下にいくほど良いのではないかと思う）
作業の割り振りは、大体の大き目の単位で依頼する。 変なところで細かく分けようとしない。例えば、共通の画面とそれを呼び出す共通モジュールを別々の人が作るとか。 結合が強い部分に関しては同じ人が担当しないと、なかなか進まないし仕様変更が発生したときの影響も大きい。 個別画面とそこから呼び出す共通モジュールなどの、モジュール間の結合度が低い境界で作業の依頼範囲を分ける。
チームで作業する以上、各人の作業範囲が分かれるわけだが、 この時どこからどこまでの作業を割り当てるかは結構注意を払って決めなければならない。 当たり前だが、作業範囲の境界には適切な境界と適切ではない境界がある。 最終的に必要とする結果物は同じでも、作業範囲の境界わけを誤ると作業に実際にかかる工数や関係者との調整、 心的負担などなどが荒々しく増減する。 これについては、マクロなものでもミクロなものでも基本は変わらない。 基本的には、（自分の担当する作業境界と隣接する）関係者との調整が最小になるような境界わけが効率が良いものと思われる。 ちなみに、（当たり前だが）関係者との調整は自分の時間だけではなく関係者全員の時間を必要とするので、 実際の作業の見積もり以上に境界わけについてはシビアにやらないと、後々大変なことになる可能性がある。 同じく、境界間のインターフェイス仕様についても、適当にやってると後々大変なことになる。 工数を算出する時、各作業自体の工数を算出するのはまあ当たり前だとは思うが、この時、 インターフェイス仕様の取り決めについての工数は考慮されていない場合が多い （意識／無意識のうちに各作業の工数に組み込んでいるのかもしれないが）。 上述したようにインターフェイス周りの仕様は実際の作業以上に神経及び時間を消費する可能性があるので、その辺りを考慮しておくこと。
情報の共有（伝達）の仕方にも色々あるが、それぞれ一長一短がある。 大雑把な種別としては、
があると思う。 一概には言えないが、下に行くほど敷居が高くなり手間もかかるようになるが、状況を正確に判断し易くなる。 各種別の長所短所は以下の通り。
長所
簡単。手間なし。何か合った場合、言った側に責任なし（の感あり）。
短所
言われた側が書き留めておかないと、後から参照することができない。言われた人にしか伝わらない。説明が適当になり易い。
伝え漏れがあっても大抵分からない。記憶に頼ることによる情報の劣化、改竄。
言葉に頼ることによる情報の伝達ミス。記憶ベースなのでキーワードによる検索不可。
伝える人数が増えるほど正しく伝わっていない可能性大。
途中で仕様が変わっても、いつ、どういう理由で、どういうふうに変わったのかが大抵の場合わからない。
後から別の人に同じ事を伝える必要が発生した場合、（大体において）最初に説明を受けたとき以上の時間が必要となる。
プラス、情報の劣化、伝達ミスが相乗的に発生する可能性大。用は伝言リレーと同じ要領。
何かあった場合、言った側にも言われた側にも責任なし（の感あり）。
言った言わない、そういう事を言ったんじゃないの虚しいやりとりに発生する可能性大。
結論
一時的、補助的なものとしてならともかく、本格的に口頭だけで情報を共有（伝達）しようとするのは問題外。
長所
文字による情報の永続化が行われるので、情報の劣化、改竄がない。
発信した情報が受信情報そのものなので、伝達ミスが少ない。
伝える相手が何人いてもかかる時間は変わらない。キーワードによる検索可能。
後から別の人に同じ事を伝える必要が発生した場合もメールを見てもらうだけで良い。
全ての発信情報が存在するので、仕様が変わっていった場合も時系列で追いかけることが可能。
発信した情報に対する責任の明確化。
短所
口頭に比べると、やや手間がかかる。
基本的にはスポット的な情報を時系列で扱うのがメインになるので、
カテゴリ的な視点から情報を参照しようとした時にどれが最終的な仕様（のまとまり）なのかが判断つきにくい（と言うか、無理がある）。
また、全情報がフラットで配信される関係で、自分の知りたい情報を見逃したり他の情報に埋もれてしまう可能性あり。
基本的に文字だけによる情報となるので、電子ファイルと比べると表現方法が貧弱と言わざるを得ない。
検索方法がキーワードによる文字検索のみ。
長所
基本的にはメールと同様の長所をもつ。
ファイルの種類によるが、基本的に表現方法が多彩。
フォルダなどを使ってカテゴリわけが可能。
最終的な情報のまとまりが参照できる。
フォルダ（カテゴリ）による視覚的な検索が可能。
短所
基本的に、時系列での取り扱いができない。
基本的に、変更履歴がわからない。
作成したファイルがそのままカテゴリ別に保存されるので、
メールと比べると気軽に作成できない（1000のメールは有り得るが、1000のファイルは有り得ない）。
時系列及び変更履歴の取り扱いについては、ソース管理ツール（VSSなど）を使用することによりある程度対応可能
（と言うより、よほど単純なドキュメントでない限り併用必須）
設計担当者は、例え間違いだらけの内容だとしても設計書を書けば終わり（になったつもりになれる）。 実装担当者は、正しい処理を書くまで終われない（例え間違っていたとしても設計書どおりに実装すれば終わりとか、 実装だけしてテストはしないでプロジェクトから外れるとか言うくだらない状況を除く）。 つまり、設計書は手を抜こうと思えばいくらでも手を抜ける。 そんなわけで、必要な事が書いてなかったり間違いだらけの設計書を書いている場合、 実装担当者に文句を言う前にまず設計書を見直すべき。 本当にその設計書に書かれている仕様であっているのか？ 設計書どおりに実装すれば、仕様が間違っていた場合設計担当者の方で責任をとるぐらいの気持ちが欲しい。
ちなみに当たり前だが、設計書が信頼できない場合、その設計書から算出された（であろう）実装工数もおのずと信頼できない値となる。 ああ、そうそう、よくよく考えるとテスト仕様書もまともに作れないね、設計書の内容から作ろうとすると。 設計者が実装するのでなければ、全てにおいてしわ寄せを受ける実装（以降の）担当者の事を少しは考えるべき。
まあ、とは言いつつも、上記の内容はちょっと実装者本位になってるかも。 実装担当者だって実装の手を抜く事はいくらだって可能だし（くだらないとは書いたけど、実装だけして抜けるってのも良くあるしね）、 テスト担当者だって手を抜く事はいくらだって可能（なはず）。 要は、各担当作業分の責任の総和は変わらないので、どこかで責任放棄したらその分の責任をどこか他の箇所で賄わなければならないと言う事。 まあ最終的には・・・メンテナンスする人に全部降りかかりそうだね。
プロジェクト成功に向けた、机上論ではない、現実的な解として面白そうな内容。まだ初めの方しか読んでないけど。
どうでもいいけど、誤訳だとは思うが、様々な問題を解決する為の必要要素の一つとして「献身」が挙げられているのが面白い。 いやまあでも・・・超現実的に考えるならば、当たっているのだろうけど。けどそれがマイクロソフトのドキュメントに出てくるのは面白い。
コードの共通化に関しては、ある程度は最初に予想して共通モジュールを作成することも可能だが、 その後に関しては個々のメンバーが自分で行っている（行おうとしている）独自処理で、 共通化できそうなものがあれば共通化の要望をそれぞれあげるしかない。 なので、書く実装メンバーが共通化に対してそれなりに意識していないと（意識させないと）、 最初に共通モジュールを作成した後は（本来なら必要であろう）その他の共通化が行われない。 もうこれはある意味実装者の意識の問題でもあるけど・・・。
まあ、当たり前だけど、データを登録する機能を先に作らないとダミーデータの作成とか、 本来なら不要な作業に時間をとられてしまう可能性がある。 また、作成したダミーデータの整合性もかなり怪しい可能性がある。 それなりの理由がないのであれば、データ登録機能から先に作成した方が効率が良い場合が多いと思う。
プロジェクト固有用語、業務用語についてはやっぱり用語集みたいなのが欲しいなぁ。 できれば、カナ読みと英語表記もつけて。変数名とかは英語表記の方に統一するようにすれば、全体的なコードの可読性も上がると思う。
少しでも関係のある人（特に設計者）はみんな集めて、一気にレビューするべきだと思う。 この段階で時間や人集めをケチると、少なくとも設計者の間ですら考え方に相違が存在する状態で実装に進む可能性があり、 結局「やり直し」になってそれまでに費やした膨大な時間が無駄になったり、再検討の時間が必要になる事が多い。 半日の集中レビューで一週間、一日の集中レビューで二週間の手戻りの発生を防げると考えれば、 はっきり言ってかなり安い投資だと思う。と言うか、だからこそ設計に時間をかけるべきなんだけれども。 誰ともレビューしていない設計を実装させるなんて、論外。
設計のレビューが終わっているかとかはここでの話とはまた次元が違うので置いておくとして、 設計者と実装者が異なる場合、実装者は設計に関わる背景や仕組みや（少なくとも前後の）流れなどを実装する前に聞いて理解しておくべき。
テーブル名やカラム名は、特に理由がない限り無理に短縮した名前付けをしないほうが良いと思う。 この辺りは変数やメソッドの名前付けと同じだと思う。 無理に短縮すると、テーブル定義書がないと何のカラムなのかさっぱり分からない状態になってしまう。
テーブルのレイアウト変更が発生した場合、既存データを旧レイアウトから新レイアウトに移行することになると思うが、 カラムが追加されてもAccessのODBCを使用して比較的簡単に移行することが可能。
共通クラスについては、MSDNライブラリみたいなヘルプがあると凄い助かりそうだなぁ。 メソッドやプロパティの一覧とか、メソッドのオーバーロードバージョンとかが一目でわかりそうだし。 まあ、よほど余力がないと無理だろうけど・・・。