案件フォルダの作成方法を体系化しよう

デスクトップに散乱したファイル達を見たことがあるか

IT系に従事するプロであっても、パソコンの中のファイル整理が下手くそな人は多い。そんな人は大抵、デスクトップがメチャクチャだ。「一体あのファイルはどこにあるんだ？」と自分で作った重要なファイルすら分からなくなってしまう人もいる。探しているだけ工数の無駄である。

誰も整理方法を教えてくれない

それはそうだ、誰もそんな事を教えてくれないから、思い思いの方法で勝手にやってるだけだから、そうなってしまうのだ。体系化されていないものは管理できない。幸いにして、私は開発に従事して1年目からフォルダできちんと整理する事を教わったので適当に共有しておくことにする。

どうすればいいか

とにかく「考えなくとも、見ただけで、誰でも、何が、どこに、あるか分かる」というのが最も重要なところなので、ずばり一連のプロジェクト工程の区切を名付けてあげるのが一番良い。なお、全てのフォルダはバッチで mkdir で作って、あとから必要なもの以外を削除またはWORKフォルダにでも移動すればいい。

工程のフォルダを作る

01.要件定義

提案かユーザの要望で発生した案件の課題管理や要件整理を行う。大々的な要件定義フェーズがなくメールでポイと来た案件は、やりとりしたメールを保存してあとは課題管理表だけで済ませたりもする。ちなみに、この名前でフォルダを作る。数字を付ければどんな環境でも名前順ソートくらいは出来るので、最初だと分かる。

02.環境構築

環境移行または初期開発でよく使う。「環境定義」でも良い。実はそんな資料が無くて作るしかないパターンでも使う。サブフォルダとして更に「01.ハード」「02.ソフト」「10.構成図」なんかも考えられる。

10.基本設計

初期開発の時か、ぼんやりしたイメージの作成にしか使わない。いわゆる外部設計。主にUIとI/Oを決める。

20.詳細設計

保守開発だとここからいきなり始まる場合が多い。データのセット仕様を元にして、個々の正常系＆異常系のケースで結果はどうなるのか、プログラマーが実装するにあたり必要な情報を書く。設計段階でマスターとして追加するデータは決まるので、サブフォルダまたは「21.データセット」としてトップフォルダに置く場合がある。ジョブフローなんかもここに入れる。

30.実装

ソースコードを収める。案件によっては、プログラム設計も入る。WinMerge あたりで単純フォルダ比較できるようにフォルダ構造ごと修正前と修正後で分けて保存する。差分があるファイルだけでよい。ちなみに私は「コードを書く工程」と「単体テストをする工程」は全然別物だと考えているタイプなので、「製造」とは言わない事にしている。

40.検証

保守開発だと単体テストと受け入れテストしかされない。必要なだけサブフォルダを作る。

50.リリース

最後にリリースだ。リリース判定の書類、リリース物のチェックリスト、最終的に確定したリソース（データやモジュール）、本番リリースの作業エビデンス（証跡、証憑とも言う）を入れる。

60.事後対応

リリース後に何かちょっとした追加作業が発生した場合ここに発生日付と共に入れる。

99.WORK

一時フォルダだ。あとで消すやつ。