こんにちは、こめすけです。
僕は仕事でもプライベートでもアプリケーションを作る機会があります。しかし、なかなか学生レベルを脱することが出来ずに作成している際に、どのように品質を高めるのか、ということまでなかなか落とし込めずにいました。そんな先日、ソフトウェア品質についての研修を受けたので、大切だと感じたことについての備忘録を書いておきます。
ソフトウェア品質に求められる2つのVとは
ソフトウェア製作は建築に似ている
ソフトウェア製作って、よく建築に例えられます。それは、まず設計書(図面)を書いて、それを元にソフトウェア(家)を作る流れがあるからなんですね。ただし、実際の作業は同じようにいかないのが現実です。そこにはソフトウェアならではの問題があります。それは、
1.建築のように成果物のイメージが固定されていない
2.お客さん自身がイメージを十分できていない
この2つが多くの原因を占めていると思います。
1.建築のように成果物のイメージが固定されていない
建築物であれば、ある程度のイメージがあると思います。屋根があって、ドアがあって、窓があって、と。稀に非常に芸術的な建築物もありますが、多くの建物は概ね僕たちが持っているイメージと相違ないです。そのような成果物であれば、作業している最中にもし間違いがあったとしても気づきやすいです。
だって、もし家にドアがなかったら途中でおかしい!って気づきますよね?
反面、ソフトウェアには決まったイメージがない場合が多いです。もちろん、見た目やデータベースの構造についてはある程度の"型"があります。しかし、細かい設定などについては決まっていないことが多いですよね。また、技術の進歩も早いので、どんどん新しいシステムが追加されます。そうすると、なかなか間違っていることに気づくことが難しいのです。
2.お客さん自身がイメージを十分できていない
もう一つの問題として、お客さんもしっかりとしたイメージを持てていないことも問題として挙げられます。
こうした問題を回避するために、「プロトタイプモデル」という試作品を作る手法や「スパイラルモデル」という微調整しながら開発する手法もありますが、やはりいかに早くお客さんのイメージを正確に設計書に落とし込むかが重要です。
このように、ソフトウェア製作では様々な問題が発生します。で結局、ソフトウェアを作った時に、何を見れば正しく問題なく作れていることが確かめられるのか、という話になります。
2つのVで成果物の妥当性をチェック
そのために、2つの視点から成果物をチェックするようです。
検証(Verification)と妥当性確認(Validation)です。
検証(Verification)
それぞれの開発工程の成果物が、正しいプロセスを踏んで作成されたか、ということ。
要は入力=出力になっているか?
ということです。
昔はウォーターフォールモデルが主流でしたが、今はアジャイル開発が主流となる流れがあり、難しくなりそうですが、、、。
これは開発者目線での正しいソフトウェアが作れているか、ということになります。
妥当性検証(Validation)
成果物が、使用者のニーズや意図された利用方法と一致するか、ということ。
つまりお客の欲しいものが作れているか、ですね。
こちらはお客さん目線での正しいソフトウェアが作れているか、ということになります。もちろん、これは正しく作れていることを検証するためのものなのですが、この何と比べて正しいか、が重要です。
つまり、あくまでも文章で明文化されている要求と一致していることが大切なのです。これは、お客さんの頭の中で考えているものとの一致をみるものではありません。なので、ちゃんと書類に沿って作りました、という担保を示すことにもつながります。自分たちを守ることにも繋がるんですよね。
以上が、ソフトウェアを作成した際にチェックするべき2つのVなのですが、言われなくてもわかるよ!!というのが本音ですよね、、、。
でもなぜかできていない!
原因は人不足だったり、予算不足だったり、上の方針が変わったりといろいろあると思うのですが。
結局はこうしたものはツールでしかなくて、正しく使いましょうってことです。
それが難しいですが。
僕はまだその方法を見つけれていないので、また日々の業務で学びつつ、ブログでアウトプットしつつ見つけれたらいいなぁ、、、。
所感
お客さんの望むシステムを実現するためにも、自分達を守るためにも、検証するという作業は非常に重要と感じた。
あ、先日、イグジズトアーカイヴてゲームやったんですが、バグが多すぎてまさにこれができていない!と思いました!!笑
いじょうっ!