ソースコードレビュー

書いたプログラムが、コンパイルも通った、テストプログラムでテストもした。さてこれで完成です……。いやいや、もうちょっと待ってください。あなたのそのプログラムは、あなたが詳細なところを設計し、あなたがテストを考え、あなたが実装し、あなたがテスト結果を確認したものです。ここまで、他の誰の目にも触れていません。

プログラミングに限らず、システム開発の作業はなかなかに複雑で、成果物に誤りが入る可能性は常に存在します。そこで行われるのが「レビュー」です。作業者以外の目で確認して、妥当性を検証します。

レビューの進め方はプロジェクトによりますが、成果物であるプログラムを、先輩やリーダ、場合によってはお客様に見てもらうことになります。対面で見てもらうとして、成果物は事前にメールなどで送付しておくことなど、レビューをする上でのマナー、手続きのようなものが定められていることもありますので、それに従いましょう。もしも公式に定めのない場合は、先輩やリーダに相談して、レビューの時間をもらってください。先輩やリーダもそれぞれに忙しい中ですが、変に遠慮することはありません。ただ、時間をもらったからには、その時間を無駄にさせないよう、プログラムを自分の目で見て万全にすることや、もらった時間は厳守することなど、準備や段取りはしっかりやりましょう。

自分のプログラムを人に見てもらうのは、初めは恥ずかしかったり気後れしたりするかもしれません。レビューしてもらって、いろいろ具合の悪いところを指摘されるのは、叱られたり貶されたりしているようでショックかもしれません。レビュー恐怖症になってしまう新人もよくいます。ですが、レビューは第一に成果物をよくするための場であり、第二には、レビューでの指摘から自分の至らない点に気づくことのできる成長の場でもあります。

コードを書くだけが実装じゃない

このパートは実装の話のはずが、プログラミングそのものの話題はほとんどありませんでした。現実の話、実際にプログラムを書いている時間というのは、工程の何割でもないのです。

もちろん、プログラミングは、システムを動かす根幹として大事なものですし、それ自体、大変に奥深くもあります。ただ、仕事でプログラミングするということは、なかなかシンプルな話でもないのです。

執筆者紹介

山本啓二(YAMAMOTO KEIJI)
- ウルシステムズ コンサルティング第2事業部 副事業部長

独立系ソフトベンダーを経て、2001年入社、2009年より現職。アーキテクチャおよび開発プロセスにまつわるコンサルティングに多く携わる。著書に、「そこが知りたい 最新Webアプリ開発のお作法(共著・翔泳社刊)」、「プログラマの本懐(日経BP社刊)」。