利用者目線で考える設計とは?IT初心者が現場で押さえるべき考え方と具体例
結論から言うと、利用者目線で考える設計とは「作る側が便利なシステム」ではなく、「実際に使う人が迷わず、安全に、効率よく業務を進められるシステム」を考えることです。
IT業務では、技術的に正しく動くだけでは十分ではありません。ログインしにくい、ボタンの場所が分からない、エラーが出ても何をすればよいか分からない、といった状態では利用者の負担が増えてしまいます。
特に社内SE、情シス、ヘルプデスク、インフラエンジニアは、サーバーやネットワークだけでなく「その仕組みを誰が、どこで、どのように使うのか」まで考える必要があります。
この記事では、IT業務を始めたばかりの人に向けて、利用者目線の設計で確認すべきポイントを現場の具体例とともに整理します。
- 利用者目線で考える設計とは
- なぜIT業務で利用者目線が重要なのか
- 「利用者」とは誰なのかを最初に考える
- 利用者目線で設計するときの基本的な考え方
- 現場で使える「利用者目線」の確認項目
- 具体例1:共有フォルダを利用者目線で設計する
- 具体例2:パスワードポリシーを利用者目線で考える
- 具体例3:Windows Updateを利用者目線で設計する
- GUIとCUIのどちらを使わせるかも利用者目線で考える
- トラブル時まで考えて設計する
- ログを確認できる設計も重要
- Windowsならイベントビューアーも確認する
- PowerShellやコマンドプロンプトを利用した確認
- 初心者が混乱しやすい「利用者目線」と「要望どおり」の違い
- 筆者が現場で失敗した利用者目線不足の例
- 利用者目線の設計で初心者がやりがちなミス
- 現場で評価される確認手順
- 上司へ報告するときのポイント
- エスカレーションするタイミング
- 利用者目線の設計で注意したい危険な設定変更
- 一歩進んだ利用者目線の設計
- 関連して覚えておきたいIT用語
- 利用者目線で考える設計についてよくある質問
- まとめ
利用者目線で考える設計とは
利用者目線で考える設計とは、システムを利用する人の知識、業務内容、操作環境、困りごとなどを想定して設計する考え方です。
例えば、社内で利用するシステムを設計するとします。開発担当者やIT担当者であれば「ブラウザを起動してURLを入力してください」という説明でも理解できます。
しかし、PC操作に慣れていない利用者の場合、「ブラウザとは何ですか」「URLはどこに入力しますか」というところで止まる可能性があります。
この違いを意識することが利用者目線の第一歩です。
自分が分かるから相手も分かる、という前提で設計しないことが重要です。
なぜIT業務で利用者目線が重要なのか
利用者目線が不足すると、システム自体は正常でも問い合わせや操作ミスが増えます。
| 設計上の問題 | 利用者に起こること | IT担当者への影響 |
|---|---|---|
| 操作方法が分かりにくい | 操作を間違える | 問い合わせが増える |
| エラー表示が難しい | 対処方法が分からない | 毎回ヘルプデスク対応が必要になる |
| 権限設計が複雑 | 必要なファイルへアクセスできない | 権限変更依頼が増える |
| ログイン方法が複雑 | ログインできない | アカウント関連の問い合わせが増える |
| マニュアルが難しい | 自己解決できない | サポート工数が増える |
つまり、利用者目線の設計は利用者のためだけではありません。
問い合わせ件数や障害対応を減らし、IT部門の運用負荷を下げる効果もあります。
「利用者」とは誰なのかを最初に考える
初心者が最初に覚えておきたいのは、利用者を一括りにしないことです。
同じ会社でも、システムを利用する人のITスキルや仕事内容は異なります。
- 一般社員
- 営業担当者
- 経理担当者
- 管理職
- 在宅勤務者
- 外出先から利用する社員
- システム管理者
- ヘルプデスク担当者
- 社外の協力会社
例えば共有フォルダを設計する場合でも、一般社員と管理者では必要な権限が違います。
「誰が使うのか」が曖昧なまま設計を始めると、後から権限変更や設定変更が大量に発生することがあります。
利用者目線で設計するときの基本的な考え方
1.誰が利用するのか
最初に利用対象者を明確にします。
社員全員なのか、特定部署だけなのか、管理者だけなのかによって必要な機能やセキュリティは変わります。
2.どこから利用するのか
利用場所も重要です。
- 社内ネットワーク
- 自宅
- 出張先
- スマートフォン
- VPN接続環境
社内では正常に利用できても、自宅からVPN経由では使えないというトラブルもあります。
3.いつ利用するのか
利用時間も確認します。
例えば毎日24時間利用するシステムであれば、Windows Updateやサーバーメンテナンスの時間を慎重に設計する必要があります。
月曜日の朝に全社員が利用するシステムなら、月曜9時にメンテナンスを実施する設計は現実的ではありません。
4.何のために利用するのか
システムの目的を明確にします。
「この機能を実装できるか」だけではなく、「この機能によって利用者のどの業務が楽になるのか」を考えることが大切です。
5.トラブルが発生したらどうするのか
正常時だけでなく、異常時まで考えるのがIT設計です。
ログインできない、ネットワークにつながらない、サーバーが停止した、といった状況を想定します。
その際に利用者が何を確認し、誰へ連絡するのかまで決めておくと運用が安定します。
現場で使える「利用者目線」の確認項目
設計するときは、次の順番で考えると整理しやすくなります。
- 誰が使うのか
- 何の業務で使うのか
- どこから使うのか
- どの端末から使うのか
- 利用者にはどの程度のIT知識があるのか
- どのくらいの頻度で使うのか
- 操作を間違えた場合に何が起こるのか
- 障害が起きた場合に業務を継続できるのか
- 問い合わせ先が分かるようになっているか
- 管理者が原因を調査できるログが残るか
特に最後の「ログが残るか」は運用担当者にとって重要です。
具体例1:共有フォルダを利用者目線で設計する
ファイルサーバーの共有フォルダは、利用者目線の設計を理解しやすい例です。
例えば営業部向けに「営業共有」というフォルダを作るとします。
技術的にはフォルダを作成して共有設定を行えば利用できます。しかし実際の業務では、それだけでは不十分です。
設計前に確認したいこと
- 営業部の誰がアクセスするのか
- 閲覧だけでよい人はいるか
- ファイルを編集できる人は誰か
- 削除を許可するか
- 他部署からアクセスする必要はあるか
- 退職者や異動者の権限をどうするか
- 誤削除したファイルを復旧できるか
- バックアップは取得されるか
Active Directory環境なら、利用者一人ひとりへ直接権限を付けるより、セキュリティグループを利用して管理する方法が一般的です。
例えば「営業部共有フォルダ編集グループ」を作成し、そのグループへ必要なユーザーを所属させます。
こうしておけば、人事異動が発生した際にもグループメンバーを変更することで対応しやすくなります。
具体例2:パスワードポリシーを利用者目線で考える
セキュリティを強くすることは重要ですが、設定を厳しくすれば必ず安全になるとは限りません。
例えば非常に複雑なパスワードを短期間で何度も変更させる運用を考えてみます。
利用者が覚えられず、パスワードをメモへ書いてPCの近くに置いてしまえば、別のセキュリティリスクが発生します。
そのため、パスワードポリシーや多要素認証などを設計するときは、セキュリティと利便性の両方を考える必要があります。
利用者目線とは「何でも簡単にすること」ではなく、安全性と使いやすさのバランスを考えることです。
具体例3:Windows Updateを利用者目線で設計する
Windows 11を利用する企業では、Windows Updateの管理も重要です。
更新プログラムを適用すること自体はセキュリティ上必要ですが、利用時間中に突然再起動されれば業務へ影響します。
設計時には次のような点を検討します。
- 更新プログラムをいつ配信するか
- 再起動をいつ実施するか
- 利用者へ事前通知するか
- 更新失敗時にどう対応するか
- 重要業務を行うPCをどう扱うか
- Windows Update後に不具合が起きた場合の切り戻し方法
「更新できるから実施する」ではなく、業務への影響まで考えることが利用者目線の設計です。
GUIとCUIのどちらを使わせるかも利用者目線で考える
GUI(Graphical User Interface)は、画面上のボタンやアイコンなどを操作する方式です。
CUI(Character User Interface)は、コマンドプロンプトやPowerShellなどで文字による命令を入力する方式です。
例えばWindows 11でIPアドレスを確認する場合、GUIなら「設定」からネットワーク情報を確認できます。
ショートカットキーの「Windowsキー + R」で「ファイル名を指定して実行」を開き、「cmd」を実行してから「ipconfig」を入力する方法もあります。
管理者にとってはコマンドの方が速くても、一般利用者にコマンド操作を求めると入力ミスが発生する可能性があります。
反対に、ヘルプデスク担当者向けの手順であれば、ipconfigなどのコマンドを使った方が効率的な場合があります。
誰が操作する手順なのかによって、GUIとCUIを使い分けることが重要です。
トラブル時まで考えて設計する
良い設計は正常時だけを考えません。
障害発生時には、まず影響範囲を確認できる仕組みが必要です。
| 確認ポイント | 切り分ける内容 |
|---|---|
| 1人だけ発生 | PC、ユーザー、権限などを疑う |
| 同じ部署全員で発生 | ネットワーク、グループポリシー、権限などを確認 |
| 全社で発生 | サーバー、ネットワーク、認証基盤などを確認 |
| 特定サイトだけ接続不可 | DNS、Webサーバー、プロキシなどを確認 |
| IPアドレスが取得できない | DHCPやネットワーク接続を確認 |
| ログインできない | Active Directory、パスワード、アカウント状態などを確認 |
DNS(Domain Name System)はコンピューター名やドメイン名とIPアドレスを対応付ける仕組み、DHCP(Dynamic Host Configuration Protocol)はPCなどへIPアドレスを自動的に割り当てる仕組みです。
こうした関連システムも含めて原因を切り分けられる設計にしておくと、障害対応がスムーズになります。
ログを確認できる設計も重要
利用者から「昨日から使えません」と問い合わせを受けても、記録がなければ原因調査は難しくなります。
そのため、システム設計ではログを残す仕組みも検討します。
- 誰がログインしたか
- ログインに失敗したか
- いつエラーが発生したか
- どの端末からアクセスしたか
- どの処理で失敗したか
ただし、ログへパスワードなどの機密情報を記録してはいけません。ログの保存期間や閲覧権限についても設計が必要です。
Windowsならイベントビューアーも確認する
Windows 11のトラブルでは、イベントビューアーからエラー情報を確認できる場合があります。
- 「Windowsキー + R」を押します。
- 「eventvwr.msc」と入力します。
- Enterキーを押します。
- 「Windowsログ」を開きます。
- 「システム」や「アプリケーション」を確認します。
- 障害が発生した時刻付近の警告やエラーを確認します。
イベントID、ソース、発生日時、エラー内容を記録しておくと、上司や上位担当者へエスカレーションするときにも役立ちます。
ただし、イベントビューアーには正常な環境でも警告やエラーが記録されます。赤いエラーがあるだけで原因と断定せず、障害発生時刻や事象との関連性を確認してください。
PowerShellやコマンドプロンプトを利用した確認
IT担当者向けの設計では、GUIだけでなくコマンドで状態を確認できることも重要です。
| コマンド | 主な用途 |
|---|---|
| ipconfig | IPアドレスなどを確認する |
| ipconfig /all | DNSやDHCPを含む詳細なネットワーク情報を確認する |
| ping | 通信相手へ到達できるか確認する |
| nslookup | DNSによる名前解決を確認する |
| whoami | 現在ログインしているユーザーを確認する |
| Get-NetIPConfiguration | PowerShellでネットワーク設定を確認する |
例えば「共有フォルダにアクセスできない」という問い合わせでも、IPアドレス、DNS、ログインユーザー、サーバーへの通信、アクセス権限という順番で確認すると原因を切り分けやすくなります。
初心者が混乱しやすい「利用者目線」と「要望どおり」の違い
利用者目線で考えることと、利用者の要望をすべてそのまま実装することは違います。
例えば利用者から「パスワード入力が面倒なので、パスワードをなくしてほしい」と要望されたとします。
そのまま実現するとセキュリティ上の問題が発生する可能性があります。
この場合は要望の裏側にある「ログイン操作を簡単にしたい」という目的を確認し、シングルサインオンなど別の方法を検討します。
要望そのものではなく「なぜ、その要望が出たのか」を確認することが重要です。
筆者が現場で失敗した利用者目線不足の例
私自身、IT業務を始めた頃は「設定が正しければ問題ない」と考えてしまったことがあります。
ある設定変更で技術的な確認ばかりを行い、実際に利用する人がどの時間帯に業務をしているかまで十分に確認していませんでした。
設定自体は問題なくても、利用者から見ると「突然使えなくなった」状態になります。そこで初めて、技術的な正常性と業務上の正常性は別物だと実感しました。
それ以降は、変更作業前に「誰に影響するのか」「何時なら影響が少ないか」「失敗したら元に戻せるか」を確認するようにしています。
利用者目線の設計で初心者がやりがちなミス
- 自分のIT知識を基準に操作方法を決める
- 正常に動くことだけ確認する
- エラー発生時の動きを考えていない
- 利用者全員が同じ権限になっている
- ネットワーク障害時を想定していない
- ログの保存を考えていない
- バックアップや復旧方法を考えていない
- 利用時間を確認せずメンテナンス時間を決める
- 利用者から言われた要望をそのまま仕様にする
- 問い合わせ先やエスカレーション先を決めていない
現場で評価される確認手順
新人のうちは高度な技術を知っていること以上に、確認する順番が整理されていることが重要です。
トラブルや設計上の問題が発生したら、まず影響範囲を確認します。
- 誰に影響しているか確認する
- いつから発生しているか確認する
- 直前に変更作業がなかったか確認する
- 特定ユーザーだけか確認する
- 特定PCだけか確認する
- Windows側の問題か確認する
- ネットワーク側を確認する
- DNS・DHCPなどの関連サービスを確認する
- Active Directoryや権限を確認する
- サーバー側の状態とログを確認する
闇雲に設定を変更するのではなく、仮説を立てながら一つずつ切り分けることがポイントです。
上司へ報告するときのポイント
障害や設計上の問題を報告するときは「動きません」だけでは情報が不足しています。
最低限、発生日時、対象ユーザー、対象端末、影響範囲、エラー内容、実施した確認、確認結果、直前の変更内容を整理します。
例えば「10時15分頃から営業部5名が共有フォルダへアクセスできません。pingによるサーバーへの通信は正常で、別部署では利用可能です。営業部のアクセス権限を確認中です」のように報告すると、状況が伝わりやすくなります。
エスカレーションするタイミング
新人が注意したいのは、自分だけで長時間抱え込まないことです。
- 業務停止が発生している
- 複数ユーザーへ影響している
- サーバー障害の可能性がある
- Active Directoryなど認証基盤へ影響している
- セキュリティインシデントの可能性がある
- データ消失の可能性がある
- 設定変更に管理者権限が必要
- 原因が分からないまま影響が拡大している
このような場合は、社内の運用ルールに従って早めに上位担当者へ報告します。
利用者目線の設計で注意したい危険な設定変更
利用者から要望されたからといって、安易にセキュリティ設定を変更してはいけません。
特にActive Directoryのグループポリシー、ファイアウォール、NTFSアクセス権、管理者権限、DNS、DHCPなどの変更は、多数の端末やユーザーへ影響する可能性があります。
本番環境では影響範囲、変更手順、バックアップ、切り戻し手順、承認の有無を確認してから作業してください。
原因が分からない状態で「とりあえず設定を変更する」という対応は避けるべきです。
一歩進んだ利用者目線の設計
慣れてきたら、使いやすさだけでなく運用全体を考えます。
例えば「利用者がパスワードを忘れた」というケースなら、単にヘルプデスクが毎回対応する設計ではなく、本人確認を安全に行ったうえで利用者自身が復旧できる仕組みを検討します。
問い合わせが発生してから対応するのではなく、問い合わせ自体を減らせないか考えることも利用者目線の設計です。
関連して覚えておきたいIT用語
| 用語 | 初心者向けの意味 |
|---|---|
| UI | User Interface。利用者が操作する画面や入力部分 |
| UX | User Experience。システムを利用して得られる体験 |
| Active Directory | Microsoft環境でユーザーやPC、認証などを管理する仕組み |
| DNS | Domain Name System。名前とIPアドレスを対応付ける仕組み |
| DHCP | Dynamic Host Configuration Protocol。IPアドレスなどを自動配布する仕組み |
| GPO | Group Policy Object。Windows端末やユーザーへ設定を適用する仕組み |
| GUI | 画面やボタンを使って操作する方式 |
| CUI | 文字でコマンドを入力して操作する方式 |
利用者目線で考える設計についてよくある質問
Q.利用者目線とは使いやすさだけを考えることですか?
いいえ。使いやすさだけでなく、セキュリティ、業務への影響、障害時の対応、運用負荷なども含めて考えます。
Q.利用者の要望はすべて実現した方がよいですか?
必ずしもそうではありません。要望の背景にある目的を確認し、セキュリティや運用面を考慮して最適な方法を検討します。
Q.インフラエンジニアにも利用者目線は必要ですか?
必要です。ネットワーク、Active Directory、ファイルサーバー、Windows Updateなどは利用者の業務へ直接影響します。技術的な設計と同時に利用者への影響を考える必要があります。
Q.設計経験がない新人は何から始めればよいですか?
「誰が、いつ、どこで、何のために使うのか」を確認する習慣から始めるとよいでしょう。さらに、障害が起きた場合の影響範囲と復旧方法まで考えられるようになると、実務で役立ちます。
Q.設計時に最も忘れてはいけないことは何ですか?
正常時だけでなく異常時を考えることです。システム停止、通信障害、認証失敗、操作ミスなどが発生した場合に、利用者とIT担当者がどう動くのかまで設計しておくことが重要です。
まとめ
利用者目線で考える設計とは、単に「使いやすい画面」を作ることではありません。
誰が使うのか、どこから使うのか、業務へどの程度影響するのか、障害が起きたらどうするのかまで考えることが重要です。
IT初心者のうちは、技術を覚えることに意識が向きやすいものです。しかし現場では「設定できること」と「業務で安全に使えること」は別です。
設計や設定変更をするときは、「この変更によって利用者はどうなるか」「困ったときに復旧できるか」「IT担当者が原因を調査できるか」という3点を確認してみてください。
利用者の業務とITの両方を理解して設計できるようになると、社内SE、情シス、ヘルプデスク、インフラ運用など幅広い現場で役立つスキルになります。
