システム部門とユーザー部門

システム部門（IT部門）と対成す呼び方として「ユーザー部門」があります。簡単に言えばシステムを使用するユーザー側の組織です。ちなみにシステムを構築する企業をITベンダーというのに対して、それを購入して利用する企業をユーザー企業といいます。使う側＝ユーザーです。

システム部門とユーザー部門で衝突することは多々あります。その中でも最も多いのがサービスインの期限でしょうか。例えばユーザー部門から事務処理系のシステム実装を依頼されたとします。そしてほとんどの場合、仕様がなかなか定まらず、もしくは開発中に変更が入りスケジュールが後ろに倒れます。そして当然だがシステム部門はスケジュールの変更を求めます。しかし、ユーザー部門は仕様変更は言ってくるが、スケジュール変更は認めない事が多いです。

筆者は両方の立場を経験したことがあるので、どちらの気持ちもすごくよくわかります。結論から言うと、これは至って自然なことなのです。特にシステム開発の期限管理は綱引きみたいなもので、そもそも根拠のない「サービスイン期限」が最初に決まり、そこから様々なスケジュールが組み立てられて予定が決まっていく事がほとんどだからです。つまりスケジュールは各タスクの最低限かかる日数を足し算していって決まるのではなく、全体のスケジュールをなんとなくの分割、要するに引き算で決まっているのです。

従って期限を守るという事が目的になりやすく、ユーザー部門はある意味下請けのシステム部門にはゴリ押しでも要求をのませ、その上でスケジュールを守ろうとしますし、それが出来るかが担当者の資質なのではないでしょうか。一方、システム部門も同じことで、受注元であるユーザー部門の方が強いことが多く、要求はのまなければならないので、たとえ開発規模が拡大しようと、開発会社や自社要員を残業させてでも期限を守ろうとします。デスマーチという言葉が生まれる原因は普通にそこにあるのです。
　
じゃあSEやPGは黙って疲弊していけばよいのでしょうか？
システム部門を預かる身からしたらそれでいいわけがありません。はっきり言うとシステム部門のスケジュール管理能力が重要だと考えます。　
ポイントは2つ。

①スケジュールを明確にする。

マイルストーンをしっかり置いて、ユーザー部門による仕様決定の期限は守らせます。簡単に期限変更を許すと、どんどんエスカレートしますので、2次開発へと逃がすのが有効です。そして変更された際にはそれを履歴としてわかるようにします。はっきり言って、ここで喧嘩できない管理者ですと、結局はスケジュールが守れなくなり、結局は非難の対象になるだけです。まあ、世の中では、最後は失敗でもユーザー部門の要求を聞いてくれるシステム部門は重宝されがちですが。

②必ずバッファを設ける。

予算が潤沢ではない事がほとんどだと思います。それに対してギリギリの予算組みをしていたらほぼ破綻します。なぜなら十分な予算を用意しない案件ほど、上流工程が思い付きレベルであり、設計期間が短くなり、開発中に仕様変更になる事が「普通」であるからです。

　

ユーザー部門の立場

ユーザー部門の立場ではどうでしょうか。はっきり言ってシステム部門と対立して良いことは無いと断言しておきます。へそを曲げられると「できない」の一点張りで終わってしまうからです。それがもし外資系の外注だったならば、「撤退」されてプロジェクトは失敗となります。

こちらもあえてポイントあげるとしたら2つ。

①必ず協力関係を築く。

要件が増えたり、変わったりした場合、あくまでも「お願い」で対応してもらうようにしましょう。システム部門もただ突っぱねたいわけではありません。喧嘩がしたいわけでもありません。ユーザー部門より論理的に足し算引き算の世界で無理と言っているだけなのです。確かに感情的な部分で受け入れてくれない場合もありますが、もはやそういう関係になったらアウトです。とはいえ、上層部からの要求でサービスインは決まっているでしょう。それに対して下流工程のシステム部門に押し付けてしまうのが一番簡単ですが、それだけだと能がありません。上記で「ゴリ押しでも」と言っていて矛盾しますが、システム部門にそう思われないように上手くやる必要があるという事です。

②スケジュールは任せきらない。

これはシステム開発に限らない話なんですが、後工程に指示を出したら後は知らんという人が多い気がします。ちゃんと定期的に進捗会議を開催して、何がどのようになっているかを確認する必要は絶対にあります。もしサービスインが守れなくて、上層部へ「システム部門の開発が遅れました」と、事後で報告をするような人がいれば、「そうならないようにするのが仕事だろ」となるのは明白です。