やらないことを決める - システム設計で考えること

システム設計では、やらないことを決めることも大事

システムの設計が進み、ある程度仕様が固まってくると、システムに対して夢が膨らんできます。
そして、あんな機能がほしい、こんな機能がほしいとなり、システムの規模が大きく膨らんでしまいます。

しかし、すべての機能を取り入れることでよいシステムとなるわけではありません。
なぜなら、多くの機能が実装されているからといって、そのすべてをユーザーが使いこなせるとは限らないからです。
そして、せっかく作った機能であっても、ユーザーが使えない機能であっては、無駄にお金をつぎ込んだだけで、十分なソリューション効果が得られない結果となります。

そのため、システムの設計(特に要件定義~基本設計の期間)の際に、「どの機能を実装するか」と同時に「どの機能は実装しないようにするのか」を決める必要があります。

やらないと決める基準

システムを作る場合には、あらかじめ予算と開発期間が設けられると思います。
また、業務システムであれば、業務の効率化を目的としていると思います。
そして、パッケージソフトWebサービスのようなシステムであれば、コンセプトやターゲットが存在すると思います。

そのため、やらないと決める基準として、予算や規模に対する費用対効果や、コンセプトやターゲットに合致しているかを検討して、機能の実装要否を決めることとなると思います。

具体的には、以下の条件に合致する場合は、基本的には機能の実装は不要だと思います。

  1. 現場ではほとんど行われない業務のための機能
  2. すでに効率化されている業務のための機能
  3. 現場の業務のやり方とシステムの運用方針がかけ離れた機能
  4. メインのターゲットの性質と機能があっていない機能(20代がターゲットなのにズームボタンによる文字サイズの変更機能を実装する)

なお、1については、ほとんど行われないが、もし発生した場合に手間がかかるような場合は、システムへの機能の追加もありだと思います。
ただし、機能の使われる頻度を考えると最低限の機能にしておいたほうが無難だと思います。

また、2については、すでに効率化されているため、新たにシステム化したところで大きなソリューション効果は得られません。
(そもそもユーザーの要求でないため、実装不要となります)
そして、3については、ユーザーがシステムを使いずらいと感じてしまい、作ったところで結局使われない機能となってしまう可能性があります。

アフィリエイトのコーナー

はじめよう! プロセス設計 ~要件定義のその前に

はじめよう! プロセス設計 ~要件定義のその前に

要求定義のチェックポイント427

要求定義のチェックポイント427

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

システムを「外注」するときに読む本

システムを「外注」するときに読む本

↓全然関係ないけど、ヒロアカおもしろいよ!!