全4477文字
PR

 「これでいこう」とユーザーが納得するデータモデルに仕上がったら開発はほぼ終わりである。私が使っている開発ツールはSELECT文を定義するだけで業務の処理画面を作れる。ユーザーと打ち合わせをしながら画面を確定できたら、データを更新する仕組みを設定すれば入出力を含む業務処理機能が即座に完成する。

 このようにデータモデルがいったんでき上がれば、SELECT文を使って実際のデータを直接扱う感覚で業務システムを開発していける。現場で帳票を毎日使っているユーザーであれば実データを見つつ、SELECT文を使い、一部の開発をこなせるようになる。

 このやり方にしてから業務システムができあがってきたらユーザーが思っていた物と違っていたという齟齬(そご)が激減した。ユーザーと技術者の間でシステムのイメージを共有でき、ユーザーも開発に参加しているつもりになってもらえることが大きい。

新システムの姿を開発の前にユーザーに見せる

 新たなやり方を編み出すきっかけは、スキルがバラバラの技術者をかき集めて業務システムを開発させる人海戦術への違和感だった。上流工程における設計が終わり、開発工程に入ると急に開発者が増える。複雑な機能など一部の例外を担当する人を除くと、さして高いスキルを求められない。とにかく人を集め、工程ごとにガチガチのルールで縛り、品質のばらつきがなるべく出ない環境を作って、がむしゃらに開発させる。

 私はこうした環境にたびたび置かれ、「なぜこんなことになってしまうのか」という気持ちが膿(うみ)のようにたまっていった。効率的に進めているように見えるがルールで押さえつけられ創意工夫の余地はほとんど無いから技術者のスキルアップにつながらないし、なにより楽しくない。顧客への請求には多重下請けに伴う費用が上乗せされる。IT業界はもうかっても顧客や技術者は幸せではない。

 なんとかしたいと考え、「データモデルが完成した時点で業務システムもほぼ完成する仕組みがあれば人海戦術を無くせる」と気付いた。データモデルに提示される、データ同士の関係は業務で表示したり加工したりしていく情報そのものであり、ここにほとんどすべてがある。そのまま業務システムにできればいい。

 ところが従来はデータモデルを作ってもユーザーが確認できるのは人海戦術による開発工程を経た後、テスト工程になってからだった。テストをして「これは違う」とユーザーに言われると、また人海戦術で手直しする。設計者とは別の技術者が開発することも多く、設計したデータモデル通りに実装されないことすらあった。

 新しい業務システムの姿を開発に入る前にユーザーに何とか見せたい。同じ思いを持つ仲間と共に私は2014年に起業し、「TALON(タロン)」と呼ぶツールを開発した。今でいうローコード開発ツールでソースコード非生成型に分類される。

データモデルをそのまま動く業務システムに

 業務で使うデータや業務の流れなどほぼすべてがデータモデルの中にあると述べた。例えば、販売管理システムの販売単価を管理するテーブルの主キーが商品コード、顧客コード、適用開始日であれば、販売価格は商品、顧客、適用開始日の組み合わせのみで決まり、ロットサイズなどで変化しないことが分かる。