ローコード開発≠安い

ゾンビファイル

今から十数年前に作られたExcelやAccessでのマクロプログラムが今もなお残り続けている。表計算ソフトと呼ばれるデータベースに似たツールを背景にユーザーインターフェースやロジックを付け足したものである。もはやゾンビファイルと言っても過言ではない。これらのシステムは当初の目的を果たしていても、時代の変化とともに保守性や拡張性に大きな課題を抱えるようになっている。

作成者不明問題

社内に残る通称「マクロ」は、今はいない人が作成していたり、一部の人が独自に作ったものであることが多くある。作った人がいる場合はまだしも、退職している場合はその中のプログラムも見ることができないので、いつ止まるか分からないシステムを業務の中心で使い続けていくことになる。このような状況では、エラーが発生した際の対処法が不明で、業務継続に深刻なリスクをもたらす可能性がある。

市民開発解決法

ブラックボックス化したマクロを情報システム部に解決をお願いするのではなく、市民開発にて解決するには多少のコツが必要になる。ポイントは完全にブラックボックス化している状態や、何から手を付けていいか分からない状態のマクロ群は、残念ながらまずは専門家に情報の整理を依頼することが必要になるだろう。自社だけでの解決を試みる前に、適切な専門知識を持つパートナーとの連携を検討することが成功への近道となる。

専門家活用法

専門家に依頼したほうがいい理由として、マクロファイルの解析だけを切り離した作業としてしまうと、その後の市民開発へ繋ぎにくくなるからである。マクロファイルのインプット／アウトプットを解析した上で、それをどのように今後の市民開発のベース作りに活かすのか。ITコンサルやシステム開発会社の腕の見せどころである。単純な解析作業ではなく、将来的な発展性を見据えた戦略的なアプローチが求められる領域といえるだろう。

まとめ

ExcelやAccessはMicrosoft社の製品であるので、そのままMicrosoft社が提供するPower PlatformやPower Appsへの移行がスマートである。間違ってもマクロをスクラッチ開発でのWebシステムに移管すべきではない。親和性の問題や閲覧性などに課題がのこることが多いようである。

システム開発の高コストと複雑化

多くの企業では、情報システム部門や外部システム会社にシステム開発を依頼すると、仕様確認が繰り返される。「この機能はどうするか？」「ステータスはこれで全てか？」など、質問が多く、時間とコストが増大。結果、システムは複雑化し、現場のニーズに即したシンプルな解決策から遠ざかる。

野良プログラムのリスク

システム開発の手間を避けるため、各部署でExcelマクロによる「野良プログラム」が横行する。これらは各人のPCに保存され、最新版の確認が困難になり、メンテナンスも不透明。担当者がいなくなるとブラックボックス化し、セキュリティリスクも増加。放置すれば、企業全体の業務効率が低下し、情報漏洩の危険もある。

Power Appsで迅速なシステム構築

こうした問題を解決するのが、MicrosoftのPower Appsだ。従来の複雑な開発プロセスを排除し、現場担当者が自らアプリを構築できる。ドラッグ＆ドロップで簡単に操作でき、セキュリティもMicrosoft標準に準拠。野良プログラムの乱立を防ぎ、システム管理とメンテナンスも容易になる。さらに、ユーザー自身がアプリを修正できるため、柔軟性も確保できる。

定量化困難な業務もデジタル化

業務のデジタル化は、数値で説明可能なタスクは簡単だが、現場には「説明しにくい」業務も多い。こうした業務は経験に依存しがちで、担当者に頼ることが多い。Power Appsは、このような曖昧な業務も迅速にアプリ化し、標準化と効率化を同時に実現する。

まとめ

Power Appsは、現場主導でアプリを作成・管理できる柔軟性を提供し、野良プログラムのリスクも解消する。複雑な開発プロセスを省き、数値化しにくい業務も効率的にデジタル化することができる。

目標設定の要諦

SESと呼ばれる派遣や準委任契約では、プロジェクトを完遂することが難しいとしている。これはゴールが未設定であったり、曖昧になってしまう場合が多くあるからである。ゴールの設定や未来像は非常に重要で、プロジェクトマネージャーなどリーダーが必ず持っておくべき指針である。

真のリーダー像

システム開発に参画するメンバーは一般的に経歴書やスキルシートによって決まる。プロジェクト経験数が多かったり、扱える言語が多かったりするだけでは、本当のスキルは推しはかれない。やはり、確認すべきは不測の事態が起きたときの対処方法を豊富に持つリーダーが必要となる。

アジャイルの本質

犬小屋を建てるときに設計書はいらないが、マンションを建てるには設計書がいる。アジャイル開発といっても、例えばマンションを設計図なしに建てるといったことを考えるとある程度は見通しや知見などを持つメンバーが方向性を決めていく必要がある。システム開発はその時その時の条件によっていい悪いの判断軸が変わる。さらに時間の経過でも判断軸が変化していくのである。

部分最適の罠

日本には「カイゼン」という高度経済成長期を支えた力強い言葉がある。しかし、時と状況によって判断軸が変わるソフトウェアという無形財産の前では、「善」に「改」めることができているのか、変化してしまう背景がある。職人気質である国民性も相まって、どうしても部分改善、部分最適を繰り返してしまうというプロジェクト現場が少なくない。

まとめ

システム運用や保守における部分最適は必ずしも全体最適になるわけではない。むしろ、この部分最適が全体を考えたときの労働生産性を下げていることすらある。小回りが利く人であればあるほど属人化してしまったりするため、誰が全体最適を見るのがベストなのか、改めて考える必要がある。