 |
||||||||||||||||||||
|
||||||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||||||
|
||||||||||||||||||||
| コードの量産を考慮した「特定のドキュメントのみ」の量産 | ||||||||||||||||||||
|
前回は単純な対応表による暗号の考え方と同じように、「一般的な言葉による、ある特定の画面項目の動作に関する詳細な記述」と、そのまま開発に流用されることを想定して入念に実装され、詳細な仕様書の記述通りに動作する「プログラム・ソースコード」の対応部分が1対1の関係となった情報を作り上げる手法であるスペックパターンについての解説をしました。 そして量産といっても、あれもこれも作るという訳ではありません。これまでバラバラの文書に分けて記述していたことを「詳細外部仕様書（画面項目定義書）」のみに極力集約して記述した上での量産です。 プログラマは、インプリメント・リーダーや仕様策定者らによる「スペックパターン（仕様書記述とモデルソースの対応部分）」やシステムの全体像などの説明を受け、モデルソースをじっくりと読み込みます。以降、顧客側承認者が承認した外部仕様書を見ることで、具体的な実装をどう行うのかということが明確にわかることになります。 通常の日本語記述で表現しきれないことについては、プログラマにとって最も適切な「ソースコードによって伝える」のがベストです。ただし可能な限り高い精度で伝えるために、実装レベルのソースコードとなっている必要があります。それがモデルソースです。 以上で、一度に大勢のプログラマに「何をどうコーディングするか」が極めて容易に伝わる方法ができあがります。このことによって、プログラマの1人1人がバラバラに分けて記述された資料に基づいて個々に組み上げていくという作業は、ほとんどなくすことができました。 そして、「スペックパターン」と「モデルソース」によってドキュメントに記述されていることから、何をどうコーディングすればよいのかという情報を大勢のプログラマに容易に理解してもらえる仕組みと、データベース化による「ドキュメント（画面項目定義書）の量産」を組み合わせれば「プログラムソースの量産」も可能なのです。 |
||||||||||||||||||||
| ドキュメントとプログラムソースの量産にあたって意識すること | ||||||||||||||||||||
|
前回の箇条書きの残りの項目について、説明します。
表1：ドキュメントの「量産」を実現するにあたって考慮すべきこと（再掲） |
||||||||||||||||||||
| 保守性 | ||||||||||||||||||||
|
単に「量産」さえできればよいということではありません。「量産」できるということは当然、後から変更を行う場合に作業対象が大量であることを意味するため、「保守性」についてはさらに高い要求が発生します。 一般的な開発では、表計算アプリケーションを使って1シート目に画面のイメージや画面概要説明を配置し、2シート目に個々の画面項目の一覧を記述するという作り方をよく見かけます。基となるファイルを作成し、そしてファイルごと複製して、内容を修正していくという方法でもある程度のドキュメントの量産は可能です。 しかしこの場合、電子媒体であること以外、つまり保守性については特に考慮がありません。ドキュメントを「量産」してしまった後に、例えば文書のフッタのコピーライトをすべてのページについて変更すること（下請け・孫請けの構造では、比較的頻繁に起こりますし、年数の変更なども容易に起こります）などは、すべてを事前に配慮して対処しておかないと大変なことになります。 また、セルに入りきらない文字が印字されないままになっていたり、あとから追加した情報によって全てのファイル、シートに手作業で項目追加を行うことになってしまったりと、大変です。 例えば、2つの提出先の要求によって、少しずつ印字項目の違うフォームを2通り用意するとなったら、単純に考えると表計算ファイルの数がいきなり倍になってしまいます。しかも以降、それらの同期をシッカリと実現しなければいけないわけですが、やはり大抵の場合はメンテナンスが中途半端になっていきます。 これが開発完了後のみとは限らず、コーディング期間前や期間中でも発生する場合があります。それは期間でプロジェクトを区切って途中経過での納品があったり、進捗に懸念を抱いた顧客が予定になかったドキュメントの提出を求めたりする場合などです。 多くの場合、コーディング以外のこれら個々のドキュメントへの対処などもプログラマたちが分担して作業を行うことになっていました。必要な作業であることは確かなのですが、量と保守性のバランスから、大人数で分担をしないと対処しきれない作業だったわけです。 単純作業であればそういった対処も可能ですが、システム開発ではそうはいきません。元々顧客業務を見たことがなく、理解しきれていないプログラマたちに対して、とても少ない情報でドキュメントの修正などを指示するようなことが時として起こってきます。 すると、個々の作業を行うプログラマが混乱し、それぞれの仕様書記述の表現がまちまちになってしまったり、混乱によってモチベーションも低下して、業務を理解している者にとっては信じがたいミスが起こってきたりします。このような場合にこそ、マネジメントが細部に渡って実作業者たちの統制をとることに集中しなければなりません。これができない場合は、マネジメントに責任があります。 |
||||||||||||||||||||
|
1 2 3 次のページ |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
