SQLer 生島勘富 のブログ

RDB・SQLの話題を中心に情報発信をしています。

日本のホワイトカラーの生産性を上げるには１

システム設計

　日本のホワイトカラーの生産性が世界的に低いらしい。なぜ、日本のホワイトカラーの生産性が世界的に低いのか。いろんな理由があると思いますが、システム開発会社である私の考えは、ホワイトカラーの生産性を上げるという使命を持った我々システム会社が十分機能していないということが、非常に大きな理由の一つだと考えております。

　そこで、どうすればシステム会社が十分に機能し、日本のホワイトカラーの生産性を上げることに貢献できるかを考えてみたいと思います。


　一番の問題は原因は、システム会社がいまだにウォータフォールモデル開発に拘っていることにあると考えています。

　ウォータフォールモデル開発では、プログラムを作る前に仕様書（基本的に紙）という形でユーザに設計を承認して貰うわけですが、グラフィカルな画面を紙で表現されてもユーザには完全にイメージできるものではありません。というよりも、「書いている本人でさえイメージできているのか？」と疑問を持つことすら多いです。しかし、開発を進めるためには承認作業は必要で、曖昧なイメージで承認された仕様書（設計）で進めて行くことになります。

　ウォータフォールモデル開発では承認されたものは正しいという前提になりますが、その前提を覆す仕様変更が起きたときに、前工程に遡る大規模な手戻りが発生することが最大の問題です。しかし、ユーザは曖昧なイメージで承認している訳ですから、そもそも承認されたものは正しいという前提は壊れている。余程、ユーザの要望がはっきりと分かりやすい場合を除き仕様変更は必ず発生します。

　開発の終盤になって、実際のプログラムをユーザが見てイメージとのギャップを口にしたとき、それをユーザが「仕様変更」である、つまり「自分たちの承認が間違っていた」と認めて、「納期延長と追加費用」を認めてくれた場合か、運良く「仕様変更」が当初の見込み分ぐらい（普通、ある程度のバッファをもって見積もる）しか発生しない場合は、そのシステムは成功したことになります。しかし、ユーザが「仕様変更」（納期延長と追加費用）を認めてくれなかった場合は、いわゆるデスマーチという状態になります。現実問題としてほとんどの場合、予想以上の仕様変更が起こり、高い確率で「納期延長」が認められることはありませんから、IT系の仕事は長時間労働が常態化しいわゆる３Ｋ職と言われるわけです。

　それでも、抜本的な解決策を講じることなく、デスマーチの後には「ユーザが仕様変更を認めざるを得ないドキュメントを作るべきだった」という反省を行い、解決策としてドキュメントが増えていきます。ドキュメントが増えれば更に工数が掛かりますが、増えたドキュメントは良いシステムを作るために生まれたドキュメントではなく、「仕様変更」という言い逃れをするためのドキュメントに過ぎませんから、生産性には何も貢献しません。

　ウォータフォールモデル開発の問題点は、まだ、CUI（character user interface）が中心だった、数十年前から言われていますが、現在のユーザインタフェースは、ほぼGUI（Graphical User Interface）に変わり、画面デザインや操作が複雑になったにもかかわらず、依然としてユーザが実際のプログラムを目にするのは開発の終盤になりますから、ユーザがプログラムを目にしてからイメージとのギャップに気付き、仕様変更が起こるというウォータフォールモデル開発の問題の影響範囲が更に広がっています。それでも、漫然と前例を踏襲してウォータフォールモデル開発が採用され続けています。IPA（独立行政法人 情報処理推進機構）によると、ウォータフォールモデル開発の採用率は96％だそうです。（一説によるとアメリカでは30％程度だそうです。これは統計の取り方にもよるので何とも言えませんが）

　ウォータフォールモデル開発の対抗馬としてアジャイル開発がありますが、アジャイル開発は２週間前後の短い期間で開発を行い、短い期間でリリースしていくという開発方法です。しかし、長い開発期間が必要な大規模開発では、開発初期に行った決定が開発の後半に出た要望と矛盾し、全体に影響を及ぼす変更というのが問題が起きてしまいます。つまり、ウォータフォールモデル開発とほぼ同種の問題が起きるのです。

　いずれの場合も、全体に及ぼす変更というのはデータベース設計に関わる問題です。ウォータフォールモデル開発で画面や帳票の設計を行うためにも、アジャイル開発で短い期間でリリースするにも、データの保存先・抽出元として、データベースは必要です。

　データベース設計に仕様変更が入ると、全体に波及します。しかし、現在の一般的な開発手法では、画面も帳票も仕様が固まってないうちにデータベース設計を行わざるを得ません。データベース設計がないと画面・帳票の仕様書が書けないし、プログラムも作れないからです。


　抜本的な解決策は、データベースをプログラムから切り離し、データベース設計をプログラミングの後に行う。そのためには、ビジネスロジックはストアドプロシージャに入れる必要があり、業界全体としてSQLのスキルをもっと上げる必要があります。

　そうすれば、無駄なドキュメントを書く必要はなくなるし、長時間労働せずとも結果が出せるし、もっと柔軟にシステムを構築することができるようになり、システム開発会社が「日本のホワイトカラーの生産性を上げること」に寄与することができるようになるでしょう。

　次回は、どうすればデータベース設計をプログラミングの後に行うことができるか書いていきます。

追記

　池田信夫先生のブログで「ITはもう成長産業じゃないのか」という記事がありました。私も古典的なSIerでもウォーターフォールモデル開発をやめることで、もう一段の成長が見込めると考えていますし、利用者側の生産性向上にも寄与できると考えています。