書籍概要

お金をドブに捨てないシステム開発の教科書
~なぜ、要件定義がうまくいっても使えないシステムができてしまうのか?

著者
発売日
更新日

概要

家は「高額で一生ものだから」とよく考えて買うのに,なぜ中堅企業でさえ数千万から数億円になるシステム開発では思考停止してしまうのか?
なぜ,要件定義がうまくいってもまったく使えないシステムが出来上がってしまい,お金をドブに捨てるハメになってしまうのか?

システムコンサルタント兼公認会計士という異色の著者が,“稼げるシステム”の作り方を教えます。

ベンチャーから中堅企業まで50社以上,業務設計・改善から会計監査さらにIPO支援まで20年近いコンサルティング実績があるからこそ書けたノウハウが満載!

こんな方におすすめ

  • システム開発の失敗を防ぎたい情報システム部門/経営企画部担当者,経営者,ベンダーの方

著者から一言

66億円 ―― これは,上場会社の2年間の有価証券報告書,適時開示を検索して,「システム開発中止」と判断したことで被った損失額を筆者が算定した結果です。表に出てこないもの,不具合がありながら使用しているものを含めれば,金額はこの何倍にもなるでしょう。たった2年で,少し調べただけでこんなにあるのですから,日本全体でいったいいくらのお金がシステム開発によってドブに捨てられてきたのでしょうか? 考えただけでも背筋が凍ります。

もちろん,だれもお金を捨てたくて捨てているわけではありません。システム開発にたずさわる人は皆,経営や業務に役立つシステムをつくろうと真剣に取り組んでいます。それでも悲しいことに,ドブ捨て現象はいまだに後を絶ちません。

個人が住宅を買うときは,「家は高額商品で一生ものだから」といって,あれこれ情報収集して,よくよく考えて買うはずです。システム開発コストは,中堅企業でさえ数千万から数億円になります。経営を左右する大きな投資です。どうして個人で住宅を買うくらいの慎重さや配慮が,システム開発でなされないのか,ほんとうに不思議でなりません。

システム開発では,まるで関係者の思考が停止したように,とおり一遍のベルトコンベア作業で,システム会社が選ばれ,開発が始まります。そして,これまた当たり前のように,あとから要件定義の見直しや機能変更が発生して,予算超過や稼働遅延が起こります。稼働後も次から次へと修正開発がくり返され,継ぎ足しだらけになったシステムは,いずれ業者も手に負えないブラックボックスとなります。そんな見捨てられたシステムにも,企業は高い保守料を払いつづけるのです。

私はシステムコンサルタント兼公認会計士として,ERP黎明期に海外ERP・国内ERPの導入支援を行い,会計監査やIPOのかたわら上場会社,その子会社,中堅企業,ベンチャーへのシステム構築や業務設計・改善のコンサルティングを50社以上行ってきました。ブラックボックスとなった古い(レガシー)システムのリプレイス案件を手がけたことも少なくありません。

20年近いコンサルティングの中で,「どうしたらシステム開発がうまくいくのか?」「どうしたら経営やユーザーに役立つシステムができるのか?」を常に考えてきました。たどり着いた結論はたった2つです。

1つは,業務の徹底的な洗いなおし・業務改革を行うこと。
もう1つは,要件定義以前にシステム構想をきちんと練りあげることです。正確にいえば,「要件定義以前」とは,システム開発業者やパッケージを選び・発注する前となります。

つまり,個人で住宅を買うときと同じことをすればいいのです。新しい家を買う前に,どんな家がほしいかを具体的に考えるはずです。「マンションか,戸建てか?」「場所はどの辺がいいのか?」「何部屋必要なのか?」など。買ってから「ああしてほしい」「こうしてほしい」といっても,せいぜい「壁紙をどうする」とか「水回りを取り替える」など,できることは限られます。また,家財道具も新しい家にそのまま持っていくことは少ないでしょう。普通は,新しい家にふさわしいもの(サイズやデザイン)を調達します。

システム開発と住宅との大きな違いは,システムが目に見えないことです。そのため,システムの本稼働までわからないこと,気づかないことがたくさんあります。そうであれば,なおさら個人が住宅を買う以上に,システム開発では要件定義以前にいろいろと検討しなければならないはずです。

今の時代,システム構想づくりは容易なことではありません。ビジネスが多様化・複雑化し,それにともなってシステムも高機能化・大規模化しています。システムに関係する経営,業務,会計の影響範囲は格段に広がり,考慮すべきことがたくさんあります。システムの視点だけではとても満足のいくものをつくれません。経営・会計・業務・システムの4つの視点をおさえることが不可欠です。

これらのことを,本書は以下の構成で書いています。

第1章『「稼げるシステム」と「稼げないシステム」の分かれ道はどこにあるのか?』では,システム開発が失敗する典型的な事例をあげ,経営・会計・業務・システムの4つの視点をおさえたシステム構想の重要性を説明します。

第2章『[経営の視点]先を制してライバル企業に勝つ』では,経営者がシステムの進むべき道を決める大切さを説きます。そして,経営が求める情報を明らかにしたうえで,稼げるシステムに欠かせないPDCAサイクルが躍動する方法を教えます。

第3章『[会計の視点]決算を早期化して利益を稼ぎ出す』では,決算スピードと業績の関連性をデータで示し,会計のプロフェッショナルとして,確実に決算を早期化させるシステムのしくみを解説します。

第4章『[業務の視点]業務改革で会社をよみがえらせる』では,システム構想では業務改革が欠かせないこと,そして,業務改革の具体的なやり方を事例も交えて説明します。実際,私はこれで管理部門(10名弱)の業務改革でコストの50%削減プランをつくりました。

第5章『[システムの視点]正しい知識で最高のシステムをつくる』では,システムの基本構成,各サブシステム,サポートシステムの位置づけを,「亀のコウラ」を使って教えます。ERP,純国産,オールインパッケージの違いや,開発方法を選択するポイントも書きました。

第6章『プロジェクトを成功に導き,会社を飛躍させよう』では,構想づくりが失敗する原因を明らかにし,システム構想プロジェクトを確実に成功させる8つのステップを解説します。さらに,その後のシステム開発プロジェクトでは何を注意すべきか,これまでの実践で学んだことをお話しします。

本書は,経営者や経営幹部をはじめ,企業システムに関係するすべての方々(情報システム部,経営企画部,経理部,パッケージベンダー,開発業者,コンサルタントほか)のために書きました。本書を活用していただき,システム開発でお金を捨てるようなムダが少しでもなくなれば,著者としてこれ以上の喜びはありません。多くの企業でシステム開発が成功することを願っています。

目次

第1章 「稼げるシステム」と「稼げないシステム」の分かれ道はどこにあるのか?

お金をドブに捨て,競争力を落とした3社の悲劇

  • システム開発には典型的なパターンがある
  • 事例1 数千万円のシステムをあっけなく廃棄した製造業者
  • 事例2 起死回生の業務改革がまぼろしに終わった建設業者
  • 事例3 クレームだらけの新システムで業務が混乱した小売業者

最強のシステム設計図をつくるには

  • 構想がなければシステム開発はうまくいかない
  • 要件定義では「稼げるシステム」をつくれない
  • システム構想づくりはなぜ難しいのか
  • システム構想づくりを成功させる4つの視点とは

第2章 先を制してライバル企業に勝つ【経営の視点】

システムの進むべき道を決める

  • 基本方針は「攻めをおろそかにしない」こと
  • 経営者の“決意の重さ”をこめる

優れたシステムは未来を予測する

  • 経営マネージャーは,ユーザーとしての地位が低いのか?
  • 過去の情報をいかに「現在」に近づけられるか
  • リアルタイムを超える究極のマネジメント情報をつくれ
  • 予測情報はこうしてつくる
  • 予測情報で大切なことは「予測精度」と「予測モデル」とのバランス

PDCAサイクルをダイナミックに動かす

  • 「稼げるシステム」には躍動感がある
  • 情報価値は3つのポイントで劇的に高まる
  • 情報の価値を上げようとするとコストが増えるメカニズム
  • ベネフィットとコストのバランスを見極める方法

第3章 決算を早期化して利益を稼ぎ出す【会計の視点】

「決算が早い企業は稼いでいる」という事実

  • 決算の早さと業績の関係をデータから検証する
  • これだけは知っておきたい決算プロセス
  • 決算早期化にシステムが果たせる役割とは

決算を早期化できるシステムをつくるには

  • 自動仕訳には3つのタイプがある
  • 決算早期化に欠かせない5つの自動仕訳
  • 「絶対にやってはいけない」仕訳自動化の2つのまちがい

決算に必要な情報をシステムでとる

  • 内訳明細のしくみを意識してつくる
  • 会計システムの集計機能をうまく活用しよう

第4章 業務改革で会社をよみがえらせる【業務の視点】

業務改革はどのように進めればいいのか

  • なぜ,システム構想で業務改革が必要なのか
  • 業務改革は4つのステップでやる

業務の特質をおさえ,実践的な改革案をつくる

  • 業務の特質を知れば,改革は成功する
  • 特質1 業務は自己増殖する
  • 特質2 業務をやめるのは難しい
  • 改革案をつくるための3つのポイント

【事例】業務改革で管理部門の業務量を30%削減する

  • 改革プロジェクトのはじまり
  • ブレインストーミングで若手が成長する
  • 全社最適化で会社が生まれ変わる

第5章 正しい知識で最高のシステムをつくる【システムの視点】

「亀のコウラ」でシステムの基本構成を押さえる

  • システムには業務やデータの流れに沿った基本の形がある
  • 基幹系システムのわく組み
  • 会計系システムのわく組み
  • 基本構成の検討で注意すべき2つのこと

システム構想を実現する開発方法を考える

  • スクラッチ開発とパッケージシステムの違いとは
  • ERP,純国産,オールインパッケージで何が違うか
  • スクラッチとパッケージの採用比率は?
  • 利用するパッケージや開発方法はどのように判断すればいいか
  • スクラッチよりパッケージを優先すべき2つの理由

サポートシステムを活用して高みをめざす

  • 次のステージに行くカギはサポートシステムにあり
  • 進化したBIツールで情報を活用しよう
  • ワークフローシステムは事業拡大に必須
  • サブシステムとサポートシステムの役割を混同しないように

第6章 プロジェクトを成功に導き,会社を飛躍させよう

システム構想は経営の単独プロジェクトにする

  • システム構想を描く8つのステップ
  • 構想づくりが失敗する3つの原因
  • システム構想を「経営の単独プロジェクト」に切り離せ
  • システム構想プロジェクトの「体制」と「予算と期間」をどう考えるか

プロジェクトをうまく進める8つのステップ

  • ステップ1 かんたんフローで現行を調査する
  • ステップ2 方針と影響要因を整理する
  • ステップ3 システムの課題を設定する
  • ステップ4 システム構成を考える
  • ステップ5 課題に対応する
  • ステップ6 要件を整理する
  • ステップ7 システム開発計画を策定する
  • ステップ8 システム方針書をつくる

システム開発プロジェクトを成功させるポイント

  • 【選定フェーズ】ここがポイント! 提案書の見極め方
  • 【開発フェーズ】要件定義は想定力,テストは忍耐力
  • 【評価フェーズ】短期的評価と長期的評価に分ける

サポート

現在サポート情報はありません。

商品一覧