見出し画像

エンジニア視点から見える、DXプロジェクトで起こりがちな幻想

わが

初めまして。リンクアンドモチベーションの我妻です。
私は、社内のDX推進を担当しています。
さらに具体的に言うと、GoogleAppsScriptなどのプログラミング言語を用いて、社内の業務の自動化システムを作成しています。
いわゆる社内ツールを作成するエンジニア的ポジションにいます。
現場から「こんなツールを作ってほしい」「こんな業務を自動化したい」といった要望をいただき、技術的な観点から「これはできるがここは難しいかも」「こういう風にやるといいと思う」といったことをお伝えし、議論し、最終的な自動化ツールの開発を行っています。

皆さんにとって、DXプロジェクトの推進はどのような印象を持ちますでしょうか。
エンジニアとして現場の方とコミュニケーションをとっていると、
・実現したいことをシステムに落とし込むことがむつかしい
・システムでできることのイメージがつきにくい
・開発を進めるうえでエンジニアとのコミュニケーションに齟齬が生まれてしまう
こういったお話をよくいただきます。

エンジニアと現場では見えているものが違うので、コミュニケーションの齟齬が生まれやすい

結果として、
・納得できるシステムが作れなかった
・本当に業務が効率化されているかわからない
などというお声を聞いたことも少なくはありません。

今回は、エンジニア視点から見えるDXプロジェクトで起こりがちな幻想をご紹介することで、「こんなはずじゃなかった」の予防に役立てていただければと思います。

自動化したほうが手動で業務を行うより効率的である

🤔自動化の結果、稼働時間が増えるというジレンマ

「どんな業務でも自動化してしまえば、コスト削減になる」
…かというと、必ずしもそういうわけではありません。
例えば、システムを開発するためにはエンジニアが開発のための稼働を行います。
どれだけ定例で決まり決まった業務を自動化するとはいえ、どんなパターンにも対応でき、安定して使い続けられる自動化システムを作成することは一朝一夕でできるものではありません。
それだけではなく、業務フローが変更されたり、データ数が増えたりすればそれに応じて適宜保守開発も行わなくてはならず、
バグが起きればそれに対応もしなくてはいけません。

なので、そういったエンジニアの稼働時間が余計にかかってしまうとしても、それでも会社全体で見た工数がプラマイマイナスになっていると判断できなければ、自動化するだけエンジニアの稼働が増え、無駄が生まれてしまうということになります。

削減個数と開発＆保守工数のバランスをとらなくてはならない

例えば、私が以前対応したDXプロジェクトに「メールの情報を自動整形し、自社システムに自動インポートする仕組みづくり」というものがありました。
しかし、受信するメールの情報はテンプレが決まっているわけではないため、うまく情報が自動整理できず、たびたびエラーが起きてしまっていました。
結果として、エンジニアの稼働工数が膨らみ、手動でやっていた時期よりも全体的に工数が増えてしまっていました。

✋場合によってはすべてを自動化することをあきらめる

上記の例のように、自動化システムを導入しようとした結果、逆に全体的な工数が増えてしまうことがあります。
それでは、そのような場合どうしたらよいのでしょうか。
ポイントは、自動化のスコープを限定することです。

例えば、上記の例であれば、メールを受信しデータを蓄積するシステムと、データを自社システムに自動インポートするシステムの2つに分け、
メールの情報を自動整形する部分についてはオペレーションで担保することにしました。
オペレーションで担保するとはいっても、完全に手動で頑張るわけではなく、簡単な整形はスプレッドシートの関数で行っておく、情報が間違った整形されてしまった場合はわかるようにしておくなどの補助線を引いておき、負担の軽減を図りました。
システムが最もエラーを吐いてしまっていた点、エンジニアの稼働を必要としてしまっていた点を切り分けることで、全体的な工数を削減しました。

必ずしもすべてを自動化することが良いわけではない

このように、すべてを自動化することが必ずしも正しいわけではなく、場合によっては一部オペレーションで担保することで、全体的に見た工数の削減を目指すことが望ましいです。

📈アウトカムを測定”し続ける”仕組みを作ろう

今まで述べた通り、常に全体的に見た工数が削減されているのかを把握し続けることは非常に大切です。
しかし、システムを作成したらそれで満足し、本当に効果が出ているのかを図らないままにしているプロジェクトも結構あると思います。
また、システムが完成した際に手元でなんとなく計算して、「このくらい削減されたかな～」と考えて終わり、みたいなこともあります。

そうではなく、継続してアウトカム（稼働工数が削減されたとか、作業のクオリティが上がったとか）を可視化して、いつでも見れるような状態にしておくことが大切です。
例えば、あるプロジェクトでは、対象のメンバーの稼働工数が削減されることを1つのアウトカムとして設定しました。
そこで、GoogleカレンダーとGoogleAppsScript、スプレッドシートとLookerStudioをもちいて、該当者の稼働工数の推移がいつでも見れる仕組みを作成し、定期的にモニタリングしています。

✅考えておきたいチェックリスト

  • システムの開発にはどのくらいの時間がかかるか

  • バグ対応や保守に、月どのくらいの時間がかかるか

  • 一方で自動化システムを導入することでどのくらいの時間削減（もしくは作業クオリティの向上）が実現できるか

  • また、それを継続的にモニタリングできる仕組みは何か

  • 上記時間の差し引きがマイナスになるためにはどこまでをオペレーションで担保し、どこから自動化するべきか

システムは一度開発してしまえば使い続けることができる

🐶システムは生き物である

システムは生き物であり、ペットの犬や猫と同じです。
定期的にお世話をしなくてはだめになってしまいます。

「はじめは使っていたんだけど、気づいたら使えなくなってしまっていた」
「正しい使い方の引継ぎがされていなくて、今では使えない」
そんなシステムが、皆さんの周りにもありませんか？
これは、システムの定期的なメンテナンスを怠ってしまったために起きています。

🔧メンテナンスのトリガーを決めておく

システムが出来上がった際、システムの限界を正しく把握することで、
「どういう状況になったらメンテナンスが必要なのか」を決めておくことが必要です。
よくありがちなところで行くと
・データ数が○○を超えた場合はメンテナンスが必要
・システムを使用するユーザ数が○○人を超えた場合はメンテナンスが必要
・業務フローがこう変わった場合はメンテナンスが必要
などです。

👻同じく、システムを廃止するトリガーも決めておく

システムそのものに限界があるのと同じように、1つの会社が扱えるシステムの数にも限界があります。
私もこれまで3年間で30程度の自動化システムを作成しましたが、
仮に70歳までこの会社で働くとして、400個超のシステムを全て管理することは困難でしょう’。（もちろんエンジニアの数が増え、引継ぎを行って一定数手元から話せるかもしれませんが）

そのため、「このシステムはこの目的を完遂させられたら廃止する」「このシステムはこの業務がなくなったら廃止する」など、廃止のタイミングをあらかじめ決めておくことも場合によっては必要です。

少し状況は違いますが、私が別業務として行っているSalesforseの保守も同じようなことが言えています。
現場から毎日のように「新しい項目を作成してほしい」「新しい自動化プロセスを設定してほしい」と要望をいただきますが、
そもそもSalesforseには項目数の上限などがあるため、すべてを永遠に実現し続けることは不可能です。
そのため「項目を作成することはできますが、どういうタイミングになったらこの項目は不要になりますか」というコミュニケーションもセットで行うようにしています。

何かを作るということは、いつか廃止するということまでがセットです。

✅考えておきたいチェックリスト

  • そのシステムはどのようなタイミングでメンテナンスが必要になるのか

  • そのシステムはどのようなタイミングで廃止にできるのか

仕様の変更が軽微であればシステムの変更も軽微である

🍛エンジニアにとってカレーとカツカレーは別物である

「カレーが食べたくなったのでカレーを作り始めたが、盛り付けの際に急にカツカレーにしたくなったので、最後にカツを盛りつけた」
料理であればこれは可能ですが、エンジニアの世界だとこれが難しい場合があります。

いわゆる仕様変更というものです。
例えば、
・入力するデータをテキスト型から日付型に変更したい
・実行ボタンを別のページにつけてほしい
・私以外の人も、このシステムを使えるようにしてほしい
などなど、表面上（日本語で表すとなんだか）軽微に見える仕様変更ですが、エンジニアにとってはコードを根本から書き直さなくてはいけないほどの大きな変更になることがあります。
エンジニアにとって、カレーとカツカレーでは買わなければならないスパイスの種類がまったくもって別なのです。

🛑要件定義を確定したら一切の変更はできないと思おう

そのため、エンジニアがスパイスの買い出しに出発する前に、要件を全て固めるようにしましょう。
もちろん、仕様変更が物理的に不可能なわけではないので対応は可能ですが、それ相応の追加時間やコストがかかってしまうことを念頭に置いた方が良いです。（カツカレーを新たに注文しなおすイメージ）

特に見落としがちな要件は
・システムの利用者は誰か、また、組織変更などの際に大幅に増加したり、利用者の特性が変わったりする可能性はあるか
・入力するデータ型は何か（数値の場合は何文字までか）、また、変更の可能性はあるか
などです。

✅考えておきたいチェックリスト

  • 要件定義に変更の可能性はないか

  • 追加要件が出てきてしまう恐れはないか

まとめ

以上のようにシステムは、どんな願いでもかなえる魔法の道具ではなく、
繊細で頑固で、しかしその分正確で優秀な生き物に近いです。

ツールを作るエンジニアと、ツールを使う現場の人。同じツールというものを見ていながらも、視点が違うために見えているものも大きく異なっているものだと思います。
そのため、どちらが正しいとかではないと思いますが、今回のNoteをきっかけに、エンジニアが考えていること、気にしていることを知っていただけると、よりスムーズなプロジェクト推進ができるのではないかなと思います！
参考になれば幸いです。


この記事が気に入ったらサポートをしてみませんか？