bon now

2月も終わりそうな今、我が社ではなかなかの激動の年を迎えているのではないだろうかと感じている。 例えばどういう風なことかといえば、大変幸運なことに利益も出していて社内景気もそれなりに良いため、 全体的に社内が明るい雰囲気になっており、「新しいこと始めようぜ」とか「予算を成長に使おう」という良い傾向がある感じだ。 これはなかなか、不採算事業を続けている場合だと見られない好意的なムードである。
ほんで、私の責務としては、チームビルディングあたりから開発(作業)フローの見直し、 および他部署連携などの効率化を図り、システム品質と生産性向上を狙う的なことをやることになっている。 2年前、僕がまだSIerだった頃に感じていた閉塞感ややりたかったことが、ここにきて一気に開放され役割としてそれをどうこうできる時期が、 ついに来たということである。2年が長いか短いかはともかく、組織まるごと仕事の仕組みを変革できるというのは、 それなりに規模の大きい会社ではできないことだし、やりがいは大変感じている。なので、実は仕事がちょっと楽しい。
(ただし、それなりの責任と結果を出さなければならない重圧も感じてはいるので、疲労もしてる……)

さて、そんなことをやることになったわけで、色々と今の仕組みを見直してどうすればよいかってのをまとめている感じなんだけど、 僕らの持つ課題の1つに「システム品質を保証する術が圧倒的に足りない」というものがある。

以前の職場では、開発した成果物に対して、それが正しい品質であるかどうかを示すための成果物も必ず一緒に提出しなければならなかった。 例えば「テスト計画書」だったり「バグ指標(信頼度成長曲線やらバグ種別やら)」だったり「品質報告書」というものだ。 これらはそれぞれ 単体・結合・総合テストの3段階で必ず作成・品質保証を担保する部署と第三者を含めたレビューおよび納品が必須なわけで、 これだけでもそれなりの作業である。これに加えテストチェックリスト(CL)やら仕様変更仕様書とかの提出も必要になる。 で、これらには「ステップ数」というプログラムの行数をベースとして、品質基準というものが設けられている。 各PJではこの基準を守るように義務付けられ、そこから逸脱したテスト結果については、いろいろな 言い訳 定性評価を書かなければならない。

巷ではこのステップ数ベースの評価を全てのプロジェクトで一意に守るべきという話もあるが、 僕のいた会社でもまあそんなもんだった。
ただし、誤解の無いよう言っておくが、全てのプロジェクトがそうであったわけではなく、ちゃんと自分らのプロジェクトの特性を踏まえて、 FP法での特性付やプロジェクト特有のテストガイドラインを作成し、そこから相対評価を設けてテスト指標を算出している人たちもちゃんといるし、 それを出すためのガイドラインもちゃんとある。例えば自動生成されるコードについては除外する記述もあるし、他製品連携バッチなら比率を上げるとかそういうルールも策定されていた。
とはいえ、大抵のプロジェクトでは下記のブログで言及されているとおりであった(笑)

参考：【悲報】客先常駐システム開発で今もステップ数によるバグ検出数基準が使用されていることが判明 - 残業ゼロのIT企業AXIA社長ブログ

ここで何が問題かというと、「品質指標を作る人」がみているシステムの品質と、「実際に製品を開発している人」のそれ、 または「開発者の作った報告書をレビューする品質保証部の人」のそれぞれで、想定している「品質保証」の形が異なっていることである。

本問題についてIT業界に身をおいている方としては、以下の画像をみていただくとすぐに想像できるのではないだろうか。

- 引用元： Requirements Management - Model-Based Design

これは、「顧客の要望するものは、大抵想定される実装および成果物とは違うし、そもそも本当に欲しかったものとも異なる」というものだ。
そしてこれは狭いチーム内でも互いの意思疎通がうまく言っておらず共通認識のない状態での会話や調整によっても生まれる問題である。

この問題を解決するには、それぞれの役割や部署によって共通認識を持たせることが大切なのは自明である。 誰も野菜を切って下さいと言われて「オノ」を持ち出す人がいないように、品質とはXXだと共通の言葉と姿勢で評価できるようにすべきだ。
先の例のように特定の標準ガイドラインを作る必要もあるだろうし、それを社内で啓蒙する必要もある。 その方法としては教育研修や品質保証のプロジェクトへの介入などが挙げられる。 ただし、これは大企業の場合である。 小さな企業の場合そんなことせずともプロジェクト毎に例えばスクラムであればスプリントの単位で振り返って評価すればいいわけだし、 アジャイルであれば常に会話しながら方針について議論すればよい。まずはやってみることが大切なのだ。 ただ、現状品質について体系的にまとまっておらず、誰かの頭の中だったり何かしらの作業フローに埋もれていたりするのであれば、 それを一旦整理して資料化していくことから始まるのだが……。 そして、この場合は多くのエンジニアが「これは自分らのタスクではない」と感じて興味を示さないから厄介である。 これについては、エンジニアからリーダーを選定し、運用部やサポート部などの面々を集めた状態で、 品質保証部が主導してガイドラインを策定していく必要があるだろう。
品質保証部は自分たちがシステムの品質に対して是非を問う最終防衛ラインであることを自覚して、 より効果的で画一的な要素を盛り込んでそれを啓蒙していく意識が重要なのだ。 小さい会社ではその辺が欠けていると思う(スピード重視で過去を振り返らないパターンが多いから)

まずは小さな一歩だが、過去の不具合事例や品質上の問題点を洗い出して傾向分析し、 自分らのシステム品質について定量的な評価しないといけないだろう。過去(過程)も知らずに現在の状況を知ることはできない。 その時間が今回ようやく確保できるであろうから、その辺についても僕なりに口出ししていこうと思っている。 そして願わくは品質保証部の権限が開発部隊から独立し、対等かつ絶対的であるよう変えていきたい。 そうやって、品質保証部の権限が強くなって最終防衛ラインとなれば、 当部署は真剣に品質について自ずと考えるようになるだろうし、 常にPDCAのサイクルが回って様々な改善・要望・提案が挙がって、他部署を巻き込んでシステム品質の共通認識が生まれてくるはずだと僕は考えている。

でもまぁ今は自分の職務を全うするほうを優先する。