最新版ITIL 4を活用したITサービスマネジメント変革とは?~デザイン思考~

前回は、ITIL4の活用アプローチである「テーラーメイド化」を紹介しましたが、今回は、各組織におけるITIL 4を活用したITサービスマネジメントの「テーラーメイド化」で必要な「デザイン思考」に注目してみたいと思います。
図1. ITIL 4のサービスバリューシステム全体構成イメージ(©株式会社JOIN)
ITIL 4を活用する目的と思考スタイル
これまで、パート1からパート5の中で、ITIL 4の概念と活用アプローチをご紹介してきましたが、ITIL 4を活用する目的はなんでしょうか。
それは、IT運用の改善や改良を目的とした従来のITサービスマネジメントから、デジタルトランスフォーメーション(DX)という経営課題への対応を目的としたITサービスマネジメントへ変革するためです。
この変革とは、ITIL 4のサービスバリューシステム(図1)を、組織に合わせて「テーラーメイド化」することであり、その変革を実践するためには、これまで改善や改良に用いてきた「ロジカル思考」だけではなく、さまざまな観点やアプローチを立体的にとらえ可視化する「デザイン思考」が必要となります。
「デザイン思考」とは?
まず、デザイン思考の歴史と定義を確認しておきたいと思います。
デザイン思考(Design Thinking)という考え方は、50年ほど前からデザイン工学や建築の分野で存在していましたが、ビジネスの世界への適用を広めたのは、デザインコンサルティング会社IDEO(アイディオ)のCEOティム・ブラウン氏だと言われています。
ブラウン氏は当初「正しい問いを見つける手法」あるいは「正しい課題設定をするための手法」としてデザイン思考を定義していましたが、現在では「デザイン経営」という経営スタイルにまで進化し、「経営課題の解決手法」として多くの組織で活用されるようになりました。
では、なぜこれまで私たちが活用してきたロジカル思考ではだめなのでしょうか。
過去におけるITサービスマネジメントに関する解決すべき経営課題は、「コスト削減」や「重大障害の抑止」「サービス品質向上」「業務プロセスのIT化」など、主にロジカル思考で対応できる課題でした。
しかし、近年のDXの潮流におけるITサービスマネジメントに関する解決すべき経営課題は、「ビジネスモデルの変革」や「コスト構造の見直し」「サービス品質の再定義」「働き方改革」「ソーシング戦略の見直し」など、これまでの価値観や手法では対応できない複雑で難易度の高い課題になってきており、その解決には全く新しい解決方法を導き出すイノベーションが必要であり、ロジカル思考だけでは解決の糸口を見いだせなくなってきたためです。
つまり、デザイン思考が対応する経営課題のテーマは、改善や改良ではなくイノベーションということになります。
図2. デザイン思考の定義
ロジカル思考とデザイン思考のアプローチの違い
続いて、これまで社会人としての基本的なコンピテンシーとして活用されてきた「ロジカル思考」と、新たな「デザイン思考」のアプローチの違いを比較してみたいと思います。
なお、2つのアプローチの特徴が分かるよう、私の個人的な解釈をもとに比較要素を抽象化して相対的に比較していることをご了承ください。
1.時代背景
主に「ロジカル思考」が使われてきた過去数十年の中で、ブラックマンデーやITバブル崩壊、リーマンショック、欧州での債務危機など、国際的な金融や経済の危機があり、多くの企業が倒産することはありました。しかし、産業構造やビジネスモデルが揺らぐことはありませんでしたので、リスク管理が機能している組織においては「予測可能な安定した時代」であったと言えます。
一方、「デザイン思考」が注目されるようになった近年では、「第4次産業革命」「デジタル破壊」「デジタルトランスフォーメーション」と呼ばれる時代に突入し、あらゆる産業構造の壁が崩壊し、従来のビジネスモデルやリスク管理は通用しなくなっており、「VUCA時代」と呼ばれています。
VUCAは、「変動性」「不確実性」「複雑性」「曖昧性」の4つの単語の頭文字から作った造語で、1990年代にアメリカの軍事領域において用いられていた言葉であり、戦場のように変化が激しく予測不能な状況を指します。
図3. VUCA時代とは
2.思考の軸
「ロジカル思考」では、主に左脳を使い、ロジック中心で要点をまとめ、最終的に数字的根拠で判断します。
一方「デザイン思考」では、主に右脳を使い、人(ステークホルダー)の視点に立ち、背景にあるストーリーやテイストが組織の理念やビジョンと整合性が取れているかどうかで判断します。
3.ニーズの特定
「ロジカル思考」では、専門家による仮説検証や、さまざまなリサーチ結果を分析することで、ターゲットとなる顧客やユーザのニーズを特定します。
一方「デザイン思考」では、ターゲットとなる顧客やユーザの考えや行動を自分の五感を使って観察し、互いの共感を通じてニーズを特定します。
4.価値基準
「ロジカル思考」では、特定されたニーズに対する論理的な正しさが価値基準であり、ベストであることを目指します。
一方「デザイン思考」では、人(ステークホルダー)の満足度が価値基準であり、身体的にも精神的にも社会的にもバランスよく良好な状態であるwell-beingであることを目指します。
5.スタイル
「ロジカル思考」では、ある人が単独で考え構想をまとめあげる独創のスタイルを取ります。
一方「デザイン思考」では、ステークホルダーが一緒になって考え、1つの構想にまとめあげる共創のスタイルを取ります。
6.組織
「ロジカル思考」は、社長をトップとした幾つもの中間管理職を置く階層型のヒエラルキー組織で使われます。
一方「デザイン思考」は、マイクロマネジメントが不要で、組織の目的実現に向けて自律的に機能しているフラット型のホラクラシーあるいはティールと呼ばれる組織で使われます。
7.視点
「ロジカル思考」では、対象となるテーマに関する直接的なステークホルダーによる局所的な視点であり、平面図やチャートなど図式化された情報を使用します。
一方「デザイン思考」では、対象となるテーマに関してだけでなく、直接関係の無いステークホルダーも含めてさまざまな観点を含む大局的な視点であり、鳥瞰図のような全体を見渡せる可視化された情報を使用します。
8.サイクル
「ロジカル思考」では、計画を重視し、決められたスケジュールに沿ってPDCAを繰り返します。
一方「デザイン思考」では、アジリティを重視し、なるべく素早くOODAを繰り返します。
OODAとは、VUCA同様にアメリカの軍事領域で、Observe(観察)→Orient(仮説構築)→Decide(意思決定)→Act(実行)の頭文字を取って作られた造語です。
このOODAの4つの行動を、戦場において高速に回すことで、敵をまどわし有利に戦闘を行うことができたそうです。
そして、戦場のようなVUCA時代にあるビジネスにおいても、戦争に勝って生き残るためにはアジリティが高い組織へと変革する必要があるため、このOODAにより意思決定が行われるようになりました。
図4. PDCAとOODAの違い
9.手法とアウトプット
「ロジカル思考」では、最終的な完成品をアウトプットすることを目標として、ウォーターフォール開発手法を使用します。
一方「デザイン思考」では、MVP(Minimum Viable Product)と呼ばれる「顧客が価値を感じる最小限の製品またはサービス」をなるべく早くアウトプットすることを目標とし、プロトタイプで顧客の反応を見ながら繰り返しアウトプットを積み上げる、アジャイル開発手法を使用します。
10.活動モデル
「ロジカル思考」では、組織内の活動そのものに着目し、標準化されたプロセスをベースにした活動モデルを使用します。
一方「デザイン思考」では、組織内の活動により生まれる価値に着目し、最終的な価値の実現のために最適化されたバリューストリーム(価値の連鎖)をベースにした活動モデルを使用します。
11.モニタリング
「ロジカル思考」では、標準化されたプロセスの活動をKPIでモニタリングし、その結果をレポート化して定期的な会議の場で報告してコントロールを行います。
一方「デザイン思考」では、最適化されたバリューストリーム(価値の連鎖)の活動を、リアルタイムでモニタリングし、ステークホルダーはデジタルツール上のダッシュボードを通じてリアルタイムにコントロールを行います。
以上の比較を表にまとめたのが図5です。
図5. ロジカル思考とデザイン思考の相対比較
この比較から分かるように、ITIL 4を活用してアジャイルにITサービスマネジメントを変革するためには、これまでとは全く違うアプローチが必要であり、「デザイン思考」が必要であることがお分かりいただけるかと思います。
これまで6回にわたり、「最新版ITIL 4を活用したITサービスマネジメント変革アプローチ」をご紹介してきましたが、多少なりとも皆さまの組織における変革のきっかけになれば幸いです。
また、ITIL 4の資格であるITIL Managing Professional (MP) とITIL Strategic Leader (SL)向けに提供される5冊のガイドブックと、プラクティスに関する補完資料である「Practice Guides」をベースにして、今後さらに実践的な活用アプローチをご紹介していきたいと考えております。
筆者紹介
ITIL導入でお悩みではありませんか?
ITILの導入にユニリタの「LMIS」を活用することで、コストの最適化とサービス品質のお悩みを解消します。
- インシデント対応や変更作業の記憶が散在しており、情報が活用できない
- IT部門が実施するそれぞれの業務やサービスの評価ができない。標準化による信頼性の向上
- 役割や手順が明確に定まっていない