一般的なシステムには構造に重大な問題が潜んでいる
開発段階では、どういったものを（仕様）、いつまでに（納期）、いくらで（費用）作ります、という主旨の契約が取り交わされ、開発が進められます。
一見当たり前の手続きです。しかし、この裏にも問題が潜んでいます。そして、一般的なシステムでは、お客様はそのことに気づけないまま、いわゆるイケていないシステムを押し付けられているのです。
システム構造の問題
システムの構造に配慮がされない
決められた仕様を決められた期間で開発することが、開発会社の仕事です。そこには、開発途中に発生する要望や運用後に発生する仕様の変更に対応し易くするといった、システム構造についての配慮が存在していません。そのため、変更に柔軟に対応することのできない、変更に弱いシステムが開発されてしまっています。
しかも、この変更に弱い構造は、お客様にとって最もわからない部分です。ソフトウェアの構造は、ソースコードを解析して、どのような構造になっているかを確認しなければわからないため、一般的に、エンジニアでないお客さまには判断することができません。
従って、変更に弱いシステムを引き渡されているのかどうかも気づくことができずに、運用することになります。
お客様には見えないシステム構造
システムの詳細な構造は、その開発会社にしかわからないため、システムに変更を加えたい場合、お客様としては、同じ会社に依頼するしかありません。極端な話、後から変更を加えると余計に費用がかかる作り方をしておいた方が、その会社が儲かることになります。意図的に、そんなことをする会社はないと思いますが、一般的なシステム開発では、結果として、変更に弱いシステムが引き渡されて、変更に余計な費用と時間をかけて対応しなければならなったケースが数多く発生しています。
これらのケースは、もし、変更に強い構造設計を行っていれば、変更に必要な費用や時間を抑止できる場合が少なくありません。
開発の進め方の問題
開発途中でお客様の要望が受け入れられない
一般的にシステム開発は、要件定義→設計→製造（プログラミング）→試験（テスト）→納品→運用という流れで進められます。これは、ものづくりの基本的な流れです。しかし、この裏にも重大な問題が潜んでいます。
この開発の流れは、いわゆる、ウォーターフォール型と呼ばれる進め方です。
この進め方の特徴は、前段階（前の工程）の結果が、次の段階（次の工程）へと引き継がれていくことです。要件定義を行い、要件が確定します。そして次の設計工程に引き継がれます。要件定義の結果は確定事項ですから、次の設計工程で変更されることはありません。あってはならないのです。同様に、設計工程の結果として、設計が確定し、次の製造工程へと引き継がれます。引き継がれた設計に基づき、製造が行なわれます。ここでも引き継がれた設計が変更されることはありません。あってはならないのです。
変更のないことが前提の開発プロセス
既に、この説明に違和感を覚える方もおられると思います。この考え方でいくと、要件が、最後の運用に至るまで変更されてはいけないことになります。設計も同じです。運用段階まで、設計変更はあってはならないのです。しかし、実際の開発では、いかがでしょうか？そうです。取り決めた要件通りに、何の変更や追加要望もなく運用開始に至ることはほとんどありません。必ずと言っていいほど、変更が必要となる要望が発生します。
つまり、開発では、変更が発生するのが当たり前であるにも関わらず、変更を前提としないプロセスで開発しているのです。そのため、ほとんどのプロジェクトが、この”変更”の影響を受け、予定通りに進まない事態に陥ります。当然と言えば当然の結果です。
実際には変更が発生し、そして対応できないという繰り返し
お客様からは、開発途中に、仕様の変更要望が発生します。しかし、開発は途中で変更が発生しないことを前提としたプロセスで進められています。当然、対応することはできません。対応するためには、費用の追加やスケジュールの変更が必ず発生します。
このように、一般的なシステム開発では、当然のように発生する要望に対応できず、そればかりか、開発の途中でシステム会社からは「変更するためには幾ら必要になります」「スケジュールはこうなります」といった説明がなされ、お客様はどうすべきか苦慮することになり、結果、プロジェクトが停滞するという事態が日常的に起こっているのです。
開発体制の問題
情報伝達ができない多重下請構造
開発に際しては、必要な人材を集めてチームを編成します。仕事の有無にかかわらず、常時、自社でその体制を保ち続けることは出来ませんので、開発のタイミングによって、都度チームを編成します。ここまでは、必要不可欠な対応です。問題はその中身です。
一般的なシステム開発におけるチーム編成は、いわゆる「下請け多重構造の寄せ集めの体制」になっています。元請会社から下請、更には孫請け会社から、それぞれ人を集めて、体制を作ります。そこでは、開発の目的や、どういったシステムを開発するのかといった理念が共有されることはありません。
情報伝達は伝言ゲームのようになり、意思疎通が不確かなものになります。そのため、なぜ、この仕様なのか？といったこともわからないままコーディングしていることも少なくありません。仕様書の通りに、上からの指示の通りに、深く考えずに開発するしかなくなってしまいます。これでは、そもそもいいものづくりはできません。
