世の中便利になった、と実感することが多くなってきている昨今。スマートフォンの登場でさらに利便性が増しITの重要性も強調されたように思える。しかしながら、システムを提供している技術開発の現場、またはシステムを利用しているユーザの環境はどれだけ進化してきているのだろうか。
確かに、優れたソフトウェア製品が日々登場し、徐々に便利にはなっているのであろうが、開発の手法そのものは数十年前から変わっておらず、既存の枠組みから抜け出すことができていないと言えるのではないだろうか。
　システム開発及びそれを利用するユーザの環境を取り巻く世界が、進化から取り残されている。そんな危機感を覚えたとき、ふとSNSの世界を見てみると、ITスキルの高いユーザのみに利用される環境だった時代から徐々に一般ユーザが気軽に利用できる環境へと移行が行われている。
　システム開発の世界も、IT技術者から一般ユーザへの移行、がキーワードではないか。

　そんな仮説を立てつつ、ユーザ自らがシステムを構築することをコンセプトとした製品「MagicLogic」開発の軌跡と今後の方向性について本論文にて記していきたい。

　まず、過去から現在においてシステム開発の現場がどのように変わっていったのかを検証していきたい。まず、現在主流となっているシステム開発方法論「ウォーターフォール・モデル」だが、1968年、NATO後援の国際会議にて、ソフトウェア開発を職人芸的な作成方法から工業製品としての作成方法に変える方法として、製品製造過程のように開発をいくつかの工程に分け、各工程の終了を意味する文書を作成することで進捗を管理し、早いうちから品質の作りこみをしようとするウォーターフォール・モデルの原形が提唱された。この後、初めて「ウォーターフォール」という用語を用いたのはT.E.BellとT.A.Thayerによる1976年に発表された論文「Software Requirement」である。「ウォーターフォール・モデル」という用語は、文字通り「滝」を意味しており、その構築フェーズは、設計、製造、テストという段階を踏んでシステムの完成を迎える、という工程となっている。アジャイル開発やスパイラル開発、モデル駆動開発等、一時持てはやされた開発方法論はあるものの主流にはなりえず、現在の開発はこのウォータフォール型が基盤となっている。

　では、なぜ古い時代の産物であるこのウォーターフォール・モデルの開発方法論が現在まで主役となりえているのか。それは、逆に言うと他の方法論が下記の点の問題点を解決できないからという指摘がある。

① 要件を変更したときの見積もりや契約の方法が確立されていない
② 各工程の頻繁なリリースによるバージョン管理が難しい
③ テストの自動化に関するノウハウが蓄積されていない

　状況を鑑みるに、特に上記①の部分の理由が大きな要因ではないかと考えられる。

　請負契約においてはその見積根拠を示す必要があり、示せなければそもそもの金額の妥当性を表現できない。つまり、この壁を越えられない限り、請負開発においての開発方法論はウォーターフォール・モデルに最終的には帰結することになる。

　ということで、請負開発を開発の前提としている場合、このウォーターフォール・モデルの設計、製造、テストというフェーズ移行の基盤が大きな枠組みとなっていることを意識する必要がある。

　なぜかというと、このウォーターフォール・モデルは、製造依頼者（顧客）の要件を、製造担当者（ITベンダ）が、イメージを徐々に形にしていく工程であることが前提となっているからである。つまり、製造担当者（ITベンダ）側は、常に顧客とのイメージの共有及びコミュニケーションを図るところからスタートすること、及び請負開発における納期から逆算される工期を基に工程のスピード感を意識付けられるため、開発進化の方向性としては、大体以下のようなカテゴリに分かれ進化することとなったと考えられる。

① 要件定義ツール（業務プロセスフロー作成ツール等）
② 設計支援ツール（ERD作成ツール、UMA関連ツール等）
③ 情報共有ツール（ファイル共有ツール、FAQ管理ツール等）
④ プロジェクトマネジメントツール（ガントチャート、プロジェクト管理ツール等）
⑤ 製造支援ツール（各種フレームワーク、プログラム自動化ツール等）
⑥ テスト支援ツール（テスト自動化ツール、テストドキュメント生成ツール等）

　このように考えていくと、開発方法論が前提としている、顧客（製造依頼者）と製造担当者（ITベンダ）との関係性、つまり「顧客の要求を製造担当者が理解、分析し、システムを物理的に創造していく」という過程を踏襲する必要があるため、このような進化の方向性になったのではないかと推察することができる。

　さて、このような現状の中でどのような問題点が出ているのかを考察していきたい。

　ユーザからの要求は、主にヒアリングによるコミュニケーションや顧客側から提示された要件を開発担当者側が理解、分析し、設計情報に落とし込んだ後、レビュー等の顧客側との意思疎通を経て承認後、製造・開発フェーズに移行する。

　概ね上記がシステム開発における、要件を設計に落とし込むまでの作業となっているが、ここにはいくつかの落とし穴が存在する。

　落とし穴の一つ目は、顧客の意図を完全に理解し、設計に落とし込む作業は、人間の持つ意思疎通能力から考えても非常に難しい作業であって、ほとんどの場合、どこかで意識の齟齬が発生してしまうという点である。そもそもシステムに要求したい曖昧なイメージを文字と図表のみで不特定多数の第三者と共有すること自体、不完全な情報共有手法なのである。これは、システム、というより人間の持つ表現力の限界が起因している。

　また、落とし穴の二つ目になるが、もし仮にユーザとの意思疎通が同調可能であったとしても、顧客の意向を基にそのままを設計に落とし込んでいった場合、その意図するところにおける運用上の矛盾が発生してしまう可能性があるという問題点がある。

　開発担当者側は、顧客の意図を忠実に反映しようとしてしまうが、運用上の顧客の意図が、そのままシステム要件上の正解とは限らないのである。結局のところ、顧客が提示した要件について運用上の矛盾や仕様祖語が生じてしまう可能性については、誰もその可能性を排除できないというのが現実である。そのために、業務のスペシャリストを用いてシステムを構築していく等の対策も取られてはいるが、この場合、汎用的な業務システムの構築はスムーズに進めることができるものの、その反面、自社独自の要望をコミットする場合のフィットアンドギャップの作業が生じるため、業務上の「あるべき論」と自社要望との取捨選択の判断が非常に難しいという別の問題が生じてしまうのである。

結論から言うと、ユーザの要求を完全に満たすことは、たとえオーダーメイドによる仕様実装が前提となっている請負開発においても、開発担当者との意識の共有や顧客自らが認識できていない運用上の矛盾等の起因により、現状どのような開発方法論を採用してもどこかに問題や課題が生じてしまう、というのが現状である。どこか意図が伝わっていなかったり、開発担当者側が気が付かない運用上の矛盾を孕んだまま運用を開始してしまうことも多々あるため、リリース後すぐに改修作業に入るとなどということはよくある話である。
　
では、このような現状を打破することはできないものだろうか。

そう考えたとき、いくつかある解決策の中でも前提を覆してしまうような考え方がある。

それは、「ユーザが自らの手でシステムを開発してしまえばよい」すなわち、「内製化」という手法である。

本来、コスト削減というテーマの中で語られることが多い内製化論であるが、これを要望イメージに近いシステムを構築するための方法論と位置付けるのである。

ユーザが自らの手でシステムを開発する、すなわち「内製化」という手法であるが、第三者意思を介せず、ダイレクトに要求を形にすることができるため、出来上がったときの満足感は高く、また問題点や運用イメージを共有できている自社のメンバにて開発を行う関係上、ウォーターフォール・モデルの枠組みを意識する必要もないため、開発方法論としては、アジャイル開発やスパイラル開発の方が向いている。当然のことながら完成度は必然的に高くなるわけだが、それが簡単に出来るのであればすでに浸透しているはずで、主流になりえていないということは現実的には様々なハードルがあるであろうことは容易に想像ができる。

では、この内製化が容易に行えない理由をひとつひとつ洗い出していきたい。

まずひとつは、、開発パワーが足りない、という問題点である。

小規模なものであればその作業ボリュームにもよるものの、対応することは概ね可能なことが多いが、規模が大きくなるにつれ開発パワーの確保が困難となり作業を進めていくことが難しくなっていくのである。

このような条件下で内製化のうまく行った事例としては、弊社のお客様である某鉄工所様の生産管理システム構築の内製化案件があげられる。

こちらでは弊社で推薦させていただいたシステム開発ツール「GeneXus（ジェネクサス）」を採用していただき、私も含めた弊社のGeneXusの技術指導兼、製造支援担当者2名と4名の情報システム担当者にて開発していったのだが、無事納期にも間に合い、運用もスムーズに運び、顧客の満足度も非常に高かった、という好事例である。

この事例では成功に至るいくつかのポイントがあったのだが、以下、そのポイントを下記の通り挙げてみた。

① GeneXusは、DOA（Data Oriented Approach：データ指向設計）の要素が非常に強いツールなのだが、当初から各担当者のDOAに対する知識と経験が豊富だった。
② 担当者全員が、Delphi等の他言語のシステム構築スキルやDBMSのノウハウを持っていたため、技術的な習得が早かった。また、弊社技術的な担当者が常に傍にいたため、技術的な問題があっても対応をスムーズに行うことができた。
③ すでに運用をしている業務だったので、システム化における業務上の問題点、矛盾点が早期に洗い出されており、業務仕様への落とし込みの際、混乱することがなかった。

このようなポイントを踏まえ適切に対応した場合において、内製化が成功するという好事例ではあるのだが、逆にいうと、このポイントのいずれかが欠けている場合、内製化が失敗に終わる要因にもなりえる、ということでもある。特に内製担当者の技術スキルやマンパワーの確保という部分においては根本的な要素であり、この要素を満たすことができない場合、即座に破綻に繋がる可能性があった。この例の場合、開発パワーの不足を開発ツールであるGeneXusで補えたことは大きかったが、GeneXusでフォローできていなかったら破綻していた可能性もある。内製化、といってもそう簡単ではないことが上記好例の裏返しを考察すると窺い知ることができるわけである。

では、こういった問題点を解決する方法はないのだろうか。

一つ解決策を挙げるとすれば、「要件のパターン化」が挙げられる。

つまり、『全て０から要件を検討し構築するのではなく、汎用的なシステムの要件をパターン化し、その中から取捨選択できる仕組みがあれば、ロジックによる構築ではなく要件の組み合わせによる構築へとシフトすることができるのではないだろうか』というアプローチである。具体的なイメージとしては、ウィザード形式のような「選択」をしていきながら、システムを構築する手法である。

このような設計思想にてシステムを構築することが可能かどうかの見極めのポイントとしては、汎用的なシステムの要件を抽出し、その要件の組み合わせによりシステム構築上の矛盾が生じないことが絶対条件となる。また、要件同士の組み合わせにより要望の相互補完が行われることで、構築できるシステムの幅を広げていく必要がある。

では、次に汎用的なシステムの要件にはどういったものがあるのかを考察していきたい。

ここでは、汎用的なシステム要件とは何かを考察していきたい。

システムによって当然のことながら要件は異なるが、どのような業務のシステムでも大抵同様の要件となっているとイメージできる事項に関しては、汎用的なシステムの要件に該当すると考えられる。

図1.5　共通要素と汎用的なシステム要件

また、「複雑（高度）な仕様＝汎用的」とする場合、非該当システムの方が多くなってしまうため、「シンプル（簡素）な仕様＝汎用的」、とこの場では定義してみる。
とはいうものの、フロントのオンライン画面系システムとバックエンドで動作するバッチ系システムとは、同じシステムであっても根本的な部分で異なる性質を持っている。

今回は、より要件が明確化され、かつユーザが認識しやすいオンライン画面系システムに的を絞って考えていきたいと思う。また、システムの要件といってもシステム全体における非機能要件から、各個別の機能要件まで幅が広い。まずは誰でもイメージできる一般的な要件群から分析していきたい。

1.5.1.ログイン認証

ログイン認証において汎用的な要素といえば、ユーザID及びパスワードによる認証であることは疑う余地がない。SSO（シングル・サイン・オン）を実現しているシステムや、ActiveDirectoryによる認証を行っている例は勿論あるが、汎用的であることを条件とした場合、ユーザID、パスワードの入力による認証が誰でも思い浮かべる認証手法であるため、1名のログインユーザに付き、この「ユーザID」及び「パスワード」による認証を行う仕様を基盤とする。

以下の要件もこのような推論に則って汎用的要件を決めていく。

1.5.2.権限

権限については、業種職種、または事業規模によっても要件が変わってくるところであるが、一番シンプルな以下の権限設定を基盤とする。

① 1権限につき、利用できる機能が設定されている
② 1名のログインユーザにつき、1権限が付与される
③ 権限は利用権限の他、「登録・更新・削除できる権限」、「参照権限のみできる権限」

を選択できるのが望ましい。

1.5.3.ログ出力

ログについては、操作（アクション）ログを基盤とする。基本的にはボタンクリック単位で、ログインユーザのアクションがログに出力される、という仕様である。システムによっては、デバックログ等、「ある特定の目的のために出力するログ」というものも確かに存在しているが、一般的、汎用的という面を考慮した場合、操作ログ出力を基盤とする。

1.5.4.履歴管理

履歴については、データベースの新規登録、更新、削除のタイミングで、旧データを履歴テーブルに登録することで履歴管理とするのが誰もが思い浮かべる仕様であるため、この仕様をもって基盤とする。

1.5.5.一覧、検索系機能

この一覧、検索系機能以降より、機能種別における機能要件となる。
固有の機能要件では、汎用的な「大枠の機能仕様」を定める必要があり、その機能仕様によって、設定される個別のテーブル及び項目を「フレキシブルに設定」することができれば、汎用的な機能として成立することになる。
具体的に例を出してみると、一覧、検索系は、「大枠の機能仕様」としては、以下の通りとなる。

① 検索条件項目が必要。複数条件がある場合、AND条件となる。
② 検索結果表示欄の表示が必要。表示結果に対して項目のソート（昇順・降順）を行うことができる仕様が望ましい。

この検索条件項目に、商品マスタの各項目（商品コード、商品名、商品カテゴリ区分等）を設定し、検索結果表示欄にも同様の項目を設定すると、「商品マスタ一覧検索」機能となり、顧客マスタの各項目（顧客番号、顧客名、郵便番号、住所、電話番号等）を検索条件項目、及び、検索結果表示欄にに設定することで「顧客マスタ一覧検索」機能となる。フレキシブルな項目設定ができることが前提条件となるが、これが可能となった場合、一つの大枠の機能要件のルール設定によって、複数のテーブルデータの管理を行うことができるようになる。よって、以下機能要件より大枠の「大枠の機能仕様」を抽出し、項目についてはフレキシブルに設定することを前提とするため以降は省略する。

1.5.6.登録系機能

登録系機能は、業務システムを基準に考えた場合、「単票登録」（カード型）と「明細登録」（伝票型）の２つが代表的な入力様式だと考える。

この単票登録と明細登録の「大枠の機能仕様」は、以下のように考える。

• A.単票登録
• • ① 表示形式は、縦に項目が並べられる方式が一般的である。
  • ② 項目によって、2列表示とし、Z型の入力順番により入力できる仕様が望ましい。
  • ③ 場合によっては、項目のカテゴリ分けができるようタブによる項目の振り替えができる仕様が望ましい。
• B.明細登録
• • ① 親テーブルと子テーブルが同一の主キーで結合されている必要がある。
  • ② 子テーブルは複数持つことができ、またこれらの子テーブルの入力はタブにより切り替えられる仕様が望ましい。
  • ③ 子テーブルの数値データを親テーブルにて集計できる仕様が望ましい。
• C.単票、明細登録共通
  • ① 項目のデータ選択方式（エディット入力、ドロップダウン選択、チェックボックス選択、ラジオボタン選択、参照ボタンによる選択）が設定できる仕様が望ましい。
  • ② 登録、更新時にデータのリミットチェック、データの型チェック（数値型、日付型、任意チェック等）が自動的に動作する仕様が望ましい。

1.5.7.一括登録機能

テーブル一括登録における「大枠の機能仕様」は、以下のように考える。

① １つのテーブルに複数データを1アクションで登録することができる。
② 登録だけではなく、更新、削除も行える仕様が望ましい。
③ 登録時において、オンラインで提供されるデータチェックが一括登録でも同様に動作する仕様が望ましい。
④ 一括登録の元となるデータは、EXCEL等のユーザと親和性の高いアプリケーションにより纏められている仕様が望ましい。

1.5.8.ファイル出力機能

ファイル出力機能における「大枠の機能仕様」は、以下のように考える。

① ユーザの親和性が高い、CSVファイル及びEXCELファイルにて出力できる仕様が望ましい
② 出力の形式は、一覧表形式、単票形式、親子明細形式のそれぞれが選択でき、また出力位置はフレキシブルに設定できる仕様が望ましい。
③ EXCELファイルによる出力の場合、罫線や計算式の定義等をユーザ自身が行ったファイルをベースファイルとし、そのベースファイルに対してデータを出力できる仕様が望ましい。

1.5.9.メニュー管理機能

メニュー管理機能における「大枠の機能仕様」は、以下のように考える。

① カテゴリ分けによる機能配列になるよう、ツリー形式の表現ができる仕様が望ましい。
② カテゴリと機能は違うアイコンで表現されている仕様が望ましい。
③ カテゴリは多重階層を持てるよう設定できる仕様が望ましい。

上記1.5.5検索、一覧系機能以降のような様々な機能要件において、一般的なテーブル構成に落とし込んだ場合、常にデータ構造を切り替えていく必要に迫られる。この場合、データがまだ投入されていない場合であれば変更を行うことができるが、データがすでに投入されている場合、正規化の概念上、容易にデータ構成の変更を行うことができなくなってしまう。

　この状況を避けるため、1.5.5でも述べた「フレキシブルな項目設定」ができることが必須となる。この仕様を具体化するにあたり検討した結果、データを一般的なテーブル構造のように「平面」で持つのではなく、「立体」で持ってしまえば問題を解決することができると結論付けた。

　「立体」で持つ場合、複数のテーブルの情報が一つのテーブルに集約される。
そしてその立体構成の枠をルールとしてデータを格納するような仕様とすれば、枠そのもの立体構成が制約とはなるものの、その枠内において様々なデータを一括管理することができるようになる。

図1.6.1　立体データの取得例（ログインマスタの情報取得）

上記は立体データの取得方法を簡易図にしたものである。ユーザの意識は平面でのデータ管理となるため、従来のSQLのような簡易なデータ取得方法を用いることができない。実際のデータ取得に置けるプロセスは上記図1.6.1のように一度、平面位置情報からデータの立体位置情報を取得し、立体の物理データを取得するという非常に複雑なプロセスを実行する必要がある。しかし、複雑であるとはいうものの、方式さえ確立してしまえば不可能ではない。このデータの保持手法を実現することで、データ枠の上限という制約はあるものの、機能要件に対してフレキシブルなテーブルや項目の設定を行うことが可能となるのである。

上記、「1.5.汎用的なシステムの要件とは」から、「1.6. 汎用的な機能要件をフレキシブルに格納できるデータ構造の模索」にて「汎用的な要件（仕様）とは何か」を洗い出し、その機能要件に対して「フレキシブルにデータをセットできるデータ構造」の方式を定義することができた。このような考えを現実に製品化したものが弊社製品である「MagicLogic（マジック・ロジック）」である。
名前の由来は、単語の語韻が似ていることと、「魔法のようなロジックでフレキシブルな機能要件を実現することができる」というイメージから名づけられた。
愛称は、「マジロジ」である。
MagicLogicの構成イメージは以下の通りである。

図２　MagicLogic構成イメージ


MagicLogicは、サーバアプリケーションだが、サーバ上の実装設定システムである「インプリメントシステム」上で、作成したいシステムの汎用的要件を設定により定義し、実行することで運用実行システムである「エグゼキューションシステム」に反映される仕組みとなっている。

さて、このMagicLogicであるが、実際の機能を解説することで、汎用的なシステム要件にて挙げられた要件を満たしていることが確認できると思うので、要件を設定するところから掻い摘んだ形で解説していきたい。

インプリメントシステムでは、まず作成したいシステムの概要を定義するところから始まる。例えば、「顧客管理システムを作成したい」ということであれば、顧客管理システムとしての要件の概略を定める。具体的には、システムのロゴやイメージカラーといったデザイン要件、パスワードの有効期限や世代管理に関する認証要件、メール通知をする、しない等のシステム全体に関わる要件を定めていく。


図2.1-1　システム設定画面


その後、下記の流れに従って、システムの要件を定義していく。
MagicLogicは、GeneXusにおけるDOA（Data Oriented Approach：データ指向設計）の思想を一定レベルで受け継いでいるため、最初の要件設定として、データ構造の登録を行うところから始める。まず、システムに必要なデータ要件を「テーブル設定」にて設定する。その後、定められたデータ項目における「データチェック設定」を行い、各テーブル間の連携を「テーブル連携設定」にて定め、その後、ログイン認証に必要なテーブルをテーブル設定で行ったテーブルから選択する「ログイン情報設定」、テーブル設定を元に機能を組み立てて、その遷移を定める「機能設定」を定義し、最後に作成した機能のメニュー体型を「メニュー設定」にて定義後、実行を行うことで、エグゼキューションシステムに反映される。

図2.1-2　インプリメントシステムの流れ

「テーブル設定」だが、下記画面を見ていただくとわかるように、キーとなる項目は5つまで、従属項目は50個までという制限が設けられている。（タブ化されており、最後のデータ枠は41~50の従属項目設定タブとなっている）
これが、「1.6.汎用的な機能要件をフレキシブルに格納できるデータ構造の模索」で記載した、「立体構造におけるデータ枠」である。
　この枠を超えるシステムは、今現状MagicLogicでは生成できないが、逆に言うとこの枠に収まるシステムであれば、あらゆるデータの管理が可能となっている。

図2.1-3　テーブル設定のデータ枠

機能設定では、下記のように「単票登録」、「明細登録」、「Excel帳票出力」、「一括アップロード」、「一覧表示」の機能を作成することができる。
機能は、一覧表示機能からすべて呼び出される。

図2.1-4　MagicLogicで作成できる機能


ひとつのテーブルから呼び出される機能は同じテーブルの編集機能であることが基本であり、汎用的である。例えば「商品一覧」から「顧客登録」の機能は通常呼ばれない。「商品一覧」からは「商品登録」機能が呼ばれるのが一般的であり、「商品一覧表」が帳票として出力されるのが当然の流れである。通常こういった部分もプログラミングを持って遷移を定義するが、MagicLogicのような汎用的動作を突き詰めたシステム構成をベースとしている場合、わざわざプログラミングをする必要はなく、汎用的なルールに則りただひとつのテーブルに関するどの機能種類を呼ぶか、を定義するだけで良い。定義をしている例は、図2.1-6を参照いただきたい。

図2.1-5　MagicLogicの機能遷移（同一テーブルにおける機能遷移）


図2.1-6　機能遷移の定義

上記は「受注テーブル」に関連する一覧系機能「受注一覧」であるが、呼出機能とともに「検索条件項目」と、検索結果の一覧表に表示する「一覧表示項目」が定義されている。
　このように「1.5.5.　一覧、検索系機能」で洗い出された汎用的な機能要件さえ定義できれば、一つのテーブルに対する検索、一覧系機能の役割はプログラミングを用いなくても「大枠の機能要件」を満たすことができる。

では、実際に運用する、エグゼキューションシステムを解説する。
最初に、エグゼキューションシステム側のログイン画面が表示される。
　このログイン認証は、インプリメントシステム側の「ログイン情報設定」機能で定義された情報に基づき認証される。

図2.2-1　ログイン認証設定と、その実行結果のログイン画面


ログイン認証後、メニューが表示され、メニュー上の任意の一覧機能を選択すると一覧機能が表示される。この機能から、設定通り一覧機能を通じて受注関連の帳票や受注明細登録機能が表示される。また、受注一覧も設定の通りの検索条件及び検索結果表示欄が表示される。

図2.2-2　一覧機能の実装結果例（受注一覧）

明細機能を見てみると、親テーブルの情報とともに子テーブルの情報が登録できるようになっている。さらに画面を見てみると、親テーブル「受注」に対する子テーブルは、「受注明細」、「経費明細」、「値引明細」の3テーブルとなっている。MagicLogicでは、他では類を見ない複数の子テーブルへの登録が可能となっているが、これを可能としているのが、テーブル連携設定における、「親子関連設定」である。

図2.2-3　親子明細型入力フォームの実装結果例（受注明細登録）


親子連携設定では、親と同一のデータ型であるキー項目が１つ、子テーブルに配置されており、かつ子テーブル側の専属のユニークキーが１つあれば連携を行うことができる。
　下記、「図2.2-4　テーブル連携設定の設定例」では受注明細登録の設定が行われている。
親テーブルである受注に対して子テーブルは受注明細、経費明細、値引明細の3テーブルが設定されている。

図2.2-4　テーブル連携設定の設定例（受注明細登録）


下記は、受注テーブル（親）と受注明細テーブル（子）の関連付けの例である。
親項目の受注番号が、子テーブルの方にも設定されている場合、紐付が行われる。
　この紐付が認識されることで、「図2.2-3　親子明細型入力フォーム」が２つのテーブル構成で表示され、入力されたデータがそれぞれ２つのテーブルデータとして管理されることになる。このような項目の論理的結合や、画面形式構成の設定だけで明細機能の「大枠の機能要件」は成立する。この要件を実現するためにプログラミングは必要としない。
　もちろん細かいロジカルな仕様を入れ込もうとすれば、それは１アクション単位のロジックの構築が必要となり、すなわちプログラミングが必要ということになるわけだが、その必要がない場合、プログラミング自体もまた必要なくなるのである。


図2.2-5　受注と受注明細との関連付け


非機能要件に該当する「ログ出力」や「履歴管理」についてだが、「1.5.3.　ログ出力」
「1.5.4.　履歴管理」で洗い出した要件を元に自動的に出力されるようになっている。
　これは、一つのテーブルにデータが多重管理されているというMagicLogicの特性を活かした機能であり、比較的容易に実装することができたため、パフォーマンスも快適である。

図2.2-6　ログ参照と履歴参照機能

下記のとおり、「1.5.汎用的なシステムの要件とは」の章で洗い出した汎用的である範囲は、ひとつのシステムから見ると、そのカバーしている面積はとても広いとは言い難い。　今後は、ユーザのご意見や顧客ニーズをキャッチアップし、この汎用的である機能の要件範囲を拡大していくことで幅広くシステムのノンプログラミング化にて実装できる範囲を増やしていくことが至上命題となる。その場合、今までのような機能要件の中から汎用的要素を抽出するだけでなく、さらにミクロな要件の分析、具体的にはロジックの中に存在する汎用的な要素を見つけ出していく必要がある。
勿論、簡単な作業ではないが、遡及点を見出して対応していくことができればこのようなノンプログラミングによるシステム構築の幅が広がっていくことは疑いようのない事実である為、今後も果敢にチャレンジしていきたい。

図2.3　MagicLogicの今後の機能拡張イメージ

ノンプログラミングによるシステム構築については、懐疑的な声や否定的な声も存在しているのは理解している。そういった声のある中で作成されたMagicLogicは、ひとつのアンチレーゼであり、意欲的な実験製品でもある。現時点では全てのシステムをノンプログラミングで実現することは現実的とは言えないかもしれないが、小規模ながらそれを実現することができたMagicLogicという製品に、私自身はこの先の光明を見出している。

ソフトウェア製品、ことにIT製品は如何にして情報を扱い活かしていくかということを追求していった結果が利用価値へと繋がっていく。

　あらゆる方面からの要件や要望を基にシステムの在り方、データの活かし方を追求し、それをMagicLogicに反映していった結果がユーザの幸福に繋がることを期待し、今後も意欲的にノンプログラムによるシステム構築というに取り組んでいきたい。

1. 菅野孝男『改訂ソフトウェア開発のマネージメント』新紀元社、1996年。
2. 「ウォーターフォール・モデル」-Wikipedia

https://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A9%E3%83%BC%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A9%E3%83%BC%E3%83%AB%E3%83%BB%E3%83%A2%E3%83%87%E3%83%AB#cite_note-FOOTNOTE.E8.8F.85.E9.87.8E.E5.AD.9D.E7.94.B7199634-1