当たり前のことから復習するDX実行推進　Pert.1

昨今話題のDXについて、今までシステム開発に携わってきた経験や学んできたことをいかし、担当者レベルで実際に実行するときにどう進めていくのかを、４回ほどに分けて私なりの考え方や進め方を記載します。
割と当たり前だと思われることをメインにまとめていくので、何を当たり前なことを書いてるんだとなる部分も多いと思います。一方でそれちょっと違うんじゃないのって部分もあると思うのでご意見いただけると嬉しいです。

手法については、例えばアジャイルであったりリーンであったりウォーターフォールであったりは、ここでは話さないです。
チームのメンバーであったりDXの対象であったりで適切な手法が変わる場合があるので、まずは考える流れを復習することを目指します。

初回は実行する流れの全体像を復習したいと思います。

今回のポイント

・DXは一人でやるものではない
・何のために作っているのか意識しよう

目次

1　全体の流れ
1-1変化を計画する
1-2状態変化を定義する
1-3システムの動きを決める
1-4設計・開発・導入・検証
2　DXは一人でやるものではない
3　アウトプットは目的をもって

1　全体の流れ

まずは全体の流れを確認します。
担当者レベルだとざっくり以下のような流れで推進していきます。

上部が推進の流れ、下部はその段階で作成されそうなアウトプットの一例です。左から右に段階が進むにあたってより細かい部分を考えていきます。
端的な言葉だけでは実際に何をするのかわからないので、各段階についてどんなことを行うのか見ていきたいと思います。アウトプットの詳細に関しては後の投稿で詳しく考えていければと思うので今回は簡単な説明にとどめます。

１-１変化を計画する

DXを行うとなった場合、スタートは変化させる対象が決まったところから始まると思います。（対象が決まってないとすると、まずはDXをやる目的が定まってないので、自分たちが何に困っているのが、なぜやるのかを明確にします。）

まず初めに行うのが対象のどこをどの順番で変化させるのかを計画することです。
とにかく一気に全部を変えるんだ、というケースも基幹系のシステムを変える場合など少なからずあると思いますが、多くの場合は早くできてなおかつ効果が高いところから順々に少しずつ変えていくケースが最近は多いと思います。それはアジャイルだから、ということではなく、変動の大きい現代社会ではちょっとずつでも変わっていかないと他社に遅れをとり淘汰される可能性が高いからだと考えてます。

この変化を計画する段階では「何を」「いつ」「どう」変えるのかを明確にして計画を立てる必要があります。なのでこの段階のアウトプットは以下のようなものが出てくることになると思います。

・AS-IS分析：現状のDX対象のあり方、フローを明確にする
・TO-BE分析：理想とするDX対象のあり方、フローを明確にする
・マイルストーン：AS-ISからTO-BEに向けてどういう順番で変化させていくのか、特に直近実行するのは何かを明確にして計画する

1-2状態変化を定義する

次にDX対象において、どんな課題を持った状態からどんな解決された状態に変化させたいのか定義します。
こちらを定義する目的ですが、単純にどんな課題を解消したいのか明確にすることだけではありません。「どんな場面」で、「どんな情報」を持っていて、「何」を必要としているところから始まって最終的にそれを叶えるのかを明確にします。これは次のシステムの動きを決める際にユーザーが知っている情報から欲しい情報を与えるようにどうするのか決めるために必要になってきます。

ここで注意したいのは前段で定義したTO-BE像全体を通してまず考える必要がある点です。
まず初めにやる部分だけ注目して考え始めてしまうと、特に業務改善でSaaSの導入をする場合などで起こりがちだと思いますが、部分部分は最適なシステムを入れたが全体を通じて様々なシステムを連携させることになってしまい、システム側の連携の手間や、ユーザーが一連のフローで複数システムを扱わないといけない負荷につながる可能性があります。それが大きな問題になるのかどうか全体を見ながら考えながら、それでいて最初に着手する各部分も詰めていく必要があります。
部分最適ではなく全体最適を考えながら部分部分を考える必要があるので個人的にはここの難易度が高い場合が多いと思います。

この状態変化を定義する段階では前述の「いつ」「何を使って」「何が欲しい」を整理するために以下のようなアウトプットが作成されます。

・状態遷移図：名前のままですが、誰がどんな状態からどんな状態に変化していくのかフローとしてまとめます。その状態から状態を変化させるのがシステムないしその一機能になります。
・DFD：状態が変化するということは少なからず情報がやり取りされているので、関係する人物・システム間で情報の流れをどうするのかまとめます。外部システムを導入する場合でも、ここで使うシステムからそこで使うシステムにこのデータ送信したいなどシステム間連携を考える上で連携の必要条件が見えてくるので整理するとよいと思います。

1-3システムの動きを決める

ここからは実際にシステムを開発する場合を前提にして話を進めます。SaaSなど外部システムを導入する場合でも当てはまる部分はあると思いますが、関係ない部分もあるため前置きしておきます。

前後のユーザーの状態から導入するシステムの動きを決めます。
システムにおけるインプットは何があるのか、ゴールに向けてどんな手順を踏んでいくのか、その際画面はどう遷移するのかなど、一機能の動きを考えるのではなく、状態の変化を起こすために必要な動き全体を考えます。

ここでのポイントはユーザーの心理を踏まえてスムーズに導くために「どのタイミングで」「どこで」「どう」機能を活用するのかを設計することです。この段階の設計のために以下のようなアウトプットを作る場合があります。

・アクティビティ図：システム上のユーザー心理とアクションを合わせて流れを可視化します。
・シーケンス図：DFDやアクティビティ図からユーザーとシステム間のデータのフローを検討します。
・ワイヤー：アクティビティのアクションやユーザーに提供するべき情報を画面の構成に要素として落としていきます。これをもとに詳細設計やデザイン制作に移っていきます。

1-4設計・開発・導入・検証

ワイヤーが出来上がると次はデザインと開発の設計に移ります。
デザイン作成においてはデザインシステムの作成や、ワイヤーから要素のグループ化共通化や優先順位をつけて視覚的に強弱をつけて作成していくことになります（書き手がデザイナー経験ないのでこのあたりの知識は薄いです）
開発においてはワイヤーからインターフェイスやDBの設計あたりから始められるかと思います。デザインが確定しないと開発できないという話もでたりしますが、ワイヤーの段階で必要項目は暫定的に決まっているので着手できる部分から進めるのが効率的かと思います。ただチームによりけりな部分が多いので、できるタイミングでできることから着手していけるといいかと思います。
ここで重要なのはデザイナーやエンジニアが設計段階で懸念点や実現不可能な部分がないか認識を都度すり合わせていくことです。お互いに出来上がったときに確認すると手戻りが発生した時に心理的に負荷が高まるので定期的に共有することが大事だと感じます。この時点で計画していたユーザーの動きが難しいことがわかれば前段のシステムの動きを見直したり、できる範囲にスコープを変化させてマイルストーンを変えて対応します。

開発手法の話は深くは書きませんが、開発段階でのプロトタイプや最終的にシステムができたら、当初計画していた通りの目標を達成しているのか検証して、次の施策に移るべくマイルストーンに照らし合わせて同様のサイクルを回していきます。
期待通りの成果があるならマイルストーンをそのまま進めて行きます。
思うような結果が得られなかった場合は原因を究明して考慮しなおした方がいいでしょう。
いずれにせよ、外的環境の変化でマイルストーン含めて見直さないといけない場合も多いので都度マイルストーンは見直して行くのが理想的だと思います。

この段階のアウトプットは実際に動くシステムを作るだけでなく、実際にシステム開発する前に対象ユーザーに触ってもらって狙った効果が出そうか検証できるものを作成して検証してみましょう。

・プロトタイプ・モック：呼び方や中身はいろいろあると思いますが、意思決定者やユーザーにそれっぽく動くものを見せて検証するためのアウトプットです。画面遷移図でこと足りる場合もあれば、デザインツールでそれっぽくポチポチ動くようにして見せる場合もあれば、システムの表面だけ作って裏側のデータをそれっぽいものにして使ってもらう場合もあるでしょう。重要なのはこのまま進めていいのか、修正するならどこを直せばいいのかを検証できることが重要なので、何で実現するかはコストや時間も考慮して選択になると思います。
・インタビュー：上記のプロトタイプ・モックを用いた検証や実際にシステムができた後の検証で、ユーザーの生の声を聞いてよかった点悪かった点を整理します。そのインタビューの後に何をするために何を知らないといけないのか事前に設計して進めます。

2　DXは一人でやるものではない

全体を通してみてみると、やらなくてはいけないことが非常に広範囲に及んでいることがわかります。
あるべき姿を描ける力、あるべき姿に向けて計画を立てられる力、実現するためにシステムの動きを設計できる力、そこからデザインを作ったり、実際に開発したりする力など、幅広い能力が求められます。正直すべてをまかなえる人はごく少数だと思います。
だからこそそれぞれの能力を持った人たちで協力して、役割を分担して進めていかなくてはなりません。
不得意分野で何とか頑張るよりも、得意な人に協力を仰いで一緒に進めた方が何倍も速く進みます。スタートアップ等、人のリソースが足りないような場合でない限り協力してより早く推進していければ理想です。（もちろんステークホルダーが増えすぎて話が進まないこともあるのでいい塩梅で......）

3　アウトプットは目的をもって

また、各段階で何を意識して考えるのかであったり、次の段階のこと考えて何を明確にしたいのかなど説明してきました。
よく現場で起こりがちなパターンとして、

・このフレームワークでうまくいったって体験談があったからやってみよう
・他でやってるこれがないからとにかく作ろう

のように、よくわからないけどうまくいきそうという理由でフレームワークを作っていることがあると思います。
何もないよりましだと思いますが、実は他で作っていたものと可視化できる情報が大差なくて単純に時間を無駄にしたというケースも多いのではないでしょうか。
システムと同じで企画を整理する段階でのアウトプットも目的を意識して作らないと活用できません。
次の工程を考える人に依頼するために整理したい場合と、自分の考えを整理したい場合とでは可視化したい情報が異なっているかもしれません。そもそも他の人に伝える必要がないなら個人のメモだけで済ませてしまってもいいかもしれません。

大切なのは以下の点を抑えて目的を明確にすることです。

・誰に伝えたいのか（自分か？意思決定者か？他のチームメイトか？）
・何を伝えたいのか（可視化して明確にしたいことは？）
・なぜ伝える必要があるのか？（設計をするため？方針の合意を取るため？）

それらを満たす手段としてアウトプットするものを選びます。
例に出したものはすべて作る必要があるものではないですし、私も毎回すべてを作っているわけではないです。あくまで選択肢の一つです。
どの段階で作るべきかもおおよその目安で現場の必要に応じて必要な情報を整理するために適した手段を選ぶことが何より重要です。

まとめ

長くなってしまいましたが、第一回はここまでにいたします。
あらためて今回伝えたかったまとめです

・DXは一人でやるものではない。協力して素早く進めよう
・何のために作っているのか意識しよう。目的をもってアウトプットを作成しよう

次回は変化を計画する段階について詳しくみていきたいと思います。

最後までお読みいただきありがとうございました。ご感想お待ちしております。