【2024】【経営者学びのネタ】システム発注＜要件定義のコツ＞

前々回、前回に渡り「システム発注」をテーマにIT投資の基本的な考え方や外注先を選ぶ際のポイ ントなどをご紹介してまいりました。

3回目となる今回は、どのようなシステムをつくるのか決めて外注先に伝えるプロセス「要件定義」 についてお話しいたします。

【システム発注】

• (1)IT投資の基本的な考え方
• (2)外注先選びのポイント
• (3)要件定義のコツ

システム発注:要件定義のコツ

要件定義は重要なプロセスで、システムに必要な仕様を明確にできないと「作っても、使われな い」「余計にお金がかかってしまった」という事態に陥りかねません。システムに必要な機能を 知っているのは誰よりも自分たち自身のはずですから、ベンダーに丸投げせず関係者が“自分ごと” として要件定義を進めて行くことが肝要です。

<初動は素早く>

「思い立ったが吉日」という言葉がありますが、システム発注に関してもこれが当てはまります。 システム投資の予算が確保できており、めぼしい外注先がある状態でシステム導入のニーズが社内 にあれば、すぐにいくつかのベンダーに相談をもちかけましょう。 数百万円程度の発注でも、納期は3カ月くらい先になることが普通ですから、初動は早いにこした ことはありません。システム発注は既成品のソフトウェアを購入するのとはわけが違い、必要な
仕様を決めて、実際に開発をして、きちんと使えるまで作り込むプロセスがあってはじめて役に立 つようになります。

要件定義にあたっては「お金と手間と時間をかけてつくるものだ」という認識を関係者にしっかりと共有し、外注先にお任せという状態を避けなければ、成功はおぼつきません。

<本当に必要? と問い続ける>

要件定義を始めるにあたっての最初のプロセスは事業責任者へのヒヤリングになります。どのよ うな業務課題があって、それをどのようにシステムで解決できるかを明確にしていくわけですが、 ここで注意すべき「本当にシステムが必要か?」と確認し続けることです。

上司から「システムを入れるか?」と言われてスタートすると、事業責任者は「システムを入れな ければならない」と考えがちです。しかし、本来は「根本的な課題は何か? それはシステムで解 決可能か?」を精査するプロセスが初回のアプローチとなります。

例えば「営業チームの人数が増えて“ほうれんそう”が疎かになっている」という課題に対して、シ ステムやアプリケーションありきで話を進めてしまうと本質的な課題解決にならない可能性があ ります。仮に、きちんとした報告がなされない理由が「怒りっぽい上司がいて、部下たちが萎縮し ている」ということであれば、新たにシステムを導入しても報告が上がらない状況は変わらないで しょう。

一方、受注するベンダー側としては「システムが必要ない」という判断をしてしまうと案件(売上) を失うことになるため「システムありき」「アプリありき」で話を進めることが普通です。私が以 前に「安心してお任せできる外注先というのは残念なことに全体の1、2割程度」とお話しした理 由はここにあります。目の前にある案件を無くしてでも、取引先の立場で「今の御社の課題を解 決するために本当に必要なのはシステム化ではないと思います」と言えるベンダーは極めて少ない、 ということは覚えておかなければなりません。

また、要件定義にあたっては、「システムがあればなんとかなるんでしょ?」「アプリを導入すれ ば良くなるんだよね?」という考え方は良くありません。あくまでも、本質的に必要なのは「業 務課題の解決」であり、そのために複数の選択肢がある中でシステム化を選ぶのが最適なのかを 考え続けるようにしましょう。

<社内を巻き込む>

システム化の必要性をゼロベースで考えた結果「要る」という判断になった場合、次に重要になっ てくるのは現場の“巻き込み”です。

現場が「社長が言ってるから、何かシステムが入るんだよね?」という程度の認識のまま事が進 むのは望ましくありません。プロジェクトマネージャーは要件定義の早い段階から「システムの利 用者は誰か」を徹底的に洗い出して、関係者からのヒヤリングや部署間のすり合わせをしておき ましょう。

また、ヒヤリングの際は役職に関わらず、業務の中で重要な役割を担っている人や、ITリテラシー の高い人を巻き込んでいくことも重要です。要件定義にあたり、部署全員の要望を聞くのが望まし いですが、すべての要望を実現しきれないというのも事実です。そこで、実際にスムーズに現場に 導入するために業務のキーになっている人や、新しい作業手順を真っ先に理解して広めてくれるよ うな人の要望を反映しておくことも必要になります。

<まとめ:要件定義のコツについて>

「家は3回つくりなおさないと、希望通りにならない」という話を聞いたことがありますが、IT投 資も似ていると思います。高い水準で要件定義を行ない、優秀なベンダーに発注しても、最初から 100%完璧なシステムを作り出す事は難しいでしょう。

まったく使われないシステムを作ってしまうような大失敗は論外ですが、きちんとシステム化が必 要かをゼロベースで考えた後、現場を巻き込んで要件定義をした結果、それでもシステムができた 後に「この機能を足してほしい」「この機能は削れる」という話が出てくるのは仕方がありませ ん。それを恐れず立ち止まってしまうより、まず作って改善していくという思い切りの良さも大 切です。

システム発注に関しては、回数が増えれば精度が上がるので、ある程度の失敗は許容しながら前に 進んで行くほうが関係者のITリテラシー高まり、結果としてシステム化が業務改善に貢献できる割 合も高くなると言えるでしょう。

これで、「システム発注」をテーマにした3回の内容は終了です。次回からは「エンジニアの採 用」をテーマにお話しをさせていただく予定ですので、ご期待ください。