« ユーザがなかなか仕様を決めてくれないって? | トップページ | 要件を要件として深追いしてはいけない »

2005.12.10

分析設計手法のスタイルとオフショアの脅威

顧客との打合せの場でどんどんモデリングするやり方を「その場方式」と筆者は呼んでいる。いっぽう、ユーザからヒアリングしたことをメモして持ち帰って机上でモデリングして、次回の打合せでその結果を示して検討するやり方を「持ち帰り方式」と呼んでいる。「持ち帰り方式」で対応できる案件も一定の比率で存在するので、そればかりを受注できる職場にいるのなら「その場方式」を身につける必要はない。しかし、「持ち帰り方式」の実践者はオフショアの脅威にさらされていることを知っておいたほうがいい。

◆スクラッチ案件とリプレース案件

 「持ち帰り方式」が有効なのは、メインフレームのオープン化プロジェクトを典型とする「リプレース案件」だ。顧客の生の声よりも、既存のコンピュータ内部のあり方をじっくり調査することで新システムを構想できる。もともと使っていたシステムが使いやすいものだったのであれば、新システムは「建材の刷新された住み馴れた家」として顧客に受け入れられる。これはこれで経済の一翼を担う開発案件といえる。

 いっぽうの「その場方式」が効果を発揮する案件のタイプは上とはまったく異なる。レファレンスがない新規事業とか、レファレンスがあっても陳腐化が進行しているような既存事業向けの開発案件(「スクラッチ案件」と呼ぼう)だ。この種の案件の上流工程を「持ち帰り方式」で進めるのは現実的ではない。前回のエントリで書いたように、顧客の曖昧な要望と設計者の専門性にもとづいて、高速に試行錯誤されつつシステムの姿が構想されなければならない。

 問題は2つのタイプの中間に置かれるような案件をどう扱うかである。レファレンスとしての現行システムは存在するがそこそこガタが来ていて、その構造を完全に捨てるほどでもないがこのままでも使いづらい。システムの部分(モジュール)毎にも状況が異なる。そのように微妙な案件はじつは少なくない。

 以前のエントリー(「レガシーの呪いを解くには勇気が必要だ」)でも書いたように、それらのモジュールをスクラッチするかリプレースするかについては「スクラッチすることで得られるモジュールの使い易さ」を取るか「システム移行の楽さ」を取るかでだいたい決まる。「リプレースすることで持ち越されるモジュールの使いづらさ」と「システム移行の辛さ」のどちらを引き受けるかという問題でもある。他にも、スクラッチ案件では担当者が仕様を最後までまとめきれない恐れがあるし、リプレース案件では構成上のわかりにくさが増すものなので開発企業によって保守フェーズが囲い込まれる恐れをも考慮しなければならない。

 その判断は簡単なことではないが、顧客の意向で決まるという意味では単純な問題ではある。「移行がしんどいのはイヤだからリプレースしてくれ」と要望されたならスクラッチすべきではないし、「移行がしんどくてもいいからスクラッチしてくれ」と要望されたならリプレースすべきではない。それぞれのタイプの長所と短所とを事前に示して、顧客としての方針を明らかにしておいてもらうことが肝要だ。

 2つのタイプの案件の比率に関して言えば、業務システム開発の業界全体として見ればどちらかといえばリプレース案件が多いような気はする。しかし、スクラッチ案件にも無視できない市場規模がある。筆者がこれまでに関わったものはたまたま8割方がスクラッチ的な案件だったので、開発会社毎にどちらのタイプを好むかの違いはあるのかもしれない。

◆技術者個人にとってのリプレース案件のリスク

 そこまではべつに問題はない。いろいろな開発企業があって、それぞれの役割があるというだけの話だ。しかし、これを設計者個人の職業的見通しの観点で見るとなかなか悩ましい。「持ち帰り方式」はユーザとのダイナミックなやりとりが要らないし深い経験も要らないゆえに、インドや中国の技術者でも担当できるからだ。上流工程だからオフショアの脅威がないなんてことじゃないんである。

 「持ち帰り方式」をことさら取り上げて説明したが、これを「人間との直接のやりとりが希薄であるような分析的手法」として一般化しても同じことが言える。ユーザ以外の何らかの素材があって、その内容を設計情報に機械的に置き換える。スクラッチ案件の上流工程向けにそのようなプロセスが確立され得るとは筆者には思えないが、リプレース案件向けであれば可能だろう。

 成果物に属人性が出にくく、また習得も容易であるような機械的プロセスが確立されたなら、開発企業は優秀な外国人技術者を活用してコストを下げようとするものだ。完全に彼らに代替可能とはいえないにせよ、そこで働く日本人技術者は早くも上流工程の段階から外国人と協業することになる。優秀な外国人技術者とつきあうことは有意義ではあろうが、彼らに伍して自分の雇用意義を示し続けなければいけないという相当にストレスフルな状況には違いない。そのことを理解したうえで、リプレース案件を主体とする開発企業や「持ち帰り」が許される分析設計手法とはつきあったほうがいい。

 ちなみに筆者はスクラッチ案件に強く惹かれるが、それはオフショアの脅威から身を守るためなんかではない。単に「その場方式」でのユーザとの丁々発止のやりとりが楽しいからだ。もし読者にそのような交流を好む性格傾向があるのなら、オフショアの脅威云々なんかはべつとして、このスタイルをお勧めしたい。

|

« ユーザがなかなか仕様を決めてくれないって? | トップページ | 要件を要件として深追いしてはいけない »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 分析設計手法のスタイルとオフショアの脅威:

« ユーザがなかなか仕様を決めてくれないって? | トップページ | 要件を要件として深追いしてはいけない »