40種類以上の豊富な設計書, 仕様書, ドキュメントテンプレート
             
          
            弊社サービスをご利用頂き、誠に有り難うございます。
            ドキュメントのダウンロード件数が2007年5月の開設以来300000件を突破しました!
            今度ともご愛顧の程よろしくお願いいたします。
          
            PocketDOC(ポケットドック)とはシステム開発に必要な設計書や仕様書などのドキュメントやテンプレートはもちろんのこと、
           議事録、納品・検収書、近年話題になっている個人情報に関しての取扱管理表などの
          ドキュメントやテンプレートも提供しています。
          
            実際に弊社のプロジェクトで使用されているため精度も高く、カスタマイズなしでも利用可能なほどです。
            上流工程から下流工程まで広い範囲をサポートしているので、
            必要なテンプレートだけをダウンロードして利用することも可能です。
          
            ドキュメントやテンプレートのファイル形式はWord(doc形式)やExcel(xls形式)です。
            ダウンロード後、すぐにお使いいただけるように
            仕様書・設計書などの各種ドキュメント・テンプレートの実例サンプルが付いています。
          
             
          
            ・お客様に提出する見積書や受領書、納品書のサンプル
            ・基本設計書、詳細設計書、テスト仕様書のサンプル
            ・SQLやPHPなどのコーディング規約に使うためのテンプレート
            ・データベース設計に必要なテーブル定義書、ER図
            ・設計書や仕様書の書き方の参考
            ・会議に使用するために必要な議事録のフォーマット
          
などシステム開発に必要な40種類以上の豊富なドキュメントテンプレートを揃えています。
| 要求仕様書 | 御見積書 | 御見積書(簡易版) | 
| 設計方式書(APL) | 設計方式書(DB) | システム構成図 | 
| 業務フロー図 | 機能一覧 | 画面レイアウト | 
| 画面一覧 | 画面遷移図 | 帳票レイアウト(横) | 
| 帳票レイアウト(縦) | 帳票一覧 | ジョブネット図 | 
| バッチ一覧 | ER図 | シーケンス一覧 | 
| テーブル定義書 | ユーザ一覧 | 表領域一覧 | 
| IFファイル定義書 | 詳細設計書 | コーディング基準書(ASP) | 
| コーディング基準書(SQL) | コーディング基準書(VB) | 試験方式書 | 
| 単体試験仕様書 | 結合試験仕様書 | 総合試験仕様書 | 
| 障害一覧 | 障害管理票 | マニュアル(一般ユーザ用) | 
| 全体スケジュール | 体制図 | 打合せ議事録 | 
| QAシート | 物品借用書 | 物品貸出書 | 
| 外注誓約書 | ソフトウェア検収書 | 受領書 | 
| 納品書 | 個人情報取扱い管理票 | 
テンプレートと連動した支援・便利ツールも提供!
            これらのドキュメントやテンプレートを便利に使うための支援ツールも用意しております。
            特にデータベースの便利ツールは開発に大きく貢献します。
          
            ・テンプレートやドキュメントのヘッダ、フッタ一括変換ツール
           ・Microsoft ExcelのVBAツールを使ったデータベースの便利ツール
          
標準化の目的
            近年の開発期間の短期化、開発要員の流動化のため、システム開発におけるドキュメントの標準化は不可欠となっています。
            しかし、標準化への過程において当初の目的がぼやけてしまう恐れがあるので注意が必要です。
          
| 目的 | ・内部統制の強化 ・開発プロセスの確立 ・開発期間の短縮 ・開発コストの削減 ・教育コストの削減 ・品質の安定・向上 ・コアメンバー流出のリスクヘッジ | 
|---|
標準化への課題
            システム開発ドキュメントの標準化が必要なことは明白ですが、
            実際に現場に導入するとなると様々な課題が浮上してくると思います。それらを如何に解決するかがポイントになってきます。
            特に中小企業では、専門チームを立ち上げることは困難なのでどうしても掛け持ち作業になってしまいます。
            メンバーのモチベーションを維持するためには何らかの工夫が必要になってきます。
          
| 課題 | ・一時的に発生する工数UPへの反発 ・標準化チームとしての予算が取れない ・せっかく導入したのに運用に乗らない ・いつの間にか派生した様式が多数発生している ・対象システムの形式(Web・C/S・バッチ・制御)が多岐に亘る ・対象システムの規模(大・中・小)が多岐に亘る | 
|---|
標準化への準備
システム開発ドキュメントの標準化に向けて様々な事前準備作業が発生します。
| 準備 | ・各部署・課への根回し ・有識者(ステークホルダー)の選定、チームの立ち上げ ・全社メンバーへの事前周知 ・既存テンプレートの収集 ・既存開発プロセスのフロー化 | 
|---|
標準化
            標準化作業をチーム体制で行ないます。
            開発工程・開発プロセスなどの見直し、フォルダ構成の確定を行なった後にテンプレートを作成します。
            ファイル数、項目数が無駄に多かったりすると導入に失敗する恐れがありますので注意が必要です。
            また、最初から完璧なテンプレートは作成できないものと割り切って作業することも重要です。
          
| 標準化 | ・開発工程・プロセス・方式の見直し ・フォルダ構成の確定 ・テンプレート対象、形式(Word・Excel・Visio)の確定 ・テンプレートの作成 ・運用ルールのマニュアル作成 ・実プロジェクトへの試験的な導入、フィードバック | 
|---|
導入
            標準化作業が完了したらいよいよ導入です。
            導入の前には必ず事前説明会を開催し、関係者全員に十分な時間を取って説明することが重要です。
            何故標準化を行なうのかを開発メンバー全員で理解し、意識レベルを統一することが成功への鍵となります。
            また、各工程毎のレビューは必ず実施することを心掛けてください。
          
| 導入 | ・説明会の実施 ・実プロジェクトへの段階的な導入 ・各工程毎の全ドキュメントのレビューの実施 | 
|---|
標準化の継続のために
            システム開発ドキュメントの標準化で一番難しいのは継続することです。
            その為には、標準化チームの横断的な監査、各プロジェクト間の情報共有が不可欠です。
            ドキュメントの標準化を行なった為に、開発工数が膨らんでは本末転倒です。
            コスト削減に結び付かないようであれば、開発プロセス、テンプレートの見直しが必要です。
          
| 継続のために | ・プロジェクト中の成果物の監査 ・プロジェクト完了後に開発者の声をフィードバック ・テンプレート変更後の周知の徹底 ・標準化チームでの定期的な会議の実施 ・標準化の目的を忘れない ・無理をしない ・諦めないで、粘り強く | 
|---|
 
            