厄介なのは同じ「在庫」という単語でもお客様によってしばしば意味が違うことである。システム開発者側にいると似た業務システムの設計や開発を何度か経験できるが、かえって早飲み込みしてしまう危険がある。ヒアリングをしていて「何か話が通じていないな」と感じた時は素直に確認することが大切である。
時折見かけるが、技術力に自信を持っている技術者で「知らないことは恥ずかしい」と勘違いし、知ったかぶりをする人がいる。勝手な理解で間違った業務システムを作ってはいけない。
経験を積み、業務知識を蓄えていくためにもモデルは欠かせない。個別の詳細な業務要件は冒頭に書いた「現実」でしかない。それを「抽象」の世界で分析し、モデルにまとめれば、そのモデルは現場の担当者やIT技術者との間の共通言語になる。他のプロが書いた様々なモデルを読み取るのは簡単ではないが勉強になる。
公開しているモデルから読者の皆様または読者の部下の若手設計者が何か一つでも得てくださればIT勉強宴会に来てくれた技術者が無償で設計、実装に取り組み、しかも結果を公開してくれた意味がある。ぜひ活用してほしい。
そして、できればIT勉強宴会に参加し、業務設計やモデリングの議論に加わってみてはいかがだろう。花束問題とは別に、当日の参加者がその場で手を挙げて比較的単純な業務要件を説明し、その場にいる複数の技術者が2時間以内に設計・実装し、デモをする「ライブモデリング」と呼ぶイベントも時折行っている。
この一風変わった名称の勉強会を開始してもうすぐ10年がたつ。連載1回目の記事で勉強会を始めた経緯と目的、活動概要を紹介した。
次回から本連載の寄稿者を花束問題の共同制作者である渡辺幸三氏にバトンタッチする。渡辺氏は『業務システムのための上流工程入門』（日本実業出版社）を出し、多くの迷える技術者を救ってきた。
渡辺氏は早くから三要素分析法と呼ばれる設計手法を提唱、実践している。「データと画面（UI）と業務手順という三要素を同時に設計する」というものだ。最初の著作で「データモデルのパターンで画面は自動的に生成できる」と書いた渡辺氏は主張を実証すべく、基本設計の情報を入れるだけで自動的に動く画面を作りだせる「X-TEA（エクスティ） Driver」というツールを開発、オープンソースとして公開している。全てを1人で作っていることに驚かされる。
渡辺氏は業務システムの骨格としてのデータベース構造について解説するはずである。筆者自身、読むのを楽しみにしている。
