前回のおさらい
第1回では、「丁寧さ」が現代の仕事環境でボトルネックになる構造について分析しました。
前回の主要な気づき:
- 「丁寧にやりたい気持ち」が実は仕事の足枷になっている
- 現代の不確実で変化が速い環境では、従来の丁寧さが機能しない
- アウトプットの完璧さより、プロセスの設計に丁寧さを向ける必要がある
- 段階的な実践で「丁寧さの方向転換」を図る
今回は、より実践的で具体的な仕事術に踏み込みます。上司すら正解を知らない不確実な環境で、どのように仕事を設計・実行すればよいのか? ChatGPTとの対話から見えてきた現実的なソリューションをお伝えします。
現代のリアルな職場事情:誰も答えを知らない
私が直面した現実
ChatGPTとの対話で、こんな状況について相談しました:
**「最近、私の隣で新任者が仕事をしているのを見て、昔の感覚が思い起こされる。『必要なスピード』『求められている品質』がわかるのは、それなりの経験と優秀さが必要だと感じる。
しかし、会社の事業領域が広がりすぎて、上司もそもそも必要なレベルが分からず、出てきたアウトプットを見て様々な方向から気になる点を指摘する、といった状況だ。」**
あなたも経験ありませんか?
こんな状況、身に覚えがありませんか?
- 新しい業務や新規事業で前例がない
- 上司から「よろしく」と言われるが、具体的な基準が不明
- 完成してから「イメージと違う」と言われる
- 自分なりに頑張ったのに「方向性がずれている」と指摘される
現実的な分析
ChatGPTの指摘:
「これは形式上の承認と実質的な責任の乖離が起きている状態です。」
つまり:
- 上司は「OK」と言った
- しかし現場では問題が起きた
- 最終的に自分が責任を取らされる(巻き取らされる)
重要な認識:上司の承認は「免責」にはならない。だからこそ、自分で守る枠を作ることが必要。
解決策1:承認を「免責化」する具体的テクニック
単なる「OK確認」では不十分
よくある間違ったアプローチ:
- 「この内容で進めます」→「OK」
- 「資料を添付します」→「確認しました」
これでは後で問題が起きた時に「言った・言わない」になってしまいます。
効果的なアプローチ:リスクを添えた確認
確認時の文面例:
「この内容で進めた場合、●●の問い合わせが一部の顧客から発生する可能性がありますが、現時点ではこの方針で進めてよろしいでしょうか?」
ポイント:
- 想定されるリスクを事前に伝える
- 「あなたにも分かっていて承認した」空気を作る
- メール・チャットで文書化して記録に残す
実践的な文面テンプレート
【新規業務の場合】
「初回のため手探りな部分もありますが、過去の○○案件を参考に添付の方向性で進める予定です。万一異なる想定がある場合は、早めに軌道修正できるよう○日までにご連絡ください。」
【不確実性が高い場合】
「現時点での情報では添付が最適解と判断していますが、前提条件が変わる可能性も考慮して○○の部分は後日調整可能な設計にしています。」
【品質レベルが不明な場合】
「今回はA案(最低限バージョン)、B案(標準バージョン)、C案(丁寧バージョン)を用意しました。どのレベル感を想定されていますか?」
解決策2:「誰も正解を知らない」時の現実的対処法
最も厳しい状況への対応策
状況:「必要なスピード」「求められている品質」が分かる経験がなく、かつ上司も分かっていない場合
この状況は相当なストレスと責任を伴いますが、裏を返せば自分の判断軸と経験値を最も成長させる貴重な機会でもあります。
段階的アプローチ:
STEP1:仮置きの基準を自分で作って小さく実験
- 複数パターンを用意して選ばせる(A案:最低限、B案:標準、C案:丁寧)
- 途中確認を強制的に組み込む
- 軌道修正のコストを最小化
STEP2:外部の知見を徹底活用
- 業界標準の調査(他社事例、業界団体資料)
- 社内の類似事例探し
- 先輩社員への相談
STEP3:顧客・エンドユーザーの反応を最優先指標にする
- 実際に使う人・受け取る人の反応で判断
- 小規模テストの実施
- 直接的なフィードバックの収集
解決策3:「試作→確認→調整」の設計型アプローチ
完璧主義からの脱却
「スピードと品質の基準が分からない」+「上司も分かっていない」=「答えが外にない仕事」
この状況では以下が重要になります:
- 完璧を目指さず、仮説→実行→フィードバックのサイクルに落とし込む
- 「早く正確に」ではなく、「早くズレを見つけて修正する」を正解とする
実践的な4ステップ
ステップ1:スピードと品質の仮設定
例:スピード=1営業日でドラフト、品質=ざっくり構成がわかるレベル
ステップ2:「完成ではなく案として出す」を徹底
- ドキュメント名を「Ver0.3」や「素案_案A」にする
- 「作り込みすぎず、方向性確認用」の注釈を添える
- 完成ではない前提で責任を分散
ステップ3:フィードバックから成功定義を言語化
- 「評価される点/不要だった点」をメモ化
- 「この仕事での成功とは何か」を少しずつ構築
- 次回以降への経験値の積み上げ
ステップ4:判断と前提の言語化
例:「過去の○○案件との類似性と短納期を踏まえてこの構成にしています。異なる想定がある場合は早めに軌道修正できるよう粗く作っています」
実践事例:問題発生時の対処パターン
よくある失敗パターン
- 上司にOKをもらって進める
- 完成後に関係者から様々な指摘を受ける
- 結局自分が残業・休日出勤で対応
- 同じパターンを繰り返す
改善された対処パターン
【事前対策】
- 想定リスクを明記した確認メール
- 複数案の提示で判断を委ねる
- 途中確認のスケジュール組み込み
【問題発生時】
- 状況の記録と分析(「どういう前提で進めたか」「どこにズレがあったか」)
- チームへの改善観点の共有(「次回以降は○○の観点を入れた方が良さそうです」)
- 構造的な問題として捉え、個人の責任に終わらせない
【振り返り】
- 同じ轍を踏まないための判断ルールの更新
- 自分なりの「決断基準」の構築
精神的ダメージを最小化する考え方
「なんで自分だけがしりぬぐいなんだ…」
この気持ちは当然です。しかし、長期的な視点で考えてみてください:
「見えていない問題を発見し、形にし、修正する力」は将来的に組織を引っ張る側に絶対必要な力です
この局面は「上司に見切りをつけて、自分がどう判断軸を作っていくか」の訓練として捉えることで、最終的に自分を強くしてくれます。
今の時代に必要な「仮説検証型」の仕事術
従来の仕事術 vs 現代の仕事術
従来のアプローチ | 現代の仮説検証型アプローチ |
---|---|
完璧な計画を立ててから実行 | 仮説を立てて小さく試す |
一度で正解を出すことを重視 | 早くズレを見つけて修正することを重視 |
上司の指示待ち | 自分で判断軸を作り提案 |
完成してから共有 | 途中段階で頻繁に確認 |
個人で抱え込む | チーム全体で学習・改善 |
なぜこのアプローチが必要なのか
時代背景:
- 業務の不確実性が高くなっている
- 新規事業、海外展開、AI活用、リモート化…
- 「前例のない仕事」が急増 → 「完璧な指示」が不可能
- 情報のサイクルが速い
- 数週間かけて作った資料が”陳腐化”するスピード
- 完成度より素早い試作品と修正サイクルが勝つ
- 「正解志向」より「修正力」が評価される社会
- 「最初から外さない人」より、「外しても素早く修正できる人」が強い
- スタートアップ、外資、DX推進企業ではこの評価軸が顕著
第2回の実践ポイント
今日から使える具体的テクニック
1. 確認メールのテンプレート化
件名:【要確認】○○の件(想定リスク:●●)
いつもお疲れ様です。
○○の件について、以下の方向性で進める予定です。
【概要】
・・・
【想定されるリスク・留意点】
・●●の可能性があります
・××については後日調整が必要になるかもしれません
【確認いただきたい点】
1. 方向性は合っていますか?
2. 優先順位で調整すべき点はありますか?
3. ○日までに進めて問題ありませんか?
何かご不明な点があれば、お気軽にお声がけください。
2. 複数案提示の習慣化
- 必ず2-3個の選択肢を用意する
- 「どれがベストか分からないので判断をお願いします」ではなく
- 「現状では○案が適切と考えますが、いかがでしょうか?」で主導権を持つ
3. 進捗の可視化
- 「今ここまで進んでいます」を定期的に共有
- 問題が起きそうな兆候を早めに報告
- 「順調です」だけでなく「こんな懸念があります」も伝える
週次・月次で見直すべきポイント
【週次振り返り】
- 今週「勇気を出して粗く出した」案件の結果はどうだったか?
- 上司からのフィードバックで繰り返される指摘はないか?
- 自分の判断基準で間違っていた部分はどこか?
【月次振り返り】
- この1ヶ月で「仮説検証型」のアプローチを使えた場面は?
- チーム全体の仕事の進め方で改善提案できることは?
- 自分の「決断ルール」をアップデートする必要は?
よくある質問と回答
Q: 上司が「丸投げ」タイプで、何を聞いても「君に任せるよ」と言われます
A: これは実は上司の問題というより、質問の仕方を変える機会です
× 悪い質問例:「どうすればいいですか?」
○ 良い質問例:「A案とB案で迷っていますが、○○の観点から○案が良いと思います。いかがでしょうか?」
上司に判断させるのではなく、自分の判断に対する承認を得るスタンスに変える。
Q: 「試作を早く出す」と言っても、社内の承認プロセスが複雑で時間がかかります
A: 承認プロセスの前に「非公式な確認」を挟むのが有効です
- 正式な承認前に、関係者に「方向性だけ」確認を取る
- 「正式な資料作成前に、イメージ共有させてください」というスタンス
- メールやチャットで「こんな感じで進めようと思いますが」と気軽に相談
Q: チーム内で「完璧主義」の人がいて、全体の進行が遅くなります
A: チーム全体の「成功定義」を最初に合意することが重要です
- プロジェクト開始時に「60%の完成度で十分な段階」を明確化
- 「完璧を目指すべき部分」と「スピード重視の部分」を分ける
- 定期的に「今の進行速度で目標達成できそうか?」を確認
第2回のまとめ
今回の重要な学び
- 上司の承認は免責にならない現実
- 想定リスクを明記した確認で自分を守る
- 文書化とプロセスの可視化が重要
- 誰も正解を知らない時代の仕事術
- 仮説→実行→フィードバックのサイクル設計
- 完璧より「早くズレを見つける」ことを重視
- 試作→確認→調整の設計型アプローチ
- 「完成」ではなく「案」として出す習慣
- 判断軸と前提を言語化して共有
- 時代に合った評価軸の理解
- 「最初から正解」より「素早い修正力」が評価される
- 仮説検証型の仕事術が今後のスタンダード
明日から実践すること
- 次の確認メールで「想定リスク」を1つ以上明記する
- 1つの仕事で「複数案提示」を試してみる
- 「80%完成度」で途中共有する場面を意図的に作る
次回予告:チームを動かす次世代マネジメント
第3回では、個人の仕事術から一歩進んで、チームや組織を動かす側の視点について深掘りします。
- 従来の「指示型」から「仮説検証型」ファシリテーターへの転換
- 「曖昧さを設計に取り入れる」新しいマネジメント手法
- 心理的安全性と自律支援のバランスの取り方
- 意思決定プロセスの可視化で組織を強くする方法
- 個人の「構造思考」をチーム価値に転換する具体策
マネジメント層や将来的にリーダーを目指す方に向けた、より発展的な内容をお届けします。
今回の「不確実な環境での仕事設計術」を個人レベルでマスターした次のステップとして、組織全体を動かす力を身につけていきましょう。
第1回をまだお読みでない方は、こちらからどうぞ。シリーズを通して読んでいただくことで、より深い理解と実践につながります。
Photo by Getty Images (@gettyimages) on Unsplash
コメント