id:kagamihogeが刺激的なエントリを量産しているので、このあたりの議論をまとめてみたい。
オブジェクト指向について
オブジェクト指向についてその内容を語れるわけではないのですが、これは間違いないなと思っているのがオブジェクト指向とコード品質は直接関係が無いということです。つまりオブジェクト指向に基づいてソフトウェアを設計したことによって間接的にコード品質が上がることは言えるけど、「オブジェクト指向にそった構造＝コード品質の担保」という等式は成り立たないと思っています。
なぜか。難しいからです。コンセプトや理論をそのまま適用することって難しいんです。
オブジェクト指向の考え方やデザインパターンは派手でカッコイイ（？）けど、それらの技術を適切なときに適切に使うことは難しい。
つまりこれは経営理論とかはカッコいいけど、それらの理論を適切に利用して成果を挙げるのは難しいというお話と同義です。
適切な人間が適切な考え方で適切な方法論で適切に運用されればそりゃ成果も上がりますが、そんなことは有り得ません。少数精鋭でサービス開発的な仕事ならまだしも、受託開発型のSIビジネスでは玉石混合のスキルメンバーであったり、デスマーチになったらとにかく動けばいいんだ品質担保とかのべき論かざしてもしょうがねぇだろプレッシャーにやられてしまいますので、仕組みとしてのサポートが無ければ鉄の意志を持ち続ける必要があります。いくらスキルがあっても、それを適切に行使できる環境がなければダメなんです。
コードの品質をどうこう言うのであれば、
変数・関数名に適切な名前をつける、関数が長すぎないようにする、同じコードを繰り返さない etc,etc。こういう原理・原則をしっかり守って書かれたコードはバグが出にくいし、出ても直しやすいことが多い。業務アプリでは後から手の入らないコードはほぼあり得ないから、一行一行が大切に書かれていることは品質の源泉になる。
このような配慮の積み重ねの方が直接的な効果が得られると私も考えます。オブジェクト指向に基づいた設計で作られた具象クラスのあるメソッドの行数が200行だった瞬間に、正直萎えます。お前ちょっとこっち来い、いいから来いとか言いたくなりません？w
で、問題はこういう原理・原則と言うのは、納期というものが存在する仕事の都合上「1人1人が頑張りなさい。そんなの常識でしょ？」と言った所でそれを担保する仕組みが無ければまず機能しないことです。「ひとりひとりが気をつけましょう」というのは小学校の学級会という素晴らしいメタファーにある通り。
例えばメソッドの行数制限を行う、Throwすべき例外を遵守させるためにCheckstyle等ではじかれたらコンパイルを通さないとか、クラスファイルからメタ情報抜き取って変数名を列挙して一覧化できるとか。最近開発から離れてしまっているので非現実的かもしれないけれど、原理・原則と言うのは基本的にシンプルなものなんだからそれを仕組みとしてルール化してコンパイル時にそれを適用して品質を担保するのである、ということを技術力のあるエンジニアが中心になって検討しなくてはならないと思う。
今そこにある危機に対しては、今そこにある手段で対抗するしかないのです。
バグレポートの話
さて、じゃあ下請け会社の評価基準は色々あると思う。ただ、大抵の元請ではバグレポートはその 1 つに入ってるのではないでしょうか。あるプロジェクトにつき、バグの出現数と致命的度合いによる評価、とかそんな感じのやつです。
要は減点方式なワケで、この状況下では出来るだけバグを出さないことが重要となります。
バグレポートかどうかは分かりませんが、バグを出さないことが大きな評価基準であることは確かです。だって受託開発なんだから。求められるのは先進的なコンセプトでもサービスでもないんです。オーダーに対してちゃんと応えたかどうかだけです。
発注する側からしたら「依頼して作る＝ちゃんと動く＝バグが無い」という思考になります。簡単に言えばコーヒーを頼んだのにお茶を持ってこられてもちょっとお前こっち来いという話になります。ソフトウェア構築に対する依頼とは、依頼された機能の実装をちゃんと担保してくれているかが当然検収条件になりますので、品質云々は二の次です。逆に言えば、そこまで厳密に逐一コードの品質チェックを行っている会社なんて一握りでしょう。
弊社のとあるプロマネは、最初の一本をまず書かせるというスタイルをとっていました。ここでどういったフレームワークを使っているのか、例外処理やトランザクション管理はどう考えているのか、CheckStyle等にかけて最低限のコーディング規約は守っているのか・・・、そういうのをちゃんとチェックして発注可否を下していました。アツい。この背中を見れた私は相当恵まれているなぁと思ったものです。
逆に言えば、バグの少なさ以外での評価基準って何だっけ、という話に変わってきます。コンサルティングとかではないので、この考え方や検討アプローチは大変素晴らしいね、という評価は下しようがありません。オブジェクト指向だけどバグだらけだね、となった瞬間に死亡です。
また更に話を進めると、バグこそが飯の種だろっていう考え方もあったりすると。
プログラマーの性能が上りすぎるのをいやがる企業だって存在する。プログラムの性能が上ると、トラブルが発生しなくなるから。トラブルこそが飯のタネという所謂デスマーチ企業というのが大量に存在しているのも現実。特に大企業ほど多い。1円で落札し、トラブルを発生させて、運用費用や改修費用を高くする事で損益を回収する企業が本気で実在するのだから。
ゼネコンの発想ですよね。昔ながらの企業さんに多い考え方です。逆にこの方式は資金に余裕の無い会社では出来ません。運用で取り返すために、単純にキャッシュが入ってくる期間が長すぎるためです。
こういう話を聞く度に思い起こされるのが、楠さんのこのエントリ。
結局のところ要件定義や仕様書に基づいてシステムをつくるという仕事は，ITが生む付加価値そのものを受け取るようにビジネスモデルができていないのだ．技術や製品・専門知識に希少性があった時代はそれでも儲かったが，ハードやソフト，それらに対する知識がコモディティ化した瞬間，サービスやソリューションそのものがコモディティ化することは避けられなかったのだろう．
では、本来ITが生む付加価値を受け取れるようなビジネスモデルは何だっけ？という議論を、私は社内で開始しています。
