【Web制作の品質アップに役立つ知識】
これ実務でウェブ制作に関わる人は
知っておいて損はしない情報。
10数年ウェブの開発に関わった経験
に基いているので間違いない。
システム開発ではV字モデルという
工程を経て、無事に稼働を迎える。
これはサイト制作にもLP制作にも
あてはまる共通不変の原理原則だ。
チームで制作したり一部を外注する
場合には特に留意していただきたい。
【V字モデルの解説】
①要求定義：
クライアントから提示される要件。
クライアントはズブの素人だという
前提で私たちプロはヒアリングを
しなければならない。
ここで決めたことはクライアントも
認識している約束事だから、間違い
があればやり直しだと心得るべし。
②基本設計：
サーバー構成やセキュリティなど、
ハード面の仕様を決める工程。
クライアントにはまずわからない
バックグラウンドの仕様だから、
要求定義で決めたことが実現できる
のなら特にこだわる必要はない。
③詳細設計：
ここ一番大事。
コーディングよりも大事。
ここに漏れがあるとコーディングの
結果も漏れる。ウォーターフォール
方式でモノ作りをする場合は特に。
ここもクライアントにはまずわからない
世界の話だから、プロ同士で情報共有
する場合は絶対に漏れてはいけない。
コーディングやプログラミングは
安く早く確実に作ってくれるところに
外注される場合が多いが、
仕様として提示していないことまで
カバーしてもらえるほど甘くはない。
なぜなら、外注される側は提示された
要件や仕様に対する見積を出すからだ。
提示されていない隠れたパターンまで
考慮しているときりがないし、
予算内で納期に間に合わせることも
できなくなる。
そこで発生した漏れは、V字モデルでは
前工程に起因すると考える。
要件や仕様の間違いは雪崩式にV字の
上流から下流へと引き継がれるからだ。
だから上流の工程は大事なのだ。
V字モデルでは各工程で考慮すべき範囲
が決まっているが、自分が担当する工程
のことだけ知っているのでは次の工程に
適切なバトンタッチはできない。
④コーディング：
設計工程で決めた仕様を実現するために
プログラムスキルを駆使して形を作る。
仕様通りでなければならないが、
仕様にないパターンは「穴」となり、
次の工程に引き継がれてしまう。
そう、V字モデルの折り返し、
「テスト工程」だ。
⑤単体テスト～システムテスト：
詳細設計で決めた仕様が実装されている
かどうかを動作確認するのが単体テスト。
基本設計で決めた仕様が実装されている
かどうかを動作確認するのが結合テスト。
要件定義で決めた仕様が実装されている
かどうかを動作確認するのがシステムテスト。
というように、動作確認でチェックする
観点を分けてテストする。
だから、クライアントの要件に漏れが
あったらシステムテストの時に初めて
NGが発覚する。
つまり、上流の（前の）工程で決めた
ことほど、後のほうにならないと確認
できないということだ。
これが何を意味するかわかるかな？
上流の（前の）工程での仕様決定に
間違いや漏れがあると、V字全体を
さかのぼってやり直しが発生すると
いうことだ。
コーディングレベルの仕様なら、
V字の一番浅いところまでしか
さかのぼる必要がないので手戻りは
比較的小さくて済むということ。
【複数人でモノ作りをする場合】
「自分はプログラマーだから
設計が間違ってるかどうかは
考えない。気にしない。」
とか、
「自分はデザイナーだから、
デザインさえすればあとは
プログラマーに丸投げ。」
とか、自分が担当する工程のこと
だけ勉強していたのではダメだ。
V字モデルにおいて、プロが自分の
担当する工程の仕事をきちんとやる
のは当たり前だ。
本当に大事なのは次工程の担当者に
必要な情報を漏れなく正確にバトン
タッチできるかどうかのスキルだ。
その責任は、上流工程ほど重い。
もちろん下流工程が簡単だとか楽だ
という意味ではない。
前の工程で間違いや漏れがあるほど、
V字をさかのぼる手戻りが発生する
リスクが大きいからだ。
それらのリスクは最終的に、
クライアントと約束した品質や納期
に影響する。
V字の中を複数人で分業する場合は、
全員の作業負担が上がることになる。
外注している工程があれば外注費に
跳ね返ってくる。
V字モデルにおいて仕様の伝達漏れや
仕様の間違いは、次の工程にとっては
「ミスではなく仕様変更」だからだ。
開発現場のように利害の対立する
複数の会社のエンジニアが１つの
プロジェクトチームを構成すると、
責任の問題はコストの問題だから
トラブルになりやすい。
初めての会社や取引の浅いところに
外注する場合は、このことを十分に
心しておいていただきたい。
全ては自分に跳ね返ってくるからだ。
