kintoneでの開発を考える・その２／アプリをたくさん作っても、それはシステムではない
プロ雑用です！
今回は引き続き、kintoneでの開発について。
このnoteは↓のシリーズの第二回目です。
Vモデルにkintoneを当てはめてみる
さて、前回のnoteを前提として、Vモデルへkintoneを当てはめてみると、図のどこに該当するのか？
Vモデルの折返しにある実装作業は主にプログラムのコーディングです。なので、kintoneをはじめとしたノー・ローコードツールは、この実装作業に該当します。建築で例えると、建築に必要な材料や道具がkintoneにはあらかじめ準備されている、と考えることができます。
kintoneなどのノー・ローコードツールなので、その名の通りということではありますが、Vモデルをベースに考えてみると、あくまで実装作業だけしか当てはまりません。それ以外の部分は、kintoneだろうがなんだろうが必要だということでもあります。
つまりこれは、ノー・ローコードはシステムを簡単に作れるわけではない、ということを表しています。ノー・ローコードツールで謳われる「簡単に作れる」は、あくまで実装部分の簡略化、であって、システムを対象にしたものではないのです。
アプリ作成＝システム構築ではない
そう考えれば、kintoneは真の意味でシステム構築のツールではないということは理解できるでしょう。kintoneはあくまで業務のアプリケーションをノー・ローコードで作るツールであり、アプリケーションはシステムの要素の一つに過ぎません。
システムではなく、単体で機能するアプリだけであれば、設計工程のほとんどは省略しても問題ないことが多いでしょう。単体アプリの作成を、無理やりVモデルを使って表してみると、こんな風に表せるでしょうか？
ユーザーの要求をそのままアプリ化すれば、要求を満たすことができるでしょうから、kintoneであれば、その場でぱっとアプリを作ることができます。こういった場合、設計や検証は省略しても問題無いかもしれません。
しかし、複数のアプリが多岐にわたって連携する場合など、複雑さが増すほどに設計をせずに構築することは困難になることは想像に難くありません。
アプリとシステムの要素の一部と先ほど述べました。その関係をざっくりと図にすると下のように示せます。
繰り返しになりますが、kintoneなどで作ったアプリは、あくまでシステムの構成要素の一つであり、システムそのものではありませんし、また、アプリが複数あったとしても、それが関連なく独立したアプリに過ぎないのであれば、それはやはりシステムとは呼べません。
そもそも「システム」ってなんだ？
「システム」という言葉の定義は非常に幅広く、業種職種によってその意味するところは異なっています。「システム」は、系、体系、制度、方式、組織など文脈に応じて意味付けされるいわば「概念」です。
そのため、厳密で統一的な定義は存在しません。しかし、それだとこの話は続かないため（笑）、ここでは一旦「ITを利用した業務システム」として定義してを進めます。
ITを利用した業務システム、というと、「なんかわからんけどコンピューターを使って仕事をする」というのが一般的な認識だと思います。また「コンピューターが人間の代わりに仕事をしてくれる」というイメージを持っている方も多いですね。
実をいうと「ITを利用した業務システム」には、「人間」という主語が隠されています。ITが人間の代わりに自動的に業務を行うのがシステム、ではなく、人間がITを利用して業務を行うためのシステム、というのが正しい理解です。
つまり、「”人間の活動”も含めてシステム」、ということです。システム構築するときに、この「人間の活動」を除外して考えてしまうと、様々なトラブルやミスの大きな要因となります。
システムは人＋アプリで成り立つ
人間の活動、を別の言い方をすれば、それは業務プロセスです。業務プロセスを先程の図に含めて表現すれば以下のように表せます。
これを念頭に、Vモデルに戻ると、プロセスの最後（最右上）に運用の確認という項目が見えますが、これはユーザーの運用イメージ（つまり要求）がシステムによって満たされているかを確認する項目です。
業務プロセスに則ってシステム（と含まれるアプリ）が想定通りに、ストレスなく、安全に、効率よく動作するかを確認します。
システム設計は「人間」を考えることから始まる
しかし、そもそもその業務プロセスは、本当に人間に活動と合っているのか？を確認することはあまり無いように思います。実際、現場ではマニュアルの業務プロセスをベースとしながらも、現場の裁量によって工夫しながら業務を行っていることがよくあります。
これは、要するに業務プロセスは、必ずしも実態を反映していない（業務プロセス≒人間の活動）、ということを示しています。
Vモデルを含めたウォーターフォールモデルは、業務プロセスを中心にしてアプリケーションソフトウェアを設計し、実装していきます。そして、業務プロセスには人間が「（プロセスとして定義された）正しい活動を行うこと」を前提としています。実態との乖離というのは、この設計する際の、人間への期待との乖離と言い換えることもできます。
実態と乖離している業務システムの構築がなされて、現場の不評を買うという実例は枚挙に暇がありませんが、それは業務プロセスで定義した活動だけを正解として設計を行ってしまうからなのです。
しかし、一方で現場の動きだけに注目すると、一人ひとりが微妙に異なる動きをしていることも実態として多くあります。では、そういった場合、システムはどのように構築したら良いのか？
ということで、今回はここまで。次回では実態に即した設計を行うためにはどうしたらしいのか、について考察していきます。
それじゃ、また👋