システム構築のための調整力向上講座（第2回）ジレンマの許容度の高さが優秀なリーダーの条件

　発注企業の情報システム部門の立場では、「自分たちが何をしたいのかもわからない段階で、予算とアウトプットを決めてしまうと後で追加要件が出てきたときに追加請求をされてしまう。曖昧にしておけばあとで『これもお願い』と言える」という目論見があります。

　ベンダーからすれば、「発注企業側はプロセスや技術的なことを理解しようとしないし要求がコロコロと変わる。にもかかわらず、予算とアウトプットを約束してしまえば、見積もり工数を大幅に超えてしまう」というリスクを考えています。アウトプットを曖昧にしておけば、予定より工数がかかりそうな場合は「そこまではプロジェクトの範囲に入っていません」と言えます。つまり、ユーザー、ベンダーともに、詳細を曖昧にしておくことで「バッファー」を持とうとするわけです。

　しかし、このバッファーがうまく機能することはあまりありません。発注企業からすれば「え、そこまでしかやってくれないの？」となりますし、ベンダーからすれば「コロコロ変わる要求にできるだけ対応したじゃないですか」となります。

　つまり、詳細にしてもリスクを背負う、曖昧にしてもリスクを背負うというジレンマがあるわけです。これは、ベンダーに丸投げしようとする発注企業と、発注企業に説明をしないベンダーの両方に原因があります。

　このとき、リーダーとして取るべき行動は、プロジェクトをあるべき姿に近づけることです。その姿とは、目的と目標、そこに至るまでのルート、つまりプロセスに対する共通認識をステークホルダーが持っている状態です。そして、この行動はプロフェッショナルであるリーダーが起点でなければなりません。なぜなら、発注企業の利用部門も経営層も、自分たちのビジネスをしているのであり、システム開発のことをイチから学べないからです。どんな分野でも説明責任はプロフェッショナル側にあります。

　まず、ステークホルダーに対して成果物に関する共通認識を持たせるべきです。このプロジェクトでは、最終成果物として何をアウトプットするのか、そのためにどのような中間成果物を作るのかを明らかにします。成果物が明らかになれば、それをどのように作るのか、プロセスを明確化します。アウトプットとプロセスが明確になれば、プロジェクトの不確実性は大幅に減らせます。

　このとき必要となるのが共通言語です。エンジニアの多くは、開発プロセスをどのように進めるのか、非エンジニアに伝えるすべを持っていません。専門用語で説明されても、経営層には全くわかりません。非エンジニアである利用部門、経営層に開発プロセスを説明し、利用部門側にかかわってもらうプロセスと、確保してもらう負担（工数）について共通認識を持つには、共通言語が必要です。筆者は「プロセスフローダイアグラム（PFD）」というツールを使い、図を共通言語にして共通認識を持つようにしています。図がシンプルなため、ほぼ説明不要で共通認識を得られます。

（7）調和と衝突のジレンマ

　プロジェクトとはさまざまなステークホルダーがかかわる複雑な取り組みです。視点と利害の異なる人たちが同じゴールに向かい、一つの取り組みを進めるのですから、しばしば衝突が起こります。また、より良い結果を生みだすためには議論が必要です。意見を戦わせながら良いものに仕上げていくプロセスのなかで品質は洗練されていくからです。

　しかし、日本人は議論に慣れていない人が多く、開発技術者が専門用語を使って話し始めると、経営層や利用部門の人は黙り込んでしまいます。本来は、そうしたユーザー側が分かるように説明する義務が技術者側にあるのですが、分からないと知っていて難しい用語で煙に巻くエンジニアも少なくありません。「説明責任はプロフェッショナル側にある」のですから、ユーザー側は何度でも「分からない」と言っていいのですが、「揉めるんじゃないか」と心配になってしまうのです。

　これらの心配は「衝突は悪いことだ」という思い込みに端を発しています。しかし、結果をより良いものにしていくには、この衝突は欠かせないプロセスです。つまり、衝突とは結果ではなく、成果を生み出すために必要な過程なのです。まず、この認識を持ってください。

　技術者側としても議論から逃げない姿勢を持つことが必要です。技術者の多くは衝突に慣れているはずです。技術的なレビューは衝突そのものだからです。「こんな設計じゃダメだ」「ちゃんと考えたのか？」ぐらいのやり取りは、エンジニアにとって日常茶飯事です。しかし、相手がユーザーとなると途端に議論を怖れてしまいます。「時間を取ってしまうといけないんじゃないか」「怒らせないだろうか」と思ってしまうのです。

　一方、ユーザー側が求めているのは、腹落ち感です。ユーザー側の人もわからないままでは本当は気持ち悪いのです。議論しないのは、技術者に遠慮しているだけなのです。技術者が「分からないことはどれだけ時間をかけても徹底的に説明する」という姿勢を見せることで、共通認識を深められるのです。

　ただし、リーダーとして慎むべきは「問題と人を一緒にしてしまう」ことです。例えば、プロジェクト計画に納得がいかないとします。このとき議論すべきは「プロジェクト計画の精度」であって、プロジェクト計画を立てた人の人間性ではないのです。問題と人を分離した上で議論することが必要です。

リーダーの優秀さはジレンマへの許容度に表れる

　コンサルタントとしてよく尋ねられるのが「他社では理想的なプロジェクトって存在してるんでしょうか？」ということです。その場合は「どこも同じようなものですよ」と答えています。「技術力がある」「上手くいっている」という評判の企業でも、ジレンマがないわけではありません。

　違うのは、ジレンマへの向き合い方です。成果を生み出すリーダーは、ジレンマを許容し、その上でどのように向き合うかを考えます。リーダーとしての優秀さは「ジレンマへの許容度」にかかっているといえます。

　リーダーは、ジレンマ（衝突）を許容し、解消を図るのではなく、それがジレンマでなくなるように行動します。ジレンマが起きているレベルでジレンマを解消しようとしてもできません。視点を一つ上に上げて問題に向き合う。ステークホルダーとの接し方のなかで、常に必要となる姿勢です。

まとめ

●リーダーは、相反する立場の人たちの間に立つ。組織のしがらみを乗りこなす立ち回りが必要。
●ジレンマとなる場面は多くある。リーダーとしての優秀さは、「ジレンマの許容度」にかかっている。
●ジレンマを解消しようとするのではなく、ジレンマでなくなるようなアプローチを採ろう。

日経SYSTEMS／芝本秀徳（プロセスデザインエージェント）