DXにおける大きな勘違い（その３）
前回、ＤＸ活動におけるＡＩ開発においてユーザー企業が「課題設定＝開発目的の設定」までベンダーに丸投げしている実態があり、その状況を避けるためにどうしたらいいか考えましょうと書きました。
筆者が、研究してきた分野の一つに「システム開発とその要件定義のやり方」があります。この分野においても、ユーザー企業がベンダーに丸投げしている実態があります。「要件定義」の手引書を読んでみると、その殆ど（筆者の経験では全部）が対象とする読者をベンダーの技術者としています。ベンダーの技術者が、ユーザー部門の担当者にヒアリングを行いシステムの要件を定義するのです。
その大前提が、「ユーザーは業務をすべて分かっている。」です。大昔に筆者が銀行の超大規模システム開発に携わった折には、要件定義を担当したメンバーはいずれも担当業務のプロで、開発チーム（ベンダー中心）に業務に関する100％の情報提供が出来ました。別の言い方をすると、データベース内の全ての情報のＣＲＵＤ条件を理解していましたし、個別のＵＩもすべて定義しました。ところが、最近のネットや書籍で触れる要件定義においては、ユーザー担当者が、開発担当者に提供する情報が極めて「アバウト」だと言う実態があります。その背景として筆者が考えることは、ユーザ部門にとって「システムの操作」が仕事になってしまっているのではないかという点です。ちょっと、偉そうなことを言って申し訳ないのですが、実感です。
さて、私たちにとって「仕事」とは何でしょうか？それは、顧客に提供する「価値」の創造です。私たちはいろいろなノウハウ・技術を駆使して一連のプロセスを実行して「価値のあるモノ・コト」を生み出し、顧客に提供しています。しかし、ＡＩ開発に於ける「課題設定」をユーザー企業がベンダーに丸投げすると言うことは、創造する価値や、それを生み出すノウハウ・技術もベンダーに依存していると言うことで、自ら存在価値を放棄していることに他なりません。
と、言うことは、ＡＩ開発を含むＤＸにおいて、ユーザー企業はまず自社が創造する「価値」と、それを生み出す「ノウハウ・技術」を「固めて、定義する」ことが必要なのです。「何となく」の仕事をしてはいけません。逆の言い方をすると、このことさえ出来ていれば、ＤＸにおいても迷うことはなくなるでしょう。
要件定義については、下記のサイトに分かりやすい解説がなされています。
その中でこのブログの筆者は以下のように述べて折れれます。
「パターン①：発注側自身で要件定義する
このパターンは、あるべきパターンであり、将来的に目指したいパターンだ。自ら要件を定義し、業者を選定し、発注をかけるというのは、理想的な姿だ。しかしながら、要件定義のスキルがない者が要件定義してしまうと、大変なことになる。そもそもの要件定義の内容が曖昧で、何を作ればいいのかわからない場合や、問題の分析が甘く、開発終盤で要件を際限なく変更してしまう場合など、開発を炎上させるリスクは満載だ。要件定義書の内容にゴーサインを出すのは発注者自身なので、客観的に見てひどい内容の要件定義書であったとしても、ゴーサインが出てしまう場合があるのだ。したがって、このパターンが理想的ではあるものの、ちゃんとした要件定義をすることは、極めて難しい。」
私、ヘボもこの考えに賛成です。しかし、「ちゃんとした要件定義をすることは、極めて難しい。」からと言って、外部に「丸投げ」してはいけません。ユーザー企業にとってこのＡＩ開発は、投資を伴う重要な経営資源の獲得が目的です。「取り敢えず開発」とか「なんちゃって開発」は絶対に回避しなければなりません。「そんなこと言われても、出来ないものは出来ない。」と仰るかも知れませんが、ＡＩ開発に留まらずこうした新規開発は絶好の「新規ノウハウ・知識」を獲得出来る「場」なのです。開発の成果物は、目の前に「モノ」として存在する「機器やプログラム」だけではありません。それらを作り上げる過程で獲得する「知識・ノウハウ・経験」なども重要な経営資源の一部であり「成果物」なのです。そうです、開発に携わって「成長したあなた自身」が「成果物」です。故に、「楽をして、結果だけ取り繕う」と言う発想は、厳禁です。もし「あなた」がどうしても出来ないと思うならば、それは「あなたの出来ない」ではなく「会社としての出来ない」なので、「何故、出来ないのか？」を明らかにして、上層部にエスカレーションし、全社的な対策を講じる必要があります。「あなた一人」で握ってはいけません。
昔、ある若手から相談を受けました。「新任部署で業務の設計を指示されたけれど、どうしても出来ません。」と言って来ました。状況を聞いた私の回答は「ゼロからは、何も生まれないよ。」でした。どういうことかと言うと、新任の彼は、当該部署の「経験・知識」が殆ど無い状態で、毎日パソコンに向かって「う～ん、う～ん」と唸っているだけだったのです。そこで私は、「指示された業務に関連する、周辺業務や、必要な専門知識の勉強から始めなさい。」とアドバイスしたのですが、ＤＸでも同じ状況が見受けられます。殆どの皆さんには「ＤＸの経験・知識」が足りない状況でプロジェクトに向かい合っているのではないでしょうか？特に、「デジタルに弱い」とか「デジタルの経験なんか無い」とデジタルを避けようとしていませんか？
ゼロからは何も生まれません。まず、自身の業務知識を整理して、プラスデジタルの知識を収集することから始めましょう。
上で、要件定義に関するブログを紹介しましたが、ここで留意事項があるのでお伝えします。それは「要件定義」と「要件定義書」は、異なる活動の成果物だと言うことです。先の「若手」も、パソコンに向かって何かを「書こう」と悩んでいました。「手順」と「手順書」も違うものです。「要件定義」とは、既存の環境、業務などを調査し、周辺技術を学習しながら、新たに「獲得」しようとしている「機能」を考え、構築する作業です。「要件定義書」とは、その成果を「見える化」した物理的な情報です。つまり、要件を検討し定義する「ソフトな活動」に始まり、定義されたものを見える化する「ハードな活動」に収れんします。
ここで、問題になるのが「期限」（或いは、予算。）です。「期限内になんとかしなければ」と言う「暗黙の圧力」が「取り敢えず開発」とか「なんちゃって開発」を誘発します。その最大の原因は、「予備調査不足」です。そもそも、ＡＩ開発について基礎知識が無いにも拘らず「期限」設定してしまったことが諸悪の根源です。ＤＸを推進するには、まず「予備知識習得」や「現行業務の整理」が必要で「人材育成」から始めなくてはなりません。最近の論調で「外部からＤＸ人材の採用」が求められていますが、新しい人材が活躍出来るのも、現場の業務担当者が十分な「環境」を提供出来るかに掛かっています。
繰り返しになりますが、ＤＸ業務を任された「あなた」に出来なければ、それは、「全社」で出来ないのです。広い視野を持ちましょう。
是非、私の著書をお読みください。実務者目線でのＤＸを本にしました。
ＤＸで困っている方、悩んでいる方。個別のご相談に乗ります。ご一報ください。（まだ、HPが整理出来ていませんが、フォームからご連絡ください。）
この記事が気に入ったらサポートをしてみませんか？