みなさんこんにちは。
エコモットの板橋です。
現在は3月末という事で、3月末納品に向けて燃えている全力疾走中の所もあるのではないでしょうか。
先日公開した「プロジェクトのゴール設定」の話、「察する文化はシステム開発と相性が悪い」話と、少し関連してくる話になります。
今回はソフトウェア業界で良く飛び交う品質について掘り下げて考えていきたいと思います。
※今回ここに記載した内容は、執筆者である私の私見になります。
この記事を読みながら、一緒に皆さんも考えて頂けると嬉しいです。
品質という漠然とした概念の衝撃
この記事を読んでいるあなたは、日常業務の中で「品質」という言葉を使った事はありますか？
私はもちろんありますよ。えぇ。
今月書いた他の記事でも触れていますし、日常でも口酸っぱくメンバーに言っています。
「テスト工程を強化してバグ検出率をあげましょう」とか、「バグが少なくて品質が気になる、、、」とか。
更に、言葉だけではなく、「品質評価報告」なる文書まで作っています。
ですが、メンバーとの会話の中で改めて認識しました。
”品質って少し漠然としていないか？”
皆さんはどう思いますか？
「品質を高めましょう」とか「品質評価」なんて偉そうなことを仕事でやっておきながら、よく考えるとそれが漠然とした概念である事に今更ながら気付いてしまった事に衝撃を受け、衝動的にこの記事を書いています。
現在使っている「品質」が指すものは何か
システム開発を日常の業務としている場合、主に「品質」という言葉は以下の様な意味合いで使っていることが多いのではないでしょうか。
- テスト工程での不具合の多さからくる”品質”への懸念
- リリース後に発生する問合せや不具合申告の多さからくる”サービス品質”への懸念
- ソースコードの可読性や修正のしやすさからくる”ソースコード品質”
ぱっと思いつくものを挙げてみました。
この記事を読んでいる皆さんも、概ね同じような感覚だと思います。
あまり良いイメージがないというか、少なからず皆さんも大変な思いをした過去があるのではないでしょうか、、、
よくわからない違和感を覚えませんか？
品質が指し示すものとして、「システムの不具合」や「美しいソースコード」を指しているのだろう、、、という話ですが、少し違和感を感じませんか？
システム開発では色々な成果物を作成し、それらを積み上げた結果、出来上がるものなのです。
その過程をすっ飛ばして、いきなりソースコードや動くシステムの品質を語ることに私は少なからず違和感を覚えるのです。
想像してみてください。
雑に作った要件定義や、メモ書きの様な設計書を元に開発されたシステムの品質が良いと思いますか？
なかなか難しい事ですよね。
一人で全て担当できる程度の小規模なものだと、それも可能かもしれませんが、基本的にシステム開発は複数のメンバーが協力して進めるチーム作業ですから、他のメンバーに対して、「お客様が求めているものは何か」「どの様に要求を実現するのか」といった情報を他のメンバーに伝えて、それが実現できるプログラムを作ってもらう必要があります。
そう考えると、開発の過程で作成される成果物に対しても「品質という概念」が存在すると考えるのが妥当です。
掘り下げて考える
では、ドキュメントの「品質」とはどういう事でしょうか。
非常に重要な点になるので、ポイントを整理しましょう。
- 成果物にはそれぞれ期待する役割がある（無駄なものは作りません）
- ドキュメント（文章）には想定する読者がいる（個人メモでも自分が読者ですよね）
- ソースコードを含む文書や媒体は、読者に対する正確な情報伝達が期待されている
- 完成した「動くシステム」はお客様の要求を満たす役割が期待されている
この点について、皆さんはどのように考えますか？
いろんな観点や意見があると思います。
では、上記の「役割」を踏まえた時に、「不具合が多い = システムの品質が悪い」という考えのロジックを紐解いてみましょう。
本番リリース後にお客様が運用を始めた際、不具合が出ることがあります。
この状況を整理すると、以下の様な状況です
- ある業務を遂行するためにシステムを操作した
- システムの処理結果がお客様の期待と異なるものだった
- システムで業務の遂行ができない状況になった
- 不具合として開発先に問い合わせる
このような状況になりますね。
つまり、システムに期待していた業務が遂行できない状況が起きたという事です。
役割の観点で考えると、期待した役割を果たせない状況という事です。
つまり「品質が悪い」とは、具体的に言うと、
「期待した役割が果たせない状況」
を指しているという事が見えてくると思います。
システム開発の成果物に当てはめて考えてみる
システム開発の過程では、色々な成果物が作成され、それぞれで期待される役割があるという話をしました。では、各成果物の品質とはどのような観点になるか考えてみたいと思います。
※開発プロジェクトの成果物は多様なものがあるので、ここではその一例として代表的な物のみ挙げることにします。
成果物には文章が多くありますので、文章の役割に関する共通の原則を出してみます。
①文章の大原則
- 読者が記載内容を理解できること
- 読者が理解した結果、情報の伝達という目的が達成できること
- 記載した側の意図通り正しく情報伝達できる（齟齬が生まれない）こと
- 継続的メンテナンス（改訂）が行われること
文書には必ず想定される読者がいるので、ざっくりと定義してみます。
②読者になり得る立場
- 顧客（発注者）
- 営業（弊社）
- 開発（弊社）
- 利用者（システムを利用する人）
③成果物ごとの役割を考えてみます
| 成果物 | 読者/利用者 | 期待する役割 |
|---|---|---|
| 議事録 | 顧客、営業、開発 | 議事の進行、発言、決定事項を記録。後日、確認事項があるときに読み返し、状況を把握出来ること |
| 要件定義書 | 顧客、営業、開発 | システムへの要求事項を整理し、機能、性能、システム構成などシステムを構成する枠組みについて明記したもの |
| 業務フロー | 顧客、（営業）、開発 | システム化の対象範囲について作業の流れを図に示し、作業の流れとシステムとのかかわりがどうなるか示したもの |
| 外部設計書 | 顧客、（営業）、開発 | システムの外見上の振る舞い（UIの挙動）について、要求事項を満たす具体的な仕様について記載したもの |
| 内部設計書 | 開発 | 要求事項を満たすシステム内部（処理アルゴリズム）の具体的な仕様について記載したもの |
| ソースコード | 開発 | 要求を満たす期待通りの正しい処理を実現する仕組み・アルゴリズムが漏れなく実装され、メンテナンスが容易に行えること |
| テスト項目 | （顧客）、開発 | 顧客の要求を実現する正しい動きの検証ができること 正しくない挙動を示す場合は、不具合として検出できること |
これらの考え方をまとめると以下のようになります。
- 要件定義：顧客がシステムに求める要求事項、機能、性能、システム構成について、読者が齟齬なく正確に理解可能で、情報の更新が継続的にできること
- 内部設計書：顧客の要求事項を実現する為の具体的なアルゴリズムを齟齬なく正確に理解でき、漏れなくプログラム実装することができること
- テスト項目：テスト条件、手順、確認観点が齟齬なく理解・実行でき、開発中のシステムに含まれる不具合を検出する事ができること
他にも成果物はたくさんありますが、基本的に、それぞれに期待する役割があり、その役割を果たすことができるかという観点で品質の概念をとらえていく事ができるはずです。
各工程での各種レビューでもそういった観点があると、より良いものが作れるようになるのではないでしょうか。
漠然とした「品質」という考えが、掘り下げて細分化することでかなり具体的な「品質」の考え方になったと思いませんか？
まとめ
このように、私たちが日常的に使っている「品質」という言葉が、実は漠然とした概念であり、掘り下げて考えることによって品質が指し示すものが何か具体的になったと思います。
皆さんはどのように考えますか？
ここまで記載した内容について、かなり理想的な話をしていますが、「理想の未来から現在の方向へ逆算し、プロジェクトの制約に応じたカスタマイズを加え適用する」のが良いと以前のブログで書きましたね。
そういう発想です。笑
「期待する役割を果たせない状態」が「品質の低い状態」
「品質の低い状態」の程度がどれくらいなのか？
この点が品質を考えていくうえで非常に重要で本質的なものであると私は考えています。
本質をとらえたうえで、品質向上のために有効な対策は何か、その対策は実行できるのか（コストや期間など）検討することによって、有効性の高い施策が取れるようになるのではないでしょうか。
もちろん、品質とコスト（期間）はトレードオフの関係にありますから、すべてを理想通りに進めるのは容易ではありません。
だからこそ、「何をどこまでやるのか」「何を最優先にするのか」。
これらをお客様としっかり合意し、納得感のある取捨選択を行うこと。
そういった取り組みを含めたものが、「品質」の本質ではないかと思いました。
私たちと一緒にモノづくりをしていく仲間を募集しています。 弊社に少しでも興味のある方は、ぜひ下記の採用ページをご覧ください。
