「その他」や「等」に敏感であれ

仕事の資料に「その他」や「等」という文言が見えると、思わずピクリと反応してしまう。これ、システム開発経験者あるあるでないだろうか。

なぜ反応するかというと、かつてこの言葉で痛い目を見たからである。

システム要件を指し示すユーザー側は、全体の7割を占めるメジャーなケースに注意を向ける。マニアックなケースについては「その他」とか「等」という表現にまとめて押し込んでしまう。

ところが、システムエンジニアやシステム企画者の目線だと、そのマニアックな部分こそが作るにせよ割り切るにせよ、最も労力を要するのである。

例えば、全部で50種類の商品があったとして、全体の7割を上位3種類が占めていたとする。上から順番にABCの三つだけ処理手順を決めて、その他は処理せずにバイパス、でよければ話は簡単だ。

ところが、「等」でまとめられた残り47種類のうち、3種類は「占率は少ないが処理を分けないとエラいことになる」性質の商品だと後から明らかになると、大慌てで追加対応することになる。

締め切りが迫っているところだが、ここで大慌てで対応すると経験上バグが発生しやすくなる。

優れたエンジニアはここで一旦落ち着いて、「○日までに本当に対応必要な種類を確定させてください。それ以降の追加対応は受け付けません」と冷静に仕切り直しができる。

なぜ一旦落ち着く必要があるかというと、「上位3種類＋追加3種類は対応する」となったが、「残りの44種類を対応しない理由」も同時に見直さなくてはいけないからだ。

考慮漏れが発覚した直後は、要件を提示する側も焦りが生じて、心理的にも判断軸がブレやすくなっている。

ここで慌てて突っ走ってしまうと、判断軸がいつの間にか「エンジニアの体力が続く限り追加対応をさせる」にすり替わり、デスマーチになってしまう。

実際、エンジニアの人との会話では「等」という言葉を発しようものなら、すかさず「それは具体的にどういうことですか」とツッコミが入る。

「等」という言葉はいわゆる"保険をかける"表現だが、曖昧さはITの要件定義ではできる限り排除しなくてはならない。

「ここに"等"って書いてありますよね。なのにシステムが作れてないじゃないですか」と言われて責任を押し付けられたら、エンジニアだってたまったもんじゃないだろう。

曖昧さを許さないエンジニアの世界はどことなく数学に似ている。理系の人間が目指すのも頷けるというものだ。

余談だが、エンジニアとして長年生き残っている人は、ユーザーとの緊張関係を活かすのが上手い。

お金の出し手だからといってペコペコはせず、「これ以上の変更は品質が保てないので無理です」とハッキリ言う。

金融業界は装置産業なので、IT部門に作ってもらわないと業務が回らない場面はたくさんある。「現行の仕組みってどうなってるんだっけ？」となった時に、最も確実なのはプログラムのコードを読むことだ。

ソースコードを独占しているというのは実はかなり強大な権力なのである。極端な話、エンジニアがある日突然失踪したら、たちまち業務崩壊するだろう。

そこを分かっているからこそ交渉ができて、適正な労働環境を保つことができる。

エンジニアはどちらかというと内向的で、他人に対して強く言えない人間がなることが多いが、開発にあたっての交渉術はよくよく観察するべきだ。

交渉の巧拙は、その後のエンジニア人生全体に影響を及ぼす重大事である。