設計者の発言

　業務システムの複雑膨大な設計情報を効率的に管理するために、Excelのような汎用ツールではなく、専用のCADツール（システム開発用の設計情報管理ツール）を使おう。そのように主張しているのだが、反応はさまざまだ。もちろんほとんどの技術者が賛同するのだが、所属組織にそれを導入できるかどうかになるとビミョーだったりする。

　専用ツールを用いることの効果のひとつが、設計の巧拙がはっきりする点だ。スキルレベルの高い組織であればそれでいいだろうが、そうでない組織は現状維持を望むかもしれない。Excel方眼紙（細かい方眼紙状に設定されたExcelシート）で設計書を書くやり方は蛇蝎のように嫌われているが、それが設計の拙さを見えにくくするための隠れ蓑として役立っていることがある。彼らはExcel方眼紙がもたらす壮大な無駄を棚に上げ、「新たなツールを導入すれば、余計な学習コストがかかる。だいいち、ツールベンダーがつぶれたらどうするんだ」といろいろな理由を挙げて反対するかもしれない。

　組織の管理者が合理化を望まないケースもある。革新的技術を取り入れて、以前より少ない見積工数や低い稼働率で仕事をこなせるようになるとしたら、それに見合う程度に案件が増える必要がある。それが無理なら、利益はかえって目減りする。短期の業績について責任を負う管理者にとって、その種の合理化はしばしば傍迷惑なものだ。

　けっきょく、システム開発の合理化を進めるためのカギを持っているのは、開発企業自身ではないと考えたほうがいい。では誰なのか。――顧客である。

　そこで、顧客（業務システムの発注者）に提案したい。業者選定の過程で「設計書（仕様書）は何を使って書いていますか？」と尋ねてほしい。なぜなら設計書こそが、システムの開発者と利用者との合意点だからだ。業者が設計書をどんなやり方で作成・管理しているかについて、事前に確認してほしい。

　「Excel等の一般的なツールを使います。お客様にとっても確認しやすくて便利ですよ」と答えた業者は避けたほうがいい。落選の理由を訊かれたらこう答えよう。「私どもは、いまどきExcel方眼紙で設計された飛行機に乗るのは怖いし、Excel方眼紙で設計された業務システムを使うのも怖いんです」

　Excel等の汎用ツールを使って設計しているというのは、上述したように業者に合理化の意志がないことの表れである。非効率さに報酬を払うような真似をしたくないのであれば、この便利な指標を利用しない手はない。そうとわかれば、ただちに切り捨てよう。

　「私たちは動くソフトウエアを優先させるため、基本的に設計書は作りません。何よりも、お客さまに素早く価値をもたらすことが重要ですからね」と答えた業者も避けたほうがいい。落選の理由を訊かれたらこう答えよう。「私どもは、設計図のないビルを手に入れようとは思わないし、設計図のない業務システムを手に入れようとも思わないんです」

　じっさい、設計図のないシステムは悲惨だ。コードを読めない限り、ユーザ企業側の人々は自分たちのシステムのあり方がわからない。結果的にユーザ企業は開発業者によってロックインされる。業務システムというものは、事業の神経系であるだけでなく、事業の変化・発展に忠実に追随してゆかねばならない。その維持について特定業者に頼らねばならないというのは、事業の舵を他人に預けているようなものだ。いくら信頼しあえたとしてもユーザ企業と開発業者とは「疎結合」であるべきで、ドキュメントはそのために欠かせないインタフェースである。

　「設計書は何を使って書いていますか？」と尋ねて、知らないツールの名前を告げられたらどうすべきか。そのツールで書かれた実際の設計書を見せてもらおう。業務フローや業務マニュアルといったユーザ向けの設計書がしっかり書かれているようであれば、見込みがある。また、データモデル等の専門的な設計書にも目を通しておこう。システムの保守を開発業者以外に依頼することもあるからだ。

　同時に、ツールそのものの使い勝手も確認しておこう。使いやすいだけでなく、価格も無償か廉価であったほうがいい。なぜか。せっかく良いツールを使っているのに、納品物が編集不可だったり、xlsやpdfやjpegといったファイル形式だとしたら、効果は半減するからだ。なにしろシステムが完成した後でも保守は続くのだから、保守の担当者（担当業者）やユーザ企業自身もそのツールを活用できたほうがいい。

　システム開発のプロではない発注者が、業者のエンジニアリングスキルを値踏みする。そのためには、まずは設計情報の管理体制というごく基本的なあり方を尋ねたらよい。素人向けのオフィスツールなどではなく専門家用のエンジニアリングツールを使いこなしているようであれば、彼らは合理化に前向きだし、腕に自信を持っていると考えていい。

　しかし、これだけでは十分ではない。業者のほんとうの実力は、実際の仕事ぶりを見るまでわからない。

　そこで、見込みのある業者を何社か見つけたら、同一の参考資料を与えて、案件の一部について半日くらいかけてその場で設計・開発してもらおう。業務設計、DB設計、機能設計の手際や成果物（設計書やアプリ）を比較すれば、どの業者のスキルが高いかは素人でも判断がつく（担当者がアテ馬でないことも確認しておくこと）。

　このように開発業者の選定も、芸能界におけるオーディションや、建築業界におけるコンペのようであったほうがいい。なぜか。知名度や営業トークや価格ではなく「開発実務のスキル」をチェックするという当たり前の選定過程が、開発組織がスキルアップや合理化を進めるための強い動機になるからだ。言い古されていることだが、業者や業界を鍛えるのは賢い顧客の眼差しである。

このブログでの参考記事：
ドキュメントの山で遭難しないために