はじめに
本記事はAdvent Calendar 2024、「過去の自分に教えたい、ソフトウェア品質の心得を投稿しよう by QualityForward」シリーズ1、16日目の記事です。
私は主に業務システムのSI事業に携わっていますので、SIer目線でソフトウェア品質の心得を振り返ります。
本記事に記述された見解は私個人の見解であり、所属する会社、組織の見解を必ずしも反映したものではありません。ご了承ください。
SI事業におけるQCDS
システムの保守開発や、新規システム構築プロジェクトを立ち上げる際にトレードオフ・スライダーで優先順位をつける指標として「QCDS」はよく使われる言葉です。
この言葉は以下の頭文字を並べたものです。
- Quality（品質）
- Cost（価格）
- Delivery（納期）
- Scope（スコープ）
最後の「S」は業種によってはSafe（安全性）だったりService（サービス、ユーザへのサポートなど）だったりします。
価格や、納期は具体的な金額や日付を設定することで、スコープもUMLを活用することで可視化できますが、品質は可視化するためには一手間が必要です。
例えば、単体テスト仕様書のテスト項目数がいくつで、バグは何件検出されたか、カバレッジの網羅率は何％か...などが挙げられます。
品質という言葉の定義
そもそも「品質」という言葉って、ずるいと思います。
たったこの一言の中に、どれだけの分類が存在するかというと「JIS X 25010」ではこれだけ定められています。
| 機能適合性 | 機能完全性 |
|---|---|
| 機能正確性 | |
| 機能適切性 | |
| 性能効率性 | 時間効率性 |
| 資源効率性 | |
| 容量満足性 | |
| 互換性 | 共存性 |
| 相互運用性 | |
| 使用性 | 適切度認識性 |
| 習得性 | |
| 運用操作性 | |
| ユーザエラー防止性 | |
| ユーザインタフェイス快美性 | |
| アクセシビリティ | |
| 信頼性 | 成熟性 |
| 可用性 | |
| 障害許容性（耐故障性） | |
| 回復性 | |
| セキュリティ | 機密性 |
| インテグリティ | |
| 否認防止性 | |
| 責任追跡性 | |
| 真正性 | |
| 保守性 | モジュール性 |
| 再利用性 | |
| 解析性 | |
| 修正性 | |
| 試験性 | |
| 移植性 | 適応性 |
| 設置性 | |
| 置換性 |
下記IPAの資料より抜粋、加工しています
https://www.ipa.go.jp/archive/files/000065866.pdf
その数、なんと31項目。わずか一文字の「Q」に詰め込むのおかしくないですか？
少なくとも、私はエンジニアになってから数年間は「品質」の中にこれだけの特性があることを認知していませんでした。
若手と呼ばれていた頃の自分
諸先輩にも「品質の高い成果物を」と言われ続けましたが、以下のようなものを「品質が高い」と誤認していました。
- 設計書であれば、「視認性が高く、必要に応じて補助資料を添付することで認識相違が生じないよう工夫し、レビューアが指摘を挙げられない」もの
- プログラムであれば、「Typoや的を射ていない命名がなく、単体テストでバグの検出数が少ない、レビューアが指摘を挙げられない」もの
- 設計書のロジックを、シンタックスシュガーなどを駆使したり、エレガントなワンライナーで表現したコード
思えば、レビューアをいかにして「ギャフン」と言わせるかの勝負をしていた気がします。
結果的にはそれによって、上記の機能適合性や性能効率性の意識には繋がり、一部の品質に対しては一定の効果を得ることができたと考えます。
しかし、少なくとも前述した「単体テスト仕様書のテスト項目数がいくつで、バグは何件検出されたか、カバレッジの網羅率」といった例で測れない品質に対しての意識は全くない、或いは極めて低い状態でした。
運命の出会い
いくつかのプロジェクトを経験し、とあるシステムリプレース案件にアサインされた時、私は運命的な出会いを経験します。
その相手は、継ぎ足しを繰り返して長文化し、スパゲティ化した、もはや誰も手が出せなくなっていた クソコードの山 巨大な泥団子 です。
この時私は初めて品質の概念に「保守性」と「移植性」があることを理解できました。
そして、その品質を無視することで多大な技術的負債が生じ、この負債は遠くない将来多大なコストとして重くのしかかってくることを学びました。
同時に、かつての私が書いていた以下のコードも、所詮はただのエゴでしかなかったことにも気付いたのです。
設計書のロジックを、シンタックスシュガーなどを駆使したり、エレガントなワンライナーで表現したコード
もちろんシンタックスシュガーを使うことやワンライナーが全て悪いわけではありません。
ここで言いたいことは、業務システムのような長期的に使われるシステムに対して、プログラミングコンテストで書くようなテクニカルで、しかもそのせいで可読性が犠牲になっているのに、コメントなどで補足もせず、どのような処理をしているのか難解になっているようなコードは可能な限り避けるべきだ、という点です。
運命の出会い Part2
さらに月日が経ち、後輩の指導を任せられるにあたって、自身の知識を言語化する必要が出てきました。この時ようやく、「自身の知識はほぼ全てが経験に依存するものであり、世間一般の知識と乖離しているのではないか」という懸念を抱いたのです。
そこで、まずは自身の初歩から見直そうと読んだのが「リーダブルコード」でした。
その内容は自身の暗黙知と一致することが多く、そして当然のことながら、私が誰かに説明するよりも遥かに優れた文章で細かに説明されていました。
この本と出会った結果、自身の知識と様々な書籍に記された知識のすり合わせや、新たな知識の習得を進めていく勉強法を取り入れるようになりました。
主体的に勉強することの大切さ
過去の私は、品質に対する理解をレビューアに委ねていました。レビューアからのフィードバックを私の中でナレッジ化していたため、品質の知識がある種「属人化」していたと言えます。
そしてその姿勢は受動的であり、主体的ではありませんでした。
品質に限らずですが、知識とは主体的に得ることで初めて深い理解に至るものと考えています。
そして、参画しているプロジェクトから得られる知見はごく僅かであり、汎用的に使える知識を身につけるためには不十分です。
では、ソフトウェアの品質を高めるために何が有効だったかと言えば、「技術に関わる書籍をとにかく読む」ことでした。
書籍は一つのテーマに対して深くフォーカスしているため、知識の深化を促せます。そして、世に出ている書籍は多く、それだけ多くのテーマを学ぶ機会が常にあり、中にはプロジェクトの成功譚や失敗談に言及されているものもあり、ある種それらプロジェクトの仮想体験さえできます。
無論「百聞は一見にしかず」という言葉の通り、実体験を伴わないと理解が及ばないものも多いので、ただ本を読むだけでなく、そこで得た知識の実践を積極的に行うことも大事です。
技術書籍は数多ありますが、そのほとんどはシステムの品質を高めるための知恵が書かれています。そして品質という一言で片付けられる項目の数だけ身につけるべき知恵があり、それを身につけるためには何よりも技術書を読み、実践することが大事だと考えています。
まとめ
過去の私に一言で伝えます。
「とにかく本を読め。」