Edited at

【要約】日経SYSTEMS 2019/8号


1. はじめに

以下雑誌の要約。


  • 題名:日経SYSTEMS 2019/8号


2. プロジェクトのファシリテーション実践法

プロジェクトの短期化、複雑化が進む今、プロジェクトマネージャーがプロジェクトの全てを把握し、対応するのは難しくなっている。

そこで求められるのが、メンバーの力を引き出し、一丸となってゴールに向かうことを支援するファシリテーションである。

ファシリテーションの実践例を以下に記載する。


2-1. 協力会社と対立! 相手を認め、真摯に傾聴する

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

[元請け]プロジェクトマネージャー ・・・ 野比
[元請け]開発リーダー ・・・ 出木杉
[協力会社]開発リーダー ・・・ 剛田
[協力会社]エンジニア ・・・ 骨川
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

野比のプロジェクトで開発を請け負っている協力会社では、遅れ気味になってきた進捗の対策会議が開かれていた。
ユーザーから指定されたパッケージを利用していたが、そのパッケージが遅延の原因になっていたからだ。

・骨川「どうしてドキュメントもないパッケージを使うんですか。使うのをやめるように言いましょう。」
・剛田「気持ちは分かるが果たして元請けが聞いてくれるのだろうか…」

協力会社の骨川は部下を守るためにも、時に理不尽なことを言ってくる元請けに不満を持っていた。
一方、元請け企業の野比と出木杉も協議中だった。

・出木杉「協力会社は、パッケージの不満を言ってくると思います。でも顧客指定のパッケージなので変更できません。」
・野比「うむむ…」

意見の異なる両社は会議をすることになった。しかしこのままではお互いを非難し合い対立が深まるのは目に見えていた。


  • 元請けと協力会社には、発注者と受注者という社会的関係性があり、発注者が受注者に対して無理を言いがちになる場合がある。しかし発注者、受注者という社会的関係性を背景に、否定的な態度に出たりすると、協力企業のモチベーションは下がる。

  • プロジェクトマネージャーは発注者、受注者といった区別なく、平等に振る舞うことが重要になる。少ない人数で、かつ短い期間で複雑なプロジェクトを進めるためには、協力会社を含めてメンバー全員が最大の力を発揮する必要がある。

  • プロジェクトマネージャーが行うべきは、協力会社を含めたメンバー同士が自由に意見を述べられる環境や雰囲気を作ることである。

  • プロジェクトは意見の相違があること前提として考える。そのために必要になるのが、対立するお互いの意見を平等に引き出すこととなる。

  • プロジェクトマネージャーとして意見を述べるのは最後にして、メンバーの意見にまず耳を傾ける。そしてメンバーの意見には可能な限り共感的に理解を示すことを心掛ける。

  • 対立を解決するためには具体的に指示を出すのではなく、「どうしたらよいだろうか」と現場の意志を問いかける。反対意見が挙がったときは、その背景、理由も同時に聞き出すと理解が進む。

・剛田「パッケージを変えさせてください!資料が少なすぎて、このままでは中断しかねません。」

・野比「そんな苦労があったとはすみません。状況を教えてください。当社からはパッケージ採用の経緯を説明します。」


2-2. メンバー同士がもめた! プロジェクトの目的を思い出す

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

プロジェクトマネージャー ・・・ 野比
移行リーダー ・・・ 大山
開発リーダー ・・・ 出木杉
インフラリーダー ・・・ 源
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

プロジェクトは総合テストに入り山場を迎えていた。これまでは主に各チームで開発を進めてきたが、
結合テストの段階で認識の違いや作業漏れが多数判明したのだ。

・大山「このままでは移行テストができません。」
・出木杉「単体テストは問題ないので、データかデータベースの問題でしょう。」
・源「データベースは開発チームに聞いた通りの仕様で開発しています。」
・大山「予定通りの性能が出ていないし、移行プログラムもエラーが多発しています。」

野比のプロジェクトでは今、議論が白熱している。プロジェクトが逼迫し追い込まれてくると、
誰もが余裕がなくなって、自分たちの作業をこなすことで精いっぱいになり、もめ事が発生しやすくなる。
野比は、メンバーの主張を冷静に聞いて、整理することにした。

・野比「みなさん、ちょっと待ってください。何が不満なのですか。なぜこうなっているのですか?」
・源「障害の多くは設計の誤りで、我々では対処できません。」
・大山「設計時点でお願いしたユーザーの調整ができていないのです。」
・出木杉「ユーザーは調整済みなはず。きちんと確認していないのでは?」

メンバーからは、それぞれの立場や役割に基づく不満や要求が繰り返されるだけ。対立の溝が埋まりそうもない。


  • プロジェクトでもめ事が発生しやすいのは、プロジェクトの状況が深刻で危機感が強まったときである。こうしたタイミングでプロジェクトマネージャーが、感情的に対立しているメンバーの非難合戦に全て耳を傾けるのは現実的でない。

  • リーダーシップを重視するプロジェクトマネージャーであればプロジェクトを進めるために、具体的な指示を下したくなる。しかしここでプロジェクトマネージャーが指示を下すとしてもメンバーの不満は解消されず、かえってプロジェクトの生産性を落とす可能性がある。細かく指示を出すとプロジェクトマネージャーの負担も増加する。

  • メンバーも繰り返し指示を受けると、「自分が責任を持って仕事をやりとげる」という意識が希薄になってしまう。やがては「指示が出た以外のことはやらない」「進まないのは指示を出さないプロジェクトマネージャーが悪い」といった思考に陥る可能性がある。

  • こうした場面で実施すべきファシリテーションは、メンバーがそれぞれの立場で、プロジェクトを進めるために必要な行動を自ら取れるように促すことである。

  • メンバーにプロジェクトの目的を振り返ってもらい、今あなたがプロジェクトに対して貢献できることは何かを問いかける。

  • プロジェクトのゴールはどのメンバーも同じはず。同じゴールに向かって進んでいることを改めて確認することで一体感を出し、目標に向かって自律的に行動できる環境を作る。イメージとしては、メンバー全員の脳が1つに集まった状態である。

  • 具体的にプロジェクトマネージャーが実施すべき行動は、以下のようなものがある。


    • プロジェクトの目的に加えて、ユーザーの作業や各工程の目的といったゴールとなるべきポイントを共有する。

    • 朝会夕会など定期的に開催される会議体で、プロジェクトの現状をありのまま共有する。

    • 目的達成までのシナリオをメンバー全員で考えるように支援する。

    • 各メンバーがプロジェクトに対して貢献できることは何かを明らかにする。



・野比「一度、プロジェクトの目的を振り返りましょう。みなさんはプロジェクトに対してどんな貢献ができますか?」

・出木杉「性能が不足しているのであれば、PGで高速化できるか検討します。」
・源「そうですね…。ではデータベースのチューニングが可能か確認します。ユーザー調整はお願いしてもいいですか?」
・大山「はい。お客様に確認します。」


2-3. 突然ユーザーが仕様変更を要求! 真のニーズを見極めよう

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

プロジェクトマネージャー ・・・ 野比
移行リーダー ・・・ 大山
開発リーダー ・・・ 出木杉
インフラリーダー ・・・ 源
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

プロジェクトの進捗会議。開発フェーズも終盤を迎えているにもかかわらず、インフラリーダーの源が
ユーザーから追加要望を受け入れて帰ってきた。

・源「お客様からこんなリクエストを受けました。対応必須になりそうです。」
・メンバー「ええっ。」
・出木杉「ちょっと源さん。その要望を受けると他の機能の改修も必要になります。追加開発は今さら無理です。」
・大山「運用観点だと手順書を大幅に増やすことになります。源さん、どうしていつも受け入れてしまうのですか?」
・源「状況はわかっていますが、この機能がないと業務が回らなくなるとお客様が言っているのです。」
・全員「…。」


  • プロジェクトを進めていくうえで、ユーザーの無理な要求に遭遇する場面は必ずある。

  • マネジメント重視のプロジェクトマネージャーの場合、ユーザーがどうしても必要な機能を実装するために、「仕様変更にかかる期間はどの程度か」「再見積もりが必要になるか」「リソースは確保できるか」など様々なシミュレーションを行う。

  • 技術力が高いエンジニアのリーダーの場合、時間のかかる費用交渉や社内承認を経るよりも「開発したほうが早い」と、作業に着手してしまう可能性もある。

  • プロジェクトの環境変化が早く、複雑になっている今、プロジェクトマネージャーがユーザーの要望に言われるがまま対応するのは難しい。たとえユーザーが追加費用を支払うといっても、対応していたら納期に間に合わなくなり、品質劣化の危険もある。

  • プロジェクトマネージャーは、「業務が回らない」と主張するユーザーの言動や、追加開発を急ぐメンバーにまどわされず、要望の本質を追究することが重要になる。

  • まず、「その機能はなぜ必要なのか」「なぜ業務が回らなくなるのか」「機能の利用頻度はどの程度か」といった問いかけを行い、ユーザーの要望/意見/背景/動機/根拠などを聞き出し、掘り下げていく。

  • 一見、突拍子もなく聞こえる要望でも、掘り下げていくと、これまでの状況との接点を見いだせることが多い。また背景や理由を聞き出す過程で、ユーザー自身が要望の本質や真に取るべき対応に気づくこともある。

  • 要望の背景を確認した結果、実は大がかりな機能開発は不要で、既に開発した機能を微修正したり、外付けの簡易ツールを利用することで十分に実現できたり、ということもよくある。

  • 余計な開発を減らすためにもプロジェクトマネージャーは、物事の本質は言葉の裏に隠れていると考え、ユーザーとの対話を通じて真意を見抜けるようにメンバーに促していくことが大切である。

・野比「本当に必要でしょうか。なぜお客様が追加要望を上げてきたのか、本当にやりたいことを確認してみませんか?」

・出木杉「本当にやりたいことですか?」
・大山「お客様の言葉をそのまま受け取っていただけかもしれないわ。」

そこで源は、ユーザーに対して突然の要望変更がなぜ必要なのか、どのような業務が行われるのかを、改めて確認した。

・源「直接確認しました。〇〇の背景があって、あの機能の要望を出したということでした。」
・出木杉「なるほど。それは実装済みの機能を少し変更するだけで対応できるのではないでしょうか?」