※本記事にはプロモーション（広告）が含まれています。
『いい感じにしておいて』――。この記事では、ビジネスの現場で起きるこの現象の裏にある「OSのバグ」を、アーキテクトの視点で解剖します。
よくある場面
美容院で「いい感じでお願いします」と頼んだことはありますか。仕上がりを鏡で見て、「もうちょっと短く……」「いや、前髪はそのままで……」。切り終わってから気づく注文が、次々に出てきます。
腕のいい美容師ほど、最初に「イメージに近い写真はありますか？」と聞きます。「いい感じ」は注文ではないと知っているからです。
職場でも同じことが起きます。金曜の夕方、上司から一言。
「来週の部長会の資料、いい感じにまとめておいて」
部下は時間をかけて10枚のスライドを作ります。月曜に見せると「もっと簡潔に」。3枚に削ると「データが足りない。根拠は？」。5枚にして3回目、返ってきたのは「……なんか違うんだよね」。
部下は「最初から言ってくれれば」と思い、上司は「なんで一発で出てこないんだ」と思う。どちらも手を抜いていないのに、3回やり直しになります。これは能力の問題ではなく、依頼の仕組みのバグです。
なぜ起きるのか ― バグの構造
ソフトウェア開発には「受け入れ条件」という考え方があります。何を満たせば「完成」と呼ぶのかを、作り始める前に決めておく取り決めです。条件がないまま発注すると、完成かどうかは、できあがったものを見た発注者の感覚で決まってしまいます。
「いい感じに」は、この受け入れ条件が空っぽの発注です。しかも、頼んだ本人も条件を持っていないことが多い。頭の中にあるのは「見ればわかる」という感覚だけなので、成果物を見て初めて「簡潔に」「データが足りない」と基準が生まれてきます。
基準は、成果物を見たあとで、後出しで生まれる。
部下は描かれていない的に向かって矢を放ち、外れるたびに、あとから的が描き足される。3回やり直しになったのは、部下が的を外したからではありません。的が3回、あとから描かれたのです。「いい感じに」は仕様ではなく、「できたら見て判断する」というレビューの予約にすぎません。
コストは見えにくいところに積み上がります。作り直しの時間に加えて、部下は「上司の好みを当てるゲーム」に慣れ、自分で考えるより顔色を読むようになっていきます。あなたが最後に「いい感じに」と頼んだ仕事、その完成の条件を、いま3つ言えるでしょうか。
まず試せる一手：完成の条件を3行で渡す
頼む前に、依頼の文に次の3つを書き足します。書くのは1行ずつで十分です。
「誰が見て、何に使って、どうなったら完成？」
- ×「部長会の資料、いい感じにまとめておいて」（完成の条件がない）
- ○「部長会の10分枠で、A案とB案のどちらで進めるかを決めてもらう資料。部長が1枚目だけ見て判断できたら完成。根拠のデータは付録でいい」
大事なのは3つ目の「どうなったら完成か」です。ここが書けないなら、まだ頼む段階ではありません。先に自分が何を決めたいのかを決める。依頼の文を書くこと自体が、頼む側の頭の整理になります。
ここまでが、最初の一手です。この一手を習慣にして、同じバグを繰り返さない仕組みにするための残りの手順は、noteで公開しています。
残りの解決策（How）はnoteで公開中
ここから先の具体的な解決策・コマンドは、noteの記事で公開しています。
この記事は、全記事入りのマガジン「アーキテクト思考の教科書」（1,980円）と、柱ごとのマガジン「① 言語化のバグ編」（980円）にも収録しています。
このテーマを深めるおすすめの本
『イシューからはじめよ』（安宅和人）
手を動かす前に「何に答えを出すのか」を決める、という考え方の定番。完成の条件を先に言葉にする習慣の土台になる一冊。
▶ 楽天で探す
▶ 耳で読むなら：新作続々追加！オーディオブック聴くなら – audiobook.jp
あわせて読みたい：「わかった」はたぶん分かっていない／「なんでもいい」
※本記事は、noteで公開した「「いい感じにしておいて」で、3回やり直しになるバグ。完成の条件は、頼む前に決める」の無料部分をブログ向けに再構成したものです。
コメント