プロジェクトチーム結成──業務部門との関係を考える：ユーザーサイド・プロジェクト推進ガイド（7）（2/3 ページ）

[山村秀樹，＠IT]

業務部門からメンバーを迎える際に注意すること

業務部門出身者に望むこと

　プロジェクトチームが、業務部門出身のメンバーに期待する役割はいろいろあります。一般的に大きく分けると以下の3つになります。

　まずは、チームと出身部署の橋渡し役です。つまり、出身部署から問題点や対策、要望を積極的に挙げてもらったり、実現できない要望や新たに負担となる業務プロセスが発生する場合には、その旨を出身部署に納得してもらったりすることです。また、仕様固めに関する協力ばかりではなく、テストや本番移行にも現場の協力が必要であり、業務部門には何かと協力を要請することがあります。故に、その部署において、影響力のある人が望まれます。

　2つ目は、当然のことながら、チームに業務知識を提供することです。機能要求仕様にはモレがないことが重要です。特に、プロジェクトは特殊な業務パターンとその対処方法に関する情報を必要としています。その知識を有し、実際に言及できる人が望まれます。平たくいえば、よく業務を知っている人が望まれます。

　3つ目は、システム開発プロジェクトのチームメンバーとして機能要求仕様を作成する役割です。業務部門出身だからといって、自分の出身部署だけを担当すればいいわけではありません。システム化の範囲にあるすべての業務部門からプロジェクトメンバーを集めることはまず不可能で、普通は大所帯の部署から人を出してもらうにとどまります。つまり、プロジェクトメンバーはある業務部門の経験しかなくても、それ以外の部署も担当しなくてはいけません。故に、できれば、ほかの部署にも知られている顔の広い人が望まれます。

　また、プロジェクトが終了し、出身職場に戻った際には、周囲にシステムの利用方法を教えることやトラブルに対応することが期待されます。ひょっとして、業務部門内におけるシステム担当部署の味方として、現場からの文句に対する防波堤になってくれることが期待される場合もあるかもしれません。

業務部門は人を出せない

　プロジェクトチームが望むメンバーとは、一言でいってしまえば「優秀な人材」です。しかし、プロジェクトリーダーがその業務部門に、最も優秀な人を出してほしいと要請しても、希望が通ることは恐らくないでしょう。現場では、常に“いま”やらなければならないことが山積みなのですから。

　人を出すように要請された部署にしてみれば、人員が減ること自体、通常業務──すなわち“本業”を遂行するうえで大きな痛手となります。どこの部署でも、業務改革やリストラなどですでに人員が削減されていますが、抱えている課題や業務は減ってはいません。人員が減り、1人当たりの仕事は増えているのに、残業規制も厳しくなってきています。単位時間当たりにしなければならない作業は格段に増加しています。このように労働強化が進んでいる状態で、能力のある人を快く送り出してくれるところはありません。

　現場としては、システム化よりも直に業務に結び付く活動や設備の方にマンパワーを掛けたいことでしょう。例えば、生産現場では、生産管理システムなどよりも、実際に生産性を上げたり品質を検査したりする機械設備の方にお金やエネルギーを注ぎたがります。一般的には「品質の向上」「歩留まりの向上」「原価の低減」は、情報システムによってもたらされるよりも、生産設備の改良・改善の方が大きな効果を出すと考えられています。

　そもそもシステム化の必要性に疑問を持たれている場合もあります。例えば、生産に関する管理値の把握などは、新たにシステムを構築しなくても、業務部門が独自に作ったExcel＋電子メールなどで間に合っているかもしれず、そのような場合、人を出す以前に構築の是非に疑問を持たれます。プロジェクトリーダーが、システムの目的やメリットを力説し、そのために現場の優秀な知恵の結集が必要なことなどを強く要請しても、業務部門にとってありがたみがなければ「おれたちは困っていない」「必要ない」で片付けられます。現場に負担の掛かる全体最適など聞いてもらえません。

それでも出してもらう

　といって、プロジェクトリーダーが業務部門から人を出してもらうことをあきらめることは許されません。「痛みを分かち合いながらいいシステムを作りましょう」というヒューマンチックなせりふや「システム担当部署の人数だけでは能力的にも時間的にも作業が非常に困難である」という“泣き”も交ぜてお願いします。同時に、上級職同士で話し合いをしてもらいます。

　たいてい、業務部門は最優秀の人を出してくれませんが、仕事のできる若い人間なら出してくれます。若ければ初めての慣れない仕事にもそんなに抵抗は感じないでしょうし、本人に良い経験を積ませるという意味あるでしょう。ひょっとして、ユーザー部門にしてもいずれ自分たちの仕事にかかわるシステムの苦情をいうに当たって、プロジェクトチームとの接点には文句のいいやすい人間がいた方がいいということもあるかもしれません。

作業内容を伝える

　普通、プロジェクトに出す人を決めるのは人を出す業務部門です。自己申告制度などでシステム開発をやってみたいといっている人がいれば、その人を出してくれるかもしれません。そうであれば本人にとっても幸せなことです。しかし、現実にはシステム開発をやってみたい、という人はあまりいないでしょう。

　その業務部門にシステム開発という作業に関する理解がない場合、パソコンやインターネットが好きなだけの人間を「適当だ」として出すかもしれません。パソコンやインターネットを操作することで得られるユーザーインターフェイスなどのセンスは、システム開発でも役立つ場面はありますが、プロジェクトチームではそれよりも前述した3点を求めています。

　業務部門に人を要請する際には、システム開発とはどのような作業であり､業務部門から出してもらったメンバーにはどのような作業をしてもらうのかを書面や図解で用意しておくのがよいでしょう。これは、業務部門に、システム開発にはプロジェクトチームと業務部門との協働が必要であることを認識してもらうためと、プロジェクトチームに出す人を選ぶ際の判断材料としてもらうためであり、同時に選ばれた本人にはこれからしなければならない作業の概要を提示するためです。なお、これはチーム結成の際、オリエンテーション資料の一部となります。

　もし、小集団活動や提案活動などの改善活動をしている企業であり、幸運にもプロジェクトリーダーが複数の候補者の中から選べるのであれば、候補者の活動具合を調べてみましょう。これは業務プロセスに密着するコンピュータ・システムを考えるうえでも、また、プロジェクト活動としても、重要な要素である問題に対する姿勢や対処のセンスが分かります。