あなたの考え、本当に伝わっていますか?

はじめに

今回は、プロジェクトマネージャーにとっては当たり前過ぎて、そのノウハウとして話題に挙げることで疑問に思われるかも知れない、というお話です。

初歩の初歩

少し前に、社内のある方から「プロジェクトマネージャとして育てて欲しい」と依頼されたベテランSEがいました。私は、私が見ているプロジェクトのプロジェクトマネージャの元で育成しようと考えて託したのですが、結果としてベテランSEをプロジェクトマネージャとして育成することを断念し、プロジェクトを外れてもらう決断をしたことがありました。

そのベテランSEに参画してもらったプロジェクトは、金融関連の巨大パッケージシステムの受託開発でした。ベテランSEがプロジェクトに参画した時期は、その新規構築が終わり、保守と別ユーザ向けカスタマイズ導入の対応に入った直後のことでした。プロジェクトマネージャは、ベテランSEが早くプロジェクトの一員として活動できるようにと思い、まずはベテランSEにお客様との打ち合わせの議事録を作成する担当をお願いしました。

プロジェクトマネージャが議事録の作成をお願いした意図は、途中参画したプロジェクトで議事録作成を担当すればプロジェクト自体の中身やよく使われる言葉、プロジェクトに関わる方々の考え方など多くの情報が手に入るため、プロジェクトに慣れるには非常に有用だからです。ところが、暫くするとプロジェクトマネージャが私の所に来て、「もう少し様子を見るが、新しく参画したベテランSEは優秀な作業者であって、SEではないかもしれない」と言いました。そのひと言でプロジェクトマネージャが言いたいことは大体予想できたのですが、念のため具体的にどのような懸念があるのかを確認すると、以下のような内容でした。

• 内容が参加者の発言のごく一部しか書かれていない
• 内容を先頭から通して読んでも打ち合わせで出た話の概要が掴めない
• 内容が参加者の発言なのか、ベテランSEが参加者の言葉から行間を読み取ったものか分からない

これを聞いて、私はプロジェクトマネージャの「優秀な作業者であって、SEではないかもしれない」という懸念は高い確率で当たっていると思いました。なぜなら、ITの仕事は他の仕事と比べて、特に高度な情報収集・整理・伝達能力が必要とされるからです。議事録の作成は、そういった情報収集・整理・伝達能力を確認する手段として非常に有用なのですが、残念ながら現時点でベテランSEはその能力が足りていないと思えたからです。

議事録と言うと、結構多くの方が「若手にでもやらせておけ!」と言いますが、実際にレベルの高い議事録を作成できる方は非常に少ないです。人によっては参加者の発言の正確な記録を議事録と呼んだり、議事内容における自身の大まかな理解を記したものを議事録と呼びますが、実際にはそれでは不十分だと考えています。

議事録の作成は、まず参加者の発言の正確な記録、次に参加者の発言の要点整理と要約、そして要旨の抽出の流れが必要になります。発言の整理と要約まで行ったものが議事内容、要旨を抽出したものが決定事項や確認事項、課題事項などに当たるのですが、特に高度なテクニックが必要となるのが要約だと思っています。人の言葉は不思議なもので、発言をそのまま文章にすると、発言者が本当に言いたかったことが見えなくなることがあります。そういった際に発言者の言葉を上手く残しつつ行間を読み取り、本当に言いたかったであろう言葉に加工する必要があるのです。

IPAのプロジェクトマネージャ試験でも
問われるスキル

令和に入って以降、「問題の出題内容に変化があった」と話題になっているIPAのプロジェクトマネージャ試験における午後Ⅰ問題ですが、試験内容自体は変化がなく、問題文の要点整理と要約、そして要旨を抽出し、問われた内容を決められた短い文字数で回答する形です。つまり、議事録作成とほぼ同じ要素が試されているのです。難易度が高く、なかなか合格できない言われるプロジェクトマネージャ試験では午後Ⅰ問題で脱落される方も結構いらっしゃると思いますが、そこで問われている内容の1つと考えれば簡単なものではないことが理解いただけると思います。

私はベテランSEと面談を行い、プロジェクトマネージャがベテランSEにお願いした議事録の作成が重要な業務であり、プロジェクトマネージャを目指すなら確実に身に着けなくてはならないスキルであること、その時点では作成された議事録の内容が満足の行く水準に達していないことを説明したのですが、ベテランSEにはどうしても議事録作成が雑用に思えてしまうようで、納得してもらえませんでした。残念ながら、議事録作成スキルがなく、またスキル向上の意思もないため、プロジェクトマネジメントにおける要件抽出や課題の整理など重要な業務の多くをお願いする基礎がないと判断し、プロジェクトを外れもらったのです。

IT業界では認識齟齬が発生しやすい

ところで、読者の皆さんは、以下の絵を見たことはあるでしょうか?

【出典】ニコニコ大百科 「顧客が本当に必要だったもの」

これは「顧客が本当に必要だったもの」と呼ばれる絵で、そもそも顧客が要件を正しく説明できず、依頼された側も顧客の要件を取り違えたり、関係者がそれぞれの立場で勝手な解釈をしてしまったり、顧客も含めて必要とするものを誰も分かっていなかったことを風刺した絵です。IT業界で働いていると、時々この風刺に近いトラブルを耳にしますが、なぜIT業界ではこのようなことが発生するのでしょうか。それは、議事録の話でも書きましたが、ITの仕事では、基本的に生み出される成果物が目に見えないものであるため、製品やサービスの代わりに資料や設計書、テスト結果などの情報を整理し記載・説明していく活動が必要になります。そのため他の仕事に比べて特に高度な情報収集・整理・伝達能力が必要であり、それらが甘くなることで上記のような風刺に繋がるトラブルが発生するのです。

考えや情報を伝える際に意識すべきこと

プロジェクトマネージャは、そういったITの仕事の中でも、お客様、社内の上層部、プロジェクトメンバー、プロジェクトに関わるパートナーなど、非常に多方面の方と同時並行でコミュニケーションを取る必要があります。つまり、プロジェクトマネージャに情報収集・整理・伝達能力がないと「顧客が本当に必要だったもの」のような状況が簡単に発生してしまうのです。

では、こういった状況を生み出さないために、プロジェクトマネージャはもちろんのこと、IT技術者として対策はできないものでしょうか。私はあることを意識するだけで意外と簡単に対策できると思っています(しかし、多くの方は意識できていない)。これは、私の見ているプロジェクトでもプロジェクトマネージャはもとより、メンバーにも強く意識してもらっている内容で「のりしろ活動」と呼んでいます。仕事をする際は、相手の立場や性格、過去の議論の経緯などを意識したり、自分が担当する仕事の後続工程の業務内容や設計内容などを意識し、仕事相手や仕事の後続工程との間で積極的にのりしろを作っていくようにするのです。人によっては「他の人や工程と重複する活動は無駄だ」「情報の二重管理になる」などネガティブなイメージを持たれることもありますが、結果的に仕事相手や後続工程での仕事を頭の中でシミュレーションしたり、一部資料に書き出したりすることで、業務での認識齟齬が圧倒的に減ります。また、認識齟齬があっても、のりしろ部分を議論することで比較的容易に認識齟齬を解消できるのです。例えば、議事録作成では要約を行う際に発言者が発言した内容を捻じ曲げず、相手の立場や性格、過去の議論の経緯などを元に発言者が言いたかったであろう内容を補足すると、大体の場合は「認識相違なし」として承認されることが多いです。

おわりに

今回は、プロジェクトマネージャとして必須で、かつIT技術者としても早い段階で身に着けるべきスキルとして、情報収集・整理・伝達における能力の大切さと、これらのスキルを向上するための方法を紹介しました。

さて、前回、今回と基本に近いスキルについての解説が続いたので、次回は少し雰囲気を変えて、障害などが発生した際の障害分析や、(ITストラテジスト業務に近い話になりますが)要件分析などに使われる情報整理のスキルについて紹介したいと思います。