プログラム製造の現状

２１世紀に入り、パソコンの爆発的な普及により、コンピュータを利用したシステムの増改築の潜在的需要は高まり、ＩＴ関連を始めとして要員の不足がいわれています。
一方で、システム構築のプラット・フォームとしてのクライアント/サーバー型や、リレーショナル・データベースをハンドリングするミドル・ソフトなども多く発表され、システム構築の手段が豊富になるとともに、システム構築の生産性や、品質も向上したかのような期待を抱かせます。
しかし、現実は２割３割当たり前、へたをすると２倍３倍のコスト増で、相も変わらぬ人海戦術と、納期がせまってからのお祭りさわぎの連続がみられ、散々言い古されている、システム開発の諸問題はなんら解決されないままの状態です。
ここではそれら問題点ににスポットをあてつつ、その解決方法として工業的生産方法を提言したいと思います。
改めて問題点を取り上げてみると次のようなものがあります。

１．生産性の低さ

プログラムを中心とするシステムの生産性は、非常に個人差があり、能力の高い人は低い人の何倍もの効率を出します。さらに、同じ機能のプログラムを作成しても、能力の低い人はプログラムそのものが冗長で大きくなる傾向があります。すなわち、プログラミング能力の低い人は、プログラム作成の速度が低い上に、プログラムそのものが大きく（行数が多く）なってしまいます。
システム開発のプロジェクトをスタートさせたような場合、メンバーの誰が生産性が高く、誰が低いのかは、まったくわかりません。せいぜい一人月２０００ステップくらいの平均生産性として見積りをせざるをえないのが現実です。
プロジェクト・チーム全体の生産性を高めようとすると、高給を払って能力の高い要員を集めるか、さもなくば、要員をトレーニングして能力を高める以外に、ほとんど方法がないのが現実です。

２．属人性の高さ

他人の作ったプログラムは読みにくく、改造がしにくいといわれます。どうかすると、改造よりも、新規に組み直した方が早くできるとさえいわれます。また、クライアント／サーバー型で基幹システムを構築する場合に必要とされる、ミドルソフトや、画面での表現性がよいとされるビジュアル・ベーシックなども、従来のプログラマーがマニュアル・ベースで簡単に取り付くことができるものではありません。

特定の人でないと作れないし、特定の人でないと良いものができない、特定の人でないと改造すらもできないという状態にあります。このような属人性の高さは、ソフトウエアの品質の劣化や、生産性の低下、保守・改造のしにくさなど大きな悪影響をもたらしています。

作成する人によって、製品の性能や精度の品質が決定づけられてしまう。これは、絵画・音楽など芸術の世界の話です。どこそこのだれそれの作だからこのシステムの品質はよい、などという書画骨董のようなことがあってよいはずがありません。


３．保守性の低さ

先に述べた属人性の高さは、個々のプログラムに色々な個性を生み出します。個人プレーによるところの多いプログラムの作成作業は、いいかえれば、個人の個性発揮の場でもあるからです。
この結果、できあがったプログラムは、どこで何をしているのか、非常に読みにくいプログラムであったり、いたるとことで同じ処理をしていたり、あるいはその場しのぎの、つぎはぎのプログラムであったり、あるいは自己の力量を誇示するためのアクロバット的コーディングがしてあったりして、間違いの訂正や機能変更のための改訂などが、しづらいものになりがちです。

さらにその上、プログラムやシステム全体の設計書にしても、記述が不充分であったり、改訂が反映されてなかったりします。どうかすると２０年以上も前のプログラムが、ろくな設計書もなしに、はれものに触るようにしてシステムの中で動いていたりします。

このような保守性の低さは、到底ソフトウエアとは言い難いほど、システムを硬直したものにしているのが現実です。

４．低品質

システムの開発のために必要な工数は、その期間を通じて一様なものではありません。開発の初期には少なく、中期・末期には多く工数が必要になります。
しかし、現状のソフト開発の体制では、ピーク時のために備えて、手空き要員を抱えているような余裕はとてもありません。当然プロジェクト体制をとります。
プロジェクト体制というと聞こえはよいのですが、ピーク時、臨時に社内外から要員をかき集める、いうなればその場しのぎのことでしかありません。臨時に集められた要員の能力が、均質で高いことは望むべくもありません。この結果、開発当初からのいきさつや約束事など、あらためて情報の交換が必要になり、行き違いや勘違いなども多く発生し、プログラムひいてはシステム全体の整合性は低いものになってしまいます。

システムのトラブルの９０％は、インターフェイスの部分で発生することを思えば、システムが低品質になるのは当然のことといえます。


５．規格性のなさ

本来工業の世界では、製品は設計書を基に作られ、同一設計書からは同一ののが作成されるというのが常識です。ところが、技術の最先端といわれるコンピュータ・ソフトとなると、途端にその常識がほとんど通用しなくなってしまいます。

現状では同一の設計書を渡してプログラム作成を依頼したとしても、同一のプログラムが出来上がってくることは期待はできません。どうかすると同一人物に、同じプログラムの作成依頼をしたとしても、同一のプログラムができあがることの保証すらありません。
ましてや、システム全体において、それを構成する一連のプログラムの中で、使用される基本的な処理ロジックの統一、内部のサブルーチン名、変数名などを統一するというようなことは、望むべくもないのが現状です。

さらに、設計書の書き方一つをとってみても、これといった業界の統一基準がある訳ではありません。それぞれのコンピュータ・メーカーやソフトハウスが独自に、自社で良いと考えた記述法を、唯我独尊的に提唱しているにすぎません。このため、設計書は一長一短の記述となり、プログラム作成に必要な情報を網羅できていないことが多く、プログラム作成者は、改めて設計者に問い合わせしたりしているのが現状です。

６．要求技術レベルの高さ

近年、コンピュータを利用してソフト開発を行う、ケース・ツールなどが発表されています。
このケース・ツールを利用することは、問題点の解決になるのでしょうか。

残念ながらその実績と見通しは悲観的です。
本来、ソフト開発を容易にかつ効率的に開発をするべきこれらのツールは、使いこなすために、相当のトレーニング期間を要するのがほとんどです。すなわち、ケース・ツールを使用しようと思えば、開発要員の技術レベルは、かえって高いものが要求されるようになります。
このことは、柔軟な増産体制が取り難いばかりでなく、ケース・ツールを導入したために、かえって技術レベルの高い人たちでないと使いこなせない、という属人性の増加をきたし、システム開発の生産性が阻害されり、保守が特定の人にしかできない、というような皮肉な結果をもたらしてしまいます。

７．技術・知識の継承のなさ

ＳＥ３５才定年説がいわれるように、コンピュータ業界では比較的はやく世代交代が行われます。実はこれは最新の知識を必要とする、コンピュータの業界だからということではありません。

慢性的な人手不足と、見積もり違いや、納期がせまってからの、大改定などが原因の繁忙状態に、体力が持たないことが主な理由のひとつです。このため若い人たちは導入講習を受けたあとは、十分な技術移転を受けるまもなく、手探りか「口伝」での技術の習得を行っているに過ぎません。

加えて転職に抵抗感のない世代の増大によって、技術移転はますます乏しくなり、コンピュータの技術はおおよそ工業とは縁遠い、「見よう見真似」の技術になってしまっているといっても過言でありません。
経営的観点からすれば、賽の河原の石積みにも似たこの状態をどこかで断ち切り、技術を社内に蓄積する必要があることはいうまでもありません。

ソフトウエア開発の工業化の提言は先に延べた、システム開発の現状の問題点を、根本から解決しようとするものです。その要諦は、徹底したソフトウエアの設計と製造の工程化と、設計情報の一元化、できうればそれを支援するソフトを開発し、徹底的活用を図ることにあります。

当然、コンピュータによる自動のプログラムソース生成機能も視野にいれますが、これが前提条件というわけではありません。


１．設計と製造の分離

ソフト開発の世界ではプログラム作成に際して、設計書でわからないことがあれば、プログラマーは設計書を作成したＳＥとよく打ち合わせをして情報交換をするようにといわれます。
工業的にみて、これほど、設計書がいい加減なものであることを、証明している言葉はありません。設計書だけでものが作れないというこどですから。

さらにひどい場合は、設計書もないまま、プログラムが作成されたりします。その場ではよいとしても、このことは後日に、属人性や保守性の問題を引き起こします。

製造工業の世界では、設計書あるいは設計図（以下設計書と総称します）によって全ての物を作ります。ネジ１本でさえ設計書によって作成し、電話や口頭で伝えたりするようなことはありません。
ソフト開発においても、工業的な生産を行おうとすれば、まず設計と製造の工程を明確に分離することから始めるべきです。

誤解のないように付け加えますが、このことはどこまでも工程を分けるということであり、設計工程の作業と製造工程の作業を、同一の人が兼任してはならないということではありません。


１）基本設計

設計工程は大別して、基本設計と詳細設計に分けます。基本設計はシステム全体に影響を及ぼす項目の設計で、いいかえればグローバル設計とでもいうものです。
詳細設計は基本設計を受けて行われる、個々の設計で、本質的にこの設計内容が全体には影響を及ぼすことはありません。
基本設計は、ユーザーから見える部分、すなわち外部設計と、直接ユーザーには見えないが、システム全体に影響を及ぼす内部設計とに分けられます。
外部設計では帳票の設計、画面の設計があります。内部設計ではファイルの設計、システムのプログラムへのブレイクダウン、共通に使用するシステム・ユニットあるいは部品プログラムの決定、あるいはシステム成立の可否を左右する重要なロジック、あるいはアーキテクチャーの検討などを行います。
この工程の結果、例えば、次のようなものを成果物とします。

・システム、サブ・システムの構成ツリー図
・帳票の一覧と個々の基本レイアウト
・画面の一覧と個々の基本レイアウト
・ファイルの一覧と個々の基本レイアウト
・プログラムの一覧と個々の機能の記述

これらは、もし工業化支援システムが開発できるなら、その中にマシン・リーダブルの形で得られるとともに、基本設計書として文書の形でも出力できるようにしておきます。基本設計書はユーザーへ提出し、承認を取得するための書類となります。

メニューツリーの情報からは、具体的に画面を表示できるメニュープログラムを作成できるようにしておきます。もちろんこれら画面とプログラムは、最終版ではありません。どこまでもユーザーに具体的な姿を見せるものです。具体的な姿をみせることによって、本当に必要なリクエストが返ってきます。

ユーザーからの改定要求があれば、この工程で改定を行い、再度承認を取得します。
改訂要求があったからといって、担当者はうんざりすることはないのです。もし支援ソフトさえ開発されていれば膨大な文書類は全てコンピュータが作成してくれるのですから。

この基本設計の工程を終えて、始めてシステムの規模が定量的に判明することになります。

２）詳細設計

詳細設計は先の基本設計の結果と、ユーザーからのリクエストを受けて、それぞれのソースをコーディングするための記述を行います。
設計の結果は、当然システム全体に影響することはありません。すなわち、グローバル設計に対してローカル設計とでもいうものが詳細設計です。

具体的作業は次のようになります。

・個別の帳票の詳細設計それに伴う処理ロジック・パターン決定
・個別の画面の詳細設計それに伴う処理ロジック・パターン決定
・個別のプログラムの詳細設計
・プログラム構成ツリー図の作成

帳票の詳細設計では、請求書や納品書など、予め印刷済の伝票との位置すりあわせなども行います。
個別の画面の設計では、画面処理パターンの選択などを行ないます。
個別のプログラムの詳細設計では、処理をメニューをサポートする制御プログラムや、帳票・画面を処理するプログラム、中間ファイルを作成するプログラムに分けて、その処理パターンのを予め準備された標準パターンから選択を行います。

標準処理パターンの作成は工業化の中の重要な部分です。すなわち、工業規格にみられるように、処理そのもののを充分吟味パターン化して、標準としておきます。建物で言えば、間取り、廊下、階段、トイレなどの標準パターンに相当します。

そのパターンを準備作成する場合は、処理ロジックをユーザー・ロジックとコンピュータ・ロジックからなる処理に分け、そのコンピュータロジックの部分を標準化しておくものです。
ユーザー・ロジックの部分とは、例えば会話型処理であれば、画面からの入力項目のチェック要領やファイルと画面の間の編集要領などがこれに該当します。


２．製造工程

製造工程すなわちプログラムの開発は、大まかには詳細設計の情報に基づいて、必要コンポーネントを集める組みたて作業と、製品の形に微調整する仕上げの工程に分けます。

１）システム組立製造（プログラム作成）

この工程では、先の基本設計、詳細設計から得られた情報に基づき、システムを組立て製造します。
経験的には、この工程は吟味すれば、さらに１０工程くらいに、細分化され得るとみています。

直接得られる成果物はソース・プログラムですが、ソースができれば、コンパイルも行うことができるので実行可能なプログラムも得られます。すなわち、この時点で断片的ながら、実行可能なシステムが出来上がります。

実行可能のプログラムは必要あれば、マスター・ファイルにデータを登録し、ユーザーに実行をデモンストレーションが可能で、システム仕様を具体的にしリクエストの追加・変更の応答をユーザーに促すことが可能になります。
ただし、追加・変更を無償で行うかどうかは、営業的な配慮との兼ね合いによるものなので、ここでの議論としては取り上げません。

２）システムの仕上げ作業

システム組みたて作業そのものの完成度は、いきなり１００％の精度を実現することはできません。これは支援ソフトが利用できたとしても同じです。

システムの仕上げ作業の工程では、細かい部分を、手作業で修正を行うことになります。
その量は全体で１０％以下と見込まれます。もちろん、標準の処理パターンでカバーできいない処理も存在するので、このような処理のプログラムは完全に手作りとなります。
しかし、処理パターンが確定する都度その重要度順に標準処理パターンに取込み、あればそのカバーの範囲を広げていくことにしますが、当初から１００％を狙わないことが現実的であろうと思います。

客先のリクエストに伴う、標準のパターンからはずれるような微調整は、有償作業とすることになります。

手修正による改訂は記録は納入成果物としての設計書を作成する場合は、標準からの差分として「設計書補足」として文書化します。


３．テスト作業

工程化においては、当然テストの作業もプログラム作成とは別工程にし、別担当者が行います。
製作者が確認のために自分で行うテストはここでいうテストではありません。
テスト仕様書は詳細設計段階での記述に基づいて作成します。
テスト内容はは業務処理部分として組込んだ部分だけのテストを行い、標準ロジックパターンとしてサポートされている部分のテストは当然不用です。これは標準ロジックとしたときにテストし、バグ・フリーとし、テスト報告書を作成しておくからです。よってテスト自体の作業量は１／３以下になります。

４．納品と設計書の作成

テスト工程まで完了したシステムは、実行可能なマシンリーダブルとして客先へ納品します。基本・詳細の設計書（補足も含む）テスト仕様書、テスト結果報告書などの文書類も客先へ納品します。
支援ソフトが利用可能になっていれば、これらを支援ソフトから印刷出力し納品物とします。
文書化の作業は、ＳＥやプログラマーに多大の負担をかけているのが現状です。
支援ソフトを開発しこの負担を取り除くことにより、生産性はさらに向上します。

システムの開発の工業化が達成されたなら、それから得られる利点は次の通りです。

１．高生産性

合理的な工程分けをしっかり行うことにより、従来複雑で技術力が必要とされてきた、システム開発の作業の内容は、ほぼ同一手順の繰返しに変えることができます。同一手順の繰返しにすることにより、担当者は、簡単に作業に慣れることができます。すなわち、技術的に低いレベルの人であっても（極論すればワープロができるだけの技能であっても）、生産性を２倍程度まで、向上させ得ることができます。この２倍というのは経験に基づく数字です。
さらに加えて、工業化支援ソフトが開発できたとして、それを利用することができれば、生産性は簡単に４・５倍にあげることが期待できます。

２．属人性の排除

工業化したソフトウエア開発手法の採用で特筆されることは、属人性が極力排除されることです。
問題点の項でも取り上げたように、プログラムの作成は、担当する技術者の個性におおいに左右されます。さらに加えてコンピュータ技術者は自己顕示的に、個性あるプログラムを組む傾向があります。このことが、ソフトウエアの生産性の低さや、統合性のなさ、品質の悪さとしてシステム開発における問題点となっています。

工業化の概念のもとに、設計情報を一元管理し、基本部分を標準化しておくプログラム生産方式では、そのような個性の入り込む部分はほとんどありません。生産されるプログラムの処理手順も、万人向けのオーソドックスな手順のものが作成されます。
このことは、システム開発の途中であっても、メンバーの増員や入替えが簡単にできる上、エンドユーザーへの引き継ぎも容易で、納入したシステムの手離れがよいことを意味します。
属人性の排除ができるという点は、経営的観点からみた場合、非常に注目すべき利点です。

３．高い保守性

プログラム改定の難しさは、そのプログラムがどこで何をしているのかが解りにくいことと、いたるところで同じことをしている、という冗長さにあります。一元化管理された設計情報からにより作成されたプログラムは、システム全体にわたって、プログラムは同一の基本構造、同一のロジック・パターン、同一変数名で統一された、冗長度のほとんどない構成となります。
従って、初めてそのシステムに接する人にも、どこでなにをしているかが、容易に理解でき、必要最低限の技術レベルがあれば、誰でもそのシステムの修正や、増改築が可能になります。

４．高品質

工業化した手法では、設計・および製造の情報を一元化管理を行います。現状ではシステムの開発を行っているものにとっては、全体を見渡して、細部まで整合性のとれたシステムを構築していくことは至難の技ですが、工業化支援ソフトを作成し一元化された設計情報を利用することができれば非常に整合性の高いシステムの構築が可能になります。
特に後述する処理の標準パターンを利用することにより、製造プログラムの７０％以上の部分がミスのないオーダーメードとなります。新規に構築する部分は３０％、すなわち実質システム規模は１／３のサイズになります。
システム規模は大きくなればなるほど、システムの品質は指数関数的に悪くなる傾向があります。
逆にいえば規模が小さくなればなるほど、その品質は相対的によくなります。
従って単純計算でも完成されたシステムは、３倍以上の高品質となることが期待されます。

５．高い規格化

このテーマは担当者個人個人が、工業化の理念を守ることからスタートしますが、支援ソフトにより半強制力をもたせると、そのメリットはさらに増大します。すなわち、設計書の記述は最終的に、支援ソフトが規定した書式にしたがって記述します。この記述を元にプログラムを生成するので、当然同じ設計書からは、１字１句違わない同じプログラムが生成されます。
最終的にはこれを「仕上げ加工」して製品としますが、問題点としてとりあげた規格性のなさは、これによりほとんど解決します。
最近よく話題にあがることの多い、ＩＳＯ９００１の取得のための条件もクリアするのが楽になるとおもわれます。

設計書とプログラム生成法については別の機会で述べます。

６．要求技術レベルの緩和

工業的な製造する場合の工程化においては、コンピュータに依存する部分と、業務側に依存する部分を明確に分けます。そして、実際の開発では、コンピュータに依存する部分の工程は人は処理パターンの選択作業のみを行い、楽屋うちであるところの、コンピュータ・プラットホームに依存する部分は、単純なコピーによって作成します。
そして業務側に依存する部分のみが、本来の開発作業として残ります。
つまり、開発のメンバーに要求される技術レベルに関しては、コンピュータ依存部分の技術が、ほとんど要求されない、言いかえれば、メンバーへの要求技術レベルが大幅に緩和されることになります。

このことは属人性の排除とあいまって、システム開発で増員や、メンバーの入替えが、簡単にできることを意味します。また、増産体制を組む必要があるとしても、固定の社員をそれほど採用しなくてもよいという利点があります。

経営的、あるいは管理的観点からみた場合は非常に大きいメリットといえます。

７．技術・知識の蓄積と継承

工業的なシステム開発では、コンピュータに関連する技術や知識を、数十種の基本的ロジックの蓄積として、また数十種のアセンブリー・ユニットや部品として、蓄積・組込みすることを想定しています。またこれらは必要の都度、改定を行い、新しい蓄積を標準にに追加します。
つまり工業化準備によってえられた標準そのものが、蓄積する技術の入れ物としての役割を果たすことになります。例え、要員が現場をリタイアしたり、転職していなくなったりしたとしても、技術やノウハウが、根こそぎなくなってしまうことにはなりません。
さらに支援ソフトが利用できれば、比較的技術力の低い人たちでも、蓄積された技術やノウハウをそれほど意識することなく簡単に享受することができることになります。

終わりに

過去、幾多のシステム開発を経験してたどりついた結論は、やはり、システムは工業的に開発されなければならないということでした。
近年パソコンの普及により、まるで紙細工かなにかのようなシステムが多くなっています。
確かにシステムが安いということは、経営的観点からすれば好ましいことなのですが、トラブルが発生したときのリカバリーや、お守り役の人件費も総合しての評価を下すべきではないかと思います。

機能が安定し、拡張やメンテナンスが樂で、かつ低価格なシステムは、工業的な開発手法を発展させてこそ実現するのではないかと思っています。

ここの記事についてはのご意見はこちらまで

（Ｃ）ＣＯＰＹＲＩＧＨＴ ＩＳＨＩＯＫＡ ＫＡＴＳＵＨＩＤＥ ２００２