ローコードツールを導入した事業者から、「導入したものの上手く機能しないので改善方法を教えて欲しい」とのご相談を受けました。
第1回は属人性の排除、第2回は拡張性の欠落について問題点と解決策についてご紹介しました。最後となる第3回はこれらを改善する際にみられた問題点と解決策をお伝えします。
属人化、再び
熟練者が作成したExcelが属人化していることを危惧し、若手中心でローコードシステムの開発を行ってきたが、重要な機能が不足していたり、データ連携が不十分で必要なデータが得られない等の問題が発生したことは、これまでお伝えしたとおりである。
これを解消するために業務分析に取り組むことを推奨したが、その分析過程で更に問題点が出てきた。
処理画面は見やすく、誰もが使いやすくなったというものの、その処理内容は作成した担当者でしか分からないものが殆どであった。また、一部の機能は作成者自身も説明できなかったり、誤った説明をしたりするものもでてきた。
業務フローをドキュメント化するだけの作業だったはずが、結局、内部構造をイチからドキュメント化する作業を行わなければならないことになった。
新たに作られたローコードシステム自体がすでにブラックボックス化していることは明らかだった。
むしろ、全てを知らない若手がそれっぽいシステムを個人個人の感性で作成したことにより、ブラックボックス化は広がり、業務ノウハウも欠落させたことで状況は悪化したともいえる。
表面の問題ではなく構造の問題を見極める
この状況は、Excelからローコードに変えたという道具の変更では、本質的な問題解決にはならないことを示している。
業務構造や情報共有の仕組みそのものが属人的であれば、どんなツールを使っても再発する。
今回の再構築は「熟練者が作成したExcelが属人化の原因」と表面的な部分だけに目を向けていた。属人化の弊害を掘り下げ、業務プロセスが可視化されていないことや手順が標準化されていないことを問題と捉えていれば、開発の進め方も異なったものになっただろう。
また、基幹システムであるならば、設計書や運用手順のドキュメント化やレビューというシステム構築における基本的な事項を考慮していれば状況が悪化することは防げた可能性が高い。
再構築に必要なのは目的ではなく視点
今回の事例が示した通り、「属人化」という言葉だけを理由に再構築を進めても表層の問題にしか手が届かない。
属人化で何が問題になっているのか、それを改善することでどのような状態を目指すのか、その先にどのような目標を達成するのかというように、「問題の掘り起こし・課題の設定、業務目標の設定」をしっかり行うことが重要である。その後に、それを実現する仕組み構築するにはどうすればよいかという視点が必要になるが、ローコードツールというのはそれを具現化する道具の一つでしかない。
蛇足 現実には・・・
今回の事例ではローコードシステムの問題を直視しているが、残念ながら実態としては「ローコードシステムで問題が発生したが、引き返さない」という事例の方が多い。
これは「開発が誤っていることを認めたら自分が悪人になる」「一度進めたのだから引き返さない」という日本人らしい発想ともいえる。
