システムが止まるのは、技術の問題ではないことが多い
「開発会社にお願いしているのに、いつまでも完成しない」「開発会社にお願いしても、希望通りにならない」というご相談をよくいただきます。実際に中に入ってみると、技術的に難しくて止まっているケースはあまり多くありません。止まっている理由のほとんどは、「決めるべき点が明確に言語化されていない」という状態にあります。
私が関わったお客様では、数年の間、開発しては修正しての繰り返しが続いており、なかなか実運用にまで行けないというパターンが多いです。ざっくりした要求事項は出ていますが、現場の業務にしっかり即した明確な要件が決めきれていないという形です。
最初にやったのは、開発ではなく業務の棚卸し
着手してまず行うのは、コードを書くことでも詳細要件を詰めることでもなく、管理者から現場の担当者まで幅広く話を伺うことでした。誰がどの帳票をいつ作っていて、どこで手が止まっているのか。現場で実際に使われているExcelを見せてもらい、業務フローとして書き起こしたりします。
その結果、当初の要件には入っていなかった作業が複数見つかり、逆に要件に入っていたが誰も必要としていない機能も見つかりました。ここを整理しただけで、作るべきもののスコープや目的をかなり明確化できると考えています。
「全部作る、完璧に作る」をやめると、動き出す
本運用に行かない理由として「最初から完成形を作ろうとする」ことが多いです。範囲が大きいほど決めることが増え、決めることが増えるほど止まります。
そこで、フェーズをしっかり分け、「最初のリリースでは日々の入力と帳票出力だけに絞る。」など段階的に運用に向けたスケジューリングを行います。そして本運用を開始するためには最低どの部分は押さえておかないと行けないのか。を明確にします。あとから欲しくなるであろう機能は、要望として記録だけ残し、作らないと決めることも大切です。
本当に難しいのは、納品したあと
システムは納品した時点では価値を生みません。現場の方が毎日使ってくれて、初めて意味を持ちます。マニュアルを整備し、操作説明会を開き、運用が始まってからも定期的に様子を伺いました。分かりにくいと言われた画面は、その都度直しました。
「作って終わり」にしないことが、結果として一番の近道になります。もし今、開発が止まっている案件をお持ちでしたら、技術の話をする前に、業務の整理から一度ご相談ください。