kintoneでの開発を考える・その3／ユーザーは目的なんか知らない
プロ雑用です！
今回も引き続き、システム開発について考えていきます。
前回のnoteは↓こちらです！
要件定義とは何をするものか
そもそも、設計の前提となる「要件定義」とはなにか。
もっと言えば、要件とはなんでしょうか？
その業務／活動の「目的」はなにか
要件を辞書で調べると、「重要な位置づけとなる用事」「あるものを満たすために必要な条件」と出ます。この意味を、業務システムに当てはめてみると「システム構築するうえで重要なものはなにか」「そのシステムはどんな成果を求める（満たす）ものなのか」となります。
これは一言で表せば「目的」です。
つまり、業務システムの要件とは、そのシステムの目的、そしてそのシステムのアプリケーションの役割はなんであるか、ということを定義するということに他なりません。
目的を達成するための機能、そして役割
自動車のハンドルやエンジンは、それが動作すること、操作することは機能であって目的ではありません。自動車は「それを運転してどこに向かう」「かっこいい車を所有すること」といった目的のために使われます。つまり、自動車は目的を達成するためのシステムを捉えることができるでしょう。
これを業務システムに置き換えれば、自動車が業務システム、それを操作するのに必要なハンドルやエンジンはアプリケーションとなります。
さらに重要なのは、運転している人も「どこに向かうか？」という目的に対しては「安全を心がけて自動車を操作する」という役割が求められます。
これもまた業務システムに置き換えれば、業務システムの利用者は正しくアプリケーションを利用し目的を果たす役割が求められるということです。
つまり、要件定義は第一に、システムの目的、アプリの機能、利用者（ユーザー）の役割を考えることが必要になります。しかし、これだけではまだ実態に即した設計には不十分です。
ユーザーの行動を見る
人間は、どんな人間でもミスをするし事故も起こします。自動車の運転でも人為的ミスは完全には防げませんし、事故を完全になくすことはできません。しかし、機能の安全性能の向上や、ユーザーのスキルアップによって重大事故は減らすことが可能です。
つまり自動車というシステムは、ある程度ユーザーが操作ミスをすることを前提にして設計されている、ということでもあります。
業務システムでも同様に、ユーザーは人間ですから、ミスや間違いを完全には防げません。そのため、そもそもミスをさせないように設計するということも必要になります。
これを、前回のnoteで示した図を元に表すと、以下のような図で示せます。
業務システムの設計には業務プロセスだけでなく、その上にいるユーザーがどのように行動（Activity）するのか、を忘れてはならないのです。
ユーザーと業務プロセスとの乖離
人間は必ず間違えるし、勝手な動きをするものだ
前回のnoteで「業務プロセスは、必ずしも実態を反映していない」と書きましたが、それはつまり、ユーザーアクティビティと業務プロセスの乖離を指しています。
まず業務プロセスはマニュアルなどで明文化されているとは限りませんし、明文化されている場合でも、内容が中途半端だったり、長らく更新されていなかったりということも十分あります。
業務が明文化されていない現場では、３人いれば３人それぞれ独自の方法で作業をしているかもしれません。結果的にうまく行っていても、詳細の過程はブラックボックス化しているため、実態と手順書などのマニュアルとは乖離があっても、だれもそれを把握してないということもありえます。
自動車のような物理的に操作方法が限定されている機械操作と違い、例えば営業活動などのユーザーの自由度が高い業務は、個人の工夫が多分に入る余地が沢山ありますから、三者三様のやり方というのは珍しくありません。
個人の工夫はシステム化できない
これは業務システムを構築するにあたって大きな問題になります。明文化された業務プロセスどおりにシステムを設計したことによって、ユーザーアクティビティが無視されてしまい、結果的に現場の負担が増す、あるいは誰も使われないシステムになる、というのはよくある話です。
デジタルというものは、再現性のあるものを繰り返すことは得意ですが、曖昧さを許容することができないため、個人の工夫で生産性が担保されている現場のリアルはアプリケーションとして実装することができません。
ここに、ウォータフォールモデルによるシステム設計の限界があります。
これまで述べた通り、ウォーターフォールモデルは、業務プロセスを中心にしてアプリケーションソフトウェアを設計し実装していきます。「前工程が間違っていないことを前提として詳細まで作り込む」というものなので、業務プロセスとユーザーアクティビティは乖離していないことが前提なのです。
多くの業界標準パッケージのシステムが「使いにくい」と言われる理由も、このあたりに要因があります。
では、使える業務システムを作るためには、どうしたらいいのでしょうか。
要求に目的は含まれていない
そもそも、業務プロセスと実態が乖離してても問題は無いのでしょうか？
これに対する答えは「短期スパンでは問題はならないが、中長期スパンでは問題になる」という時間軸の違いがあげられます。
どういうことか？
短期スパンで問題にならない理由は明確で「それでも今日、現場は回っているから」です。売上にしろ生産にしろ目標達成していれば問題視はされません。（もし、短期スパンで目標達成もできていなければ、それは業務システム以前の問題ですので、いくら良いシステムを導入しても解決はしません）
中長期スパンで問題になる理由は、「より高い目標を達成したい／下落に歯止めをかけたい」ということ。生産性、売上を今よりも上げたい、あるいは下がり続けるものを食い止めたい、というどちらにせよ現状より上を目指したい（マイナスを０にするのも、０を１にするのもベクトルとしては同じ）となると、乖離があるのは問題です。そもそも、業務プロセスそのものが効率的ではない可能性も考慮する必要があります。
つまり、これは「そもそも業務システムを何故つくりたいのか？」という、目的の話に繋がります。
ここで再び、Vモデルを見てみると、実は目的にあたる項目がありません。要件定義の「要件」に当たる部分が、実は含まれていない事がわかります。業務システムを何故使うのか？というのは、だいたいこういったモデルの外側にあります。言い換えるとこれは「業務システムの目的は、システムをつくる人ではなく、それを利用する側にある」ということです。
これは極めて重要なことですが、忘れられることが多いことです。基本的にユーザー側は要求しかしません。その要求を要件と思い込んでシステムを作ると大失敗するのは当たり前ですから、システムを作る側は一生懸命に要求を分析します。しかし要求をいくら分析しても目的はわかりません。要求の中に目的は含まれていないのです。
そんなことは当たり前だろう、と考えている人も多いと思いますが、残念ながらシステム開発の現場を見て、これを正しく理解できている人は少なく、だからこそ作ったシステムが使われないということが頻発するのですね。
ということで今回はここまで。
まだ続きます。
それじゃ、また👋
この記事が気に入ったらサポートをしてみませんか？