OXYGEN DESIGN 株式会社オキシゲンデザイン

営業日のお知らせ

ITコンサルティング

画面とシステムを分けて考える

もちろん画面もシステムのうちですが、、
ここでは画面とそれ以外のシステムを分けてお話をさせて頂きます。

よくお客様からこんな話を聞きます。
「ちょっと画面を変えただけで、ものすごく高い見積もりが来た」

たしかにシステムを発注する側からみると、少し画面を変えただけで数十万!? 数百万!?とびっくりされるのも無理はありません。
こんな見積もりを出されると、何を説明されてもシステム制作会社に対しての不信感で話が耳に入ってこない。。

この問題を解決するためには、以下の2つの点について整理する必要があります。

  1. A.  画面に何か変更を加えるだけでなく、機能自体にも変更が及ぶのか?
  2. B.  実行する機能は全く同じなのに実行する画面のデザインが変わるだけなのか?

一般的に画面のデザインは「非機能仕様」と分類され、「機能仕様」とは分けて考えるべき仕様です。

図 1 画面と機能が分離されている場合

図 1 画面と機能が分離されている場合

図 2 画面と機能が混在している場合

図 2 画面と機能が混在している場合

Aのケースの場合(図1):
利用者から見ると画面に1つボタンを追加するだけでも、実際にはボタンを押された後の動作を実装する必要がある。つまりボタンを1つ追加するだけではない為に、見積もりが高くなる。これは当然の話です。
何もない所に1つの機能を実装するのはプログラマーにとっては簡単な事かもしれません。しかし、すでにいくつもの機能が実装された上に、別の機能を追加するとなると、他の機能への影響や全体の仕様の矛盾について考慮しながら実装しなくてはならないため、思いのほか時間や費用がかかってしまうものです。

原因と解決策:
一見簡単な話のように思えるのですが、実際にこのような問題は私の支援するプロジェクトで多く発生します。
このような問題が生じる原因としては、発注者(システムの利用者)と実装者(機能を実装するプログラマー)の視点の違いがあげられます。
システムの利用者は、「この画面にこんなボタンを追加すれば良いじゃないか?うん、簡単だ!」と考え、実装者は「この機能のココを変更して、そうするとあの機能のこの部分にも変更が生じる・・・大変な作業だ!」と考えます。
また、システム利用者は「あんな機能もあったら便利だ、この機能をこう変えればもっと使いやすい」と常に考えますが、システム実装者は「はじめから想定していない機能を追加するのは困難、言われてない事はできませんよ(または、やりますけど高いですよ)」と考えます。

家の建築に例えましょう。
「この部屋を2つに分けてよ!」という家主さんの要望が、大工さんからすると「えっ!?それは大黒柱を削れということですか?」「大がかりな工事になりますので費用がかかりますよ」「リスクが大きいのでやめた方が良いですよ」を意味するような事です。大黒柱はおそらく家主さんでもわかる言葉ですので、この場合には理解してもらえるかもしれません。

しかし、それがプログラムの言語だとどうでしょう?
「えっ、●●関数に修正を入れるってことですか?」「それを修正してしまうと、影響を受ける別のプログラムが山ほどありますので、、費用がかかりますよ」
と言われると理解が出来ないため、結果として「部屋を2つにわけるだけで(壁を1つ作るだけで)すごい見積もりを出された!」と不満が生じるのです。

解決策としては、

  • ・システム利用者とシステム実装者が共通で理解できる資料を作成し、事前にレビューする
  • ・システム利用者と実装者が共にシステムの完成形を初期時に出来るだけ想像する

などがあげられます。

特に視点の違う両者が共通でレビューできる資料の作成は有効です。
通常の場合、設計・実装会社が作る資料は専門家でないと分からない言葉で書かれており、発注者がわかるような資料が作成されない事が多いです。

(備考)
私は、本来このような資料は発注する側が作るべきと考えています。
「システムを将来こうしたい」「もしかするとこんな処理ができたら良いかも」と想像できるのは発注者の仕事だからです。
また、仕様書を設計・実装者が書こうと思っても、先に述べた「視点の違い」からなかなか上手く作成できないものです。

Bのケースの場合(図2):
「ある機能を実行するためのロジックが画面のデザインに依存している」
事が考えられます。つまり画面(非機能仕様)を機能仕様と混在させてしまっている為、画面デザインの変更が機能仕様の変更にまで及んでしまう。結果、見た目のデザインだけでなく中身のプログラムまで修正が必要になり、嬉しくない見積もりを提示されてしまうというわけです。

原因と解決策:
設計者がはじめから、画面デザイン仕様と機能仕様を分けて考える必要があります。
発注する側がそのような指示を出来れば良いのですが、一般的にはこれは設計者・実装者の能力次第な部分です。
通常の場合、おそらく設計者・実装者もはじめからこのような実装は望んでいないはずです。システムに修正を重ね、厳しい納期との闘いの中で、とりあえず動けば良いという「悪魔のささやき」によって、このような状況になってしまったのではないでしょうか?
まずは図2のような現状を図1のような作りに修正しなくては、今後も同じような問題が続くと思われます。