【課題解決・問題解決】02 課題解決アプローチ＆方法論の発展 回顧録
はじめに
アールツリー・イノベーション 辻隆盛です。私は、1989年から2010年までコンサルティング業界で多くの課題解決プロジェクトに取り組んできました。私が20年以上に渡って取り組めたのは、先進的なお客様との出会いがあったこと、上司および優秀なチームメンバーに恵まれたこと、そして多様な課題解決アプローチ、方法論を習得する機会に恵まれたことにあったと考えています。
私は、1989年以降に在籍していた外資系コンサルティングファームで、最初に情報システム開発に関する課題解決アプローチ、方法論を習得しました。その後の1990年代には次々に新たなコンサルティング・サービスが開発され、新たなコンサルティング・サービス毎に課題解決アプローチ、方法論が開発されていました。これらの課題解決アプローチ、方法論は、外資系コンサルティングファームが独自に全てを開発したものではなく、時々に著名な学者の方々が提唱していた考え方を適用して開発されていました。また、先進的なお客様企業と協同で開発することもありました。
方法論を習得したコンサルタントとお客様がチームを編成し、課題解決プロジェクトに取り組むことは、成果品質を向上させるために有効な方法です。私も方法論に関する分厚いリファレンスブックを精読し、方法論に関する研修プログラムに参加したことを覚えています。
一方、方法論はあくまでもツールであり、リファレンスブックを精読し、研修プログラムに参加するだけでは使いこなせるようになるわけではありません。プロジェクト プランニングにおいて課題解決の特性に応じて方法論をカスタマイズした上で、プロジェクトの現場で使い込むことが習得する上で肝要であると考えています。
この記事では、私が1989年以降に出会い習得してきました課題解決アプローチおよび方法論を振り返り、回顧録として記します。尚、私が習得していない方法論も多数あります。限られた経験における回顧録になりますこと、ご了承をお願いします。
課題解決アプローチ、方法論とは
課題解決アプローチとは、「課題解決において必要とする成果/成果物を創出するプロセスを意思決定ポイントおよび承認ポイントで区分し、一連のフェーズとして構成したもの」です。
方法論とは、「課題解決アプローチに基づき、創出する成果/成果物、実行する活動、活動の中で用いる技法、実行するための組織体制を定めたもの」です。
情報システム開発方法論 （1980年代後期）
1980年代後期には、欧米企業は大型汎用機上で構築してきた基幹系情報システムをUNIXベースのシステムへダウンサイジングする課題解決に取り組み始めていました。当時、在籍していた外資系コンサルティングファームでは、この課題解決を支援するべく情報システム開発方法論を開発しました。この情報システム開発方法論は、カスタムソフトウェア開発およびパッケージソフトウェア導入の２つのアプローチに分かれていました。
カスタムソフトウェア開発アプローチは、システム要件定義、システム設計、システム開発、システムテスト、ユーザー受入テスト、導入のフェーズで構成されていました。
パッケージソフトウェア導入アプローチは、適合分析、パッケージソフトウェア・パラメータ設定、システムテスト、ユーザー受入テスト、導入のフェーズで構成されていました。
システム要件定義では、システム構造化分析技法が適用されており、ビジネスファンクション分解、システムファンクション分解、データモデリング、データーフロー分析などを実施していました。ビジネスファンクション分解ではＢＦＣと呼ばれるチャート、システムファンクション分解ではＳＦＣと呼ばれるチャート、データモデリングではＥＲ図、データーフロー分析ではデータフロー図を使用していたことを覚えています。
システム構造化分析技法の発展に貢献した方の中で、著名な方はEdward Nash Yourdon先生、Tom DeMarco先生です。
ＩＴ投資プランニング方法論 （1990年代前期）
1990年代前期には、欧米企業がUNIXベースのシステムへダウンサイジングするためのプランニングを支援するべくＩＴ投資プランニング方法論が開発されました。
システムファンクション、システムデータ、システム基盤、通信ネットワーク基盤の４つの構成要素により新たな情報システム構成の複数案を立案し、各案のリスクおよび投資費用を比較検討した上で、情報システム構成を選択し、投資意思決定するアプローチでした。
ちなみに1990年代前期から中期までの日本企業では、大型汎用機上のシステム資産を維持・拡張することが主流であり、ダウンサイジングを目的としたＩＴ投資プランニングを実施する機会が少なかったことを覚えています。
情報システム/ＲＡＤ方法論 （1990年代前期）
1990年代前期には、情報システム開発期間を短期化するＲＡＤ方法論が開発されました。ＲＡＤは、Rapid Application Developmentの略称です。
当時、いくつかのツールベンダーがシステムプログラム・ソースコードおよびデータベース・ＳＱＬを自動生成するＣＡＳＥツールの提供を始めていました。これらのＣＡＳＥツールを用いて、システム要件定義フェーズにおいてプロトタイピングを実施し、開発期間の短縮化をはかるアプローチでした。ＣＡＳＥとは、Computer Aided Software Engineeringの略称です。
ＲＡＤ方法論では、データ中心アプローチが提唱されていました。私はデータモデリング技法を習得するために、ＣＡＳＥツールを用いてエンティティおよびエンティティ・リレーションシップを入力し、自動生成されるＳＱＬを学習していたことを覚えています。
ＲＡＤ方法論の発展に貢献した方の中で、著名な方はJames Martin先生です。
ＢＰＲ構想策定方法論 （1990年代中期）
1990年代中期には、ビジネスプロセス・リエンジニアリングの考え方を適用したＢＰＲ構想策定方法論が開発されました。ＢＰＲは、Business Process Re-engineeringの略称です。
特定の事業あるいは特定の組織を対象として、ビジネスプロセスにおける変革機会を分析した上で、実現すべき姿を定め、変革実行計画を立案するアプローチでした。
この方法論のリファレンスブックの冒頭には、「ビジネス活動の始まりは２通りである」と記されていましたが、この定義方法を理解し習得するのに時間を要したことを覚えています。
ちなみに私が在籍していた外資系コンサルティングファームでは、ＢＰＲ構想策定方法論が導入された際に、ビジネスイベントおよびビジネス・アクティビティをデザインするアプローチも導入されており、従来のシステム要件定義で使用していたビジネスファンクション分解、ＢＦＣ、データフロー図などの使用が廃止になったことを覚えています。
ビジネスプロセス・リエンジニアリングを提唱し発展に貢献した方は、Michael Hammer先生、James A.Champy先生です。
ＥＲＰパッケージソフトウェア導入方法論 （1990年代中期）
1990年代中期には、ＥＲＰパッケージソフトウェア導入方法論が開発されました。従来のパッケージソフトウェア導入アプローチをベースにして、ＲＡＤ方法論におけるプロトタイピングが適用されました。ＥＲＰは、Enterprise Resource Planningの略称です。
当時、先進的な欧米企業ではＥＲＰパッケージソフトウェア導入が始まっていました。先進的な欧米企業が採用したアプローチは、「ＢＰＲ w/ ＥＲＰパッケージソフトウェア導入」でした。一方、当時はＥＲＰパッケージソフトウェア製品におけるシステムファンクションが充実していなかったため、パッケージソフトウェアベンダーは先進的な欧米企業が必要とするシステムファンクションを製品の標準機能として実装する活動を推進していました。
ちなみに日本企業では1990年代後期からＥＲＰパッケージソフトウェア導入が本格化しましたが、そのアプローチは、「システムリプレース w/ ＥＲＰパッケージソフトウェア導入」が主流であり、ビジネスプロセスを変革することなく、大型汎用機上で肥大化していたシステム資産をＥＲＰパッケージソフトウェア環境へ移行する取り組みに陥っていました。この取り組みにより多数の日本企業において多大なアドオン開発が発生したことを覚えています。
業績評価指標デザイン方法論 （1990年代中期）
1990年代中期には、業績評価指標デザイン方法論が開発されました。
当時、伝統ある欧米企業では、業績管理において古くなり必要としない多数の評価指標が滞留している問題を抱えていました。一方ではデータウェアハウス、データマートなどの情報技術を導入して、新たな業績管理の仕組みを構築する取り組みが始まっていました。
この方法論は、企業のビジョン、経営戦略、施策に基づいて、達成目標を階層化し、階層毎に主要成功要因、評価指標、目標値、達成期限を定め、組織内に達成目標を浸透させるアプローチでした。バランス・スコアカードという考え方が適用されており、評価指標を財務の視点に偏って定めるのではなく、顧客の視点、ビジネスプロセスの視点、学習と成長の視点を持って、バランス良く評価指標を定めることが提唱されていました。
バランス・スコアカードを提唱し発展に貢献した方は、Robert S.Kaplan先生、David P.Norton先生です。
データウェアハウス構築方法論 （1990年代中期）
1990年代中期には、データウェアハウス構築方法論が開発されました。
当時、先進的な欧米企業ではＥＲＰパッケージソフトウェア導入に伴ってシステムデータを一元管理することが可能になり、そのシステムデータを業績管理および様々な分析活動に活用する取り組みが始まっていました。データウェアハウス、データマートというアーキテクチャーが提唱され、ツールベンダーが実装するためのツールの提供を始めていました。
この方法論は、トランザクション・データ、オペレーション・データをデータクレンジングした上で、データウェアハウスに格納し、業績管理および個別の分析活動で使用するためのシステムデータを分散配置する仕組みを設計し、構築するアプローチでした。
業績管理システム構築に関しては、業績評価指標デザイン方法論と連携する位置付けになっていました。
ビジネス変革構想策定方法論 （1990年代後期）
1990年代年後期には、ビジネス変革構想策定方法論が開発されました。
当時、先進的な欧米企業では、グローバルに展開するグループ企業を対象にしてグループ企業標準とするビジネスプロセスおよび情報システムを導入・展開する取り組み、グループ企業のビジネスプロセスを共有化する取り組み、グループ企業のビジネスプロセスをＢＰＯする取り組みなどを始めていました。対象範囲はグローバル＆グループ企業であり、変革の対象とする経営資源は、「組織・人財」「制度」「ビジネスプロセス」「情報システム」などに広がり、取り組みの始めにビジネス変革のための構想を策定することが必要になっていました。
当初のビジネス変革構想策定では、ビジネス変革構想策定チームから次フェーズを担当するビジネスデザインチームへスムーズに引き継ぐことが難しく、問題が発生していました。その後、ビジネス変革構想策定を推進したプロジェクトリーダーが、全てのフェーズの推進を一貫してリードすることで問題を解決していたことを覚えています。
ネットサービス/アジャイル開発方法論 （1990年代後期）
1990年代後期には、ＳＩＰＳと呼ばれていた外資系コンサルティング会社がＲＡＤ方法論をベースにしてアジャイル開発方法論（原型）を開発していました。ＳＩＰＳとは、Strategic Internet Professinal Serviceの略称です。
当時、欧米ではインターネット・サービスの黎明期を迎えており、ネットサービス・ベンチャー企業の創業が増えていました。インターネット・サービスでは、短期間にサービスを追加しリリースすること、また短期間にＵＸ/ＵＩを改善することが求められていました。
しかし2000年以降にe-エコノミー（インターネット・サービス）が破綻し、多くのネットサービス・ベンチャー企業およびＳＩＰＳが衰退したことを覚えています。その後は、現在の大手ネットサービス企業が台頭し、アジャイル開発方法論の開発を内製化して推進しています。
私は2000年に米国でアジャイル開発方法論（原型）に関する研修プログラムに参加する機会に恵まれました。コミュニケーションおよび合意形成を重視したアプローチ、開発期間を短期化するためのスケジューリング技法、ＵＸ/ＵＩエキスパート人財の参画など、私が習得してきました方法論との相違点が多く、愕然としたことを覚えています。
今後の課題解決アプローチ、方法論について
1990年代には外資系コンサルティングファームが課題解決アプローチ、方法論の開発を推進しており、お客様である欧米企業が適用し、習得していました。また、先進的な欧米企業では、外資系コンサルティングファームと協同で課題解決アプローチ、方法論の開発に取り組んでいました。
日本では2000年以降にコンサルティング業界の再編が発生し、多数の外資系コンサルティングファーム 日本法人では、課題解決アプローチ、方法論の伝承および開発が途絶えています。また、日本で活動する多数のコンサルティング会社では、課題解決アプローチ、方法論を開発するノウハウおよび経験を有していません。
一方、日本企業では、1990年代後期以降に「システムリプレース w/ ＥＲＰパッケージソフトウェア導入」が主流になったために、ビジネス構想策定、ビジネスデザインに関する方法論を適用し、習得する機会を逸しています。いまもなお多くの日本企業では、ビジネス構想策定、ビジネスデザインにおいて迷走している取り組みが少なくありません。
企業が取り組む課題解決の難度が一層高まる中、属人的なアプローチ、画一的なアプローチでは課題を解決することが困難になっています。新たなビジネス・スタートアップ、ビジネス変革、制度変革、ビジネスプロセス変革などの取り組みを立ち上げる際には、企業組織内において様々な課題解決アプローチ、方法論を参考にして課題解決の特性に応じた課題解決アプローチを組み立てられるリーダー人財、さらには課題解決を推進できるリーダー人財が必要不可欠になっています。
この記事が気に入ったらサポートをしてみませんか？