おはようござロゾー、はやしでゾー
生産管理の業務システムを200万でフルスクラッチ、ローコード・ノーコード製品だとうまくいくかというと微妙、その１問題定義 No5045
フルスクラッチで200万
最近IT導入補助金について、
色々と調べています。
導入事例でググった結果、
こんな例を見つけました。
フルスクラッチで200万の予算で、
IT導入補助金が下りました。
で生産管理関係のシステムを
作る事になりました。
とのこと。
あまり詳しくは書いてなかったのですが、
今時フルスクラッチ、
すなわち、
PHPやMySQLを駆使して、
０からコーディングをして、
導入する、、、、
という内容でした。
200万円だとおおむね３～４か月、
という記載と、気になる書き方が、、、
・途中で言ったことを変更してくれない
・先方が勝手に決めて進めている
・最初に言ったことを実装してくれない
などなど、
文句たらたら書いていて、
上司に苦情を出したり、
問題点を表にしてまとめたら、
かなりの数になった、
などと書いてありました。
最初に決めたことを変更したいが、
出来ない。。。。
このままでは導入が心配だ。。。。
そんな声がすでに出てきています。
現在、詳細設計から、
コーディングと言って、
プログラムを書いているところ。。。
後には戻れなさそうです。
それはなぜでしょうか。
ウォーターフォールモデルの限界
これはウォーターフォールモデルと言って、
一連の流れがあるから、
簡単に元に戻れません。
こういう順序で、
システムを作っているため、
途中で、、、、
例：桁数を〇桁から〇桁に減らしてほしい
といった軽微な修正は出来たとしても、
プログラムの箇所を再度チェックして、
テストし直して、、
(先方担当が決めて譲らない、とのこと)
例：倉庫数や配置場所を増やせる柔軟な作りにして欲しい
なんて当たり前だと思っていても、
それをシステムに反映するには、
設計から戻らざるを得ず、、
(要求定義で言っています、とのこと)
なんてことになり、
原則元に戻れない。
というわけ。
すでに設計から開発に
入っているところですから、
一度ひっくり返すくらいで
ないとすべての要望はかなえられません。
が、
なぜ最初から言っていないのでしょうか。
仕事をお願いした方は、
きっと最初から伝えているものもあれば、
詳細を煮詰めていないものもあれば、
途中で気が変ったものも０ではないでしょう。
コミュニケーションの問題
な気がします。
要件定義が９９％
ウォーターフォールモデルは、
従来からあるシステム構築の
モデルなので、
スケジュールが進みやすい、
工数が読みやすい、
人数が配置しやすい、
など管理のしやすさで、
これまで日本で行ってきました。
しかしこれは前提で、
「要件定義が９９％正しい」
という暗黙の了解があってこそ、
成り立つものです。
プロジェクトの大小問わず、
〇兆円から〇万円まで、
行ってきました。
なので、
最近はアジャイル開発といって、
小さく設計・開発・テストを
繰り返しながら、
修正があれば直しながら、
という開発技法もあります。
しかしながら、
アジャイル開発でもデメリットがあって、
・全体像が把握しにくい
・管理や工数が難しい
・修正点が大きいと全体の方向性がずれる
・出来るスタッフが少ない
という問題もあり、
採用の可否も問われます。
期間が限られている中で、
アジャイル開発で、
とは限定的になるでしょう。
ローコード・ノーコード
そこで出てきたのが、
ローコード・ノーコード製品です。
パーツを組み合わせて、
マウスでドラッグ&ドロップして、
と作れば１か月で出来る。
というもの。
kintoneをはじめとする、
たくさんの製品が出てきているので、
私のようなPHP知らない人でも、、
デイサービスアプリを作れて
しまうというわけ。
ローコード・ノーコードは、
アジャイル開発でもできやすい。
要求定義で画面の仕様書を作る暇があるなら、、、、
プロトタイプで作っちゃった方が早く、
全体の開発期間を短く出来、
修正箇所があればすぐ対応。
そんなことが実現出来ます。
しかしながら、
冒頭で書いた生産管理の業務アプリ、、、
これが果たして、
kintoneやAppSheetで実現出来るか？
というと疑問なわけです。
ケアプラン管理システム
生産管理だと私がよくわかりません。
なので、
これをケアプラン管理システムを、
AppSheetで行ったらどうなるか？
をやってみましたが、、、、
うまく行きませんでした。
ケアプラン１と２の関係性、
帳票の出力内容、
モニタリングのデータ、
画面上の表示、
などなど、
日本文化で培ったケアプラン管理は、
AppSheetでは実現出来ませんでした。
じゃあ、他のローコード・ノーコードで
実現出来るのかというと、、、
kintoneでは関数が足りず、
プラグイン課金が増えそうで諦めました。
OutSystemは英語で断念しました。
SPIRALは帳票がありませんでした。
Forguncyはスマホ対応が出来ませんでした。
と色々と試しました(笑)。
だから、ローコード・ノーコードがいい！
と言っても、
もしかして冒頭の
生産管理の業務システムは、、、
出来ないかも知れません。
kintoneだと出来るかも知れません。
しかし細かい、業務的な実装は、、、
結局ノーコードでは無理で、
どこかでプログラムを書く、
ことになるというわけです。
kintoneなら、JavaScriptとなります。
AppSheetなどクラウド製品の肝は、
リリースしたあとも維持費（利用料）が
かかってきます。
だから単純にローコード・ノーコードがいい、
というわけではありません。
この記事の目的
だからどっち側の意見で
書いているんだ、はやしは！？
と言われますが、
問題点や課題を洗い出すのが
この記事の目的です。
つまりは
フルスクラッチで行うにしろ、
ローコード・ノーコードで行うにしろ、
十分に検討した上で、
技術検証した上で、
対処が必要だ、というわけ。
だから、
働き方改革、
IT化、
DX推進って、、、、
なかなか進みにくいんですね。
その話を、
先日のIT介護支援室で話した内容を、
その２に続く。
連載記事はこちら
コメントを残す