【新人SE向け】ウォークスルーの準備とレビューのやり方
趣味として一人でプログラムを組んだ人が仕事で複数人でプログラムを作成すると違いを感じることがあるのだが、大きな違いの一つには情報を共有しながら作成するということがあげられる。
ウォ－クスル－という成果物の情報共有の仕方をする機会があったのでウォ－クスル－について具体的にどんなことをするのかを自分用のメモも兼ねて説明していく。
ピアレビュー､ウォークスルーとは
情報共有の手段の一つには仲間や同僚によるピアレビューというものがある。このピアレビューと呼ばれる情報共有のうち、よりカジュアルなレビューのことをウォークスルーと呼ばれている。
また、この記事ではウォークスルーはそのまま呼ぶが、場所によってはアルファベット2文字で「WT」と略して記載されることもある
なお、似た言葉に認知的ウォークスルーという言葉があるが、認知的ウォークスルーはプログラムをユ－ザ－になりきって動かすというレビュー方法であるので、基本的に別物と思ってもらってよい。
ウォークスルーの大まかな流れ
ウォークスルーの大まかな流れは以下の通りである。
- ウォークスルーの開催予告をする
- 説明の準備をする
- プログラムの作成者が確認しておきたい部分を説明する。
- 記録を作成する。
- 指摘された点を繁栄する
開催予告について
プログラム作成者が確認してほしい点がある時に事前に○○日の○○時頃にウォークスルーをしたいですと事前に申告する。
開催予告のポイントは時間を早過ぎず､遅すぎないタイミングに設定することである。
○早すぎることによる問題点
後述する事前準備が間に合わなくなる。特に右も左も分からない新人の状態だと、事前準備にもかなり時間がかかることが予想される。そのため、少し遅いかなと思う位の時間設定が意外とちょうど良かったりする。
○遅すぎることによる問題点
後行程にかけられる時間が少なくなってしまうため､スケジュールに遅れが生じてしまうことである。
説明の下準備について
ピアレビューのうちのウォークスルーの特徴の一つは作成者が説明を行うことである。
説明の際には以下の3点を中心に説明するはずなので、説明出来るように頭を整理しておく。
- ・プログラム変更の目的、背景を行っているのか
- ・変更したプログラムの具体的な内容
- ・プログラムの実行位置の根拠
また、作成した成果物も見せることも多いので、以下の点もチェックを行っておく
なお、「意味が曖昧な表現がないか」について少し補足を入れる。
プログラムの成果物で文章を書くものは以下の通りである。
- ・設計書
- ・プログラム内に書いたコメント
- ・プログラムのテストの仕様書
これらの文章は誰のために書くのかというと、次の行程を担当するエンジニアのためである。そのため、プログラムの仕様書に書かれてある言葉やプログラムの専門用語を使うのは問題なく、それらを専門用語を使わずに書き直す必要はない。ただし、次に担当するエンジニアはプログラムの仕様やデ－タの構造を把握しているとは限らない。そのため、作成した成果物を見るだけで作業が出来る、または調べたることができるように書く必要がある。
説明について
ウォークスルーではできたものを共有するために説明をする。話すのは苦手というのもあってIT系の方に進んだというのもあるのになのに結局共有の関係で授業を行うというね(笑)
私はプログラムの技術うんぬんより授業をするような感覚でようなものだと思ってやっている
私自身が口下手というのもあって授業をする際にやっていた事を説明する｡なお、これはあくまで私にあった型の例である。
○書くものを利用する
授業といっても常に話続けないといけない訳では無い。書いて→話して→書いてを繰り返すことで書いている最中に思考の整理をしつつ、話すことの時間稼ぎができたりする。ウォークスルー中だと説明部分を描画つツールで囲むくらいが限度だが、全て口頭の説明よりは説明しやすくなるはずである。
○沈黙を利用する
口下手であると、沈黙が訪れることが多々ある。口下手な人にとっては以外かもしれないが、沈黙の時間あることは必ずしも悪いことばかりではない 。話すときと話沈黙の時があることで、説明に緩急が生まれる。そして、聞く側にとっては今までの説明の内容を整理したり､次話し出す際に集中出来るように､頭を休められる時間になるという効果がある。
とはいっても私は10秒以上沈黙がつ続くと焦ってしまうので正直に「すみません今話す内容まとめています」と言ってしまうことが多い
○途中段階での「ここまでは大丈夫ですか?」と確認を入れる。
授業のテクニックとして一時一事の原則と呼ばれるものがある。難しい言葉を用いたが、要は一度に出す指示は一つづつにした方がわかりやすいよということである。
途中段階、または説明のきりがいい所で一旦説明を止めて確認すると聞く側の理解度が上がるだけではなく話す側も一回て話せる量を少なくできるので話を組み立てやすくなる。
○頭括型と尾括型の使い分け
頭括と尾括であるが、これらは結論、または一つの話で一番伝えたいことをどのタイミングで話すかである。最初に伝えたいことを言ってからあとからそれが何故かを補強するのが頭括、最初に伝えたいことを引き立てる根拠をあげて、最後にクライマックスとして伝えたいことを言う形が尾括型である。
尾括で話す(結論を最後)に話すメリット
ストーリー性(起承転結)を作りやすい
頭括で話すメリット
最初から結論が分かっているので話の迷走を防ぎやすい。
口下手というよりもこれは内向的な人の脳の特徴であるが、長期記憶から取り出して言語化するので、話していると論点がぐちゃる。
そのため、論点が多くなったり、自分でも何が言いたいのか分からなくなりそうな気がしたら頭括型で話してもよい。
また私の経験談ではあるが、頭括型で話始めに「変更点の一つ目の概要は○○です。これから詳細について説明入るのですが、ここまでは大丈夫ですか?」と言った段階で疑問点や質問が飛んでくるなんてこともあるので説明の手間が省けてラッキーとなることも多々ある。
○質問持ち帰り
話を終わった後に質問が飛んでくることがあるが、これらは全て即座に完璧に答えないといけないという訳では無い。
少なくとも新人の段階では「すみません勉強不足でした」と言ってウォークスルー以降にもう一度考え直す。という質問の回答を誤魔化す方法もある。(とはいっても、可能な限り以降同じような質問が来た時には答えられるようには準備をするようにはしておこう。)
ウォークスルーの修正した時の確認など完璧にすることを求められたが
上手く話せなくても焦らない
記録の作成
ウォークスルーは実行して終わりとなることは少なく、どんなにベテランであっても、間違いは起こりうる。
他のレビュー方法に比べても、カジュアルな方法ではある。しかし、改善の要点の洗い出しをすることが目的であり、一々その場で修正していたら、ウォークスルーだけで日が暮れてしまう｡そのため、後で抜け漏れなく修正出来るように修正点の概要のメモは取っておく。メモをとるタイミングは可能であれば報告中,状況的に難しそうであればウォークスルーが終わった直後に行えばよい。
反映を行う
メモを取ってあれば終わって記憶が新しいうちにメモの整理を行い、挙げられた修正点を反映する。