全6425文字
PR

 ITの仕事をしているあなたの実家の隣に花屋があるとしよう。子供のころから知っている花屋の若奥さんから次のように頼まれたらあなたはどうするか。

 「お母さんに聞いたけれどコンピューターのお仕事をやっているのですって。花が余ってしまうので困っているの。何とかならないかしら。PCが1台遊んでいるから自由に使っていいわ」

 若奥さんを助けられないなら、設計手法やプログラミングを学んだ意味がなかったことにならないか。

設計手法やプログラミングを学ぶ目的は何か

 我々ITの技術者が設計手法やプログラミングを学ぶ目的は、お客さんの業務上の困りごとを解決すること。筆者はこう考える。プログラムを作るのは確かに楽しいがそれが目的となるのは趣味としてのプログラミングではないだろうか。

 若奥さんを助けるにはまず、普段どういう手順で花屋の仕事をしているのかをヒアリングして現状業務の問題を洗い出し、あるべき姿を考え、現状とのギャップを整理する。そのギャップを埋める新たな業務を設計し、説明する。若奥さんの了解を得てからシステムを開発し、それを使って業務をこなし、問題を解決してもらう。

 図にすると次の流れになる。問題やギャップを分析していくと、本当のお困りごとがどこにあるのか分かって来る。ここまでを問題領域と呼ぶ。改善策となる新たな業務を設計し、解決へ向かう。こちらを解決領域という。必ず一度分析し、抽象化してから解決策を考える。現実の問題から直接、解決策を考えたくなるかもしれないが、問題を裏返しただけの対症療法になりがちだし、解決領域のシステムをつくれない。

 データモデリングの「TM(T字形ER手法)」を考案された佐藤正美氏は「事業過程と管理過程」と言っているが同じ趣旨である。佐藤氏に話を伺ったところ、「その企業が何を管理したいのか、という視点からデータを集める」と分かり易く解説された。

図 問題解決への道筋
図 問題解決への道筋
[画像のクリックで拡大表示]

 業務を分析し、設計することは奥深く、しかも面白い。にもかかわらず業務のことは苦手という技術者にしばしば出会う。面白さをどうしたら分かってもらえるだろうかと考えて作ったのが今回紹介する「花束問題」である。簡単にまとめると次のようになる。

(1)花屋さんがWebショップを開設した

(2)順調に受注があるのに利益が伸びていない

(3)廃棄する花が多いためだろう

(4)効率的に仕入れ、販売できる業務システムを構築してほしい

 この設定をできる限り解釈の余地が少なくなるように、ユーザー要件として文書にまとめた。まず「事業と問題の概要」と題して次のように書いた。

 「当初は受注も少なく手作業で管理できていたが、受注が増えるにつれシステム化の必要性が出てきた。『新鮮な花を大切な記念日に』を売り文句にしていることもあって、廃棄される在庫が多く、受注の増加にともなって利益が伸びていないため」

簡単に見えるが実は難しい花束問題

 花束問題の全文は筆者が理事長をしているNPO法人、IT勉強宴会のサイトで公開している。「花束配送問題(V1.2)」で検索いただければすぐ見つかる。筆者と渡辺幸三氏(ディービーコンセプト)で作ったもので問題のレベルを次のように設定している。

・IT技術者としてちょっと自信を持っている方なら一読して「簡単だ」と思える。

・ところが業務を設計した経験がないと、どこから手を付けていいか分かりにくい