« 「定義すること」が苦労の始まり | トップページ | 「XEADインテグレータ」の開発 »

2007.02.12

「わかりやすいシステム」のためにオーディションを

■わかりにくさで儲ける方法

 「わかりにくさ」で儲けることができる。「オイシソウだがわかりにくい話」で相手から金品を巻き上げるという話ではなく、わかりにくくすることで(または、わかりやすくする努力の放棄によって)持続的な収入を確保できるという話だ。なにも特殊な話ではない。システム開発の世界では意図的でないにせよ、この手がよく利用される。

 コレコレの新技術を用いて革新的なシステムが手に入りますよと華々しく営業して、契約を勝ち取ってシステムを開発し、導入する。それは素晴らしいシステムかもしれないし、まあまあ使えるくらいのシステムなのかもしれないし、ガマンできないシステムかもしれない。ここで問題にしたいのはシステムの「わかりやすさ」だ。

 そのシステムは第三者が見てわかりやすいものかどうか。システムの基本骨格や機能構成から、データ項目の名称や業務マニュアルの文言まで、重層的なわかりやすさで綴られているか。そうでないとしたら、開発会社やその子飼いが保守せざるを得ない。結果的に、開発会社は継続的な収入源を確保できる。サービスレベルを低下しても、保守料金を吊り上げても、ユーザー企業はもう逃げられない。業務システムは事業活動の神経系なので、簡単には交換できないからだ。システム開発事業を「手離れが悪い」と嫌悪していた知り合いの経営者がいたが、その特性を逆手にとった形だ。

 手離れを悪くするためにわかりにくくする。そのための手段は山ほどある。その会社しか扱えないいわゆる「オレ様フレームワーク」やクセのある実装パターンを使う。適性や実務経験の不足した技術者を起用する。もっと手っ取り早く、システムをわかりやすくするための努力をなーんとなく放棄するだけでも、システムはあっという間にわかりにくくなる。ほっとけば部屋が勝手に散らかるエントロピーの法則みたいなものだ。

■主任設計者をオーディションで選ぶ

 では、ユーザー企業としてはこの問題にどのように対処したらよいのだろう。大きな開発会社に頼めば無難だろうと考えるのはアマい。開発会社の知名度や規模に関係なく、起用される技術者個人のスキルをきっちりと値踏みすべきである。なぜなら、アテになるのは基本的に、起用される個人の能力だけだからだ。ただし、プログラマを含めた全員について調べるのは現実的ではないので、「契約したら起用される予定の主任設計者」をターゲットにする。

 システム設計は歴史が浅い分、個人毎のスキルのぶれが大きい。そして、設計者同士が実務に関して批判・助言し合うようなこともない(なぜなら、彼らはとにかく忙殺されているし、ヒマであってもそんな習慣がないからだ)。また、技術者個人が多彩な開発案件を通じて設計技術を磨けるかどうかについては、企業規模は関係ない。大企業では一次請け案件が多いいっぽうで、技術者が十分な実務経験を重ねる前に管理系の仕事にまわされることが多い(だから、手練の設計者が孫請けの小さな開発会社にいたりする)。

 では、設計担当者の設計スキルをきっちり見極めておくためにはどうすればよいか。担当者の保有資格も参考になるが、資格が立派でも実務経験が不足しているケースもある。だから、口頭試問やデモンストレーションを通じた審査、すなわち「オーディション」がいい。

■オーディションで「構成力」と「業務知識」を測る

 設計スキルをオーディションするといっても、設計技術に関する専門知識は買い手側に必ずしも必要ではない。開発予定の業務分野の一部について、1~2時間かけて「その場」で設計してもらうだけでいい。ヒアリングやとりまとめの手際も悪いしホワイトボードに手書きされた図面もわかりにくいようであれば不合格。あらかじめ技術力を評価しておきたいという意図をきちんと伝えておけば、まともな開発会社ならば協力してくれるはずだ。そして、気に入った人材を見つけたのなら、契約後に確実に起用してもらえるように抜け目なく交渉しておこう。「アテ馬」の参加もあり得るからだ。

 ミュージシャンに欠かせない職業適性が「人並みでない音感」であるように、システム設計者に欠かせない職業適性は「人並みでない構成力」である。これは、わかりやすく保守しやすいシステムを手に入れるためになくてはならない。語りや文章や図解がわかりにくい人物が「わかりやすいシステム」だけは生み出せるとは考えにくい。その場で丸腰で設計させることで、そこらへんの適性はじゅうぶん明らかになる。会計を核とした業務知識の多寡も歴然とする。

 審査に前後して担当者の「設計作品」を示してもらうのも、実務能力を見るためには有効である。「守秘義務」ゆえに示せないと断られることが多いかもしれない。しかし、他人様(ひとさま)にパッと見せられる「自分の設計作品」を持たない人物が「システム設計のエキスパート」とか「アーキテクト」などと紹介されるのはそもそもおかしい。設計者自身の多彩な設計事例を一般化した「オープンデザイン作品」があってもおかしくない時代だ。OSSの流れは確実にその方向へ向かっている。

 歌手や俳優に限らず、プロの仕事師を選定するために「オーディション」や「実務による審査」は広くなされている。システム開発の世界でも、技術者が仕事にありつくためのそのような過程があるべきだ。見方を変えれば、買い手側にそういった厳しさが欠けていることが、売り手側が専門技術の向上努力を怠ることの原因にもなっている。「よくわからないシステム」は「システムのことはよくわからない」というユーザー企業側のオマカセ姿勢が生み出しているともいえる。「よくわからない」のであれば「よくわからせてくれる相手」をオーディションで選べばいいだけの話だ。

|

« 「定義すること」が苦労の始まり | トップページ | 「XEADインテグレータ」の開発 »

コメント

 インターネット系のシステムを頼むときには、代表的な仕事のURLを教えてもらう事はあります。

 リアルタイムモデリングが課題だときついですね。システム屋側から言うと、設計手法やフレームワークが決まってないと手をつけにくいので、その議論で煙に巻いて終わらせるかも知れません。

 一番わかりやすいと判断されるのは、画面/帳票設計だけをホワイトボードにさらさらと書き出す人のような気がします。それを実装出来ないと指摘されれば負けというチキンゲームですね(笑)

投稿: HAT | 2007.02.18 14:27

実装できそうにないパネルの絵を上手に描いて高い評価を受けてしまうなんてこともあり得ない話ではないのでしょうが、実際にはなかなかないと思いますね。その場でユーザと対話してユーザが納得できるようなパネルを描くというのは、十分な業務知識と開発経験なしでは無理だと思うからです。

私自身、データモデルを描かずにパネルの絵だけをどんどん描き広げてゆくことはありますが、そんなときでも、前提となるデータベースが想定可能であるように注意を払います。業務知識と開発経験を活用しつつユーザとの対話を通してパネルや帳票イメージを描ける人ならば、たいていはそんな配慮のできる技術者ではないかと思うのですがどうでしょう。

投稿: わたなべ | 2007.02.18 17:27

>ユーザとの対話を通してパネルや帳票イメージを描ける人ならば、
>たいていはそんな配慮のできる技術者ではないかと思うのですがどうでしょう。

 私の知ってる大トラブル事例のいくつかでは、美しいパネル設計だけでユーザと対話してました。それが残念ながら実装不可能だったのです。お客様もご自分の業務がちゃんとわかってなかったらしいですが。

 渡辺さんの仰るとおり、お客様の99%は発注する「会社」を選んでます。システムって結局は「人」なんですがそれがわかってるお客様は少ないです。

投稿: HAT | 2007.02.18 22:03

自分の業務がわかってないユーザですか(^^; それにしてもオーディションで「美しいパネルの絵」を描けるだけではまだ信用できないとしたら、データモデリングまでやってもらう必要がありそうです。その場合には、素人にはデータモデルを評価するのは難しいでしょうから、業界人をこっそりと試験官に混ぜておくと。やってみたいなあ、試験官(^^;

投稿: わたなべ | 2007.02.18 23:39

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「わかりやすいシステム」のためにオーディションを:

» オーディションは効果的、それだけに怖い方法だ。 [atsushifxの七転八倒]
(via 設計者の発言: 「わかりやすいシステム」のためにオーディションを) 設計担当者の設計スキルをきっちり見極めておくためにはどうすればよいか。担当者の保有資格も参考になるが、資格が立派でも実務経験が不足しているケースもある。だから、口頭試問やデモンストレ...... [続きを読む]

受信: 2007.02.14 00:24

« 「定義すること」が苦労の始まり | トップページ | 「XEADインテグレータ」の開発 »