仕様書や要件定義を作成すべき案件
システム開発の分野に置いて要件定義は必要不可欠で、そのシステムで何を解決するのか、どこをゴールとするのかが明確でないとプログラマーは開発できません。
ですが、その要件というのは実はクライアントが把握しているのかというとそうでもなくて、実際に要望を要件定義やら仕様書に落とすことはなかなか難しかったりしますし、そもそも要件定義が向いてなかったり、実はそもそもできない場合もあったりします。
目次
要件定義を厳密に作成すべき案件
インストール型ソフトウェアの場合
例えば、Windowsにインストールするソフトなどを作成する場合、要件定義が必要不可欠でかつ非常に向いてると思います。
その理由はインストール型のアプリはコンパイルが必要でソフトを見れる形にするまでに時間がかかるからです。さらに、クライアントがそのソフトを確認するのにも時間がかかります。いちいちインストールしたりアンインストールするの面倒ですしね。
インストール型だと、業務ソフトなども多いと思うのですが、その場合業務フローを把握してそれを仕様に落とし込めば良いので、要件定義しやすく向いてると思います。
余談ですが、要件定義を厳密に作成する文化は大手のSierからの影響が大きいのではないかと思います。
公共系の入札案件や病院、病院の業務システムなどは要件定義が強く求められる分野だし向いてると思います。
そこの下請け会社が大手にならって要件定義書を作る文化ができたのではないかなぁと。
ウェブサービスの場合の要件定義
ウェブサービスの場合、要件定義して発注すること自体がそもそも向いてないと思います。
なぜなら日々ユーザーが増えたり、機能改善や機能追加が求められるウェブサービスの分野では要件自体が変わるし、日々育てていく必要があるからです。
当社もそもそもウェブサービスで納品は難しいと感じてますし、要件定義するよりプロトタイプを作ったほうが早い場合が多いです。
チェックやデバッグが簡単にできる
ウェブサービスはブラウザで動作するのでコンパイルしたりインストールしたりする必要がありません。
修正点の確認はブラウザをリロードするだけでできるので、テストも簡単です。インストール型のソフトウェアでは面倒だったデバッグや仕様変更も比較的早く対応できるのが最大の利点です。
多少曖昧な仕様でも一旦作成して画面で確認するということが容易にできるので、仕様を固めずにA/Bテストしてどちらかを採用するなどというやりかたも良いかもしれません。
正しい要件を誰も知らない
例えば、管理画面を作成するという場合、どういうUIが使い易いのか、メニューのショートカットは何を置くべきか、などこういう課題を仕様として要件定義すべきでしょうか。
要件とする場合、ワイヤーフレームの作成は誰が行うのか。
そのUIが本当にユーザーにとって使いやすいのかどうかの検証はどうやるのか。そのデザインがUIやUXの問題を解決してくれているのか？
などなど、ウェブサービスでは仕様を定義したところでそれが正しいかどうかがわからないことが多々あります。
また、テクノロジーの進歩も日進月歩ですし、ユーザーの動向や外部の環境も日々変わっていきますので、プロトタイプでリリースしてテストを繰り返して改善するのが良いかと思います。
モバイルアプリの場合の要件定義
モバイルアプリはインストール型アプリなので本来は可能な限り要件定義して仕様に落とし込んだ方が良いです。ウェブサービスほど簡単にUIも変えられないし仕様の変更があると面倒です。
とはいえ、PCソフトとの違いは、スマホユーザーの数が急激に伸びているところで、PCユーザーの数を圧倒的に超えています。そのためプラットフォーマー側もアプリ開発を支援するためにリーンスタートアップしやすい環境を提供してたり、サードパーティーが便利なアプリ開発環境を提供していたりします。
プロトタイピングツールを使う
プロトタイピングツールは実際のデータがない状態でUIだけのアプリデモを作れるツールです。無料で提供されているサービスもありますので、仕様をガチガチに固めて開発会社に発注するより、自分でプロトタイピングツールでデモを作るほうが早くて伝わりやすかったりします。
例としてProttを紹介します
Prottは「1000の会議より、1つのプロトタイプというキャッチフレーズ」でおなじみのプロトタイピングツールです。
UIパーツの組み合わせで画面デザインができるだけでなく、画面の遷移などもマウス操作で簡単に作ることができます。
さらに、作成したプロトタイプのアプリを実機のモバイル端末でデモ起動することもできます。
要件定義書をExcelやらWordやらで書き出すよりわかりやすいし早いです。
要件定義より大事なアーキテクチャの決定
要件定義は大事なのですが、それよりも大事なのはどういうアーキテクチャを採用するかという技術的決断です。
ウェブサービスでもアプリでも最悪「ダメなら直す」ということができるのですが、それは最初に選んだ技術に間違いがない場合です。
SNSやアプリのAPIを作るのにWordPressを選んだりすると、改善したり機能追加すればするほど技術的負債が増えていって収拾がつかなくなっていきます。
最初の決定を間違えると後々面倒なことになるので、そこにコストをかけるべきです。
どういう案件に対して、どういう技術を採用するのが良いのかはなかなか判断難しいですが、よければ一度ご相談下さい♪
最新記事 by まなびん (全て見る)
- 日本最大級セミナーのポータルサイトの開発に関わらせて頂いています - 2019年10月24日
- エンジニアとして求人応募する際に意識してほしいこと - 2019年10月23日
- 受託が忙しく自社サービス開発できないので開発メンバー募集！ - 2019年1月28日