オルタナティブ・ブログ > 「神奈河、神名川、上無川 。」 >

読めばベタに分かる、タイトルどおりのブログ

[経験談シリーズ]システム開発がうまくいかなかった訳(3)~Web型でシステムを組む、ということの認識不足

»

今となっては当たり前・・・いや、その時でも当たり前だったのかもしれない。だが、あまりに無知で想像ができていなかったがために、結果として今も引き摺っている、というお話。

数年前(具体的な年数はあえて書かないが5年以上は前とだけ書いておく)、とある基幹系のシステムの全面再構築の話があった。ホスト系の画面をリモートコンソールで操作していたものを、新たな業務ロジックを組み直すと共ににWeb型に変更する、という割と大掛かりなもの。その画面設計にあたっては、その基幹系の対象ユーザー経験もあるメンバーが数名で開発者と共に、画面イメージづくり~ラフスケッチ~htmlでダミー画面を作成・各項目の配置や動作を確認、という流れで行っていたようだ。自分はほとんど全ての画面設計が終わった頃にそのプロジェクトに加わった。

自分はその対象ユーザーだった経験は無かったので、特にその画面構成に対してケチを付ける理由もなく、単にその業務想定上、こういった項目の用意も必要なんじゃないですか?ぐらいの話で補佐するような役目だった。

画面における項目の配置等はユーザーに対しての操作性の向上、業務効率の低下を招かないようにするための重要なポイントだとは思うが、やはりそれに携わる人の好みや関与度合い、また開発側の設計上の都合等により大きく左右される所もあり、どれが正解、というものは無いとは自分は考えている。ただ、自分が画面設計に携わる場合には、何故こういう項目配置にしたか、何故こういう画面割にしたか、という理由付けはユーザーに説明する段になることを想定し行うようにしているので、自分の理解を進めるためにもその既に決まっている画面構成について関与した担当スタッフに聞いてみた。

なるほど、以前は一つの業務を行うのに順送りで数画面を経由して初めてその業務の完結に向かうのがまどろっこしく感じていた、ということで、極力一画面におさまるように画面の組み替えた、とのこと。早く業務が出来る、なんて言うことで”クイック”系とか呼んでいた。確かにその気持ちは理解できる所はある。それぐらいにしか気に留めていなかった。但し、それでも当時その基幹システムを動作させる想定が細いネットワークを想定していたので、画面のサイズは極力20kに抑える、等の工夫が開発者側とで調整されていたようである。

ちなみに、ユーザー側の自分を含めてそのメンバー達の中で、Web型のシステム構築を行った経験がある者は少なく、あってもアンケート入力や情報表示、もしくは極めて少ない条件組合せで動作するロジックの業務システムぐらいしか担当したことのある者は居なかった。そういう意味ではその時開発していたようなかなり複雑な、かつかなり数多くの条件パラメータを与える業務システムをWebで開発することのイメージは誰一人できていなかった、と思う。

で、いざ完成してみると・・・もしかすると数画面を経由していた頃の画面よりも動作がはるかにまどろっこしく感じてしまう事態になった。
それには理由がある。
条件パラメータの与え方によってその次の選択肢が変わるようなものの場合、その全ての組合せを事前にhtmlに埋め込んでおくことはシステム的にも非常に複雑だし無駄である、と自分も理解できる。結果としてどんな組合せであっても変わらないパラメータは事前にプルダウン型の選択肢として読み込みをさせておくが、そうではない場合、別画面での選択や条件設定後に再取得となった結果、Web画面のリロードが発生する・・・イコール画面遷移と変わらない印象になってしまう、ということ。当たり前だ、htmlをブラウザで表示するのだから、JSPなりServletでその都度生成されたhtmlを取得しなくては画面表示が成り立たない。でも、そのこと自身が所詮VBやリモートコンソールでの業務をしたこと無い者には想定ができていなかった。
また、細いネットワークを想定した画面設計のため、前述の理由のパラメータとして事前に読み込んでおくものが項目数として少なかったり選択肢として極めて少数のものだけになった、とも言える。
結果としてどこが”クイック”なんだ・・・と。

画面設計を担当していた者は、画面がhtmlで表示される=その画面での動作が全て完結できる、というイメージで居たようである。実際には、その都度リロードが発生するから、画面項目の全てが表示されていたところで、それは「これだけ入力する必要がありますよ」のガイダンスにしか過ぎず、業務処理的には何の意味も持たなかったのである。開発者側はどれだけWeb型のシステム構築経験があったのかわからない。でも、当初のラフスケッチを見る限り、こういった部分に関する議論がなされていたようには思えないので、条件パラメータの読み違いをしていたか、元々ユーザー側が何故そこまで画面に項目を詰め込もう、としていたのかを理解できていなかったか、のどちらかはあると思えた。

非常に複雑な業務のシステムのため、未だにその部分は同じ作りで稼動している。という意味では未だに”格好悪い”動きをしている。現在のユーザーはきっとまどろっこしい、と思いながらもまぁ所詮こんなもん、ということで慣れてしまっているかあきらめてしまっているようだが・・・。

現在ではリッチクライアントというソリューションも出てきているので、前述のようないちいちリロードする、という所で「思いどおりでは無い」というのはほとんど世の中のケースとしては発生しないのだろう。また、ブロードバンド化されたネットワークにおいては、もっと画面の構成仕方も工夫できるだろう。

ユーザー側であった、としても、その自分達が実現しようとしているシステムの技術が自分達の実現イメージにどう影響するか、に気を払うことが必要だ、と思うし、開発側においてはいくらユーザーが主張したとしても、それが意味の無いことになるのであれば、そうでは無いよ、という諭しをする必要がある、と思う。

自分の場合は残念ながら経験しなければわからなかったことだが。

Comment(4)

コメント

AB12

普段このシステムを使っている身としては、聊か微妙な気持ちですが(笑)。
所謂「OA」と呼んでいた画面の時代の方が、寧ろ操作性は上だったというのは皮肉な話です。
システム開発に関しては素人なので、操作性向上のためにどれだけのコストが掛かるのかは分かりませんが、オンラインシステムとの並行状態なのは困りますので、なるべく早くバージョンアップされる事を望みます。

>AB12さま
コメントありがとうございました。
昔のものまで細かく読んでいただいて誠にありがとうございました。
一番の問題は・・・ここでは書けませんので、また”裏”ででも(苦笑)

けん@ユーロR

開発側には苦労があって、利用者には伝わらない。また、利用者が「こうして欲しい」と思っても、開発側には伝わりにくい。利用者の立場に立っても"利用者の立場"は何パターンもあるから最大公約数にせざるをえない。
伝わったとしてもコストとか諸々難題が。

クルマもそうですが、開発側と利用者側とで"共同開発"はできないものだと思うので、難しい話かもしれませんねぇ。

>けん@ユーロRさま
コメントありがとうございました。
あくまで個人的な意見ですが、実は根は単純なことなんだと思います。じゃあ何故なのか、と言えば・・・。とても語り尽くせません・・・(苦笑)→もったいつけてる訳じゃ無いんですがここでは・・・。

コメントを投稿する