　HHKB HYBRID発売されましたね。欲しいですね。私は間が悪くHHKB追加購入したばかりなので泣いています。id:kfly8です。

　この記事はEngineering Manager vol.2 Advent Calendar 2019の20日目の記事です。

　伝えたいことはタイトル通り「フィードフォワードをしてから、フィードバックする」ことが良いという話です。場面はピープルマネジメントを想定していますが、コードレビューがフィードバックの１つなのでエンジニアにとって身近な内容だとも思います。

　ここでのフィードバックは、目標達成のための軌道修正のことです。ロケットの軌道修正から来た言葉だそうです。ロケット機内にいることを想像してみると、何の手助けなしに自分がどこを飛んでいるのか把握するのは難しいと思います。プログラミングであれば、自分が書いたコードを客観的に見るのは難しいと感じませんか？少なくとも自分には難しいです。なので、コードを一晩寝かせたり、あるいは人に見てもらうことで気づきを得ようとします。自分がロケット機内にいたら問題に気づけないので、ロケットの外に出たり、周りに教えてもらって、ようやくどこにいてどこに向かっているか認識できます。自己認識を調整するために、フィードバックは必要だと思います。

　ただ対人間のフィードバックでおこりがちな失敗はあると思います。正直自分は失敗だらけです。例えば、フィードバックされる側からしたら「なんでそんなこと言われなきゃいけないんだ」と抵抗を感じることはあるあるです。原因は、フィードバックを求めていない場面だったり、そもそも目標の認識が合わせられてないってことがあると思います。フィードバックが、自分では変えようがない過去の出来事に対しての指摘になるので、批判的なニュアンスがどうしても伴います。

　フィードバックは、自己認識の調整のために必要だと思いますが、どうしても抵抗感を作りやすい側面があります。

f:id:kfly8:20191220074008j:plain:w600

　フィードバックの抵抗感を緩和する手段はないか？

　今回の自分の提案は「フィードフォワードしてから、フィードバックする」ことです。フィードフォワードとは、これから起こる出来事を予測し、予告することです。例えば、開発をする際、性能か、堅さか、はたまたさくっと書くことか、期待を話し合っておけば、あとでコードレビューする際、どんな観点でのレビューになるのか予想がついていてある程度開発をする人は準備をしているので、抵抗感は減ると思います。準備の期待の合わせだけなく、仕事を進めている最中も「次はこんなこと起きそうだねー。あそこが落とし穴になりそう。」といった話が、「あそこどうだった？」とフィードバック時の伏線に繋がります。

　まとめると、フィードフォワードとフィードバックの関係を業務に当てはめると次のようなイメージです*1。フィードバックだけの片割れ運用をしていたら、フィードフォワードを意識して取り入れてみると良さそうです。