日本のホワイトカラーの生産性を上げるには３
日本のホワイトカラーの生産性が低い大きな原因の一つに、システム会社の生産性が著しく低いことがあると考えています。
SEはいわゆる３Ｋ職といわれますが、仕様変更を防げたら無茶な長時間労働をする必要はないのです。しかし、システム会社が仕様変更を防ぐのではなく「顧客に仕様変更を認めさせよう」という防衛策を採ってきたから、無駄なドキュメントを大量生産することになり、顧客側が大量のドキュメントを読むのに時間が掛かるため承認時期の遅れにつながり、結果として工期が短くなり、いわゆるデスマーチという状態になります。それでも、開発の後半（土壇場）に要望が出てきて、それが「仕様変更と認められない」ということは多々起こっています。どんなに大量の管理資料を作っても、デスマーチがなくなっていないのがその証拠です。
システム会社にとっても、ユーザ企業にとっても、なんのメリットもない悪循環が起きています。
そういう悪循環を断ち切るために、前々回からビジネスロジックをストアドプロシージャに入れるべきということを書いてきましたが、こういうことを書くと、「パフォーマンスに拘っている」と誤解されることがある。しかし、何度も繰り返しているとおり、パフォーマンスは二次的な効果であって、本題となるのは、データベース設計をすることなくユーザインターフェースを先に製造すること。データベースとユーザインターフェースを疎結合にすることによって担当する技術者を分離することによって、システム会社の生産性を上げることを目指して書いています。
明確に目的を書いているにもかかわらず、「パフォーマンスに拘っている」と誤解されるのは、残念なことに、ストアドプロシージャ（ファンクション）を使った開発が一般的ではないことの証明です。（炎上するのもしかり）
暗黙の前提として、「パフォーマンスが悪いときにはストアドプロシージャを検討する」というのが常識となっているからです。
その原因は歴史的に仕方がなかった面はあります。
1990年代後半から汎用コンピュータやオフィスコンピュータをPCサーバへダウンサイジングするために、RDBMSがメインストリームになっていきましたが、ちょうど2000年問題を控えIT技術者が非常に不足した時代で、そのときRDBMSを担当した技術者のほとんどはCOBOLの技術者でした。
人手不足のため、十分なスキル獲得の時間を与えられることがなかったCOBOLの技術者にとって「SQLはファイルの読み書きの構文が変わったに過ぎない」という感覚で使わざるを得ず、その考え方がシステム会社の文化として定着してしまいました。その後、ユーザインターフェース側の言語は、本格的にオブジェクト指向言語に変わっていきましたが、定着してしまった文化が見直されることはありませんでした。
もう一度以下の図1を見てください。
図1 オブジェクト指向での開発
この形は全体を俯瞰して見たものですが、1990年代後半からオブジェクト指向言語に置き換わった現在に至るまで、ごく小さな部分でO/Rマッパなどが出てきたりしていますが、根本的な部分は何も変わってない。仕様変更が起き「１．３．４．」と3カ所も修正しなければいけない非合理も、パフォーマンスが悪かったら「１．３．４．」と3カ所を修正すればよいという非合理も、それが文化として定着している以上、正しいことになってしまいます。簡単には覆せません。
もう一つ、ストアドプロシージャを使った開発が流行らない理由は、当時のデファクトスタンダードのRDBMSであるOracleで、SELECT系のストアドプロシージャ（ファンクション）を書くのが非常に面倒である。ということも影響しているでしょう。特に1990年代後半バージョンではできませんでしたから、ストアドプロシージャはバッチ処理のためにある。SELECT系の処理をするときにはバッチ処理のようにワークテーブルにデータを作り、それを固有のキーで取り出すという処理が一般的でした。
これらは既に文化として定着していますが、それを覆したいというのが私の起業した理由になりますので、覆すための活動を続けたいと思います。
