大規模なシステムのプロジェクトには必ずと言っていいほど標準化チームが設けられる。
標準化チームの主な役割は
・ユーザインターフェイスを統一する
・画面レイアウト
・操作性
・文言
・システムの方式を統一する
・共通部品
・ツール
・標準規約
・システムのドキュメントを統一する
・各種設計書
と概ね上記の様な統一系の業務に集中すると思われます。
これは間違いなく大規模プロジェクトでは統一が必要な項目であり、
標準化チームは必須だと思われます。
では何故望まれるべき標準化チームが嫌われるかと言うと
・決定が遅い
・エンドユーザーと関わらない
・コストとに対してノータッチ
が主な原因だと思われます。
■決定が遅い
私が参加した大規模プロジェクトのほとんどが、
設計書などが出来上がってから設計書のフォーマットが提示されます。
後から設計書のフォーマットが出てくるということは、一度記述した設計書を
別のフォーマットに書き移すことを意味します。これは全くの無駄です。
顧客によっては内容は変わっていなくとも再レビュー、再承認が必要となります。
この様な無駄な作業をさせされるところが嫌われる一要因です。
■エンドユーザーと関わらない
これはユーザーインターフェイスの部分でよく起こりますが
エンドユーザーが望んだ画面レイアウトに対して、標準的でない場合、
SEによって却下されます。
この際、顧客とSE側でやりとりが行われますが、揉めます。
顧客の希望に対してノーと言うわけですから当然です。
ここで標準化の意向を汲み取れるSEであればきちんと説明できますが、
訳もわからずダメだと言うSEは顧客に怒られ、標準化チームに憎しみを持ちます。
これはほぼ逆恨みですが、標準化チームが決めたことをSEが顧客に説明する事に
よって問題が発生します。
■コストに対してノータッチ
設計書のフォーマットが遅れて手戻り作業が発生した場合など
その分のコスト(工数)については、問題となります。
支払われるかどうか分からない作業の場合、増員で対応することができず、
SE側のがんばりで対応します。
この際、やりきれない思いは標準化チームに向けられます。
上記が嫌われる原因ではないでしょうか。
一方標準化チームの立場に立つと下記の様な事情があります。
■決定が遅い
標準化チームが決めれる事は当たり前の部分です。
それ以外の部分は大抵政治的な要因で顧客若しくは社の上層部より
すぐに回答がでません。よって決定が遅れます。
■エンドユーザーと関わらない
これは立場上しかたありません。必要であれば顧客に対して説明を行いますが、
画面レイアウト等でそうなった理由を話してもコストだのシステム的な理由である為、
なかなか顧客が理解してくれません。
更に顧客ではなく知識不足のSEが顧客に説明できずに文句をつけてきます。
■コストに対してノータッチ
共通部品等が遅れる場合に関しては問題ですが、仕様等で決定が遅れるのは
前述した様にほぼ政治的要因です。
標準化チームとしては作業のコスト(工数)はありますが手戻り分の工数など
保障できません。自分の仕事をしているだけです。
まとめると「標準化チームは嫌われるが致し方ない」という救いの無い結論に
なってしまいました。
SEのたまごさん私なりの回答ですが如何でしょうか?
関連
標準化チーム
http://www.hotdocument.net/
みたいなツールを使えば、標準化もできるし、
皆さんに喜ばれるかと思います。
いかがでしょうか。
ドキュメント標準化に関してはツールを利用するのも有効な手段のひとつだと思います。コストに関する問題は少しは解決できるかもしれませんね。
New2さんコメントありがとうございました。