その3まででDX概要、およびその推進による様々な変化、及びそのためになにをしなければいけないかについてお話ししてきました。そうはいっても現状は問題なく守らなければいけない、という現実もあります。
そのためには、単なる見える化だけではなく、戦略的にiCD、ITSS+を活用する必要があります。
iCDの限界とITSS+
先回の繰り返しになりますが、重要なことですので再度述べておきます。
iCDは、ユーザー企業、IT企業、また様々なビジネスモデルの企業であっても活用できるようになっています。別の言い方をすると、どの企業にもそのまま使うことはできません。素材として揃っているコンテンツであって、それを材料に自ら組み立てるために用意されているものです。
意志を持って企業や組織の将来計画を基に「頭を使って」構築します。To Beの姿を論理的、また客観的に表現できる数少ない方法の一つだと言えます。
しかしながら、iCDで全てをカバー出来るわけではありません。タスクの並びを見ると2つの特徴に気づく方も多いと思います。
一つ目について、まず筆者が現在のiCDの構造を作ったのは2004年ですが、その時はタスクと呼ばずファンクションと言っていました。まさに、機能として定義していたわけです。
何かを設計する場合、機能的には「設計」と表現できます。業界が異なるシステムの設計、バッチ系の設計、Web系の設計、データ構造の設計、そしてDX関連でいうとAIを用いたユーザー向けのクラウドシステムの設計。設計の前にそれぞれ修飾子をつけると識別できますが、機能的には「設計」に変わりはありません。
特にDX技術について同じように表現すると、いわずもがなミスリードにつながります。
二つ目は、タスクはコンテンツの特徴としてウォーターフォールに見える構成になっています。ITSSやUISSの考えを基にしてるわけですから、当然このようになってしまうわけです。先ほどの機能的表現の混乱だけではなくて、DXの主流であるアジャイル開発がうまく表現できないことになります。無理やり表現しようとするとウォーターフォールのタスクと同じような定義となってしまい、埋没してしまいます。
この状況を回避するために、ITSS+として別途定義するのは自然な流れだと言えます。
iCDの中にもデータサイエンスやIoTが定義されていますが、タスクとして一体化しているのではなく。新たに「領域」を設けて一線を画してあります。当然使い方も異なります。
iCD と ITSS+ をどう使うか
まとめると次のようになります。
iCDだけではDX技術の対応が不可能である
ITSS+で補完する必要がある
では、どのように補完するのでしょうか。
2004年に筆者がITSS向けの活用プロセスとして策定しましたが、以来UISS、CCSFと引き継がれ、現在はiCDの活用プロセスとして採用されています。
図は、そのiCDの活用の流れをベースにし、ITSS＋での補完の仕方を表現したものです。
タスク役割定義のタイミングで、新たにITSS+の定義群などを活用するように考えてあります。
役割はタスクの集合体ですが、策定の仕方は企業のタスク構造(To Be)を構築してから役割として分担していくという手順です。この全体のタスク構造構築時にDX技術のタスクが入り込んでしまうとミスリードとなってしまい、うまく構造化できないということになります。理由は先に述べた通りですが、役割を策定した後に、その役割に対してITSS+の定義体などを使ってDX技術を補完していくことは、それほど難しくなくミスリードを防ぐことができます。
iCD、ITSS+活用ワークショップ
スキル標準ユーザー協会では、最先端の内容でコンサル経験豊かな講師陣でのワークショップを開催しています。
今年は6月と10月に予定されています。自社の題材を使用する実習形式のワークショップですので、非常に効果的です。ぜひご検討ください。
(下記参照)
関連サイト
公開日：
2022.03.11
