こんばんは。
遠足のおやつの金額制限って今もある文化なんでしょうか。
プロセスは大切なのか
「プロセスが大切か、成果が大切か」という議論はときどき見かけるような気がします。
どちらも重要な要素であり、だからこそ議論されるテーマであるとは思うのですが、一般的には成長という観点ではプロセスが、仕事という観点では成果が重視されるイメージがありますよね。
ただ、この認識は揃っているのにもかかわらず、すれ違いが起こることが少なくありません。
その背景には「プロセス」に対する視点の違いがあるのでは？というのが今回のお話です。
プロセスの二つの側面
まず、このすれ違いの大きな要因である「プロセス」と呼んでいるものを改めて考えると、実は二つの側面があることに気付きます。
「過程としてのプロセス」と「根拠としてのプロセス」の二つです。
過程としてのプロセス
タスクを完了するための具体的な手順やステップ。詳細な行動や試行錯誤の記録。
根拠としてのプロセス
成果や結論に至るための理由や論理的な裏付け。なぜその結論に至ったのかを説明するための情報。
重要なポイントは、仕事という観点では「過程としてのプロセス」は成果に含まれないですが、「根拠としてのプロセス」は成果に含まれるということです。
上司の要求は矛盾している？
簡単な例を挙げてみます。
ある部下が上司に報告を行う際、前回は「プロセスはいいから結論を簡潔に伝えてほしい。」と言われました。
そこで今回は前回の反省を活かして結論だけを報告すると、今度は「結論だけではよくわからない。そこに至るプロセスを説明してほしい。」と言われてしまいました。
一見すると上司の振る舞いが矛盾しているようにも思えますが、この会話における前者は「過程としてのプロセス」、後者は「根拠としてのプロセス」で別のものを指しています。
上司は結論に至る根拠を知りたいのであって、詳細な過程を聞きたいわけではありません。（まぁ過程自体が根拠になることがあるのがややこしいところでもあるのですが…）
抽象度が高いので、もうちょっとエンジニア寄りの具体的な例を出してみます。
レビューにおけるやり取りの例
レビュアーとレビューイのやりとりを例にします。
あるシステムに機能改修を行うにあたって、影響範囲を調査した結果をレビューする場面としましょう。
結論のみの場合
レビューイ「調査の結果、影響範囲はこれでした。問題ないでしょうか。」
レビュアー（一体何をレビューすれば…？）
結論＋過程
レビューイ「調査をするにあたってまず○○から調べようと思ったんですがその途中で△△も関係することに気付き、仕様がよくわからなったのでAさんに聞いてみたら××も影響するよと言われたので…（略）」
レビュアー（つまりどういうことなんだ…？）
結論＋根拠
レビューイ「今回の調査にあたってまずは関係する機能を洗い出し、○○という観点でフィルタしました。表にまとめて対象外はグレーアウトしてありますが、何か気になる点はあるでしょうか。」
レビュアー「フィルタの観点は問題ないです。ただ、一覧にない△△という機能も一見無関係そうに見えますが、影響があると思うので調べてみてください。」
だいぶ極端な例ではありますが、違いはわかりやすいかと思います。
相手は何を求めているのか
シンプルな話なのですが、相手が何を求めているのかを意識することが大切です。
何かを判断してほしいのであれば、どんな情報があれば判断に足るのかを考えます。
手段としては、自分しか知らない前提情報を抜きにして相手が判断できるかどうか自問してみるとか。
何かを報告・説明したいのであれば、物事の背景や説得に値するだけの材料が揃えられているかを確認します。
手段としては、上司がさらに上司により高い抽象度で報告・説明できるだけの情報になっているかチェックするとか。
はい。そんな感じです。
何となくぼんやり思っていたことをちょっと整理したかったんです。
こういうことって誰が教えてくれるんでしょうか。
コミュニケーションって難しいですよね。
