管理項目を抑え、管理コストを低減するために、またメンバーの信頼関係を維持するためには、ルールを定めてそれを守る(守らせる)必要があります。ルールとは行動を規制するだけのものではなく、作業のやり方をガイドするものでもあります。
ルールを守るというのは本来常識ですが、「ルールを守ろう」などのスローガンをよく見掛けるということは、実はあまり守られていないということでしょう。
ルールを守れない理由には、「そもそもルールを守るという意識がないから」「もともと守れないルールだったり守る価値のないルールだったりするから」「ルールそのものが分からないから」などが考えられます。ルールの価値については別途勉強していただくとして、ここではルールそのものが分からない場合について考えます。
ルールが分からないケースには2つあります。まずは、どんなルールが存在するのか分からないケースであり、もう1つは、最新のルールが分からなくなっているケースです。
恐らくルールを決めた当初は定められたところにファイリングされていたはずです。また、そのルールブックのメンテナンスをきちんとしようとルールを決めたとも思われます。ところが、担当者の異動によりその運用が消滅してしまったり、利便性の面からルールブックを個人持ちするようになりメンテナンスも各人に任せてしまうようになったりします。そして、次第に現在有効なルールが分からなくなり、新人にとっては存在していることさえ明らかではない(暗黙の)ルールになるのです。
また、新たに作ったルールを電子メールで通知するだけのやり方もうまくいきません。せっかくの新ルールは頭の中でもメールボックスの中でも、アッという間に、ほかの情報に埋もれてしまいます。ルールを検索しようとした際に、改訂が重なっていれば、古いメールを参照する危険性もあります。
こうしたやり方を行っているシステム担当部署があるとすれば、そこは情報を有効に利用する方法を知らないシステム担当部署だといえます。
さて、よく「リーダーの主張は一貫性があるべきだ」のようにいわれます。しかし、実際には、何でもかんでも一貫性を維持することは不可能です。大規模なシステムの開発プロジェクトであれば、状況も変わるものです。無理に一貫性にこだわってしまえば、かえってプロジェクトに害をなす恐れがあります。君子は豹変すべきものです。ルールは変わることを前提にすべきです。
しかし、メンバーにしてみれば、頭の中を常に最新のルールに維持したり、個人で管理したりするように強要されることは、間違いなくストレスであり、間違いのもとです。
そこで、ルールをネットワーク上で一元管理します。なお、ルールの管理とはルールブックにアクセスしやすいようにすることも含みます。改訂の際には、改訂前の記述を削除するのではなく、取り消し線で分かるようにしておきます。もちろん、日時の記入を忘れてはいけません。
本連載第7回で、業務部門から人を出してもらう際に、システム開発にはプロジェクトチームと業務部門の協働が必要であることを認識してもらうため、システム開発とはどのような作業であるか、またどのような作業をしてもらうのかなどを書面や図解で用意しておくのがよいと述べました。
作業を書面や図解で用意しておくのは、業務部門(責任者など)に理解してもらうためですが、実は作業の変更が発生した際に、それがメンバー同士で共有できるようにしておくことも理由の1つです。書面や図解もネットワークに蓄積しておき、変更があれば変更点が分かるように修正を加え、メンバーに伝えます。変更があったのに変更を知らなければ、メンバーは戸惑いや疑問の念を抱くことになるかもしれません。こうした策は、個人のモチベーションやチームのモラールの低下を防ぐことにもつながります。
プロジェクトチーム発足時にメンバーに伝える事柄
次回もオリエンテーションで話すべき事柄を考えます。
山村 秀樹(やまむら ひでき)
某製造業において、主としてシステムの運用保守作業に従事している。仕事を通して、コンピュータ・システムに関心を持つようになり、中でもシステムの開発プロセスについて興味を感じている。
Elie_Worldを運営し、システムのライフサイクル全般にわたる作業について考えている。
Copyright © ITmedia, Inc. All Rights Reserved.