よくWebシステムの要件定義をまとめていると段階で、拡張性のあるシステムにして欲しい、ということをよく言われます。こういう機能を追加したい、こういう表示を追加したいなど、将来的に追加オーダーを取り入れやすく作って欲しいということです。

これには、改造があったとしても少しの手間で改造が済むようにしたい、改造コストを抑えたいという意図があります。

システム開発を発注した方や実際に開発に携わっている方であれば分かると思うのですが、システムの改造には結構な費用がかかります。
内容によってはイニシャルでかかったコストと同じくらいの費用がかかることもあります。

普通に考えると、最初に作ったものに対して改造を加えるのに、何故ゼロから作ったのと同じくらいの費用がかかってしまうんだ！と思われる方も多いでしょう。私は見積りを出す立場ですが、出された見積書を見てそう思う方の気持ちはよく分かります。

しかし、ひとつひとつの要望が簡単そうであっても、実際には設計をかなり変更しないといけないことも多いのです。
そこで拡張性の高いシステムですが、一体どうすれば改造コストを抑えられるシステムが作れるのでしょうか？

これは受注する側の課題でもありますので、今回はシステムの拡張性について考えてみます。

どうして拡張性の高いシステムを最初から作るのが難しいのか

まず、どうして仕様変更や改造というとエンジニアが騒ぐのか？その都度結構な費用がかかるのか？を理解しておいた方が良いでしょう。

 

エンジニアは拡張性よりシステムのパフォーマンスとメンテナンス性を優先する

まず、エンジニアがシステムを設計する場合は、システムの拡張性よりも、リリースするシステムやWebサービスが、リリース時の仕様でいかにパフォーマンスが高く稼働するかを考えます。
拡張性を重視するあまり、システム自体の表示速度や処理速度が重くなっては本末転倒です。

また、バグなどが発生した際に分散して色々な不具合を修正するより、数か所を修正すれば全体が治るようメンテナンス性の高い作りを優先します。

なぜかと言うと、バグがあった際には早急に対応することが要求されます。その時にバグの原因箇所が何か所にも点在すると、修正にも時間がかかります。バグを治していたら新しいバグを生んでしまったなんてことにもなりかねません。
ですので、そのリスクを回避し効率よく処理が行われるパフォーマンスの良い設計をするのです。

ですので、無駄を省いて効率よくという意味だと、拡張性とは遠い設計をすることが多いようです。
(これはエンジニアによってかなり異なるので、一概には言えませんが。)

 

拡張の詳細な内容が分からないと対策しようがないのが現実

拡張性と一概にいっても、将来どんな拡張をしたいのか分からなければ準備することが出来ません。
例えば、今は10個の項目が将来的には20個になる可能性は高いので、データベースには20項目は領域を取っておいてほしい、などであれば分かります。

ただ、漠然と拡張性と言われてしまうと、新規に開発する場合は準備のしようがないのが現実です。

 

では、どうするれば少しでも拡張性の高いシステムを作れるのか？

正直なところ、制作会社としてもイニシャルの開発費に近い改造費を出すのは心苦しいです。
みなさん、システムを構築される時には、どんどん機能拡張して育てていきたいと考えられておられるので、出来るだけ拡張性高く、どんどん改良していけるようなものを作りたいとは思ってます。

では、少しでも拡張性の高いシステムを最初に用意するにはどうしたら良いでしょうか？
開発側の今までの経験踏まえて書いてみます。

 

将来的にやりたいことは先にリストアップしておく。

将来的にやりたいことを、取りあえず全部リストアップしておくと良いと思います。
使ってみないと、運営してみないと分からないことが多いですが、可能な限り思い付く拡張機能をリストアップして開発者と共有しておくのです。

例えば、問い合わせフォームについては、将来的には顧客リストの管理としてデータベースに蓄積していくようなことを考えている、など細かい点においてもすべてです。

おおまかな話だけだと拡張性は薄いですが、考えていることがあるのであれば、細かいレベルでリストかして開発者と共有しておくことをお勧めします。
最初からある程度のオーダーを分かっていれば、それを加味したうえで効率よく設計してもらうことは十分検討できると思います。

やりたいことが明確であれば、追加機能の入口だけでも初期に作っておいてもらう。

もし、将来追加したい機能はあるけどイニシャルではコストをかけられない、などの事情がある場合は、メニューボタンなど入口だけでも用意しておくと良いと思います。

そもそも、入口もないところから始めると時間がかかりますし、費用もかかります。
(インターフェイスの改修などプログラム以外のところでも費用がかかってきます。)

ですので、例えば準備中でも入口(ボタン)だけ用意しておくと結構効率は変わってくると思います。

 

機能を流用できるような作りにしてもらう。

可能かどうかはシステムによりますが、例えば顧客管理機能を流用して、業者管理機能を作れないか、などです。すでにある機能を改修して他の管理機能を追加できるような作りになっていると、改造コストも抑えられるかもしれません。

要件定義や画面設計の段階で、そういうオーダーも一応伝えておくと良いかもしれません。
画面設計をシンプルにしておくと流用性も高くなると思います。

 

注意したいのは、拡張性が高いとイニシャルでコストはかかるということ。

最後に、ひとつ注意ですが拡張性を高く設計するとイニシャルのコストはどうしても高くつきます。
なぜなら設計段階で将来性を見据えて設計するので、その分時間もかかります。

例えば、登録項目は将来何個になるか分からないので、自分たちで追加や削除を出来るようにしたい、など何でも調整が出来るように設計することも可能でしょう。
しかし、それをやるとやらないでは、大きく設計や開発にかかる時間や費用は変わってきます。

将来的なことを考えると、あらゆる可能性を考慮したシステムを作りたくなりますが、あらゆることを考慮したシステムは高度なシステムになってきますので、それなりに初期費用がかかることだけは念頭に置いておいたほうが良いです。