たまにしか使わない機能ほど丁寧に作りましょう

まもなく令和の時代になりますね。年号表記が平成31年ではなく「令和元年」となります。

各システムからレポート印刷するとき、画面に年号表示するとき、の仕様が変更になるわけです。

昭和64年から平成元年に変わったときや、「2000年問題」のときを思い出します。

今回はあの頃ほどの混乱はないでしょうけれど。。

令和元年への年号変更に限らず、いろんなところで日々システムの改修が行われています。

私の仕事先、取引先においても、いくつか大規模なシステム改修の相談を受けています。

「2025年EOS問題」があるからか、20～30年ぶりの大型改修のご相談の場合、

・現行システムが「小さく作って」「何度も改修を繰り返した」秘伝のたれ状態になっている

・よって今回の大規模改修は実は初めての大型SIである

・SIをどこか1社に一括発注したいがなかなか請けてくれるベンダーに出会えず「分割発注」となる

最近の傾向として上記のような特徴を感じています。

この傾向の影響と思っているのですが、最近システム開発の品質管理意識が低くなってきている或るいは意識が人によってばらばらに重視・軽視されている危惧を感じています。

少し前に、弊社も参画していた超大規模システムが稼働開始し、そのクライアントの基幹システムは約30年ぶりに刷新されました。

システム処理はざっくり分けると「年次」「四半期毎」「月次」「週次」「日次」「随時」に分類できます。

例えば年次処理は1年に一度しか実行しませんから、月次処理のように当月処理でみつかった不具合を修正して翌月処理では改良されていく、という流れになりません。場合によっては、年次処理は新システム稼働後1年経過してようやくお披露目になることもあります。そこで大きな不具合が起きると、新システム稼働後の繁忙にかまけて年次処理の不具合発生に備えることを失念し、大きなトラブルに見舞われるクライアントにも時折出会ってしまいます（前述のシステムは無事動きました^^;）。

たまにしか使わない機能こそ、意外に「ちゃんと不具合なく動いてほしい」というものも少なくありません。

しかし、テストケースはどうしても「月次」＞＞「年次」のように傾注することが多いので、新システム稼働を優先するあまり、テスト不足のまま「年次」処理やたまにしか実行しない「随時」処理が稼働後割と長い時間が経過したのちに、実行されて大きなトラブルに・・・という可能性は低くないのです。

これはシステムに限ったことでもありません。

人間が行う業務についても、「たまにしかやらない」仕事で且つ結構大事な業務、数をこなしてないので不測の事態に慣れておらず、実施局面においてトラブルが起きると対処法の準備もなく、どうやって収束していいのかオロオロ、、、という経験がないでしょうか。

「ブラッシュアップ」なんて便利な言葉がありますが（苦笑）、頻度の高い業務やシステム処理は、最初に不具合が起きてもなんだかんだ一生懸命対応して不具合解消して次回に臨み、次回あらたにまた不具合が起きてもまたその繰り返しで、対応する人間側も修練していき、1年もたたないうちに不具合は収束していきます。が、頻度が低いものはそうもいきません。

なので、私はシステム開発のご支援をする際には、「たまにしか使わない機能だからこそ」丁寧に作りテストをするように指南をさせていただきます。頻度の高い機能を軽視しているわけではありません。そういう機能は関係者も意識が高くなって自然に丁寧な作り方やテストをするようになるからです。人間心理として、頻度の低い機能や業務は、意識しないと優先順位が下がりがちになるのです。

私達のような客観目線をもった存在が、自然と優先順位が下がった機能の開発やテストを期待品質になるように警鐘を鳴らすのは、大事な使命だからです。

（例えば）年に一度しか実行されない機能・処理だからこそ、丁寧に作ってテストして準備をし、絶対に重大な不具合を起こさないように品質保証に努め、そして実行時には万全の体制で臨むべきなのです。

この意識は、繰り返しになりますが、人間の業務における優先順位管理と品質向上・維持の意識、そして継続的改善の心がけにおいても、まさに同じことだと思っています。