私の会社では、事業計画業務に使う基幹システムを刷新すべく、情報システム部と事業部が連携してアジャイル開発を推進しています。

今まで何度か記事にさせていただいております。

アジャイル開発と言っても、今回の開発では、「最低限の定義のみ決めて、あとはカスタマイズ性を残す」という意味合いで使われています。
そして、その最低限の定義を決めるために、海外子会社であったり、事業部の担当者が参画しています。

ただ、この「最低限の定義」というのが曲者です。
以前も書きましたが、「このようにシステムを作れば、今やっている業務に問題なく適用できますか？」という質問になっているのです。

つまり、「今の業務」が基点なんです。

確かに、事業計画業務は非常に複雑に発展してきました。
私の会社が扱う製品は非常に多岐にわたっており、作り方からビジネスモデルから全く違うものがあります。そのために事業部制を採っており、それゆえ製品特性に合わせて事業計画業務が進化してきた、という歴史があります。

それもあって、開発会議には全事業部の担当者が呼ばれ、それぞれの事業部の業務に支障が出ないか確認しているのです。

私はここで悩むわけです。

今までの業務を効率的にするのがDXなの？

数十年かけて成熟してきた事業計画業務ですから、非常に複雑に絡み合っています。
そうするとどうなるか。
「作業」が引き継がれていくわけです。

私の事業部だと、3～5年スパンで担当者が入れ替わりますので、引継ぎの回数もそれなりにあるわけです。
私も若いときには事業計画の実務者でしたから、作業をしていましたが、驚くことに、15年たっても同じ作業をしていたりするのです。

そしてその作業をしている担当者に「あなたの仕事は何？」と聞くと、「PLのエクセルを埋めることです」「売上計画のエラーチェックをすることです」といった感じで「作業」で答えるようになるのです。

もちろん、データは膨大にありますから、それらの作業時間もかなり多くなりますし、こういった作業によってエラーがつぶしこまれ、計画精度が上がるのも事実です。

そして、それらは各製品の特性に合わせて巧妙に作り込まれた作業になっているんです。

これらの作業をカバーしよう、というのが今の開発の考え方になっているのです。具体的には各個人がエクセルで作業しているものをシステム上で動くようにしよう、ということです。
そうすればだれでもアクセスできるようになりますし、作業内容が残る、という利点があるわけです。

それはそれでわかります。
良いノウハウは共有できるようになるので、属人的なスキルから脱却できます。それは全体の底上げにもなるでしょう。

DXするときに強制断捨離することもできるはず。

一方で、こういった基幹システムが刷新されるタイミングというのは、業務を断捨離するいい機会だとも思うのです。

先ほど述べたように、作業自体を仕事だと思い込んでしまうくらい、作業オリエンテッドな業務になってきています。
正直、今の事業環境では不要な作業もあると私は思っています。
少なくとも、作業インプット時間に見合うアウトプットは出せていない、と思っています。
しかし、作業が仕事だと思うと、自浄作用が働かなくなります。

私はこの自浄作用が働かない、思考停止状態が大きな課題だと思っているので、今回の基幹システム刷新というのは強制断捨離のいい機会だと捉えていました。

今回導入する基幹システムは、名だたるグローバル大企業で導入されているものです。各社でどの程度カスタマイズされているかはわかりませんが、聞いたところ、各社の導入までのスピード感を見るに、そこまで作り込まれていないように感じます。
私の会社は導入まで3年をかけることになっています。その3年間に「要件定義→画面開発→テスト」が数回組み込まれています。

このサイクルにユーザーである事業部が参画していることをもってアジャイル開発としているようなのですが、根本的に本稼働までが長すぎます。

そこまでしないといけないの？と強い疑問を持つわけです。
だって、世界の有名大企業はもっと早く導入しているのですから。

でも、そうしたら私たちの強みってどこに行っちゃうのだろう？

要は、私は「限りなく吊るしに近い状態」で業務を半ば強引に進めてしまえばいい、と思っています。
とまあ、こう思って見たものの、ここでまた迷いが出てきます。
今まで業務が進化してきたけれど、それを捨てるの？そこに我々の強みがあるのではないのか？ということです。

私の会社はそれなりの大企業なので、事業部間に壁があり、お互いの業務が分かっていない状態です。そんな中たまに業務について意見交換する場というのがあると、「あなたの事業部はさすがだね、いいやり方してるね」というコメントをもらうことがあります。

他の事業部が分析やトラブルシューティングに四苦八苦しているところを、私たちのところは最短距離で課題解決ができていることがあるのです。

それは過去に蓄積した分析パターンなどを実務で実行しているために、結果的にそのプロセス上で分析できていることがあります。その代わり普段からルーティン作業が多すぎるんですけどね。

でも、標準的な基幹システムに沿った業務に置き換えるとそういったノウハウが消えてしまうのではないか？と思うわけです。

強みって「考える」こと？「ノウハウがある」こと？

ここで改めて考えてみると、「ノウハウが消えてしまうのでは？」と心配するということは、「ノウハウがあることが強み」ということなのか、という疑問が出てきます。

ここに製造業の落とし穴があるのではと思うのです。

今まで長い歴史の中で経験が蓄積される。確かにそれも大事な知恵ですが、その経験自体を価値だと思ってしまうと、それを繰り返してしまおうとします。なぜその方法を採ったのか？と問われれば、「今までそうやってたから」と答えてしまう状況です。

つまり、ただ今までノウハウを使って解決できていたのは、「たまたまその時に有効な手立てだっただけ」だと思うのです。自ら根拠をもってそのノウハウを選択したわけではありませんからね。

強みは、その時に必要な手段を選ぶ根拠を説明できること

では、先人が事業で成功してきたのは「たまたま」だったのか？というとそうは思いません。
過去、その時に考え抜いて方法論を確立してきたのだと思います。その考え抜く姿勢が強みだったのではないかと思います。
しかし、今、私たちは、あまりに過去のノウハウが膨大であるがために、それを持っていることを強みと思ってしまい、それを守ることを優先しようとしています。

私たちは今後自分たちで未来を切り開いていくために、過去の繰り返しではなく、「結果的に過去と同じ打ち手であったとしても」自分たちで選択した手段であると根拠を持って説明しなければいけません。

DXは本当の強さが試される。

色々自分で考えましたが、やはり、DXは極力標準的なものに振ってしまうのがいいのではないかと思いました。

ここでユーザー自身が如何に腹を括って「シンプルな進め方にしてみる」と言えるか。そしてそれで対応できないことが起こったときに自ら考え、カスタマイズできるか。

今の我々の強さが試されているのだと思います。

過去のノウハウをコピーして自分たちが強いと思ってはいけません。

とにかく早く実務を回して見ましょうよ。そんな気になりました。