プロジェクトチームにおける“システム担当者”の役割：ユーザーサイド・プロジェクト推進ガイド（8）（1/4 ページ）

「システム開発プロジェクト」というとシステム担当部署が担当すると思われがちだが、大企業を除くとそうした望ましい体制を作ることは難しい。そんなとき、システム担当者の知恵を生かしてプロジェクトを推進する方法とは？

[山村秀樹，＠IT]

ルーチンワークとプロジェクトの並行作業の弊害

　この連載でいうシステム担当部署は、管理部や総務課のようなほかの部／課の中にある少人数のグループであることを想定しています。このようなシステム担当部署は人員が極めて少なく、新しいプロジェクトに取り組むときには全員参加ということになります。プロジェクトチームはシステム担当部署の内部に組織され、メンバーはプロジェクトと既存システムの保守などのルーチンワークの両方に携わります。

　これに対し、例えば、製造業における機械設備を設計・構築する部署は規模も大きく、保守に関しては専門の部署が別にあり、設計に専念できる環境になっている会社も多いでしょう。機械設備とコンピュータ・システムの開発についての違いはいろいろありますが、機械設備の設計・構築と同じレベルでコンピュータ・システムの新規開発を論じることは無理があります。

　ルーチンワークとプロジェクトを並行に担当した場合、ルーチンワークであるメンテナンス作業に時間を取られ、プロジェクトに十分な時間をかけられません。また、既存システムにトラブルが頻発するようならば、プロジェクトの進ちょくにとって大きな外乱要因となります。

可用性の低い既存システムがプロジェクトに及ぼす影響

　特に、既存システムの老朽化に伴う更新プロジェクトでは、末期状態のシステムを保守しているのでハード故障が頻発します。更新間近なのだからと部品交換をケチっていると、“しっかりと”トラブルが発生します。

　ソフト的にも、トラブルの発生が多くなってきます。末期状況のシステムや出来のよくないシステムは、発生する“症状”に対してその場しのぎの対策やオペレータに不自然な操作を強いる対応などを積み重ねており、最後までトラブルが消滅することはありません。

　例えば、システム内部に不整合があったり、関連するシステムと改造の同期が取れていなかったりすれば、入力の際に人間があらかじめデータを加工したりチェックしたりすることが必要となります。エンドユーザーは注意事項を聞かされた当初は注意してくれますが、時間がたったり人が代わったりして、その注意事項が忘れ去られるとトラブルになります。そうでなくても、注意事項が山のようにあり、それぞれのケースに適応しなければならないようなシステムであれば、注意をキチンと守ること自体が不可能です。また、人は忙しいときには注意力は散漫になり、トラブルが発生しやすくなります。

　ついでながら、“ドキュメントが不備な困ったシステム”の更新プロジェクトであれば、そのシステムの調査のために、運用中のシステムをテスト操作したり、テストデータを入力したりすることがよくあります。このことによって、想定外の重大なトラブルが発生するケースもあり、復旧作業や対応にかなりの時間を取られることがあります。

プロジェクト作業の低効率

　システム担当部署はトラブルが発生すれば、即座にそれに対応しなければなりません。新たなシステム開発どころではなくなります。

　運用・保守担当者がいくらプロジェクトに没頭したくても、既存システムにトラブルが発生すれば、すぐさま思考をトラブル対応に切り替えなければなりません。そのときまで考えていたことは頭の中から揮発します。トラブルが片付いて、プロジェクト作業に復帰する際には、後戻りして考え直さなければならず不経済です。

　トラブル発生が打ち合わせ中であった場合は、中座しなければなりません。大トラブルの場合は、システム担当部署のメンバーがゴッソリと抜けて、プロジェクトの打ち合わせそのものが中止になることがあります。関係部署のスケジュール調整に苦労した打ち合わせであっても、再度スケジューリングからやり直さなければなりません。

プロジェクト内の迷子

　打ち合わせを中止しない場合であっても、トラブル対応に出動する人を除いて打ち合わせに残った人たちだけで各案件をドンドン決定することが多くなれば、トラブル対応に出動する人のプロジェクトに関するモチベーションが低下するという問題が出てきます。

　システム担当部署のメンバーは運用・保守を通じて得たノウハウがあり、既存システムに出来のよくないものがあれば、反省に基づいた新システムに対するアイデアもあることでしょう。これらを盛り込むことなく、あるいは相反する事項が決定とされればやる気はなくなります。当然ながら、運用・保守現場のノウハウを利用することができないこと自体も大きなデメリットです。

　さらには、打ち合わせなどへの欠席を重ねた結果、プロジェクトの進ちょくや要求仕様の現状が分からなくなってしまうと、その人はプロジェクトメンバーとされていながらプロジェクトの迷子になってしまいます。こうなってしまえば、その人にとってプロジェクトは“X＝バツ”状態です。全プロジェクトメンバーが現時点の機能要求仕様がどのようになっているのかを即座に見えるような仕組みや資料の整備が必要です。