提供サービス ８．情報システムの開発・導入のプロデュース
システムへの期待を図解で構造的に分かりやすく表現しシステム導入プロデュース
ユーザーの立場で、システム導入をプロデュースします。
簡単に言うと．．．
私の仕事は、一般的には「ＩＴコンサルテーション」の範疇にはいると思います。
ただ、コンサルが中心ではありません。
具体的には、このように開発を支援します
・情報システムの開発導入を行うために
・導入するユーザー側に立って
・社内のシステムに対する要求を図解でまとめま
・まとめた要求をもとに、「仕組み」としての整合性を確認し
・「要求定義」として、外部の立場で社内コンセンサスを取り
・３社程度の開発会社に提案依頼を行う
・同じ資料と同じ説明で、開発会社から提案と見積を求める
・私の関連の開発会社は入れません
（開発規模が小さい場合にのみ紹介します）
・上がってきた見積と提案を「選定基準」をもとに開発会社を一緒に選びます
・その後、導入する中小企業の立場で開発の調整役を行います
．．
と言うような作業を、導入するユーザー側に立って行動します。
■システム開発の進め方、必要なドキュメント
開発には、しっかりしたドキュメント制作が必要です！
最も重要なのは．．．
●要求定義
「〜がしたい」 利用者の希望
ビジネスで何が必要かを記述したもの
事業運用をオペレーションレベル考え
それを実現するコンピュータシステムへの要求
●要件定義
「〜が必要」システムの仕様書
システムが何をしなければならないかを記述したもの
システムの機能やＤＢ・通信などの利用方法など
導入企業の要求を理想としてまとめたものが「要求定義」です。
それをもとに、現実化の作業を行った結果が「要件定義」です。
この、右の進め方で開発が進みます。
それぞれでしっかりした文書を残しておくことが
開発の・導入後のトラブルを防ぐことになります！
■要求定義がシステム開発の成果を決める
なぜ．．．
・システム開発が失敗するのか？
・仕様変更が多いのか？
・言った聞いてないのトラブルなのか？
・システムが使えないのか？
間違った「要求定義」が、システム開発の失敗の原因です！
顧客が、システムに期待している内容を具体的に
文書に体系的にまとめたものを要求定義と言います。
この要求定義が間違っていることが問題なのです。
開発技術は、要求されたことをもとにして
開発のための設計作業に入ります。
そして、要求を満たす開発を行います。
でも、その要求が間違っているのです．．
問題は、そこにあるのです。
開発者の多くは、まじめで一生懸命に仕事をします。
「要求定義」が違うと、まじめに間違った目標に向かう．．
そして、使えないシステムを作ったとクレームへ．．
■使えないシステムが作られる原因の多くは！
よくある失敗の原因は．．．
●ユーザー：コンピュータは素人ですから全面的に
お任せします使いやすいシステムを！
●ソフトハウス：コンピュータは専門家です
安心して任せてください
と、依頼企業はソフトハウスに丸投げしてしまう。
ここで問題なのは？
・ソフトハウスの技術者は、コンピュータには詳しいが
その会社の業務の素人
・最も重要な企業の業務の仕組みを
話し合う場、組織として確定する場が軽視されている
ということなのです。
決まっているのは「良いシステム、使いやすいシステム」だけ！
要するに、「要求定義」をしっかりしないで丸投げする．．
これが問題です。
この状態で、システム開発を進めてしまうと
・専門家だというから信頼したのに．．
・何度も確認したのに、いまさら違うと言われても．．
■要求定義と要件定義の違い
・要求定義
導入企業の要求を理想としてまとめたもの
理想を明示しています
・要件定義
それをもとに、現実化の作業を行った開発要件
予算・工期・手作業との分担・開発ツールなどから
現実的な開発要件を固めたもの
この２つに共通する部分は．．
ユーザーインターフェース（オペレーション）の部分です。
仕事で使うには、仕事の進め方の根幹になります。
システム開発では、設計に大きく影響します。
要するに、
オペレーションレベルで確認して進めることが必要です。
でも現実は、抽象的なレベルで確認して開発が進みます。
オペレーションレベルの図解フローで確認し
システム開発・導入後の問題を防ぎます！
■「期待」を正しく伝えられない・伝わらない構造
システム開発が失敗するのは、
・顧客に要求を取材し
・それを元に開発要件をまとめる
ことが原因です。
顧客は、自分がシステム対して
・期待していることを、認識できていない部分（抜け）があります
・認識できていても、分かりやすく表現できない部分（抜け）があります
・表現できたのですが、伝え忘れた部分（抜け）があります
・間違って伝えたことがあります
取材した、ＳＥ（システムエンジニア）は
・聞き洩らした部分（抜け）があります
・間違って聞いた部分があります
・正しく理解した部分があります
というように、だんだん情報が抜けて、間違いが重なっていきます。
上図の右下の破線の部分の
・間違い
・理解した部分
を使ってシステム開発のための「要件定義」を行います。
当然、顧客の真意・期待とは違ってきます。
ここに問題があります。
図解を使って要素と関係を整理すると
・抜けている部分
・間違っている部分
・期待を超える部分
を見えるようにできます。
見えたら
・よく聴いて
・質問して
・提案して
どんどん要求の内容の完成度を高めていきます。
■システム開発に必要な２つのアプローチ
１．ビジネス
ビジネスの仕組みを設計
システムを導入すると仕事の仕方が大きく変わります
ユーザーの要求や現状の業務分析だけでは
新しいビジネスの仕方を構築できません
ビジネスの仕組みを構築する視点が必要です
．．．私は、この分野を担当しています。
２．システム
情報システムの設計・構築
従来のＳＥとしてシステム設計・開発を進めていくことです
必要なIT技術を選びユーザーのビジネスを支える
システム環境を開発します
３．ＩＴ技術
ＩＴの専門技術の支援
ネットワークやデーターベースなどの
最新の技術をＳＥに提供することが必要です
この３つのすべてに精通している技術者はいません。
それぞれの専門家が協力しあうことが必要です。
過度な期待をしないで「得意」を活かす体制が必要！
私の、主とした役割は．．
・社内のシステム化の要求を図解でまとめる
・もれ、ダブり、整合不良を整理調整する
・足りない部分を補強する
・社内コンセンサスの調整を行う
ということで「要求定義」として確定することです。
私の特徴は、
・図解を使って具体的なレベルまで書きだす
・事業のコンセプトからオペレーションレベルまで書きだす
かなり細かくまとめるので作業時間がかかります。
取材や調整の時間もかかります。
導入する中小企業に依頼していただいて行動します。
費用は、作業期間、作業規模、難易度で見積もらせていただきます。
上流工程のＳＥ単価くらいです。
業務経験の浅い技術者が増えてきました
ソフト会社は、「わが社の優秀な技術者です。」とつれてきますが．．．
コンピュータやＷＥＢに関する技術はあっても、営業、顧客管理、社内事務．．が
どのように進んでいるかが理解できない場合が多いのです。
業務を理解する経験が浅いのです。
どうなるか．．．
業務の現場を理解できないと、顧客の現場を取材して、
その取材の範囲内でシステムを設計し開発することになります。
要求されたことだけを、要求されたように実現しようとすることになります。
すると．．
開発の途中で機能の足りない部分がどんどん発覚し、追加され．．
テストの段階で、機能の整合性の不部が発覚し、変更を求められ．．
これでは使えないと、修正・修正の繰り返しになります。
こうならないために、しっかりした「要求定義」を作成することが必要です。
専門家だから、プロだからと．．．
コンピュータの専門家に、業務運用の仕組みまで
丸投げにしてしまうことが問題なのです。
導入側の立場で、システムの導入をプロデュースします。
「要求定義」を分かりやすい図解混じりの文書を作成します。
現場作業のインターフェース部分まで確立して
「要求定義」とするので時間はかかりますが、開発後のトラブルは減ります。
３社くらいのソフト開発会社に、
その要求定義を同じ説明して提案と見積もりを求めます。
その提案内容と見積もりを見比べて、評価軸を決めて１枚の比較表を作成します。
どの開発会社に依頼したら良いか、一緒に比較検討しましょう。
開発には、しっかりした要求定義の文書化が必要です！
提供サービス 一覧へ
簡単に言うと．．．
私の仕事は、一般的には「ＩＴコンサルテーション」の範疇にはいると思います。
ただ、コンサルが中心ではありません。
具体的には、このように開発を支援します
・情報システムの開発導入を行うために
・導入するユーザー側に立って
・社内のシステムに対する要求を図解でまとめま
・まとめた要求をもとに、「仕組み」としての整合性を確認し
・「要求定義」として、外部の立場で社内コンセンサスを取り
・３社程度の開発会社に提案依頼を行う
・同じ資料と同じ説明で、開発会社から提案と見積を求める
・私の関連の開発会社は入れません
（開発規模が小さい場合にのみ紹介します）
・上がってきた見積と提案を「選定基準」をもとに開発会社を一緒に選びます
・その後、導入する中小企業の立場で開発の調整役を行います
．．
と言うような作業を、導入するユーザー側に立って行動します。
■システム開発の進め方、必要なドキュメント
開発には、しっかりしたドキュメント制作が必要です！
最も重要なのは．．．
●要求定義
「〜がしたい」 利用者の希望
ビジネスで何が必要かを記述したもの
事業運用をオペレーションレベル考え
それを実現するコンピュータシステムへの要求
●要件定義
「〜が必要」システムの仕様書
システムが何をしなければならないかを記述したもの
システムの機能やＤＢ・通信などの利用方法など
導入企業の要求を理想としてまとめたものが「要求定義」です。
それをもとに、現実化の作業を行った結果が「要件定義」です。
この、右の進め方で開発が進みます。
それぞれでしっかりした文書を残しておくことが
開発の・導入後のトラブルを防ぐことになります！
■要求定義がシステム開発の成果を決める
なぜ．．．
・システム開発が失敗するのか？
・仕様変更が多いのか？
・言った聞いてないのトラブルなのか？
・システムが使えないのか？
間違った「要求定義」が、システム開発の失敗の原因です！
顧客が、システムに期待している内容を具体的に
文書に体系的にまとめたものを要求定義と言います。
この要求定義が間違っていることが問題なのです。
開発技術は、要求されたことをもとにして
開発のための設計作業に入ります。
そして、要求を満たす開発を行います。
でも、その要求が間違っているのです．．
問題は、そこにあるのです。
開発者の多くは、まじめで一生懸命に仕事をします。
「要求定義」が違うと、まじめに間違った目標に向かう．．
そして、使えないシステムを作ったとクレームへ．．
■使えないシステムが作られる原因の多くは！
よくある失敗の原因は．．．
●ユーザー：コンピュータは素人ですから全面的に
お任せします使いやすいシステムを！
●ソフトハウス：コンピュータは専門家です
安心して任せてください
と、依頼企業はソフトハウスに丸投げしてしまう。
ここで問題なのは？
・ソフトハウスの技術者は、コンピュータには詳しいが
その会社の業務の素人
・最も重要な企業の業務の仕組みを
話し合う場、組織として確定する場が軽視されている
ということなのです。
決まっているのは「良いシステム、使いやすいシステム」だけ！
要するに、「要求定義」をしっかりしないで丸投げする．．
これが問題です。
この状態で、システム開発を進めてしまうと
・専門家だというから信頼したのに．．
・何度も確認したのに、いまさら違うと言われても．．
■要求定義と要件定義の違い
・要求定義
導入企業の要求を理想としてまとめたもの
理想を明示しています
・要件定義
それをもとに、現実化の作業を行った開発要件
予算・工期・手作業との分担・開発ツールなどから
現実的な開発要件を固めたもの
この２つに共通する部分は．．
ユーザーインターフェース（オペレーション）の部分です。
仕事で使うには、仕事の進め方の根幹になります。
システム開発では、設計に大きく影響します。
要するに、
オペレーションレベルで確認して進めることが必要です。
でも現実は、抽象的なレベルで確認して開発が進みます。
オペレーションレベルの図解フローで確認し
システム開発・導入後の問題を防ぎます！
■「期待」を正しく伝えられない・伝わらない構造
システム開発が失敗するのは、
・顧客に要求を取材し
・それを元に開発要件をまとめる
ことが原因です。
顧客は、自分がシステム対して
・期待していることを、認識できていない部分（抜け）があります
・認識できていても、分かりやすく表現できない部分（抜け）があります
・表現できたのですが、伝え忘れた部分（抜け）があります
・間違って伝えたことがあります
取材した、ＳＥ（システムエンジニア）は
・聞き洩らした部分（抜け）があります
・間違って聞いた部分があります
・正しく理解した部分があります
というように、だんだん情報が抜けて、間違いが重なっていきます。
上図の右下の破線の部分の
・間違い
・理解した部分
を使ってシステム開発のための「要件定義」を行います。
当然、顧客の真意・期待とは違ってきます。
ここに問題があります。
図解を使って要素と関係を整理すると
・抜けている部分
・間違っている部分
・期待を超える部分
を見えるようにできます。
見えたら
・よく聴いて
・質問して
・提案して
どんどん要求の内容の完成度を高めていきます。
■システム開発に必要な２つのアプローチ
１．ビジネス
ビジネスの仕組みを設計
システムを導入すると仕事の仕方が大きく変わります
ユーザーの要求や現状の業務分析だけでは
新しいビジネスの仕方を構築できません
ビジネスの仕組みを構築する視点が必要です
．．．私は、この分野を担当しています。
２．システム
情報システムの設計・構築
従来のＳＥとしてシステム設計・開発を進めていくことです
必要なIT技術を選びユーザーのビジネスを支える
システム環境を開発します
３．ＩＴ技術
ＩＴの専門技術の支援
ネットワークやデーターベースなどの
最新の技術をＳＥに提供することが必要です
この３つのすべてに精通している技術者はいません。
それぞれの専門家が協力しあうことが必要です。
過度な期待をしないで「得意」を活かす体制が必要！
私の、主とした役割は．．・社内のシステム化の要求を図解でまとめる
・もれ、ダブり、整合不良を整理調整する
・足りない部分を補強する
・社内コンセンサスの調整を行う
ということで「要求定義」として確定することです。
私の特徴は、
・図解を使って具体的なレベルまで書きだす
・事業のコンセプトからオペレーションレベルまで書きだす
かなり細かくまとめるので作業時間がかかります。
取材や調整の時間もかかります。
導入する中小企業に依頼していただいて行動します。
費用は、作業期間、作業規模、難易度で見積もらせていただきます。
上流工程のＳＥ単価くらいです。
業務経験の浅い技術者が増えてきました
ソフト会社は、「わが社の優秀な技術者です。」とつれてきますが．．．
コンピュータやＷＥＢに関する技術はあっても、営業、顧客管理、社内事務．．が
どのように進んでいるかが理解できない場合が多いのです。
業務を理解する経験が浅いのです。
どうなるか．．．
業務の現場を理解できないと、顧客の現場を取材して、
その取材の範囲内でシステムを設計し開発することになります。
要求されたことだけを、要求されたように実現しようとすることになります。
すると．．
開発の途中で機能の足りない部分がどんどん発覚し、追加され．．
テストの段階で、機能の整合性の不部が発覚し、変更を求められ．．
これでは使えないと、修正・修正の繰り返しになります。
こうならないために、しっかりした「要求定義」を作成することが必要です。
専門家だから、プロだからと．．．
コンピュータの専門家に、業務運用の仕組みまで
丸投げにしてしまうことが問題なのです。
導入側の立場で、システムの導入をプロデュースします。
「要求定義」を分かりやすい図解混じりの文書を作成します。
現場作業のインターフェース部分まで確立して
「要求定義」とするので時間はかかりますが、開発後のトラブルは減ります。
３社くらいのソフト開発会社に、
その要求定義を同じ説明して提案と見積もりを求めます。
その提案内容と見積もりを見比べて、評価軸を決めて１枚の比較表を作成します。
どの開発会社に依頼したら良いか、一緒に比較検討しましょう。
開発には、しっかりした要求定義の文書化が必要です！提供サービス 一覧へ
info@teoria.co.jp