マクロからPower Appsへ

ゾンビファイル

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

作成者不明問題

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

市民開発解決法

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

専門家活用法

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

まとめ

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

関連記事

熱意の共有

提案と負担

「なぜ、自社のシステム担当者や社外から常駐するSEは、システムの改善提案をしてくれないのだろう?」と思うことはないか。それは、提案することで自分が大変になってしまうことを理解しているからである。

現状維持の理

自分たちが大変になるだけであるため、普通に考えれば、それを「やろう」と思うはずがない。それがシステム担当者から提案が出てこない理由であろう。

知と意欲

そうなると、非エンジニアやシステム営業が発想する提案は、システムの要件や縛りを無視した案になってしまう。問題解決意欲の高い非エンジニアが指揮するシステム開発を成功させるには、同じ温度感を持つエンジニアを味方につけるほかない。

人材の見極め

システム担当として向いている人材を探すことは非常に困難である。仮に全社的な問題解決意欲の高いエンジニアを採用したとしても、本当のスキルがどの程度であるか知ることができない。システムの開発のほとんどは巻き戻すことができないからである。

まとめ

システム開発や運用の大変さを知る人材ほど、モチベーションがない限り全力を出し切らせるには、相当の熱量を伝えることが肝要である。

続きを見る >

フルスクラッチは体力

開発手法の選択

フルスクラッチかパッケージか、最近ではSaaSなどもシステム構築の検討に入る。実は開発手法やツールよりも、どのようなシステムで、どれくらいの規模のシステム開発会社が担当するかが重要である。

SESのリスク

人数が多い会社であればあるほど安心感があってよいと安易に考えることは適切ではない。なぜなら、SE派遣やSESと呼ばれる人月(人工)単位で売り上げの経つ会社には技術の総合力がないからである。

技術の総合力

技術の総合力とは、SE作業やプログラミング作業などの1人で対応できる技術力を差すのではなく、システム構築やシステムの運用全般における最適手段を考えることができる能力のことである。

表層の即効性

SE派遣やSESの付加価値はその人単体のプログラミング能力に偏るため、一見対応がよく、何も問題がないように思える。しかし、これが技術的負債を作ってしまうひとつの要因でもある。

まとめ

フルスクラッチを考えるなら、SESを中心としないシステム会社で且つ人数規模も多い方がよい。安価にフルスクラッチでシステムを構築してしまうと、メンテナンスや運用でしっぺ返しが待っている。時間が経つごとにシステム保守費用が高くなるのである。

続きを見る >

予算ブレの原因

開発の変動要因

システム開発は長期にわたることが多く、また未来の不確実性の中で予算を策定しなくてはいけないことがある。セキュリティーをはじめ動作環境の変化や人員の欠如、予期していなかった仕様の発覚などが原因だ。

目標変化と予算

進捗率は目的地が明確に設定されていれば数字を負うことで予算達成率を算出することができる。しかし、目的地が近い遠いのは無しではなく、根本的な目的地がなくなったり、複数になったりすることがシステム予算の策定の難しいところである。

計画型開発法

システムに未来を見ることができればブレない、見えないことをすべて調査の上で着手できれば確実な予算と実行が可能である。進捗率の報告が可能になる。フォーターフォールモデルなのでコストがかかることと時間がかかることの覚悟が必要だ。途中での方向修正は原則できない。

柔軟な開発手法

逆に低予算で早く導入するなら、見えにくくなるデメリットがある。状況によって対応を素早く変化させる必要があるため進捗率を算出しにくい。アジャイル開発と呼ばれるものであり、社内開発であることが理想である。途中で出てくる条件に対しても柔軟に方向性を変化させることが可能である。

まとめ

アジャイル開発で予算を立てるときは、1.5-2.5倍くらいを目安に余裕を持って設定することを推奨する。

続きを見る >