ここ数ヶ月、これまで作ってきたものに比べたら「圧倒的に低レベル」なシステムを作っている。もちろん、これはバグをたくさん作り込んでるとか、そういう話ではなくて、要求されるドキュメントのレベルであったり、テストのレベルであったり、運用のレベルが低い（≠悪い）という要件で作っているに過ぎないけど、まあ、このくらいでもいいんだーって思うのは金融ずっとやっている人間の性なのかな、とは思う。
別に要求のレベルが低いからといって低品質になるわけではないんだがやはり「早く柔軟に（安く、はダメよ）」に対応すればするほど品質に対する懸念は出てくるし、最低限守らなければならない仕様について、接続先（接続仕様を出してきている側）が書いてないことを想定していたりとかそういう事故も起きる。政府筋の案件ですらそういうレベルであるので早く安く柔軟にという案件は求められる仕組みが堅牢でなくてはならないものほどリスクが高くなるのは自明なことだ。
おおよそ、ここで現実の問題に対して発生するギャップは「リスクの見極め」に起因していることが多い。後から判明したある致命的なリスクに対応することがノックアウトファクターになり、サービスが提供できない、ということすらある（某リモートワークのシステムが諦めたのはこのへんじゃないかと思っている）。だから、最初から大きな要件（特にセキュリティ周り）があるPJTのスタートする際の要件の確認というのは非常に重要だし、それを発注者側がわかってないという最悪パターンに対して「なんとかしてやろう」と義侠心を持って立ち向かうのはおよそ事故を招くだけではあるよね。
ソフトウェアが低品質になっていく場合の大きな理由の一つは、これだ。根本的には発注者側の問題ではあるんだけれども、受注者に責任がないとは言えない、難しい話だ。絶対に考慮しなければいけない問題を考慮できてなかった場合に、それが受注者のプロフェッショナルとしてのレベルの問題なのか、時間の足りなさ（みんな大好きなきつい納期のことです）に起因しているのか、仮にどちらかが原因なのだとしたら、それは受注をする側の甘さに起因している問題と考えたほうが良い。できないものはできない（できるようにするにはこうするべきだ）、ということを言い続けることもエンジニアとしての矜持なのではないだろうか。
