［変更管理編］変更の影響を軽く見てはいけない
「少し変更するだけだから…」。ユーザーや、仕様策定に携わるITエンジニアは、こういう言葉で、変更作業を担当するITエンジニアに、仕様変更の指示を出しがちだ。この言葉からは、「変更による影響は、軽いものだと思いたい」という、指示する側の気持ちが透けて見える。 しかし、変更の影響を軽く見てはいけない。システムは内部で深く関連し合っていて、1カ所の変更が多くの箇所に影響を及ぼすからだ。また、変更することで新たに作りこまれるバグが発生するといった、品質面での影響も考慮しなければならない。 そのため、たとえ影響が少ない場合であっても、その範囲が限定的であることを調査・確認したり、ドキュメント類を修正したりしなければならない。ユーザーや上級SEにとっては大したことがない変更でも、変更作業の担当者には大変な作業なのである。影響は、変更する上でかさむ作業量だけにとどまらない。 また、川が上流から下流に行く
［変更管理編］変更管理をExcelでやってはいけない
皆さんの現場では、変更管理にどのようなツールを使っているだろうか。SubversionやMicrosoft Visual SourceSafe（VSS）といったツール名をすぐに思い浮かべるかもしれない。しかしそれらは構成管理ツールであって、変更管理のためのものではない。「変更構成管理ツール」と称される製品も多く、混同しがちなので簡単に整理してみよう。 変更管理ツールは、ユーザーなどから変更依頼を受け付け、影響度や優先度を評価し、実施するかどうかを判断するためのもの。実施が決まった変更依頼には、作業指示の情報を加え、作業のステータスを管理することも含まれる。 一方の構成管理ツールは、成果物（ドキュメントやプログラムソースなど）の変更に応じてバージョン管理したり、複数のITエンジニアが同時にアクセスしてもデグレードしないように排他制御を行ったりする。つまり変更管理では変更依頼を管理するのに対し
［変更管理編］コストの話を後回しにしてはいけない
ITエンジニアとしては、スケジュールが圧迫されてコストもかさむ仕様変更はなんとか避けたい。ところが利用部門の立場で見ると、変更は正義である。仕様を変更しないよりも変更した方が、システムは良くなるからだ。それゆえ、「変更しなければ業務が大変なことになってしまう」といった、変更を求めるユーザーの説明には説得力がある。 このとき、ほとんどのITエンジニアが用いる交渉の切り札は納期だろう。コストも切り札として有効なのに、「コストの話をするのは卑怯で汚いような気がする」と感じて、コストの話を後回しにしがちである。 しかし、変更する/しないという交渉の場で、コストの話を後回しにしてはいけない。ITエンジニアにとって劣勢を挽回する最大の切り札はコストだからだ。「変更依頼をシステムに反映させるとしたら、これだけコストがかさむ」という反撃をすると、ユーザーはひるまざるを得ない。 そもそも納期は、交渉をする切
［変更管理編］ユーザーの言い分を真に受けてはいけない
仕様の変更が発生した場面でのITエンジニアの腕の見せ所は、いかにユーザーのニーズを引き出して変更依頼の内容を的確につかむかである。思い込みで進めてはいけない。これは要件定義の勘所と共通している。優秀なITエンジニアほど自分なりのヒアリングのスタイルを持っていて、仕様変更でユーザーにものを言わせることに、非常に長けている。 だからといって、ユーザーの言い分を真に受けてはいけない。ひっくり返されることが少なくないからだ。 ひっくり返されるのは、システム開発におけるユーザーは1人ではないことが背景にある。例えば販売管理システムを構築する場合、ユーザーは営業部門、物流部門、システム部門、経営者と多岐にわたる。そしてそれぞれの立場でニーズを言うため収拾しづらい。一つの部門に限っても、事務担当者、課長などの立場によって、見ている世界が微妙にずれているため、聞く人によって意見やニーズは異なる。 ここでは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
