仕事で会計関連のバッチ処理を設計しているところなのだが、機能のほとんどが数値を操作するだけのいわゆる業務ロジック（ビジネスロジック）なので、ちっとも面白くない。そういえば、WEB+DB PRESS Vol.38
もちろん、このタイトルの意味は理解している。「業務ロジック」というのは、ユーザーの業務に特化した処理である。そのため、それぞれのシステムによって処理内容が違い、その都度新しく処理を「書く」必要がある。一方、業務ロジック以外の部分は、どのシステムでも似たようなものになりがちなので、ある程度は汎用的な仕組みでの対応が可能だ。システム開発の効率化を考えるとき、業務ロジック以外の部分の汎用性を高めて「書く量」を減らすというのは重要なことである。そういう意味で、「業務ロジックしか書きたくない」というのは自然な話である。
しかし、純粋な意味で「書きたいか、書きたくないか」と問われれば、私は業務ロジックをあまり書きたいとは思わない。ほとんどの場合、顧客の業務内容に興味は沸かないのである（もちろん例外はあるが）。むしろ、業務ロジック以外の部分を書くほうが面白い。例えば、そのシステム専用のアプリケーション・フレームワークや共通ライブラリを作ったりするようなことである。開発プロジェクトの中で、そういう仕事をするメンバーを「共通チーム」と呼んだりするが、そういったチームとして働く時の方が楽しい。
ある程度大きな規模のシステム開発では、「共通チーム」が専用のフレームワークを作り（あるいは既存のものを拡張し）、他のメンバーはその仕組みの中で動作する業務ロジックを書いていく、という形をとることが多いだろう。
つまり、多くのプログラマにとって、フレームワークは使うもの（使われるもの？）であり、作るものではない。以前、「簡単フレームワーク・プログラミングの罠 」にも書いたが、このことは、プロジェクトの効率化という意味では好ましくとも、プログラマのスキルアップという意味では好ましくない。
業務ロジックだけを書いていたのでは、多くのシステムで必要なはずの基礎的な技術が身につかないからだ。例えば、データベースへの接続方法が分からないとか、適切な文字コードの変換方法が分からないといったことが起こる。ずっと業務ロジックだけを書いて生きていければいいのかもしれないが、現場ではそれ以上のことが求められることも多く、あわてて勉強するような人もいる。
コンピュータの世界は、問題を簡単にするための仕組みが積み重なって層を成しているように見える。ある「層」は、下の層にある複雑な問題を隠蔽する（プログラマ流に言えば「ラップ（Wrap）」する）ことで、機能を簡単に利用できるようにしている。業務ロジックだけを書く人が、フレームワークの中身を知る必要がないのと同じように、フレームワークを書く人も、言語の処理系（コンパイラやインタプリタ、VM など）の実装内容まで知る必要はない。こうした階層構造は、アプリケーションから OS、ハードウェアの領域に至るまで、幾重にも積み重なっている。技術者が効率的に分業できる仕組みになっているというわけである。
複雑化した現在のコンピュータについて、一人の人間が全ての階層について理解するのは難しい。しかし、自分のスキルを今以上に伸ばそうと思うなら、自分が今立っている「層」のひとつ下ぐらいは覗いてみることも必要だろう。端的に言えば、自分がいつも呼び出している「共通関数」のソースコードを読んでみることである。
それを面白いと感じないなら、なかなかできないことではあるが。
■関連記事
・簡単フレームワーク・プログラミングの罠
・頭を使うために頭を使う時代
・最低限の道具でどこまでできるか
・面白いプログラムを作ろう
・嬉しいこと
技術評論社 (2007/04/24)
売り上げランキング: 128319
翔泳社 (2007/03/17)
売り上げランキング: 57633
総集編