システムエンジニアはレビューで２度死ぬ

設計書や実現仕様の検討資料を作成するときに、必要なインプットの情報が抜け漏れなく取り込めているか、仕様としての条件を場合分けできているか、アウトプットは要件どおり充足しているか、などなど考えながらやっていると思いますが、でも時間的制約もあって本当のところはやっつけで書いていたりしませんか。

「わかっているけれど…」実感としてはこう思っているんでしょう。「時間が足らない」と。

ときどき、もっともらしく「ちゃんと推敲しないから二度手間になるんだよ」なんていう人もいたりしますね。「なんだよ、こっちだって時間がないんだよ」と言いたいわけです。内心「間違っていたら後で直すんだからレビューで指摘してくれ」って。

ちょっと「推敲」の意味を調べてみましょう。

すいこう −かう［0］【推敲▼】
（名）スル
〔唐代の詩人賈島（かとう）が，「僧は推す月下の門」の「推（おす）」を「敲（たたく）」にしようかと迷って，韓愈の助言で「敲」にきめたという「唐詩紀事賈島」にある故事から〕
詩文を作るとき，最適の字句や表現を求めて考え練り上げること。「 −を重ねる」「原稿を−する」

都合の良いように要約すると「最適を求めて考えること」になりますね。そう、ベストを尽くせ、と言うことです。

さて、冒頭の「間違っていたら後で直すんだからレビューで指摘してくれ」はこれに当たりませんね。全くもって逆です。「推敲しろよ」っていう方が理屈では正しいわけです。ぐーのねもでません。

でも普段の資料の作成のルーチンを考えてみましょう。

「なんだよ、こっちだって時間がないんだよ」
「間違っていたら後で直すんだからレビューで指摘してくれ」

これって、レビューを２回する前提で作業していませんか。だって、１回目のレビューを受けて、指摘を修正してもう一度レビュー受ける前提ですよね。

「時間がない」と言いつつ、レビューは２回するんですよ。１回ではなくて。時間がないなら１回で終わるようにしたらいいのにって思いますよね。レビューが１回で終われば、レビューイもレビューアも双方幸せなのに、わざわざ２回する前提です。

１回で終わってもそれ、ラッキースケベならぬレビューアがしょぼくてすり抜けちゃっただけじゃないんでしょうか。そういったしょぼくてすり抜けちゃうレビューはあとあとの工程でバグを出すんですが。

そういう作業の仕方ってどう思いますか。え、そうですよね、やっぱりダメですよね。じゃあどうするかって話なんですが、設計にかかる情報を整理する方法を変えるしかないんだと思うんです。凡庸に言えば、抜け漏れなく、ですけど、MECEでっていう他ないですね。あとは、全体を俯瞰して見直しているか、です。

MECEの方は使用の条件を決めるときに、Aの場合を考えたらA以外のすべての場合の振る舞いを考えるということです。Aが正常でA以外はエラーなら、エラーのときの仕様としての振る舞いをきちんと決めておきなさい、って。

俯瞰して考えるというのは、自分の担当する機能仕様だけ考えていてはあとで痛い目にあうから、全体のシステム構成図やネットワーク図を眺めて自分の担当する機能に作用する他の機能を明らかにしておきなさいっていうことです。同じように自分の機能仕様がアウトプットするデータで影響を受ける他の機能がいるかどうかを知っておきなさい、っていうことです。

誰かのデータを使って加工してそのデータを誰かが使うのですから。その誰かは人かシステムかは問いません。

機能仕様を書くとき、全体の位置付けから書くことで自然とMECEになっていくはずなんです。機能分解しているので。それでもバグが出るのは機能分解して機能仕様の詳細を決定しているときに分解した片側まで考えが及んでいないからです。

だから、想定外なんて恥ずかしいことを言うんです。想定外じゃなくて考えていなかったんでしょ。そういう仕事の仕方をしたんでしょ、と言われない、言わせないためにもちょっと推敲する時間をとってレビューを１回で終わらせましょう。