woman-in-glasses-at-meeting_925x

適当に集まって、適当に打ち合わせをしているだけでは、絶対に話はまとまりません。
特に具体的な成果が求められるプロジェクトでは、打ち合わせをする際のルールが必要です。

私が基幹システム導入の際に周知したグランドルールをご紹介します。

１．意見調整がつかない事項については、まず基本方針に立ち返って判断する

打ち合わせをしていると、利害関係がぶつかりあい、意見調整できないことが多々あります。
その場合は、基本方針に立ち返って判断します。

基本方針とは、例えば基幹システム導入の場合、

・現状業務の整理・見直し
    未利用、不要機能の削除
    機能の有効利用
    業務の質の向上

・導入コストの削減（限られた予算での更新）
    パッケージソフト標準機能の活用
    ※現行システム機能の全てが、そのままに新システムに移行されるわけではない

などがプロジェクト開始時に挙げられているはずです。

基本方針は、プロジェクトの憲法とも言えるものです。
意見が対立したときは、どちらの意見がこの基本方針に沿っているかで、判断すれば良いのです。

でも打ち合わせに集中していると、ついつい基本方針を忘れがちです。
基本方針の意識づけを強くするためにも、グランドルールで明文化しておくべきです。

２．どうしても意見調整がつかない場合は、プロジェクトオーナーによる全社的視点での判断を仰ぐ

プロジェクトの憲法ともいえる基本方針があるとは言え、それでも意見調整ができない場合があります。

ただでさえ社内での立場が弱い情シスは、現場に押し切られる恐れがあります。
情シス（＝会社）が不利になる恐れを感じたら、プロジェクトオーナー（役員）に頼ります。
プロジェクトオーナーは、情シスの直系上司に当たることが多いですので話しやすいでしょう。
もちろん情シスが持って行きたい方向に誘導するのです。

キックオフミーティングと打ち上げの飲み会しか出席しない役員も、こういうときは利用できます。
頼られたほうも「仕方ねえなあ・・・」という感じで、嫌な気分にはならないでしょう。


打ち合わせにおいて、全てを論理的に白黒つけるのは、なかなか難しいところがあります。
情シスとしては、こういう泥臭いオプションも確保しておくべきです。

３．時間厳守、話は簡潔・明瞭に

プロジェクトに限らず、打ち合わせは時間厳守です。当たり前のことです。

私がプロジェクトリーダーの時は、時間が来たら部屋の鍵まではかけませんが、
ドアを閉めて、さっさと打ち合わせを開始します。

絶対に遅れた人を待ちません。
遅れて入ってきても、話を戻すことなくそのまま進めます。

当たり前のことです。
時間通りに来てくれた他のメンバーの時間を無駄にすることはできません。

もちろん打ち合わせが終わる時間も厳守です。
なるべく早めに終わるようにします。


それを続けていると、大抵遅刻が減ってきます。
早く集まって、早く打ち合わせを終えようとしている私の意図が伝わるのだと思います。


打ち合わせ時間をオーバーしないためには、話を簡潔・明瞭にする必要もあります。

愚痴に近い話をダラダラとされては、終わるものも終わらなくなります。
アジェンダに目を通してこない、宿題をやってこないでグダグダというのは問題外です。


現場の担当者レベルだと、普段皆の前で話す機会が少なく、うまく話せないこともあります。
分かりやすく話すこともメンバーの義務だということを明言しておく必要があります。

４．建設的な意見を出す

自分の仕事だけが大変だとばかりに、愚痴だけを言う人がいます。
こういう人は愚痴を言うのが、自分の仕事だと思っているのです。大人なのに困ったものです。

愚痴だけではなく、改善のアイデアを出し、さらに実行するまでが正社員の役割です。

関連記事：


改善するアイデアがないなら不平・不満を言うな、ということをメンバーに浸透させます。

５．プランのない意見は進行の妨げになるので排除する

いくら前向きでも、実現不可能とも言えるプランを話されても話が進まなくなります。
そもそもプランとは、QCD（Quality：品質、Cost：価格、Delivery：納期）を漏れなく満たしている必要があります。

実現不可能なプランは、QばかりでCとDが非現実的になっているはずです。

ＣとＤの制約がある中で行うのがプロジェクトです。
ブレストではないので、極端な意見を尊重する必要はありません。


プロジェクト進行を妨げるような意見は切り捨てても良いのです。

６．あるべき論は進行の妨げになるので排除する

あるべき論は、議論の前提をひっくり返そうとするような意見、という形で現れることが多いです。
上のプランのない意見とも似ています。

あるべき論も正論であるだけに議論が進まなくなります。

正論だけ言い放って、自己満足に浸っている人には、
「別途、議論の場を ”自分で” 設けて下さい」
「このプロジェクト発足前に話し合うべき内容です」
といなします。

「お客さん」としてプロジェクトに参加しているから、のんきなことを言えるのです。
こういう人には「ご自分でどうぞ」と水を向ければ、「いえいえそれは・・・」とトーンが下がります。所詮その程度の覚悟なのです。


プロジェクト中は清濁併せ呑み、とにかくプロジェクトを少しでも前進させることに、意識を集中する必要があります。
それに協力しない意見に耳を貸さなくても良いです。

７．意見は皆がいる打ち合わせの場で言う

気が弱いんですかね、慎ましいんですかね。
会議が終わってから情シスに個人的に「さっきのは実は・・・」とささやいてくるずるい人が本当に多いです。
「で、何が言いたいの？」と思います。こういう人は情シスに代弁させたいのです。子どもか？(笑)

こんな人に関わると、情シスが厄介ごとを抱え込まされることになるので、予防線を張っておきます。


それでも「相談」と称し、絡んでくる人には、
「メーリングリストに提案を投げてください」
「次回打ち合わせの議題に入れますので、そこで説明してください」
などと返し、公の場に引きずり出すようにします。

８．ベンダーに対して「強気に言う」＝「要望を言う」ではない

ベンダーに現場ユーザが、
「○○できないと困るんですけど！」と詰め寄る場面、ITのプロジェクトにありがちです。

本人は強気に言っているつもりですが、結局要望を言っているだけですから(笑)
「言ったった」とドヤ顔する人もいますが、全て開発コストに跳ね返るだけです。

情シスとしては、「あーぁ、言っちゃったよ・・・」というところですね。
QCD（Quality：品質、Cost：価格、Delivery：納期）のうち、CかDにダメージを与えるからです。プロジェクトの妨害行為とも言えます。


グレーゾーンをグレーのままで放置せず、先回りしてベンダーにぶつけ、
こちらに有利な条件を勝ち取ることが強気と言うことです。

事前に勘違いメンバーに釘を刺しておくことで、コスト増大・納期オーバーを防ぎます。

９．打ち合わせ欠席時は他の人に委任する

打ち合わせ欠席時は
「会議に出られませんので○○さんに委任します、決定には従います」
とプロジェクトリーダーに伝えるようルール化します。


情シスが苦労してスケジュール調整しているのに
「○月○日は予定があります」とだけ言い放つ人が多いです。

何が言いたいんだろう、と思います。

飲み会の日程調整でもいますよね。
幹事の苦労を尻目に「○月○日はダメ、×月×日も予定あり」とだけ言い放つ人が。
そういう人に限って来ても来なくてもいい人だったりします(笑)

「私がNGの日でも構わずやってください。また次の機会に出席します。楽しんできてください」
と先に幹事に伝えるのが大人の対応でしょう。


プロジェクトでも同じです。

はっきり言わせてもらうと、情シスに委任して欲しいんですよ。
大人なんだからそれをこちらに言わせるな、というところです。

欠席するという事は、事前に予定が分かっている、他の大事な用事があるんですよね。
こっちのプロジェクトの優先順位は低いんですよね。

だったらプロジェクト（＝情シス）の決定事項に異議を唱える資格はないはずなんですよね。


厳しいようですが、これらを守ってももらわないと、プロジェクトがまともに進みません。
反感を買うのを覚悟で宣言してしまいましょう。

受け入れられないならプロジェクトリーダーを降りてもいいと思います。
どうせそんなプロジェクトは破綻してしまうでしょうから。


上記9つのルールには、内容的に重複する部分もあるのですが、細かく分類することで、「自分は正しいことを言っている」とメンバーが勘違いするのを防ぐ狙いがあります。


要するにプロジェクトメンバーに伝えたいのは、
「お客さん感覚ではなく、当事者意識を持ってプロジェクトに参加しろ」
ということです。

自分がプロジェクトを仕切る側に立ったら、言われなくても守るであろうルールばかりです。

なんと当事者意識に欠けるメンバーの多いことか・・・
同じ会社なんですから、一蓮托生だと思うんですけどね。


これらのルールについては、プロジェクトのキックオフ以降、事あるごとにしつこく確認したほうが良いです。
メンバーにとって、耳の痛い内容なので、すぐになあなあになってしまうからです。


普段の仕事や会議でも、常に意識しておくべき大事なことだと思うのですが、何故かITの時だけ明確に意識しなくてはいけないんですよね。

関連記事：
仕様策定1/3-キックオフミーティング