いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。

ドキュメントを見て分かる現場のこけ方 Part8 ねちっこいレビューをする現場

»

--ふれこみ--

 作業の計画は綿密に立てて、綿密にレビューすることで確保できる。チェックする体制を厳重にしておけば、ドキュメントでの抜け漏れを防ぐことができ、トラブルを未然に解消することができるはずだ。

--実際--

 技術と関係無い立場の人がレビューをすることがある。そうなると、プロジェクトの炎上は必至だ。諦めるしかない。分からない人に理解させるために、膨大な工数が割かれてしまう。

 また、レビューの基準がかなり曖昧だ。チェックする項目を明確にしてレビューしているのを見たこと無い。チェックする項目にしても、レイアウトか内容か、内容にしても、文言のブレか、仕様との合致か、設定内容の妥当性か、チェックリストが作れるくらいの項目がある。

 これだけの項目があるにも関わらず、書類を印刷させて、その場でレビューし始める。これはチェックリストを作らずにサーバの作動検証をするようなものだ。あまりに無計画過ぎる。しかも、事前にドキュメントを熟読することが無いので、レビューの度に指摘漏れが生じやすい。

 その場でレビューする形式では、レビュアーにも負担は集中しやすい。これは以外と認識されていない。何の準備も無しにドキュメントの内容を確認するのは、かなりの理解力や思考力が要求される。真面目にやろうとするとかなり大変な筈だ。

--こけ方--

 レビューするのはいいが、単に間違いが指摘されるだけだ。何が正しいのかというところまで検討されない。「間違えてる。はい、ダメ!」のような突き返し方をするので、メンバーが精神的に疲弊する。

 結果として、レビューを厳密にやればやるほど現場は殺伐とする。レビューする側も監獄の監視官のようになっていく。そして、どいういう訳か高圧的になったり、罵ったりするようになってくる。

 間違いしか指摘しないので、レビューをする側もされる側も何が正しいかを見失っていくことになる。モチベーションは下がるし、高圧的に詰められるし、進捗は遅れし、だんだんと仕事をするのがしんどくなってくる。

 一般的にはレビューされる側の悲鳴をよく聞くが、レビューする側も実は悲鳴を上げている。レビューするドキュメントの内容がわからないので、相当な不安を感じている。ストレスはかなりかかっている。

 レビューする側も、メンバーからの反発をさけるため、重すぎるプレッシャーやストレスのため、高圧的にならざるを得なくなる。結局、みんなが不幸になるのでプロジェクトも疲弊してレビューも機能しなくなり、最悪、破綻してしまう。

--解決方法--

 じつは解消方法はかなり簡単だ。レビューの際に、できている部分はできていると認めるのだ。よく勘違いされているが、レビューは間違い探しではない。できているところも的確に伝える必要がある。

 8割完成しているドキュメントでも、2割のできていない部分だけをやり玉に上げて好き放題に問い詰めると、10割できていないと無意識に判断してしまう。そして、8割の完成している部分と思考がかみ合わなくなり混乱してしまう。

 こうなると、どの情報が正しいか確信が持てなくなり、ドキュメントの修正作業はできなくなる。ドキュメントの修正を依頼しても、ほとんど修正されずに返ってくる原因はこれだ。よく言われるPDCAのプロセスのC(Check)がK(Kill)になっているので、このプロセスを個人的にPDKと呼んでいる。

 レビューする内容もリストアップしておこう。誤字脱字やレイアウトであれば、わざわざ責任者がチェックする必要もない。それに長けた人に作業を割り振って、責任者の負担を減らすこともできる。ただ、責任者がレイアウトや誤字脱字のチェックしかできないのであれば、ご退陣頂くのがベストかもしれない。

 レビューする上で重要なのは、できた部分を認めていくことだ。そうしないといつまで経っても進捗は進まない。あとは、間違えた人を罵らない事だ。この二つを実践するだけでも、情報の錯綜と殺伐さは回避できる筈だ。

--総論--

 ねちっこいレビューは不安の表れだ。やってる時点で実力不足はほぼ確定している。基準が明確にできないから、ねちねちやるしか方法が無いのだ。そういう人を槍玉に上げて叩きたくなるが、突き詰めれば人材を育成していなかったツケだ。個人に責任を追及するのも違う気がする。

 間違える、イコール迷惑。間違える、イコール悪。そいういう単純思考では問題は解決しない。悪に対しては何をしてもいい。迷惑をかけたから罰せられるべきだ。という思考から発展して、できている部分が見えなくなるという状態に至る。こうなると、悪循環しか生まれない。

 技術も大事だが、精神論についても必要なのではないだろうか。それも、根拠のない感情論でなく、理論的な根拠に基づいた精神論だ。現場の殺伐さの解消方法は、もっと考えられてもいいのではないだろうか。

Comment(3)

コメント

ハリコフ

システムの稼働までで考えたらレビューは手間暇が掛かるだけですが、長期間に及ぶ保守フェイズを考えると、それが難癖に近い内容でもあった方が良いですね。

複数人でプログラムを書くと、中に必ず、規約を無視したり、不必要に複雑なロジックにしたりする人間が出てくる(大抵は新人か奇人)。そういう悪い意味での出る杭を叩いて潰す(要は教育)のをレビューの目的と考えれば、悪いものじゃないかもです。

そもそも、機能の検証はテスト工程で行う訳ですから、レビューの内容が規約の順守やロジック面に偏るのは仕方ない気がします。

Anubis

> ハリコフ さん
コメントありがとうございます。

>そういう悪い意味での出る杭を叩いて潰す(要は教育)のをレビューの目的と考えれば、悪いものじゃないかもです。

そういう目的であれば、
ねちっこくいくよりスパッといった方がいいのではないでしょうか。
根拠を揃えてズバッと指摘です。

そもそも、規約を無視したり、不必要に複雑なロジックにしたりする人が
ねちっこくないですか?

難癖をつけると難癖が返ってきます。
同じスタンスで接すると、長期戦になりやすいと思います。

>レビューの目的と考えれば、悪いものじゃないかもです。
アプローチは違いますが、方針は同じ意見です。

ハリコフ

>ねちっこくいくよりスパッといった方がいいのではないでしょうか。

確かに、その通りです。

書きたかったのは、立ち話で話すと喧嘩になるだけなので、レビューという公式の場所で指摘するのであれば、レビューの意味もあるのでは?って事で、指摘の仕方(ねちっこいとか)は、あんまり意識してませんでした。

コメントを投稿する