品質

品質を仕様から考えるのは間違いで、実用性から考えなければならない。ソフトウェアは実際に使われてこそ意味があり、仕様通りで実用性がなければ仕様バグである。

使用状況により品質の意味は異なる。少人数が使う先端的なソフトと、一般的に使うソフトでは品質の意味が違う。前者は高度な機能が重要で、後者は簡単に使える事が重要になる。使用状況を正確に理解する必要がある。

実用性を上げるには、ソフトウェアの実体を適切に管理する必要がある。ソース・コンパイル環境・テスト環境・入出力ファイル・実行ファイル環境・各種資料などである。管理が不十分だと継続的に開発を続けるのが難しくなる。

作業者が実用性を追求する必要がある。実用から離れ形だけの作業を行ってしまうと品質が悪化する。形だけ整えるため品質の悪化がわかりにくく、深刻な問題になりやすい。実用面の欠陥は技術的な欠陥より深刻である。技術的な欠陥なら回避できる場合があるが、実用面の欠陥は回避できない。

ソース履歴やドキュメントの自動管理ツールにより品質が向上する事はない。これらは管理を容易にするツールであり、実体管理が不適切なら意味がない。自動管理ツールの導入により実体管理に手を抜いてしまい、逆に品質が低下する可能性もある。

ソースの品質

十分な検討と整理の継続が情報処理の実務の根幹となる。品質を考える際もまずこの点に注意すべきだ。他の仕事と同様にPDCAと改善の連続が品質向上の中核となる。

ソースの品質を上げるのは簡単ではない。Code Complete上巻・下巻という有名な本があるが、まるで辞書のような重さだ。これを読む事で高品質のソースが書ける訳でもなく、実践の中で理解を進める必要がある。

基本となるのは、同一のデータや処理を一つにまとめる事と、データと処理を一体的に扱う事である。この２つはあらゆる局面でプログラム作成の基本となる。整理と処理削減が重要である。

同じ処理やデータを２度書くべきではない。ソースが冗長になり、内容がわかりにくく、修正もしにくくなる。少なくとも10行を超えるソースが同じ内容ならまとめるべきだ。これを続けるだけでも品質は高くなる。

コンパイル時の警告は除去すべきだ。何らかの問題があるから警告されるので可能な限り消すべきだ。難しくないはずなのだが、やっていない開発者は多い。

無駄な処理はできるだけ削るべきだ。ソースは必ず複雑になるので、無駄な処理はそれ自体が負担になる。過去に作った役に立たない処理は再利用などできない。一度整理して作り直した方が扱いやすい。

常にソースを修正して品質を改善する努力をすべきだ。最終的なテストの前であれば多少ソースを直しても大した手間にはならない。むしろ品質が上がった分だけあとの作業が楽になる。テスト完了後はバグが生まれるため一般にソース整形をすべきではないが、アジャイル開発の場合は自動テストを前提として完成後のソース整形（リファクタリング）を行う。

テストとソースの見直しが必要である。少なくとも正常系は動作確認を行い、その際にソースの不具合も同時に確認すべきだ。テスト時は処理の詳細よりも、全体の流れに気を配った方がいい。テストとソース整形を同時に行う事で効率よく高品質のソフトを作る事ができる。

また可読性向上や適切なモジュール分割も重要である。

問題解決

一般にソフトの問題はバグと呼ばれるが、バグは主に仕様に基づいてない誤動作を示すため、問題のごく一部でしかない。品質は実用性から見るべきであり、バグでなく実用性の判定が必要である。そう考えると問題の幅は非常に広く、解決方法も多岐にわたる。ソフトの修正が必要な場合もあれば、運用で回避できる場合もあり、利用方法が間違っている場合もある。これらすべての問題を解決しなければ実用化できない。

利用状況の理解が必須である。特にハードウェアやソフトウェア実行環境は重要になる。できる限り同じ実行環境でテストを行う必要がある。開発と並行して準備するべきもので、開発中でも可能な限り実際の利用に近づけるべきだ。そうでないと環境に依存した根本的問題に直面して大幅な修正が必要になる。

問題が発生した場合の最適な解決方法は、発生範囲を正確に絞り込む事である。原因となる特定の処理・データ・ファイルなどを絞り込めば、難解な問題でない限り原因が判明する。正確に原因がわからなくても、問題を絞り込む事で回避が容易になる。重要なのは絞り込みの正確さであり、見落としのない形で絞り込まなければならない。実行状況を正確に理解する必要がある。適当な判断で調べるだけでは原因は解らない。

使用方法とエラー処理

開発者はソフトの使用方法を固定的に考えてしまいがちだが、利用者の多くはソフトを最大限活用しようとする。そのため開発者が意図しないような使用方法になる場合も多い。

開発者は利用者よりも自分たちが有能だと考えがちだが、実際はそんな事はない。開発者の意図しない使用方法も、利用者が誤りでなく開発者が誤りと考えた方がいい。利用者が多いソフトの場合は良く理解せずに利用される事もあるが、利用者が限定されるソフトだと利用技量も向上するので、ソフトの能力を限界まで使おうとする。そのため付加的な機能の不足や、速度や容量の不足という問題が良く起こる。開発時にはこのような使い方について良く理解しておかなければならない。

付加的な機能の部分で非常に大きな問題になるのはエラー処理不足である。能力の低い開発者は固定の利用法のみを頭に入れて、他の利用方法は無視しようとする。最悪の場合は少し利用方法を変えると原因不明のエラーになり動作しなくなる。動作しないだけでなく原因も分からないので対処しようもない。これはソフトの品質が明確に悪いのだが、自分の利用方法から外れるため問題自体を受け付けない。開発者が多くなってくると、こういう問題は起こりやすいので注意しなければならない。

中核部分の品質向上

規模の大きなソフトウェア開発では、中核部分とそれ以外を明確に分けて考えなければならない。

中核部分には実現可能な最高レベルの品質が必要になる。最もレベルの高い技術者を割り当て、先行して丁寧に作らなければならない。この品質が悪いとソフトウェア全体の品質が悪化し、プロジェクトが破綻してしまう可能性もある。

中核部分の品質向上は地味で長期的な作業が必要になる。このような作業こそが重要なのであり、派手な周辺部分に凝っても意味はない。

周辺部分に関してはそこまでの品質は必要ない。先行して作った中核部分に基づき、それを利用する形にすればひどい品質悪化を避ける事ができる。

周辺部分の必要性が低ければ切り捨てるのも選択肢である。現在では様々なソフトがフリーウェアなどで利用可能であり、そちらを使うようにした方が高品質になる可能性もある。

最も避けなければならないのは、周辺部分を含めた大きな形で一体的に作り、人員や工数不足のため全体の品質が大きく下がる事である。ここから品質を向上させる事は難しい。もし切り出して再利用可能な部分があれば幸運だが、そうでなければ実用可能にする事はほぼ不可能である。