アル中プログラマの備忘録。もはやコーディングしてないけど。

酔いどれまさになう。プログラマとして就職し、システムエンジニア、プロジェクトマネージャーと立場を変えながら、システム開発に関わるとあるアル中の成長記録。

システム開発

設計レビューを効果的に行うには、目的を理解してそれに沿った方法で行おう

投稿日:

Review

レビューあるある

  • 長い
  • 喧嘩してる、槍玉に上げられてる
  • 脱線する
  • 重箱の隅をつついていている
  • 不具合を見つけたけど黙ってる

などなど、結果として時間はかかる、気分も悪い、その割には後で不具合が見つかるといったことが起こります。これを避けるにはどうしたら良いのでしょうか?

そもそもなぜレビューするのか?

×:完璧な設計書を作るためにレビューをする

些細な誤字脱字も全くない完璧な設計書・仕様書。もしそのドキュメントが納品物であるなら、確かに完璧なものが必要かもしれません。

しかし、それは「設計段階」で必要なものなのでしょうか?納品前に体裁を整えれば良いだけではないのでしょうか?もし完璧な設計書があったとしても肝心なプログラムがなければ、要望を何も満たすことができません。それでは道具の手入れだけで終わってしまったのと同じで本末転倒ではないでしょうか?

○:手戻りコスト削減のためにレビューをする

ウォーターフォールでもアジャイルでも(1回で終わらせるか、小さく繰り返すかの違いはありますが)設計→製造→試験という流れで開発は進みます。

この時、試験の段階で不具合が見つかると、試験→修正→試験と作業が必要になります。場合によっては設計から直す必要もあり大変です。もし、設計の段階で不具合を見つけることができれば修正や再試験の工数を節約することができます。

多くの場合、設計段階での修正の方が試験段階(ときには製造段階)での修正よりはコストが低いです。これは経験や感覚的にもわかると思います。

ではどうすればいいのか?

目的が手戻りコスト削減ですので、期待できる削減コストをレビューのコストが超えないというのが判断の基準になります。

例:誤字脱字の指摘

例えば誤字脱字に対する指摘の場合、ものにもよりますがテスト段階で見つかったとしても大した修正コストではなさそうです。

だからといって誤字脱字を指摘するなというわけではありません。問題なのはレビューの時間を使って一生懸命誤字脱字を探したり、その指摘のために都度レビューが中断することです。そうやって時間を割いていると、レビューのコストが修正コストより高くなってしまいます。

誤字脱字程度であれば、気づいたらメモして後で渡してあげれば済むはずです。そうすれば本来集中すべきところに集中しやすくなります。

例:不具合の起きやすい部分、過去に不具合を起こしたパターンの確認

はじめての開発の場合は難しいかもしれませんが、システム開発をしていると比較的不具合を起こしやすいところ(DB、ファイル操作、通信、特殊なロジックを組んでいる部分などなど)と比較的安定しているところ(決まりきった作り方があり、過去にも実績がある部分など)が出てきます。

安定しているところを見なくて良いわけではありませんが、限られた時間で確認するのであればより不具合を起こしやすい部分(できればその中でも修正するのが大変そうな部分)から問題ないかを確認していくのが効率的です。

そうしておけば、仮にレビューが時間切れになったとしても、残っている問題は些細なものの可能性が高くなります。そうではなく、見つけやすそうなものから見つけていていると重大なものを見逃す可能性があります。

特に過去の開発で設計段階をすり抜けて試験段階で苦労したものについては、それをフィードバックして設計段階で見つけれるように工夫していくのが良いです。

これを行うためには?

これを行うには全員がレビューの目的を理解している必要があります。

その上で冷静に指摘できる環境(先輩だから控えようとか、嫌いだから厳しく行こうとかやらない)、指摘を冷静に受け止めれる環境(指摘されているのはドキュメントであって作成者自身ではないことを理解)を作っていく必要があります。

また、どこが重点的に見るべきところで、どこがそうではないのかはチームや開発しているものによって異なってくるため、徐々に修正しながらやっていく必要があります。

これらはすぐには難しい場合もあるかと思います。しかし、放置していても良くはなっていかないので、話し合っていく必要があります。

例えば私は誰がレビューイで誰がレビューアでも同じ品質を担保できるようにしたいと思っていますが、分野ごとに得意な人に分けてみてもらうというのも方法の一つです。

専門家に診てもらう場合などがそうで、単純にレビューをお願いするとつい目につくところに指摘が集中してしまいがちになるため、専門家として見てほしい部分を伝えて、それ以外は無視してもらうぐらいが良い場合もあります。

また効果の測定についてはレビューにかかった工数と仕様に起因する不具合の修正工数を継続的に見ていくのが良いと思います。これらの総和が減っていれば取り組みがうまく行っているということです。修正工数が減っていっても、それを上回るほどレビュー工数が増えていれば重箱の隅をつついている可能性がありますし、レビュー工数が減って修正工数が増えているのは見なければ行けないものを見落としている可能性があります。

良いものを楽に作るために、頑張っていきましょう。

酔いどれまさになう。

-システム開発

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

入り口

Developers Summit 2012に参加してきました

Developers Summit 2012 名称:Developers Summit 2012 (デブサミ2012) 会期:2012年2月16日(木)・17日(金) 会場:目黒雅叙園(東京・目黒) …

Jenkins実践入門

Jenkins 執事さん!公式サイトの人で、 CI(Continuous Integration、継続的インテグレーション)のためのサーバー(ソフト、サービス)。 継続的に開発、ビルド、テスト、修正、 …

「実践 反復型ソフトウェア開発」XP祭りでいただきました(2013年)

2013年のXP祭りで「実践 反復型ソフトウェア開発」をいただきました。 おすすめしたい人 本には3〜5年程度のソフトウェア開発経験のある人や、チームをリードする人、 品質について悩んでる人、反復型開 …

体系的に学ぶ安全なWebアプリケーションの作り方〜脆弱性が生まれる原理と対策の実践〜

体系的に学ぶ 安全なWebアプリケーションの作り方 Kindle版の方が安かったため、そちらを買いましたが、適宜参照しやすい紙の方を買ったほうが良かったです。 主なサンプルコードはPHPで書かれていま …

セミナー

QCon Tokyo 2012に行って来ました

QCon Tokyo 2012 はじめて同時翻訳のレシーバ利用しました。 その場で訳されていてすごいと思いました。ある程度は台本があるのでしょうか? ラウンジではアジャイルマインドの同人誌が売っていた …

カテゴリー