From: リスキルテクノロジー 松田航
新宿本校にて、、、
プログラムや
システムの設計は
作っておしまい！
という訳にはいきません。
必ず内容を
他の人に説明する必要があります。
今回は
エンジニアとっての
「レビュー」
についてお話ししましょう。
目次
エンジニアにとってのレビューとは？
芸術家が絵を描いて
見事な作品を作ったとします。
誰もが見惚れる程の
美しい抽象画です。
しかし、
芸術家はその抽象画について
絵の表現する意味や
細かい内容については
見る人に説明する必要ありません。
絵画は
人の感性に訴えかけるものです。
説明することで
見る人が受ける感覚を
惑わせてしまうケースもあります。
しかし
エンジニアが作る
プログラムや設計書などは
感性ではなく
理論や手法を明確にしたものです。
芸術のように
人によって受け止め方が違うと
問題になる場合もあります。
そこで
他のエンジニアやユーザーに
「レビュー」
という形で
内容を詳しく説明する必要があるのです。
読んでおいてください－だけではダメなのです
設計書も
プログラムソースもあるのに
どうしてレビューが必要なの？
それを見て理解すればいいでしょう？
...という
エンジニアも中にはいらっしゃいます。
しかし、
どれだけ優れたドキュメントでも
読み手によって
理解できる範囲が異なります。
例えば...
参考書を買って勉強したという
経験を持つ方は多いでしょう。
勉強していくうちに...
「書いている内容がイマイチわからない」
「説明がむずかしい」
と思う箇所が
必ず1つや2つは出てくるものです。
そういう時に
読み手に合わせて丁寧に教えてくれる
講師がいれば理解できますよね。
レビューにおいては
関係者に内容を理解してもらうことも目的です。
設計書やプログラムを
作った本人だからこそ、
一番詳しい講師になれるのです。
エンジニアが行うレビュー
エンジニアは
レビューをする機会も
レビューされる機会も多いと言えます。
システム開発を進める上で、
よくあるレビューに次のようなものがあります。
■1: 設計レビュー
基本設計や詳細設計など
システムの設計内容について
エンジニアやユーザーに
説明することが目的のレビューです。
内容の理解を深めるの
ももちろんですが...
設計ミスを早い段階で
発見して修正するのも目的のひとつです。
2: ソースレビュー
プログラマが作った
プログラムソースを、
他のエンジニアに説明し、
適切な処理内容が行えているかをチェックします。
ほとんどの場合は
開発チーム内で行いますが、
ソースがわかるユーザーがいる場合は
ユーザーが参加するケースもあります。
3: テストレビュー
テスト仕様書や
テスト結果についてのレビューです。
テスト内容や
テストの種類に問題がないか、
不具合があった場合、
何が原因で不具合が発生したかなどを
主にユーザーに向けてレビューします。
これ以外にも
いろいろなレビューがありますが、
所属している企業やチームによって
レビュー対象は異なります。
レビューするにあたってのポイント
レビューを苦手とする
エンジニアは少なくありません。
黙々と仕事をするのは得意でも、
人前で何かを説明することが苦手！
...と言う方は多いです。
それでも、
エンジニアを続ける限り
レビューする機会はなくならないでしょう。
そういう方は、
ソースコードにコメント多用したり、
わかりやすい言葉を使って
設計書を作ったりと、
プログラムや設計書を
丁寧に作るようにしましょう。
実際のレビューでは
作成物を見ながらレビューするのですから、
丁寧に作っていれば
それを読み解く形で進めることができます。
あとはストーリーですね。
どのような流れで
レビューを進めるのかを思い描いて
レビューすれば大丈夫です。
レビューに関しては...
トーク力を高めなければいけない！
と考える方もいらっしゃいます。
それはそれで
間違いではないのですが、
トーク力を高めることが必要なのではありません。
得意不得意は誰にもあります。
トークが不得意ならば、
丁寧なドキュメントを作り、
レビューの際に
トーク力不足を補うと言ったように...
あなたの不得意分野を
得意分野でカバーできるように
それをカバーできる工夫を忘れないようにしましょう。
リスキルテクノロジー
松田
PS
誰もが優れた能力を
持っている訳ではありません。
しかし、
それに近づくための
向上心を持つことこそが大切なのです。
そして、
あなたの能力を高める手助けをすることが
私たちの役目でもあります。
