開発用のフォルダ構成を，自動的に生成してくれるバッチ　（プロジェクト用のリポジトリ立ち上げに便利。ついでに，用が済んだら自動消滅！）

ソフトウェア開発のためのフォルダ構造を，自動的に生成するバッチ。

例えばSVNリポジトリの立ち上げ時などに，ワンクリックで，チームで作業可能な開発プロジェクトのひな型を生成することができる。

毎回同じようなフォルダ構造を手動で作るのは面倒なので，自動化する。

具体的には下記のように，各開発工程に対応したフォルダが作成される。

各フォルダは複数のサブフォルダを持つ。

詳しいフォルダ構造の中身は，エントリの後半を参照。（カスタマイズ可能）

01_立ち上げ
02_要件定義
03_基本設計
04_詳細設計
05_実装
06_試験
07_リリース
08_運用
09_移行
10_その他
99_マネジメント

開発者に対して「作業開始を促す」ため，各サブフォルダにはTODOファイルが設置される。

これはプレースホルダの役目を果たす。

このようなファイルセットを，一発で生成するためのバッチ。

ソースコード

forループとサブルーチンを駆使する。

開発用フォルダ構造を初期化.bat

@rem 
@echo off

rem 開発用リポジトリの，ドキュメント側のフォルダ構造のひな型を，自動的に作成するバッチ


rem このバッチが存在するフォルダをカレントに
pushd %0\..

rem 本当は最初に rmdir /S . で該当フォルダ内のクリーンアップをしたいが，
rem フォルダ内を全削除すると .svn ディレクトリも失われるし，
rem このバッチ自体も削除されるので処理が続かない。:-(


call :ROUTINE_SETUP_ONE_DIR "01_立ち上げ" "企画,ヒアリング"
call :ROUTINE_SETUP_ONE_DIR "02_要件定義" "プロジェクト概要,プロトタイプ,機能設計,初期計画"
call :ROUTINE_SETUP_ONE_DIR "03_基本設計" "アーキテクチャ,画面設計,DB,ネットワーク"
call :ROUTINE_SETUP_ONE_DIR "04_詳細設計" "クラス設計,処理設計"
call :ROUTINE_SETUP_ONE_DIR "05_実装"     "環境構築,規約,バッチ,設定ファイル,メモ"
call :ROUTINE_SETUP_ONE_DIR "06_試験"     "テスト設計,単体テスト,結合テスト,システムテスト,その他"
call :ROUTINE_SETUP_ONE_DIR "07_リリース" "本番環境,リリース手順,計画"
call :ROUTINE_SETUP_ONE_DIR "08_運用"     "ユーザマニュアル,運用マニュアル,保守対応,引き継ぎ"
call :ROUTINE_SETUP_ONE_DIR "09_移行"     "原案,移行設計,移行資材,移行本番"
call :ROUTINE_SETUP_ONE_DIR "10_その他"   "議事録,ツール,保管,etc"
call :ROUTINE_SETUP_ONE_DIR "99_マネジメント"  "進捗,再見積もり"


rem 終了処理
echo フォルダ構造の作成が完了しました。
pause
tree /f

echo このバッチを削除せず，残しておきますか？
  rem @see http://language-and-engineering.hatenablog.jp/entry/20081208/1228708657
set userkey=
set /p userkey=残す (Enter) / 削除する (n + Enter)
if not '%userkey%'=='' set userkey=%userkey:~0,1%
if '%userkey%'=='n' goto LABEL_DELETE_THIS_BAT
goto LABEL_QUIT


:LABEL_DELETE_THIS_BAT
del /Q %0


:LABEL_QUIT
pause
exit /b
  rem /bオプションが無いと，呼び出し元のコマプロのウィンドウ自体を終了させてしまう。
  rem @see http://www.ne.jp/asahi/hishidama/home/tech/windows/bat.html#%E6%88%BB%E3%82%8A%E5%80%A4



rem --------------------- サブルーチン ---------------------


rem １フォルダ作成用のルーチン
:ROUTINE_SETUP_ONE_DIR

  rem ルーチンの引数を取得
  setlocal
  set DIR_NAME=%1
  set SUBDIR_LIST=%2
    rem ※サブルーチン中でsetlocalすれば，
    rem   呼び出し元に影響なくローカル変数を使える
    rem   http://language-and-engineering.hatenablog.jp/entry/20111030/p1

  rem 上位フォルダ作成
  mkdir %DIR_NAME%
  
  rem 下位フォルダを作成
  cd %DIR_NAME%
  for /F "delims=, tokens=1,2,3,4,5" %%i in ( %SUBDIR_LIST% ) do (
      rem @see http://language-and-engineering.hatenablog.jp/entry/20100819/p1
    call :ROUTINE_CREATE_SUBDIR "01_", "%%i"
    call :ROUTINE_CREATE_SUBDIR "02_", "%%j"
    call :ROUTINE_CREATE_SUBDIR "03_", "%%k"
    call :ROUTINE_CREATE_SUBDIR "04_", "%%l"
    call :ROUTINE_CREATE_SUBDIR "05_", "%%m"
    
    rem TODO: 数を増やしたい場合はここを追記
  )
  
  cd ..\

  rem ルーチン終了
  exit /b


rem カレントフォルダにサブフォルダと空ファイルを作成するルーチン
:ROUTINE_CREATE_SUBDIR

  rem ルーチンの引数を取得
  setlocal
  set SUBDIR_PREFIX=%1
  set SUBDIR_BASENAME=%2
  set TEMP_FILE_NAME=TODO
  set SUBDIR_NAME=%SUBDIR_PREFIX%%SUBDIR_BASENAME%

  if "%SUBDIR_BASENAME%"=="""" (
    rem なし
  ) else (
    rem サブディレクトリを作成
    mkdir %SUBDIR_NAME%
    
    rem 空ファイルを作成
    cd    %SUBDIR_NAME%
    type nul > %TEMP_FILE_NAME%
      rem @see http://text.readalittle.net/article.php?id=244
    cd ..\
  )
  
  exit /b

このバッチを，開発プロジェクトのルートフォルダに置いて，実行するだけ。

SVNで言うと，リポジトリのtrunkのドキュメント用フォルダのルートという事になる。

ただし，開発対象にバージョンアップの可能性があるのであれば，

はじめから「ver1.0」のようなフォルダを置いといて，そこを期間内の暫定ルートにして作業した方が良いだろう。

バッチを実行すると，フォルダが生成され，フォルダツリーのプレビューができる。

実行ログ：

フォルダ構造の作成が完了しました。
続行するには何かキーを押してください . . .

D:.
│  開発用フォルダ構造を初期化.bat
│
├─01_立ち上げ
│  ├─01_企画
│  │      TODO
│  │
│  └─02_ヒアリング
│          TODO
│
├─02_要件定義
│  ├─01_プロジェクト概要
│  │      TODO
│  │
│  ├─02_プロトタイプ
│  │      TODO
│  │
│  ├─03_機能設計
│  │      TODO
│  │
│  └─04_初期計画
│          TODO
│
├─03_基本設計
│  ├─01_アーキテクチャ
│  │      TODO
│  │
│  ├─02_画面設計
│  │      TODO
│  │
│  ├─03_DB
│  │      TODO
│  │
│  └─04_ネットワーク
│          TODO
│
├─04_詳細設計
│  ├─01_クラス設計
│  │      TODO
│  │
│  └─02_処理設計
│          TODO
│
├─05_実装
│  ├─01_環境構築
│  │      TODO
│  │
│  ├─02_規約
│  │      TODO
│  │
│  ├─03_バッチ
│  │      TODO
│  │
│  ├─04_設定ファイル
│  │      TODO
│  │
│  └─05_メモ
│          TODO
│
├─06_試験
│  ├─01_テスト設計
│  │      TODO
│  │
│  ├─02_単体テスト
│  │      TODO
│  │
│  ├─03_結合テスト
│  │      TODO
│  │
│  ├─04_システムテスト
│  │      TODO
│  │
│  └─05_その他
│          TODO
│
├─07_リリース
│  ├─01_本番環境
│  │      TODO
│  │
│  ├─02_リリース手順
│  │      TODO
│  │
│  └─03_計画
│          TODO
│
├─08_運用
│  ├─01_ユーザマニュアル
│  │      TODO
│  │
│  ├─02_運用マニュアル
│  │      TODO
│  │
│  ├─03_保守対応
│  │      TODO
│  │
│  └─04_引き継ぎ
│          TODO
│
├─09_移行
│  ├─01_原案
│  │      TODO
│  │
│  ├─02_移行設計
│  │      TODO
│  │
│  ├─03_移行資材
│  │      TODO
│  │
│  └─04_移行本番
│          TODO
│
├─10_その他
│  ├─01_議事録
│  │      TODO
│  │
│  ├─02_ツール
│  │      TODO
│  │
│  ├─03_保管
│  │      TODO
│  │
│  └─04_etc
│          TODO
│
└─99_マネジメント
    ├─01_進捗
    │      TODO
    │
    └─02_再見積もり
            TODO

このバッチを削除せず，残しておきますか？
残す (Enter) / 削除する (n + Enter)
続行するには何かキーを押してください . . .

たいへん面白い事に，

バッチの実行の最後の部分では，「このバッチ自身を削除するか？」と質問している。

このバッチは，用が済んだら「自己消滅」してくれるのだ。

まるで，スパイ同士が情報伝達のために使う音声テープのようだ。

「なお，このテープは自動的に消滅する・・・」

スパイ大作戦
http://ja.wikipedia.org/wiki/%E3%82%B...

指令録音の最後部分には「録音部分は5秒以内に消滅する」、「録音部分は直ちに消滅する」、「このテープは自動的に消滅する」等が録音されており、指令が録音されたメディアのテープや、レコード盤等は指令の再生後に自動的に化学変化を起こし、発火等をし消滅する。

もしくは，自己破壊するウィルスのようだとも描写できるのだが。

なおバッチを使わずに，本物のフォルダツリーを生の形式か，もしくは圧縮形式で保持しておくという手もある。

だがそれってprogrammableなアプローチではないため，変更に弱い。

なので，このように動的に生成している。

また，これはドキュメント等のためのフォルダ構造であって，

ソースコード用のフォルダ構造ではない点に注意。

フォルダ構造に関する参考：

開発者向けから運用者向けへ共有フォルダを整理したい。
http://oshiete.goo.ne.jp/qa/2026694.html

各工程ごとに納品物や最新のドキュメント・参考資料等を保管する

Subversionのフォルダ構成
http://www.ryuzee.com/contents/blog/2728

ルート配下にtrunk、tags、branchesを配置して、他のものは配置しないのがよい

Java開発におけるフォルダ構成
http://d.hatena.ne.jp/wyukawa/2010020...

trunk配下にドキュメント専用のフォルダを置く

補足

利用上の注意点：

bat自体をカスタマイズし，自分自身が実際によく使うフォルダ構造に書き換えた上で使うこと。

フォルダ生成後は，必要なもののみを残し，不要なものは削除すること。

特に２番目は大事。

たまにだが，システム開発を，ドキュメントのテンプレートの穴埋め作業みたいに考えている人間がいる。

不要なドキュメントを大量に作って，成果物のページ数を誇りたがるメンバーだ。

チーム内にそういう浅はかなメンバがいると，プロジェクトは容易に火を吹く。（よく見かける？）

必要なドキュメントのみを，必要な時に作ればいいのだ。

そうしないと，工数が無駄に失われるし，文書間の整合性も崩れる。

とはいえ，こういう「テンプレート生成」用のバッチがあれば，定型作業が自動化される。

メリットとして，開発プロジェクトを立ち上げる手間が簡略化され，

「身動きの素早いエンジニア」になる事ができるのだ。

誰かの発案と同時にプロジェクトを立ち上げ，

その発案者の発言が終わる時点では，もう既に要件が箇条書きで整理されており，

話し終わった時点で発案者にメールで送付される。

それを見てもらって，ちょっと話してるうちに，もうプロトタイプが動き始め，

さあ，これをどう肉付けしますか？と，ぐいぐい話を進めてゆける。

そして，いつの間にかチーム作業のためのインフラとひな型も整っている。

そんなエンジニア。
（Rails系フレームワークを使っていないと，これはまず実現不可能だろう。。）