実際に、一部上場企業や官庁での、画面や帳票を中心とした業務システム開発プロジェクトを成功させてきた考え方と実際の行動を著した業務システム開発プロセス「スペックパターン開発(R)プロセス」を公開します。 従来の開発プロセスにはなかった、業務分析、要求定義、仕様策定までの工程を特に重視したものとなっており、 全て日本国内で実際に行った行動です。

• 　顧客にもプログラマにも伝わる「質の高い仕様書（設計書）の量産」を行うことができる。
• 　全体的な生産性が圧倒的に向上する（５倍以上−顧客からの評価）。
• 　顧客とのコミュニケーション、プログラマとのコミュニケーションがしっかり出来る。
• 　顧客とのコラボレーションをスムーズに行うことができ、顧客満足につながる。
• 　結果、トラブルのないシステム開発を行うことができている（弊社業務実績参照）。

等の効果、実績があります。

　従来米国などで発表されている多くの開発プロセスとは、以下のような違いや革新性があります。
　

　
　これまで多くの開発プロセスが提唱されていますが、そのほとんどは具体的なプログラミングに関するものであり、例えばプログラムの再利用、主として内部設計の図示技法などです。上流工程の重要性は認めるものの、より具体的な提案はされていませんでした。

　「スペックパターン開発(R)プロセス」は、主として業務分析、要求定義、仕様策定（システム設計）までの工程に焦点をあて、これらの工程を確実に行うことによって、プロジェクトを顧客が満足するものに導く具体的な行動や考え方の集まりです。上流工程を丁寧に行う中でプログラムの吟味も行うため、テストでバグを検出するのではなく、最初からバグの少ないプログラムとする効果も得られます。
　従来のほとんどの開発プロセスとは領域の異なる部分の改善案であるため、これらと組み合わせて適用することによって弱点を相互に補完することが出来ます。

• 　顧客の本当の要求を導き出していくための具体案を提示しています。
• 　初期段階の行動を丁寧に行う具体的な手順を提示しています。
• 　その結果、多くの業務システム開発で仕様書を量産することが可能となります。
• 　「仕様変更」は、本当は「仕様策定漏れ」や「コミュニケーション・エラー」である事がほとんどですが、これを大幅に減少させるための具体案を提示しています。
• 　その結果、リスク・マネジメントの観点から見ても、価値のある仕様書を作成できます。

　

スペックパターンとは

　
　画面や帳票の項目ごとの詳細な外部仕様書の記述とそれを実現する具体的なプログラム・ソースとの組み合わせを、顧客に承認してもらいながら、ＳＥ（仕様策定者）とＩＬ（インプリメント・リーダ　＝　プログラマのリーダ）が対等な協働の中でひとつひとつ丁寧に整理していきます。これを「スペックパターン」と呼びます。
　　

　
「スペックパターン開発プロセス」は、「スペックパターン」を作成するＳＥとＩＬの協働作業を中心として、以下のような行動や考え方を提案しています。
　これらを単に手順だけではなく、顧客や開発実作業者との密接なコミュニケーション、経験やモチベーションを重要視しながらプロジェクト・マネジメントを行っていくことで、高い品質と生産性を実現します。
　本プロセスはプログラマの不安感や迷いを出来る限り排除し、モチベーションを高める事を考慮した結果でもあります。

　

１．「モックアップ」の作成と承認

ＳＥ（仕様策定者）が初めて顧客担当者と顔を合わせた日から数日のうちに「モックアップ」を作成し、「承認を得る」行為を実施します。顧客に安心していただくと共に実際に作成していくシステムについてのイメージがしやすくなることによって、後の作業の効率化が図れます。以降「現場主義」「１８０度逆の法則」他、具体的な考え方、行動によって「業務分析」「要求定義」を進めていきます。

２．顧客業務理解についての承認

ＳＥ（仕様策定者）が顧客の新しいシステムを考え始める前に、現在の顧客の業務をしっかり理解し、その承認を得るプロセスを明確に定義しています。 　また、そのためのコミュニケーションツール（モデリング技法）として、業務プロセスについて素晴らしい表現力を持ったツール（産能大式業務フローチャート）の利用を提案しています。

３．深沢式会議法

顧客との意志決定の会議での「議事録」を「システム開発の最重要ドキュメント」としてとらえ、独特な会議の進め方、議事録の取り方を提案しています。

４．「スペックパターン」によるサンプル画面のレビュー

業務分析、要件定義などと並行してＩＬが作成してきた、想定稼働環境上で実際に動くユーザーインターフェース等のサンプル集と、ＳＥが作成してきたそれらを表現する仕様書のサンプル集（含技術的制限等の情報）によって顧客とのレビューを行い、と同時にシステム全体に渡って考えられるリスクについての検討および出来うる限りの対策方針決定を行います。

５．「スペックパターン」による、最初の作成

ここまでで作成された顧客とプログラマが理解できる「仕様書（の部品）」と、それを具体化したプログラム（の部品）である「スペックパターン」を元に、ターゲットシステムの代表的な機能について、実リリース品質で最初の作成（設計、コーディング）を行います。

６．「スペックパターン」による最初の成果物のレビュー、テスト、承認

最初に作成されたプログラムについて、細部に渡って、顧客（稼働後実際に操作する人）にテスト、承認をしていただき、「仕様書」「プログラム・ソース」双方の完成度を出来る限り高めます。

７．テスト済み、承認済み「スペックパターン」からの仕様書の量産

完成度を高めた、顧客承認済み、テスト済みであり、プログラマに伝わる表現となっている「仕様書」を元に、他の機能についての「仕様書」を市販データベースアプリケーションを利用して量産していきます。