2022年現在、どの組織も高度に細分化、複雑化された「システム」となっており、そのシステムをPCなどのデバイスを使って扱うものを「業務アプリケーション」と呼んでいます。業務アプリケーションはシステムの一部をある切り口で「モデル化」した「データ」と「業務処理」を操作するソフトウェアです。
このような組織で働く一個人としての "私" はシステムの一部であり、業務アプリケーションを介在してシステムをより良い状態に導くのが （組織に身を置く）"私" の仕事であり、やりがいです。通常、良い状態というのは数字で把握できるようになっています。達成率を上げる、不足しないようにする、といった数値目標が見える化されており、この実現に向かって日々の仕事をこなしていくわけです。ところが、この状況をもって、"私" はシステムの奴隷である、と感じる方がいるかもしれません。この感じ方は、どこからくるのでしょうか。
奴隷とはどういう状態かを考えてみます。おおむね合意をとりやすいのは、"私" の「自由」もしくは「意志」を発揮することができず、システムが（業務アプリケーションを通して）"私" に次の仕事を指示する枠組みになっていることではないでしょうか。つまり奴隷ではないと感じるためには、"私" の意志、あるいは決定に基づいてシステムの内部状態が変わり、それが自分（あるいはチーム全体）にとって、よい影響を与えることが実感できること、といえます。
これを前提に、今度は業務アプリケーションが扱う時間軸、という視点で整理してみます。
最初に登場した業務アプリケーションは、人間に代わって情報を正確に記録することが求められました。これは「過去」をカバーすることです。
その後の業務アプリケーションは、今どうなっているのか、という状況を「見える化」することを求められました。これは「現在」をカバーすることです。
そして現在の業務アプリケーションは、過去の情報と現在の状況から、未来の時間に何が起こるかを予測できることが求められています。つまり「未来」をカバーすることです。
この予測に対して、"私" がどうすべきかがシステムから（業務アプリケーションを介在して）一方的に指示されるのであれば "私" の「意志」は必要ありません。予測から "私" の次の行動を自分の「意志」で決めることができれば、"私" はシステムの奴隷ではなく主人となりえます。
なぜ私は業務アプリケーションをパッケージソフト導入ではなく、自分達で作ることにこだわっているのか、もここに理由があります。私見ですが、多くのパッケージソフトの思想は "私" の意志を介在させることなくシステムが運用できることを目指しているのではないかと感じています。このメリットは個人の能力によって業務遂行のレベルに差が出ないことです。しかし "私" はシステムの制御下に置かれるため、"私" はこの組織の中で代替可能な要員、と受け止めてしまうのです。
業務アプリケーションを自分達で作る、というのは、今いるスタッフを念頭に置きつつ、ここまではシステムが面倒をみるが、ここからは現場に委ねるという線引きを自分達で決める、ということです。自動化する部分と現場が判断する部分の棲み分けを意識した上流設計を行うことになります。当然、現場の判断には担当者の特徴がみえてきます。失敗する判断を行うこともあるでしょう。それをあえて残し、現場力とみなす、というのが私が求める上流設計の思想です。
これらを考慮し、システムをデザインすることはエンジニアにとってやりがいのある設計です。しかしこれまでは実装コストの問題で、冒険的な上流設計を行うことはできませんでした。ローコード開発ツールの活用によって設計から短時間で実装できるようになったため、業務アプリケーション開発の試行錯誤が可能になったことは大きなメリットです。
郵便管理簿でみるサンプル
わかりやすい例を示します。総務部のための「郵便管理簿」アプリケーションを想定してみます。いつ、どこに何の郵便物を送付し、切手を何枚使ったのか、を記録することが目的です。
業務アプリケーションは最低でも「過去」をカバーする必要があるので、すでに送った郵便記録の作成と検索機能は必須です。
では「現在」のカバーとは何でしょう。おそらくそれは切手の在庫状況を把握することです。本日時点で、あとどのくらいの切手在庫があるかを知ることは総務にとって外せない要件でしょう。
その上で、総務部担当者の「意志」が介在できる部分はどこにあるでしょうか。それは切手の在庫推移を把握することです。そのためには「（すでに送った）郵便の記録を管理する」だけではなく、「将来、この郵便を送る予定がある」という状態も記録できるようにします。未来の切手使用予定を管理対象に加えることで「今月は月末を待たずに84円切手の在庫が不足しそうなので、早めに調達しておこう」という判断につながり、在庫補充というアクションを起こすことができます。常に切手の欠品のない状態を維持することが担当者にとっての（小さいながらも大切な）やりがいになります。
このくらい簡単ではないか、と感じた方は是非、実際の業務アプリケーション設計に挑戦してみてください。どういうテーブル構造にすべきかを探ることが、上流設計の最大のポイント「モデル設計」です。
私はこの在庫推移という考え方の有効性を、IT勉強宴会が提供した「花束問題」で知りました。
若奥さんを助けるための「花束問題」、これが解けたら立派な中堅技術者だ | 日経クロステック（xTECH）
同時に、モデル設計を起点にアプリケーションのあるべき姿を見出すためには、システムと "私" の位置付けをどう捉えるかを考え続ける必要があると感じたところです。
参考までに Wagby ではこのテーマについてどういうテーブル構造を提供するのか、というサンプルを用意しました。
https://wagby.com/tutorial/addongallery-yubinkanri.html
どなたでも Wagby にログオンして、このアプリケーションのモデル（テーブル定義を含む設計情報）を確認できます。モデルさえ描くことができれば実装コストはほとんどかからない、という事例として、みていただけると幸いです。
