エンジニアにも信頼性がある

多くのエンジニアに、コンピュータシステムの信頼性を高くする為に、どのようなことをすれば良いですか？と聞けば、色々な手段や方式を思いつくでしょう。信頼性設計とは、冗長性を考えたり、例え誤動作をしても、問題を局所化したりすることを行うことです。例えば、電化製品や自動車にフューズがついていて、高い電圧が掛かったときに製品全体がショートしないようにするといった具合です。

ハードウェアで信頼性設計をすることは考えやすいでしょう。では、システム開発の信頼性設計は、どうでしょうか？

システム開発は、エンジニアが個々に設計を行なうため、信頼性を高くする方法はエンジニアの技量に依存すると思います。「⁠あのエンジニアが設計したのであれば、信頼性が高そうだ」「⁠あのエンジニアが設計してこのシステムは大丈夫かな？」と思うものです。システムそのものより、エンジニアそのものに信頼性があるようです。

今回は、エンジニアの信頼性について、考えてみたいと思います。

若き日の失敗

筆者が会社に入ってまもなくした頃、プログラムを数本任されました。そのプログラムは、購買データのエントリや照会といった類のものでしたが、難易度はそれ程高いものではありませんでした。

プログラムを作成後、一通りのテストを行ない先輩エンジニアに報告しました。「⁠おっ、早いじゃん」という感じで言われ、得意になったものです。

プログラム開発が一通り完成し、組合せテストに入る段階になり、データをいったんクリアし、検索キー情報も何も入れずに実行ボタンを押すとプログラムがアベンド[1]しました。すぐに修正をして対応しましたが、上司から「⁠（⁠この程度のことも、ろくに確認していないなら）もういいよ」と言われているようで、自己嫌悪になったことを思い出します。

システム設計ができない

数年前、筆者が担当したプロジェクトは、最大時で5人程度の規模でしたが、システム設計の大半を、システム設計経験が豊富と聞いていた1人のエンジニアに任せました。

そのエンジニアは、確かに概念を纏めるのは得意でしたが、詳細なことを詰める段階となり、いつまでたっても前に進みません。「⁠概念は分かったが、そろそろ具体的な設計書に落としましょうよ」と話をしても、同じような資料が形を変えて作成されていくだけでした。

どうやらこれまでの仕事のやり方は、自分でプログラムを作りながら分からない事があった都度、お客様に仕様を確認しながらシステムを開発するようなやり方だったようです[2]⁠。

その後、何とか完成した仕様書を元にプログラム開発を進めましたが、プログラム間の論理矛盾やエラー時の処理考慮不足が発生し、大幅の手戻りが発生したのは、言うまでもありません。後で別の人から「そもそも彼にシステム設計は無理だと思うよ」という言葉を聞いたときに、その意味が分かりました。

信頼性を見極める

エンジニアの信頼性は長く仕事をしていると、ある程度決まってくるものです。平たくいうと、仕事を安心して任せられる人と任せられない人に分かれてきます。プロジェクト体制を、頭数と経験年数で考えるのは、とても危険な行為です。「⁠このプロジェクト規模だと、このくらいの信頼性の人が何人いれれば大丈夫」といった感覚がとても重要だと思います。自分の信頼性が周りからどのように見られているのか、振り返ってみると良いでしょう。

エンジニアとしての信頼性を作る努力

プログラム開発の失敗について筆者の経験を紹介しましたが、筆者は今でも、丁寧さを求められる仕事は不得手で良くミスをします。ビジネス文書を作成しても、「⁠誤字脱字」「⁠てにをはの間違い」「⁠ですます調とである調の混在」が多い自覚があります。

エンジニアの信頼性をあげる事はとても大変で、下げる事はとても簡単です。もし、自分が丁寧さを求められる仕事が苦手で、ミスが多いと自覚するならば、必ずチェックを行うクセをつけ、エンジニアの信頼性を高める努力をすることをお奨めします。