近年、幾つかのプロジェクトを見ていて感じている事ですが、製品品質を確保する上で本質的に欠かせない内容に触れる事なく、何か別の（形式上の）作業に振り回されているうちに、肝心の品質保証が不十分になってしまうケースがあるようです。今回のプレゼンテーションでは、現代的な製品に欠かす事のできないソフトウェアの品質保証について、実際に現場で起きた事をざっくりデフォルメして説明させて頂きました。
先日のInterfaceの記事でも少し触れましたが、設計がどうして必要なのか、実装は何に対するものなのか、実装の正しさは何によって証明すべきものなのか、など、これらの関係について明確な思想を持っておく事が非常に重要です。
しかし、実際に現場で色々な作業成果物を見てみると、何とも残念な結果になっている事が少なくありません。それらがどのような背景で起きるのかについて触れるとともに、どのようなアプローチが実際に現場で有効であるのかについて、ヒントを示すような内容としました。
例えば、製品の見た目や大きさで設計対象物の大きさを判断しない事、など、少し考えてみれば当たり前の事ですが、混乱が繰り返し起こるような現場では有用な示唆になると思います。この「物事は見た目ほど単純ではない」というのは、色々な場面で使えます。
資料は、後日酔漢さんのウェブページで公開予定ですのでお楽しみに。
https://signalbottom.wordpress.com/
2015年12月16日追記：(リンク)
https://signalbottom.wordpress.com/2015/12/13/2015%E5%B9%B411%E6%9C%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%83%E3%83%97%E3%81%BE%E3%81%A8%E3%82%81/ に公開頂きました。
2015年12月29日追記：(要約)
製品の品質を担保するための活動は、その製品の企画構想、仕様、設計、実装、内部検証、外部検証、文章化、クロージングなど、製品開発の全てのフェーズに渡るのが通例である。しかしながら、実際の開発現場では、各フェーズの関連性を見い出せず、結果的に品質保証の視点が完成したシステムに対する外から見た挙動を評価する事に終始するようなケースもみられる。このような背景を踏まえた上で、本発表ではシステムの内部品質にフォーカスし、特定の指標を用いた設計や実装の品質保証について概略を述べる。
