新人SEや情シス担当に読んでほしい
今回は業務システムを設計するうえで、「より使いやすく便利なシステム」を作るためのポイントを紹介していきます。
尚、今回紹介する内容は、前提としてユーザーのシステム要件がちゃんと満たされており、システムを動かすだけなら支障が無いが、よりユーザーの満足度を高める為には何を考慮すべきかという趣旨でまとめます。
システムをより良くする10のポイント
- 画面のレイアウトは可能な限り共通化するべし
- イベント毎のシステムの振る舞いは同一にするべし
- 可能な限りマニュアルを見なくても使えるシステムにするべし
- マウス操作を前提としないシステムにするべし
- 色分けによる情報の区別はなるべくやめるべき
- メッセージはマスタ化して統一するべし
- 将来の拡張を想定した予備カラムは廃止するべし
- テーブル名やカラム名は格納データが推測できる名前にするべし
- 設計書等のドキュメントが無いシステムに仕様は存在しないと認識するべし
- 納品後のサポート体制や保守費用は受注時に取り決めておくべし
上記の10のポイントを説明していきます。
1.画面のレイアウトは可能な限り共通化するべし
システム設計で重要なのは「一貫性」です。
一般的な業務システムをシステム会社で作成する場合、システムの各画面は画面生成用のクラス等を用意し、最低限の一貫性は確保しようとします。
その様に基本的な設計がされていれば良いですが、すべてのSEやSIerがその様な設計をしてくれるとは限らないため、注意が必要です。
ここで言う一貫性とは、「閉じる」ボタンの位置、「検索」ボタンの位置、各ボタンの並びや順番、画面内のコントロールのレイアウト等を指します。
未熟なSEが設計したシステムでは、機能要件を満たすことしか考慮されず、ユーザーの使い勝手まで頭が回りません。
ユーザーの使い勝手を決める一つの要素としては、「あるべきボタンなどの機能がどの画面でもあるべき位置にある」ということも重要です。
そうすることで、画面や機能が変わっても同じように操作が出来て、操作ミスを起こしにくくなります。
例えば、一つのシステムで画面によって検索ボタンや更新ボタンが右上にあったり右下にあったりとバラバラでは、画面遷移の度にボタンを探さないといけなくなります。
また、ボタンの位置は同じでも、画面によって閉じるボタンが一番右だったり、更新ボタンが一番右だったりと、ボタンの並び順がバラバラの場合は、ユーザーは確実に操作を誤ります。
尚、同一のシステム内でUI(ユーザー・インターフェイス)設計をしっかり行い、各画面の構成を統一化することは当然として、出来れば、ユーザー側で既に長年使われているシステムがあれば、それらのシステムの画面等も見せてもらい、そのシステムのUI設計を部分的に取り入れていけば、ユーザーは長年使っているシステムとボタンの配置や画面構成が似ていることで、新しいシステムでも違和感無く使用でき、それが「使い勝手の良いシステム」という印象に繋がります。
2.イベント毎のシステムの振る舞いは同一にするべし
ここで言うイベントとは、ユーザーがシステム内のボタンを押下するといった操作を意味し、振る舞いとは、ユーザーの操作をトリガーとして、システムが返す反応を指します。
例えば、データの更新が行える画面で、ユーザーが「更新」ボタンを押したあとに、システムが確認メッセージを出すと言ったやり取りが、ここで言う「イベント」と「振る舞い」になります。
上記に記載した「更新」ボタンを押したあとの振る舞いでも、画面によって確認メッセージを出したり出さなかったり、出しても、表示するメッセージのボタン設定が”OK-Cancel”だったり、”はい-いいえ”だったりして統一されていないと、やはりユーザーの使い勝手は低下します。
イベントと振る舞いの例としては以下です。
- 更新ボタン押下時の確認メッセージ有無、内容
- 登録ボタン押下時の確認メッセージ有無、内容
- 閉じるボタン押下時の確認メッセージ有無、内容、未反映チェック有無
- 検索ボタン押下時の確認メッセージ有無、全件検索チェック有無、取得件数上限値有無
- 印刷ボタンやデータ出力ボタン押下時の確認メッセージ有無、出力先指定タイアログの表示有無、表示タイミング
他にも色々あるかと思いますが、例えば上記のボタン押下時の振る舞いについては、システム全体で予め取り決めをしておくことが必要です。
3.可能な限りマニュアルを見なくても使えるシステムにするべし
システムの画面設計をするうえで、操作マニュアルをユーザーが読まなくても使用できる様な造りをするべきです。
具体的な内容は以下です。
- 画面毎の機能の概要をラベル等で表示する。※「当画面は顧客データの登録と更新、削除を行います。」など
- 同一画面内で複数の操作が必要な画面では操作手順もラベル等で明記する。※「手順①参照ボタンを押してファイル出力先フォルダを指定 手順②出力ボタンを押してファイルを出力」など
- 検索画面で、内部的に検索対象から除外される条件や必要となる条件があればラベル等で明記する。※「受注日付に値がある案件データのみ対象」など
ユーザーは新しくシステムの使い方を習得するに当たって、操作マニュアルは読んでくれないし、設計書を見ても簡単には理解できません。
よって、画面ごとに何をする目的の画面なのか、どう操作をすれば良いのかを、簡単で良いので同画面内に明記してあげることで、操作方法の習得における操作マニュアルの必須度が軽減されます。
また、検索画面などで内部的に設定されている検索条件は、設計書には当然記述されているでしょうが、画面内でも主だったものは明記されていると、データがあるはずなのに見つからないといったトラブルも減ります。
説明の文字ばかり記載されているとシステムだとお洒落感も無いですし、一見使いづらそうな印象を与えてしまうかも知れませんが、洒落たUIで何も説明が無く、マニュアルを見ないとボタンひとつ押すだけでもびくびくするようなシステムは使い勝手が良いとは言えないので、過度にならない程度に、画面内に説明は入れるべきだと考えます。
4.マウス操作を前提としないシステムにするべし
普段パソコンを使う場合、ブラウザでウェブサイトを見たり、メーラーでメールを作って送ったりするといった操作はマウスを使いながら行っているかと思います。
ただ、メジャーなアプリケーションではマウスを使わなくてもキーボードだけで操作できるように作られていたりします。キーボードの矢印キーやタブキーでフォーカスの移動、スペースキーでリストが開き、エンターキーで決定。
また、アプリケーション独自のショートカットキーも割り当てられていて、それらを駆使することでマウスは不要になります。
ではなぜその様に作られているかというと、「キーボードだけで操作をした方が早いから」です。マウス操作をする場合は、一旦キーボードから手を離しマウスに持ち変える必要があります。
これは当たり前の動作のように思えますが、例えば登録系のシステムに対してデータ入力を一日中するようなオペレーター業務であれば、都度発生するマウス操作でデータ入力作業が妨げられ、作業効率が大きく下がります。熟練オペレーターほどこの影響は顕著です。
ひとつのデータを登録するのに、仮にマウス操作が混在した状態で１分２０秒掛かり、キーボードのみの操作で１分掛かると仮定した場合、一件あたりの時間差は20秒です。一見すると大した違いに感じないかも知れませんが、延々とこの作業をする前提でコストを算出すると、結構違いが出てきます。
▪️コスト算出例
１分２０秒で300件の入力にかかる時間：400分
１分で300件の入力にかかる時間：300分
→300件の入力に掛かる時間差：100分時給1500円で雇った入力オペレーターの１分あたりの費用：25円
毎日300件の入力をする場合の１日あたりのコスト差：100分×25円＝2500円
この様に一件のデータ入力で仮に20秒の差が出る場合、オペレーターが一人の場合でもこんなに差がでます。尚、一か月で試算する場合はこの数字に20日で掛けてください。また、オペレーターは一人ではなく、複数人で作業することも想定すると、更に人数分掛けてください。そうすると、入力操作を効率化させ、一件あたりの入力時間を数秒縮めることがどれほど大切かを理解して頂けるかと思います。
5.色分けによる情報の区別はなるべくやめるべき
こういう要望はSEからの提案というよりは、顧客からの要望でよくあがってきます。例えばデータグリッドで特定の条件に合致するデータの場合は、行の背景色を変えてほしいとか、注意を促すために特定のテキストボックスについてはフォントの色を変えてほしいなど。
だが、そういった実装をしても、世の中には色の違いの区別が出来ない、または区別し辛い人が多くいます。
そう、色覚異常障害を持たれている方、所謂「色弱」や「色盲」です。
特に男性ではその比率は高く、日本の統計では男性の5パーセント程度が何らかの色覚異常を持っているそうです。※Wikipediaによると、北欧やフランスでは男性の10パーセントが色覚異常だそうです。
結構多いですね。
これまで色覚異常を持っている人たちと仕事をしたり、同僚として一緒に働いた経験もありますが、やはり色の違いが判らずに苦労されていました。そういった仕事を通した実体験から、色を区別できることを前提としたシステム設計はすべきではないと考えます。
もちろん色というのは、赤は危険、黄色は注意、淡い緑は心を落ち着かせるなど、人の本能に近い部分の認識に直結する部分もあり、上手くシステムに実装出来ればより使い勝手の良いシステムが作れるとは思います。
ただ、上記の様な色覚異常を持たれている人がシステムを使用することも想定し、もし色でデータを区別したいなら、「色」＋「文字での補足」だったり、「色」＋「網掛け線」だったり、色を識別できない人でもハンディが無くシステムを使えるように設計すべきです。
国籍、文化、性別や年齢、障害の有無などを問わずに使用できるように製品を設計することを「ユニバーサルデザイン」と呼びますが、システム設計でもユニバーサルデザインを意識した設計を心掛けることで、誰でも使える使い勝手の良いシステムが出来上がると思っています。
※昔SIerとして開発に関わったシステムで、データグリッドの行の背景色を色々な条件で変えてほしいと顧客から要望を受けて、その通りに実装したことがありました。
ただ、背景色がどの色だとどの様な意味なのかが画面上では一切説明されていなかったことから、やたらデータグリッドはカラフルだが、いちいち設計書をみないと色分けの意味合いを把握出来ないということがありました。色分けするなら色の意味も同画面内に書いておくべきですね・・・。
6.メッセージはマスタ化して統一するべし
ここで言うメッセージとは、VB系であればMsgbox関数などの、ユーザーに処理実行の確認したり、処理完了の通知をしたりする機能のことです。
この辺りは、SIerであれば、会社の設計ルールで常にマスタ化したものを使う決まりになっている場合もありますし、案件の規模や、設計担当のSEの判断で決めている場合もあるかと思います。
ここで言う「マスタ化」とは、そのシステムが使用するデータベースに、メッセージの文言や形式を定義する区分などを登録するマスタテーブルを用意し、システムの共通関数やクラスに、そのマスタテーブルからメッセージを呼び出せる機能を作っておきます。
システムでメッセージを表示させる場合は、表示するすべての文言を引数に渡した標準のメッセージ機能を使うのでは無く、新しく作ったメッセージ用の関数やクラスを呼び出します。
この様にメッセージのマスタ化をするメリットは、「システム全体でメッセージの文体が統一化される」ことにあります。
もしメッセージがマスタ化されていない状況だと、例えば、データを登録する画面で登録ボタンを押して、登録処理を実行して良いか確認するメッセージを表示する場合に、設計するSEや実装するプログラマによって
「登録します。よろしいですか？」とか
「登録しますか？」
などと、確認するという意味では同じだが、言い回しが異なるメッセージが表示される可能性があります。
そんな細かいことをユーザーは気にしないと思うかもしれませんが、確認メッセージではこの文面でこの言葉尻、処理完了メッセージではこの文面でこの言葉尻、と言うようにかっちりと共通化されていると、システムの振る舞いや応答内容に一貫性が生まれ、使い勝手の向上に繋がります。
尚、メッセージ管理用マスタのレイアウトやデータ例も提示しておきます。
| メッセージID | 種類区分 | メッセージ文面 | メッセージタイトル |
|---|---|---|---|
| 1 | 1 | 処理が完了しました。 | 完了通知 |
| 2 | 2 | %%します。よろしいですか？ | 実行確認 |
| 3 | 2 | %%です。%%はできません。 | 拒否通知 |
種類区分は、1がOKのみのメッセージ、2がOK-Cancelタイプのメッセージを指定します。必要によって別のタイプのメッセージも呼べるように区分を追加します。
メッセージ文面の%%は、メッセージ呼び出し用の関数などで任意の文字列を指定出来るようにします。
このようなマスタテーブルを用意しておいて、メッセージ表示用のシステム共通関数では、引数として、呼び出すメッセージID、メッセージ文面の%%に含める文字列(複数指定出来るなら引数を分けて指定)を指定できるようにします。
開発者はメッセージをシステムで表示させる際には、必ずこの共通関数なりクラスなりを使うというルールを作ることで、メッセージの一貫性が確保できます。
7.将来の拡張を想定した予備カラムは廃止するべし
データベースのテーブル設計をするうえで、将来的に必要になるかも知れないからと、数値1、数値2、数値3とか、文字列1、文字列2とか、区分1、区分2といったカラム名で予備のカラムを予め用意しておくことが好きな人が一定の割合で存在します。
個人的な感覚では、ある程度の年齢を越えたベテラン的な人達でそういった発想になる人が多いと感じます。
ただ、実際にシステムを運用していくと、こういう工夫はメリットよりデメリットの方が大きいので、即刻やめましょう。
予備カラムをテーブルに持たせるメリットとしては、「システムの仕様変更が必要になった際にカラム追加しなくても済む」ことだと思いますが、いやいや、カラム追加が必要になれば都度実施すれば良いじゃないですか？？
何千万件のレコードが格納されているテーブルであっても、カラム追加自体は一瞬だったり短時間で完了します。
予め用意しておいた予備カラムを使われだす状況では、併せてプログラム側の改修も必要になることが大半だと思われます。だったら結局システムに手を入れることになるので、カラムだけ用意しておく必要性は無いと言えます。
また、予備カラムのデメリットとしては、カラム名が実際に格納されるデータを現さなくなるため、カラム名だけ見てもどんな値が格納されているのかわからなくなります。カラム名の問題については、また別の項で後述します。
あと、予備カラムでは、カラムのデータ型やデータサイズを実際に格納されるデータに合わせることが出来ません。
例えば郵便番号の場合、数字だけ扱うのであれば7バイト、ハイフンも入れたければ8バイトが適切なデータサイズです。
予備カラムで都合よく7バイトや8バイトが用意されていればよいですが、大抵は100バイトとか、余裕を持ったサイズが定義されています。
その場合、郵便番号を入れるカラムなのに本来郵便番号ではあり得ない桁数が格納される余地が出来てしまい、アプリケーション側でのチェック処理が増えてしまうかも知れません。
予備カラムがあることで、場当たり的な設計でシステムが実装され、不具合を生む要因となります。
よって、謎の慣習はやめて、必要な機能に合わせて適切なテーブルを設計擦るようにしましょう。
8.テーブル名やカラム名は格納データが推測できる名前にするべし
テーブル設計において、テーブル名やカラム名の命名ひとつで、運用後のシステムの使い勝手か変わってきます。
前項の内容とも被りますが、たまにあるのが区分の値を格納するカラムに「区分」と命名されているテーブルがあります。
設計した当事者であれば何の区分を入れるカラムかは理解しているかと思いますが、当事者以外がこのテーブルを見たときに「何の区分？？」となります。
いちいちテーブル設計書を確認することになりますが、万が一テーブル設計書が無かったりすると、実プログラム内のソースやコメントを見てようやく区分の値の意味がわかる場合もあります。
後から運用で苦労するため、こういう雑な設計はやめていただきたい…。
あと、当初フラグ用カラムとして「◯◯フラグ」とい名称で使っていたカラムに対して、あとから区分として使いたくなったからと、0と1以外の値が平気で入っているケースもあります。入れる値の設計が変わったなら、必ずカラムも作り直してほしいところです。
あと、「◯◯フラグ」とい名称なのに、Nullが許されていてNullが入っているのも不具合の元です。
稚拙な設計でよくあるのが、例えばテーブルによって、「社員番号」だったり「社員コード」だったり「社員NO」だったりと、同じ値を入れるにも関わらず、カラム名称がバラバラなケース。
ひどいとデータの型まで違ってたりします。
こういったテーブル設計における不完全なカラムの設計は、アプリケーションの開発作業をややこしくし、運用フェーズでは運用担当者が苦労します。
データベース設計におけるコード設計、ドメイン設計もきっちり実施しておくことが、使い勝手の良いシステムに繋がります。
※余談ですが、よくカラム名に日本語は有りか無しかということが議論されます。もし私が設計担当のSEで、まるっと新規のシステム構築であれば日本語カラム名は使いません。
理由は「未知の不具合にはまる可能性があるから」です。
メジャーなデータベース製品も昨今はほぼ日本語のカラム名に対応していますが、やはりアルファベットでカラム名を定義しておく方がリスクは低いと考えています。
ただ、既存のデータベースが有り、そのデータベース内で既に日本語カラムを採用しているような環境下にテーブルを追加してシステムを構築するのであれば、「一貫性」の観点から日本語カラム名を採用します。
9.設計書等のドキュメントが無いシステムに仕様は存在しないと認識するべし
過去の経験で言えば、SIerで勤めていた頃は、見積書内で工数計上していた各種設計書の作成工数に対して、見積もり費用を下げたい顧客の思惑から、「この設計書は運用後に見返すこともないので不要」とか「予算が足らないのでドキュメントの納品は一切不要」といった交渉を受けたこともありました。
また、情シスに居た時には、そういったドキュメント不要交渉が過去にあった設計書がほとんど存在しないシステムの運用を担当した経験もあります。
そういった経験も踏まえ、情シスや新米SEに伝えたいのは、
ということです。
どの様な意味かと言いますと、システム開発における各種設計書は、納品後に仕様を確認する為に見返す目的が主ではなく、開発者と顧客が「これからこういったシステムをこの様に作りますが良いですよね？」という合意形成を行う為の資料です。
また、システムが出来上がった際には、「設計書通りに作りました。プログラムを納品するので設計書通りになっているかをお客さんも確認してください。」という意味合いで検収をします。
よって、本来設計書の意味合いを正しく理解していれば、複数ある設計書の一部、または大半の納品を不要とした場合、顧客からしたら、納品されていない設計書に関連する機能で想定と異なる実装があっても、それに対して修正を求めることはできません。
また、SIer側からしたら、設計書を顧客に提示して合意形成していない内容で実装しているプログラムに対して、顧客から修正要望が来た場合に、それを断る根拠が存在しないことになります。
これはSIer側も顧客側もお互いが不利な状態と言えます。この場合、SIer側と顧客側でより力関係の弱い方が、相手の言い分を受け入れて譲歩することになります。
よって、システム開発における見積もり費用の交渉において、設計書等のドキュメントを減らすことによる作業工数削減は絶対に実施してはいけません。
SIer側視点で言えば、本来システムを開発するにあたって、顧客と合意形成が必要と考える範囲は全て設計書として明文化し、必ず納品物のリストに含めてください。
また、顧客側視点で言えば、設計書を軽視せず設計書の中身を精査出来る能力を持つ人材が居ないのであれば、能力を持つ人材を雇うか、コンサルと契約してください。
そのうえで、見積書の内容で費用交渉をする場合には、以下の2点に絞って調整することを推奨します。
- システム要件で優先順位を付けて優先順位の低い機能を減らす、次期開発対象に繰り下げる。
- 実装における前提条件を複数付与して、システムが網羅すべき処理を減らし、開発工数を削減する。
前者は単純に実装する機能を減らして見積もり金額を減らすことです。
後者は、例えばウェブシステムで言えば、動作保証するブラウザをIEの特定のバージョンに限定したり、Windowsアプリケーションであれば、動作環境をWindows10のみに限定するといったことです。
どのような前提条件を付与すれば工数が下がるのかは工数を算出したSEでないとわからないため、顧客は、「前提条件を付与することで工数が下がる可能性のある機能を提示してほしい」とSIerに依頼する流れになります。
システムをより良くするには、システム開発を発注、または受注する段階から、然るべきプロセスを経て進めていく必要があります。
10.納品後のサポート体制や保守費用は受注時に取り決めておくべし
多いパターンではシステム開発の初期開発費用しか見積り金額に計上せず、納品後に保守費用の話をして、顧客とトラブルになったり、瑕疵担保と保守作業を顧客、またはSIer側が混同していることでトラブルになったりします。
また、顧客側が保守費用の必要性を理解しておらず、一度納品してもらったシステムに対する問い合わせや不具合対応は無期限で対応、実施してもらえるのが当たり前という認識を持っていたりします。
より良いシステムとは、納品した直後の使い勝手だけではなく、運用後のシステムに対するサポート体制によっても変わってきます。
いくら納品直後は使い勝手や品質に満足していても、システムを運用していけば、不具合と思われる挙動を見つけたり、業務の変化に併せてシステムの仕様を見直したりしたくなります。
そういった場合に、専門的なサポートをSIerから受けられる体制を確保しておく必要があります。
ただ、それは無償では本来受けられません。システムに対する問い合わせを受けるにも、不具合かどうかの調査をするのにも、技術者に対応をしてもらう必要があり、ぞれには労力が発生します。
詳しくは当ブログの過去の記事て記載しておりますため、一読していただけると幸いです。
「より良いシステム」とは、前項で繰り返し記載してきた設計上の考慮だけではなく、運用後のサポート体制といった部分までしっかり確保されているかも重要な要素だと考えます。
まとめ
今回10のポイントと称して列挙させて頂きました。
SIerであれば、自社でシステム設計時のルールを設けて、厳密に運用し、今回記載しているようなレベルの低い問題が発生することは無い会社が大半かと思います。
また、顧客側であれば、情報システムにおける納品物のルールや、開発工程ごとのSIerとの合意形成についてしっかりした取り決めを設けて運用している会社が大半かと思います。
ただ、なかにはそういったレベルに満たないSIerやSE、発注側の顧客もまだまだ多く存在していることは過去の経験則から身を以て認識しております。そういった会社や技術者の皆さんに力に少しでもなれたらと思い、記事を作成しました。
また、設計に関する記述については、人によっては賛同出来ないと思われる方もいらっしゃるかと思います。その場合はすみません。
今回も長々と読んで頂きましてありがとうございました。
↓スクラッチでのシステム開発ではなく、RPAに興味があるあなたは以下の記事はどうでしょうか？
