このエントリーをはてなブックマークに追加LINEで送る

14.7. 指揮命令

ハッピィ・エンジニアリング表紙

 火のついたプロジェクトの実施体制上の問題はいくつかある。

 

  • 標準的な作業プロセスがない
  • 作業ルールがない、あるいは不明確
  • 指揮命令が具体的ではないなど、指示の出し方が悪い
  • 指示を完遂できないなど、要員スキルが低い
  • 手抜きや作業ルールを守れないなど、メンバのモラルが低い

 

 間違いなく、これらの原因によりプロジェクトは混乱しているはずである。しかし、火がついたプロジェクトでは、まともな指示、まともな作業プロセス、まともな作業ルールを持ち込んでメンバに任せるには遅すぎる。もはやプロジェクトメンバは疲れ果て、精神的な余裕がないため自己を守ることで精いっぱいであり、モラルも低下している。さらに、目の前のトラブルが多すぎて、全体を考えながら作業をしていく余裕など当然ない。

 

 しかし、プロジェクトは緊急事態のままである。普通の考えであれば、「これまでのやり方を改善する」方向に向かいがちだが、精神的な余裕を失っているプロジェクトメンバに違うやり方を要求するのは、生産性を下げるばかりか反発を生む。

 

 つまり、通常の「命令」で人を動かすことは不可能であると同時に、やり方を変えることも不可能なのである。

 

少人数のプロジェクトにおける指揮命令

 少人数のプロジェクトにおいては、このような状況下にあっても、「やり方を変えた」ように見えず、抵抗感を少なくする進め方がある。まず、毎朝、各メンバとの会話を終えた段階で、チームリーダから状況をヒアリングする。リーダの報告に各メンバからヒアリングした問題点が出てこなければ、リーダには各メンバからヒアリングした問題点を伝え、フォローに入るようにさせる。前述したとおり、すでにメンバとの会話でいくつかの解決手段が検討され、その方法が決まっていれば、リーダがフォローで手いっぱいになるようなことは少なくなる。こうすることで、プロジェクトメンバが問題を抱え込み、生産性の低下を防ぐことが可能になる。

 

 各チームへの作業指示は「号令」でよい。数時間から数日の細かい単位に分割し指示する。作業を細かく分割することにより、その作業に要求される内容が明確になる。つまりメンバは余計なことを検討する必要がなくなり、作業に集中できるようになる。つまり、生産性を今までより向上させることが可能になるのである。さらに、作業を細かく分割し、随時チェックを入れておくことで、品質の低下や大幅な作業のやり直しが避けられる。
 この数時間から数日のマイルストーンを死守することが、プロジェクトを通常の状態に戻すために重要である。

 

 指示が「号令」になるので、各チームメンバには、作業終了の報告と、問題発生時の迅速な報告を徹底させる。問題発生時には、解決方法をいくつかピックアップさせ、プロジェクトリーダはその中から(あるいは、それ以外の)解決策を指示する。対応メンバは誰か、解決に至る期間はいつまでかを決め、徹底させる。不明確な部分をその場その場で迅速に処理し、課題を先送りせずに解決していく。

 

 作業終了の報告を受けたら、成果物のチェックを行う。数時間から数日の成果をチェックするので、膨大な時間は必要としないはずである。細かく分割した作業の品質をこまめにチェックすることが、品質の低下を避けるポイントとなる。

 

 このような体制を実現するには、前述した綿密な作業タスクの洗い出しとスケジュールの決定が不可欠である。また、プロジェクトリーダは、いかにプロジェクトメンバが忙しくとも、作業を手伝うようなことをしてはならない。やらなければならないことは、正確な状況の把握、迅速な作業指示、迅速な問題解決、そして成果物品質のチェックである。

 

大規模プロジェクトにおける指揮命令

 数十人を超えるような規模のプロジェクトでは、少人数のプロジェクトにおける指揮命令手段を取ることはできない。そもそも、これだけ細かく管理するだけのマネジメントスタッフがそろっていない。さらに、プロジェクト全体の整合性が取れなくなり、プロジェクト内に混乱がまん延していき、結果的にさらに立ち行かなくなってしまう。数人のチームやグループ、各担当者が身近な問題に埋没していき、周辺を見て行動することがますます困難になるのである。

 

 通常、大規模なプロジェクトの管理を行ううえでは、ヘッドクオータのメンバは火のついた状況で課題を洗い出し、顧客も交えて優先順位付けを行う。それにより、「戦力の集中」を図るのである。「多方面展開」を行うと、それぞれに傾注できる腕のいい技術者の数は少なくなるばかりなので、「やらなければならない箇所」に戦力を集中させ、徐々に「見た目上」順調な進展にしていくのだ。ただし、このやり方の最大のネックは、ユーザ企業側の了解を得られるかどうかである。この方法は、そもそも部分リリースを行うことが前提になるため、ユーザ企業側の担当者によっては、強硬に反対する。大規模プロジェクトのプロジェクトマネージャとして、ネゴシエーション能力が大いに問われるところである。もっとも、多くの場合、この方法も、最後には作り手側が「できないものはできない」と開き直って両者が妥協点を探すことになるのである。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

14.7. 指揮命令 ハッピィ・エンジニアリング関連ページ

14.1. 敗戦処理投手
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
14.2. 火消しに与えられた命題
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
14.3. 決定権と人事権
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
14.4. 実態の把握
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
14.5. 根本的な原因を探る
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
14.6. スケジュール、見積もり
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
14.8. キッチリ任せる
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング