オルタナティブ・ブログ > 一般システムエンジニアの刻苦勉励 >

身の周りのおもしろおかしい事を探す日々。ITを中心に。

システムの開発者と品質管理者とのすれ違い

»

小俣さんのエントリで悩ましい問題が提起されています。

ミスに対して厳しい制裁ばかり考えても逆効果では?:プログラマー社長のブログ:ITmedia オルタナティブ・ブログ
http://blogs.itmedia.co.jp/komata/2012/07/post-4a52.html

私は品質というのは前か中か後で作りこまれると考えています。このいずれかというわけではなく、このどこかでそれぞれに品質を高めるアプローチが全然違ってきます。

例えばワンオフで巨大でミッションクリティカルなシステムを作ろうとしたときには、動かしてみたらどうにもなりませんでしたということは許されません。ですので事前に可能な限りの検証を進めた上で、その土台の上にシステムを作っていくというアプローチとなります。これは前>中>後の順番で力の入れ方が弱くなっていきます。事前検証がとても大変で、その次には事前の設計通りに作られているかの単体レベルでの確認に注力し、最後には総合的なテストをする流れです。(システムが巨大過ぎてあらゆるシナリオを網羅するテストが現実的に不可能)

一方でワンオフものでも前人未到なものをパイロット的に開発するのであれば、前<中<後の順番で力を強く入れていくことになるでしょう。事前の検証は「いけるかどうか」を見極めるようなレベルで試行錯誤をし、いけそうと見れば部品を試作してみて、最後に部品をすりあわせた状態で動かすことになるでしょう。この場合、前と中の工程で「なるほど」というような知見が増えていくことになりますので、後の工程では最初は思いもよらなかったような「こうなったら危ないのでは」というアイデアがどんどん湧いてきて当初よりも強力なテストをする能力が開発陣に備わっていることが期待されます。

それでは中で力を入れるものは?というとワンオフではないもので、例えばシステムの基盤構築といった作業が挙げられます。だいたい基盤構築というのはまったく新しい製品同士を同時に大量に組み合わせると収集がつかない未知の不具合に繋がることが少なく無いですので、多くの実績ある構成に少し未知の要素が混ざるくらいの事例が多いでしょう。そのような中では事前の検証は既に実績のある設計書がベースとなるので新たな考慮点は局所的になります。そして事前の設計書の通りに組まれているかという中の作業チェックが非常に重要となります。最後には、期待通りに組まれていればこのように動くはず、というテストをして終わることになります。この最後の部分で強く優秀なテストシナリオやツールを持っているかどうかで品質も効率も大きく左右されますね。

さて前置きが長くなってしまったのですが、前で作るべき品質を後で作れとか、後で確保できるはずの品質を前や中でみっちり見ろと言われるとこれは技術者として非常にカチンと来る問題です。もしその部分を外していないならば、開発者に「制裁」と感じさせてしまうことが問題です。この品質はこのように確保すべきであろうということを技術者同士の会話として説明できないのであれば、それは品質を管理する側の力不足であると思います。

本当はこのような会話はもっとあっても良いと思うのですが、世の中のシステム開発の品質管理というと上のような特性はほとんど無視して「何千行(何クラス)あたりバグ何件以下とする(またはレビュー時に何件発見する)」ですとか、更にそれが前年度比10%削減ですとか、なんでその数字に落ち着いたの?ということを品質管理者側が技術者に対して説明できないような状況が少なくないと思います。

あまり長くなると誰も読まなくなるので細かいことは省略しますが、品質を管理する側が技術者に対して十分な説明力を果たすには過去の実績を材料とするのが良いと思います。「このような性質の開発でこのようなパターンにはまっていたこの案件は担当者が3週間家に帰れませんでしたよ!」というデータで開発者を脅し、なおかつその脅しに従った挙句にはそこそこの品質のものが出てきたということがいくつか積み重なれば互いの信頼関係も深まるでしょう。そのためには性格な開発記録を取る必要があるのですが、開発者はバグを隠したがったり、記録をすっ飛ばしてコードをどんどん書き換えてしまったりしやすいですので、記録というのも大きな課題です。ただしこの部分は非常に良い開発支援ツールがたくさんありますので、品質管理者はまず開発者をチマチマしておもしろくない記録作業から開放することに尽力し、開発者が油断してどんどんデータを積み上げた後に言い逃れできない証拠を集めて深々と刺すというのが私が推奨するアプローチです。

もっとも、実物を扱うような製造業での品質管理者と製品設計者、場合によっては生産工程の設計者、製品開発者との戦いは非常に凄まじいそうで、システム開発の世界もまだまだ学ぶ余地が大きいように思っています。

Comment(2)