株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。2018年2月8日のイベントでは「お金をドブに捨てないシステム開発の教科書」を開催。
「公認会計士でシステムコンサルタント」という異色の経歴を持ち、書籍『お金をドブに捨てないシステム開発の教科書』の著者でもある中川充さんに、要件定義がうまくいっても、使えないシステムができてしまう、その問題点と解決策を紹介していただきました。そのイベントの様子をご紹介します。
■今回のイベントのポイント
・システム構想こそ、システム開発成功のカギになる
・事例：資金が6億円も悪化するシステム
・システム構想の8つのステップ、コツとツボ
システムコンサルタント・公認会計士。公認会計士中川充事務所代表。システム・業務・会計を統合し、企業経営のしくみを改革することを得意とする。上場会社、中堅企業、ベンチャーへのシステム開発や業務改革のコンサルティング実績は全国50社以上。そのほか、システム選定委員やパッケージ製品の開発助言なども行う。
システム開発失敗の理由は本当に要件定義か？
日本情報システム・ユーザー協会が実施する「ソフトウェアメトリックス調査」によれば工期遅延や総費用増大の理由は、要件定義が4割、プロジェクトマネージメントに関するものが6割という結果が示されているそうです。
要件定義は理由の4割を占めていますが、「でも、要件定義のせいだけじゃないよね」（中川さん）というのが、今回のテーマとのこと。
中川さんは冒頭で、上場企業が公開している有価証券報告書から、システムがらみで減損損失や特別損失を計上している会社をいくつか拾い上げ、紹介されました。
あるエレクトロニクス企業は、基幹システムの開発にかかった7億2千万円を減損損失に計上。その理由に「基幹システム導入の見直しを行った結果、当初想定した費用削減効果が見込まれなくなったため」と記されていました。中川さんによれば「あくまで推定ですが、買ったもののダメになり、結局稼働しないイメージ」だそうです。
ほかにも、「自社利用のソフトウェア（開発中）の一部に、システム開発の変更が生じたこと等に伴い、使用が見込まれなくなった」として8億7千万円を減損計上した医療系ホールディングス企業や、基幹システムの「導入規模・範囲を見直したため」に42億円もの損失を計上した機器メーカーもありました。
これらの原因は本当に要件定義なのでしょうか？
システム構想こそ、システム開発成功のカギになる
中川さんは、「要件定義が上手くいく ＝ 使えるシステム」とは限らない、と訴えます。
なぜなら、業務要求に基づいて要件定義が行われますが、時間の経過とともに業務要求そのものが変わることがあるからです。このとき「手戻りして修正できればいいのですが、そうはいかないケースも多い」といい、特に全社システムでは、その傾向が強いそうです。
全社システムは、関係者も部門システムに比べると格段に増えます。部門間の要求の違いや、部門間の隠れた利害の衝突が起きてしまうことも多く、単純に各部門の業務要求を寄せ集めても、全社システムの業務要求にはなりません。
こうした課題をあらかじめ見つけ出し、解決しておくことが重要だと中川さんは強調します。この工程がシステム開発を成功に導く「システム構想」なのだそうです。これはシステム開発の一環というより、ビジネスモデルを設計していくのに近いとのことでした。
システム構想においては、経営・会計・業務・システムの4つの視点が重要で、いずれかが欠けてしまうと、いくら要件定義が上手くいったとしても、後から業務要求が変わったときに、使えないシステムになってしまう危険性があります。
では、実際に後から業務要求が変わるケースとは、どのようなものがあるのでしょうか？
事例：資金が6億円も悪化するシステム？
会員向けオンラインサービスを提供している会社を例として採り上げました。
この要件に対してシステムベンダーが提示してきたのが、年払い機能の無いA案と、年払い機能ありだが予算を大幅に超えるB案でした。
年払いのパイナップル事業は売上も15億と少ないので、これを他の事業と同様の月払いに変更するというのがA案の提案ポイントです。請求データが売り上げになるので、業務もいたってシンプルになることがわかります。
B案は予算を大きくオーバーしているし、会員管理部も課金方法の変更を承諾したので、情報システム部の見解は A案でいいのでは？ と、なりかけましたが、そこには大きな問題があったのです。パイナップル事業を月払いに変更してしまうと、会社の現金が足りなくなり6.6億円も資金が悪化してしまうことが判明しました。
当然、経営者から「待った」がかかり「年払いへの変更は認められないのでB案を予算内におさめよ」という指令が下りました。
システム開発の要件で「PL（損益）まで考える人はいますが、CF（キャッシュフロー）まできちんと考える人は、あまりいません」（中川さん）
経営者の指示でしたが、B案を予算内におさめるのは金額に開きがあり難しいので、経理部も巻き込んで再検討します。そしてA案をベースにしながら、年払い分は入会月別明細を参照して、前受金を毎月手入力していく――すなわち経理部が自動仕訳の一部を諦める修正A案で落ち着きました。
システム構想の8つのステップ、コツとツボ
システム構想を要件定義の前段のフェーズと捉えるのではなく、1つのプロジェクトとして、切り離したほうがうまくいく、と中川さんは説明します。
「システム開発の流れの中に組み入れてしまうと、開発時間が足りないときに、システム構想かテストのいずれかの工程が、真っ先に切り詰められてしまう。しかし、システム構想はビジネスモデルデザインと呼ぶべきもので、通常、中堅企業でも6カ月はかかります。本当は6カ月でも足りないぐらいかもしれません。これをしっかりやるためには、システム開発プロジェクトのスケジュールに左右されないように、1つの独立したプロジェクトとしておくべきなのです」（中川さん）
システム構想は、プロジェクトとしてきちんと予算を取り、必要ならばプロトタイプでしっかりとテストを行うべきで、できれば経営企画や情報戦略部門が担当するのが好ましいそうです。プロジェクトでは、4つの視点をしっかり持つために各部門から人を集めますが、誰でも良いというわけではありません。
会計の担当はシステムと業務のことも、業務の担当はシステムと会計のことも、システムの担当は会計と業務のことも、それぞれある程度は理解している必要があるといいます。
エンジニアとして、自分が心血を注いで作り上げたシステムが、実際に使われないことほど悲しいことはありません。すでに要件定義を手掛けている人はもちろん、これから要件定義のフェーズを学んでいく人も、目の前の業務要求だけでなく、システム構想がどのようになっているのかを意識していくべきだと感じました。
