2018.02.15

業者の設計スキルをハダカにする

■設計スキルが劣悪でも稼げる世界

 システム刷新に失敗する理由のひとつが、ユーザ企業が業者の設計スキルを吟味せずに一括請負契約を結んでしまう点にある。彼らに委託すると、実際には下請業者が設計していたりする。多くの業者が多かれ少なかれゼネコン化しているため、設計スキルが空洞化しているためだ。下請業者に的確な設計が出来ないとは限らないが、起用される設計者のスキルレベルを発注者がコントロールできないという意味で、リスクが大き過ぎる。

 そもそも「システム刷新に失敗した」とはどういうことか。ユーザ企業自身が想定するコスト感やスピード感でシステムを改善・発展させられなくなっているのであれば、失敗したと判断していい。少しばかり改修しようとしても、無駄に複雑な設計を掌握している開発業者の意向に振り回される。そんな業務システムの命運は業者に握られていて、これはもう経営権の一部を奪われているのと変わらない。そんな事例は少なくない。

 なぜそういうことになるのか。ありていに言えば、業者には良い設計をする動機がないためだ。端正かつ的確な設計をすれば、開発工数が目減りするうえに、他の業者でも保守できてしまう。下請業者に平気で設計まで丸投げするのはそのためで、元請けとしてはショぼい設計が納品されてもかまわない。前回記事でも書いたように、ショぼい設計やそれにもとづく実装は、ユーザ企業から余分な工数契約を引き出し続けるための源泉だからだ。

 しかも、ほとんどのユーザ企業は設計の良し悪しを判断できないので、どんなにコストがかかっても仕方ないこととして受け入れてしまう。この話がやりきれないのは、業者がいかに良心的であっても、設計スキルが不足しているだけでエゲつなく稼ぐ悪徳業者になってしまうところだ。根本的な原因は、システムの内部構造が素人にはわかりにくいことと、それゆえに業者の腕がわからないこと、すなわち市場における「情報格差」にある。

 典型的な例なのだが、刷新案件において開発業者は、UIが現代的なわりにDB構造が混乱したままの「そっくりさんDB」を作ろうとする。ほとんどのユーザ企業は不平を言わない。結果的に、ただでさえわかりにくいシステムが、彼らにしか保守できない経営資源として生まれ変わる。彼らはDB構造の見直しは出来ないが、それが出来るようになるための理由もないのである。

 ちなみに、「そっくりさんDB」を作るのは、ユーザ企業自身が「同じ使い勝手」を望むゆえ、というのが開発業者の言い分である。しかし、使い勝手を同じにすることと混乱したDB構造を温存することとは意味が違う。使い勝手が同じだとしても、保守コストを低減させるためにDB構造の見直しは積極的になされなければいけない。そもそも使い勝手を同じにしたいという要望はエンドユーザの保身から出る我儘のようなもので、経営者がそれを望んでいるとは限らない。なによりも、システム刷新において「同じ使い勝手」を実現することがいかに無駄であるかを、業者は丁寧に伝えなければいけない。

 もちろん有能かつ良心的な業者もいるのだが、相手がどんな業者であるかがユーザ企業にはわからない。業者の食い物にされずに、ユーザ企業が安全・安価にシステムを開発・刷新するにはどうしたらいいのだろう。自社が擁する技術者だけで内製できればいちばんいいのだが、そんな態勢をとれる企業は例外的だし、辣腕技術者を見つけて雇い入れることが難しい。現実には開発業者を活用せざるを得ない。

■オーディションで剥き出しにされる実力

 そこで登場するやり方が「オーディション」だ。いくら開発業者の設計スキルが組織レベルで空洞化したといっても、的確な設計をやれる数少ない技術者は開発専業の企業に所属している。そのような技術者を自分たちで探し出して起用するためだ。

 これまでは、RFPにもとづいて「持ち帰り」で作られた提案書やプレゼンの巧拙を比較するしかなかったが、それでは業者の実力はまったく測れない。そこでオーディションでは、A4数枚のRFPを渡して「その場」で2~3時間かけてシステムを設計・実装してもらうのである。「持ち帰り」を許さないのは、下請に作らせないため、そしてオーディションに参加した技術者と直接契約するためだ。

 このようなやり方が可能になったのは、近年の実装技術の急速な発展のおかげなのだが、結果的に業者間の開発力に顕著な違いが生じつつある。合理化の努力をとっくに放棄している旧来型の業者はそのことに気づいていない。彼らは「2~3時間で作れるシステム?そんなショぼいもので業者の実力なんて測れるわけがない」とあざ笑うだろうし、仮にオーディションに参加しても本番同様のショぼいシステムしか作れないだろう。

 じっさいオーディション方式は、委託側と受託側の「情報格差」を埋めるために効果絶大だ。わずかな手がかりから動作するシステムを設計・実装するための、幅広い業務知識や想像力や創造性が求められる。データモデルや仕様書の様式を見れば、複雑膨大な設計情報の管理態勢もわかる。業務システムという「素人にはよくわからないもの」を作る業者(技術者)の実力がハダカにされる。結果を評価するためには発注側に専門知識が要りそうに思われるかもしれないが、それほどおおげさな話ではない。自分たちの要求にシャープかつエレガントに応えているかどうかを見ればよい。歌い手の実力がわからなければ、その場で歌ってもらえばいい。その歌を気に入るかどうかは「プロの歌い手」ではない発注側の問題だ。

 気に入った技術者を見つけたなら、かれを含むチームに設計とプロトタイピングとデータ移行をやってもらう。チームといっても2~3名の少数精鋭だし、彼らにきっちり働いてもらうためにも準委任契約がいい。データ移行までやってもらうのは、データモデルが絵に描いたモチでないことを確認するためだ。優れたデザインを手に入れたいと真剣に願うなら、ここまでやらねばならない。しかしここまでやりさえすれば、システム刷新のリスクもコストも桁違いに減る。

 刷新されたDBへのデータ移行が完了したなら、本番アプリの実装が始まる。プロトタイプとして作られたアプリをそのまま仕上げてもいいし、規定の実装手段を使って作ってもいい。設計チームに実装してもらうのがベストだが、それが無理ならば「アプリの実装専任」として別の業者と委託契約すればよい。DBの刷新とデータ移行は終わっているので、基本的に見積工数の少なさで選定していい。使いやすい実装手段を用いているかどうかも見よう。必要に応じて保守業者を切り替えられないのでは困るからだ。

 「オーディション&準委任契約」は、実装過程の合理化によって必然的に生まれる発注形態で、ゼネコン化した開発業者にとってはとくに脅威だ。全員がPMになることでより高い単価で人員を動かせると考えて、多くの業者がゼネコン化した。しかし、技術革新によって工数や要員数が激減すると、プロジェクト管理については主任設計者が片手間で担えるようになる。単価が高いだけのPM専任要員などお呼びでない。自分たちで設計できないので、オーディションにも参加できない。下請業者の融通という最後に残った役割も無意味になる。

 発注側にとって何より大事なのは、システム開発業者の設計スキルが空洞化して久しいという現実を受け入れることだ。彼らの設計スキルを当てにしてはいけない。知名度のある業者と契約すれば辣腕の設計者がいい仕事をしてくれる、などと考えてはいけない。それはあり得ない話ではないが、京都人と知り合えば舞子さんと仲良くなれると考えるようなものだ。本当にその気があるのなら、舞子さんを46人くらい集めてオーディションすべきだ(って無理か)。

| | コメント (0) | トラックバック (0)

«おそ松なデータベース