レビューの進め方

仕事場では業務マニュアルを作ったり、プログラムの改修をしたりすることが多くあります。
その作業工程で発生する「レビュー」について考えてみました。

業務マニュアルの作成にしても、プログラムの改修にしても、担当者との相談はありますが実作業は私一人で行っています。
するとある程度のレベルまでは自分の成果物に対して自分でレビューをする、というふうになります。
その状態に私は少し疑問を持っていて、もっとユーザにもレビューに積極的になって欲しいと思っていました。
では私はユーザに何をレビューしてもらいたいのだろう、と考えてみました。

• 業務の解析結果
• プログラムの解析結果
• 解決策の模索、実装方法
• 最終成果物(プログラム、マニュアル、仕様に関するドキュメントなど)

これらは私が実際に作業をしていて作成・レビューの段階で行き詰まることが多い事項なのですが、あれ待てよと。
これらに対して頭を抱えるのは、まだまだ未熟な技術者である私には当然のことじゃないかと。
むしろこうして頭を抱えている間にこそ成長のきっかけが見いだせるはず。

…なんとなく抱いていたレビューに対する疑問がクリアになってきました。
レビューするのに必要な知識が足りないこともそうですが、レビューという作業の進め方そのものにもまだ改善の余地がありそうです。
単にいいものを作りたいという気持ちだけでレビューするのではなく、レビューという行為そのものにもレビューが必要なのです。


私は今のレベルの仕事をこの先ずっと続けていくつもりはありません。
もっと自分なりに高いところへ進みたいと思っています。
このブログのテーマでもありますが、今向き合っている仕事を通して成長していかなければなりません。
今向き合っている仕事で成長ができないと思うなら、向き合い方や向き合う対象を変えなければなりません。


辛いけど、頭を抱えた分だけ成長していける、そう信じています。