見出し画像

kintoneでの開発を考える・その4/現場主導の開発がうまくいかない理由

プロ雑用です。
このnoteは、こちらのシリーズの第四回目です。

このシリーズはウォーターフォールモデルの一つ・Vモデルを例に上げてシステム開発を考えていきました。前回までほとんどkintoneについては触れていませんでしたが、今回もあんまりkintoneには触れていません。もうちょっとお待ちくださいw


現場主導のシステム開発はなぜ躓くのか

kintoneはプログラミングは端折れるが…

kintoneのようなローコード、あるいはノーコードツールによる開発の利点としてよく挙げられるのが、プログラミングを学んでいない非IT人材、とくに業務部門のメンバーが、自ら必要なアプリケーションを作れる、という点が挙げられます。いわゆる、市民開発です。

市民開発の利点は、何と言っても「現場が自分たちの要求をすぐに反映することができる」という点だと思います。ただし、これは別にノー・ローコードでなくても、Excelやスプレッドシートでも必要十分な場合も多く、本当に利点と言えるかどうかは疑わしいと私は考えています。

ノー・ローコードは、プログラミングができなくともアプリケーションが作れるのが特徴なことは、すでにこのシリーズの第二回で述べました

Vモデルで考えると、実装の部分のみがkintoneで置き換えることができるが、逆を言えばそこしかkintoneは代替しない。むしろkintoneの代わりにExcelでも代替できることは多いかもしれない。

しかし、専門知識を持たない人材が開発できるのは、システムではなくアプリケーションまでです。アプリケーションをたくさん作っても、それもはシステムとは言えません。

システムは要求に従うと確実に失敗する

では、専門知識を持たない人々がシステム開発ができない(あるいはチャレンジして失敗する)のはなぜか、といえば、それは前回述べたように、ユーザーは要求しかしない=要求には目的が含まれない=そもそもの目的がよくわかっていないからです。

市民開発によるシステム開発が失敗/うまくいかない理由も同様に、業務の目的をしっかりと認識できておらず、そして関係者同士で共通認識できていないからです。

「業務システムの目的は、システムをつくる人ではなく、それを利用する側にある」と、前回の最後に述べましたが、しかし、ユーザー側も「その業務がなぜ必要か、何を目的としているのか」は、ほとんど理解していない、という現実が多くあります。

そんなわけはない!と反論する人も多いのですが、そういった人々にヒアリングしてみると、出てくるのは「目標」の話がほとんど、あるいは自部署などの狭い範囲の目的に限定されており、プロセスを含んだ業務全体の、本質的な目的は把握できていないということが圧倒的に多いのです。

これは、多くの組織が分業し専門性を高めた結果でもあります。その組織全体の目的を理解しなくても、業務が回るようにできているからです。

これが現場主導でのシステム開発がうまくいかない一番大きなポイントです。目的が見えていない/はっきりわかっていない状態で、現場の活動「だけ」を考えると、場当たり的なものしか作れないのですね。

目的を理解する前に小さくしてみる

「目的が大事なのはわかるんだけど、どうやって目的設定すればいいのかわからない」という声も多く聞かれます。

さまざまなアプローチ方法はありますが、このシリーズはVモデルを中心に話を進めているので、こちらについてもVモデルを元に解説していきます。

あらためてVモデルを見ると、ちょっと分かりづらい言葉が並んでいると感じますね。それはこれらの言葉がシステム寄りの機能的な言葉(要するに専門用語)だからです。これらの言葉を、人間の活動に寄せた言葉に言い換えてみると、以下の図のようになります。

システムおよびそこに含まれるアプリケーションは、それを利用するユーザーがいるのは当然です。ではそのユーザーの役割は何なのか?逆に言うと、ユーザーがどういう場面で使うかは、役割によって定まるということでもあります。営業が工場に出向いて機械のボタンを押さないように、役割がその人の活動を定めるのです。
役割がわかれば、その目標も見えてきます。営業なら売上、製造なら生産数などのように。目標がわかれば、達成状況を把握するためにどんな情報が必要なのかがわかりますから、自ずと何を入力するのかがわかりますし、それがわかればどんな項目(テーブル)を用意すればいいのかがわかります。

右側の検証フェーズでは、各々、正しい情報が入力できるような項目や機能が揃っているか、そこから正しい(必要な)データが出力できるか、目標達成を把握できる指標(営業であれば、接点数、架電数、訪問数、受注率などの数値ですね)が把握できるようになっているか、そして最終的にユーザーがその役割を全うするための活動ができるようになっているか、ということを段階的に確かめていきます。

これらは基本的に業務プロセスの則っていますが、前回も述べた通り、実際の活動と乖離がある可能性もあるわけです。なので、どこに乖離があるのかを確かめていくためにも、このような方法で一つずつ細分化して確認していけば、自ずと乖離が見えてくるはずです。

違和感をチューニングしながら目的を可視化する

また、確認の際には常に「この活動の目的は何なんだろうか?」という事を問い続けていくことで「この内容はちょっとズレている?」というようなちょっとした違和感が出てくるようにもなります。その違和感が、プロセスと活動の乖離をチューニングする大きなヒントになります。

どちらのフェーズのどの段階でも常に「目的は何か」を問いかけ続けることが、目的が見えないなかでシステム開発を進めるときに有効になる。

「目的」というのは「どこを目指しているか」ということです。徒歩、自転車、自動車、船舶、飛行機、鉄道、いずれのものにしても出発したらどこかに到着するわけですが、「どこを目指しているか」がなければ、すなわち目的地が必要です。ただの散歩やドライブであっても「その活動には何らかの意味がある」わけで、それが目的となります。(健康のため、気晴らしのため、も立派な目的であり活動の意味です)

システムは手段であり、手段は目的のために存在する、ということは常に理解しておく必要があります。

今回はここまで。次回に続きます。
それじゃまた👋

この記事が気に入ったらサポートをしてみませんか?