プロジェクトチームのマインドとルールを方向づけるには:ユーザーサイド・プロジェクト推進ガイド(12)(2/2 ページ)
システム開発の経験に乏しいメンバーからなるプロジェクトチームは、最初の“オリエンテーション”が大切だ。前回に引き続いて、オリエンテーションで話すべき内容について考察する。
ルールはネットワーク上に存在することを伝える
管理項目を抑え、管理コストを低減するために、またメンバーの信頼関係を維持するためには、ルールを定めてそれを守る(守らせる)必要があります。ルールとは行動を規制するだけのものではなく、作業のやり方をガイドするものでもあります。
ルールを守るというのは本来常識ですが、「ルールを守ろう」などのスローガンをよく見掛けるということは、実はあまり守られていないということでしょう。
ルールを守れない理由には、「そもそもルールを守るという意識がないから」「もともと守れないルールだったり守る価値のないルールだったりするから」「ルールそのものが分からないから」などが考えられます。ルールの価値については別途勉強していただくとして、ここではルールそのものが分からない場合について考えます。
ルールが分からないケースには2つあります。まずは、どんなルールが存在するのか分からないケースであり、もう1つは、最新のルールが分からなくなっているケースです。
恐らくルールを決めた当初は定められたところにファイリングされていたはずです。また、そのルールブックのメンテナンスをきちんとしようとルールを決めたとも思われます。ところが、担当者の異動によりその運用が消滅してしまったり、利便性の面からルールブックを個人持ちするようになりメンテナンスも各人に任せてしまうようになったりします。そして、次第に現在有効なルールが分からなくなり、新人にとっては存在していることさえ明らかではない(暗黙の)ルールになるのです。
また、新たに作ったルールを電子メールで通知するだけのやり方もうまくいきません。せっかくの新ルールは頭の中でもメールボックスの中でも、アッという間に、ほかの情報に埋もれてしまいます。ルールを検索しようとした際に、改訂が重なっていれば、古いメールを参照する危険性もあります。
こうしたやり方を行っているシステム担当部署があるとすれば、そこは情報を有効に利用する方法を知らないシステム担当部署だといえます。
ルールは変わるもの
さて、よく「リーダーの主張は一貫性があるべきだ」のようにいわれます。しかし、実際には、何でもかんでも一貫性を維持することは不可能です。大規模なシステムの開発プロジェクトであれば、状況も変わるものです。無理に一貫性にこだわってしまえば、かえってプロジェクトに害をなす恐れがあります。君子は豹変すべきものです。ルールは変わることを前提にすべきです。
しかし、メンバーにしてみれば、頭の中を常に最新のルールに維持したり、個人で管理したりするように強要されることは、間違いなくストレスであり、間違いのもとです。
そこで、ルールをネットワーク上で一元管理します。なお、ルールの管理とはルールブックにアクセスしやすいようにすることも含みます。改訂の際には、改訂前の記述を削除するのではなく、取り消し線で分かるようにしておきます。もちろん、日時の記入を忘れてはいけません。
本連載第7回で、業務部門から人を出してもらう際に、システム開発にはプロジェクトチームと業務部門の協働が必要であることを認識してもらうため、システム開発とはどのような作業であるか、またどのような作業をしてもらうのかなどを書面や図解で用意しておくのがよいと述べました。
作業を書面や図解で用意しておくのは、業務部門(責任者など)に理解してもらうためですが、実は作業の変更が発生した際に、それがメンバー同士で共有できるようにしておくことも理由の1つです。書面や図解もネットワークに蓄積しておき、変更があれば変更点が分かるように修正を加え、メンバーに伝えます。変更があったのに変更を知らなければ、メンバーは戸惑いや疑問の念を抱くことになるかもしれません。こうした策は、個人のモチベーションやチームのモラールの低下を防ぐことにもつながります。
プロジェクトチーム発足時にメンバーに伝える事柄
- 業務部門に積極的に顔を出して、現場で要求を見つける努力をすることを説く
- 情報共有することを説き、成果物は一元管理する
- 常に最新ルールをネットワーク上に整備し、それを参照するように伝える
次回もオリエンテーションで話すべき事柄を考えます。
筆者プロフィール
山村 秀樹(やまむら ひでき)
某製造業において、主としてシステムの運用保守作業に従事している。仕事を通して、コンピュータ・システムに関心を持つようになり、中でもシステムの開発プロセスについて興味を感じている。
Elie_Worldを運営し、システムのライフサイクル全般にわたる作業について考えている。
- 業務の可視化で、多くの関係者を巻き込め!
- 工夫と規律で「システム用語辞書」を実現せよ
- 社内用語を統一する「用語辞典」作成のポイント
- 言葉の不統一がもたらす業務とシステムへの悪影響
- ドキュメントを作成しないユーザーは、失敗する
- プロジェクトメンバーがそろう前に行っておく事前準備
- システム開発プロジェクトの魅力を伝えよう
- プロジェクトチームのマインドとルールを方向づけるには
- プロジェクトキックオフ! オリエンテーションで話すこと
- プロジェクトリーダーは十二分な準備で自信を生み出せ
- プロジェクトチームのリーダーに向く人、向かない人
- プロジェクトチームにおける“システム担当者”の役割
- プロジェクトチーム結成──業務部門との関係を考える
- プロジェクトチームに付きまとう制約を打破するために
- タイプ別プロジェクトチームの問題点
- 不良システムを作らないプロジェクトの枠組み
- スケジュールとコストは、ユーザー側が始めからつかめ
- 最初が大切──構築システムの“概要”を作る
- ユーザー企業側プロジェクトチームの使命と役割
Copyright © ITmedia, Inc. All Rights Reserved.