今回は、ソフトウェア品質に関する話題です。ですが、この問題は《どの世界にも起こりえる問題》ですので、ＩＴ業界以外の人も最後までお付き合いください。
私は、長年、ソフトウェアの品質に携わってきましたが、恥ずかしながらこれまで「オブジェクト指向」についてあまり詳しく考えてきませんでした。Javaについても「COBOLやＣのようなプログラミング言語のひとつ」としか考えていなかったのです。ところが最近、初めてオブジェクト指向によるプログラミングを経験してみて、事の重大さに気がつきました。今回は、その経験をもとに、オブジェクト指向プログラミングについての私の理解と、オブジェクト指向が抱える品質上の問題を書きたいと思います。
目次
・品質管理の変遷
・プログラミングの変遷
・オブジェクト指向の超概略
・オブジェクト指向の品質問題１（管理手法）
・オブジェクト指向の品質問題２（人材・育成）
・最後に
–
品質管理の変遷
昔、少量生産の頃は、出荷する製品を１つ１つ検査して不良品を取り除き、合格品だけを出荷していました。やがて大量生産の時代になって全ての製品を検査することが難しくなると、サンプリング検査を研究することで対応してきました。ところが、ニーズの多様化とそれに伴う製品の多様化により、もはや物の検査だけでは製品の品質を保証することが難しくなってきました。
そして、「物の確認だけでは品質を保証出来ない」という考えが生まれ、それと同時に「品質を保証するためには、作り方を確認する必要がある」という考えが出てきました。これが “品質保証” です。つまり、『いつも同じやり方で作っていれば、いつも品質の良い製品が出来るはずだ』という考え方です。そして、「いつもと同じやり方か？」というのが品質管理（品質マネジメント）の１つの柱になりました。それがプロセス品質でありISO9001です。（もう一つの柱は「そのやり方でいいのか？」、つまりプロセス改善です）
”やり方” とは、過去の経験を元に帰納的思考によって考えたものです。つまり、「こうしたら成功した」という経験を集めて、「こうすると成功する」という法則を導いたのです。この法則を集めたものが、手順書や手法です。世の中にある数多くの手法・方法論・規格などは、多くの先人達の経験（成功や失敗）を元に作られているのです。
–
プログラミングの変遷
コンピューターが生まれた頃、プログラムは機械語で作っていました。機械語とは、コンピューターが理解できるデータで、[0] と [1] の集まりです。人がちょっと見ただけでは全く意味が分かりません。ですが、昔の人はそれでプログラムを書いていました。
やがて、人が理解できるプログラミング言語が作られました。例えば「B = A」や「MOVE A TO B」という記述なら人間が読むことができますね。これによって、プログラマーは機械語という非常に面倒な世界から解放されました。
この時のプログラムは、データ定義部と手続き部から出来ていました。データ定義とは、プログラムが扱うデータを入れておく “箱” を用意することで、この箱を介して値を処理（転記や演算など）します。この “処理” を記述するのが手続き部です。先の「B = A」の場合、”Ａ” と “Ｂ” が箱で、「B = A」は『箱Aの内容を箱Bに転記する』という処理です。このようなやり方を《手続き型プログラミング》と言います。
やがて、プログラムが大規模になると、データ定義や処理がどこに書かれているのか分かりにくくなり、保守や改造が大変になりました。データ定義部と手続き部の距離が大きくなったのと、プログラマーが無秩序にデータ定義や手続きを記述していたからです。そこで登場したのが “オブジェクト指向” です。
–
オブジェクト指向の超概略
オブジェクト指向とは、現実世界のモノやコトに注目してプログラミングすることです。手続き型プログラミングがデータや手続きといったコンピューター内の世界に注目していたのに対して、オブジェクト指向では、現実世界に注目してプログラミングします。その注目の対象が “オブジェクト” です。オブジェクト毎に、データ定義や手続きを記述するのです。これにより、プログラムの構造が格段に分かりやすくなりました。
オブジェクト指向プログラミングでは、”抽象化” という思考作業が必要です。これは、同じ性質のものを一つのオブジェクトと見なすことです。例えば、缶飲料の自動販売機のプログラムを作る場合、[コーヒー] [紅茶] [日本茶] はすべて “ドリンク” というオブジェクトと考えることができます。そして、[コーヒー] [紅茶] [日本茶] のそれぞれのプログラムを記述するのではなく、”ドリンク” に関するデータ（プロパティ）や手続き（メソッド）を記述します。
※ もっと詳しく知りたい方は、サイトや書籍で勉強してください。とてもたくさんあります。
ここではオブジェクト指向についてこれ以上詳しく説明しませんが、次の２つの特徴だけは覚えておいてください。これが、「ソフトウェア品質の闇」の原因です。
特徴１：これまでの手続き型プログラミングにはなかった新しい概念《抽象化》が登場した。
特徴２：オブジェクト指向に対応したプログラミング言語であっても、オブジェクトを使わずにプログラミングすることができる。
せっかくオブジェクトという便利な仕組みがあるのに、それを有効に使わずに（使えないまま）プログラムを作ることが出来るのです。この問題は実際によく聞きます。例えるなら、せっかくピストルという強力な武器があるのに、銃身を握ってこん棒として戦っているようなものです。
–
オブジェクト指向の品質問題１（管理手法）
オブジェクト指向プログラミングの適切度を示す品質指標が分からない。
オブジェクト指向を用いる最大のメリットは、プログラムの可読性と高い保守性です。しかし、保守性の良し悪しを測る指標が分からない（つまり、何を計測すればよいか分からない）のです。
オブジェクトを使わなくてもプログラムは動きます。したがって、「動かない」や「動作異常」などの数をカウントすれば、手続き型プログラミングと同じく信頼性や機能性の品質は把握することはできます。しかし、それではオブジェクト指向プログラミング特有の品質である〈保守性〉の良し悪しの判断にはなりません。
オブジェクト指向プログラミング特有の品質管理について解説する書籍やサイトは、私が知る限りありません。あるのはオブジェクト指向の説明とプログラミングの方法だけで、「オブジェクト指向プログラミングの適切性をどう判断するか、どう管理するのか」という問いに対する答えやヒントはどこにも見当たりません。ソフトウェア品質研究会やシンポジウムでも、まったく問題視されていません。ソフトウェア品質に関する知識体系であるSQuBOK（※）にも記述されていません。
オブジェクト指向は、まだまだ未成熟な技術なのかも知れません。品質管理に関する理論や手法が生み出されるほどの多くの経験や知見が、まだ蓄積されていないのかも知れません。
※ SQuBOK：（財）日本科学技術連盟を中心に、日本国内のソフトウェア品質の実務担当者がまとめた、ソフトウェア品質に関する知識体系ガイドです。ソフトウェア品質担当者の育成に役立つように、様々な知見が体系的に記載されています。
ほとんどの会社は、オブジェクト指向プログラミングの適切性（例えば、クラス設定の良し悪しや、保守性の良し悪し）を示す品質情報を集めていないのではないかと思います。それだけではなく、品質管理に必要なメトリクス（計測項目）に及ぼすオブジェクト指向の影響を意識していないのではないかと危惧します。
例えば、「バグ作り込み原因」です。ソフトウェア開発においてバグ（ミス）を継続的に減らしていくためには、バグの作り込み原因を除去していくことが必要です。そのためには、現在どのような原因でバグが多く作り込まれているのか把握する必要があります。手続き型プログラミングの場合、バグを作り込む原因は大きく「考えていなかった」「間違って考えた」「手が滑った」の３つに分けられます。では、オブジェクト指向プログラミングの場合はどうでしょうか？ 抽象化においてミスを作り込む際の行動とはどのようなものでしょうか？
また、オブジェクト指向は工程管理や見積りにも大きく関わります。オブジェクト指向プログラミングは、手続き型プログラミングに比べて設計に多くの手間がかかります。抽象化とその後のオブジェクト定義に時間がかかるからです。つまり、「オブジェクト指向で作る」のか「オブジェクトなしで作る」のかによって、工程の比率や作業量が大きく違ってきます。同じプログラミング言語を使っていても、オブジェクト指向で作った場合、オブジェクトなしで作るのに比べて作業量が大きくなります。知らない人が見れば生産性が低下したように見えます。ですので、オブジェクト指向で作る際には、それによる効果を明確に示す（品質指標を明確にする）必要があるのです。
–
オブジェクト指向の品質問題２（人材・育成）
品質管理に携わっている人の中で、オブジェクト指向を理解している人は少ない。
（と思われる）
理由１：オブジェクト指向を理解するのはとても難しい。そして、どんなに頑張っても理解できない人がいる。
努力の問題ではありません。《抽象化》を司る脳の違いです。空間認知能力が小さい人（方向音痴）や、論理的に考えられない人（数学が苦手な人）がいるように、抽象化が苦手な人がいるのです。一般的にプログラマーを目指す人は、情報系や理数系の学校で学び、就職試験で論理的思考の適性を調べられますが、これからはそれに加えて《抽象化》の適性も問題になるでしょう。
さらに、職場においてオブジェクト指向プログラミングをどうやって指導しているのか気になります。オブジェクト指向についてのサイトを見ると、詳しい人はかなり詳しいです。しかし、企業において特定の個人に頼るわけにはいきません。従業員全体の底上げが必要です。JavaやC++などのプログラミング言語の教育はそれなりに出来るかも知れませんが、実習ではかなり苦労しているのではないかと推測します。抽象化に対する適性の個人差が大きいからです。個人的には、オブジェクト指向プログラミングの教育は、集合教育よりも徒弟制度によるOJTの方が向いているような気がします。
理由２：プログラマーのキャリアマップ
歳を取るとプログラムを作ることが徐々に難しくなってきます。記憶力、思考力、集中力、探求心などが低下してくるからです。そこで、プログラマーはある時期から他のキャリアに進むのが普通です。一般的にはマネジメントへの道です。例えば、進捗のマネジメント、原価のマネジメント、人材のマネジメント、そして品質のマネジメントです。実際、品質管理に従事している人達は、プログラマーとしての経験を積んできた人がほとんどでしょう。もっと言えば、プログラマーとしての限界に達した人達と言ってもよいかも知れません。その人たちが、今さらオブジェクト指向というまったく新しい技術を勉強をするのはかなり難しいと言わざるを得ません。書籍を読めば知識は得られるかも知れませんが、実際にプログラムを組んでみないとオブジェクト指向の真価は分からないと思います。
–
最後に
以上述べてきたように、現在のＩＴ業界は “オブジェクト指向” という「闇」を抱えています。オブジェクト指向プログラミングの品質（※）は、未だに “人依存” です。
※ 信頼性や機能性のことではなく、オブジェクト指向の本来の目的である [保守性] のこと。
オブジェクト指向特有の品質指標が確立されていないまま、オブジェクト指向がどんなものか分かっていない人が管理している、と言ってもいい状況です。
もしかすると、オブジェクト指向プログラミングを、手続き型プログラミングの延長として管理しているのではないかと危惧しています。最初に述べた例のように、ピストルを棍棒として扱っているのと同じことをしているのではないでしょうか？ オブジェクト指向プログラミングの効果を最大限生かすために、そのメリットである保守性を〈どう計測するか〉、そして〈どう指導するか〉を真剣に研究する必要がある考えます。
一刻も早く、オブジェクト指向に適応した品質管理の研究が進むことを願っています。
コメント