![見出し画像](https://assets.st-note.com/production/uploads/images/101805933/rectangle_large_type_2_1754e471edf930da9047319d37da9e76.jpeg?width=1200)
DX人材の育成ロードマップ_業務フロー
DX推進という言葉が流行り始めて数年が経過しています。
しかし、いまだに推進をする人材はどの企業でも不足しているのが現状かと思います。
人材の確保・育成は急務であり、私自身いろんなタイプの人材へのインプットを続けて試行錯誤しています。
よくIT系に強い人をイメージしてしまいますが、システムに強い人材とDXを推進する人材は似て非なるものです。
過去の失敗談
数年前、DX推進が流行り始めた際に現場では人材が足りず、アサインしたのは外部のシステム知見者でした。ただこれが見事にフィットしませんでした。
要求定義に時間がかかり、依頼できるのは要件設計した後。その後もレビューなど足りない工数を補填することができませんでした。
また、社内でシステム運用管理をしていた人物をアサインしたが、こちらも育成しきれなかった。
私自身、運用しているシステムの概要などのインプットやツールの手法などからインプットを進めたが、これが失敗でした。
自分が「よしなに」考えてやっていたことがインプットできていなかったのです。
私が辿り着いた育成のロードマップは「まずは業務設計のレベルを向上させる」ということです。
育成ロードマップ
インプットの順番
業務設計をする人材とシステム設計をする人材では所有するスキルや習得の順番が異なります。
DX人材は横断するような知見が必要です。
下記は例ですが、現場でDXを推進する人材は主に「要求定義」を行い、SEとコミュニケーションを取るようなブリッジSEのような業務を行うことが求められます。
そのため、私は業務設計の基礎知識から習得することをオススメしています。
逆にこれまでのようなレガシーな業務設計しかできない場合、業務の中にシステムが必ず組み込まれている現在では設計が難しくなる場面が出てくると考えています。
![](https://assets.st-note.com/img/1680344014294-YE2mZ9KdNs.png?width=1200)
上記の業務設計部分ができないと「V字モデル」の中の「要求定義」などを行うことができず、また基本設計のレビューを行うことができないので手戻りやスピード感が落ちる可能性があると考えています。
![](https://assets.st-note.com/img/1680345899578-WTC8KXW6er.png?width=1200)
業務設計の第一歩_業務フロー
DX推進の業務設計を行う上ではまずは現状の把握が必要です。
前の記事でも記載したように業務のプロセスを明確化、画一化した上で
モニタリングすることでどこに不があり、脱落しているのか、改善ポイントは何かを明確にすることができるようになります。
そこで役に立つのが「業務フロー」です。
業務フローとは
仕事のプロセスを示した流れのことです。
何をきっかけに業務をするか、次に何をするか、誰に依頼したり、どこに情報共有したりするかの詳しい流れを示すことで間違いなく業務を遂行することができます。
また、トラブルがあった際にどのように対処するかまで記載することが重要です。
業務フローのレベル
DX推進には業務フローを如何に綿密に設計できるかが鍵であると考えています。
業務フローには下記のレベルがあると考えています。
会社レベル:会社の契約・委託先との分掌に利用
└ステークホルダーは会社別に記載部署レベル:部署間の連携に利用
└ステークホルダーは部署別に記載業務レベル:施策の企画に利用
└ステークホルダーは担当者別に記載プロセスレベル:施策の運用設計に利用
└ステークホルダーは担当者&入力システムまで記載アクティビティレベル:業務効率化、問題の洗い出しに利用
└ステークホルダーは担当者&入力システム&データの流れ・蓄積方法まで記載
実際のDX推進やシステム導入にはアクティビティレベルの業務フローが必要であると考えており、アクティビティレベルのフローには「どのようにシステム入力のデータを活用するか」「データの動き」まで記載する必要があります。
■アクティビティレベルの業務フローを書く
①まずは現場にヒアリングしてタスクを全部洗い出す
企画職をやりたいという人は現場でのヒアリングを大事にするべきです。
マニュアルでわかったつもりになったり、フローの書き方の形式だけ知っていても実際に現場に行ったら「実はやっている」ことがあったりします。
また、業務とは複数の部署が関わって行うことが多いので対象の部署だけでなく「その先」までヒアリングして記載することが重要です。
例えば営業部の業務フローを記載しても受注までしか書かないのは勿体無いです。その先には請求処理する部署や与信審査する部署があるかもしれない。
その人たちは何をきっかけに業務を始めるかを意識する必要です。
実はこの箇所のデータの入力がとても大事であるなど落としてはいけないタスク、逆にやらなくても良いタスクに気づくことができます。
②モニタリングまで意識する
業務の中では業績管理や成果管理などが必ず発生します。
どのタスクを行った際に成果としてカウントを行うか?を意識することで管理部署と現場の橋渡しができるようになります。
DX推進しても旧体制のやり方をしてしまう人が出ています。
業績モニタリングなどは、DX推進のハレーションを予防する効果がとても強いので特に意識をします。
また、モニタリングをするなら異常値分析までセットで思考するようにします。
③知らない人に実際にやってもらって運用ブラッシュアップ
ヒアリングして業務フローを書いたり、実際の現場の人に試してもらうと「潜在的にわかっている」ことを無意識に記載がなくても実行してしまいます。
研鑽するときは必ず、新入社員や別部署の方など知らない人に見てもらうと練度が向上します。
また、トラブルやうまく行かないことが必ず発生します。その時の判断方法まで記載してあり、質問が出なければベストです。
④システムの流れを記載する
DX推進する上では、データ管理の文脈からシステム知見が必要となります。
先ほど定義したモニタリングを行うためには、システムのどの項目に何を入力してもらうかを設計しなければ、正しく取得したいデータが取れません。
-特定項目に日付で上書き入力するのか?
-フラグを立てるのか?
-日付を全部蓄積するか?
何に使いたいか?どのように加工するかを明確にするとシステムの設計も変わってきます。
これがシステム側の要件である、「ロール権限」や「入力項目」「データの保持のテーブル設計」に寄与してくるものになります。
「とりあえず項目作っておこう」だと、現場は負荷高く入力させられているだけとなり、さらに入力してもらったデータを使うこともできない状態になります。
業務設計する際には「現場の工程」と「経営層のみたいもの」をつなぐことが重要です。
上記の業務フローが描けるようになると情報の流れがイメージできるのでER図やリレーションのイメージがつけやすくなります。
その上で必要な言語を勉強すれば自分で実装もできるようになります。
要求定義についてまとめる力やベンダーに依頼する際に細かい内容は分からなくても流れやリスクを洗い出すことができるようにもなります。
そうすると業務設計と平行してシステムの要件設計、基本設計を行い、最適なツールの選択でDXを推進する人材に成長できるようになります。
この記事が気に入ったらサポートをしてみませんか?