 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||||||
|
||||||||||||||||||||
| 大幅なドキュメント作成・保守の生産性向上を可能とするために | ||||||||||||||||||||
|
「スペックパターン開発プロセス」では画面などの設計について、極めて小さな単位である「画面項目」単位で詳細に動作を記述していくことになります。画面項目単位の記述をデータベース上で1レコードとすることによって、ドキュメント作成・保守の生産性が大幅に高まります。仕様書（設計書）について、一見相反する「極めて高い生産性」と「極めて詳細で高品質な記述」の両立を実現しており、このことは表計算アプリケーションなどでは実現不可能です。 仕様書が「量産」できると「モデルソース」「スペックパターン」によって、プログラムの実装も「量産」できます。1人のプログラマの生産性も極めて高くなりますし、大勢のプログラマを一気に動員した開発でも、極めて高い品質と生産性で「量産」ができるのです。 実装を進めていく中で新たにでてくる画面項目などの外部仕様（「モデルソース」や「スペックパターン」として実現されていないもの）については、その都度インプリメント・リーダーや担当プログラマと重点的に話し合って実現していきます。 ここまで読んでわかる方もいると思いますが、コーディング規約を配布して各個にバラバラにコーディングしてもらうより、プログラマのソースコードを読み取る力を信頼する方がはるかに高品質でバグがなく、かつプロジェクト全体で統一された高品質なコーディングがきるようになります。 「深沢式 会議法・議事録術」や「モデルソース」など、「スペックパターン開発プロセス」では、「あらかじめ手本となるようなことをやってみせ、提供する」というのが、考え方の基本です。 これら手法によってコミュニケーションは品質や生産性の高い充実したものとなって、「詳細さ」「正確さ」「高い生産性」「高い品質」をすべて同時に実現できます。また役割分担がより明確となることにより、実作業者たちの不安や迷いをなくし、「達成感」や「助け合っているという実感」も得られやすくなります。結果として「モチベーションも高めていく」ことができ、つまり「すべて上手くいく」ようになるのです。 これは詳細な情報を示さずに「あれはダメ、これはダメ」というような問題指摘型で業務システム開発を進めて行く方法とは対局的な考え方でしょう。元々問題が発生するようなプロジェクトの進め方をしておいて、いざ問題が発生すると解決策を提示できずに、「権威的にプログラマたち実作業者の残業、徹夜に依存して助けてもらう」という開発をするわけではありません。 本連載を読んで応用／実践していくにあたっては、プロジェクトを「すべてうまくいく」ようにするということを念頭に置いていただきたいと思います。もちろん、簡単にはいきませんが、少なくとも誰かが目指さなければ絶対実現しません。 |
||||||||||||||||||||
| 顧客業務理解（業務分析） | ||||||||||||||||||||
|
ここから具体的な開発工程で極めて重要な段階である業務分析の話を進めます。業務システム開発・ソフトウェア開発に限らず、何かを実現するもの作るには、その実現したい対象を正確かつできる限り詳細に知る必要があります。 業務分析は様々な書籍で取り上げられ、重要視されています。しかしながら、実務でじっくり時間と資源を使って顧客業務の現状を詳細に渡って掌握するということは、なかなか行われていません。「自分はきちんと業務分析をしている」と感じられている読者も多いと思いますが、筆者が考えているのはかなり徹底的な業務分析です。 |
||||||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
