小さな組織が必要とするシステム、それは当然大規模なものではなく、こじんまりとしたものであることが多いのは当然です。そのような企業の場合、経営者さんに言わせると「うちが必要としているシステムは、システムなどと呼ぶとおこがましいぐらい小さなもの。なんならExcelでもなんとかなるぐらいのものですよ」と説明されたりします。しかし、本当にExcelで良いならそうしているはずで、それでは立ちゆかなくなったから何らかのシステムが必要となるわけです。ところが、この「なんならExcelでも…」という矮小化した認識が大きな罠になってしまうことが多々あります。たとえば、従業員15名程度の小さなサービス業を営んでいらっしゃる社長さんにこわれて現場担当者も交えて困りごとをヒアリングしたときのこと。

社長・ご担当者：「自社のサービス販売に関する受注管理のシステムをフリーランスのソフトウェア開発者に委託して作ってもらっています。ほぼほぼ機能が完成したというので画面を見せてもらったら、受注管理の機能はありました。しかし、うちは小さいから、受注後の人が動く日程を厳密に管理しないといけないのに受注の機能しかなく、サービスを提供する日程は備考に入力してくれ、といわれたのです。当然機能の追加を要求したのですが、「できない」と頑なに言われてしまって困っています。先日納品請求まで来たのですが、このまま納品されても使い物になりません。」

とのことでした。どうやら必要な機能をきちんと伝えきれず、また、開発者からも聞かれず、概要だけで発注してしまったため、
 完成した後に齟齬が発覚した
という状態に陥った様です。このような事例は、私の経験上かなりの数になっており、小さな組織であればあるほど発生しやすいトラブルです。
では、なぜこんなことが起きてしまうのでしょうか？それは、

発注側の規模の矮小化に起因して発生する齟齬

です。「規模の矮小化」とは、「自分達が必要としている機能はこれっぽっちしかない」という自分達の物差しにより、開発側に機能要件の規模を過小判断させてしまう、という状況です。さらに「齟齬」とは以前にもこのコラムで話題にしましたが、「誤解」、「言葉の違い」、「知見の違いによるすれ違い」です。今回の例は、「自分達が要求していることは、受注の情報管理だけだ」という誤った認識を最初に開発者に植え付けてしまったが故に、一般的な受注管理だけできれば良いと開発者側が誤解し、規模が小さい案件として「まず作ってしまう」方向に動いてしまったことが原因だと考えられます。そして、「人の動く日程管理の機能が無い」と指摘されても、開発者側にとってそれは「スケジュール管理機能ですね？それは聞いていません。今回そんな機能が必要と思っていなかったので、データベースの構造上、対応するとなると作り直しに近くなります。」という状況に陥ったわけです。

こんな状況に陥らない為の方策はただ一つしかなく、「発注する方が自分達の要求をきちんと説明しきる。それも将来構想も含めて。」ということに尽きます。口で言うだけでなく、文字と図にしてきちんと「齟齬」が無い様に説明しきることです。これができなければ、どんなに小さな規模の会社でも、どんなに小さな規模のシステムでも、齟齬の発生を防止しきれず、それがトラブルに発展するとせっかくの投資をドブに捨てることになります。

上記の会社は結局納品されたシステムを使うことができず、作り直しとなりました。大規模ではないとはいえ、多大な勉強料を支払ったことになります。

自分達の考えを開発者に伝えきること。つまり、「要求事項はきちんと書面にして説明する」を正しくご理解いただき、やけどを負うことが無い様にご注意頂ければと思います。「うちは小さいから…」と言っている社長ほど危ないですよ。