ザ・SIer的プロジェクト共有フォルダのデファクト構成を考えてみる
先日こんなツイートをみかけました。
まだ、SESやSIer会社で勤務していた頃、散々現場で見かけたのを思い出して懐かしい気持ちになりました。
不思議なことにどこに行っても多少の差はあれど、プロジェクト共有フォルダって同じような作りになってるんですよね。
（炎上プロジェクトほど散らかります）
懐かしさついでに、プロジェクト共有フォルダのデファクトを考えてみます。
（あくまで私の経験に基づくものです）
SIerがその案件でウォーターフォールのどの工程に入るかによって、設計工程や製造工程のフォルダだけになったりもします。
フォルダは数字の若い順にできていくので、頭から順に見ていきます。
代替、会社で決められている管理番号や、キックオフの日付なんかをプレフィックスにつけます。
これに限らず、フォルダにはプレフィックスをつけるのが決まりです。
理由は名前順に綺麗に並ぶから、またエクスプローラーで先頭文字をタイプすれば狙いのフォルダにすぐに飛べるからです。
途中でお蔵入りになったり、失注した案件はZIPで固められアーカイブされます…。
クライアントからの提案依頼書、それを受けて営業をかけるための提案書、金額見積、プロジェクトスケジュール、プロジェクト体制図などが入ります。
営業やPMが見るものなので、SEやPGは関係ないと思いきや。
そもそものシステムへの要求（夢）が書かれているものなので、下流工程で仕様がぶれてきたときに、原点に立ち返るのに役立ちます。
フルスクラッチではなくパッケージ導入だとフィット＆ギャップの資料などが入るでしょう。
作るシステムの本当のボリューム感がだいたいここで決まります。
基本設計をプログラム機能、部品単位に落とし込んだドキュメントが用意されます。
開発工程を下請けベンダーにお願いする場合は、ベンダーのレベルにもよりますが特にしっかり書かなければ結合テストでえらい目にあいます。
コードやSQLをそのまま日本語で記述したようなドキュメントもみたことがあります。
経験上一番蔑ろにされやすい工程で、これがない状態で製造に入ることも結構ありました。
ソースコードはVCSで管理することがほとんどですが、稀にここで管理してる場合があります…。
スケジュールが押してるとクリアしきってなくても無理くり実施したりします…。
サブシステム同士をつなげたシステム全体のテストと、システム間連携テストを行います。
スケジュールが押してると(ry
ユーザーが直接テストして、要件を満たしているか、業務が回せるか検証します。
そのためのテスト手順、シナリオ設計はベンダーの仕事になります。
UAT時に出た課題は台帳にまとめ、クリティカルなものはカットオーバー日までに解消しなければいけません。
カットオーバー時には、当日のスケジュールや確認ポイント、切り戻しプランなど事前にスケジュールを作成します。
また、要所要所でトラブルや問合せなど起きるので、その内容と対処を台帳にしておくことも重要です。
上がった課題のうちクリティカルなものは、なるはやで対応、そうでないものは保守運用フェーズに引き継ぎます。
システム監視や定期バッチパラメータ設定などの運用手順書や、問い合わせ・障害管理台帳などのドキュメントが入ります。
その人の名前がフォルダに付きます。
レビュー依頼など、人とのファイルのやり取りに使ったりします。
モダンなIT企業は、ファイル共有をBacklogやSlackなどのSaaSでスマートにやってるとは思いますが、それでもあるべきところに、見つけやすいように人がデータを整理するというのは、ツールが変わっても必要です。
これは、ITエンジニアリングすべてに通ずることだとは思いますが…。
不思議なことにどこに行っても多少の差はあれど、プロジェクト共有フォルダって同じような作りになってるんですよね。
（炎上プロジェクトほど散らかります）
懐かしさついでに、プロジェクト共有フォルダのデファクトを考えてみます。
（あくまで私の経験に基づくものです）
[管理No or キックオフ日].プロジェクト（案件）名
├───00.プロジェクト管理
│ ├───提案依頼書（RFP）
│ ├───提案書
│ ├───見積
│ ├───スケジュール
│ ├───議事録
│ └───etc...
├───10.要件定義
│ ├───業務フロー
│ ├───システム構成
│ ├───移行設計
│ └───非機能要件
│ │ ├───インフラ構成
│ │ └───ネットワーク構成
│ ├───議事録
│ └───etc...
├───20.基本設計
│ ├───機能一覧
│ ├───画面・帳票定義書
│ ├───バッチ設計書
│ ├───外部システムインターフェース設計書
│ ├───テーブル設計書
│ └───etc...
├───30.詳細設計
├───40.製造・単体テスト
├───50.結合テスト
├───60.総合テスト
├───70.受入テスト
├───80.カットオーバー
├───90.運用保守
└───XX.その他SIerがその案件でウォーターフォールのどの工程に入るかによって、設計工程や製造工程のフォルダだけになったりもします。
フォルダは数字の若い順にできていくので、頭から順に見ていきます。
目次
ルートフォルダ
ルートのフォルダはプロジェクト（案件）名になります。代替、会社で決められている管理番号や、キックオフの日付なんかをプレフィックスにつけます。
これに限らず、フォルダにはプレフィックスをつけるのが決まりです。
理由は名前順に綺麗に並ぶから、またエクスプローラーで先頭文字をタイプすれば狙いのフォルダにすぐに飛べるからです。
途中でお蔵入りになったり、失注した案件はZIPで固められアーカイブされます…。
プロジェクト管理
一番最初がプロジェクト管理のフォルダです。クライアントからの提案依頼書、それを受けて営業をかけるための提案書、金額見積、プロジェクトスケジュール、プロジェクト体制図などが入ります。
営業やPMが見るものなので、SEやPGは関係ないと思いきや。
そもそものシステムへの要求（夢）が書かれているものなので、下流工程で仕様がぶれてきたときに、原点に立ち返るのに役立ちます。
要件定義
要件定義では、ユーザーと打ち合わせをしながら業務、要件をヒアリングし要件定義書を作成していきます。フルスクラッチではなくパッケージ導入だとフィット＆ギャップの資料などが入るでしょう。
基本設計
外部設計ともいいます。作るシステムの本当のボリューム感がだいたいここで決まります。
詳細設計
内部設計ともいいます。基本設計をプログラム機能、部品単位に落とし込んだドキュメントが用意されます。
開発工程を下請けベンダーにお願いする場合は、ベンダーのレベルにもよりますが特にしっかり書かなければ結合テストでえらい目にあいます。
コードやSQLをそのまま日本語で記述したようなドキュメントもみたことがあります。
経験上一番蔑ろにされやすい工程で、これがない状態で製造に入ることも結構ありました。
製造・単体テスト
コーディング規約や開発環境構築手順書などのプログラム開発用の資料と、単体テスト（UT）のエビデンス等が入ります。ソースコードはVCSで管理することがほとんどですが、稀にここで管理してる場合があります…。
結合テスト
ITとも。単体テストをクリアした機能をつなげて、サブシステム単位のテストを行います。スケジュールが押してるとクリアしきってなくても無理くり実施したりします…。
総合テスト
システムテスト（ST）ともいいます。サブシステム同士をつなげたシステム全体のテストと、システム間連携テストを行います。
スケジュールが押してると(ry
受入テスト
ユーザー受入テスト（UAT）ともいいます。ユーザーが直接テストして、要件を満たしているか、業務が回せるか検証します。
そのためのテスト手順、シナリオ設計はベンダーの仕事になります。
UAT時に出た課題は台帳にまとめ、クリティカルなものはカットオーバー日までに解消しなければいけません。
カットオーバー
リリース、本番稼働ともいいます。カットオーバー時には、当日のスケジュールや確認ポイント、切り戻しプランなど事前にスケジュールを作成します。
また、要所要所でトラブルや問合せなど起きるので、その内容と対処を台帳にしておくことも重要です。
上がった課題のうちクリティカルなものは、なるはやで対応、そうでないものは保守運用フェーズに引き継ぎます。
運用保守
システムがカットオーバーされ、安定運用に入ると、運用保守フェーズとなります。システム監視や定期バッチパラメータ設定などの運用手順書や、問い合わせ・障害管理台帳などのドキュメントが入ります。
XX.その他
個人フォルダ
プロジェクトメンバーが作業用ファイルを置いておくフォルダです。その人の名前がフォルダに付きます。
レビュー依頼など、人とのファイルのやり取りに使ったりします。
モダンなIT企業は、ファイル共有をBacklogやSlackなどのSaaSでスマートにやってるとは思いますが、それでもあるべきところに、見つけやすいように人がデータを整理するというのは、ツールが変わっても必要です。
これは、ITエンジニアリングすべてに通ずることだとは思いますが…。