説明責任

 

開発に携わる人々の間では「仕様書」をベースに話が進められます。

 

プログラムが進みつつある状況でも、そのコードをみながら関係者で議論することはありません。

 

プログラマ以外だれもコードがわからないからです。

 

しかし「プログラム」が「仕様書」通りである、ということを言明するのはだれでしょうか？

 

「正しい仕様書」が「正しくプログラミング」されている、というのはだれが保証するのでしょうか？

 

「テスト」によってこの保証が行われる、という考えもあります。

 

ところが「テスト」は常に具体的な値の確認でしかありません。

 

消費税の計算ロジックに対して行われるテストは「1000」と入力したときに「50」と出力されることを確認するだけです。

 

これは厳密には「ロジック」の検証ではありません。

 

「1000」から「50」を導き出す計算ロジックなど無数にあるからです。

 

ソースコードが読めれば入力値に対して５％をかけているかどうかが判断できます。これがロジック検証です。

 

システム開発の現場では常に「まやかしの」仕様書、「まやかしの」テストで話が進んでいきます。

 

本来はプログラマがソースコードを説明しなければいけません。

 

ユーザはもっと認識すべきでしょう。

最終的にお金を払って買っているのは「設計仕様書」や「テスト仕様書」ではなく、正しく動く「ソースコード」だということを。