技術者に要件定義を経験してもらうと、時折、次のような人が現れる。「いい考えを思いつきました。業務分析で業務フローを書いていますよね。そのフローからプログラムを自動生成できる気がするんですよ」。ひょっとしたら読者の中にも同じことを考えた人がいるかもしれない。

 業務担当者自らが自分で使うプログラムを組み立てるというのは、エンドユーザーコンピューティングと呼ばれる技術分野の一つだ。特に、業務プログラムは定型的なところが多いので、業務フローからプログラムを自動生成することを目指した人は大勢いた。古くは1980年代の第4世代言語と呼ばれる活動まで遡れる。世界的なIT企業の研究者の多くが考えてきたことであり、今も世界中で多くの人がチャレンジしているはずだ。ただ、今のところうまくいってはいない。

 筆者はそうした研究開発プロジェクトをいくつか見てきたが、今後もうまくいかないだろうと思っている。理由は簡単で、業務担当者が定義できる程度の“いいかげん”な業務フローでは、とてもシステムを動かすまで至らないからである。そこを甘く見たプロジェクトは似たような道筋をたどる。

 最初は単純な業務フローでツールのプロトタイプが作られる。単純なフローであれば、フローをグラフィカルに編集してその通りに動作するプログラムを自動生成することは比較的容易だ。業務担当者自らプログラムを作ることのできるメリットには説得力があり経営層の心をつかむ。

 研究開発の予算が確保できると、より本格的な要件向けに拡張していくことになる。例えばフローの承認順は逆でも構わない、という事情に対応させることを考えると、フローの表現と制御の両面でツールの改良が必要になる。フローに並列動作を表現できるような記述方法を導入すると共に、自動生成するプログラムも並列動作できるようにする。難易度の高い要求としては、フローで記述しにくいタイムアウトなどの例外への対応がある。しかし、これも例外処理技術を参考にして解決できる。このようにして、グラフィカルなフロー図と設定ダイアログの操作だけで業務プログラムを自動生成するツールを作ることは可能である。

 しかし、この時点でツールはかなり高度なものになっている。ここで直面するのは、業務担当者が自動生成ツールを使いこなせるのかという問題だ。並列処理や例外処理などのメカニズムを理解してフローを作るのは、詳細設計をするのと変わらない作業になる。普通の業務担当者にはそんなことは不可能だ。この現実に直面した後どうするか。投資して作ったものはなかなか捨てられない。たどる道筋は似ている。ツールの想定利用者を業務担当者でなくIT技術者にし、主な用途を顧客向けデモに変更する。

 こうした経緯で作られた自動生成ツールが出回り、IT技術者が使わなければならない状況にときどき巻き込まれる。使ってみるとすぐ分かるのだが、たいていはツールの固有環境でしか動作しない上、カバー範囲は限られる。カバー範囲の中と外のギャップは大きく、限界を超えたところで問題なく動かすには高い技術力が必要になる。パッと見は便利そうな自動生成ツールを使う方向で話が進んだら、ここで書いたことを思い出してほしい。

 ここまで自動生成ツールを否定的に見てきたが、役に立たないとは思っていない。IT技術者の手間を省くツールという方向では有望で、それは今後のシステム開発の方向性でもある。つまり、要件定義から実装まで長く延びていた開発工程を短くするということだ。そうなると、重要な活動は工程の両端に集約されていく。曖昧な業務をシステム化できる精緻さまで落とす活動と、自動生成ツールの限界を補ってシステム全体を完成させる活動だ。この両端を担うスキルの重要性は今後ますます高くなると思う。

林 浩一(はやし こういち)
ピースミール・テクノロジー株式会社 代表取締役社長。ウルシステムズ ディレクターを兼務。富士ゼロックス、外資系データベースベンダーを経て現職。オブジェクト指向、XMLデータベース、SOA(Service Oriented Architecture)などに知見を持つITアーキテクトとして、企業への革新的IT導入に取り組む。現在、企業や公共機関のシステム発注側支援コンサルティングに注力