上流工程から自動生成へつなげることの難しさを知ると、ビジネスチャンスが見えてくる

私が意識して活動しているから、という立場を差し引いても、今年に入ってから「業務アプリケーション開発は自動生成が主流になる(ことは避けられない)」という意見を多く伺うようになりました。直接お会いさせていただく方、ブログ等の意見、メディアの記事、いずれもその潮流を後押ししています。こうやって時代が変わっていくのだと思うと、感慨深いものがあります。10年後のSI業界のビジネスモデルは、今とは大きく変わっていることでしょう。

 

さて大枠として自動生成化に進むとしても、早くからそれを実践してきた経験からいえば、まだまだ解決すべき課題は多いと思っています。それは視点を変えると、開発の自動化という時代における新しいビジネスチャンスが到来しているということです。その最たるものは、上流設計から具体的な自動生成エンジンへつなげていく方法論が固まっていないことです。

 

業務アプリケーションの上流設計といっても、関わる人の立ち位置によって、さまざまな視点があります。ここに、おおまかな図をつくってみました。ここでモデリングとは「特徴を抽出し、不要なものを削ぎ落として、わかりやすく可視化する」ことです。

 

f:id:ynie:20120618222222p:plain

ビジネスモデリング

お客様はそもそも自分が欲しいものが何かをわかっていない(可能性がある)ので、そこから整理しようというお話。いわゆる「超上流」に分類されます。最近ではビジネスモデル・ジェネレーションという言葉まで登場しています。企業にとって何が収益モデルで、どのコストを削減するかといった "共通の目標" を認識し、社内で共有する土壌をつくるまでがこの段階なので、経営層を巻き込んだ会議が主体です。

 

業務フローのモデリング

業務フローは、収益を生み出す機関です。そこが古い仕組みで無駄が出ていたり、本来、収益化できるチャンスを逸しているなどは問題なので、そういう見直しを含みつつモデル化します。このレベルでの自動生成を実現する製品はユーザーインタフェースを持たず、データ連携や業務ルール実行といった、複雑なオンライン処理やバッチ処理を対象とします。また、既存のばらばらなシステムを(内部を変えずに)うまくつなぎあわせるという手法も提案されています。

 

データ構造のモデリング

対象データの入力発生源の確定、各データの管理責任の明確化、意思決定支援に用いるデータの決定、不正データの扱いといったデータ視点でモデリングを行います。ここには業務用語辞書という概念も含まれ、異なる表現だが意味が同じなら統合できるというマスタデータ管理という視点もあります。古くは DFD や ER 図があり、オブジェクト指向時代にはクラス図といった表記法が登場しています。さらにクラス図の情報からデータベースへの基本処理(登録、更新、検索、表示)を行うプログラムを自動生成する MDA という技術も登場しています。データベース操作中心の自動生成であり、ユーザーインタフェースは、おまけ的なものがほとんどです。

 

ユーザー体験のモデリング

システムを実際に操作する利用者による、ユーザー体験という視点でモデリングを行います。主に入力画面、検索・一覧表示画面、そして帳票になります。ここで得られた画面レイアウトとデータ構造、そして業務フローは必ずしも一致しません。一つの画面には性質の異なる複数のデータが含まれており、そして条件(データの性質もしくは月初、月末といった時期)によって業務フローも異なります。よってユーザー体験のモデルからシステム全体を把握することはできませんが、利用者からみた具体的なシステムの姿になっています。

 

非機能要件

非機能要件は、モデリングとは異なります。機能要件が「○○すること」という表現を使うのに対し、非機能要件は主として「○○しないこと」という視点から、その条件を満たすためのシステム構成を検討していきます。

 

すべてを俯瞰できる、統一的な仕様記述言語をつくることはできるのか

もともと UML は「統一モデリング言語」という枠組みを目指しているので、もっとも近い立ち位置にいるでしょう。しかし UML からアプリケーションを自動生成する MDA が登場したとき、その UML は複雑すぎるという非難の声が少なからず上がりました。その後 UML の拡張ペースは落ちているように見えます。このことから、一つの仕様記述言語ですべてを表現するのは受け入れられないのではないかと感じています。

 

各分野の成果物が相互作用する巨大な設計書を支える

現実には、ここであげた分野それぞれに専門家がいらっしゃいます。そしてすべての分野を一人でこなすことは困難です。

であれば、各分野の専門家がそれぞれの記述方式で表現した「(ある視点からみた)システム」をつなぎあわせ、その結果でてきた巨大な設計書を俯瞰し、理解する必要があります。

ところで「設計書の理解」とは何を意味するのか。旧来型の開発ですと、その設計書をもとに、さらにプログラマーが理解できる詳細設計書、そして内部設計書へと処理を細かく記述していくことでした。抽象度の高い自由文章から、何段階もの形式言語変換を経て、最終的にプログラムコードに変換することがシステムの開発作業です。

しかし開発の自動化という時代では、この設計書を読み込んで、必要なコードを生成するエンジンが登場します。私が知るところ、このすべてを理解できるエンジンはまだ存在しません。(その実現はまだまだ先ではないかと思います。)一方で、エンジンが理解できる範囲で設計情報量を絞り込むことで、開発自動化を実現できるのもまた事実です。

つまり「設計書の理解」とは、「上流設計の成果物を解釈しつつ、自動生成エンジンの実現能力とのギャップを把握し、その間を埋める」こと、です。

自動生成エンジンは万能ではありませんが、その能力を活かすことで、これまでのプログラミングでは不可能だった開発生産性を達成できます。そして、エンジンの手に余るところを補完する形でプログラムを書くことで、上流設計が求めた要件の実現を「高速に、かつ高品質で」達成できるようになります。それが次の時代の業務アプリケーション開発の在り方です。

この流れの中で、「新しい開発スタイルを実現できる技術者」のニーズが急速に高まってくるというのが私の予想です。

 

きたる28日、29日に沖縄で開催されるWagby Developer Daysでは、そういうスタイルを具体的に実践してきた技術者が発表します。新時代のエンジニアの具体的な姿として彼らの発表を聞いてみてください。期待を裏切らないと思います。