HYBRID発売されましたね。私は間が悪くHHKB追加購入したばかりなので泣いています。id:kfly8です。2019の20日目の記事です。伝えたいことはタイトル通り「フィードフォワードをしてから、フィードバックする」ことが良いという話です。場面はピープルマネジメントを想定していますが、コードレビューがフィードバックの1つなのでエンジニアにとって身近な内容だとも思います。ここでのフィードバックは、目標達成のための軌道修正のことです。ロケットの軌道修正から来た言葉だそうです。ロケット機内にいることを想像してみると、何の手助けなしに自分がどこを飛んでいるのか把握するのは難しいと思います。プログラミングであれば、自分が書いたコードを客観的に見るのは難しいと感じませんか?少なくとも自分には難しいです。コードを一晩寝かせたり、あるいは人に見てもらうことで気づきを得ようとします。自分がロケット機内にいたら問題に気づけないので、ロケットの外に出たり、周りに教えてもらって、ようやくどこにいてどこに向かっているか認識できます。自己認識を調整するために、フィードバックは必要だと思います。対人間のフィードバックでおこりがちな失敗はあると思います。自分は失敗だらけです。フィードバックされる側からしたら「なんでそんなこと言われなきゃいけないんだ」と抵抗を感じることはあるあるです。原因は、フィードバックを求めていない場面だったり、そもそも目標の認識が合わせられてないってことがあると思います。フィードバックが、自分では変えようがない過去の出来事に対しての指摘になるので、批判的なニュアンスがどうしても伴います。フィードバックは、自己認識の調整のために必要だと思いますが、どうしても抵抗感を作りやすい側面があります。フィードバックの抵抗感を緩和する手段はないか?今回の自分の提案は「フィードフォワードしてから、フィードバックする」ことです。フィードフォワードとは、これから起こる出来事を予測し、予告することです。開発をする際、性能か、堅さか、はたまたさくっと書くことか、期待を話し合っておけば、あとでコードレビューする際、どんな観点でのレビューになるのか予想がついていてある程度開発をする人は準備をしているので、抵抗感は減ると思います。準備の期待の合わせだけなく、仕事を進めている最中も「次はこんなこと起きそうだねー。あそこが落とし穴になりそう。」といった話が、「あそこどうだった?」とフィードバック時の伏線に繋がります。まとめると、フィードフォワードとフィードバックの関係を業務に当てはめると次のようなイメージです*1。フィードバックだけの片割れ運用をしていたら、フィードフォワードを意識して取り入れてみると良さそうです。2018の10日目の記事です。予選、暫定で生き残れたよう。isuconに参加させてもらいました。第52回「Perlで堅牢な開発」に寄稿しましたはてなブログをはじめよう!kfly8さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。