Webサイトの構築においては、ユーザ画面設計、それを管理する運用者用の管理画面設計が必要になる。それらを統一の取れたものとするためには、クライアント(この場合は運用者側)が何をしたいかを明確にイメージしておく事が必要となる。しかし、大抵の場合、運用フローおよび何をしたいかを明確にフロー化できているケースはごく稀である。その部分から手伝い決定を促す必要がある。
そして、このような開発における無駄には2つのボトルネックがあると思う。
1.受注から仕様凍結までの期間における無駄
2.開発工程における無駄
これらの無駄が、納期の延長や質の悪いプログラム、動作保証のないシステム、したい事が実現できていないシステムといった最低最悪なものを生み出す大きな要因のように思う。
理想を言えば、受注後すぐに案件担当PM/SEがアサインされ、下記のステップを踏めること。
- クライアントの要望をヒアリング。(PM/SE)
- 仕様策定。(PM/SE)
- 仕様書作成。(PM/SE)
- 開発スコープを決定。(PM/SE)
- 画面フローの決定。(PM/SE)
- DB設計、サーバおよびネットワークプラン構築。(PM/SE)
- 概要設計。
- 詳細設計(SE)
- テスト仕様書作成
- 開発
- 社内テスト
- クライアント検収
- 納品
なのかな、と思う。まあ、これも我流なのでツッコミどころは満載だとは思いますが。
1.受注から仕様凍結までの期間における無駄
これは、会社の組織体制や業務分担によって変わると思うが、まず仕事を取ってくる営業サイドが無駄に時間を費やす。クライアントは自社のビジネススケジュールというものがあり、納期は当然クライアントのプランに合わせて要求される。無駄に時間を費やしている間に、クライアントが要望する公開日などが迫る。営業は、受注を取りたいので、その納期を承諾する。
ここで最初の問題が発生する。クライアントとのやりとりに開発側の人間が一切タッチしていない場合、果たして開発ボリュームに見合う開発工数と納期のバランスをどうとるか。何を基準にそれを決めるのか。それが適当であるという判断は誰が下すのか。開発サイドに案件が下りてきた時点で、仕様や開発スコープがが決っていないにもかかわらず納期は決っている、という状況がまず問題である。
このあたりのフローは、会社の規模や組織体制、開発体制によってまちまちだとは思うが、そもそも、納期を決定するところで開発ボリュームを考慮されないというのは、どう考えても間違っていると思う。
そして、納期に間に合わせようと思うと、十分な設計やスコープ決定をしている時間がなくなる。当然、開発は各担当者がメールやわずかな書面による情報を元に、設計=プログラミングという最悪の手順を踏まざるを得ない。テスト仕様書なんて考えている時間もない。
2.開発工程における無駄
上述の状況がゆえに生じる問題ではあるが、クライアントのヒアリングがしっかりされないままに、きちんと設計されないシステムを作るということは、開発の手戻りが多いということである。
クライアントは、大抵の場合システムのプロではない事が多い。出来上がった画面をみて、こういう風にしてほしかった、こういう風にしてほしいな、という要望が次から次へと出てくる。それは当たり前のことなのだが、デザインや画面フローのきちんとした設計がされていないため、開発者は作りながらシステム中心の画面フローになりがちである。常識の範囲で当たり前に流れるべき画面遷移やフローはあるものの、ここのクライアントの運用フローによっては、その画面設計がベストマッチでないことはしばしばある。毎日使うわけではない管理画面は、ある程度の不便さも不便と感じないが、毎日業務で使い続ける画面となると、また要求される画面設計の思想は違ったものとなる。
要はクライアントとが何を求めているか、何をしたいと思っているのかを、こちら側が十分にヒアリングし、それを具象化する事が必要なのである。しかし、その時間やスケジュール的なゆとりがない場合が多い。
ヒアリングが十分にされないままの仕様はいつまでたっても凍結しない。仕様が凍結しないと開発スコープは決まらない。スコープのない設計はまとまりがなくなる。まとまりのない設計は、何をどう開発してほしいのかわからないままのコーディング作業となり、作ったものがユーザの要求にマッチしているのかすらわからない。そこを結局のところ、規約や前提条件や「これが仕様です」といった逃げ口上で乗り切る羽目になる。運よければ、それで開発し直しという事態は逃れられるが、使えないシステムを作った会社というレッテルは免れない。クライアントの要望どおり対応すれば、開発のやり直しという手間を生み出す。
そして、仕様の定まらないままの見切り開発、設計書のない開発、タイトなスケジュールの開発というのは、間違いなくバグを量産する。きちんとした設計さえされていれば見落とすはずのない部分を見落としたり、エラーチェックやエラー処理が正しくなされていないという結果を生み出す。
手離れの悪い案件というのは、想定外の動作、運用のイレギュラーケースへの対応漏れによるバグである事が多い。
運用フロー、目的をユーザにきっちりと認識させ、明示的に書面化するということは、ただの形式上のドキュメントを整えるという作業とは違う次元のものである。想定されうるレギュラーケースの運用フローをきちんと決めていなければ、おきうる問題、予想されるイレギュラーケース、考慮すべきイレギュラー、想定されるリスク、そういったものを割り出せないのである。そのような想定のないシステムは、運良く安全な動作だけで運用されている間は分からない。しかし、一回イレギュラーが発生すると、それに吸い寄せられるように運用の矛盾が生まれ、その運用上の矛盾したフローは、システムの矛盾につながる。そうなれば、ボロボロである。
ここで書いたことは、氷山の一角である。が、最低限のことでもある。
そんな基本的な事が出来ていないようでは、利益があがるはずもない。割く必要のなかった社内リソースをバグ回収やトラブル対応に割くのだから。
利益をあげたければ、無駄を省く事をまず考えるべきだ。
どう見ても合理的でない、実際的でない。そんな行動を繰り返すのはなぜなのか。なぜ、学習能力がないのか。
事象の原因を正しく分析できていないからである。