« システム変数とシステム区分の設計 | トップページ | データ指向設計・開発の実践 »

2014.12.22

「だるいコーディング」を駆逐した後に残る仕事

 「開発効率アンチパターン」という興味深いスライドがある。Android向けアプリ開発において「だるいコーディング(機械的なコーディング)」の手間を減らすための工夫が説明されている。基本的にはコードのテンプレートを活用する手法だが、専用の関数を用意して、パラメータ指定でより複雑なコードブロックを自動生成できるようにしたいと結ばれている。

 このような効率改善のためのまっとうな努力は、開発の現場で広くなされていると思われるかもしれないが、必ずしもそうではない。スライドの作者である釘宮氏は、アプリを量産する必要に迫られている現場で働いておられる。そんな立場であれば、効率改善の工夫が欠かせないだろう。

 いっぽう、「膨大な工数を下請けにまわして管理費とマージンで稼ぐ」ようなSI系の現場では、開発効率については現状維持を了とする。ときには「だるいコーディング」の手間さえ、契約工数の埋め草として是認される。SIはそのビジネススタイルゆえに、せいぜい緩慢な効率改善しか受け入れられない。まあ、そんなブラックな現場についてはほっておこう。

 私がこのスライドで印象的だったのは、効率化における「パターン」の重要性が示されている点だ。どんな分野でも、ドメイン(問題領域)において繰り返し現れるパターンを識別することが、効率改善のカギである。プログラミングにおいては、クラスやアプリのパターンが識別される。それらのパターンに沿った仕掛けを組み込んでおけば、パターンを選んでその可変部分を指示することで、必要なコードブロックを一瞬で用意できるようになる。

 ただし、そこまでは「古典的」な工夫である。釘宮氏が気づいておられるかどうかはわからないが、パターン化が目指す現代的な目標はその先にある。

 すなわち、識別されたパターンが有用であるほど、その可変部分を制御するためのパラメータ構成は複雑になる。それはまさにDSL(ドメイン固有言語,Domain Specific Language)の適用領域だ。これを的確に体系化することで、「だるいコーディング」どころか「だるいコード」そのものを駆逐できる。「コードを書いたら負け」という言い方を聞いたことがあるかもしれないが、私に言わせれば「コードがあれば負け」である。コーディングを自動化しようがしまいが、管理すべきコードの量が多いほどシステムの保守性は低下するからだ。

 コードを駆逐するには、DSLに即した「エディタ」と「ドライバ」を開発しておけばよい。そのうえで、まずはエディタを使って、実現したいアプリの「仕様書」を作成する。これをドライバに渡せば、指定されたアプリにドライバ自身が変形して立ち上がる(*1)。拙作の実装基盤XEAD Driver/Editorはその実例である。

 では、こうした工夫によって「ノンコーディング」で開発できるようになるものなのだろうか。ごく限定されたドメインにおいては可能かもしれないが、一般の業務システム向けには不可能だと私は断言できる。「だるいコーディング」が駆逐されて、一定量の「だるくないコーディング」が残る。従来のような人海戦術は要らなくなるが、プログラマが要らなくなるわけではない。

 じっさい、上述した実装基盤でもノンコーディングが実現されるわけではない。バッチ処理等のパターンからはずれるような機能タイプについては、個々にコーディングせざるを得ない。また、ある種のビジネスルールについても端正なコードとして補う必要がある。

 たとえば、ユーザがUIを通じて追加した製造指示について、部品表(BT040)にもとづいて製造指示材料明細(JT011)を展開するために、以下のJavaScriptコードが製造指示テーブル(JT010)の拡張定義として登録される。他にも、入力値に対するバリデーションや導出フィールドの設定など、さまざまなコードがテーブルの拡張定義として補完される。

////////////////////////////////////
// 部品表にもとづいて材料明細を設定 //
////////////////////////////////////
rBT040 = instance.createTableOperator('Select', 'BT040');
rBT040.addKeyValue('製造品目ID',JT010_製造品目ID.value);
while (rBT040.next()) {
  quantity = rBT040.getValueOf('構成数') * JT010_製造指示数.value;
  cJT011 = instance.createTableOperator('Insert', 'JT011');
  cJT011.addValue('製造指示№', JT010_製造指示№.value);
  cJT011.addValue('材料行番', rBT040.getValueOf('材料行番'));
  cJT011.addValue('品目ID', rBT040.getValueOf('材料品目ID'));
  cJT011.addValue('投入数', quantity);
  cJT011.execute();
}

 なお、この種の「だるくないコーディング」は、プログラミング技術として必ずしも高度というわけではない。たとえばクラス構造について悩む必要がないので、UMLやオブジェクト指向を活用したいプログラマには物足りないかもしれない。また、SQLをほとんど書く必要がないので、そこらへんについて腕に覚えのあるプログラマにも物足りないかもしれない。

 とはいえ、この種のコーディングには独特の難しさと面白さが伴う。それは「システム全体の仕様を構想・決定すること」とセットになっているためだ。

 上述したように、書いた仕様書がそのままアプリとして動作するのであれば、「わたしは仕様書を書くひと、あなたは仕様書見ながらプログラムを書くひと」の分業が無意味になる。必然的に、開発メンバーは「だるくないコーディング」と「仕様書作成」とを兼務する。DBや業務連係の設計にまで関わらざるを得ないし、簿記をはじめとする業務知識も必要になる。ソフトウエア開発の合理化にともなって、プログラマの役割や責任範囲が変化するということだ。

 まとめよう。システム開発の効率化を徹底すれば、「だるいコーディング」は確実に駆逐される。ただし、その後に残る「だるくないコーディング」は、仕様策定の責任とセットになっている。それを軽やかにこなすための専門性が、合理化された現場で働くプログラマには求められる。


*1.仕様情報にもとづいてその場でアプリに変化する「ドライバ」の代わりに、専用の「インタプリタ」によって、仕様書の内容を事前に規定言語のコードに展開しておくやり方もある。私は前者を「動的制御方式」、後者を「自動生成方式」と呼んでいるが、仕様書作成と実装とが統合されているという意味では両者に本質的な違いはない。とはいえ私としては、コードの削減にこだわっているという点で動的制御方式が気に入っている。

|

« システム変数とシステム区分の設計 | トップページ | データ指向設計・開発の実践 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「だるいコーディング」を駆逐した後に残る仕事:

« システム変数とシステム区分の設計 | トップページ | データ指向設計・開発の実践 »