update it, Inc.社長のブログ

日本のシステム開発というのは建設業に例えられることが多く、開発体制においてゼネコンにあたる元請けから協力会社またはパートナーと呼ばれる下請、さらにその孫請け…という構造になっています。元請けの会社は全体を取り仕切り、開発においては現場監督となるわけです。

昨日ある方と話をしている際に、最近元請けに相当する会社が利益優先で物事を考えるところが増え、どんどん下請けへの丸投げ構造がひどくなっているということを聞きました。効率化を追求するあまり、中身をまったくチェックしないままスルーされていることがままある、ということなのです。

現場監督の話でいえば、建設を知らない人が現場監督をしている、という話になります。建物の中身は建設現場で働く下請けに人に全部任せて、ろくなチェックもせずにそのまま客に引き渡してしまう、ということです。

問題なのは、元請けで現場監督をしている人たちがシステム設計に関する教育を十分に受けていないということ、そしてシステム開発の経験が十分でないまま、いきなり「現場監督」をさせられているということでしょう。

建築の世界では耐震強度をごまかした偽装設計が世間を騒がせ、大きな問題になりましたが、システム開発の世界でも上記のような状況が進行しているとすると、由々しき問題です。最近はシステムのトラブルが原因で実際に会社が傾くような大問題となるケースも良く聞くようになりました。対岸の火事と思わずに早急に手を打っていかないと、いずれ大変なことが起きるかもしれません。

システムがうまく機能しない大きな原因の１つに、非機能要件が満たされていないことがあります。機能要件についてはやらなければならないことが明確なので、きちんと合致していることを検証するのは比較的容易ですが、非機能要件については定義そのものがぼんやりとしている場合が多く、どこまでやれば満たされていると判断できるのかが釈然としない場合が多いのではないでしょうか？

非機能要件の例としては、こんな項目があります。
・性能要件
・キャパシティ要件
・移行要件
・運用要件
・障害対策要件
・セキュリティ要件

「非機能要件については定義そのものがぼんやりとしている」と書いたのですが、これは非機能要件は「?できる状態」をあらわしているものだからではないかと思います。システム全体に渡って定義された状態を満たしていることを検証しなければならないわけですが、「状態」を満たしていることをシステムの外部から見て確信できるようにする、なんてことはなかなか難しいものです。

少し前に、大規模ＥＣサイトのリニューアル後に大規模な障害が発生したという件がネット上で話題になっていましたが、これなども一言でいえば、性能要件とかキャパシティ要件といった非機能要件に問題があったと言えます。それらがきちんと検証されていたかどうかは知る由もないのですが、もし当事者となって考えた場合、じゃあ実際問題、どうやって本番運用前の段階で問題が発生しないことを検証するのか？　というのはかなり難しい問題だと思いませんか？

こういった問題に対処できるのは、似たような環境で多くの事例・経験を積んだ組織ということになるのだと思います。これこそシステム開発の本来のノウハウといえる部分ではないでしょうか？