SIerとしてよく見る工程

とってもスタンダードな現場でしたら、下記のようないわゆる"工程"で成り立っているはずです。

結構長いですよね。
システム開発(ウォーターフォール)はなかなか大変なんです。
ちょっと端折った書き方をしている箇所もありますが、ここからそんなに外れないはずです。
で、この中で全フェーズに渡って絶対に行われる作業が「レビュー」です。

もちろん、各フェーズにおいてレビューの観点は変わってきます。

外部設計でのレビューであれば、ユーザーの目に触れるUI部分については違和感がないか、などという観点でレビューしますし、内部設計であれば次は開発フェーズなので「これで作れるかな？」というわかりやすい観点になります。

上流であればあるほど、レビュー観点が曖昧で難しくなります。

なぜレビューが必要なのか？

SEや、SIerとして働く方であれば、レビューを受けたことがない人はいないのではないでしょうか。
もちろん、私も例に漏れません。

今ではだいぶ丸くなりましたが、3年目くらいまでの私はかなり横暴で、横柄でした。
レビューでもっともな指摘を受けているにも関わらず、なぜか不機嫌な表情をしていたものですw

それは、レビューの目的を心の底ではわかっていたからです。

レビューを受けたことがある方であればわかるかと思いますが、レビューの大きな目的の一つに、「品質担保」が上げられます。
つまり、穿った見方をすると「おまえは単独で品質担保できないのだ」という評価を突きつけられているようなものなのです。

数年経ち、私がレビューアーとして振る舞えるようになり、チーム全体の品質管理も行うようになってからは、レビューのハードルがかなり上がりました。

「俺が最後の砦なんだ」
「俺がミスを見逃したら顧客の評価に直結する」

と考えるとドキドキします。
レビューアはいつも緊張感を持ってレビューしないといけません。

言い方は良くないですが、本当に心が擦り減ってしまいそうなポジションです。
なので、レビューアの力だけで全てを賄うことはなかなか難しいです。

時間もたっぷりあるわけではないですし、ポイントを絞ってレビューできるのが理想です。

二つ目の目的、こちらの方が私は重要だと考えています。

レビューは指摘するだけでは駄目です。
それだとレビューイが萎縮しますし、一緒に働くチームメンバーなんですから、長い目で見てちゃんと成長してもらわなければなりません。

後輩や部下にやり甲斐を与えるのは、上司の役目です。

とっても苦手なんですが、前回の指摘が解消されていたり、難しい設計が上手くできていたら、
「やるやん！」
と言ってあげるように心掛けています。

私にとってはコレが一番むずかしい。。
でも、レビューイが成長してくれて、ゆくゆくは自分と同じレベルの品質を保てるようになれば、レビューアの負担は減りますよね。
しかも、チームの二番手として活躍してくれるわけです。

優秀なチームには、必ず優秀な二番手がいるものです。
リーダーは後輩を育て、チームに良い循環を起こさないといけません。

レビューア、レビューイは決して上下の関係ではありません。
理想は、お互いに指摘し合えるのが健全な関係だと思っています。

「品質」に上司と部下なんてないですからね。
品質は「満たされるべき基準」であって、その基準に対してどのようなプロセスを用いて近付けるか、が品質担保の肝です。

あの人がレビューしたからOKだろう、という基準は非常に曖昧で危険です。
現実的にはそのような状態が大変多いですが、属人化した品質担保は組織の成長に繋がりません。

レビューイは、レビューアのレビュー観点を吸収して、いつでも自分がレビューアになれるように意識しないといけませんし、レビューアは指摘だけじゃなくて、誰でも品質担保できるような、「教育」と「品質担保の仕組み」を考え続けないといけません。

よくある話ですが、８０点くらいまでは簡単に品質が向上するのですが、残りの２０点を拾い上げようとなると、指数関数的に労力が掛かります。
その２０点を、なんとか「仕組み」で対応できないかなぁ、、と知恵を絞るのが最近の私の仕事です。

なかなか難しい問題ですが、自動化やチェックリスト化で簡単にできる部分を増やすのも、愚直ですが効果的な方法です。
こういう、知力が問われる問題は楽しいですね。

テストの自動化や、テストファーストの考えがSIer界に少しずつ浸透してきているので、私ももっと勉強しないと。
今日はたまの真面目な話でした。