kintoneでの開発を考える・その6／統合に必要なのは、一本の柱
プロ雑用です。
このnoteは、こちらのシリーズの第６回目です。
そろそろkintoneが出て…出て…出てくると思いますｗ
前回は、各部門バラバラに存在しているアプリ群を統合する際には、それぞれの部門や役割ごとの目的ではなく、更にその上位の目的を見る必要があると述べました。
さらに、上位の目的を見ると同時に、「誰が何を入力するのか」という活動にも同時に考えを巡らす必要があると述べました。
今回は、では「誰が何を入力するのか」を具体的にどう考えればいいのかについて考察していきます。
システム、プロセス、活動は三位一体
前回の最後の方に登場した以下の図は、業務プロセス全体の目的は、システムの存在意義に直結し、さらにkintoneのアプリそれぞれの目的も、プロセス全体の目的と矛盾なく設定されていなくてはならない、ということを示しています。
システムは、業務プロセス全体の目的のために存在し、それは各アプリも同様です。各アプリにデータを入力するのは、各プロセスを担う部署でありそこに所属するメンバー（ユーザー）となります。
目的など知らなくても、ちゃんと入力できるようにする
一方、これは前回も述べましたが、ユーザーはシステムの目的など知ったことではありません。与えられた作業をこなすために、アプリへデータを入力していきます。これを押さえたうえで何を入力させるのか、どう入力させるのかを考える必要があります。
システム設計者はエンジニアリングの視点で正しいデータを入力してほしいという期待でもって入力フォームを設定していきますが、残念ながらユーザーはいつだって設計者の期待を裏切ります。これは、ユーザーが悪いのではなく、そういうユーザーに勝手な期待を寄せている設計者の責任です。
信じられないかもしれませんが、世の中には「プルダウンメニューのような選択項目が隠れているフォームが認識できない」という人もいるんです。
システムをQCDで考えてはいけない
システムに含まれる、各アプリケーションはシステムのために何らかの機能を提供するものですから、QCD（クオリティ・コスト・デリバリ）によって検証（評価）することができます。
一方で、システム全体の品質はQCDで考えてはいけません。
個々のアプリ品質はQCDで考えますが、システムはそれではダメなのです。
なぜかと言えば、第二回からずっと触れてきているように、システムはアプリ＋人の活動で成立するからです。人間の活動をQCDで評価することができない以上、システムをQCDで評価してはいけないのです。
では何か、といえば、一言で言えばそれは「目的に沿っているか」ということなのですけども、それだけ評価軸としては弱いです。
システム評価でエンジニアが用いる評価軸はRASIS（ライアス）が一般的かと思います。ただ、今回はノーコード・ローコードによるシステムなので、この評価軸は適当ではありません。（ノーコード・ローコードツールの開発プラットフォームとしての評価には妥当だが、プラットフォーム上で作られたものを評価するには大げさすぎると思われる）
そこで、ここではEEEという評価軸を提案します。ノーコード・ローコードにより開発されたシステムは、業務の目的に対して、以下の3点をどの程度満たしているかを評価するのが良いでしょう。
Effectiveness（プロセスの有効性）
成果はどうか：構築されたシステムが、現実の業務課題や目的にどれだけ適切に対応できるかを評価する。
例：業務の効率化やエラー削減などの具体的な成果をどれだけ実現できたか。
Efficacy（活動の実効性）
操作性はどうか：システムが理想的条件下（熟練者やサポートのある環境）で、期待される機能をどれだけ確実に実現できるかを評価。
例：ガイドラインに従うことで、システムがスムーズに機能するか。
Efficiency（システム開発の効率性）
生産性はどうか：システムの開発プロセスで、リソース（時間、人員、コスト）がどれだけ効率的かを評価する。また、リリース後のメンテナンスや将来の拡張性への対応も評価する。
例：開発コストや外部リソースの削減や、リリースまでの時間など
これは、より簡便な説明をすると、QCDが製品そのもの性能評価であるのに対し、EEEはシステムの体験評価、となります。これはシステム開発そのものにも使えますが、むしろリリース後に定期的に評価していくことで変化を受容できるシステムを作ることが可能になります。
これがシステム、プロセス、活動は三位一体という意味です。
目的に始まり、目的に沿い続けること
さて、このシリーズは今回で終わるのですが、結局kintoneの話はほとんどしていません笑笑笑 すまんな、それは予定調和なんだ、最初っからkintoneの話をするつもりは無かったんや！！！ｗ
ITシステムやアプリケーション、ソフトウェア。これらの言葉の意味することは、時代とともに変化してきました。新しい道具、あくまで既存の道具の代替手段として誕生したこれらは、いまや生活や仕事の中心に位置するようになりました。つまり、システムなくして今の生活や業務が成り立たない、というほど重要なものになったということ。
もうすでにその萌芽はありますが、ITシステムは社会インフラとなります。つまり水道とか道路とかと同じになるということ。
そしてPCとインターネットはもはやインフラ。エクセルやワードなど初めとした便利なデジタルオフィスツールもそれに近い。ノーコード・ローコードツールは開発プラットフォームとしてシステムやアプリケーションを身近なものとしました。
水道、電気、ガス、道路などの今では当たり前に存在するインフラシステムも、使い方を誤れば重大な事故につながりますが、安全に使える仕組みとルールによって制御されています。しかし、使う人がそれを使う目的を見失えば、どれだけ安全なものでも事故を起こす。それがなぜそうなのか、ともすれば見失いがちな目的を意識するというのは、普段の生活においても重要です。
企業はその業種業態などによって様々な目的がありますが、突き詰めればドラッカーが指摘するように「顧客の創造」という目的にたどり着きます。市民開発だろうとパッケージシステムだろうとなんだろうと、システムは顧客想像という目的のために役に立たなければ意味がなく、またそうであれば、使ってもらえないシステムもまた存在する意味がないし、開発・導入する意味がないとも言えます。
kintoneを初めとしたノーコード・ローコードツールが、システム開発という専門性の高い分野のハードルを引き下げたのは事実です。だからこそ、目的をよくよく考え、そして意識し続けるということが大事なんじゃよな、ということで終わりにしたいと思います。
最後に、QCDとEEEがVモデルのどの範囲に適応できるかを示しておきます。ただ、これはあくまでざっくりとした切り分けなので、それこそ目的によって範囲は変わってくるだろうなとは思います。
QCDが適正でも、EEEが満たされていなければ、各論OK・総論NGみたいな感じになっちゃいます。どんなに設計者が頭を捻って工夫したものでも、現場が使ってくれなければ意味がないし、現場が使いたいだけで目的を沿わないものは、ダメなんですね。
ということで、今年初めたものは今年中に終わらせられました。
よかったよかったｗ
それじゃまた👋