2018.09.14

「技術者とのコネ」で決まる開発の成否

 大枚を払って業務システムを刷新したのに、使いにくく保守しにくい金食い虫が生み出されただけ――これは今でもありきたりな話だ。原因のほとんどは単純で、「誰が担当したか(Who)」の問題を軽視したゆえである。すなわち、誰を主任設計者に据えたかでプロジェクトの成否はほぼ決まってしまう。言い換えれば、ユーザ企業に「腕のいいシステム開発者との個人的なコネ」がなければ、開発プロジェクトは分の悪いバクチであり続ける。

 システム要件はこんがらがった毛糸玉のようなもので、これに対する的確な仕様を構想するのは簡単な仕事ではない。そのいっぽうで、構想された仕様(それが的確であるかどうかはさておき)の実装は楽になるばかりだ。喩えるならば、「設計図にもとづいて高層ビルをヒョイヒョイッと施工するための技術」は確立されているのだが、肝心の「美しく堅牢で居住性も保守性も良好な高層ビルの設計図」を生み出すことが相変わらず難しい、といった状況である。だからこそ、ウォーターフォールかアジャイルかOOPかDSLかといった「どのようにやるか(How)」の工夫も、今や誤差程度の違いしか生み出さないのではないかとさえ私には思える。

 その結果でもあるのだが、有能な主任設計者の確保が年々困難になっている。彼らはただでさえ希少、かつ売れっ子なので、信頼できる相手が持ってくる案件の中から「良質な仕事」を選べる立場にある。つまり彼らは、合見積もりや入札を旨とする一般市場に出っ張ってゆく必要がない。一般市場に辣腕技術者がいないわけではないが、いたとしてもユーザ企業は技術者を選べない。札束を積めば、あるいは有名ベンダーと契約すれば有能な技術者にリーチできると考えるのはあまりに甘い。

 システム設計を担える人材を増やせばいいと思われるかもしれない。ところが昨今の開発業者は、せいぜいプログラミング言語やSQLのような実装作業に役立つ知識しか教えない。オーソドックスなDB設計や簿記といった重厚な基礎知識を学ばせる業者はごく稀で、必要ならば外注要員に設計させたらいいというスタンスである。学ぶ方としても、オブジェクト指向やクラス設計を理解すれば設計スキルの大枠を身につけたことになると勘違いしてしまっている。結果的に、業務システム全体を的確に設計できる要員は今や天然記念物になってしまった。

 したがって、システム開発を成功させたいとユーザ企業が本気で願うのなら、まずは天然記念物(!)との個人的なコネを作っておかねばならない。そのために、技術者が集まりそうな勉強会あたりに足しげく参加するくらいのことはやったほうがいい。懇親会で案件の概略を聴いてその場でDB構造を含めた全体構造を描き出せるような技術者がいたら幸運である。その場で見つからなかったとしても、参加者の知り合いにそんな技術者がいる可能性は低くない。有能な技術者は口コミで知られるようになるからだ。

 もちろん、相手を見つけるだけでは道半ばで、相手に気に入ってもらう必要がある。つまり、その案件が相手にとってじゅうぶん魅力的なものでなければならない。この点に関して重要なアドバイスがある。有能な技術者が嫌う案件には共通の特徴がある。「現行どおりの使い勝手」にこだわる案件を彼らは蛇蝎のように嫌う。

 なぜか。ここで言う「主任設計者の有能さ」は、「システムのあり方をゼロベースで創造することに喜びを感じる性格傾向」を基礎としている。「現行どおりの使い勝手」を新奇技術を使って再現するような作業には、そういった傾向は役に立たないどころか邪魔になる。しかもその手の案件は決まってデスマーチ化する。面白くないうえに定時で帰れない。彼らがそんな仕事にわざわざ時間を割くわけがない。

 稚拙なDB構造と非効率な業務態勢を今風のUIで化粧直ししたいだけなら、技術者とのコネなど要らない。一般市場でお金を払えば、言われた通りに作ってくれる作業員をいくらでも確保できる。ただしその先には「使いにくく保守しにくい金食い虫」が大口を開けて待っている。そんなバケモノを喜ぶのは、「現行どおりの使い勝手」で雇用が安堵された一部のエンドユーザと、新たな金食い虫の送り込みに成功した業者の社長だけだ。

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

«打ち合わせの真ん中にモデルを置こう