・ハイコンセプト
世界的ベストセラー、『ハイコンセプト「新しいこと」を考え出す人
の時代』の著者、ダニエル・ピンク氏によれば、
グローバル化とアウトソーシングの時代に生き残るためには、
理性、論理、分析力といった機能をつかさどる左脳だけでなく、
感性、感情を理解し、直感的理解を可能にする右脳を駆使する
ことが重要になるという。
（PRESIDENT 2007 3.5 より一部抜粋）
■システム開発の場合
コンピュータシステムの開発に、ハイコンセプトの概念を適用すると、
システム開発は、業務分析、プログラミングといった概念だけでなく、
関係者との人間関係、考え方、思惑などを理解し、直感的創造力を
駆使することが重要となるのでしょうか。
ところで、最近Ｗｅｂ上の記事で、「システム開発の失敗」に関連する
記事が目に付きます。
たとえば『システム開発を失敗させない“現実的な処方せん”とは？』
という記事です。（itmedia）
http://www.itmedia.co.jp/enterprise/articles/2007-2-7
この記事の冒頭に、「昨今、大規模なシステム開発の現場において
“失敗プロジェクト”が常態化していると聞く。」とあります。
「常態化」とは恐ろしい表現です。
■システム開発の特異性
建築物のような造形が無い成果物を、立場の異なる関係者と協調して
作り上げます。
以前から、システム開発も建築を例に表現されますが、規模や複雑さ
などは、建築物のようなに造形が無いのでよくわかりません。
そもそも、大規模システムは概要を理解するだけでも大変です。
そのあたりが、失敗プロジェクトを誘発させやすいのではと考えます。
■失敗の回避策
システムの発注者と受注者の間で
�ゝ’修篩犧鄒�の合意
�▲灰好箸版軸�の合意
��プロジェクトの進め方の合意
�ぅ廛蹈哀薀爐虜遒衒�の合意
�ね渋�困難の内容に対する考え方の合意
などの合意が得られれば、プロジェクトの失敗は高い確率で
回避できるかと思いますが。
■ハイ・コンセンサス
ですから、システム開発の場合、システムの発注者と受注者の間で
高い次元の合意が必要となりますから、
冒頭の『ハイコンセプト』より『ハイ・コンセンサス』がキーワードとなる
のでしょうか。
世界的ベストセラー、『ハイコンセプト「新しいこと」を考え出す人
の時代』の著者、ダニエル・ピンク氏によれば、
グローバル化とアウトソーシングの時代に生き残るためには、
理性、論理、分析力といった機能をつかさどる左脳だけでなく、
感性、感情を理解し、直感的理解を可能にする右脳を駆使する
ことが重要になるという。
（PRESIDENT 2007 3.5 より一部抜粋）
■システム開発の場合
コンピュータシステムの開発に、ハイコンセプトの概念を適用すると、
システム開発は、業務分析、プログラミングといった概念だけでなく、
関係者との人間関係、考え方、思惑などを理解し、直感的創造力を
駆使することが重要となるのでしょうか。
ところで、最近Ｗｅｂ上の記事で、「システム開発の失敗」に関連する
記事が目に付きます。
たとえば『システム開発を失敗させない“現実的な処方せん”とは？』
という記事です。（itmedia）
http://www.itmedia.co.jp/enterprise/articles/2007-2-7
この記事の冒頭に、「昨今、大規模なシステム開発の現場において
“失敗プロジェクト”が常態化していると聞く。」とあります。
「常態化」とは恐ろしい表現です。
■システム開発の特異性
建築物のような造形が無い成果物を、立場の異なる関係者と協調して
作り上げます。
以前から、システム開発も建築を例に表現されますが、規模や複雑さ
などは、建築物のようなに造形が無いのでよくわかりません。
そもそも、大規模システムは概要を理解するだけでも大変です。
そのあたりが、失敗プロジェクトを誘発させやすいのではと考えます。
■失敗の回避策
システムの発注者と受注者の間で
�ゝ’修篩犧鄒�の合意
�▲灰好箸版軸�の合意
��プロジェクトの進め方の合意
�ぅ廛蹈哀薀爐虜遒衒�の合意
�ね渋�困難の内容に対する考え方の合意
などの合意が得られれば、プロジェクトの失敗は高い確率で
回避できるかと思いますが。
■ハイ・コンセンサス
ですから、システム開発の場合、システムの発注者と受注者の間で
高い次元の合意が必要となりますから、
冒頭の『ハイコンセプト』より『ハイ・コンセンサス』がキーワードとなる
のでしょうか。
■［業務システム］と［心］
ひとつ前の記事 ［仕事］＝［考え方×心×行動］の応用で、
「業務システム」は次のように考えました。
・［業務システム］＝［考え方］×［現場の心と合意］×［機能］
最近、目にした事例で、
・１０月２９日の新聞に、『郵政公社トヨタ式に混乱 ・指導社員
「上辺だけ改善」・現場「車とは違う」・年賀状遅配の懸念』
という見出しで特集がありました。
詳細な記事は割愛しますが、要はトヨタ方式を応用した
「ＪＳＰ（ジャパン・ポスト・システム）」の導入の過程で
現場から反感を買い、期待した効果が出ず、スムーズにことが
進んでいないという内容でした。
・その日の夜にはＮＨＫスペシャルで
米国の著名な流通大手が、トヨタの「ジャストインタイム」の手法
を全面的に受け入れ、女性のブーツ販売戦略で、
中国と米国間で発注からの物流を日単位で短縮、時間単位で管理
し業績を伸ばしているというドキュメンタリー番組がありました。
共に、物流に関する「トヨタ方式」の応用なのですが、
風土やシステムの導入アプローチがポイントかと思います。
・変化を望まず安定を求める風土／システムのごり押しをする。
・変化を受け入れ成長を求める風土／システムを自ら応用し考える。
しかし、
・現場の「心」との合意が無い／指導者側が、改革に本気では無い。
・現場の「心」との合意が有る／経営者側が、改革に本気。
という見方もできるかと思います。
（新聞とテレビの情報からの推測です。本当の内情は？です。
目的、機能、関連する人は多いと思いますから単純には考えられず）
よって、イメージとしては
［業務システム］＝［考え方］×［現場の心と合意］×［機能］
こんな感じでしょうか？
（ムリがあるかなぁ？）
結果的に業務システムは、他のシステムと連携（直接/間接）し、
［システム］＝［社会インフラ］になるかと思いますが。
（世の中の業務システムが突然動かなくなると、社会は麻痺しますし。）
ひとつ前の記事 ［仕事］＝［考え方×心×行動］の応用で、
「業務システム」は次のように考えました。
・［業務システム］＝［考え方］×［現場の心と合意］×［機能］
最近、目にした事例で、
・１０月２９日の新聞に、『郵政公社トヨタ式に混乱 ・指導社員
「上辺だけ改善」・現場「車とは違う」・年賀状遅配の懸念』
という見出しで特集がありました。
詳細な記事は割愛しますが、要はトヨタ方式を応用した
「ＪＳＰ（ジャパン・ポスト・システム）」の導入の過程で
現場から反感を買い、期待した効果が出ず、スムーズにことが
進んでいないという内容でした。
・その日の夜にはＮＨＫスペシャルで
米国の著名な流通大手が、トヨタの「ジャストインタイム」の手法
を全面的に受け入れ、女性のブーツ販売戦略で、
中国と米国間で発注からの物流を日単位で短縮、時間単位で管理
し業績を伸ばしているというドキュメンタリー番組がありました。
共に、物流に関する「トヨタ方式」の応用なのですが、
風土やシステムの導入アプローチがポイントかと思います。
・変化を望まず安定を求める風土／システムのごり押しをする。
・変化を受け入れ成長を求める風土／システムを自ら応用し考える。
しかし、
・現場の「心」との合意が無い／指導者側が、改革に本気では無い。
・現場の「心」との合意が有る／経営者側が、改革に本気。
という見方もできるかと思います。
（新聞とテレビの情報からの推測です。本当の内情は？です。
目的、機能、関連する人は多いと思いますから単純には考えられず）
よって、イメージとしては
［業務システム］＝［考え方］×［現場の心と合意］×［機能］
こんな感じでしょうか？
（ムリがあるかなぁ？）
結果的に業務システムは、他のシステムと連携（直接/間接）し、
［システム］＝［社会インフラ］になるかと思いますが。
（世の中の業務システムが突然動かなくなると、社会は麻痺しますし。）
最近、「要件整理」の重要性を取り上げている記事などが目に着きます。
私も以前から仕事で気にしている内容なので、その内容を簡単に整理
してみました。
■例えば、「生産管理システム」構築時の要件整理の場合
私は、製造工場経験者で、実務で忙しい現場や管理業務にコンピュータを
導入するのは意外と難しいことは熟知していると思っています. ．．？
（詳細は割愛）
とは言っても社外の立場から、生産管理システムなどを構築する際は、
対象の固有の業務や現場作業は理解していませんから、関係者から
聞き取り（ヒアリング）し、要件を整理します。
その際、一般的に
・数人の人が使用するシステム
・多数の人が使用するシステムだが、使い方は皆ほぼ同じ
の場合は比較的簡単で、特定の関係者からのヒアリングで要件整理が
できる場合も多いのですが、
・例えば工場全体のシステムのような場合
（複数の人が使用するシステムで、イレギュラー対応も多く、
工場間の連携もある．．．）
のような場合は要注意です。
■ヒアリングによる要件整理の落とし穴
システム化の要求を整理するにあたり、関係者各々の立場での要望、
着目点、スキル、向いているところの見極めが大事かと思います。
例えば
・経営者の立場の人 ・管理者の立場の人 ・実務者の立場の人
・システムをイメージできる人できない人 ・個人的思惑．．？
など、様々な考え方を持った人からのヒアリングには、精度にも限界が
ありますし、関係する人が多くなれば本質が埋没することもあります。
また、方法論を多数決で決めればＯｋというものでもありません。
■まずは、手コンピュータで確認・検討・調整
そもそも、システムの要件整理には、下記内容を押さえていることが
前提条件となります。
�ゞ般格�析 → 今はどのようにしているか、
そして次どのようにしたいのか
�▲轡好謄牴修量榲�を具体的に定義化
�６般灰侫蹇爾寮依�
�ぅぅ譽�ュラー処理等の対応方法検討
�コ堂萍未篦�票のイメージ作成
�Τ堂萍未料犧酳�法
すなわち、業務を整理し事実として積み上げ具体的に検討し、システム
化の目的も含め、これから作る新しいシステムの使い方を机上で検討し
シミュレーションする必要があります。
（具体的なシステム化の課題等は割愛）
■キーワードは、
・要件開発 ・要件整理 ・合意の方法
・開発側とエンドユーザーとの間で、真の合意
でしょうか。
■以下、最近目にした関連記事や雑誌です。
ボーランド社のＡＬＭ製品宣伝記事に下記のような表現がありました。
開発プロジェクトが失敗する原因のトップに、要件の不正確さ、
不完全さ、要件の誤った管理がある。
また、要件の間違いは手戻り作業を引き起こす最大の原因となり、
その割合はプロジェクト全体の開発作業の40％にも及ぶという報告
がある。
問題は、これまでの開発の多くが、開発側とエンドユーザーとの
間で、真の合意が得られぬまま進められてきたことにあるのだ。
雑誌には下記のような特集がありました。
・日経ソフトウェア ２００６年９月・１０月号
「要求は開発するものである」
・日経ＳＹＳＴＥＭＳ ２００６年１１月号（ITproTechメールからの情報）
「特集１ 図解で極める要求定義」
その他、ITproTech メール 2006.10.26[要求定義を極める]から抜粋
・要件定義の方法論を知る
・ＤＯＡ型要件定義の実際 ・日本標準的な作業手順とは？
・非機能要件を見極める
・ヒアリングでは不十分 ・ひな型を使い漏れ防止
・上流工程の問題解決 要求定義編
・要求と機能の関係は？ ・うまく合意するには？
・上流工程の問題解決 仕様変更編
・仕様変更が出たときの「禁句」は？
・上流工程AtoZ
有名な書籍
・「動かないコンピュータ」という書籍は以前から有名
ところで、これらの関連記事を読むのも大変！
開発者からユーザまでわかりやすいものがあると嬉しいですが。。。
■コンピューティングの将来（業務システム）
要件開発とか要件整理の手法に関する標準化が必要かと思います。
この部分はコンピュータの技術から分離できるため、その気になれば
さほど難しくないと思いますが。。。
私も以前から仕事で気にしている内容なので、その内容を簡単に整理
してみました。
■例えば、「生産管理システム」構築時の要件整理の場合
私は、製造工場経験者で、実務で忙しい現場や管理業務にコンピュータを
導入するのは意外と難しいことは熟知していると思っています. ．．？
（詳細は割愛）
とは言っても社外の立場から、生産管理システムなどを構築する際は、
対象の固有の業務や現場作業は理解していませんから、関係者から
聞き取り（ヒアリング）し、要件を整理します。
その際、一般的に
・数人の人が使用するシステム
・多数の人が使用するシステムだが、使い方は皆ほぼ同じ
の場合は比較的簡単で、特定の関係者からのヒアリングで要件整理が
できる場合も多いのですが、
・例えば工場全体のシステムのような場合
（複数の人が使用するシステムで、イレギュラー対応も多く、
工場間の連携もある．．．）
のような場合は要注意です。
■ヒアリングによる要件整理の落とし穴
システム化の要求を整理するにあたり、関係者各々の立場での要望、
着目点、スキル、向いているところの見極めが大事かと思います。
例えば
・経営者の立場の人 ・管理者の立場の人 ・実務者の立場の人
・システムをイメージできる人できない人 ・個人的思惑．．？
など、様々な考え方を持った人からのヒアリングには、精度にも限界が
ありますし、関係する人が多くなれば本質が埋没することもあります。
また、方法論を多数決で決めればＯｋというものでもありません。
■まずは、手コンピュータで確認・検討・調整
そもそも、システムの要件整理には、下記内容を押さえていることが
前提条件となります。
�ゞ般格�析 → 今はどのようにしているか、
そして次どのようにしたいのか
�▲轡好謄牴修量榲�を具体的に定義化
�６般灰侫蹇爾寮依�
�ぅぅ譽�ュラー処理等の対応方法検討
�コ堂萍未篦�票のイメージ作成
�Τ堂萍未料犧酳�法
すなわち、業務を整理し事実として積み上げ具体的に検討し、システム
化の目的も含め、これから作る新しいシステムの使い方を机上で検討し
シミュレーションする必要があります。
（具体的なシステム化の課題等は割愛）
■キーワードは、
・要件開発 ・要件整理 ・合意の方法
・開発側とエンドユーザーとの間で、真の合意
でしょうか。
■以下、最近目にした関連記事や雑誌です。
ボーランド社のＡＬＭ製品宣伝記事に下記のような表現がありました。
開発プロジェクトが失敗する原因のトップに、要件の不正確さ、
不完全さ、要件の誤った管理がある。
また、要件の間違いは手戻り作業を引き起こす最大の原因となり、
その割合はプロジェクト全体の開発作業の40％にも及ぶという報告
がある。
問題は、これまでの開発の多くが、開発側とエンドユーザーとの
間で、真の合意が得られぬまま進められてきたことにあるのだ。
雑誌には下記のような特集がありました。
・日経ソフトウェア ２００６年９月・１０月号
「要求は開発するものである」
・日経ＳＹＳＴＥＭＳ ２００６年１１月号（ITproTechメールからの情報）
「特集１ 図解で極める要求定義」
その他、ITproTech メール 2006.10.26[要求定義を極める]から抜粋
・要件定義の方法論を知る
・ＤＯＡ型要件定義の実際 ・日本標準的な作業手順とは？
・非機能要件を見極める
・ヒアリングでは不十分 ・ひな型を使い漏れ防止
・上流工程の問題解決 要求定義編
・要求と機能の関係は？ ・うまく合意するには？
・上流工程の問題解決 仕様変更編
・仕様変更が出たときの「禁句」は？
・上流工程AtoZ
有名な書籍
・「動かないコンピュータ」という書籍は以前から有名
ところで、これらの関連記事を読むのも大変！
開発者からユーザまでわかりやすいものがあると嬉しいですが。。。
■コンピューティングの将来（業務システム）
要件開発とか要件整理の手法に関する標準化が必要かと思います。
この部分はコンピュータの技術から分離できるため、その気になれば
さほど難しくないと思いますが。。。
プロフィール
