花束問題を公表してからIT勉強宴会のメンバーと会話してみた。在庫管理システムに携わったことがない若手からは「どこから手を付けてよいか分からない」という声が多かった。色々なシステムの主にプログラムを作ってきた中堅技術者は「自分ならできる」と感じて設計を始めてみたが「途中からどう扱えばよいか分からなくなった」と語っていた。
中堅の技術者の方はこの問題について議論ができるようになってようやくスタートラインに立てたと考えてほしい。皆さんが所属する情報システム部門、開発会社の中でスタートラインに立っている技術者は何人いるだろうか。
最近ではローコード開発コミュニティ（旧・超高速開発コミュニティ）に花束問題を取り上げていただいた。「同じ業務をおのおののローコード開発ツールで実装、結果をお見せします！」というイベントが開かれ、盛況だった。
各種のローコード開発ツールを使って花束問題を解くためのモデルやシステムが実装され、コミュニティの会員に無料で公開されている。その活動については「ローコード開発リファレンスモデル分科会 活動報告ブログ」を見ていただきたい。
ローコード開発ツールは進化しており、業務設計をしてモデルを入力するとそのまま画面が立ち上がる動的制御ツールも増えている。こうなるとまさに「動的な仕様書」である。業務システムをだれかの設計に基づいてコーディングするだけの人はまもなく不要になってしまうだろう。Salesforceなどのクラウドサービスの利用がさらに広がればインフラ技術者の仕事も少なくなる。
業務設計に挑戦しよう
というわけで業務設計に挑戦し、「そういう業務でしたらこうすれば良くなるのでは」と提案してはどうだろうか。「何を作ってほしいか言ってもらえればどんなプログラムでも作ります」という姿勢では価値を生めなくなる。次の図の右側ばかりやっていた技術者は左側にも興味を持ち勉強する必要がある。
すべての業務処理は最終的に会計処理につながる。したがって帳簿設計も必要で最低限の会計帳簿の知識が求められる。データに着目して業務と帳簿を設計することを総称し、「データ駆動設計」と筆者は呼んでいる。
業務を設計し、花束問題を解くために「モデルを作ってみる」ことを強くお勧めする。モデルを描いていくと業務のつながりが見えてくる。プロが作ったモデルを読んで業務を学ぶこともできる。ドメイン駆動設計の信奉者であれば「ユビキタス言語とはモデルのことだ」と認識し、自らドメインエキスパートになることを意識してほしい。
先に述べた通り、現実の問題をいったん抽象化し、何らかのモデルに描くことが重要で、手法にはこだわらない。図に「データモデル」と書いておいたが別のモデルでもかまわない。
業務を紐解き、モデルを描くとはどういうことか、それを実感いただくため、在庫管理を例に話を進める。
在庫管理は需給調整と言い換えられる。物を作ったり仕入れたり売ったりする際、必ず相手がいる。需要と供給はなかなか一致しないから、例えば花屋がリスクを負って在庫を抱えたり、仕入れのタイミングを調整したりする。つまり数量や時間を管理する必要がある。
