ソフトウェアの品質というと国際基準や規約というものがまずあるのだけれども、そういった観点とは別に「工業製品としての品質」という考え方もあるのではないかと思っている。美しいコードは品質が高いと言われているけれども、それは「芸術品」を目指したものではないか。われわれが作っているものは「芸術品」なのか「工業製品」なのかということを考えるべきではないだろうか。
そのソフトウェアに「品質過剰」は無いか？
知り合いのプロジェクトで「複数のシステムが使う共通検索機能」があって、スケジュールの関係もありバラバラに(共通化せず)構築してしまった話を最近聞いた。そのプロジェクトでは開発フェーズの終盤で顧客からクレームがあり、該当の機能は苦労して再度共通機能として作りなおしたそうだ。比較的よく聞くたぐいの話だけれども、いくつかの点で少しひっかかった。
- 内部実装がバラバラだったとしても、外見上の機能性がまったく一緒だったら「作りなおす」必要は無かったのではないだろうか？
- 見かけ上「同一であるべき」ものがそうでなかったから顧客クレームとなったのであって、違いが無ければクレームは出にくかったろう
- クレームを受けた後に作り直す際に、「共通化する」ことは必須だったのだろうか？
- 共通化することのメリットは、共通化するコストを上回っているかどうか検討されたのだろうか？
ビジネスでソフトウェアを構築する際には、「工業製品」が求められているのか、はたまた「工芸品」なのか、それとも「芸術品」なのかを気をつけるようにしている。普通われわれが作るのは「工業製品」である。ここに「工芸品」や「芸術品」を作る際の職人気質を持ち込むとおかしなことになると思っている。
舞台裏の話
遠い昔に舞台美術を志していたことがあって、アルバイトで舞台設置の手伝いもしていた。「カキワリ」に始まり、アートっぽい舞台装置もあったけれども、客席から見えない裏側はけっこう雑然としていて最初驚いた。クギは頭まで打ち込まずに、中途半端に打ち込まれている。実はこれには意味があって、「撤収(バラ)しやすくする」ためにそうなっているのである。クギを最後まで打ち込んでしまうと、抜くのが大変なのだ。だからわざと頭が出る状態にしておく。「舞台装置が壊れない」が最も重要な要件だけれども、その次に「撤収しやすく」があったのだ。舞台裏まで過剰に美しくする必要は無い。
舞台装置に限らずとも、裏側が考えているほど整然と整備されていないものはゴマンとある。
- 百貨店のバックヤード
- ビルの管理エリア
- 自動販売機の内側
- レストランの厨房
何が言いたいのかというと、何もかもを整然とした状態で保つことは必ずしも必須ではない、ということなのだ。
「芸術品」「工芸品」のソフトウェアを作っているのであれば、好きなだけ美しさを追求しても良い。しかし殆どの職業エンジニアにとって、作成するソフトウェアは「工業製品」である。過剰な美しさは、「あれば良い」ものだけれども必ずしも必須のものではない。もちろん保守性という観点で「美しい」コードを保つことは大いに意味があることだけれども、「美しいコードでなければ保守が出来ない」というわけではない。また「美しい」コードのほうがバグが少ないということも異論は無い。それでも過剰に「美しさ」にこだってしまうのは間違いだろう。
「美しさ」の議論に気をつける
リファクタリングという言葉が一般的になり、良いコードに関する書籍も最近充実している。「リファクタリング」は便利な言葉だけれども、だからこそ気をつけたい。
メンバーが「この部分のコードがひどいのでリファクタリングしたい」と言う。そこで私が考えるのは例えば次のようなことだ。
- リファクタリングしたい理由は何か
- リファクタリングする価値はあるのか
- リファクタリングする時間はあるのか
- リファクタリングする以外に品質を高めるために出来ることは無いのか
- 例えばテストを充実させるのと、どちらが効果が高いのか
Joel Spolskyが「Joel on Software」で書いていたのだけれどもプログラマは「既存のコードを捨てて新しく書き直したい」傾向があるということも忘れてはならないと思う。
というわけで「リファクタリングしたい」と言ってきたメンバーには、「われわれが作っているのは芸術品ではなく、工業製品なのだ。だからね・・・」と私は言うのである。
