半蔵門御散歩雑談/ODR Pickups

株式会社ODR Room Network

このブログは、株式会社ODR Room Networkのお客様へのWeekly reportに掲載されている内容をアーカイブしたものです。但し、一部の記事を除きます。ODRについての状況、国際会議の参加報告、ビジネスよもやま話、台湾たまにロードレーサーの話題など、半蔵門やたまプラーザ付近を歩きながら雑談するように。

レビューが教えてくれたこと

レビューが教えてくれたこと【半蔵門ビジネス雑談】20191219

 

レビューを学んだのは、IT会社に入った直後だ。

tech.nikkeibp.co.jp

プログラムを開発する際のプロセスの一つとして決められていた。先輩からもそのように指導された。

プログラムを、コードを、書く。コーディングだ。当時は、コンピュータはホスト・スレーブ型で、コンピュータのCPUを利用するのは高価だった。デスクトップPCもノートPCもまだなかった。

1台を占有的に使うのではなく、割り当てられたマシンタイムを待って実行して、結果を見てデバッグする、そしてコードを修正し、再度マシンタイムを待って実行して。。。の繰り返し。

何度もマシンタイムを借りるとその分のコストがかかるので、マシンを使う前にコードが正しいかを見るのがとても重要だった。それを自分だけでやっても間違いが見つからない可能性があるので、誰かに説明しながら指摘してもらう。それがレビューだ。

レビューには、何をレビューするかということを明確にするチェックリストがあった。コーディングでは、例えば、形式的なこと/if文とend文の数があっているか、ピリオドがあるか、それから論理的な動作の確認、カウンターの値がマイナスになったり、テーブル数を超えないか、などをチェックする。それによって、マシンタイムを有効に使うのだ。

いつしか、コンピュータの価格は下がり、何度もマシンを使ってテストすることができるようになった。マシン利用のコストを意識して事前に人力でレビューするよりは、マシンを動かして動作確認していくほうが安上がりになったのだ。

会社としても、人材をレビューに費やすより、営業や企画やその他の業務に費やすほうが効果を発揮することに気づいたのだ。レビューは減少した。

 

そして私はレビューを忘れた。

 

レビューをしなくなって久しいが、最近ふとそのレビューのことを思い出す。

レビューで、長らく解決しなかった問題が解決したこと。レビューワーに説明している間に、小さな、しかし、致命的な間違いに気がつく。目の前がパッと開けて、停滞していた仕事が進んだこと。完成したプロジェクトの打ち上げでメンバーで歯目を外して騒いだこと。

自信家の若い新入社員にレビューをして、彼の間違いを指摘したこと。最初は素直に受け入れなかった彼が、やがて自分からレビューを申し入れてきたこと。やがて彼も彼の後輩にレビューをしなくてはダメだと指導しているのを頼もしく見る。

f:id:emandai34:20191122184112p:plain

論文を書くわけではない。出版の原稿は編集者がレビューしてくれる。研究者は、論文をレビューしてもらうことはあるのだろうか?発表前の論文を誰かに見せるとそれを盗用されて先に発表されたりするTVドラマのようなトラブルも起こるだろう。

最近のレビュー対象になりそうな仕事は、このブログか。もちろんセルフレビューはしている。しかし、誰かに事前にレビューしてもらうのは少し抵抗がある。デジタルで発表するブログ。ただの文章だからレビューしてもらうのは公開後でも構わない。

 

レビューは共同作業の一形態だ。

達成感を共有し、後進を育成し、先輩を育成者に育成する。

 

ところで、最近翻訳に絡む仕事を受けた。

翻訳結果は、正しい訳かどうかの正解が一つではない。文脈としてカチッとくるかどうかも人によって異なる。自力レビューでは限界がある。レビューが有効な分野だと思う。

またレビューをする機会が増えることを少し心待ちにしている。