前回の記事の続きになります。
本当は今週TALONの基礎技術に関する特許審査が届き、特許取得しましたのでその話をしたいと思ったのですが、先週前編を書いた記事がありますので、先にその続きを書きます 。特許の話はまた今度書きたいと思います。
はじめに
前回は究極の業務システムを定義する所まで書きました。その結果、以下のような物が究極であるとしました。
- 設計した業務システムが即座に運用可能となり、ビジネスの変化に合わせて変化する
- 必要なプロセスは、「システム構想 → システム基本設計 → システム運用」
基本的には人間の頭脳が必要な領域のみが残され、コンピュータでも代用できる領域（プログラミング作業など）は削られています。プロセスが３つありますが、それぞれがこの言葉だけだとあいまいなので、具体的にどのような作業を指しているのかを以下にまとめました。
システム構想
どのような業務システムが必要となるのかを定義する段階。基本的にはここで決定した内容が業務システム完成後の成果目標となる。製造業であれば注文から製造・出荷までのリードタイムをXX％削減する、や、リアルタイムで在庫把握をする仕組み構築、など。通常のシステム開発プロジェクトでは、この内容をRFP（Request for Proposal、提案依頼書）という資料に纏めます。この資料を元にシステム開発会社がウチがやればこんな値段で実現しますよ、といった提案書を作ります。ここでは具体的なシステムの機能などには触れる必要がありませんので、必ずしもITの専門家は必要ではなく、業務に精通し、今後のヴィジョンを持っている人が重要となるプロセスです。
システム基本設計
システム構想で決定した実現したい内容を具体的にどのようなシステムとするかを決めます。重要となるのは、
- 作成する業務システムを利用した場合の業務フロー
- 業務システムの情報を格納するデータベースモデル
- その情報を利用する画面・帳票イメージ
になります。
システム運用
実際にシステムを運用するプロセスになります。究極の業務システム開発は、この段階でもビジネスの変化に合わせてシステムが変化するとありますので、ここでもシステムの変化が自動で発生します。ただし、自動と言っても、ビジネスの変化をシステムに伝える必要がありますので、システム構想、システム基本設計は必要となります。
通常はこのシステム基本設計の後に一般に詳細設計と呼ばれる設計を行います。これは、基本設計で決めた処理の流れや画面・帳票イメージから、システムが人間の代わりに行う処理（ビジネスロジック）をプログラム言語で表現可能なレベルまで設計します（例えば注文の入力という処理が行われた場合、注文情報としてデータベースに登録すると同時に、注文された商品の在庫があるか確認し、存在する場合は内部的に予約をしておき、ステータスを在庫確保済みとしておく、など）。その後にプログラミングによる開発を行い、様々なテストを経てシステム運用に入りますが、究極の業務システム開発ではこの詳細設計書からテストまでを削除しています。
理由は、コンピュータが代用できる可能性を持っている為です。
何故、現在は究極の形が実現しないのか
今回定義した究極の業務システム開発は簡単に言ってしまうと開発・テストフェーズを無くして、運用後もシステム改造する場合に開発・テストフェーズが無いから非常に速い速度で改造を行う事が出来るという物です。
これが実現出来ない一番大きな理由は、
- 実際に動くプログラムを自動で作る事が出来ない
という一点に尽きると思います。逆に言うと、これが実現すれば究極の形は簡単に実現します。自動で作ってくれさえすれば、プログラムコードと大差無いくらい細かく記述する詳細設計書やプログラミングをした結果をテストする必要もなくなりますので（テストが必要なのは人が作る物たからですね）。
では、なぜプログラムは自動で作られないのでしょうか？
これは、ビジネスロジックを自動変換してプログラムにする方法が存在しないからです。そして、そもそも自動変換させるためにはビジネスロジックをコンピュータが分かるレベルに記述する必要があります、そうです、すなわち詳細設計書が必要なのです。
では、この部分もSFのような話で実現する事は不可能なのでしょうか？
私はそうは思いません。この部分は将来的には十分に実現可能なのではないかと感じています。
どうすれば実現するのか
詳細設計書を作らずにビジネスロジックを自動変換してプログラムにするにはどうすれば良いでしょうか？
これは、システム基本設計の成果物である、業務フロー、データモデル、画面・帳票イメージから自動でビジネスロジックを作りプログラムコードに変換すれば良いのです。CASEツールというキーワードが浮かぶと思いますが、現在のCASEツールでこれを完全に実現しようと思うと、基本設計で定義したフローなどにあらかじめ取り決めた開発方法論を適用して、ルールに基づいた記述を徹底して、プログラムコード生成を行う必要があります。このルールに基づいた記述というのが曲者で、完全な自動生成を目指すと、結局詳細設計書を作成するのと同じ位細かな記述を延々とするハメになります。実際にはプログラミングと同じぐらいの細かな専用記述を書くのであればこれまでの開発とあまり変わらないという事になります。（もちろん設計物と実行プログラムの一元管理という視点で見ると有用だとは思います）
処理の分岐、エラーチェック、データの見せ方・メンテナンスの仕方などを自動でプログラムコードにするには、現在は同じ細かさの記述が必要です。それを無くして、フローとデータモデル、画面・帳票イメージからビジネスロジックを生むためには何らかのイノベーションが必要になるのは間違いありません。そして、それは現在のCASEツールとは違う方法論になると考えています。少なくとも上記３つの資料に関係線を引く位で自動生成してくれないとダメだと思います。このイノベーションを起こせば極めて大きな価値となるのは間違いないので日々考えていますが、現在はこの究極段階は程遠いというのが正直な所です。
TALONは何を目指しているのか
究極の形はこれまで書いてきた内容ですが、現在の技術では難しい（情報の扱いが現在存在するリレーショナルデータベース、オブジェクト指向データベースの形ではない何かが必要なのかもしれません）ので、現在できる最適解をという事でTALONを開発しています。
まず、TALONでは業務システムの機能要素を大きく２つに分けています。
- ユーザインタフェース＋定型化可能、もしくは単純なビジネスロジック
- 定型化出来ない、業務・会社に特有、かつ複雑なビジネスロジック
この２つに分けています。ユーザインタフェースは画面や帳票のレイアウトや入力領域の情報です。ビジネスロジックが１と２の両方にありますが、これを分ける基準は定型化できるかどうかです。定型化とは、画面や帳票に表示する情報の取得や、入力値のチェックや、印刷時のステータス変更や、マスタ情報のメンテナンスや、内部処理として複雑なチェック・更新などが存在しないトランザクション情報のメンテナンスのようなビジネスロジックが単純なデータベースの登録・更新・削除機能です。２のビジネスロジックはそれ以外の処理部分を指します。
TALONの考え方はこの２つを開発の中で別物として捉えます。
まず、システム構想でプロジェクトの目標を定義しますが、ここでは特にTALONは利用しません。TALONが出てくるのは次からで、システム基本設計で画面・帳票を設計する際にTALONを使って、実際に運用で利用できる本物の画面・帳票を作ってしまいます。これは5分で作れるというコンセプトを持っているTALONだから出来る事です。そして、TALONで作った画面・帳票の情報からデータモデルを設計します。作った機能はデータベースにリポジトリ情報として格納されますので、そちらの情報をデータモデル設計の補助資料として使います。
実はこのシステム基本設計完了時点で先ほどの「１．ユーザインタフェース＋定型化可能なビジネスロジック」の作りこみは完了しているのです。TALONで作った機能はプログラムソースを生成せずに起動しますのでプログラミング作業は不要です。（補足ですがプログラミングを記述してロジックを実現することも可能です）
大規模開発になると、流石にプログラミングをゼロにする事は出来ませんが、本当に人が行うしかない部分だけに狭めることが可能になりました。また、システム基本設計で画面・帳票のレイアウトを決定する為に通常はモックと呼ばれる紙芝居をExcelやHTMLで作りますが、TALONは動く機能をその場で作りますので後工程でそのまま使用できます。さらに、実際にデータが入って動いている画面を見て利用ユーザと打ち合わせが出来るので、打ち合わせでイメージがしやすくなります。
それでは今回はこの辺で。
文=古関 雄介
