この記事で書きたいことは、大筋以下のようなことです。
・「曖昧さ耐性」についての記事を読みました
・部下の曖昧さ耐性の有無と状況に合わせて指示の出し方をコントロールする必要がある、というのはその通りだと思います
・ところで私には、自分の「曖昧さ耐性」を顕著に下げてしまった経験があり、「部下の曖昧さ耐性を下げない為にはどうすればいいか」を常々考えています
・重要なのは、チーム内での「成果物のフェーズ」に関する意識の統一ではないかと思います
・成果物のフェーズ認識に不一致があると、作業者が無駄に疲弊するし曖昧耐性が毀損される場合があります
・「今は成果物の曖昧さを許容するフェーズ」という意識統一がとても大事です
以上です。よろしくお願いします。
さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。
***
先日、logmiBizさんでこんな記事を拝読しました。
曖昧な指示でパニックになる人・自主的に動ける人の違い 部下の「曖昧さ耐性」に合わせた、上司の仕事の任せ方
非常に内容が濃い記事なので通してのご一読をお勧めしたいのですが、僭越ながらいくつかポイントを抽出・要約させていただくと、
・曖昧な指示には、様々な解釈が出来る(多義的)為に曖昧になっている場合と、情報が不足している為に曖昧になっている場合がある
・通常、上司はタスクの状況に応じて的確な指示をしなくてはいけない
・ただ、中には曖昧な状況を好ましいと感じる(つまり曖昧さ耐性が高い)人材もおり、曖昧さ耐性に応じて指示の出し方をコントロールできることが望ましい
・曖昧さ耐性は変化し得るもので、曖昧さ耐性を向上させる為には段階的にタスクのハードルを上げていくことが重要
・曖昧さ耐性が高い人材だからといって、便利屋的に曖昧なタスクばかりを任せていてはいけない
といった感じになると思います。だいぶざっくりした要約なので気になる方は原文を読んでください。
上記記事への反応を見ていると、「曖昧なタスク」自体に拒否感を示す人も多いなーと感じました。
とはいえ、タスクの状況、プロジェクトのステージにもよるのですが、「どうしても曖昧さを避け得ない状況」「むしろ曖昧であるべき場面」というのは、仕事上必ず発生します。
例えば要求定義の初期段階、「何をするべきか」「何をやればいいか」ということ自体ブレストでどんどん発散させていくべき状況だとか、新しいソリューションを根っこから検討しなくてはいけない段階、業務改善で既存の成果物のフォーマット自体を見直さなくてはいけない状況などは、「曖昧さが不可分な場面」の代表例でしょう。
「曖昧さ」の定義で言うと情報不足の局面、そもそも正解というものがなく、無理に曖昧さを排除しようとすると成果物が小さくまとまってしまって、最終的なクオリティが低くなってしまうような局面ですね。
もちろんこういった場合でも、タスク自体を可能な限り細かく切り分けて、多義性を排除して、一つ一つのタスクを明確にすることは可能ですし、曖昧なタスクが苦手な人に対してはそういう指示出しをしなくてはいけません。
ここで甘えないのはマネージャーとしての責務です。
手前みそなのですが、私が以前書いたこちらの記事、ちょっと引用させてください。
タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
面談やらヒアリングで色々と話を聞くうちに、Dさんのタスクが遅れてしまう時には、二つの典型的なパターンがあることが分かりました。
まず一つは、「いわゆるQuick & Dirtyを要求された場合」。
「適当でいいから、取り敢えず出来るところまでやって」みたいな、細かく品質を指定しないタスクを振られた時、Dさんはほぼ百発百中、そのタスクをずるずると遅延させていました。
ここでいうDさんは、極めて「曖昧さ耐性が低い」人だったと言えるでしょう。
だからといってDさんが無能というわけでは全くなく、マネージャーの指示と管理強度次第で十分なパフォーマンスを出すことが出来る人だった、というのも引用の記事通りです。
一方曖昧な状況を苦手としない、曖昧さ耐性が高い人材には、そこまで細かい指示出しをしなくてもパフォーマンスを出してくれる、ということも確かかなーと思います。
とはいえこれも、「出来る」と「やりたい」はだいぶ別の話で、基本的に「曖昧な状況を整理する」ってどんな人にとっても大変なことなので、やらないで済めばやりたくない人の方が多いんじゃないかなーとも考えるところです。
私の観測範囲内では、「曖昧な仕事大好き、どんどんウェルカム」って人、かなり希少です。そういう人、会社辞めて独立しちゃう率も高いですし。
冒頭引用記事でも、曖昧さ耐性が高い人を便利屋扱いすることのリスクが触れられていますが、マネージャー側としても、部下の曖昧さ耐性に「甘えて」しまっている状況は自覚して、的確なフォローをしていかなくてはいけないなーと考える次第です。
***
さて。
logmiBizさんの記事にも書かれている通り、曖昧さ耐性というのは変化し得るもので、向上させることも可能なのですが、一方デバフによって耐性が低下してしまうこともあるようです。RPGの耐性低下呪文みたいなもんです。ルカナンとかラクンダとかあの辺です。
「ソースは私」というやつなんですが、しんざきには、自分の「曖昧さ耐性」が下がってしまったなー、曖昧な仕事が以前より苦手になっちゃったなーとはっきり自覚した時期があります。
10年ちょっと前でしょうか。
以前から書いている通り、しんざきはシステム関係の仕事をしています。
最近はマネージャーとしての立ち位置で働くことが多いですが、当然タスク実行者としての立場になったことも多いです。
元々、自己評価としては「曖昧なタスク」というものをそれ程苦にしない方だと思っていました。
情報量が少ないなら少ないなり、多義的であるなら多義的なりに、必要に応じてスコープを絞って、ふわっとしたタスクを明確なタスクにまとめる。で、曖昧な状況なりに必要な成果物を仕上げて、タスクを次のステージに繋げる。そういう仕事は割と得意な方です。
ただ、あるプロジェクトに関わっていた時期、「自分の成果物とプロジェクトの要求が食い違うなー」と感じることが急に増えたんですね。
自分としては指示をくみ取って局面局面で必要な成果物を出力しているつもりなのに、何故か周囲からの評価が食い違う。レビューでのダメ出しがやたら多い。
成果物として必要な情報が足りない、ディテールがぼんやりしている、これでは次のステージへの出力にならない、といった指摘を受けることも頻繁でした。
当時は今ほど「曖昧さ」についての言語化が出来ていなかったので、私自身原因を明確に出来なかったのですが、今なら分かります。
これ、
「成果物の要求ステージについての、チーム内での意識の不統一」
が原因です。
まず一つ前提として、「指示の曖昧さと成果物の曖昧さは別」「成果物の出来やディテールは、上司からの指示次第」という認識が必要です。
入力がなければ出力は発生しません。必然、出力のクオリティは入力のクオリティ次第ということになります。
一方、最初の方で書いた通り、仕事の局面として「曖昧さが不可分」というステージは必ずあります。
正解がはっきり定義出来ない局面、とにかくアイディアベースの発散が必要な局面、「何をすればゴールなのか」というところから考えないといけない局面。
こういう局面で「何をどんな風に作って」という成果物の定義を明確に出来ないのはある程度仕方ないところなんですが、一方当然その「曖昧さ」は成果物の側にも影響します。
要求定義での成果物と詳細設計での成果物って、当たり前ですけど求められるディテールって全然違うじゃないですか。「何を作ればいいか」が明確になっていない以上、当然成果物もそこまでかっちり固まらない筈なんですよね。
ところが、この認識が食い違っていると、「指示は曖昧なのに、成果物にはやたらディテールが要求される」という状況が発生するんですよ。
そもそも情報不足で、ディテールをしっかり詰めた成果物なんて作りようがないのに、レビューではディテールについての指摘ばかりが発生する。作る側としては「なんでだよ」ってなっちゃいますよね？
つまり、「今のステージでは、指示がある程度曖昧になってしまうのと同様、成果物にもそこまでのディテールは要求されない」「今は、曖昧な指示、曖昧な成果物が共に許容される段階」という共通認識が、やむを得ず曖昧な指示を出す上では絶対に必要なんです。
これ、チーム構成やレビューのやり方にもよりますが、上司だけが認識していてもダメで、きちんとプロジェクト内で「今は成果物にも曖昧さが許容されるステージだよ」ってことを言語化しなくてはいけません。
上司と部下、二人体制でのプロジェクトでない限り、自分の成果物は必ず複数の人に見られますし、複数の人のレビューを受けることになります。
厄介なことに、レビューって「何かを指摘しないといけない」という圧が高まることもあって、「細かいこと程指摘しやすい」という側面があるんですよ。ディテールの不足って慣れてる人にとっては一番指摘しやすいことなので、「今はディテールを詰める段階じゃないよ」という意識が統一されていないと、ディテール不足についてのダメ出しがガンガン発生してしまう。心理的安全性が下がりまくるわけです。
当然、成果物を作る側としては、ダメ出しに対応する為に細かい穴を塞ごうとしますし、本来許容されるべき「曖昧さ」を可能な限り潰そうとしますよね。
結果、曖昧な状況がどんどん苦手になっていくし、可能な限り曖昧さを避けようとしてしまう。発散が必要なところで成果物を小さく閉じようとしてしまう。
これ、本来はマネージャーが「今のプロジェクトのステージからすると、この指摘は当たらないよ」と明確に言わないといけない場面だったと思うのですが、マネージャーはマネージャーで他プロジェクトも兼任してますし、「ダメ出しに対するダメ出し」って基本的にやりにくいんですよね。
別にトラブルが発生しているわけでもなし、「意見が出ている状態」というのは、上位者からすると止めにくいんです。
これが、今だから分かる、当時の私に発生していたデバフの正体です。
この為、一時期曖昧なタスクが非常に苦手になりまして、「あれ、なんでこういう出力しか出来ないのかな……」「前はもっと出来てたのに……」って随分悩みました。
結果、曖昧なタスク自体がストレス源になりました。曖昧さ耐性が分かりやすく低下した状態です。
幸い、そのプロジェクトが終って他のメンバーで仕事をすることになってからは、曖昧なステージではきちんとそれに応じた成果物が出せる状態に回復したんですが、この状況が続くことで曖昧さ耐性がメタメタになってしまう人も多いんだろうなーと思います。
***
あれからそこそこ時間も経ちまして、部下側・管理側両方を経験する内に、「今のステージで必要とされる成果物のクオリティ、ディテール」について明確に言語化して、しかもその認識をしっかりチーム内で共有することは、プロジェクト全体のクオリティを守る為に非常に重要なことだ、と認識するようになりました。
「今は曖昧な成果物でいいんだよ」をしっかり共通認識にしないといけない、と思うようになりました。
もちろん、指示出しは指示出しで、十分部下の適性を考えた指示出しが出来るよう気をつかう訳ですが、「成果物のステージ」の言語化も重要だなーと。
部下の曖昧さ耐性を育てる為にも、ただそれ以前に「曖昧な状況に対する苦手意識」を醸成しない為にも、上司としてはその辺気をつけないといけないなーと。
そんな風に考える次第なのです。
今日書きたいことはそれくらいです。
AUTOMAGICは、webブラウザ上で商品情報を入力するだけで、
・ターゲット分析
・キャッチコピー
・ネーミング
・キャンペーン企画案
・商品紹介LPの文章
を自動で出力します。
登録すると月間40,000トークン（約2記事程度）までは無料でご利用できます。
↓
無料登録は こちら（AUTOMAGICサイト）へ
詳しい説明や資料が欲しい方は下記フォームからお問合わせください。
↓
AUTOMAGIC お問合せ・資料ダウンロードフォーム
【著者プロフィール】
著者名：しんざき
SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。
レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。
ブログ：不倒城
Photo：Luis Villasmil
