忍者ブログ

東からの放浪者

様々なソフトウェア開発を経験してきた視点から、開発、マネジメント、経済などについて書いています。
タイトルは、あるレトロゲームからのオマージュ。

ツイッターアカウントはこちら。

ピアレビューの勧めと注意点(レビューと投資)

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

ピアレビューの勧めと注意点(レビューと投資)

長々とレビューの話を書いてきましたが、
今回は「この観点でレビューが語られることってないよなぁ」と思っていた内容です。

投資という観点から見たレビューの話です。

そもそも、プロジェクト計画に投資計画が含まれていないことが多いんですけどね。
そのせいで、下流工程でキツくなるプロジェクトが多いのです。

(今までの記事)
⇒ ピアレビューの勧めと注意点(レビューの種類)
⇒ ピアレビューの勧めと注意点(よくないレビュー)

ピアレビューの導入

自動化との併用

ピアレビューの導入を考えるときは、
同時に、文書やソースコードのチェックの自動化も考えましょう。

いきなり目視によるレビューの否定かよ!

と思うかもしれませんが、開発が大規模化すると、文書やコードの量は増えます。
そうなると、すべてをレビューに頼るわけにはいかないのです。

初めのうちから、レビューと自動化の棲み分けを計画し、
開発者は「人の目でしかチェックできない」部分に集中すべきです。

以下のチェックは自動化しやすいので、早めに導入を始めましょう。

  • 表記ゆれ(同じ用語の省略形が混在してないか?等)
  • 翻訳ゆれ(同じ単語が、違う単語に翻訳されていないか?等)
  • コーディング規約(コードの体裁に関するもの等)

自動化も効果を上げるまでには、運用の慣れ、ノウハウの蓄積が必要です。
中長期の投資になると思って、計画的にコストを配分してください。

レビュアーを育てる

開発プロジェクトでは、レビュアーが育っているかどうかを見るだけで、
プロジェクトの後半が「混乱するか否か」が分かります。

それくらい重要なのです。

レビューができる = 代役ができる

前回の記事で、「レビューの負荷が特定の人に偏ってしまうことがある」と書きました。

開発の仕事は、すべてをマニュアル化することは不可能です。
専門的な知識と経験を必要とする仕事が大半です。

特定の人に仕事が偏ったとき、代役を務められる人、少なくとも手伝える人がいないと、
開発の進行が妨げられてしまいます。

レビューができる人というのは、この代役ができる人になります。

レビュー導入の本質 =人材投資

レビューは、上手く行えば、低コストで手戻りを防いでくれる優秀な手段です。
しかし、私は「人材を育てる」という部分こそ、大事だと思うのです。

正しいレビューの方法をいくら導入しても、人材が育っていなければ効果はありません。

人材投資って、なんか難しいな・・・(*'-')

そんなに堅苦しく考える必要はありません。
必要なのは「知識と経験」です。

開発者たちが必要な情報を共有でき、また経験を積める環境があればよいのです。
そして、その環境を作るのがマネージャの仕事なのです。

生産性向上のための投資とマネジメント

レビュアーの育成は、特に難しい話ではありません。

プロジェクト運営ができていて、「生産性」を正しく理解している組織では、
自然とレビュアーが育つのです。

生産性は投資によって向上する

以前、「開発における生産性の誤解」という記事の中で、
以下のようなスライドを紹介しました。

生産性を上げるための投資

生産性を上げるには、この3種類の投資をバランスよく計画的に行う必要があります。

実は、先に説明した「自動化の併用」は、設備投資、技術投資であり、
レビュアーを育てる」は、人材投資なのです。

※もちろん、自動化の運用にも知識や経験は必要なので人材投資の要素は含まれますが。

投資にはマネジメントが必要

そして、人材投資、技術投資は中長期の視点が必要です。

開発初期から始める投資

マネージャが、

プロジェクト後半までに、このような人材が必要であり、
プロジェクトチームの生産性は、ここまで引き上げておく必要がある

と目標を設定し、
プロジェクト計画に投資計画を組み込んで運用していく必要があります。

とにかく、レビュアーが育っていないプロジェクトは、
プロジェクト計画がお粗末なことが多いのです。

今日のまとめ

  • レビュー導入の本質は、人材投資である。
  • 自動化(設備投資、技術投資)を併用して、レビューの効果を上げる。
  • マネジメントが機能しているプロジェクトではレビュアーが自然と育っている。

私が以前、働いていたとある職場では、
「成果物の品質は、開発者のプロ意識次第」という教義があり、

  1. 特定の人に負荷が集中する
  2. 誰もその人を手伝えない
  3. その人が休む
  4. 作業が止まる

ということを毎プロジェクト繰り返していました。

「プロ意識」とは、あくまで開発者の行動を後付で評価するための抽象語であり、
生産性向上という具体的な現象の原資になるものではありません。

当然、この組織では中々レビューが根付きませんでした。
記事を気に入っていただけた方は、クリックしていただけると励みになります。
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓


PR

コメント

プロフィール

HN:
なかば
性別:
男性
職業:
元ソフトウェアエンジニア
自己紹介:
東京のゲーム会社でゲームプログラマ。
家電メーカーで組み込みエンジニア。
その後、京都に移動して観光を楽しみながら
製品開発、業務改善、QA管理などを経験。
今は東京に戻って暮らしています。

詳細な自己紹介は、こちら

ブログ紹介

管理人(なかば)の個人ブログです。

もともと、以前の職場で投稿していた社内ブログの延長で書き始めました。
エンジニア仲間に向けた雑な口調はそのままにしていますが、その辺は気にせず読んでもらえると嬉しいです(*'-')

諸事情により更新を停止していますが、生きています。そのうち再開する予定です。

カレンダー

03 2024/04 05
S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30