道具としてのExcel活用

システム開発を依頼する側（ユーザー）の立場

システム開発は、ユーザー固有の業務に対し、何らかの情報システム的な支援を行う目的で行われます。
別の言い方をすると、固有ではない業務（例：一般的な経理処理）については、パッケージもので十分なので、わざわざオーダーメイドで開発をする必要がありません。
ところが、「今こうしている」という説明や資料だけで、「あとはお任せ」というスタイルのお客様が、ごくまれにいらっしゃいます。いわく、「わからないところは質問すれば答えるから、自分の頭で考えるべき」ということです。

お金を払うのだからしっかり働け、という主旨のようであり、そうした価値観自体を真っ向から否定するわけではないのですが、このようなやり方は一見お客さんに親切に見えて、実はとんでもない結果に繋がりかねません。

寓話で共有する、システム要求の出し方

１．身近な例で、「質問ベースでシステム開発を進める」のデメリットを説明

「システム開発」と言葉自体、専門的なイメージが先行し、自分には関係ないことと思われがちです。
そこで、もう少し身近な例で、寓話的に前述のような「質問を組み立てて完成させる」方式の課題を説明できるよう、以下のような寓話で説明することにしました。

２．菓子職人が外国の機械メーカーに製造装置を依頼する

情報システムの開発は、例えるなら「職人と機械設計者の協働」によく似ています。
たとえば、ある菓子職人が金平糖をもとに独自の新しいタイプの菓子を発案し、ベトナムの機械会社に量産機械の作成を依頼したとします。
その際、現状のレシピを基に口頭で補足説明し、金平糖を見たことがない設計者に試作品を2つ渡し、「わからないことがあれば質問してください」とだけ伝えました。

すると後日、設計者からは次々と質問が届きます。
「粒の表面はツルツルですか？」「混ぜるスピードは毎回一定にしますか？」
「味付けは加熱前？それとも後？」「角ができる仕組みは何でしょう？」
さらには、「効率を上げるために二倍速で回してもいいですか？」など、
一見まっとうな質問の中に、方向違いのものまで混じってきました。

こうしたやり取りが増えるほど、回答する職人も質問する設計側も疲弊します。
そして肝心の「着色材を後から加える」工程の重要性や、「量産といえば1日数千個が常識」といった基本的な前提は、結局どこにも記録されず、色づけができない、1時間に30個しか作れないといった結果になりかねません。これはまさに“合成の誤謬”です。

システム開発もこれと同じで、業務の背景や意図（何を重視するか）を十分に共有しないと、期待と結果の間に“見えないズレ”が生じやすくなります。
このため、背景・運用・目的をできるだけ当事者の立場から具体的に資料化・ご説明いただくことが、プロジェクト成功の最短経路となります。

果たして伝わるか・・・？

ここ7年以上、お客さんから仕様の提供を断られることはありませんでしたが、不幸にして8年目にして「資料を基に、自分で質問をして仕様をまとめよ」として9ヶ月も放置された挙げ句、解約に至ってしまいました。ユーザ側から仕様を出して貰わないとわからない、ということが伝わらなかったようです。

もちろん、開発側が努力して何とかなるなら頑張るのですが（ただし、費用は上がります）、今回のケースでは、
・仕訳日計表を自動作成する　→　当然1日単位で処理が完結しなければならない（経理一般の常識）
・ところで、渡された資料では、複数日の仕訳日計表が存在した
・そのうち8月30日のものが含まれていた事に対し、「月末でまとめることが読み取れなければならない」とのご主張（当事者の常識）
という流れでした。
サンプルでは1月～8月までの日付があるので、たまたま8月30日のものが含まれていたからと言って、「月末に集計する」という発想がそもそも出てきませんし、8月の月末は31日です。

とは言え、お客さんは「いつもこのルールでやっているから当然」となります。

一方、経理の一般ルールを知っている立場としては、仕訳”日計”表を月単位で作る、と言う発想がそもそも浮かびません。「決算を数年に1度行う」のと同じです。先の寓話の通り、発想が浮かばないものは、質問が組み立てられないのです。

こうしたすれ違いを今後根絶させるためには、あらゆる手段をつかって、当事者から伝える必然姓の理解に努めるしかありません。

この反省から、もう少し身近な例で、当事者が肝心なことを伝えないと、双方が労多くして不合理な結果になることを伝えたいのですが、果たして伝わるかどうか・・・今後15年以上、同種のトラブルが防げることを期待するばかりです。

以上、自省を込めて、記録まで。