要件定義も終わり、設計フェーズになりました。
ここから、アプリができあがるまでの間は専門性が高くなってきます。
そのため、開発を委託する側は踏み込みにくいのですが、このフェーズはアプリ開発会社に任せきりでいいのでしょうか、あるいは何かすべきなのでしょうか、悩ましいところです。
開発委託側による設計レビューは必要か？
設計フェーズにおいて、開発を委託する側がすべきことは設計のレビューです。
ただし、実際には専門性が高くなるために委託側にシステム部門がない場合は、省略されるケースが多いでしょう。
では、システム部門がいないからといって本当に省略してもいいのでしょうか？
まず、そもそも設計レビューでは何を行うのかという点に立ち戻ります。
システム開発においては、ユーザーのやりたいことを要件定義にてまとめ、その内容を具体的にどんな機能にするか、どんなデータの管理をするかといったことを行うのが設計作業です。
規模が大きくなると、要件定義者、設計者、プログラマー、テスターとそれぞれの工程にて別の担当者が作業を行いますが、実際は、ケースバイケースで全ての工程、あるいはいくつかの工程を同じエンジニアにて行うこともあります。
同じエンジニアが行うにせよ、違うエンジニアになるにせよ、委託者とは別の人間であるため、要件定義で定義したやりたいことに対して、どこか勘違い・思い違いが生ずることがあります。
その勘違い・思い違いは後の工程に進めば進むほど、大きな問題となるため、できるだけ早い時期に解消する必要があります。
そのために、開発（プログラミング）をする前の設計段階で、設計者以外の人間の視点にて、要件定義にて定義した内容に準じた機能なのか、データ管理なのか、あるいは技術面からみて正しい設計方法なのかという確認を行うのが設計レビューです。
さて、ここで最初に戻るのですが専門性の高い設計についてどうレビューをするかということです。
システムが詳しくない場合、ここだけ見る
まず、今回の開発では要件定義にてどこまで定義したかということに戻って考えます。
要件定義と言っても、開発会社ごとに要件定義書の書式も違えば、定義の範囲も異なります。そのため、詳細は次のフェーズで確認しよう。と設計フェーズに要件の詳細を決定する機会を移してしまうこともあります。
もし、要件定義の最中に明示的に「ここの詳細は設計フェーズで決定します。」というやり取りがあったとしたなら、そこは設計フェーズで必ず確認しなければなりません。実際、細かな要件でシステム全体への影響が小さいと判断できる場合、あるいは何らかの理由で要件定義の時間が足りないからそうするということも珍しくはありません。
参考：【アプリ開発】『要件定義』ではどこまで「定義」するのか？
詳細を設計フェーズに回さなかった場合であっても、以下については設計フェーズで行うことが多いため、システムが詳しくないとしても最低限抑えておきたいところです。
■エラーメッセージの内容
エラーメッセージ程度は後から変更するのは簡単です。しかし、わずかとはいえ変更するのにも時間はかかります。受け入れテストの際に、様々な不具合をつぶしながら、エラーメッセージも修正する。そんな時間すらもったいないのです。先にできることは先にしておいたほうが後の時間が有効に使えるのです。
また、エンジニアの考えるエラーメッセージは時に意味不明なことがあります。どうしてもユーザー目線になり切れないところがあるため、エンジニアならわかるけど、ユーザーから見たら、その表現だと分からないということは少なくありません。
■エラー表示タイミング
例えば、登録フォームがあるとします。そこに、名前、住所、メールアドレス等々の項目を多数入力します。そこにエラーがあった場合、どのタイミングでエラーを表示するのでしょうか。１つ目の項目を入力し、次の項目に移った直後ですか？あるいは、全ての項目を入力し「確認ボタン」を押してからですか？それとも、そもそもエラーは入力できないようにしますか？
こんなチェックについても、こうしなければならないという決まりはありません。要件定義で一律エラーチェック・表示タイミングについて定義していればいいですが、そうでなければ確認しておきましょう。
■てにをは
設計レビューの本来の目的とは少々離れていますが、「てにをは」のチェックも必要だと考えています。プログラミングが得意なエンジニアは文章力が優れているとは限りません。文章を書くって、意外に難しいことですよね？
そのため、エンジニアが設計書を書くと、日本語として表現がおかしいのでは？ということもあります。その表現がおかしいというのが、単純に間違ったものなのか、あるいは要件の勘違いによるものなのかというところを指摘し確認するのがポイントです。
また、同じような機能の設計書を書く場合、先に作った設計書をコピーして違う点だけを書き直すのは常とう手段。そこでも、変えなけばならないのに、コピー元の通りにしてしまうこともあり、そこが間違いの始まりになることもあります。
システム開発の専門家ではない人が、専門的な設計レビューを行うのは難しいかもしれませんが、専門家ではなくとも、確認できる点についてチェックすることで、後の工程への影響を少しでも抑えることができるのです。
スマホアプリを使った業務システム構築のことなら
株式会社クラボードへお気軽にご相談ください