私がローコード導入に失敗した理由
こんにちは。日本はゴールデンウィークですね。少し考える時間ができたので、私のプロジェクト経験から、ローコード導入プロジェクトで失敗した理由を記載しておこうと思います。
３年前
あるプロジェクトでローコードを選定していたのは、３年前です。当時、ローコードというキーワードがちょうど流行りだしたころでした。私もお客様にローコードを提案し、たまたま運がよく、その案が採用され導入していただくことになりました。
流行に乗った理由
なぜ、ローコードを選んだのか、当時は、ローコードと同時にアジャイル開発というキーワードも出てきていました。これからのシステム開発はアジャイルで進めるべきだ、アジャイルで画面イメージを利用する人と一緒に考えていくんだ、そういった思いで、アジャイル開発やローコードを導入しました。そのコンセプトが理解されて実際の顧客プロジェクトとして進めていきました。
どこからが失敗だったか
それは、今、まさに現在です。当時はアジャイルで、ユーザが使いやすい画面を開発、より便利になることが、さらなる改善を生み、画面が洗練されていきました。しかし、徐々に改善事項はなくなり、２年ほど前に開発チームは解散してしまいました。チームが解散した後、２年ほど同じ画面で運用をしていくと、業務に合わなくなってきており、新しい改善が必要な状態となりました。その時です。
開発チームはすでに解散、アジャイル開発のプロセスにおいて、ドキュメントより動くものを重視してきた結果、画面修正が、簡単にできなくなってしまったのです。ある機能を修正しようとすると、他の機能に影響があり、その影響度の調査にものすごい時間を費やすようになってしまっています。これが、失敗と考える理由です。
運用を考える
ローコードの欠点は、運用後、忘れたころにやってくるのです。ローコードで素早く開発できることはメリットですが、その分、２年後、３年後を見通して開発することは難しいです。そのため、ババ抜きのように、ババが最後に残り、たまたまいま運用保守をしているメンバーに負荷がかかってしまうのです。そこからは悪循環が続きます。３年前からセキュリティの脆弱性対応など、より強固なセキュリティを求められるようになり、パッチを適用しなければならないですが、そのセキュリティパッチが別の不具合を引き起こすこともしばしば。従来はアクセスできていたのに、セキュリティが厳しくなってアクセスできなくなってしまうシステムとなっていました。
運用コストを意識する
保守の体制の問題だったのかもしれません。そもそも、３年後も開発を続けていて、そのシステムを深く理解しているメンバーが継続的に案件に携わっているのがあたりまえ、そのような考えで当時は案件導入を行っていたかもしれません。でも、システム開発は、従来から何も変わらず、一定の開発が終われば、新規開発はなくなり、メンバーは解散するのです。この当たり前の状態を意識した、運用チームを編成するべきでした。運用チームのスキルを上げておくべきでした。
ドキュメントがないことが運用チームの負荷を上げる
さらに、アジャイル開発で進めてきた関係で、ドキュメントは最小限しか残っていません。また、ローコードのプラットフォームであるが故、設定値すべてをドキュメントに残していないので、影響度調査や類似障害調査の時間が余計にかかるようになっています。
ローコード開発で失敗しないために
ローコード開発で失敗しないためにはどうすればよいか。それは、アジャイルでもできるだけドキュメントを残す。ドキュメントではなくても、Youtube動画のように設定を動画で残すのも１つのやるべきことかもしれません。とにかく、記録をできるだけたくさん残すこと。これからは、以前よりも記録が重要です。なんでも記録する習慣をつけ、その記録を簡単に検索できる仕組みがあれば、運用チームがもっと効率的に回る体制となるはずです。
記録を残す
幸いにして、現在、記録を残すためのツールがたくさんあります。これらを有効活用し、多くの記録を残すことで、後世の運用メンバーをサポートしたい、と今は考えているところです。
３年前の自分に知っておいてほしいこと
とにかく記録。
これからやるべきこと
とにかく記録。記憶はすたるので。
※参考にした書籍