« XEADがX-TEAとして再登場 | トップページ | 入出力定義と「非対話型業務」の関係 »

2015.07.31

動くシステムを営業段階で示せるか

 先日ある技術者とビールを飲みながら、興味深い話を聞いた。某有名SIerで働く彼はなじみの顧客から、ある開発案件に対して別のベンダーから提示された見積額が妥当かどうかを検証してほしい、と相談されたという。

 さっそく彼は客先でシステムの仕様をヒアリングしてから、XEAD Modelerでざっとモデリングしてみたそうだ。というのも彼は、職場の仲間とXEAD(現X-TEA)の勉強会をしばらく前からやっていたからだ。それで、モデルがいい感じでまとまったし小振りなシステムだったので、モデルをXEAD Editorにインポートしてたちまち実装してしまった。その後に客先に出向いて「どう考えてもそれほどはかかりません。私たちならその半額でも請けますね」と説明したという。

 なにしろ実際にシステムを動かしながらの説明だったので、効果は絶大である。ただし今回は案件獲得のためではなく、セカンドオピニオンの提供のためではあったのだが、「ここまで作り込んで検証してくれたのか」と感謝されたという。また彼自身が、こういったやり方が現実に可能であることに驚いたそうだ。

 どういうやり方か。まず、営業段階で案件のモデルをざっとまとめ、それを専用エディタに取り込んで主要なテーブルとアプリの仕様書を書く。それを実行エンジンに食わせると、エンジン自身が仕様書の内容にしたがって動的に変形して立ち上がる。クラス構造など悩まなくても、また、誰かに仕様書を渡してプログラミングしてもらわなくても、動くシステムが営業段階で手に入るのである。

 営業段階でこれをやることの意義は大きい。仕様や工数の見込を安全なレベルまで持っていけるだけでなく、クライアントに対して自社の開発力をアピールできるからだ。それで受注が確定したのであれば、モデルを精密に仕上げ、自社での標準的な実装技術を使って「ホンモノ」を作って納めたらいい。もちろん、案件によってはプリプロダクションに使ったツールでそのまま仕上げたらいい。

 いっぱんにソフトウエアの仕様というものは、それが機能する社会的文脈での「問題のあり方に関する仮説」のようなものである。その仮説の有効性を測るためにいちばんいいのは、その仕様で実装して動かしてみることだ。それで問題が解決されそうならば、その仕様は問題のあり方をうまく表しているとみなせる。

 だから、ベンダーのスキルは簡単に値踏みできる。断片的な手がかりにもとづいて端正にモデリングできるか。そして、出来上がったモデルにしたがって動くソフトウエアを示せるか。営業段階でそれがやれるなら、スキルレベルについては信用できる。それに比べたら、提案金額が安いかどうかなどじつに些末な問題だ。

 ところで、ある種の方法論では、問題のありようをまずは「分析モデル」としてまとめ、これを解決するための「設計モデル」をまとめたらいいと説明される。そんな頭でっかちで俊敏さに欠けた枠組みが、はたして営業や開発の現場で通用するものなのだろうか。私の経験では、問題の構造を洞察することと、それを解決するためのソフトウエアの仕様を構想することとは、ほとんど同時に起こる。同時に起こらないとしたら、ソフトウエアでは解決できない問題だということだ。

 私の言うモデリングとは「概念モデル」とか「分析モデル」とかではなく、「動作する仕様」を構想するための過程である。そしてその仕様を実装して動かすことは、仮説検証の過程として欠かせない。方法論や実装基盤といった開発体制は、そういった一連の活動をサポートするものでなければならない。その馬脚は、営業段階で動くシステムを示せるかどうかにあらわれる。

|

« XEADがX-TEAとして再登場 | トップページ | 入出力定義と「非対話型業務」の関係 »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 動くシステムを営業段階で示せるか:

« XEADがX-TEAとして再登場 | トップページ | 入出力定義と「非対話型業務」の関係 »