近年ハードウェアの性能向上などにより、IT業界をめぐるインフラは、ようやく市場の要求に耐えうるようになってきた。以前はプラットフォームの陳腐化により５年と持たなかったソフトウェアの平均寿命は、ここへきて徐々に延びつつある。
このような状況の中でソフトウェアに求められるものは、繰り返し行われる機能追加に耐えうる拡張性と、長期に渡って品質を保つことのできる保守性だ。これらの課題については、クラウドのような分散コンピューティング技術や、オブジェクト指向デザインなどの設計思想といった大きな枠組みの中で数多く議論され、ソフトウェア技術の進歩を押し上げてきた。実際の現場においてこれらの課題をインプリメントするのは、システム設計者やSEなどの、上流工程をまかされた人間の役目であると一般に言われている。
彼らのアウトプットは、基本的に文書（Documentation）だ。日本語や図から構成され、比較的読解の敷居は高くない（作成の難易度は高い）。特に顧客や経営者に見せる資料は、専門知識がなくとも理解できるようわかりやすく書かれていることだろう。彼らのアウトプットは多くの人の目に触れ、議論にさらされやすい。たくさんの批評や支援の下に経験を積むことで、おのずとその品質や精度は上がっていくだろう。
一方、我々プログラマの方はどうだろうか。
驚くべきことにIT業界に携わっている人でさえ、プログラマのアウトプットが「ソフトウェア実行モジュール（実行ファイル）」だと思っている人がいる。もちろん最終的には実行モジュールを納品するのだから、その見解は間違いではない。しかし、我々が画面に向かってあくせくとタイプし、ない知恵を振り絞ってひねり出しているものは、プログラミングされたコードの方である。実行モジュールは、ソースコードを実行可能な状態に加工したものにすぎない。
そもそも読解に多くの前提知識を必要とするソースコードにあれこれ言える人間の数は限られている。実際の現場において議論の対象となったり吟味・分析される機会は、上流工程のそれに比べて異様に少ない。工数が潤沢にあるプロジェクトであれば、ソースレビューやペアプロなどが実践されているかもしれないが、それでも１つのコード作成に関わるのべ人数はせいぜい1～2人であり、コードそのものがブラッシュアップされる契機は、残念ながらあまりないのではないだろうか。
これまではそれで良かった。結果的にソフトウェアが正しく動けばそれで事足りていたからだ。我々に課せられた一番の課題は実行モジュールが正常稼動することであり、障害が発生すればそれを修正するだけであった。この時点でアウトプットの評価はもはやソースコードから離れ、テスト項目の網羅性やテスト結果に基づく品質分析によって行われることとなる。
このように設計と検査の間にある工程、つまり我々が最も苦労するコーディングの作業は、ブラックボックス化される傾向にある。ところができあがったソースコードの質は、プログラマの能力によって驚くほどの差がでる。なぜなら上流工程で作られる設計書は、必要機能や拡張保守性を網羅するための「プログラミング設計指針」にすぎないからだ。
もしソフトウェアの設計書が建築物の設計図と同じなのだとすれば、設計図通り忠実に作りさえすれば誰が作ってもまったく同じものができあがるはずだ。実行モジュールの動作だけをとって見れば、これは当てはまるだろう。しかし、本当の意味でのアウトプットであるソースコードは、１つとして同じものにはならない。設計書をコードに落とすには、（設計図と比べて）あまりにも情報が足りなすぎるのだ。
そこには上流工程で網羅されなかった、粒度の細かい機能仕様や設計が数多く存在する。どこまでを上流で設計するか、プロジェクトによってもその線引きは非常にあいまいだ。プログラマは絶えず不足分の設計を行いながらプログラミングしており、上流のツケによって払わされたコストは、ブラックボックス化された工程の中にすべて押し込まれ、周りからはまったく見えない。
これに加え、アルゴリズムの組み方やコードの可読性、プログラミング言語の習熟度や上流設計を自ら改善できる能力などの様々な要因が関わってくることで、できあがるコードの実装レベルにおける保守性が大きく変わってくる。特にソースコードは最も頻繁にリビジョンアップが行われる納品物であり、常に水準低下の危険性にさらされている。修正方法の質によっては、後々の保守作業に甚大な被害をもたらすかもしれないにもかかわらず、その修正の詳細を把握しているのは、ほぼコード作成者本人だけである。今後、拡張・保守工程の期間が伸びるであろう将来のことを考えると、深刻に受け止めなければならない問題であることに間違いない。そして一番の問題は、このことを知っているのはコードを読解できる限られた人間、プログラマだけであるということだ。
残念ながらプログラマを除くほとんどの人は、コードが正しいことよりも実行モジュールが正しく動くことの方を優先する。非常に洗練されたコードは、バグのないプログラムに負ける。優秀なプログラマはバグの数によって過小評価され、その素晴らしいプログラミングの思想は日の目を見ることなくその人だけの暗黙知となる。プログラマは自分のコードについて学習できる機会が極端に少ない。スパゲッティを作る人はいつまで経ってもスパゲッティを作り続け、よもや自分のコードに多くの改善点があるとは思いもしないだろう。
我々は実行モジュールを作っているのではない。ソースコードを作っているのだ。
プログラマ自らがコードの洗練性や進化を渇望せずして、一体誰がそれを望むのか。我々は一刻も早くコードの質の向上について議論しなければならない。このままではいつまで経っても他人の書いたプログラムの修正に頭を抱えたり、機能追加にかかる工数を理解してもらえず、ブラックボックス化された工程の中で孤軍奮闘しなければならないだろう。来るべき保守フェーズ長期化時代に向けて、対策を練っておく必要がある。いつまでも海外からの技術革新を待っているだけでは、日本のIT業界は市場に生き残り続ける製品を作ることが難しくなっていくだろう。
では「コードの質の向上」とは一体なんだろうか。「洗練されたコード」とは何であろうか。いくつか論点があると思うが、私が最も重要視しているのは「可読性」である。プログラマがコードの可読性にもっと気を使うことで、ソフトウェアの長期保守性が格段に上がると信じている。ここではその詳細は述べないが、機会があればテキスト化する（できる）かもしれない。
プログラミング言語は構造化やOOPなど様々な進化を遂げてきたが、次の大きな技術革新は「可読性の向上」に焦点を当てたものではないかと私は推測している。ScalaやRubyなど最近の言語は、非常に簡潔なコードが書けるものが多い。言語仕様が徐々に可読性という方向に向かって進歩しつつある兆候なのかもしれない、という考えはいささか勇み足だろうか。
ちなみに簡潔なコードであれば可読性が高いかというと、必ずしもそうではないと私は思っている。一見冗長ではあるが、わかりやすく書かれたコードというものも存在するだろう。一通りの経験をお持ちの方であれば、この辺りの話は容易に理解できるはずだ。では少し飛躍するが、遠い将来には変数名のスペルミスすらコンパイラがチェックするようになるかもしれない、と言うとどうだろうか。「さすがにそれはないだろう」と思った方は注意した方がいい。なぜならコンピュータは、いずれ人間の言語を解して動くようになるからだ：Ｐ
コメント