新人Ａさんは何とか単体テスト仕様書の作成工程と単体テストに進んだ。

これまでに日程は大幅に遅れている。
たった今、プログラミングの速度は仕方ないかと、そこは問題視していない。
スピードは経験を積めば徐々に上がっていくかと予測もしている。

また、ＳＶＮでUpdateを忘れ、途中でチームの別担当者が更新し、
古くなったソースにコーディングして、いざコミットする際に
誤って自分のソースを消してしまったとかも、
経験を積めば改善されていくだろうと捉えている。
またこの件は、なぜそうなったかも私は心得ている。
チーム内から「頻繁すぎるコミットは止めてほしい」
と苦情があったことで、遠慮していたことが起因しているのだ。

ここは以前にも書いたが、バランス感覚と言いますか、ＥＱの問題だろう。

確かにそれも問題ではあるが、しかし本当の問題はそこではない。

そもそも何のためにＳＶＮを使っているのか？
・チームで同じソースを変更する可能性があるから。
・自分のソースの誤りに気付きロールバックをある時点まで容易にできるから。
・ファイルの変更日時、変更者、変更理由などの履歴が残るので、何のために変更したのか情報共通しやすい。...

さてそこで、下記（＜コミットの履歴と事象＞）は
新人AさんのSVNコミット履歴 と事象の経緯である。
確かに少し頻繁な更新が10/20～24にかけて行われているが
クレームがでるほどでも？
■「頻繁すぎるコミットは止めてほしい」とはその回数ではなく、
受入テストしている端からコミットを繰り返さないでとのクレームなのだ。
なぜ、頻繁だとチーム内で感じられたのかそれを追求せずに
「コミット」を意味も判らず止める対応に問題がある。
■修正履歴のコメントが冗長でかつ変更理由に成っていない
コメントで「変更理由」が第三者に分かるのか？
それは、ソースの変更箇所をviewすれば分かるのでは？
修正履歴のコメントにソース書かなくても？
同じようなコメントで修正理由が分からない（本末転倒！）

コメント１つ、コミットタイミング１つ
「神は細部に宿る」根本はそこにある。

＜コミットの履歴と事象＞
●2016年10月20日 16:38:44　
　ヘッダーを最初のみ表示。
　A型をX型を同じ形式に変更。（→日本語がおかしい）
　A項目追加。
●2016年10月20日 16:55:38
　発行用のページ総数を修正。
●2016年10月24日 14:29:32
　○○一覧表を追加。
　(case "7"
　return DownloadBxx(); //○○一覧表)
●2016年10月24日 14:52:13
　○○一覧表 DownloadBxxを追加。
●2016年10月24日 17:36:50
　XX書の○○品・構成部品の箇所を修正。

☆「受入テスト中」(→ここでコミットが頻繁すぎるとクレーム)

●2016年10月24日 19:42:22
　○○一覧表を出力。
●2016年10月24日 19:42:22
　プレビューでも構成部品の品名コードを表示。
　明細行が26行まで表示されていたので25行までに修正。
　重複したデータがあったため改行の箇所を修正。

☆「コミットすることを止める」
↓
☆「ソースを取り込まず、コーディングが始まる」
↓
☆「マージに失敗してソースが消える」
↓
☆「コミット再開」

●2016年11月18日 17:47:04 （↓冗長なコメント）
　string dateFrom = (string)ymRow["MONTHLY_START_DATE"];
　DateTime start = DateTime.ParseExact(dateFrom, "yyyyMMdd", null);
　string dateTo = (string)ymRow["MONTHLY_END_DATE"];
　DateTime end = DateTime.ParseExact(dateTo, "yyyyMMdd", null);
　form.taishouYMFrom = Convert.ToString(start);
　form.taishouYMTo = Convert.ToString(end);
　「年月の選択リスト作成」に上記を追加。
　画面で対象月度と対象日付の関係性を確認するため。（○○一覧表）
●2016年11月18日 19:42:04（2016年10月24日 14:29:32にも追加してるが？）
　○○一覧表を追加。
●2016年11月18日 20:53:22
　○○一覧表(EXCEl出力)を追加。
　SQLの共通検索に○○一覧表のための検索条件追加。
●2016年11月18日 20:57:03
ヘッダー出力追加。

☆は事象