« モデリングツールとExcel仕様書の合わせ技 | トップページ | 設計情報のバージョン管理を合理化する »

2015.09.07

「八合目キャンプ」からのアジャイル

 「花束問題V1.2」の実装版を公開した。完成していない部分が残っているが、基本的な流れ(商品登録→発注・入荷→受注・出荷→在庫廃棄)は理解してもらえるだろう。後掲のイベントまではもっと作り込んでから再アップするつもりである。

 花束のネット販売向けの事業管理システムで、テーブル数36本、機能数110本と小振りだが、その要件を侮ってはいけない。花束の構成品である「単品」の廃棄量を減らすことに貢献すること――これは想像以上にややこしい要件で、安易な枠組みでは達成できない。在庫管理の知見にもとづく相応のDB設計とアプリ設計と業務設計が求められる。詳細についてはダウンロードして確認してほしい。

 例によって、実装の過程でもともとのモデルにいろいろと手を加えた。大きな変更としては、廃棄管理のための枠組みを精緻化するとともに、ロットや買掛の振替向けのテーブルや管理機能を追加した。他にもこまごまと加筆訂正した。やはり、実装してみないと気づかない点があるものだ。

 このような経験を重ねてますます確信することがある。実際の動作を確認しない限り、基本設計(モデリング)が完了したとは言えないのではないか。私のような古株でさえそうなのだから、それをせずに基本設計が適切であると確信できる技術者は、天才かオメデタイかのどちらかであろう。そして、確信が持てないままに基本設計を終えることが無責任過ぎるゆえに、少なくとも基本的な流れに関わる部分については実装して動きを確認しておかねばならない。

 とは言うものの、どうせ変わるのだから、事前にじっくりモデリングすること(データモデル、業務モデル、機能モデルをまとめること)が重要でないという気はまったくない。変わったといってもこの程度で済んだのは、元になるモデルの完成度がじゅうぶんに高かったからだ。

 システム開発を8000メートル級の山に登ることに喩えるなら、モデリングは「八合目にたどり着いてそこにキャンプを設営するまでの過程」に相当する。そこで装備や体力を整えたうえで頂上にアタックするわけで、その「ラストワンマイル」が実装フェーズなのだと考えたほうがいい。だから、アジャイルだからといきなり実装から始めるのは、麓から軽装のままいきなり山頂を目指して歩き出すようなものだ。夏の富士山なら可能かもしれないが、8000メートル級相手では無謀である。

 そして、実装フェーズに移る前にモデルの動作を確認しておくことは、キャンプから先遣隊を送って、頂上までのルートを事前に見極めておくようなことなのだろう。プロジェクトが八合目に留まっていることに変わりはないが、登頂の確度は格段に高まる。

 ただし、先遣隊や本隊が「丸腰」で、つまり、アジャイル本で勧められるように「コーディング主体」で歩みを進めるようでは芸がない。ソフトウエアの構築には、飛行機やビルと違って「資材」が要らない。まさにそれゆえに、業務システムは「モデル(設計情報)による動作確認」が可能である。この特性を生かした仕掛けは、デスゾーンで活動するための酸素ボンベのようなもので、この種の装備はどんどん取り入れたほうがいい。システム開発プロジェクトはわくわくするような冒険としてではなく、日常的な手順のまとまりとして遂行される。そのために命を賭す必要などないからだ。

 山頂にプロジェクトの旗を立てて淡々と生還する。そのために、実装フェーズに移る前の「モデリング」と「モデルによる動作確認」を励行しよう。これらの手順や装備をないがしろにするための言い訳が「アジャイルだから」であってはならない。八合目キャンプを設営できた堅実なプロジェクトだけに与えられる特権、それが私にとってのアジャイルである。


◆イベントのお知らせ◆
実装!花束問題<超高速開発コミュニティ&第44回IT勉強宴会>
2015/09/19(土曜日)13:00~17:00@新大阪
5つの超高速開発ツール(X-TEA,Talon,Salesforce,楽々FW,Wagby)による同一実装課題の大競演。「モデルによる動作確認」の粋を体感しよう。

|

« モデリングツールとExcel仕様書の合わせ技 | トップページ | 設計情報のバージョン管理を合理化する »

コメント

いつも貴重なブログを拝見させていただき、大変勉強になります。
さて、ブログのコメントでこんな質問というか相談をさせていただいていいのかどうかわかりませんが、
今抱えてる案件でモデリングに悩んでる案件があります。。
倉庫業様の入出庫管理の案件なのですが、渡辺様の本などを拝読して入荷予定から出荷までのながれをサンプルなどで拝見させていただいてすごく納得がいき、このまま使えばいいと思うのですが、、
とりあえずスタートするには現場の対応できる範囲でのスタートとなり、
「ロット管理やロケーション管理」ができていて「入荷予定」「出荷予定」の管理できる倉庫と
とりあえず「入出庫実績」のみ入力し保管料請求のためだけの資料をだしたい倉庫と二極化されています。
要望としては両方同じデータモデルでユーザーインターフェイスのみ仕様を分けて運用したいということなのですが、
(後々、ロット管理やロケーション管理をできるように)
データのモデリングは渡辺様の著書のように「あるべき姿」のモデリングで、入出庫実績のみ入力する倉庫に関しては、入出庫実績入力時に入荷予定、出荷予定データを自動発生させようかと思ってます。
これはベストではありませんがベターな選択といえるのでしょうか??
ほかに何か方法はございますでしょうか??

投稿: 上原 | 2015.10.02 16:28

上原さま

倉庫業者と契約している場合、倉庫別に管理レベルが違うというのはよくある話ですね。基本的には「ややこしい方に寄せる」のが妥当なので、上原さんが考えるように設計して良いと思います。あと、すでに工夫されているかと思いますが、倉庫に「固定ロケ№」や「固定ロット№」を属性として持たせることで、その倉庫向けの入出力実績も作りやすくなるでしょう。そのうえで「ロケ管理もロット管理もやる倉庫」と「ロケ管理だけやる倉庫(ロット№固定)」と「ロット管理だけやる倉庫(ロケ№固定)」と「ロケもロットも管理しない倉庫(ロット№とロケ№固定)」のバリエーション向けに、何パターンのUIを用意するかが工夫のしどころですね。ここらへんは「複雑なデータモデル上でUIをいかに簡略化するか」という一般的な問題をはらんでいるので、ブログ記事としてまとめてみたいと思います。

投稿: わたなべ | 2015.10.03 11:56

渡辺様ありがとうございます!!返信していただけただけでもありがたいのに、ブログの記事に扱っていただけるなんて本当にありがとうございます。
たぶん、悩みどころは、入出庫実績入力のみの倉庫のデータの発生の仕方と修正の仕方なのかな?と思ってます。ややこしいモデリングにあわせてデータの整合性を保持しようとすれば、入荷予定などのデータを実績入力時に自動発生させたり、修正時はどう扱うか?入荷見出しの扱いはどうするのか?そのあたりなのかなぁぁとぼんやり考え中です。
楽しみにしてますね!よろしくお願いします。
m(_ _)m

投稿: 上原 | 2015.10.05 17:04

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「八合目キャンプ」からのアジャイル:

« モデリングツールとExcel仕様書の合わせ技 | トップページ | 設計情報のバージョン管理を合理化する »