パソコンを導入/リプレイスする際、必ず設計が必要になります。
例えば、失くしたら困るのでHDDの中身は暗号化しておこう。セキュリティソフトは必須だな。アップデートはWSUSを使って管理しよう。IPアドレスはDHCPにしよう。などなど。
これらは要件といいます。
企業で利用する機器は、企業のポリシー（ルール）に従うよう要件を明確にし、どのように実現するかを決めます。
これが設計です。
具体的に解を記載すると、下記のようになります。
要件を満たす機能や目的、理由を明記したうえで、採用する機能や製品を記載します。
パソコンの紛失に備え、HDDの暗号化を行う。
HDD自体にパスワードを設定することで、第三者がHDD内のデータを取得することを防止する。
既知（マルウェアやウイルス）の脅威に備えるため、EPP機能を実装する。
侵入後の挙動に備えるため、EDR機能を実装する。
EPP、EDR両機能を有する製品は複数存在するが、社内ポリシーとの親和性を鑑み、Symantec Endpoint Securityを採用する。
年に1度の機能アップデートを適用する。
月に1度のセキュリティアップデートを適用する。
クライアントの適用状況を把握できる管理ツールを採用する。
管理手法には資産管理ツール、WSUS、Intune等が存在するが、コストを鑑みWSUSを採用する。
拠点移動等のユーザーの利便性を鑑み、DHCP設定を採用する。
各拠点にはDHCPサーバを配置している。DHCP設計はサーバの設計書を参照。
パフォーマンスを考慮しSSDを採用する。
総容量は256GBのドライブを選定し、下記の用途とする。
CドライブはOS領域とし、肥大化に備え150GB確保する。
Dドライブをデータ保存領域とし、100GB確保する。
管理人が考えるに、下記の優先順位で要件を並べ、設計に反映すべきです。
担当者が「運用がラクな設計にしたい」と考えても第一優先とすべきではありません。自社のために導入するのですから、自社のポリシー（ルール）に則ることを第一優先すべきです。まずはルールを明確に洗い出しましょう。
＜セキュリティ要件の例＞
次に、利用者の使い勝手を優先すべきです。
何のために導入するのかといえば、会社の業務をスムーズに実施できるようにするためですね。
これはある種、天秤にかける作業でもあります。
パソコンのロックは多すぎると利便性を損ないますが、放置して第三者に操作されても困ります。ロックの時間は20分にするのか、60分にするのか、またはロックさせないのか。パソコンの使い方を鑑み、社内で同意を得られる値とすべきです。
また最近ではWEB会議も多くなっていますので、カメラは搭載させるのか、させないのか、カメラを隠せるシャッター式にするか。これもハード選定における要件になります。
残念ながら情シスにとってメリットとなる要件は、優先順位第三位です。
ここで考えたいのは「運用を如何にラクにできるか」です。誰しもお守りはラクに済ませたいもの、管理人kotoとて同じです。
ラクの第一歩は誰でもパソコンの運用ができるようになることです。
そのためにはイレギュラーな設定を減らしましょう。または、OUにコンピュータを配置した際に自動的に個別設定が配布されるなど、仕組みでクリアしましょう。属人的な作業やミスが減り、誰でも運用できるようになり、担当者がラクになれます。
パソコンの入替時、新入社員、人事異動、返却時、この仕組みが大きな仕事をしてくれるはずです。
同時に資産管理的な意味で、台帳への変更の反映も必要です。パソコンの返却も含め、どのように管理台帳への反映をするのか。マネージャーレベルを納得させるためには全体の運用設計の視点も必要です。
1点注意事項ですが、やろうと思えば自動化は多くの箇所で実現できます。一度仕組みを作ってしまえば勝手に設定が終わります。ですが、だからこそブラックボックスになります。作った人しかわからないシステムが出来上がるのです。
対策として、きちんとドキュメントに残しましょう。また、この仕組化を初学者～中堅が取り組むことにより、理解とレベルアップの循環を促すことができます。
ベンダーに丸投げしても社内のレベルアップは進まず、ベンダー依存体制となるだけです。ベンダーはあくまでビジネスパートナーであり、自社に対する責任を負ってくれるわけではありません。ITエンジニアが不足してくる未来では仕事を受けてくれる保証はありません。
どんなシステムでも関係者が概ね問題なしと認めなければ導入できません。または失敗です。
関係者には、立場により観点のギャップがあることに注意しましょう。
①意思決定者（社長/部門長等）
組織的観点で捉えます。運用を含め、自社で受け入れ可能なシステムであるかという観点です。
②ユーザー（利用者）
業務的観点で捉えます。日々の業務に影響があるか、ないかという観点です。
③ベンダー
責任範囲の観点で捉えます。契約書に記載の事項を満たせるか、満たせないかという観点です。
情シス担当者には、上記①②③を満たし、各関係者間のギャップを埋め、リリースまでの舵取りをすることが求められます。技術的観点に気を取られがちですが、本当に必要なことは合意を得られることです。
企業のために設計する以上、自分自身がやりたいことを全て実現することは無理だと思います。
ですが絵を描くことにより、それに近づけることはできます。
優先順位を考え、要件を並べ、どのレベルまで実現できるのかを明文化し、社内の合意を得ます。
ある程度深いITの知見も必要になるでしょう。
あなたがレベルアップを目指すのであれば、これらと向き合い、一歩ずつ成長し、理想に近づいていただきたい。