「後悔しない！」、フルスクラッチ開発を委ねるシステム開発会社の選び方

「お客さまの希望通りに作ったはずなのに」──クレームに悩むシステム開発会社の憂鬱

かつて筆者は、IBM系列のLAMP(※)企業にて、営業兼PM（プロジェクトマネージャー)兼コンサルタントとして活動していた。
当時、知り合いのシステム開発会社（以下、A社とする）と、そのお客さまであるユーザー企業から相談を受けたことがあった。

「A社に開発してもらっているフルスクラッチ・システムだが、とても使いにくくて困っています」
──ユーザー企業担当者の言葉に、知己のSE（システムエンジニア）は、困惑した表情を浮かべていた。

ひと通り、ユーザー企業担当者の言い分を聞いた後、私はユーザー企業担当者を先に帰し、本件のSEから話を聞いた。
「本音を言うとね…、このお客さま、ちょっと変わった要望が多くてさ。そのため、パッケージ・システムでは、お客さまのご要望には応えきれず、フルスクラッチ開発を行うことになったんだ。ところがテストフェイズが始まって、開発したシステムをお客さま自身が確認し始めた途端、『使いにくい』を連発だよ。参っちゃうよな。うちは、お客さまの要望通りに開発しただけなのにさぁ…」

（※）LAMP
Linux、Apache、MySQL、そして、Perl、PHP、Pythonに共通する「P」の頭文字を並べたもの。ここに挙げたOpenSource系の環境や言語で開発するシステム開発会社を指す。

お客さまはシステム開発のプロではない！

お客さまの「ちょっと変わった要望」に悩まされた経験は私にもあるし、システム開発経験者であれば、誰もが一度は経験したことがあるのではないか。

● ボタンに文字は不要
「入力」「保存」などの文字があるのは、スタイリッシュではないと主張する。

● システム画面上のメニューボタンはすべて不要
ナビゲーションメニューがあることで、データ等の表示・操作スペースが狭くなるのが嫌。
操作メニューへの遷移は、Homeボタン一つあればOKと主張する。

● データ更新前の確認メッセージや更新内容の確認画面は不要
「うちの事務員は、絶対にデータ入力の間違いなどしない」ので、注意喚起のメッセージ等は時間の無駄であると主張する。

これは私が実際に出会った、お客さまからの不可思議な要望の一部である。
馬鹿げた要望と笑うことなかれ。要望したお客さまは大マジメなのだ。

お客さま（ユーザー企業）は、システム開発のプロフェッショナルではない。
だから、システム開発を生業としている側の人間からすると、ユーザビリティもシステム設計のセオリーも無視した、不可思議な要望をしてくることがある。

お客さまの要望を否定するのは、勇気を必要とする。
その瞬間だけを切り取れば、お客さまのシステム開発会社に対する評価は悪化するかもしれない。
だが本当にお客さまのことを大切にするのであれば、言うべきことは言うべきだ。
ただし、「何故その設計は駄目なのか？」という理由を、きちんと理をもって諭さなければならない。

「お客さまの要望通りに開発しただけなのに」
──このようにぼやいたSEは、残念ながらお客さまの間違った要望を正す勇気がなかったのだ。

もう一つ、このSEと、そしてA社に足りなかったものがある。
それが、BPRを行いつつ、業務の標準化を実現する能力である。

フルスクラッチを主とするシステム開発会社に不可欠なBPR能力

BPRとは、「Business Process Re-engineering」の頭文字を取ったものであり、関連する業務の見直しを行い、最適な業務プロセスを導くコンサルテーション能力を指す。

「お客さまのご要望にそったシステム開発を実現します」
──言葉は美しいが、実態はお客さまの言いなりに開発を行って恥じぬことを繕っているだけだ。

あくまで私の印象であり、肌感覚なのだが、フルスクラッチによるシステム開発を主業務としているシステム開発会社の中には、BPRを極端に苦手としている会社が少なからず存在する。

もっと言えば、システム開発に関わる人（もしくは会社）の中には、コンサルテーションとシステム開発を別物と捉えている人がいる。
これは大間違いである。不完全で非効率なままの業務プロセスをシステム化すれば、さまざまな弊害が生じる。システム化によって生産性がかえって下がることもあれば、業務改善をする上でのボトルネックになることもある。

A社のケースでは、お客さまは自分自身の要望が、「使いにくい」システムを生み出していることに気がついていない。
これは仕方ない。繰り返しになるが、お客さまは、システム開発のプロフェッショナルではないのだから。
問題は、プロフェッショナルとしてお客さまに「使いやすい」システムを提供できていないA社にある。

万能型人材に開発品質が属人化しているシステム開発会社

「お前のせいで、うちの会社は営業が育たないんだ！」
──LAMP企業に所属していた当時、私は社長から叱責されたことがある。

私の在籍していた会社は、従業員数50名ほどの小さな会社である。
既に申し上げたとおり、私は営業、PM、コンサルタントを兼務していた。他にも営業はいたものの、フルスクラッチのシステム開発案件は、私だけが担当していた。

理由は明確だった。
BPRを行いつつ、システム開発の進捗管理もこなしながら、営業活動をできる人材が、私しかいなかったからである。そして、私は私の後釜となる人材を育成することもできなかった。

デザイナーやHTMLコーダー、SEを含めた開発スタッフは、当時10名弱であった。そのリソースの大半は、私が獲得した案件に費やされていた。このような状況になったのは、私が営業成績を必死に追求した結果である。社長も、自身の言葉が理不尽であることは分かっていたと思う。
だが一方で、フルスクラッチ・システムの開発案件を、私しか担当できないというのは、経営者としては看過し難いリスクだったのだろう。

フルスクラッチに限ったことではないのだが、従業員数の少ないシステム開発会社では、得てして、かつての私のような限られた万能型人材に、システム開発のノウハウや品質が属人化しているケースがある。
そして、このような会社をお客さまであるユーザー企業側が見抜くのは、とても難しい。

営業や、システム開発のフロントに立つPMが優秀であることと、そのシステム開発会社が優秀であることは、必ずしも一致しない。
むしろ、システム開発会社側にノウハウが蓄積されていないからこそ、万能型人材が生まれてしまうという事情もある。

お客さまと接するフロントマン（営業やPM）が優秀であれば、ユーザー企業側は、会社全体が優秀だと思ってしまう。
だが実際には、その人が退社した瞬間から、それまでのサービス品質を維持できなくなり、ボロを出すシステム開発会社も多いのだ。

フルスクラッチ開発を任せるシステム開発会社を選ぶ際のチェックポイント

1.BPR能力を見極める

見極めるためには、事例をヒアリングするが早い。事例をもとに、BPR能力を備えているのかどうかを判断するのが良いだろう。

ただし、BPRを行うと言っても、程度の問題はある。ここでいうBPR能力とは、システム化される業務範囲のみに対し適切な業務整理を行うことができるかどうかであり、関連業務を含めた業務改善を求めるとなると、別の次元の話となる。

2.開発体制を見極める

少数（もしくは一人）の万能型人材に開発品質・製品品質を依存しているのではなく、企業のノウハウとして開発品質・製品品質が担保されていることを確認する。

システム開発会社選定の際には、システム開発会社側の開発体制（組織図）を必ず確認すること。そして打ち合わせには、複数の担当者に参加してもらい、業務が分担されているかどうかを確認すると良い。
もちろん、万能型人材一人だけしか打ち合わせに参加しない会社は注意したほうが良い。

3.値段だけで選ばない

フルスクラッチ開発は、パッケージ・システムに比べると、どうしても割高になる。
相場に比べて著しく安く開発を行うシステム開発会社の中には、SEはおろか、PM、営業までも外注に出していて、実は、社員は、社長と経理担当者、外注担当者など数名しかいない会社もある。
「安物買いの銭失い」にならぬよう、十分に注意して欲しい。

4.ドキュメンテーション能力を見極める

フルスクラッチ・システムは、どんなに対策を実施したところで、ブラックボックス化しがちである。それを防ぐために、システム開発会社には、仕様書（外部設計、内部設計、DB仕様書）を作成させなければならない。
ちなみに、安く上げようとして、ドキュメント作成費用を値切るのは論外だ。

システム開発会社側のドキュメンテーション能力を確認するためには、（可能であれば）過去に作成した仕様書を見せてもらうのが良い。
もっとも、これも過去開発した案件で、よくできた仕様書を出し、背伸びをしてくる可能性を排除できないのだが。

パッケージ・システムの利用を再検討することも必要

ここまで本稿に目を通してくださった方の中には、「いやぁ、フルスクラッチでシステム開発を行うって大変なんだな」と思った方もいることだろう。

そのとおりなのだ。
だからこそ、フルスクラッチ・システム開発を選択する場合には、覚悟を持って望んで欲しい。

一方で、本当にパッケージ・システムでは、貴社のニーズを満たすことができないのかどうかは、もう一度検討して欲しい。最近では、クラウド、オンプレミスを問わず、数多くの優れたシステムが巷にはあふれている。

もちろん、パッケージ・システムでは、貴社のニーズを十分に満たせないケースもあるだろう。
だが、例えば7割のニーズを満たすパッケージ・システムと、10割のニーズを満たすフルスクラッチ・システムのどちらを選択すべきかは、投資コストや将来の運用安全性（※ブラックボックス化や塩漬けリスクなど）も含めて冷静に検証していただき、判断して欲しい。

パッケージ・システムは、多くの企業で採用されている業務プロセスを、最大公約数として盛り込んでいる。
よってパッケージ・システムが提供・実現する業務プロセスは、こなれて安全性・健全性の高い業務プロセスである。
だから優れたパッケージ・システムを導入すれば、自ずと属人化を解消し、業務プロセスの標準化が実現できることも多い。

有効に活用できれば、フルスクラッチ・システムは、パッケージ・システムをはるかに上回る効果を発揮する。だが、優れたフルスクラッチ・システムを生み出すのは簡単ではないし、末永くフルスクラッチ・システムを使い続けるためには、ユーザー企業側のリテラシーや努力が不可欠だ。

フルスクラッチで望むシステムを開発するか、それともパッケージ・システムを選択するのか…
悩むあなたにとって、本稿が助けとなれば幸いである。