設計者の発言

　大切な人の記念日に花束とカードを贈りましょう――そんな事業を支援するシステムの三要素モデルを公開した。もともとのシステム要件は「花束問題V1.2」として、IT勉強宴会のサイトで公開されている。複雑過ぎず単純過ぎないバランスの良い問題である。

・ダウンロードページ（モデルを閲覧するにはX-TEA Modelerが必要）
・花束問題V1.2のページ

　要件をざっと説明しよう。「商品」である花束に組み込まれる素材は「単品」と呼ばれ、入荷日毎にロット管理される。単品ロットはナマモノなので、規定の日数後には廃棄されなければいけない。ゆえに、受発注状況に応じた単品の欠品見込や廃棄見込をリアルタイムで示すための仕掛けが要る。次図は公開したモデルの一部である。

▼受注～出荷の流れを示す業務フロー

▼受注まわりのデータモデル

　このシステム要件にもとづいてまとめられたモデルを、手法横断的に比較検討する。そんな活動をIT勉強宴会でやっている。初回は2月20日の第39回IT勉強宴会で、私の手書きモデル（後掲）や鳥谷部氏によるT字形ER手法でのモデルが公開されている。2回目は4月25日で、TH手法やDDDでのモデルが示される予定だ（当日私は別件で参加できない）。

　腕に覚えのある技術者には是非挑戦していただきたいモデリング課題なのだが、1点だけ注意してほしいことがある。たとえば三要素モデルの業務フローをユースケース図に、データモデルをクラス図に、それぞれ機械的に変換することは難しいことではない。だがそれでは「記法の違い」がわかるだけで面白みがない。変換結果を見て「手法が違っても、目指すところは同じってことだよなぁ」なんて納得されても困る。

　どうせモデリングするなら、誰かが描いたモデルを翻案するのではなく、「花束問題」の原文にもとづいてモデリングしてほしい。そうすることで、「問題の認識の枠組みとしてのモデリング手法」の特性や性能までわかるからだ。ある手法では気づけるが別の手法では気づけないことがある。そこらへんを吟味できることは、標準問題の大きな意義だ。

　意識されることが少ないが、標準問題にはもうひとつの意義がある。三要素モデルをダウンロードして眺めてもらえばわかるのだが、もともとの「花束問題」の文言に含まれていない要素がいろいろと補完されている。そのことは、初回にホワイトボードに手書きしたモデル（次図）と比較してもよくわかる。手書きの段階では、わかりやすく示すために省略されていた要素が想像以上に多い。モデリングツールを使ってまとめた段階で大量に示される「頼まれもしないのに組み込まれた要素」がじつは重大な意味を含んでいる。

▼最初の手書きモデル(第39回IT勉強宴会,2015/02/20)

　「花束問題」もそうであるように、現実のユーザの語りやRFPは、実装のあり方を１００％カバーするものではない。じっさい、語られたことだけを実装してコトが済むのであれば、エンジニアなど要らない。ビルの施工業者は施主に「鉄筋？そんなものは入れてません。だって、鉄筋が欲しいなんて言わなかったではないですか」とは言わない。エンジニアはさまざまな技術的配慮を「頼まれもしないのに」仕事に組み込むものだ。そこらへんの配慮の深さが専門家としての腕の見せ所といってもいい。

　ところが、システム開発を担当する技術者は「繰越処理？パージ処理？そんなものは設計してません。そういう機能が欲しいなんてお客さんから言われてませんから」なんてことをピアレビューで平然と言ったりする。なぜか。ようするに、彼らが「ソフトウエアの開発者」であったとしても、「業務システムのエンジニア」になり損ねているからだ。

　「頼まれもしない機能を組み込む」といっても、出血大サービスしようなんて話ではないし、工数を水増ししようなんて話でもない。明示的に求められているわけではないが、省けば業務システムとして問題が生じる要素がある。それらの扱いについて積極的に提案し、話し合って仕様やコストを決めようという話だ。それをせずに「顧客から言われたことだけやります」なんて素人でもやれる。

　もちろん顧客の語りは仕様策定の重要なヒントになるが、あてにしすぎると失敗する。なぜなら彼らの多くは、担当業務を効果的に支援する帳簿組織やプロセスが本来どうあるべきかといったレベルの問題意識を持っているわけではないからだ。単に「これまでどのようにシノいできたか」を語れるだけだったりする。その意味で、彼らは「ドメイン・エキスパート」ではない。

　まさに、開発者自身がドメイン・エキスパートでなければ、システム設計などまともにできないということだ。開発者自身の「業務システムのあり方に関する一般的知識」が大量に援用されなければ先に進まない。それに比べたら、私たちが大好きなプログラミングの知識なんてものは、ガッカリするほど基礎的な事柄でしかない。

　だからこそ、標準問題の原文からスクラッチモデリングして比較することに意味がある。「業務システムのエンジニア」として足りない点に気づけるからだ。最初は皆が素人なのだから、しみじみと引け目を感じて成長のきっかけにすればいい。標準問題は、そんな貴重な経験のための安全で温和な機会をもたらしてくれる。それが上級者にとっても意義深いことは言うまでもない。上級者といっても個々の経験が特殊であるゆえに、専門家としての知識の広がり方には凹凸がある。標準問題を解いて比較することで、自分の欠落を効率的に補える。

　そういうわけで、公開されたモデルを精査する前に、ぜひ「花束問題」を読んで自分なりにモデルを描いてほしい。そのうえで、誰かがまとめたモデルと比較してほしい。そうすることで、各手法の特性と上級者の知見とを同時に学べるからだ。

このブログでの参考記事：
「ドメイン・エキスパート」になろう